大規模網頁綁架轉址之水落石出篇
来源：阿碼外傳
山高月小，水落石出、清風徐來，水波不興！
最近的大規模轉址事件，由於影響範圍廣大，引起了各方的討論，o0o.nu的fyodor yarochkin（聯絡方式：fygrave 鼠 o0o 點 nu）與阿碼科技的Wayne，之前針對此事鍵做了一些研究，並在前一篇post「大規模網頁綁架轉址：威脅未解除，但專家都猜錯了」中，依據我們錄到的封包，詳述了我們對事件的看法。我們不覺得此事與DNS有關係，也沒有證據顯示此次與zxarps工具的ARP掛馬手法有關。從我們錄到的封包來看，這是典型的，從90年代一直用到現在的IP spoofing。
這兩天，經過一些研究與測試，我們可以在route上準確的指出攻擊程式的所在位子，昨天也已經充分通知相關單位，今天在這裡把結果與各位分享，另外也謝謝Peter Yen與其他朋友提供的寶貴資訊。
最 近攻擊有轉緩的趨勢，大部分大型網站的流量已經不再被轉址，但是我們這幾天觀察下來，一直到昨天（今天尚未測試），攻擊程式都還存在，只是不再針對大型網 站spoofing，而針對某些特定網站做spoofing，並且不斷更改行為，故我們認為對方正在做許多測試與校調，試圖盡量讓spoofed封包看起 來與正常流量類似，以便下次發動攻擊。我們的測試方法是利用一個小程式發送TCP封包，封包裡是HTTP GET request，而再透過TTL的設計，就可以知道當封包經過哪一個節點時，有spoofed IP packet發送回來。當然我們這種測試方法是可以被偵測到的，所以現在公開之後，預計也將增加往後類似測試的困難度。
[攻擊所在位置]
我 們從兩個端點進行測試，其中一個端點A是會被攻擊的，而另一個端點B是不會被攻擊的。這兩個端點的匯集處是211.22.33.225這個路由器，而我們 同時在兩端點跑測試程式，對目前仍會遭受攻擊的網域送GET封包。測試結果，端點B不會收到spoofed封包，而端點A則每當封包經過第六個節點 210.65.255.241（也就是連到211.22.33.225的前一個節點）時，我們就會收到spoofed封包。我們因此可以肯定，在 210.65.255.241這個分支中，有攻擊程式。由於資源有限，我們只測試了A與B兩個分支。
（圖一）
（圖二）
[攻擊手法改變]
在我們貼出了「大規模網頁綁架轉址：威脅未解除，但專家都猜錯了」一篇後，立刻觀察到對方在攻擊手法上不斷調整，我們做紀錄於下：
1. id已經不像之前我們觀察到的，固定在0x0100，開始隨機了。其實我們之前沒有明講，但是相信許多網管人員一看到我們的post，就了解到了，裡頭的資訊可以直接用來設定IDS/IPS/Firewall，有效阻擋攻擊吧？像是id固定是0x0100、或FIN與payload同時存在等，可惜我們每次一公開，對方也會跟著改變。下圖錄於三月11日10:30am，第五個封包是spoofed，第六個是正牌的封包：
（圖三）
2. 已經不再是一個封包完成攻擊了。一 個封包同時設FIN與帶payload，是很大的特徵，很容易被IDS/IPS/firewall抓到，故這幾天錄到的流量中，對方不斷改變方式，已經不 再採此手法了。但是也並不是一次發兩個封包，一個payload一個FIN，而是還是只發一個，而讓正牌的FIN來結束連線。這樣的作法，每個攻擊仍然只 有一個spoofed封包（payload），比較俐落，但是由於沒有立刻結束連線（不帶FIN），故根據各作業系統TCP/IP stack實做之不同，可能造成假封包與正封包內容被系統合而為一，因此payload需要特別設計，以免轉址失敗而瀏覽器出現亂碼。我們測試時，對方正 不斷調整payload的設計。上圖中，第五個封包的FIN沒有設了，第六個是正牌repy，第七個則是正牌網站送出的FIN。
3. 開始轉向確定有惡意程式的網址。之 前雖然轉址網域過去都有許多不良紀錄，但是就這次攻擊事件的範圍，之前沒有看到確實具有攻擊力的惡意程式存在於這些網址中。然而如上圖又下方所示，最新的 攻擊中，所轉址的其中一個網址：hxxp://61.218.245.190/_vti_access/index.htm，確定含有四支具有攻擊性，可 觸發之攻擊程式（以下為免費網站惡意程式監控服務HackAlert畫面）：
（圖四）
4. 開始想辦法隱藏攻擊。見下圖，錄於三月11日10:30am。 下圖中，第51封包是spoofed，我們看右下角的payload，這會讓瀏覽器載入一個隱形的iframe（目前是google），而過了四秒後，瀏 覽器會reload。由於沒有轉向，這會讓受害者只覺得等了比較久，但是正確網頁最後還是會載入，故不容易發現蹊蹺，而到時候把iframe改成指向惡意 網頁而非google，這四秒足夠惡意程式攻擊受害者電腦成功，植入木馬了。
（圖五）
5. 同一個被感染的網段，可能有不只一個的攻擊程式。圖 五中，第51封包是spoofed，id=0x0100，ttl=115，payload是隱藏的google iframe，並在四秒後重新載入原網站的內容。第54個封包也是spoofed，id=0xccbb，ttl=113，內容是直接轉向到惡意網址。正牌 的回應封包則是第56與58。這很可能是兩組不同人馬所植入之不同攻擊程式，也有可能是同一組人在測試不同版本時忘記把其中一個版本關閉。
（圖六）
6. 攻擊之工具是否是zxarps的改版延伸？這我們一開始就測試過了，然zarpx可實際做man-in-the-middle竄改封包而這次並沒有，另外封包特徵差異非常大（ttl/id/service filed/行為等），故我們覺得應該使用了其他的攻擊程式。
[結論]
針對我們錄到的資料，我們可以做出以下結論：
1. 至少可以測出攻擊程式仍位於210.65.255.241這個節點。另外可以確定並非網站本身受感染。
2. 對方目前不斷測試不同攻擊方式並使得此攻擊完美化，明顯為下一波攻擊鋪路。
3. 在初次很粗糙的測試中，對方可以造成大量轉址，但行為明顯，使用者很容易察覺。在新一波觀察到的手法中，對方一直致力調整成使用者無法察覺之方式。
4. 對方針對我們公布的特徵進行改良，欲使IDS/IPS/firewall無法輕易認出假造的封包。
5. 在小量的測試中，已經含有具有攻擊性並能攻擊成功的惡意網頁。
6. 由於是基礎架構問題，一般使用者無能為力，只能盡量使用https，等待基礎架構修復。
7. 有問題的網段可以檢查路由器與路由器相通的他機器是否遭侵入或竄改設定。
貌似是大陆的朋友做的
很强大