CSDN博客

img e_lion

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

发表于2001/3/30 12:35:00  494人阅读

现在很多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 0

相关博文

我的热门文章

img
取 消
img