溢位程式使用通道對抗防火牆 (轉)

溢位程式使用通道對抗防火牆 (轉)[@more@]現在很多等應用使用了，我們自己也可能處於、透明閘道器等後面，這對於等的通訊造成了一個小小的麻煩。可能很多人會想到code主動連線，這個如果防火牆做得好的話，不准許訪問外部一樣不行，即使不考慮這防火牆，而我們自己可能往往處於代理或者透明閘道器後面，考慮這也是一道難題。
 但我們仔細考慮考慮一下資料傳輸問題，就會發現實際上這一切都沒有想象的那麼困難，其實早已經有東西為我們掃清了道路，那就是資料通道。所以很多問題怕的就是我們沒有去想，沒有去理解一些東西。只要我們訪問到了server,其實對於現在這些應用，中間已經建立了類似下面一樣的一個通道，其實中間可能還更復雜，但對於我們的應用，都會有這麼一個通道。
 client  要運用這個通道,只要我們在server上找到了對於這個通道的讀寫就可以了。下面具體針對IIS說一說應用。IIS有兩種介面，IS和CGI，主要考慮這兩種應用的情況下的辦法。
 1、ISAPI介面；IIS的server與ISAPI通訊大致是這樣：
 ecb
 servertypedef struct _EXTENSION_CONTROL_BLOCK
{D cbSize; // Size of this struct.
DWORD dwVersion; // Version info of this spec
HCONN ConnID; // Context number not to be modified!
DWORD dwHttpStatude; // HTTP Status code
CHAR lpszLogData[HSE_LOG_BUFFER_LEN];// null tenated 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，這兩種辦法在我的不同程式裡面使用過，效果都不錯。
　　注意的ISPAI實現上沒有實現ReadClient的功能，可能因為覺得處理一個請求的時候已經不在需要讀客戶端了，但你完全可以透過ecb找到socket，再直接呼叫send功能傳送。再就是很多proxy（閘道器一定不會）實現上也是client------&gtproxy------&gtserver------&gtproxy------&gtclient,而不是client　　２、ＣＧＩ介面；熟悉IIS的cgi介面一點的可能就會明白其資料是下面一種形式：
 　　　　pipe pipe
　　　　server------&gtcgi------&gtserver
　　看IIS這點處理資料也同樣不是完全互動的，所以我開始處理CGI的溢位的時候也是沒辦法使用的開port，再client連這port的辦法實現。但對於上面那種良好的互動性、對付防火牆等功能，始終心存懷念，所以也一直考慮解決辦法。
　　這段時間突然想到，雖然這時cgi是在單獨的空間裡面，但會不會繼承了server的socket，仍然還有讀寫那socket的可能呢？於是今天在cgi的shellcode裡面不是直接輸出或者開port等待連線後往裡面寫，而是填加了程式碼往所有socket裡面寫，可喜的是在client裡面成功接收到來自shellcode的資訊。這說明這個通道是通的，讀應該也沒問題。現在需要的就是shellcode裡面怎麼找到這個正確的socket。這點也需要技術去解決，不過應該沒什麼問題。
　　對於apache等的cgi,相信也有同樣的結果，願望始終應該要美好點嘛。
　
　　上面介紹了iis的兩種應用的情況下使用通道對抗防火牆，但看那技術對於別的等的應用應該一樣可以。畢竟這種思路是系統無關的，剩下的就只有技術細節了。是不是也想把你的unix下的shellcode加上對抗防火牆的功能了呢？其實我的溢位程式編寫裡面還有很多東西你可以考慮借鑑的呢，像溢位點定位呢、shellcode定位呢，原始碼編寫shellcode呢，shellcode編碼呀等等。其實很想自己動手寫一個滿意的unix等系統的溢位程式樣本出來，但一個人不能什麼都做呀,也還有很多別的事要做呢。