原理:一碗水,望一個杯子裡灌,杯子裝不下了,我們會說,水溢出了。因此溢出在現實中可以描述為,當液體被倒入容器中,而超過了容器的限制時,就會造成溢出。駭客技術所描述的溢出,含義基本是一樣的。當某個資料,超過了處理常式限制的範圍時,該資料就會造成程式的執行溢出(overflow)。
通常一些系統在未對接收資料進行嚴格判斷的情況下,都有可能造成溢出,對於一些無心的操作者,溢出最多會造成該處理進程報錯或者異常終止,並不是很嚴重的事情,有人奇怪,異常終止還不嚴重嗎?實際是這樣的,這裡我們面對的多人共用服務的應用,通常一個服務進程在接收一個使用者請求時,會建立一個子進程去進行應答和服務,如果這個子進程接收了一些無特別含義的超過限制的資料,通常會終止,而服務的父進程和其他子進程並不受影響,因此對系統的危害實際上並不大。但是如果這個資料包是被精心構造的(參見上文,特殊字元構造法),那麼在溢出點後面的就可能是精心策劃的代碼,從而進行服務端的代碼執行,進而有可能控制系統。
溢出攻擊法的危險在於,大部分系統設計者在設計初都無法完全預料和防範溢出攻擊的各種可能性,
因此事實上任何具有一定複雜性的服務系統幾乎都肯定有遭受溢出攻擊的危險,只是有的已經被發現,
有的尚未被發現而已。從Wu-ftp,Sendmail,IIS,qmail,到Apache,幾乎全部世界上最通用的網路服務
系統,都曾出現過能夠導致溢出攻擊的漏洞。
而且每個漏洞都是極端高危險的(可被攻擊者獲得對服務系統的控制),這種危險是如何?的呢?
一個程式被執行,程式碼片段(這裡的程式碼片段通常不是程式員編寫的原始碼,而是經過編譯和處理後的
彙編指令)會放到記憶體裡,程式碼片段所處理的資料也會放在記憶體裡,通常資料區段會在程式碼片段前面,
這裡明確一點,電腦並不認識誰是代碼,誰是資料,在它眼裡,只有0和1,也就是高電平和低電平。
通常資料和代碼都會相安無事,但是如果資料超過了資料區段的限制,佔用了程式碼片段的位置,那就不
一樣了,如果是資料提交者無意造成的,通常是造成代碼無法執行,該子進程的崩潰。但是如果是
精心構造的,那麼就有可能改寫程式碼片段的執行命令
(通過彙編),從而讓程式碼片段(請記住這個程式碼片段是在伺服器的記憶體上)執行攻擊者所期望執行的
操作,這樣,入侵者就可以在隨心所欲的讓伺服器執行自己要執行的操作,也就是控制伺服器的整個
系統(而不是單純的應用服務)!
攻擊方式:
1.測試溢出點
假設我們針對一個服務系統進行資料包的構造和發送,通常,服務系統溢出的錯誤顯示和錄入錯誤的
顯示是顯著不同的,錄入錯誤的提示是服務系統程式所產生的相關資訊,而溢出的提示是作業系統所
產生的相關資訊,根據錯誤資訊的差異,有經驗的駭客可以很快判斷該應用系統是否存在溢出點,
這個過程通常是一個程式迴圈執行,用各種長度或格式的報文進行測試,並比較系統返回的資訊,通
過逐步細化範圍,有經驗的駭客可以測算中具體溢出點(也就是可以放置攻擊代碼的臨界點,如果放
置錯了哪怕一個位置,都不可能被系統執行,這种放在記憶體裡的彙編和用開發工具寫原程式對格式的
要求,位置的要求都是極高的)
2.構造攻擊代碼
這要看攻擊者的目的和企圖了,沒有定論,但是有幾點要強調的,第一是代碼格式和規範必須與受攻
擊系統的相關彙編指令完全一致,第二是代碼結束要乾淨,比如中斷進程,如果結束不乾淨,又和人
家原來系統的代碼攪在一起,執行過程就可能會偏離攻擊者的意圖。
3.進行控制和入侵
如果相關攻擊代碼載入了後門,開闢了專門的shell, 那麼這名攻擊者就可以方便的進出該系統,實
現更方便的控制。
防護方式:
對於系統的設計者,必須對太多地方考慮周詳才可能避免這種方式的入侵,實際上所謂超過限制,有
時候不一定是超過長度,一個長度標記位的改寫就可能逃避長度檢查,達到溢出攻擊效果。
對於系統維護者,那沒有辦法,只能天天多看相關安全網站的最新問題,一旦確認和自己系統所處的
服務環境有關,就一定要立即去相關網站下載補丁,進行防護,不過還有一些其他辦法可以盡量減少
攻擊者的攻擊:
第一,除非一定需要,盡量少開服務。少開服務的意思就是讓攻擊者缺少與系統進行溝通和資料互動
的通道,減少被攻擊的可能。
第二,如果是專有的服務,使用IP屏蔽技術。如果某些服務(如telnet,ftp),僅面向有限人群,而
這些人群的IP地址相對集中,可以使用IP屏蔽方式讓其他IP使用者無法訪問,這樣其他IP地址的使用者就
無法和該系統進行資料互動了。
第三,如果是面向有限人群服務,可以使用改變服務連接埠的方式,比如你的FTP服務僅限於一些比較
熟悉的朋友,如果他們上網環境無法固定(無法提供IP屏蔽),可以將相關服務連接埠改變並通知他們,
這樣可以使大部分網路上的掃描器無法發現的該服務的存在,也就使那些比較懶(沒有太多時間做全
連接埠掃描)的駭客放棄對你網站的糾纏。
第四,如果有特殊興趣,可以使用連接埠偽裝技術,讓駭客進入你的圈套,被假象迷惑,從而保護你真
實的服務。這樣你還可以偷偷對駭客的入侵和攻擊行為進行跟蹤和分析。
經典案例:
如果有人說,我控制了全球50%的web伺服器,你一定以為他瘋了,而apache Chunk分段溢出漏洞的發
布,真的讓使句話成為了事實!
Apache一直是自由主義者,共用主義者的一面大期,很少有商業公司,能夠在microsoft的奮力追趕
下,不會失去市場優勢的,不管是Apple(他們的視窗作業系統,windows的前身),NetScape
(被IE兩三年內輕鬆擊敗),
Borland(borland C++被後來居上的Visual C++輕鬆擊敗), 碩果僅存的Oracle還被老巨無霸IBM幹到
了老二的位置上,而一個非商業組織的Apache Web Server能夠立壓微軟大力推廣的IIS多年,一直保
持應用伺服器全球使用率50%以上的比例,甚至於不少人在windows主機上用apache做web伺服器
(他們通常都是被IIS漏洞搞的心力憔悴了),這不能不算一個奇蹟了,在IIS千瘡百孔的時代,雖
然apache也有一些諸如phf.cgi,nph-test.cgi等有名的漏洞,但是還都停留在附屬配套軟體身上,
本身一直還都沒出過太出格的問題,也深受全球使用者的好評,但是這次,micro$oft的fans們終於可
以長出一口氣了,"看看,敢情apache也有這毛病不是"。
bug起源是這樣的,本身apache對chunk資料分段的支援是有長度驗證的,但是由於對無符號數意識
不夠,導致攻擊者精心構造的分段資料包可以在逃避驗證後,造成記憶體配置的溢出!從而執行攻擊
者精心構造的代碼。涉及範疇包括了絕大部分的apache版本,也就是相當於全世界50%以上的
Web Server都有這個問題!
與此類似的還有以前Sendmail各個版本屢補不淨的溢出問題(弄的我現在看到senmail的就怕怕),幾個
全球流行的ftp軟體屢補不淨的溢出漏洞。甚至一些路由裝置,乃至防火牆,也常常暴露出同樣問題,
真是一言難盡。
總結:
溢出攻擊法的特點是,只要用足夠的技術,對系統有足夠的認識和分析,就能夠通過溢出攻擊獲得對
系統的控制,從而達到攻擊的最高目標,而這個過程中,不需要依賴於密碼的破解,嗅探,偵聽等手段,
也不需要任何非技術的手段和騙局,事實上,如果能夠成功實施溢出攻擊,即便是面對一個已知的漏洞,
在沒有特別傻瓜化的工具情況下,也需要非常高的系統認識能力和低層編程素質,一些精深的老駭客樂於
此道而不思其餘,是很有道理的。
溢出攻擊法所以前文章所言,仍然屬於特殊字元構造範疇,所不同的是,其攻擊的思想已經不在簡單是
面嚮應用程式本身的程式設計問題,而是更多進入了系統級的考慮,包括記憶體段的分配,不同系統下
彙編的規範,協議層的報文規範,這些都是其他特殊字元構造法所沒有涉及的。精通溢出攻擊並能通
過該領域進行問題研究者,是最容易讓全世界網管都嚇一跳的人