黑客避開檢測的手段
更新時(shí)間:2006年10月03日 00:00:00 作者:
黑客的聰明并不只是在于他們知道如何去入侵服務(wù)器,還在于他們知道如何去偽裝自己的攻擊。惡意的攻擊者會(huì)使用多種逃避的手段來讓自己不會(huì)被檢測到,所以作為系統(tǒng)管理員,也應(yīng)當(dāng)了解這些手段以應(yīng)付可能發(fā)生的攻擊。
這篇文章的主要目的不是揭示黑客新的攻擊手法,而是對(duì)那些黑客所用到的逃避檢測的手法以及他們可能留下的證據(jù)做描述。這些手段的欺騙性很大,所以想檢測到它們也更加的困難。
網(wǎng)絡(luò)服務(wù)器
我們的實(shí)驗(yàn)環(huán)境使用兩種最常用的網(wǎng)絡(luò)服務(wù)器,Apache和微軟的Internet Information Server(IIS)。我們在Red Hat Linux上運(yùn)行Apache 1.3.9,在Windows NT 4.0上運(yùn)行IIS 4.0。并且兩種都采用普通和允許SSL的版本,所以我們可以對(duì)加密和未加密的服務(wù)器的攻擊做測試。
16進(jìn)制編碼
一種最簡單的將攻擊偽裝的手段就是修改URL請求。作為管理員,我們一般會(huì)在日志文件中查找某些字符串,或是一些普通文本的字符集。例如我們在請求中查找匹配已知漏洞的字符串。例如,我們在我們的IIS服務(wù)器中發(fā)現(xiàn)了如下的字符串,我們就知道有人正在查找是否有IIS中可以遠(yuǎn)程利用的MDAC漏洞:
06:45:25 10.0.2.79 GET /msadc/ 302
要知道攻擊者是如何躲過這種匹配檢測的,請參考以下作為惡意攻擊者策略一部分的請求。要確定msadc目錄是否存在,攻擊者可能鍵入以下內(nèi)容:
[root@localhost /root]# nc -n 10.0.2.55 80
GET /msadc HTTP/1.0
這就會(huì)產(chǎn)生我們以上所見的日志文件。攻擊者可以將請求進(jìn)行十六進(jìn)制的ASCII字符編碼。在以上的例子中,字符串msadc在十六進(jìn)制編碼以后就會(huì)變?yōu)?D 73 61 64 63。你可以使用Windows Charmap程序來快速的進(jìn)行字符的ASCII到十六進(jìn)制的轉(zhuǎn)換。以上的HTTP請求,將字符串msadc用十六進(jìn)制編碼以后,就變成了:
[root@localhost]# nc -n 10.0.2.55 80
GET /%6D%73%61%64%63 HTTP/1.0
IIS的日志文件顯示:
07:10:39 10.0.2.31 GET /msadc/ 302
?wèi)?yīng)當(dāng)注意的是,雖然采用了十六進(jìn)制編碼的手段,但是所產(chǎn)生的日志和沒有使用十六進(jìn)制編碼的URL產(chǎn)生的是一樣的。所以在這個(gè)例子里,編碼并沒有幫助攻擊者逃避檢測。但是,如果我們看看看Apache的日志情況,那么就是另外一個(gè)情形了。以下列出了攻擊者使用來搜索某個(gè)CGI腳本的命令,后面跟著的是使用十六進(jìn)制編碼以后的同樣命令:
[root@localhost]# nc -n 10.0.0.2 80
HEAD /cgi-bin/test-cgi HTTP/1.0
[root@localhost]# nc -n 10.0.0.2 80
HEAD /%63%67%69-bin/test-%63%67%69 HTTP/1.0
現(xiàn)在我們來查看一下access_log文件:
10.10.10.10 - - [18/Oct/2000:08:22:47 -0700] "HEAD /cgi-bin/test-cgi HTTP/1.0" 200 0
10.10.10.10 - - [18/Oct/2000:08:23:47 -0700] "HEAD /%63%67%69-bin/test-%63%67%69 HTTP/1.0" 200 0
首先應(yīng)注意到的是在這兩個(gè)例子中都是200代碼說明命令完成成功。但是在第二中情況中,日志中出現(xiàn)的是十六進(jìn)制的值而不是明文的。如果我們是依賴于形式來對(duì)這種攻擊進(jìn)行檢測的話,那么我們是不可能檢測到所發(fā)生的攻擊的。許多的入侵檢測系統(tǒng)使用的格式匹配技術(shù)智能化都不高,并且有些產(chǎn)品不會(huì)將十六進(jìn)制的URL轉(zhuǎn)換過后進(jìn)行匹配。但是不論所使用的入侵檢測軟件是否能夠?qū)κM(jìn)制的代碼進(jìn)行轉(zhuǎn)換,所有的網(wǎng)絡(luò)管理員都應(yīng)當(dāng)對(duì)這種伎倆有所了解。
代理服務(wù)器
因?yàn)閷?duì)攻擊者而言完全隱藏攻擊行為是很難做到的,所以掩蓋攻擊的真實(shí)來源也就成為相當(dāng)重要的課題了。如果黑客可以隱藏他的源IP地址的話,那么他就可以在不用擔(dān)心被抓住的情況下進(jìn)行攻擊。而黑客用來隱藏他們的源IP地址的一種手段就是使用代理服務(wù)器。
代理服務(wù)器是被合法的用來從一個(gè)單一的訪問點(diǎn)轉(zhuǎn)發(fā)多種協(xié)議的。一般來說,內(nèi)部用戶必須通過代理服務(wù)器才能訪問Internet,因此管理員就可以在代理服務(wù)器指定外部訪問以及內(nèi)部訪問的限制策略。用戶首先是和代理服務(wù)器建立連接,然后代理服務(wù)器就將連接請求轉(zhuǎn)發(fā)到真正的目的地址。目的地址會(huì)記錄下代理服務(wù)器的IP地址以作為請求的源地址,而不是最初發(fā)出請求的系統(tǒng)的IP地址。
但是不幸的是代理服務(wù)器在Internet上的放置太隨意了。(可以查看Proxys-4-All來獲得這些錯(cuò)誤配置機(jī)器的列表。) 這些服務(wù)器經(jīng)常會(huì)存在配置錯(cuò)誤使得Internet用戶可以連接到這些代理服務(wù)器上。一旦某個(gè)Internet用戶通過代理服務(wù)器連接到某個(gè)服務(wù)器上,該服務(wù)器就會(huì)將代理服務(wù)器的IP地址作為發(fā)出請求的源地址記錄在日志中。而在被攻擊服務(wù)器的日志中對(duì)攻擊者的記錄其IP地址是屬于一個(gè)沒有任何攻擊行為的“無辜”主機(jī)的,而不是攻擊者的真正地址。我們來看以下的例子。
下面的例子顯示了黑客的攻擊和攻擊在日志中產(chǎn)生的相關(guān)信息。
攻擊者
[root@10.1.1.1 /]# nc -v 10.8.8.8 80
HEAD / HTTP/1.0
日志文件
10.1.1.1 - - [18/Oct/2000:03:31:58 -0700] "HEAD / HTTP/1.0" 200 0
在下面這種情況中,我們看到攻擊者達(dá)到了同樣的目的,但是這次他使用了代理服務(wù)器。
攻擊者
[root@10.1.1.1 /]# nc -v 216.234.161.83 80
HEAD http://10.8.8.8/ HTTP/1.0
日志文件
216.234.161.83 - - [18/Oct/2000:03:39:29 -0700] "HEAD / HTTP/1.1" 200 0
注意在這個(gè)例子中,日志文件中所出現(xiàn)的地址是代理服務(wù)器的(216.234.161.83,proxy.proxyspace.com),而不是攻擊者的真實(shí)地址。在這個(gè)案例中,攻擊者成功的隱藏了攻擊的來源地址。不過網(wǎng)絡(luò)管理員如果能得到代理服務(wù)的支持的話還是可以追蹤到攻擊的真正來源。大多數(shù)的代理服務(wù)器都會(huì)保存一份相當(dāng)詳細(xì)的日志,所以多半也就可以從中找到攻擊的來源。但是道高一尺魔高一仗,黑客也有相應(yīng)的方法來反跟蹤:他們可以使用多重代理,也可以說是一個(gè)“代理鏈”來進(jìn)行攻擊。而管理員和執(zhí)法部門也就必須對(duì)所有的中間代理服務(wù)器進(jìn)行依次檢查來獲得攻擊來源。在黑客的團(tuán)體中這種“代理鏈”的使用非常的普遍,并且有類似SocksChain for Windows這樣的工具可供使用。
SSL
對(duì)此以往很多人進(jìn)行了討論,但是它現(xiàn)在值得再一次提出:允許SSL的服務(wù)器是不會(huì)被網(wǎng)絡(luò)入侵檢測系統(tǒng)所檢測到的。如果讓一個(gè)黑客在80端口(HTTP)和443端口(HTTPS)之間做一個(gè)選擇的話,攻擊者每一次都會(huì)選擇443端口的。這實(shí)際上并不是什么手段,而是由于加密通訊的使用所造成的副作用。你可以使用網(wǎng)絡(luò)服務(wù)器日志文件來監(jiān)視443端口的請求。
結(jié)論
我們向你演示了一些網(wǎng)絡(luò)上的黑客常用的欺騙伎倆。無須多說,這些手段是隨著黑客們的想象力和創(chuàng)造力不斷增加而不斷擴(kuò)展的。例如十六進(jìn)制編碼這樣的技術(shù)不光是用在欺騙性的日志文件入口這樣的地方;它同樣也欺騙網(wǎng)絡(luò)服務(wù)器的URL解析機(jī)制,并可能導(dǎo)致例如源代碼暴露之類的漏洞的出現(xiàn)。攻擊者某些時(shí)候也使用多代理服務(wù)器來進(jìn)行掃描和攻擊,讓管理員很難跟蹤攻擊的真正來源。當(dāng)然,SSL某些時(shí)候?yàn)椤鞍踩诳托袨椤变伷搅说缆贰?
這篇文章的主要目的不是揭示黑客新的攻擊手法,而是對(duì)那些黑客所用到的逃避檢測的手法以及他們可能留下的證據(jù)做描述。這些手段的欺騙性很大,所以想檢測到它們也更加的困難。
網(wǎng)絡(luò)服務(wù)器
我們的實(shí)驗(yàn)環(huán)境使用兩種最常用的網(wǎng)絡(luò)服務(wù)器,Apache和微軟的Internet Information Server(IIS)。我們在Red Hat Linux上運(yùn)行Apache 1.3.9,在Windows NT 4.0上運(yùn)行IIS 4.0。并且兩種都采用普通和允許SSL的版本,所以我們可以對(duì)加密和未加密的服務(wù)器的攻擊做測試。
16進(jìn)制編碼
一種最簡單的將攻擊偽裝的手段就是修改URL請求。作為管理員,我們一般會(huì)在日志文件中查找某些字符串,或是一些普通文本的字符集。例如我們在請求中查找匹配已知漏洞的字符串。例如,我們在我們的IIS服務(wù)器中發(fā)現(xiàn)了如下的字符串,我們就知道有人正在查找是否有IIS中可以遠(yuǎn)程利用的MDAC漏洞:
06:45:25 10.0.2.79 GET /msadc/ 302
要知道攻擊者是如何躲過這種匹配檢測的,請參考以下作為惡意攻擊者策略一部分的請求。要確定msadc目錄是否存在,攻擊者可能鍵入以下內(nèi)容:
[root@localhost /root]# nc -n 10.0.2.55 80
GET /msadc HTTP/1.0
這就會(huì)產(chǎn)生我們以上所見的日志文件。攻擊者可以將請求進(jìn)行十六進(jìn)制的ASCII字符編碼。在以上的例子中,字符串msadc在十六進(jìn)制編碼以后就會(huì)變?yōu)?D 73 61 64 63。你可以使用Windows Charmap程序來快速的進(jìn)行字符的ASCII到十六進(jìn)制的轉(zhuǎn)換。以上的HTTP請求,將字符串msadc用十六進(jìn)制編碼以后,就變成了:
[root@localhost]# nc -n 10.0.2.55 80
GET /%6D%73%61%64%63 HTTP/1.0
IIS的日志文件顯示:
07:10:39 10.0.2.31 GET /msadc/ 302
?wèi)?yīng)當(dāng)注意的是,雖然采用了十六進(jìn)制編碼的手段,但是所產(chǎn)生的日志和沒有使用十六進(jìn)制編碼的URL產(chǎn)生的是一樣的。所以在這個(gè)例子里,編碼并沒有幫助攻擊者逃避檢測。但是,如果我們看看看Apache的日志情況,那么就是另外一個(gè)情形了。以下列出了攻擊者使用來搜索某個(gè)CGI腳本的命令,后面跟著的是使用十六進(jìn)制編碼以后的同樣命令:
[root@localhost]# nc -n 10.0.0.2 80
HEAD /cgi-bin/test-cgi HTTP/1.0
[root@localhost]# nc -n 10.0.0.2 80
HEAD /%63%67%69-bin/test-%63%67%69 HTTP/1.0
現(xiàn)在我們來查看一下access_log文件:
10.10.10.10 - - [18/Oct/2000:08:22:47 -0700] "HEAD /cgi-bin/test-cgi HTTP/1.0" 200 0
10.10.10.10 - - [18/Oct/2000:08:23:47 -0700] "HEAD /%63%67%69-bin/test-%63%67%69 HTTP/1.0" 200 0
首先應(yīng)注意到的是在這兩個(gè)例子中都是200代碼說明命令完成成功。但是在第二中情況中,日志中出現(xiàn)的是十六進(jìn)制的值而不是明文的。如果我們是依賴于形式來對(duì)這種攻擊進(jìn)行檢測的話,那么我們是不可能檢測到所發(fā)生的攻擊的。許多的入侵檢測系統(tǒng)使用的格式匹配技術(shù)智能化都不高,并且有些產(chǎn)品不會(huì)將十六進(jìn)制的URL轉(zhuǎn)換過后進(jìn)行匹配。但是不論所使用的入侵檢測軟件是否能夠?qū)κM(jìn)制的代碼進(jìn)行轉(zhuǎn)換,所有的網(wǎng)絡(luò)管理員都應(yīng)當(dāng)對(duì)這種伎倆有所了解。
代理服務(wù)器
因?yàn)閷?duì)攻擊者而言完全隱藏攻擊行為是很難做到的,所以掩蓋攻擊的真實(shí)來源也就成為相當(dāng)重要的課題了。如果黑客可以隱藏他的源IP地址的話,那么他就可以在不用擔(dān)心被抓住的情況下進(jìn)行攻擊。而黑客用來隱藏他們的源IP地址的一種手段就是使用代理服務(wù)器。
代理服務(wù)器是被合法的用來從一個(gè)單一的訪問點(diǎn)轉(zhuǎn)發(fā)多種協(xié)議的。一般來說,內(nèi)部用戶必須通過代理服務(wù)器才能訪問Internet,因此管理員就可以在代理服務(wù)器指定外部訪問以及內(nèi)部訪問的限制策略。用戶首先是和代理服務(wù)器建立連接,然后代理服務(wù)器就將連接請求轉(zhuǎn)發(fā)到真正的目的地址。目的地址會(huì)記錄下代理服務(wù)器的IP地址以作為請求的源地址,而不是最初發(fā)出請求的系統(tǒng)的IP地址。
但是不幸的是代理服務(wù)器在Internet上的放置太隨意了。(可以查看Proxys-4-All來獲得這些錯(cuò)誤配置機(jī)器的列表。) 這些服務(wù)器經(jīng)常會(huì)存在配置錯(cuò)誤使得Internet用戶可以連接到這些代理服務(wù)器上。一旦某個(gè)Internet用戶通過代理服務(wù)器連接到某個(gè)服務(wù)器上,該服務(wù)器就會(huì)將代理服務(wù)器的IP地址作為發(fā)出請求的源地址記錄在日志中。而在被攻擊服務(wù)器的日志中對(duì)攻擊者的記錄其IP地址是屬于一個(gè)沒有任何攻擊行為的“無辜”主機(jī)的,而不是攻擊者的真正地址。我們來看以下的例子。
下面的例子顯示了黑客的攻擊和攻擊在日志中產(chǎn)生的相關(guān)信息。
攻擊者
[root@10.1.1.1 /]# nc -v 10.8.8.8 80
HEAD / HTTP/1.0
日志文件
10.1.1.1 - - [18/Oct/2000:03:31:58 -0700] "HEAD / HTTP/1.0" 200 0
在下面這種情況中,我們看到攻擊者達(dá)到了同樣的目的,但是這次他使用了代理服務(wù)器。
攻擊者
[root@10.1.1.1 /]# nc -v 216.234.161.83 80
HEAD http://10.8.8.8/ HTTP/1.0
日志文件
216.234.161.83 - - [18/Oct/2000:03:39:29 -0700] "HEAD / HTTP/1.1" 200 0
注意在這個(gè)例子中,日志文件中所出現(xiàn)的地址是代理服務(wù)器的(216.234.161.83,proxy.proxyspace.com),而不是攻擊者的真實(shí)地址。在這個(gè)案例中,攻擊者成功的隱藏了攻擊的來源地址。不過網(wǎng)絡(luò)管理員如果能得到代理服務(wù)的支持的話還是可以追蹤到攻擊的真正來源。大多數(shù)的代理服務(wù)器都會(huì)保存一份相當(dāng)詳細(xì)的日志,所以多半也就可以從中找到攻擊的來源。但是道高一尺魔高一仗,黑客也有相應(yīng)的方法來反跟蹤:他們可以使用多重代理,也可以說是一個(gè)“代理鏈”來進(jìn)行攻擊。而管理員和執(zhí)法部門也就必須對(duì)所有的中間代理服務(wù)器進(jìn)行依次檢查來獲得攻擊來源。在黑客的團(tuán)體中這種“代理鏈”的使用非常的普遍,并且有類似SocksChain for Windows這樣的工具可供使用。
SSL
對(duì)此以往很多人進(jìn)行了討論,但是它現(xiàn)在值得再一次提出:允許SSL的服務(wù)器是不會(huì)被網(wǎng)絡(luò)入侵檢測系統(tǒng)所檢測到的。如果讓一個(gè)黑客在80端口(HTTP)和443端口(HTTPS)之間做一個(gè)選擇的話,攻擊者每一次都會(huì)選擇443端口的。這實(shí)際上并不是什么手段,而是由于加密通訊的使用所造成的副作用。你可以使用網(wǎng)絡(luò)服務(wù)器日志文件來監(jiān)視443端口的請求。
結(jié)論
我們向你演示了一些網(wǎng)絡(luò)上的黑客常用的欺騙伎倆。無須多說,這些手段是隨著黑客們的想象力和創(chuàng)造力不斷增加而不斷擴(kuò)展的。例如十六進(jìn)制編碼這樣的技術(shù)不光是用在欺騙性的日志文件入口這樣的地方;它同樣也欺騙網(wǎng)絡(luò)服務(wù)器的URL解析機(jī)制,并可能導(dǎo)致例如源代碼暴露之類的漏洞的出現(xiàn)。攻擊者某些時(shí)候也使用多代理服務(wù)器來進(jìn)行掃描和攻擊,讓管理員很難跟蹤攻擊的真正來源。當(dāng)然,SSL某些時(shí)候?yàn)椤鞍踩诳托袨椤变伷搅说缆贰?
相關(guān)文章
跨站式腳本(Cross-SiteScripting)XSS攻擊原理分析
XSS又叫CSS (Cross Site Script) ,跨站腳本攻擊。它指的是惡意攻擊者往Web頁面里插入惡意html代碼,當(dāng)用戶瀏覽該頁之時(shí),嵌入其中Web里面的html代碼會(huì)被執(zhí)行,從而達(dá)到惡意用戶的特殊目的。2008-09-09分析攻擊IP來源地與防御IP攻擊的應(yīng)對(duì)策略
今天小編就為大家分享一篇關(guān)于分析攻擊IP來源地并畫出餅圖的文章,小編覺得內(nèi)容挺不錯(cuò)的,現(xiàn)在分享給大家,具有很好的參考價(jià)值,需要的朋友一起跟隨小編來看看吧2018-09-09