现在很多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的良好的交互性。
２、ＣＧＩ接口；熟悉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等系统的溢出攻击程序样本出来，但一个人不能什么都做呀,也还有很多别的事要做呢。
