第8页
Win32平台的具体实现
– 3.3 getpeername查找socket
客户端在发送攻击串之前用getsockname函数获得套接字本地 信息,把相应信息写入shellcode. 服务端shellcode从1开始递增查找socket,并且用 getpeername函数获得套接字远程信息. 如果两个信息相符就认为找到socket,跳出递增循环,并且把 shell绑定在这个socket上. 有很大局限性,如果客户端在NAT网络环境里,客户端 getsockname取得的套接字信息和服务端getpeername取得的 套接字信息不一定相符,导致查找socket失败.
第9页
Win32平台的具体实现
– 3.4 字串匹配查找socket
客户端在发送完攻击数据包后,再发送几个字节的字符串,在 服务端的shellcode对一个递增的socket值接收相应字节的字符 串,然后匹配是否是当前连接的socket.这种方法避免了 getpeername在NAT网络环境里的限制. 多线程环境下容易处理到处于accept下的socket,一般的网络 函数都会进入等待状态,直到有连接建立. flier提到WaitForSingleObjectEx处理这种处于accept的socket 会返回WAIT_TIMEOUT,可用的句柄返回 WAIT_OBJECT_0.
第10页
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).
第11页
Win32平台的具体实现
– 3.5 Hook系统的recv调用
用VirtualProtect设置真实recv函数地址开始的5个字节为可 写. 把真实recv开始的指令改为跳转到新recv函数. 在新的recv函数里先把这5个字节指令改回去. 调用真实recv来执行系统本来的操作. 再把真实recv函数地址开始的5个字节改为跳转新recv的指 令. 比较接收的数据是否是约定字串,如果是就绑定一个 cmd.exe,否则跳到压栈的返回地址,继续系统原来的流程. 这种方法能绕过rpc之类机制,也能够搜索再次连接的 socket.
第12页
Win32平台的具体实现
– 3.6 文件上传下载功能的实现
必须要客户端和shellcode做紧密配合. 上传文件需要客户端打开并读取文件发送给服务端,服务端的 shellcode创建并写入该文件. 下载文件需要服务端的shellcode打开读取文件发送给客户 端,客户端创建并写入该文件. 由于是非阻塞的连接,上传文件的时候,服务端的shellcode 必须判断socket里是否还有数据可接收,如果没有就关闭句 柄,执行后续流程.下载文件的时候,客户端必须判断socket 里是否还有数据. select和ioctlsocket都可以实现这个功能.select的汇编实现相 对复杂,ioctlsocket需要在发送缓冲块大于接收缓冲块的情况 下使用.
第13页
Win32平台的具体实现
– 3.6 文件上传下载功能的实现
客户端和服务端shellcode可以使用一个约定的key对传输的数 据做xor操作,由于用管道绑定cmd,那么交互的命令也是编 码的,进一步增强隐蔽性,躲避IDS的检测.
第14页
Linux x86平台的具体实现
4. Linux x86平台的具体实现
– 4.1 fcntl设置socket状态
scz最早使用这种方法,基本思路如下:
while (1) { i++; oldflags = fcntl(i, F_GETFL, 0); fcntl(i, F_SETFL, oldflags | O_NONBLOCK); read(i, buf, 4); fcntl( i, F_SETFL, oldflags ); if (buf == 'Xc0n') goto shell; }

上一页下一页