關於序

今年五六月的時候，看到某個曾經很多人用但快停止維護的 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

• 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注入漏洞導致遠端代碼執行
• 網頁應用開發者本身自己寫出來的洞

舉個🌰:

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

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

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

小結

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

如在研究時順便觀察到 Apple 的網站有使用 Mojarra 的特徵，2013 年的漏洞丟下去居然還可以用 Java Web Framework 相關的漏洞真的滿邊緣人的XDD

PoC:

https://???.apple.com/???/javax.faces.resource…/WEB-INF/web.xml.jsf

題外話 1

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

題外話 2