金和OA系統(tǒng)代碼審計之挖掘0day,未公開poc
參與的眾測項目,資產非常難挖掘漏洞,所以只能通過審計的方式,找找漏洞點 資產里相對用的多的 oa,都是用友,泛微,致遠等大型 oa,對我這種小菜來說,直接上手有點難度,無意間發(fā)現(xiàn)了金和系統(tǒng),就直接來審計學學,剛開始找網盤資料,發(fā)現(xiàn)有個 net 版的源碼,結果目標系統(tǒng)是 jsp,就 G 了。 然后就找朋友要了安裝包,對源碼進行分析,跟蹤路由,審計漏洞點。 但是有一點就是sbcp是真他媽惡心,水平越權,只因 id 不易猜測,直接駁回,任意密碼重置,通過 id,可直接重置密碼,不需要驗證,也是因為 id 不易猜測。真他媽氣打不一出來 你他馬勒戈壁,回答我,你的安全是誰教的,這他媽不是漏洞嗎,look in my eyes
路由關系尋找 開始正題,第一次審計,所以不太了解路由關系,大致看了看代碼結構,發(fā)現(xiàn)相對簡單點。
整體文件那么多,主要是關注 WEB-INF/jsp 文件夾,這是對應的視圖文件,也就是訪問 web 頁面的 jsp 文件。
我并沒有分析那些需要鑒權,那些不需要鑒權。 這個網上有個模板注入漏洞,我是根據(jù)對應的二級目錄來找的相關漏洞點,后面也是發(fā)現(xiàn)了注入,但是是Hibernate,構造半天沒讀出來數(shù)據(jù)庫名 jc6/platform/portalwb/portalwb-con-template!viewConTemplate.action 然后就是根據(jù)portalwb目錄下的文件去挖掘注入。 然后再其次就是關注后臺文件,也就是 lib 下的 jcs-xx.jar文件,這才是后端代碼。
根據(jù)上面的路徑 jc6/platform/portalwb/portalwb-con-template 就可以知道,對應的 jar 就是 jcs-platform-java-xxxxxx.jar。 HQL注入 經過我不懈的努力,在 jsp 頁面中,找到了一個參數(shù)
那如何在后段代碼,找到對應方法呢 很簡單,例如: main.action!viewConTemplate.action==main.action?方法名=viewConTemplate portalweb-datasource.jsp則是前端的文件,后端也會存在對應的路由,然后方法名則是下面的,getTemplateOpt
這里有typeFlag參數(shù),我們跟蹤getAllTemplates方法
直接對應了接口名稱,往下跟,就到了數(shù)據(jù)庫層面了
直接是拼接的 sql 語句 于是就可以構造請求方法了 jc6/platform/portalwb/dataSource/portalwb-data-source!getTemplateOpt.action?moduId=1&typeFlag=1
僅限于 or 1=1 也嘗試構造數(shù)據(jù)包讀取數(shù)據(jù)庫 SQL 注入 于是放棄對業(yè)務數(shù)據(jù)的審計,翻了翻下面的 jar 包 jcs-eform-java-1.5.0-SNAPSHOT.jar
clobfield這個接口,網上有,也是我審計之后發(fā)現(xiàn)的,不過目標系統(tǒng)存在這個接口,注入點變成了sKeyname 通過req獲取請求參數(shù),參數(shù)跟進
clobfield1 存在查詢語句
直接拼接,無過濾 構造訪問參數(shù),需要滿足key包含readClob
XXE 漏洞 想著,這幾個servlet 有兩三個接口都存在漏洞,那么剩下的是不是也存在。
post方式,創(chuàng)建SAXReader,用來讀取xml信息,全程代碼就那么多,可見未過濾任何信息 路由訪問,因為繼承HttpServlet,所以直接拼接訪問 dnslog 嘗試
然后就是讀取windows/win.ini
我感覺那么簡單的漏洞,應該是被提交了 果不其然 閱讀原文:原文鏈接 該文章在 2025/5/9 9:45:27 編輯過 |
關鍵字查詢
相關文章
正在查詢... |