前言
護網時平時遇到的針對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
但是此時似乎是沒有用的，因為我們在進行漏洞利用的時候走的是http協議，傳輸層走的是tcp但是依舊是無法看到詳細的流量資料，
【----幫助網安學習，以下所有學習資料免費領！加vx：yj009991，備注 “博客園” 獲取！】
① 網安學習成長路徑思維導圖
② 60+網安經典常用工具包
③ 100+SRC漏洞分析報告
④ 150+網安攻防實戰技術電子書
⑤ 最權威CISSP 認證考試指南+題庫
⑥ 超1800頁CTF實戰技巧手冊
⑦ 最新網安大廠面試題合集（含答案）
⑧ APP客戶端安全檢測指南（安卓+IOS）
設定虛擬機為橋接模式，再次嘗試獲取流量
已成功獲取到資料流量，使用命令查看對目標攻擊的所有流量
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,但是可能不會考慮到是否有完整的利用鏈，所以用戶的體驗感就比較難受了，
更多靶場實驗練習、網安學習資料，請點擊這里>>
搜索
復制
合天智匯：合天網路靶場、網安實戰虛擬環境轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/498728.html
標籤：其他
上一篇：相機控制, 相機跟隨