复用当前连接技术介绍
2. 复用当前连接技术的一些问题及优势
2.1 绑定shell
Unix下可以直接把SOCKET作为“/bin/sh”的输入输出句柄。
在Win32下，socket()函数隐式指定了重叠标志，它创建的
SOCKET是重叠套接字(overlapped socket)，不能直接将
cmd.exe的stdin、stdout、stderr转向到套接字上，只能用管道
(pipe)来与cmd.exe进程传输数据。winsock推荐使用重叠套接
字，所以实际使用尽可能用管道。
WSASocket()创建的SOCKET默认是非重叠套接字，可以直接
将cmd.exe的stdin、stdout、stderr转向到套接字上。
复用当前连接技术介绍
2.2 多线程环境搜索SOCKET
-=-=-=-=-=- start sample code =-=-=-=-=-=-=
s = WSASocket(2,1,...)
bind(s,..)
listen(s,...)
s2 = accept(s,....)
-=-=-=-=-=- end sample code =-=-=-=-=-=-
当s处于accept状态时，任何对s操作的网络函数都会处于等待
状态，直到有连接建立。
先用WaitForSingleObjectEx处理句柄，当s处于accept状态时
会返回WAIT_TIMEOUT，可用的句柄返回
WAIT_OBJECT_0。然后再用ioctlsocket/recv处理判断是否当
前连接的socket。
复用当前连接技术介绍
2.3 优势
复用当前连接的技术相对较隐蔽，而且对于Win32的用管道绑
定cmd.exe后，和服务器交互的数据可以用xor的办法进行编
码，进一步躲避IDS的检测。
单单查找SOCKET的shellcode可以写的相对比较短，在找到
SOCKET后，可以再继续接收一段功能更复杂的shellcode到
缓冲区，然后跳入执行。对于该后续shellcode就没有任何字
符和长度的限制。
甚至接收一个dll文件，实现更复杂的功能。
Win32平台的具体实现
3. Win32平台的具体实现
3.1 端口复用具体实现
端口复用shellcode要求服务重新绑定在0.0.0.0地址，而且不
能使用SO_EXCLUSIVEADDRUSE选项。
客户端攻击的时候需要把服务端的具体IP和端口写入shellcode
里面。
Shellcode里执行：
setsockopt(s, 0xFFFF, 4, &d, 4);
bind(s, &sockaddr, 0x10);
用netstat -na在服务端查看可以看到同一个端口有0.0.0.0和具
体IP两个绑定着。
如果服务端在NAT环境里，可能会存在问题。
Win32平台的具体实现
3.2 重新绑定原端口的实现
CreateProcess()创建一个suspend模式的进程。
GetThreadContext()来获得该线程的上下文结构和寄存器信
息。
用VirtualAllocEx()在该进程里分配内存。
把shellcode指令用WriteProcessMemory()来写入该进程刚才
分配的空间。
SetThreadContext()把GetThreadContext()获得的EIP修改指
向VirtualAllocEx()分配的内存地址。
ResumeThread()恢复suspend模式的进程。
TerminateProcess(-1, 0)终止当前进程。
循环绑定原来端口。
Win32平台的具体实现
3.3 getpeername查找socket
客户端在发送攻击串之前用getsockname函数获得套接字本地
信息，把相应信息写入shellcode。
服务端shellcode从1开始递增查找socket，并且用
getpeername函数获得套接字远程信息。
如果两个信息相符就认为找到socket，跳出递增循环，并且把
shell绑定在这个socket上。
有很大局限性，如果客户端在NAT网络环境里，客户端
getsockname取得的套接字信息和服务端getpeername取得的
套接字信息不一定相符，导致查找socket失败。
Win32平台的具体实现
3.4 字串匹配查找socket
客户端在发送完攻击数据包后，再发送几个字节的字符串，在
服务端的shellcode对一个递增的socket值接收相应字节的字符
串，然后匹配是否是当前连接的socket。这种方法避免了
getpeername在NAT网络环境里的限制。
多线程环境下容易处理到处于accept下的socket，一般的网络
函数都会进入等待状态，直到有连接建立。
flier提到WaitForSingleObjectEx处理这种处于accept的socket
会返回WAIT_TIMEOUT，可用的句柄返回
WAIT_OBJECT_0。
Win32平台的具体实现
3.4 字串匹配查找socket
查找流程如下：
while (1)
{
i++;
ret = WaitForSingleObjectEx(i, 10, 1);
if (ret != 0) continue;
ret = ioctlsocket(i, FIONREAD, &ul);
if (ul != 4) continue;
recv(i, buff, 4, 0);
if( *(DWORD *)buff == 'Xc0n') goto shell;
}
bkbll测试发现socket()函数创建的句柄在accept用户后有
getsockname操作，那么后续WaitForSingleObjectEx返回
WAIT_TIMEOUT (0x102)。
Win32平台的具体实现
3.5 Hook系统的recv调用
用VirtualProtect设置真实recv函数地址开始的5个字节为可
写。
把真实recv开始的指令改为跳转到新recv函数。
在新的recv函数里先把这5个字节指令改回去。
调用真实recv来执行系统本来的操作。
再把真实recv函数地址开始的5个字节改为跳转新recv的指
令。
比较接收的数据是否是约定字串，如果是就绑定一个
cmd.exe，否则跳到压栈的返回地址，继续系统原来的流程。
这种方法能绕过rpc之类机制，也能够搜索再次连接的
socket。
Win32平台的具体实现
3.6 文件上传下载功能的实现
必须要客户端和shellcode做紧密配合。
上传文件需要客户端打开并读取文件发送给服务端，服务端的
shellcode创建并写入该文件。
下载文件需要服务端的shellcode打开读取文件发送给客户
端，客户端创建并写入该文件。
由于是非阻塞的连接，上传文件的时候，服务端的shellcode
必须判断socket里是否还有数据可接收，如果没有就关闭句
柄，执行后续流程。下载文件的时候，客户端必须判断socket
里是否还有数据。
select和ioctlsocket都可以实现这个功能。select的汇编实现相
对复杂，ioctlsocket需要在发送缓冲块大于接收缓冲块的情况
下使用。
Win32平台的具体实现
3.6 文件上传下载功能的实现
客户端和服务端shellcode可以使用一个约定的key对传输的数
据做xor操作，由于用管道绑定cmd，那么交互的命令也是编
码的，进一步增强隐蔽性，躲避IDS的检测。
|
