溢出程序使用通道对抗防火墙

2008-02-23 07:18:06来源:互联网 阅读 ()

新老客户大回馈,云服务器低至5折

  现在很多web等应用使用了防火墙,我们自己也可能处于代理、透明网关等后面,这对于溢出等的通信造成了一个小小的麻烦。可能很多人会想到shellcode主动连接,这个如果防火墙做得好的话,不准许访问外部一样不行,即使不考虑这防火墙,而我们自己可能往往处于代理或者透明网关后面,考虑这也是一道难题。

  但我们仔细考虑考虑一下数据传输问题,就会发现实际上这一切都没有想象的那么困难,其实早已经有东西为我们扫清了道路,那就是数据通道。所以很多问题怕的就是我们没有去想,没有去理解一些东西。只要我们访问到了server,其实对于现在这些应用,中间已经建立了类似下面一样的一个通道,其实中间可能还更复杂,但对于我们的应用,都会有这么一个通道。

client <------> proxy <------> firlwall <------>server

  要运用这个通道,只要我们在server上找到了对于这个通道的读写调用就可以了。下面具体针对IIS说一说应用。IIS有两种接口,ISAPI和CGI,主要考虑这两种应用的情况下的办法。

1、ISAPI接口;IIS的server与ISAPI通信大致是这样:

ecb
server<------>isapi
typedef struct _EXTENSION_CONTROL_BLOCK
{DWORD cbSize; // Size of this struct.
DWORD dwVersion; // Version info of this spec
HCONN ConnID; // Context number not to be modified!
DWORD dwHttpStatusCode; // HTTP Status code
CHAR lpszLogData[HSE_LOG_BUFFER_LEN];// null terminated log info specific to this Extension DLL
LPSTR lpszMethod; // REQUEST_METHOD
LPSTR lpszQueryString; // QUERY_STRING
LPSTR lpszPathInfo; // PATH_INFO
LPSTR lpszPathTranslated; // PATH_TRANSLATED
DWORD cbTotalBytes; // Total bytes indicated from client
DWORD cbAvailable; // Available number of bytes
LPBYTE lpbData; // Pointer to cbAvailable bytes
LPSTR lpszContentType; // Content type of client data
BOOL (WINAPI * GetServerVariable);
BOOL (WINAPI * WriteClient);
BOOL (WINAPI * ReadClient);
BOOL (WINAPI * ServerSupportFunction);
}

  可以看出isapi里面有个WriteClient和ReadClient支持对客户的读、写,其实这就是对于那个通道的读、写。只要我们在ISAPI溢出时,shellcode能找到这个ecb参数,就可以读写这个通道,实现对抗防火墙,与我们的client的溢出程序交互的功能了。这点可以考虑溢出时的寄存器以及堆栈里面的参数等看什么是ecb参数,实在不行还可以shellcode直接搜索内存结构找到我们自己的ecb,这两种办法在我的不同程序里面使用过,效果都不错。

  注意apache的ISPAI实现上没有实现ReadClient的功能,可能因为觉得处理一个请求的时候已经不在需要读客户端了,但你完全可以通过ecb找到socket,再直接调用send功能发送。再就是很多proxy(网关一定不会)实现上也是client------>proxy------>server------>proxy------>client,而不是client<------>proxy<------>server。所以对于这样的代理我们不要让其成为中间环节,因为这会破坏我们client与shellcode的良好的交互性。

  2、CGI接口;熟悉IIS的cgi接口一点的可能就会明白其数据是下面一种形式:

    pipe pipe
    server------>cgi------>server

  看IIS这点处理数据也同样不是完全交互的,所以我开始处理CGI的溢出的时候也是没办法使用的开port,再client连这port的办法实现。但对于上面那种良好的交互性、对付防火墙等功能,始终心存怀念,所以也一直考虑解决办法。

  这段时间突然想到,虽然这时cgi是在单独的空间里面,但会不会继承了server的socket,仍然还有读写那socket的可能呢?于是今天在cgi的shellcode里面不是直接输出或者开port等待连接后往里面写,而是填加了代码往所有socket里面写,可喜的是在client里面成功接收到来自shellcode的信息。这说明这个通道是通的,读应该也没问题。现在需要的就是shellcode里面怎么找到这个正确的socket。这点也需要技术去解决,不过应该没什么问题。

  对于apache等的cgi,相信也有同样的结果,愿望始终应该要美好点嘛。
 
  上面介绍了iis的两种应用的情况下使用通道对抗防火墙,但看那技术对于别的unix等系统的应用应该一样可以。毕竟这种思路是系统无关的,剩下的就只有技术细节了。是不是也想把你的unix下的shellcode加上对抗防火墙的功能了呢?其实我的溢出程序编写里面还有很多东西你可以考虑借鉴的呢,像溢出点定位呢、shellcode定位呢,原代码编写shellcode呢,shellcode编码呀等等。其实很想自己动手写一个满意的unix等系统的溢出攻击程序样本出来,但一个人不能什么都做呀,也还有很多别的事要做呢。

关键词:
【推荐给好友】【关闭】
最新五条评论
查看全部评论
评论总数 0 条
您的评论
用户名: 新注册) 密 码:

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:局域网IP地址的非法使用问题解决方法

下一篇:如何做到不输入密码照样登陆Windows系统