我是怎樣進入中國最大軟件公司站點的(繁体)
大家都知道，中國有個最大的操作系統軟件生產廠家，那就是 chinalinux。很多人都想試圖進入其主站點 http://www.chinalinux.com，因為那將是對自己的一個挑戰。終於有一天成功的進入了其主站，在此寫出我的過程，以及對常見web服務的安全模型的理解，對此的一些總結等，希望大家能夠從中得到自己的理解。
首先，那當然得介紹介紹這chinalinux站點的一些情況吧。http://www.chinalinux.com是使用自己開發的一個由linux升級得來的中文操作系統，而web服務也是采用自己的產品ccs。這ccs安裝、使用非常方便，也很容易配置管理，所以很多管理員都喜歡使用這個產品。
為了要能進入這樣的站點，那當然就得熟悉ccs這個web服務系統了。根據這個系統的一些基本服務特性，以及一些權限配置，簡單總結後有三點。
一、ccs系統提供外界可以訪問系統一部分目錄文件的服務
二、ccs提供虛擬目錄配置，每個虛擬目錄可以對應一定的權限
三、ccs系統文件類型配置，可以配置不同的文件類型，提供直接在服務端運行和返回客戶端運行兩种方式
通過上面的了解，我總結出了ccs的一個安全模型，那就是ccs是一個外掛式的有權限限制的web系統。怎麼來理解這“外掛”呢？因為大家熟悉操作系統的都知道，操作系統本身對一些對象有權限控制，而這ccs系統的權限控制不是依靠操作系統本身的這些功能，而是依靠自己的一些檢測。最重要的一點，操作系統對對象權限的分配都附在對象本身身上，而ccs的是把所有對象的權限分配記在ccs系統上面。
這點有什麼區別呢，操作系統處理的時候每個真實對象有一個檔案，而每個對象可能有些別名，這樣訪問這些別名的時候我們不用關心它到底是別名還是真名，只要最終對應到那個唯一的檔案就能正確的得到權限分配。打個形象點的比喻，月底發工資，操作系統把每個人建立了一個唯一的檔案，這些檔案里面記錄有這個人的工資，而這個人可能叫小張也叫張三，那麼發工資的時候不用管他叫小張還是張三，最終是找到了他的工資表也就正確的發放了他的工資。而對於ccs系統來說，因為它沒有這樣一張工資表，它就是根據人名來確定工資，所以它就必須考慮每個人所有的名字才能正確的發放工資。所以根據這個基本的特點，總結出了安全編寫ccs系統應該注意的四點：
1、 ccs系統提供的服務應該做chroot限制
2、 ccs系統應該能識別一個真實目錄對應的所有目錄名
3、 ccs系統應該能識別一個真實文件對應的所有文件名
4、 ccs系統的調用接口應該完全按照接口意思實現
這幾點，每點都可以寫出一大篇文章了，因為這篇文章不是寫這些，所以也就只寫這點提綱式的東西吧。不光是CCS系統需要注意上面4點，其它的WEB服務器差不多同樣需要考慮這樣4點。
根據這些認識以及對一些原來公布漏洞的理解，很快就發現了大量的漏洞，在此總結出來原因：編寫CCS系統的人員沒有建立一個安全模型，對安全沒有深刻的認識，所以在系統實現上就沒有系統的、全面的對權限做檢測，只是編寫人員想到一條做一條，因為沒有明確提出這些安全上的要求，這些檢測也往往是很容易逃避的，所以造成這麼多的漏洞。
說了這麼多，還沒有正式提到漏洞，那就馬上來了。根據上面的第1條，顯然CCS系統應該檢測用戶請求中的“/../”，這點不知道現在還有多少WEB有這樣低級的嚴重的不可饒恕的錯誤。CCS系統低版本就有這樣的漏洞，但現在顯然沒有了，它會先檢測這樣的請求，做出正確的處理。但是因為沒有這樣明確的安全模型，所以錯誤又出來了。為了對多語言以及一些傳輸設備的支持，CCS系統支持一种unicode的傳輸編碼格式，而經過這樣的解碼後，請求的字符已經發生變化，顯然根據上面安全模型的提出的“外掛式”特徵，這權限檢測不能依靠解碼前的檢測，需要再次檢測，而CCS根本就沒意思到這些，所以我們可以輕易突破所有這些限制了。
於是試了其主站http://www.chinalinux.com果然有此漏洞，不過沒法利用幹什麼事，因為其主站虛擬目錄對應的一個可執行/csapi目錄是作了chroot限制，也就是通過這個虛擬目錄，往上級目錄返回最終也到不了系統的根“/”，當然也就不能執行系統/bin/目錄里面的東西了，也不能得到/etc/目錄里面的密碼文件，而那些缺省安裝沒有做chroot限制的可執行虛擬目錄卻被刪除。好不容易找到一個漏洞卻不能利用。
不過後來偶然一天訪問到其一個分站點http://support.chinalinux.com，於是偷偷的試了一下其缺省安裝的可執行虛擬目錄/chinaadc，就是在瀏覽器里面輸入了http://support.chinalinux.com/chinaadc/，乖乖，返回的是“HTTP 錯誤 403 - 禁止訪問”而不是此目錄不存在的“HTTP 404 - 無法找到文件”錯誤。大家都知道這個目錄是沒有做chroot限制的，可以成功的返回到系統的根“/”,再進入系統目錄“/bin/”，執行下面的shell程序“sh”了。當然也就用此sh查看了一些web目錄結構。
http://support.chinalinux.com/chinaadc/..%c0%af../..%c0%af../bin/sh.elf?ls+/http
就可以看到web目錄所在東西了，很高興的看到了此目錄里面有一些腳本“.sh”文件。
對於這些腳本文件，CCS系統又有漏洞，那就是上面第4條的一個漏洞。在作接口的時候，接口實現程序一定得完全按照接口意思實現，這點CCS系統出了更是無數的漏洞。而因為CCS是相對操作系統後出來的了，它在調用操作系統調用的時候，當然就不能要求操作系統來滿足它的要求了，這些調用本身處於比CCS系統低的層次，也不應該去滿足CCS的特殊要求，所以CCS必須明白一些操作系統調用有什麼特殊的地方。這在 chinalinux系統實現加載程序的調用上，為了支持長文件名、文件名里面的空格等，可以在加載的文件名前後加上“””號，chinalinux加載程序就是用“””來匹配到底加載的是哪個文件。而又一點，如果檢測到是加載“.sh”的腳本文件，就自動的調用shell程序“sh”去解釋，而這調用也饒過了chroot使得不能訪問“/”以及系統目錄的限制。在調用“sh”的時候，操作系統會把這個腳本文件以及腳本文件的參數統一作為參數加載。大家都知道shell程序“sh”本身支持命令連接符、管道等，所以我們可以在參數里面加上命令連接符和我們要執行的命令。所以CCS在加載程序的時候就必須應該明白操作系統chinalinux加載程序的這些特性，從而實現相應的檢測。
對於上面看到的web目錄結構，以及里面的那些“.sh”腳本文件，我大膽的猜測其主站http://www.chinalinux.com可能也存在。雖然CCS系統不准直接加載“.sh”的腳本文件，但是我們可以通過使用“””的辦法使得實際加載的不是CCS系統需要的“.elf”格式文件。
http://www.chinalinux.com/csapi/..%c0%afhttp/china.sh”+.elf?”+&+ls+/bin
成功的突破了chroot對根“/”的限制，查看到了系統目錄，也可以完全控制主站了。當然這些不是目的，我們也不希望這樣的站點有任何的被修改，後來其站點終於也打上了相應的補丁。
後來有人用unicode漏洞破了chinalinux一個廢棄不用的分站點，改了一個頁面並且大肆宣揚，這完全沒有必要。我們需要的是通過這些方法得到我們考慮問題的思路、方法等，而不是去破坏。
最後再次總結：
一、編寫WEB服務安全模型建立的必要性
二、站點安全配置往往因為一點小小的錯誤，使得全線崩潰
希望我們的程序員在編寫安全程序的時候，也要多考慮考慮我們怎麼能夠更好的編寫安全的程序。发布人:Crystal 来自:中联绿盟BBS