渗透测试 | 内网Mysql代理浅析

文章来源：先知社区

0x00 使用场景

0x01 原理

Socket-reuse shellcode is used to bypass firewalls. Usually, shellcode and exploit developers and users provide "bindshell" and "connect-back" shellcodes. Both of these require a permissive firewall to some extent or another. However, because sockets are treated as re-usable or dynamic file descriptors by most operating systems, it is possible to examine existing socket connections, therefore one can simply bind a shell to the socket that the exploit shellcode came from.

0x02 踩坑过程

来看下关键代码逻辑，先看攻击端，首先连接Mysql数据库，然后进入proxy_init函数，传参是3，其实就是我们连接数据库的那个socket的fd，012是标准输入输出那些

执行已经加载好的UDF函数，并读取服务端返回的一个特定字符串，确定服务端代码已经执行，跳出循环，select_fd[0]即数据库链接fd

在本地监听任意可用的端口，这里用了1337,select_fd[1]是我们用proxychains连接时产生的fd

感觉没什么问题，因为客户端的代码是可以跑起来的，也能成功执行服务端的函数，执行proxychains ssh [email protected]，抓个包验证一下(不熟悉socks5的师傅可以看看这个)，客户端先发送了05 01 00，05是版本号，01是支持的认证方式总数，后面就是认证方式，00即NOAUTH

服务端返回05 00，同样05是版本号，00是服务端选择的认证方式

至此认证是已经完成了的，然后就是客户端发送命令05 01 00 01 7f 00 00 01 00 16，各字节含义如下：

• 05 版本号
• 01 CONNECT命令
• 00 保留字段
• 01 地址类型为IPv4
• 7f 00 00 01 IP地址127.0.0.1
• 00 16 端口号22

客户端执行select do_carracha('a');之后，服务端用getpeername遍历所有fd，通过ip匹配上我们的连接，并fork出一个子进程，执行payload

最终子进程执行了worker函数，fd就是客户端的数据库连接，红框中的socks5_invitation和socks5_auth分别对应了客户端发的05 01 00和服务端发的05 00

所以为什么socks5_command这里出了问题？原来的代码读了05 01 00 01 7f 00 00 01 00 16的前4个字节

然后判断第4个字节是否01，但是判断socks命令类型不应该是判断第2个字节吗......虽然结果是一样的，这里就假设是对的

最后发现是command前面多了一个00......所以是socks5_invitation这里读少了一个字节，擦，那作者是怎么跑成功的......

所以就把上面那里读少的字节读完，就可以跑了，启动代理

成功连接

联系/合作/投稿邮箱：[email protected]

你点的每个赞，我都认真当成了喜欢