通過補丁比對分析發現HPE IMC系統代碼執行漏洞
一些開發人員認為,只要程序身份驗證代碼是安全的,則其程序輸入也應該是相對沒問題的。通常,這種想法會導致一些草率隨意的代碼,一旦攻擊者在這些代碼中發現漏洞,一些後驗證性(Post-authentication)Bug就能被攻擊者利用,對軟體系統形成威脅。今天,我們要來說的就是,通過身份驗證繞過漏洞結合用戶輸入的表達式注入漏洞,形成對HP智能管理伺服器( HPE IMC)系統的遠程代碼執行。
在ZDI上有多個HP智能管理伺服器( HPE IMC)的後驗證型漏洞,它們是需要身份認證繞過方式才能利用的,然而最近,名為Steven Seeley的ZDI常客就非常厲害地提交了一個身份認證繞過漏洞ZDI-18-139,該漏洞的出現使得之前一大波HPE IMC的後驗證型漏洞立馬變得極具利用價值。該身份認證繞過漏洞的存在,根本上是由於2017年3月被發現的另一個HPE IMC漏洞ZDI-17-161(CVE-2017-5791)的未完全修復而導致的。
由於目前Steven Seeley發現的這個ZDI-18-139身份認證繞過漏洞還未完全公開技術細節,本文中,我們通過對漏洞ZDI-17-161的補丁分析,來嘗試自行發現ZDI-18-139漏洞,最後,我們會利用該繞過漏洞,結合一個獨特的表達式注入漏洞ZDI-17-663,實現對HPE IMC伺服器系統的遠程代碼執行。
補丁比對發現HPE IMC系統doFilter方法遠程繞過漏洞ZDI-17-161
在下面的web.xml文件中,HPE IMC系統使用了UrlAccessController類作為訪問控制過濾器,來限制未授權用戶對受保護URL的訪問。該訪問控制過濾器是一個開發人員經常用到的,用來實現訪問控制功能的Java組件。
以下就是HPE IMC的7.3E0504P2系統版本中,未完全修復漏洞ZDI-17-161的補丁下UrlAccessController::doFilter()方法的補丁反編譯分析片段:
在以上補丁中可發現,過濾器邏輯之前,添加了一個保護函數normalizeSyntax()用於對輸入內容的凈化審核。如果路徑中缺少「..」字元,則此函數將退出不執行任何操作。因此,我們可以讓normalizeSyntax()函數來嘗試執行一些包含「..」字元路徑的「規範化」操作,如果路徑是/imc/primepush/../這種樣子的,攻擊者就能繞過過濾器以未授權用戶身份訪問受保護的其它系統組件。事實上,這也就是ZDI-17-161漏洞的威脅所在。
從補丁信息中發現隱秘寶藏-ZDI-18-139漏洞
如果你仔細檢查ZDI-17-161補丁中新添加的函數normalizeSyntax(),不難發現,其中存在一個嚴重的身份認證繞過漏洞。在此,你先花點時間看看能否發現這個漏洞……。這個漏洞就存在於函數normalizeSyntax()的前幾行代碼中,如果攻擊者把URL路徑中的字元」..」進行編碼混淆,將會編過函數提前返回某些信息。換句話說,攻擊者可以簡單地使用形如這樣的路徑/imc/primepush/%2e%2e/去繞過補丁!
使用URL編碼混淆路徑遍歷字元之後,攻擊者只能繞過URL訪問控制器,但也能查看到某些受保護的身份驗證頁面,但至此,攻擊者可以利用ZDI-18-136來劫持管理員會話信息,或使用以下存在於HPE IMC系統中的任意表達式注入漏洞(EL injection)來實現遠程代碼執行:
ZDI-17-690 (CVE-2017-12526), ZDI-17-689 (CVE-2017-12525),
ZDI-17-688 (CVE-2017-12524), ZDI-17-687 (CVE-2017-12523),
ZDI-17-686 (CVE-2017-12522), ZDI-17-685 (CVE-2017-12521),
ZDI-17-684 (CVE-2017-12520), ZDI-17-683 (CVE-2017-12519),
ZDI-17-682 (CVE-2017-12518), ZDI-17-681 (CVE-2017-12517),
ZDI-17-680 (CVE-2017-12515), ZDI-17-679 (CVE-2017-12514),
ZDI-17-678 (CVE-2017-12513), ZDI-17-677 (CVE-2017-12512),
ZDI-17-676 (CVE-2017-12510), ZDI-17-675 (CVE-2017-12511),
ZDI-17-674 (CVE-2017-12499), ZDI-17-673 (CVE-2017-12509),
……
表達式注入漏洞(EL injection)介紹
表達式語言(Expression Language, EL)是稱為Java Server Faces (JSF)的Web應用UI框架的一部份,在此就有一個表達式語言在JSF框架下如何工作的簡單例子。而表達式語言注入漏洞(EL injection)是一個相對新的漏洞類,除了Minded Security的Stefano Di Paola和Aspect Security的Arshan Dabirsiaghi及少數分析博客提出了最初的漏洞概念之外,沒有更多網上現成的參考資料。
第一個表達式語言注入漏洞可追溯到2011年,也就是CVE-2011-2730,它涉及到了Spring框架中的一個雙向評價漏洞並可導致某些信息泄露。到了2012年,Dan Amodio在 JSP/EL 2.2 中演示了一種利用表達式注入漏洞的新技巧以實現遠程代碼執行,該技巧不需要漏洞代碼對攻擊者控制的表達式進行兩次估值(Evaluate)。
剖析表達式注入漏洞ZDI-17-663
ZDI-17-663是一個後驗證性表達式注入漏洞,該漏洞環境下,攻擊者可以利用傳遞到ictExpertDownload.xhtml的beanName參數來實現任意表達式語言執行。我們先來看看該漏洞的入口點 — 也就是路徑C:Program FilesiMCclientwebappsimcictexportictExpertDownload.xhtml中的ictExpertDownload.xhtml文件:
在上述代碼[1]標記處,導入了一個名為」http://www.huawei-3com.com/jsf/core」 的命名空間,其中包含了一些通用標籤,其中就包括imcf:beanMethod標籤,當該頁面發起請求時,標記[2]處的imcf:beanMethod就會對ictTableExportBean中的initPage方法進行調用,該操作行為也在位於C:Program FilesiMCclientwebappsimcWEB-INFimc-jsf-core.taglib.xml中的標籤庫中能有所記載:
以上代碼的標記[4]處,本質上說,並不是表達式進行估值的地方,在這裡攻擊者控制的數據可被傳遞到FacesUtils類中,實際上來講,也完成了一次表達式估值。以下是FacesUtils類的反編譯代碼:
至此,攻擊者控制的數據可被解析為一個ValueExpression並被完成最終估值,一旦目標Web伺服器運行的是系統許可權,則攻擊者構造的惡意Payload也將會以系統許可權執行。
綜合形成Metasploit利用模塊
綜上所述,綜合身份認證繞過漏洞ZDI-18-139和表達式注入漏洞ZDI-17-663,我們寫出了一個Metasploit利用模塊hp_imc_el_injection_rce.rb,經測試,該利用模塊結合cmd/windows/powershell_reverse,可在HPE iMC7.3E0504P2 系統下成功利用,具體利用方式如以下視頻所示:
https://www.youtube.com/watch?v=E8TjFWysI78
http://v.youku.com/v_show/id_XMzQxODE4OTQ5Mg==.html
總結
本文中提到的HPE IMC 信息泄露和代碼執行漏洞,側面說明了開發人員應該重視程序的輸入機制安全,即使這些輸入機制是存在於安全的身份驗證框架下,也不能說明它們就是絕對安全的。這裡也說明,後驗證性漏洞同樣能被攻擊者和滲透測試人員加以利用,形成危害。而表達式注入漏洞由於在黑盒測試前提下,很難被發現,但非常有必要通過源代碼審查來發現並排除這種漏洞。希望這類漏洞在造成一些重要影響後,能像字元串漏洞一樣可被快速消除,及時防範。
文章轉自FreeBuf.COM
※分析CVE-2018-6376–Joomla!二階SQL注入
※CrossRat遠程控制軟體的分析
TAG:聚鋒實驗室 |