鑽石舞台

作者：斯文

來源：https://www.svenbeast.com

0x01 描述

實戰中遇到了2次這種繞過場景，第一次並沒在意，以為可能是對面的waf或者部署方面有一定的問題，然後第二次也是同樣方法，遂記錄一下

0x02 第一次

1】是一次攻防演練中，一些掃描無果後，手工去排查一些網站，在排查到weblogic資產的時候，發現目標會在識別到一些敏感路徑時回包reset，感覺有戲，因為(個人看法)存在這種waf，部分甲方本地自己人或者請乙方安全公司去進行安全測試時，如果在發現waf後，因為一些部門可能並不相通不好找人加白或者奇怪的心理(還要加白？是不是你們能力不行？)，很少會獲得waf白名單的權利，而對waf開啟狀態的目標網站進行測試時，測試人員其實並不會去深究waf的繞過這些，最後獲得結果就是: 漏洞存在，但測試結果是沒有這個漏洞，獲得網站安全的表面現象。

2】廢話一籮筐湊字數別介意，然後就各種想辦法，無果後，理了一下這個waf的攔截邏輯是：訪問的url路徑中存在歷史漏洞中出現的漏洞利用路徑就會重置鏈接，不針對weblogic，隨便的利用鏈接像.svn這種也會攔，也就是說他是所有漏洞的利用url的黑名單，訪問路徑在黑名單內即重置鏈接。

3】求助了沒什麼好辦法，想到sql注入有的場景是垃圾填充這些辦法嘛，然後試着構造了超大的cookie包，大概是服務器本身就會拒絕鏈接的那種長度再短一點，發包後，哈哈，還是拒絕鏈接，不過他拒絕的比較慢，又想了一會，我想着再暴力一點，寫了個多進程python腳本，附上weblogic漏洞利用的請求包帶超大cookie的，然後100進程開啟，過了10分鐘收到了狀態碼200的回顯，至此waf就過了

4】不過後面也很麻煩，負載均衡什麼的，哈哈，設備多還是強的，後來演練結束後我去了解了一下目標的waf產品，是某明的天清xxx，當時覺得2種原因:可能是目標部署位置有問題導致有漏包，也可能是waf本身的一些設計問題或者版本不是最新，並沒認為以後還會碰到這種繞過案例。

0x03 第二次

第一天

然後過了xx時間後，是幫朋友的一次不知道啥行動中，發現目標存在nc，bsh.servlet.BshServlet那個頁面，那不直接就shell了，結果發現waf，邏輯是post包中存在bsh.script=，就無法訪問，雖然bp上不是直接顯示reset，但是差不多，也是個白頁面那種，繞了會也沒繞過去，也是構造了個大包去跑，大包啥格式忘了，然後跑了10來分鐘也沒結果就關了

第二天

第一天收集了了一些資產，因為目標不少，就想着慢慢來，然後還是對那個nc不死心，去查了一下IBM的httpserver怎麼解析http包，得知是提交多個相同還是不相同無法解析的參數時，最後一個參數是結果，具體並沒理解，我只確認一件事是最後一個參數是漏洞參數就行了，然後弄個cookie大包，漏洞參數前放了其他的超大參數後120進程開跑，然後就去看其他資產了

過了不知道多長時間，只記得按小時計算，期間隔一段時間就看看發包結果，一直跑，最後下午6點左右吧，發現了有200回包，心中甚是歡喜，然後改成執行命令的post包，繼續跑，然後幾分鐘很快就跑出來了，root權限，然後給朋友要了服務器ip，彈了shell。

0x04 總結

廢話一堆，描述了一下心理活動，就是貧，有的時候吧，用一些時間做成了

什麼事情的時候很開心，很希望有個人可以分享，然後能一起開心。

1.cookie和提交參數垃圾填充+多線程疑似通用辦法

2.個別服務器配置或者waf產品配置過高，需要一些時間才能生效

3.構造的包別影響最終解析

侵權請私聊公眾號刪文

歡迎關注LemonSec

覺得不錯點個「贊」、「在看」哦