基于某厂安全设备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流中数据交互的流量包。

因为这里只显示数据块部分的数据,那么这里可以看到，同样文件上传的时候内容是分块传输的

分作了四个数据块进行传输。

安全设备流量监控下的预警以及触发条件是基于全流量还是部分流量以及规则条件产生的，规则库基于POC以及EXP,但是可能不会考虑到是否有完整的利用链，这可能是现在为什么存在那么多wu用告警的原因。