木馬用戶端與服務端通訊是如何隱藏的
　

　
　

一個成功的木馬必須實現一種既可靠，又不易被宿主發現的通訊方案，下面在我所知的範圍內對各種方案的實現方法，可靠性，安全性做一些探討。文中錯誤之處一定很多，歡迎大家指出，更希望能有木馬開發經驗的高手寫一些這方面的文章，能讓不管是駭客，還是普通用戶，都得到一定的提高。至於什麼警告的我也不多說了，反正看了文章你去做壞事與我是毫無關係的。下面進入正題。
  首先應該明確的是受害者的機器上運行的木馬程式我們稱之為服務端，控制者機器上運行的我們稱之為用戶端（其實對於現代的木馬，已經很難說誰是客戶，誰是服務了，不過我們還是繼續用這種叫法）。另外雖然Windows9x仍然有巨大的用戶基礎，但是Windows9x向Windows XP遷徙只是早晚問題，所以這裏的討論主要是針對NT/2000/XP平臺的。

1.使用TCP協定，服務端偵聽，用戶端連接。這是最簡單，最早，最廣泛使用的一種通訊方案。使用過冰河或者被冰河用戶端掃過的對此一定不會陌生。這種通訊方案是服務端在宿主機器上開一個TCP埠，然後等待用戶端的連接，在通過對用戶端的認證後，用戶端就可以控制服務端了。由於是建立在TCP協定基礎上，所以通訊的可靠性是得到保證的。但是通訊的安全性卻很成問題。首先，使用像fport,tcpview pro這樣的工具可以很容易的發現在某一埠上偵聽的進程，以及進程對應的可執行檔。其次，在安裝了防火牆的機器上，當用戶端連接到服務端時，很容易引起防火牆報警。

2.使用TCP協定，用戶端偵聽，服務端連接。這就是所謂的反向連接技術了。為了克服服務端在某一埠上偵聽易被發現這一缺點，現在服務端不再偵聽埠，而是去連接用戶端在偵聽的某一埠。這樣用一般的port scanner或者fport就很發現不了服務端了。而為了更好的麻痹宿主機，用戶端偵聽的埠一般是21,80,23這種任何人都要訪問的埠。雖然在安裝了防火牆的機器上，服務端去連接用戶端還是要引起防火牆報警，但是一個粗心的用戶很可能會忽略“應用程式xxxxx試圖訪問xxx.xxx.xxx.xxx通過埠80”這樣的警告。

  這種反向連接技術要解決的一個問題是，服務端如何找到用戶端。由於一般用戶端都是撥號上網的，沒有一個固定的IP，所以用戶端IP不可能硬編碼在服務端程式中。當然由於撥號上網用戶的IP一般都是處於一個固定的IP位址範圍內，服務端也可以掃描這個範圍，然後根據被掃描主機的回饋來確定是否是自己的用戶端，但是服務端掃描一個IP位址範圍也太……另一個方法是用戶端通過一個有固定IP或者固定功能變數名稱的第三方發佈自己的IP，實現的方法就很多了，比如通過一個公共的郵箱，通過一個個人主頁，就看你有多大的想像力的。

3.使用UDP協定，服務端偵聽，用戶端連接；用戶端偵聽，服務端連接。方法和安全性與使用TCP協定差不多。需要注意的是UDP不是一個可靠的協議，所以，必須在UDP協議的基礎上設計一個自己的可靠的報文傳遞協議。

4.解決防火牆問題，無論是服務端被動偵聽，還是服務端主動連接，在服務端和用戶端試圖建立連接時都會引起防火牆得報警。畢竟粗心得用戶不會很多，所以，解決防火牆報警是服務端必須要解決的一個問題。一種方法是代碼注入，服務端將自己注入到一個可以合法的與外界進行網路通訊的進程(比如 IE, ICQ, OICQ, TELNTED, FTPD, IIS等）的位址空間中，然後或者可以以一個新線程的形式運行，或者只是修改宿主進程，截獲宿主進程的網路系統調用(WinSock)。後者的實現可能要麻煩一些。如果是以新線程的形式運行，那麼然後或者可以被動偵聽，或者可以主動連接。

  無論哪種情況都不會引起防火牆的報警(當然不是百分之百不會引起防火牆報警)。但要注意的是如果是被動偵聽的話，比如寄生在IE內，用fport會發現IE在某一個埠偵聽，這有可能會引起細心的用戶的警覺。所以比較好得方法是在新線程內去主動連接用戶端，而且連的是用戶端的80埠；如果是寄生在OICQ內，何不連接用戶端的8000埠。使用代碼注入需要服務端具有若干特權，考慮到一般用戶都是以Admin身份啟動NT的，這應該不是一個問題(如果服務端是作為一個service啟動的話，就更沒問題了)。

5.再討論一下服務端主動連接時用戶端IP的公佈問題。

  使用第三方公佈用戶端IP不是一種可靠的方法。比如如果是通過一個個人主頁發佈用戶端IP的話，一旦由於種種原因，這個個人主頁被主頁提供商取消的話，服務端就找不到用戶端了。而這種個人主頁被主頁提供商取消的可能性是很大的。同時用戶端也要冒暴露自己的IP的風險。所以更好的方法是用戶端通過某種方法主動告訴服務端自己的IP和埠，然後服務端來連接。這樣可以保證最大的可靠性，安全性和靈活性。

  服務端怎麼收到用戶端的通知呢？一種方法是我們截獲其他進程收到的TCP資料或者UDP包，然後分析截獲的資料，從中確定是否用戶端發來了一個報告其IP的資料片斷。另一種方法是使用RAW socket來收聽ECHO REPLY類型的ICMP包，在ICMP資料包的資料去就包含了用戶端IP。而對於普通用戶來說，由於要上網流覽，這樣的ICMP包是很少過濾掉的。

6.用ICMP來通訊。

  既然用戶端可以通過發一個ICMP(ECHO REPLY)來告訴服務端它的IP，那為什麼不把所有服務端和用戶端的通訊都建立在ICMP的基礎上呢?服務端向用戶端發ICMP(ECHO REQUEST)，用戶端向服務端發ICMP(ECHO REPLY)，然後可以在ICMP基礎上建立一個自己的可靠資料報通訊協定。如果不怕煩的話，還可以建立一個TCP over ICMP。由於一般的用戶這兩類ICMP包都是設為無警告放行的，這種方法的隱秘性還是很強的。

7. 用自定義的協定來通訊。

  我們知道IP頭的協議欄位指定了這個IP包承載得資料的協定，比如TCP,UDP,ICMP等等。我們完全可以把這個欄位設為我們自己定義的值(>80)，定義自己的通訊協定。不過估計這種IP包將會被所有的防火牆過濾掉。

8.關於伺服器上的木馬的通訊隱藏。

  前面所說都是針對個人用戶(大部分都是撥號用戶，包括Modem,ISDN,ADSL,FTTX+LA,Cable Modem)。對這類機器來說，一般都沒有開什麼服務，而且一般都使用了個人防火牆，同時ICMP ECHO REPLY/REQUEST都是放行的，所有才有我們上述的各種方案。而對於伺服器來說，至少要開HTTP服務，同時，又一般位於專門的防火牆之後。這個專門的防火牆很可能過濾掉除類型為TCP，且目的埠為80的IP包之外的所有的IP包，更不要說各類ICMP包了。向下的方案通不過，我們可以試試向上的方案。一種方法就是注射到IIS服務的進程空間中，然後在IIS接受到木馬用戶端的請求前來個預處理，在IIS將資料發給木馬用戶端時來個後處理，不過我不知道怎麼實現，不知哪為高手知道。

  另一種方法就是寫一個ISAPI AP，這樣，木馬用戶端發個http://xxx.xxx.xxx.xxx/ba...cmd=dir+c:\請求來發命令了。當然，一切資訊都是加密得。RPC除了RPC over SMB,RPC over TCP等等外，還有一個RPC over HTTP，事實上QQ的http代理就是他自己定義的一個rpc over http，至少QQ自己是這麼叫的。現在，我們也來了個rpc over http。

  通訊隱藏技術只是木馬隱藏諸技術中得一部分，但也是最重要的一部分。因為他不但要保護木馬，還要保護木馬得控制者，所以不管是木馬編寫者，還是防火牆編寫者，都應該對這一部分給於足夠的重視。