基于某商產品WeblogicT3反序列化告警流量分析
前言
護網時平時遇到的針對weblogic等中間件漏洞利用以及漏洞掃描的很多，但是我看到某態勢的流量的時候發現態勢的探針的監測不單單是基于披露的poc或者exp來產生的告警。
這里一萬多條告警。
環境搭建
這里我使vulhub復現幾個cve來分析流量，這里的目的主要是對比wireshark、科*分析軟件和某商安全設備的全流量的數據包告警分析。
cd CVE-2020-14882 docker-compose up -d
docker ps
http://192.168.166.130:7001/console/login/LoginForm.jsp
分析
直接使用wireshark抓包是無法抓取不到數據包的，原因是nat模式下不走網卡，所以這里涉及到了tips就是添加路由
route add 192.168.166.130 mask 255.255.255.255 192.168.0.1
用完刪除
route delete 192.168.166.130 mask 255.255.255.255 192.168.0.1
但是此時似乎是沒有用的，因為我們在進行漏洞利s用的時候走的是http協議，傳輸層走的是tcp但是依舊是無法看到詳細的流量數據。
設置虛擬機為橋接模式，再次嘗試獲取流量
已成功獲取到數據流量。使用命令查看對目標攻擊的所有流量
ip.addr==192.168.0.120
追蹤一下tcp流
直接追蹤t3流量，因為weblogic使用的協議為T3,當然態勢內的漏洞監測也是基于t3協議來告警觸發的。
上面兩部分的內容是客戶端和服務端的信息
t3 7.0.0.0 AS:10 HL:19 HELO:12.2.1.3.false AS:2048 HL:19 MS:10000000 PN:DOMAIN
在使用paylaod的時候會給服務端發送請求，正常情況下我們能夠找到的poc或者說exp的工作原理大部分都是基于版本來校驗的
當然這里的環境版本為12.2.1.3.0
這里根據不通的流可以看出來。這一點兒的話其實可以根據python腳本的內容也能看出來校驗機制，這一點兒跟很多廠商的漏掃的原理應該是一致的。
這里我執行了幾條命令，來查看一下流量特征
whoami
ls
pwd
上傳的shell.jsp文件做編碼
序列化的部分就是在這一部分完成的
回頭看一下某報警日志的流量
這里觸發規則庫的內容是由于探針監測到流量中存在序列化的操作就直接觸發了，所以這個時候正常的日志也是會觸發漏洞預警。
可能使用wireshark對tcp的交互看著不太清晰，使用科*網絡分析
重新抓包
這是所有的攻擊日志
可以看到tcp流中數據交互的流量包。
因為這里只顯示數據塊部分的數據,那么這里可以看到，同樣文件上傳的時候內容是分塊傳輸的
分作了四個數據塊進行傳輸。
安全設備的告警
上面是tcp部分流量
請求體內容
那么告警行為的觸發已經不是基于weblogic正常利用時的流量了，此時只是在tcp的傳輸階段就已經拒絕連接了。
思考
安全設備流量監控下的預警以及觸發條件是基于全流量還是部分流量以及規則條件產生的，規則庫基于POC以及EXP,但是可能不會考慮到是否有完整的利用鏈，所以用戶的體驗感就比較難受了。
