深入淺出MS06-040(6)

 3 展望篇
——山高月小，水落石出
大道不過二三四。然而在我看來，唯有跟進記憶體，盯著寄存器，被莫名其妙的問題反覆鬱悶之後最終成功的人，才有資格談論“道”。下面就讓我們撥開雲霧去看看山高月小和水落石出的美景吧。
3.1 魔波，蠕蟲現身！
不管是讓遠端機器“嘀”一下，還是綁定command作為後門，或者磁碟格式化，這些在編程技術上是沒有本質區別的。可能犇犇們的技術到了一定層次會有種高處不勝寒的寂寞感吧，就有人會寫點東西讓自己的程式利用漏洞在網路間自己複製傳播，這就是蠕蟲。
由於在XP SP2上MS06-040是不能被成功利用的，主要受害機器集中在WIN2000和XP低版本作業系統，所以受害機群較少。另外RPC調用需要使用139 和445連接埠，這兩個連接埠早在衝擊波年代就被各大網關路由全面封殺過了，所以從網路角度講，這次電腦風險還不致於引起擁塞癱瘓。
但是我個人認為，這次電腦風險還沒有完全過去。因為蠕蟲爆發時正值學校放假，可能當時影響並不大。現在高校開學，大量校園網使用者無法出國更新補丁，所以仍應當提高警惕。
魔波的逆向分析我不想在這裡佔用篇幅了，本著學習研究提高技術的目的，我把魔波的shellcode部分放在了附件中，至於完整的代碼和可執行檔PE樣本麼，請原諒這裡不方便公布，因為萬一幾個熱血的朋友用這些資料搞出幾個蠕蟲變種來我可擔當不起這個責任。
魔波的主要行為是開後門，把目標機變成能夠被遠控的“殭屍”機。這和衝擊波那種純粹以傳播為目的的蠕蟲小有不同。恰巧課題組有兩位博士在做這方面研究，就大嘴巴替他們多說兩句了。
目前蠕蟲研究的主要思路是從網路行為上提取特徵進行預警和控制。簡單說，就是蠕蟲在傳播時會探測性的發出大量的掃描資料包，這會造成特定的資料包在網路中指數級的迅速增長，大量佔用網路頻寬。研究者通過即時監控網路情況，從網路流量中提取諸如協議種類、協議比重、流、時序等特徵來進行檢測。當發現蠕蟲爆發時，可以根據蠕蟲的傳播形式建立數學模型進行預測和控制。一般在分析網路行為時會用到大量《隨機過程》和《數理統計學》中的知識，比如用“隱馬爾可夫鏈” 來處理時間序列上的隨機資料最近在這個領域應用的就挺火。在控制預測中一般會用“傳染病”預測模型建立一套方程組給出預測和控制。如果你有興趣，
IEEE、ACM上可以找到很多paper，你不妨用EI或者SCI搜幾個來看看。不過這類文章就是所謂的講“道”的文章了，裡邊全是偏微分方程，基本上是見不到寄存器狀態的。
另外一個比較新興的研究領域就是在IPV6下研究蠕蟲擴散。從技術上講，似乎和我們的實驗還是沒有質的區別，無非在shellcode中把Beep（）調用換成IPV6的網路操作而已；從學術角度講，似乎也沒有大的區別，還是傳染病預測理論麼。其實不然：IPV4和IPV6一個重要的區別是地址空間的增加，在稀疏的地址空間裡如果還像傳統蠕蟲那樣隨機掃描目標主機來感染的話，那麼建立數學模型預測一下會發現，兩種協議下被感染主機數量的曲線形狀幾乎是一樣的，都是類指數曲線，但時間軸座標會完全不同，感染進度在IPV4下是按秒和分鐘來計算的，而IPV6下是XXXX年！
當然，理論上預測出的傳播困難在我看來也是可以促進hack技術的進步的。下一代在IPV6蠕蟲在傳播技術上必需有新的創意，發現目標主機將是一個痛點。隨機掃描是不可取的，可以嘗試別的技術和利用別的層次的協議，比如利用DNS和ARP上的主機資訊去傳播。
當IPV6蠕蟲真的出現的時候，傳播模型當然也會有很大變化，又可以湧現出許多新的學術研究成果了，真的是在攻防中共同進步啊。
這方面的資料可以參看課題組的博士剛剛在電腦學報8月安專刊上發表的文章《IPv6網路中蠕蟲擴散模型及分析》，他們是這方面的專家。
3.2 補丁，無洞可鑽？
享受了溢出的快感之後，難道你不想看看微軟補丁裡究竟修改了什麼嗎？我在附件中給出了補丁前後的不同版本的netapi32.dll。用IDA看一下，在做長度檢查時，已經由補丁前的限制0x411改成了補丁後的0x208。XP SP2的補丁前後的DLL我也給出，你們不妨也去看看有哪些變動。MS06-040中除了NetpwPathCanonicalize（）還有其它問題，這裡不再討論，有興趣的可以參考0x557上面的分析。
有鑽洞的能力還要有洞可鑽才行，否則補丁過後蟲蟲不是沒有活路了。這裡我想談談怎麼挖掘0day。
0day是指能被成功利用，而微軟官方並不知道或知道並未公布的漏洞。掌握一個0day，你就幾乎可以所向披靡的隨意hack全天下機器了。我們討論的 MS06-040在發布前無疑是一個被犇犇們玩弄於股掌之間的0day。不管是對hacker，對微軟，對軍方，對安全公司，0day都有很重要的意義。能夠利用漏洞只是懂了一點技術的大鳥，能夠發現0day的才是真正的犇犇。
其實在我們實驗的基礎上，把RPC溢出的代碼略加改動，豐富一下IDL中的介面和函數的定義，你就可以擁有自己的RPC函數的漏洞發掘工具了。遠程函數如果需要int的就給送long型，指標的就試驗NULL之類的，字串的就用超長的往裡塞，總之就是把所有可能引起錯誤的因素組合一下，一個一個的送進函數看反應。你可以編程把RPC能夠CALL到的遠程函數一個一個的測過去，如果發現崩潰的就用我們前面的調試方法跟進去看看崩潰的原因，結合棧和寄存器的狀態確認下能不能利用，運氣好了就會撞到0day啦。
從今年的《XCon 安全焦點資訊安全技術峰會》上回來，有不少感慨。14位演講者中涉及漏洞挖掘方法的就有四位。Funnyway和CoolQ在代碼審計上的嘗試讓人看到了 hacker的勇氣，而Dave現場示範的RPC漏洞fuzz則直接關注於技術本身，最後來自微軟的Adrian發表的對0day的看法，則強烈的激勵著有志之士投身這個領域。下面就結合我個人的研究，談談我對這個領域的瞭解和看法。
其實上面談的測試0day的方法就是工業界目前普遍採用的fuzz方法。Fuzz實際上就是軟體工程中的黑箱測試。你可以對協議，對API，對軟體進行這樣的fuzz測試。fuzz方法的優點是沒有誤判，儘管可能有些運行錯誤並不能被成功利用；缺點是你無法窮舉所有的輸入，就算fuzz不出問題也無法證明一個系統是安全的。
學術界則偏向於用演算法直接在程式的邏輯上尋找漏洞。這方面的方法和理論有很多，比如資料流分析，類型驗證系統，邊界檢驗系統，狀態機器系統等。這種方法的優點是可以搜尋到程式流程中的所有路徑，但缺點是非常容易誤判。
半年前我曾經研究過一段時間代碼級的漏洞挖掘，用的方法大概也是上面列出的這些靜態分析技術，並且實現了一個分析PHP指令碼中SQL注入漏洞的挖掘工具的 demo版本。研究過後深深覺得代碼的靜態分析理論要想在工業上運用還有很長的路要走，突出的問題在於大量的誤判。個人認為，所有這方面理論都面臨同樣一個棘手的問題：就是在處理常式邏輯中由動態因素引起的複雜的條件分支和迴圈時，靜態分析的天然缺陷。靜態分析演算法要想取得實質性的突破必須面對“徹底讀懂”程式邏輯的挑戰，這在形式語言上實際涉及到了上下文相關文法，而編譯理論和狀態機器理論只發展到解釋上下文無關文法的階段。
如果代碼靜態分析技術真的在文法的解釋上有所突破，那麼從數學上證明一個軟體沒有缺陷將成為可能！這種進步不光是在漏洞挖掘上的進步，更重要的是電腦背後的形式語言和邏輯學的飛躍——這可能將是能和萊布尼茲、歌德爾、布爾、圖靈、馮諾伊曼那一票邏輯大師的貢獻相媲美的成就——喬姆斯基的文法體系出台後的這50多年裡，雖然編譯理論和技術蓬勃發展，但時至今日，電腦能“讀懂”的語言始終局限於上下文無關文法。展望一下電腦能處理上下文相關文法甚至圖靈機的那一天將會是一副什麼樣的美景吧：VC編譯的時候不用運行就會告訴你哪裡有死迴圈、哪裡記憶體流失、哪裡的指標在什麼情況下會跑飛……編譯器不只會檢查文法問題，還會檢查邏輯問題，軟體工程中不論開發還是測試的壓力都將大大減輕，整個電腦工業體系都將產生一次飛躍，當然我們的漏洞發掘工具也更智能——
只是真的有那一天hacker們可能都要下崗了：）