現(xiàn)代木馬的實(shí)現(xiàn)是建立在一種既可靠，又不易被宿主發(fā)現(xiàn)的通訊方案上的，本文就是對各種方案的實(shí)現(xiàn)方法，可靠性，安全性做了一些理論上的探討。充分的理解木馬的客戶端和服務(wù)端是怎么進(jìn)行隱藏的，不但可以幫助您能深刻的理解網(wǎng)絡(luò)通信的原理，也可以更有效的做好安全防范。基于此我們編發(fā)了此文，下面我們進(jìn)入正題。
首先應(yīng)該明確的是受害者的機(jī)器上運(yùn)行的木馬程序我們稱之為服務(wù)端，控制者機(jī)器上運(yùn)行的我們稱之為客戶端(其實(shí)對于現(xiàn)代的木馬，已經(jīng)很難說誰是客戶，誰是服務(wù)了，不過我們還是繼續(xù)用這種叫法)。另外雖然Windows9x仍然有巨大的用戶基礎(chǔ)，但是Windows9x向Windows XP遷徙只是早晚問題，所以這里的討論主要是針對NT/2000/XP平臺的。
1.使用TCP協(xié)議，服務(wù)端偵聽，客戶端連接。
這是最簡單，最早，最廣泛使用的一種通訊方案。使用過冰河或者被冰河客戶端掃過的對此一定不會陌生。這種通訊方案是服務(wù)端在宿主機(jī)器上開一個TCP端口，然后等待客戶端的連接，在通過對客戶端的認(rèn)證后，客戶端就可以控制服務(wù)端了。由于是建立在TCP協(xié)議基礎(chǔ)上，所以通訊的可靠性是得到保證的。但是通訊的安全性卻很成問題。首先，使用像fport,tcpview pro這樣的工具可以很容易的發(fā)現(xiàn)在某一端口上偵聽的進(jìn)程，以及進(jìn)程對應(yīng)的可執(zhí)行文件。其次，在安裝了防火墻的機(jī)器上，當(dāng)客戶端連接到服務(wù)端時，很容易引起防火墻報(bào)警。
2.使用TCP協(xié)議。
客戶端偵聽，服務(wù)端連接。這就是所謂的反向連接技術(shù)了。為了克服服務(wù)端在某一端口上偵聽易被發(fā)現(xiàn)這一缺點(diǎn)，現(xiàn)在服務(wù)端不再偵聽端口，而是去連接客戶端在偵聽的某一端口。這樣用一般的port scanner或者fport就發(fā)現(xiàn)不了服務(wù)端了。而為了更好的麻痹宿主機(jī)，客戶端偵聽的端口一般是21,80,23這種任何人都要訪問的端口。雖然在安裝了防火墻的機(jī)器上，服務(wù)端去連接客戶端還是要引起防火墻報(bào)警，但是一個粗心的用戶很可能會忽略“應(yīng)用程序xxxxx試圖訪問xxx.xxx.xxx.xxx通過端口80”這樣的警告。
這種反向連接技術(shù)要解決的一個問題是，服務(wù)端如何找到客戶端。由于一般客戶端都是撥號上網(wǎng)的，沒有一個固定的IP，所以客戶端IP不可能硬編碼在服務(wù)端程序中。當(dāng)然由于撥號上網(wǎng)用戶的IP一般都是處于一個固定的IP地址范圍內(nèi)，服務(wù)端也可以掃描這個范圍，然后根據(jù)被掃描主機(jī)的反饋來確定是否是自己的客戶端，但是服務(wù)端掃描一個IP地址范圍也太。另一個方法是客戶端通過一個有固定IP或者固定域名的第三方發(fā)布自己的IP，實(shí)現(xiàn)的方法就很多了，比如通過一個公共的郵箱，通過一個個人主頁，就看你有多大的想象力。
3.使用UDP協(xié)議。
服務(wù)端偵聽，客戶端連接;客戶端偵聽，服務(wù)端連接。方法和安全性與使用TCP協(xié)議差不多。需要注意的是UDP不是一個可靠的協(xié)議，所以，必須在UDP協(xié)議的基礎(chǔ)上設(shè)計(jì)一個自己的可靠的報(bào)文傳遞協(xié)議。
4.解決防火墻問題。
無論是服務(wù)端被動偵聽，還是服務(wù)端主動連接，在服務(wù)端和客戶端試圖建立連接時都會引起防火墻得報(bào)警。畢竟粗心得用戶不會很多，所以，解決防火墻報(bào)警是服務(wù)端必須要解決的一個問題。一種方法是代碼注入，服務(wù)端將自己注入到一個可以合法的與外界進(jìn)行網(wǎng)絡(luò)通訊的進(jìn)程(比如 IE, ICQ, OICQ, TELNTED, FTPD, IIS等)的地址空間中，然后或者可以以一個新線程的形式運(yùn)行，或者只是修改宿主進(jìn)程，截獲宿主進(jìn)程的網(wǎng)絡(luò)系統(tǒng)調(diào)用(WinSock)。后者的實(shí)現(xiàn)可能要麻煩一些。如果是以新線程的形式運(yùn)行，那么然后或者可以被動偵聽，或者可以主動連接。
無論哪種情況都不會引起防火墻的報(bào)警(當(dāng)然不是百分之百不會引起防火墻報(bào)警)。但要注意的是如果是被動偵聽的話，比如寄生在IE內(nèi)，用fport會發(fā)現(xiàn)IE在某一個端口偵聽，這有可能會引起細(xì)心的用戶的警覺。所以比較好得方法是在新線程內(nèi)去主動連接客戶端，而且連的是客戶端的80端口;如果是寄生在OICQ內(nèi)，何不連接客戶端的8000端口。使用代碼注入需要服務(wù)端具有若干特權(quán)，考慮到一般用戶都是以Admin身份啟動NT的，這應(yīng)該不是一個問題(如果服務(wù)端是作為一個service啟動的話，就更沒問題了)。 5.服務(wù)端主動連接時客戶端IP的公布問題。
使用第三方公布客戶端IP不是一種可靠的方法。比如如果是通過一個個人主頁發(fā)布客戶端IP的話，一旦由于種種原因，這個個人主頁被主頁提供商取消的話，服務(wù)端就找不到客戶端了。而這種個人主頁被主頁提供商取消的可能性是很大的。同時客戶端也要冒暴露自己的IP的風(fēng)險(xiǎn)。所以更好的方法是客戶端通過某種方法主動告訴服務(wù)端自己的IP和端口，然后服務(wù)端來連接。這樣可以保證最大的可靠性，安全性和靈活性。
服務(wù)端怎么收到客戶端的通知呢?一種方法是我們截獲其他進(jìn)程收到的TCP數(shù)據(jù)或者UDP包，然后分析截獲的數(shù)據(jù)，從中確定是否客戶端發(fā)來了一個報(bào)告其IP的數(shù)據(jù)片斷。另一種方法是使用RAW socket來收聽ECHO REPLY類型的ICMP包，在ICMP數(shù)據(jù)包的數(shù)據(jù)去就包含了客戶端IP。而對于普通用戶來說，由于要上網(wǎng)瀏覽，這樣的ICMP包是很少過濾掉的。
6.用ICMP來通訊。
既然客戶端可以通過發(fā)一個ICMP(ECHO REPLY)來告訴服務(wù)端它的IP，那為什么不把所有服務(wù)端和客戶端的通訊都建立在ICMP的基礎(chǔ)上呢?服務(wù)端向客戶端發(fā)ICMP(ECHO REQUEST)，客戶端向服務(wù)端發(fā)ICMP(ECHO REPLY)，然后可以在ICMP基礎(chǔ)上建立一個自己的可靠數(shù)據(jù)報(bào)通訊協(xié)議。如果不怕煩的話，還可以建立一個TCP over ICMP。由于一般的用戶這兩類ICMP包都是設(shè)為無警告放行的，這種方法的隱秘性還是很強(qiáng)的。
7. 用自定義的協(xié)議來通訊。
我們知道IP頭的協(xié)議字段指定了這個IP包承載得數(shù)據(jù)的協(xié)議，比如TCP,UDP,ICMP等等。我們完全可以把這個字段設(shè)為我們自己定義的值(>80)，定義自己的通訊協(xié)議。不過估計(jì)這種IP包將會被所有的防火墻過濾掉。
8.關(guān)于服務(wù)器上的木馬的通訊隱藏。
前面所說都是針對個人用戶(大部分都是撥號用戶，包括Modem,ISDN,ADSL,FTTX+LA,Cable Modem)。對這類機(jī)器來說，一般都沒有開什么服務(wù)，而且一般都使用了個人防火墻，同時ICMP ECHO REPLY/REQUEST都是放行的，所有才有我們上述的各種方案。而對于服務(wù)器來說，至少要開HTTP服務(wù)，同時，又一般位于專門的防火墻之后。這個專門的防火墻很可能過濾掉除類型為TCP，且目的端口為80的IP包之外的所有的IP包，更不要說各類ICMP包了。向下的方案通不過，我們可以試試向上的方案。一種方法就是注射到IIS服務(wù)的進(jìn)程空間中，然后在IIS接受到木馬客戶端的請求前來個預(yù)處理，在IIS將數(shù)據(jù)發(fā)給木馬客戶端時來個后處理，不過我不知道怎么實(shí)現(xiàn)，不知哪為高手知道。
另一種方法就是寫一個ISAPI AP，這樣，木馬客戶端發(fā)個 "http://xxx.xxx.xxx.xxx/backdoor.dll?cmd=dir+c:"請求來發(fā)命令了。當(dāng)然，一切信息都是加密得。RPC除了RPC over SMB,RPC over TCP等等外，還有一個RPC over HTTP，事實(shí)上QQ的http代理就是他自己定義的一個rpc over http，至少Q(mào)Q自己是這么叫的。現(xiàn)在，我們也來了個rpc over http。
通訊隱藏技術(shù)只是木馬隱藏諸技術(shù)中得一部分，但也是最重要的一部分。因?yàn)樗坏Ｗo(hù)木馬，還要保護(hù)木馬得控制者，所以不管是木馬編寫者，還是防火墻編寫者，都應(yīng)該對這一部分給于足夠的重視。
