2016年12月7日 星期三

[隨筆] Java Web 漏洞生態食物鏈


本來這篇文章叫做 HITCON CTF 2016 初賽出題小記的,可是擺著擺著就兩個月過去惹~
轉來寫寫跟 Java 有關的東西XD



關於序:


今年五六月的時候,看到某個曾經很多人用但快停止維護的 Java Web Framework 弱點的修補方式感覺還有戲所以開始追一下原始碼挖 0-Day,順便整理一下 Java Web 相關弱點 — 😊覺得有趣。

通常自己在外面演講時對於 Web Security 的分類中大致可分為三個世界:

  • File-Based 的世界,一個檔案對應一個入口點如經典的 ASP, PHP, ASPX 等
  • Route-Based 的世界,一個路徑對應一組函數(功能)如經典的 Rails, NodeJS, Django 等
  • Java 的世界,Java 的世界極其複雜自成一格獨立討論

當然三種分類並不是獨立開來,如常見 PHP MVC 用 Rewrite 將 File-Based 偽裝成 Route-Based 的還是有可能有 File Based 的特性,Java 世界中還是可能出現 File-Based / Route-Based 常見問題等等等

Java 可以獨樹一格自成一圈自然有它的道理在! Java Web 相關攻擊手法一直以來都是撲朔迷離,生態複雜出過的弱點又多(想想 Struts2 :P),偶爾爆出一個很嚴重的漏洞才又開始有人關注,也很難有一個脈絡所以一直以來都沒有看到有個很好的整理! (當然國外還是有一些在這個領域耕耘已久的研究人員如 @pwntester @meder @gebl @frohoff @空虛浪子心 等等等)

這也促使我在這下半年開始來好好研讀一下關於 Java Web 的生態以及弱點漏洞的整理。

從 2013 年開始接觸 CTF 到現在,在 Web 分類中所看到關於 Java 的題目真的少之又少,最常見的通常是 PHP、其次 Python、偶爾來點 Ruby / JavaScript / Go 等等...

雖然 PHP 最大宗很合理(現實網站常見、新手容易入門、語法特性容易寫出問題),不過身為穩定度高,在大型網站、銀行、政府網站常見的 Java 幾乎沒有就很不合理了。

最後是,PHP 的梗幾乎都被玩完了,除了老梗外幾乎都是基於 PHP 核心問題的特性,該是換點新梗的時候!



關於 Java:


Java Web 的生態各種複雜,從最底層的 JVM 到 Web Container 到上層的 Web Framework,在 Java 的世界中就像是一種原料什麼都可以靠它堆塑起來,而不像以往的 PHP 只須要顧好應用層就好! 再加上在 Java 生態中很喜歡引用來、引用去,串來串去的結果則是當底層函示庫出包後,上方所有應用會跟著一起受害,舉個 JBoss Admin Console 這個應用來當例子的話則是:

JBoss Admin Console 使用 Seam Framework 這個框架所開發的網頁應用,而 Seam Framework 使用了 JSF(Java Server Faces) 的架構,Java Server Faces 為一個 Java EE 的標準,基於這個標準上的實作較知名的共有兩套
  • Apache 所實作的 MyFaces
  • Oracle 所實作的 Mojarra

而為了讓 JSF 實作更為好用又在其上引申出了一些方便 JSF 使用的 Framework 如 Richfaces
而 Seam 則是使用基於 Richfaces 上的實作,所以整個生態鏈為
  • JVM -> JBoss -> Mojarra -> Richfaces -> Seam Framework -> JBoss Admin Console

整個生態鏈串來串去只要其中一個出現漏洞則最上層的應用皆會有問題

如:
  • CVE-2010-4476,JVM 浮點數解析 DoS 漏洞,只要以上處裡的過程中出現類似 Double.parseDouble("2.2250738585072012e-308") 的狀況就可以達成 DoS 效果
  • Web Container / Application Server 弱點,這個不細數,JBoss, Tomcat, GlassFish, Weblogic 或是 Websphere 都出過很多洞XD
  • JSF 實作漏洞,可以看下面舉的例子
  • Framework 本身漏洞,如 CVE-2010-1871 - Seam EL注入漏洞導致遠端代碼執行
  • 網頁應用開發者本身自己寫出來的洞

舉個🌰:

在研究 Java 網頁應用弱點的時候發現到了 CVE-2010-1871 這個好玩的東西
漏洞詳情可參閱 《JBoss Seam Framework remote code execution

雖然 Seam Framework 已經是過時的產品了不過身為弱點研究人員感興趣的是漏洞的成因跟如何修補,在研究漏洞如何修補的同時順便對 Seam Framework 的原始碼審查一下,發現在 Seam Framework 2 的這個分支中最新的版本為 2.3.1.Final,在前文有提到,Seam 所使用的是基於 Mojarra 實作的 Richfaces,這代表只要 Mojarra 或是 Richfaces 有弱點,則可影響到所有使用 Seam2 所撰寫的應用程式。

再仔細觀察一下 Seam 2 所使用到的函示庫
  • lib/richfaces-core-impl.jar - 根據 MANIFEST 內容顯示版本為 Richfaces 4.3.3.Final
  • lib/jsf-impl.jar - 根據 MANIFEST 內容顯示版本為 Mojarra 2.1.7

最新版本的 Seam 2 使用的居然不是最新版本的第三方函示庫! 透過尋找上面兩個函示庫出現過的漏洞會發現在 2013 年出現的 CVE-2013-3827
詳情可參考《Two Path Traversal Defects in Oracle's JSF2 Implementation

所以基於 CVE-2013-3827 上,將原本的 PoC 修改一下就可以完美的重現在最新版本的 Seam Framework 2 上面。

上面這個例子只能做到讀取敏感檔案,接下來再一個遠端代碼執行的例子:
同樣也是使用到舊版本 Richfaces 的 CVE-2013-2165,開發者根本不會知道多了一個 /a4j/ 的 url-pattern,漏洞會從 url 中直接將參數代入 readObject 執行,剛好可以搭上最近很夯的 Java Deserialization 風潮達成遠端代碼執行!

關於這樣應用建立在前面的基石,當基石出問題時整個倒下來的情形在 Java 世界中並不少見,最近很夯的 Java Deserialization  相關問題也有類似這樣的生態鏈,還不覺得 Java 的世界很有趣嗎? XD

好惹,差不多降!
這只是個隨筆就先富堅,有空的話再多寫一點好惹



小結:


由於生態完整並要注重系統穩定,大部分使用 Java 當成網站開發的都是些大型網站或注重穩定性的網站如金融業或是政府機構,並且為求穩定通常不會頻繁的更新系統,所以在複雜的架構交疊下如攻擊者沒有一定程度的研究的話很難發現用了什麼框架會有什麼漏洞,因此有時很容易出現那種明明被被很多人檢視過但還是沒被挖出來的漏洞!

如在研究時順便觀察到 Apple 的網站有使用 Mojarra 的特徵,2013 年的漏洞丟下去居然還可以用 Java Web Framework 相關的漏洞真的滿邊緣人的XDD
  • https://???.apple.com/???/javax.faces.resource.../WEB-INF/web.xml.jsf

出來混遲早要還的,不然技術債會越累積越多,接下來有空的話應該會嘗試檢視 Spring Framework Source Code,畢竟也是現在的主流!
至於 S 什麼什麼 T 什麼什麼 2 的就不用多講了XD



題外話 1:


題外話是,在 Review 完 Seam Framework 後回報了幾個漏洞給 security@jboss.org ,不過回覆則說因為 Seam 只能在 JBoss EAP 7 下使用,而 JBoss EAP 也即將在 2016/11 月停止維護,所以除了重要或是嚴重風險的漏洞外皆不修復。

所以你知道的,現在用 Seam 寫的網頁都可以
嗯,真棒XD



題外話 2:


Apple 敏感檔案存取的漏洞是新訓進去前發現的,出來要回報時就發現不能用不知道是修掉還怎樣QQ
本來想直接公開不過還是在發佈文章前最後一秒把關鍵字碼掉惹

2016年10月13日 星期四

Collection of CTF Web Challenges I made


把出過的 CTF Web 題都整理上 GitHub 惹,包括原始碼、解法、所用到技術、散落在外的 Write ups 等等

This is the repository of CTF Web challenges I made. It contains challs's source code, solution, write ups and some idea explanation.



2016年7月23日 星期六

HITCON 2016 投影片 - Bug Bounty 獎金獵人甘苦談 那些年我回報過的漏洞


This is my talk about being a Bug Bounty Hunter at HITCON Community 2016

It shared some of my views on finding bugs and some case studies, such as
  • Facebook Remote Code Execution... more details
  • Uber Remote Code Execution... more details
  • developer.apple.com Remote Code Execution
  • abs.apple.com Remote Code Execution
  • b.login.yahoo.com Remote Code Execution... more details
  • eBay SQL Injection
  • www.google.com XSS
  • Apple XSS
  • Facebook Onavo XSS
  • Uber XSS

Sorry for it's only in Chinese. Wishing you would like it.

-----

很榮幸成為 HITCON 2016 CMT 的 Keynote,下面是這次演講的投影片跟介紹XD

分享當個獎金獵人在參加各大廠商 Bug Bounty 計畫與尋找漏洞上的心得談, 以及那些回報中那些成功或被拒絕的案例與漏洞細節!

廠商包括 Google, Facebook, Apple, Yahoo, Uber 及 eBay,弱點則從 Remote Code Execution, SQL Injection, Logical Flaws 到特殊姿勢的 XSS 不等。

一起來看看大公司會有什麼樣的漏洞吧!




2016年4月7日 星期四

[Bug Bounty] Uber 遠端代碼執行- Uber.com Remote Code Execution via Flask Jinja2 Template Injection




好久沒 po 文了XD

幾天前,Uber 公佈了 Bug Bounty 計畫,從  Hackerone 上看到獎金不低,最少的 XSS / CSRF 都有 3000 美金起就跳下來看一下有什麼好玩的XD

從官方公佈的技術細節發現 Uber 主要網站是以 Python Flask 以及 NodeJS 為架構,所以在尋找漏洞的時候自然會比較偏以測試這兩種 Framework 的漏洞為主!

Uber 網站在進行一些動作如修改電話、姓名時,會以寄信及簡訊的方式告知使用者帳號進行了變更,在某次動作後發現 Uber 寄過來的信如下圖,怎麼名字會多個 "2" XDDDD



往前追查原因才發現進入點是在 Riders.uber.com,Riders.uber.com 為修改個人資料以及顯示帳單、行程行程的地方,在修改的姓名中,使用了

{{ 1+1 }}

這個 payload 導致的,漏洞大概成因是 Python Flask 中預設使用的模板引擎是 Jinja2,在 Jinja2 中可使用些許的 Python 語法來幫助產生 HTML (當然有 Sandbox)

所以 {{ 1+1 }} 就被 Python 解析成 2 並且放置信件中寄到我的信箱,更詳細的內容可參考由 PortSwigger (BurpSuite 開發人員) 在 BlackHat 2015 發表的  Server-Side Template Injection:RCE for the modern webapp

所以現在我可以使用 Jinja2 的語法有限度的在姓名欄位寫 Python 程式碼了! 如在姓名欄位依照 Jinja2 語法填入

{% for c in [1,2,3] %}{{ c,c,c }}{% endfor %}

利用模板引擎叫 Uber 伺服器幫我們跑個 FOR 迴圈,結果還會寄到你信箱XD






成功執行 FOR 迴圈! 不過在文章前面有提到,可以執行 Python Code 但並不是無限制,Jinja2 中有 Sandbox 來對危險的用法、函數進行防護。

不過這個對常玩 CTF 的人絕對不是問題,在各個比賽中很常出現 Python 的 Sandbox 繞過用到的手法可以直接拿來這裡用!

詳細技術細節可以參考
Exploring SSTI in Flask/Jinja2, Part2
利用 Python 特性在 Jinja2 模板中執行任意代碼

如使用

{{ [].__class__.__base__.__subclasses__() }}

可列出所有引用的模組, 如



會顯示是空的是因為被 HTML < > 包起來了,檢視原始信件就可以看到了XD

額外一提的是在引用模組中看到 Celery,因此可以猜測網站大致架構應該是:

從 Riders.uber.com 這個進入點修改姓名後存進資料庫

不過為了寄送簡訊以及信件等耗時的工作,使用 Asynchronous Task 機制交給後方的 Worker

而當 Worker 再從資料庫抓出姓名產生模板時使用串接的方式直接將模板產生所以導致了這次遠端代碼執行 :P

寫到這,最後廢言一下,對我來說,其實玩 Bug Bounty 獎金什麼都是額外的,最主要的是可以找出別人找不出、別人發現不了的漏洞,回報並且讓別人也認同你的發現,這其中得到的成就感才是最爽的XD