繞過(guò)Apache httpproxy 繼續(xù)DOS TOMCAT/JBOSS
tomcat在外面使用apache的情況,你會(huì)發(fā)現(xiàn)使用POC,這里是無(wú)效的,關(guān)于這一點(diǎn),官方如下描述“This flaw is mitigated if Tomcat is behind a reverse proxy (such as Apache httpd 2.2) as the proxy should reject the invalid transfer encoding header.”他說(shuō)如果你的tomcat外面還有一層web server做轉(zhuǎn)發(fā),就會(huì)減輕這個(gè)漏洞帶來(lái)的危害。
從長(zhǎng)遠(yuǎn)的角度講,一個(gè)完整的安全方案,應(yīng)該是和現(xiàn)有架構(gòu)本身的特性,是分開的,它并不能因?yàn)楝F(xiàn)有應(yīng)用架構(gòu)攔截了攻擊,于是自己就表示影響不大。如果安全方案總是依靠應(yīng)用現(xiàn)有的特性,那就要承受可能被繞過(guò)的隱患,這種隱患,導(dǎo)致我們總有一天,會(huì)不得不把補(bǔ)丁老老實(shí)實(shí)的打上去。如本文就是一個(gè)很好的例子。
也許大家看到這個(gè),放心了很多,就沒(méi)有修補(bǔ)。
官方這么講,是什么原理呢?我們看下攻擊的POC:
遇到這樣的HTTP頭,apache會(huì)因?yàn)橛?rdquo;transfer-encoding: buffered”,則自動(dòng)攔截下來(lái),自己處理掉這個(gè)數(shù)據(jù)包,不交給tomcat處理,并直接返回錯(cuò)誤。這是出于apache自己的原因造成的,但是這不重要。重要的是,這個(gè)攔截的機(jī)制,能否被繞過(guò)。TOMCAT仍然老老實(shí)實(shí)的在apache后面等候數(shù)據(jù)包,如果能繞過(guò),它就會(huì)再次忠實(shí)的睡大覺(jué)。要繞過(guò)apache的“自動(dòng)攔截”(這個(gè)名字好記點(diǎn)),就必須讓apache不認(rèn)識(shí)這個(gè)頭。
發(fā)個(gè)數(shù)據(jù)包,這是攔截后返回的信息:
Apache返回了500 Internal Server Error,如果去掉那個(gè)頭”transfer-encoding: buffered”,返回就200 OK了,但是也就打不死了。
看起來(lái)這是個(gè)死循環(huán),永遠(yuǎn)搞不定,所以tomcat官方也說(shuō)了能減輕危害。
但是,如果apache和tomcat對(duì)某些字符的理解不一致,可能會(huì)apache放過(guò)某些字符,但是tomcat卻剛巧認(rèn)識(shí),又如果這個(gè)字符剛好能影響到這里,就會(huì)bypass這個(gè)所謂的“防御架構(gòu)”,所以我們找找看有沒(méi)有這樣“猥瑣”的字符存在。
Apache和Tomcat實(shí)現(xiàn)原理不一樣(廢,所以,對(duì)一些字符可能理解不一致,是正常的。
我們先看看大家對(duì)http heads的分段是如何理解的,我查到“CRLF”,從apache源碼中看到,它把crlf定義為“\r\n”,轉(zhuǎn)換為也就是16進(jìn)制的“0D 0A”,“#define CRLF "\r\n"”,只有這一個(gè)對(duì)crlf的定義。
這有什么用呢?這其實(shí)表示,apache所理解CRLF,就是“\r\n”,它不認(rèn)識(shí)“\n\r”(看仔細(xì)點(diǎn),反過(guò)來(lái)了)。
悲劇的是,tomcat和JBOSS認(rèn)識(shí)它們,并且很喜歡它們!
Tomcat和jboss對(duì)這個(gè)東西的定義含義是
“If (xx==’\r’|| xx==’\n’)”
就是說(shuō),不但把字符反過(guò)來(lái)寫它們認(rèn)識(shí),就算拆成骨頭,TOMCAT和JBOSS也認(rèn)識(shí)。
知道了這個(gè)關(guān)鍵點(diǎn),下面思路就有了。我們把”transfer-encoding: buffered”這個(gè)字段,偽裝成其他字段的一部分,讓apache放過(guò)去,交給tomcat處理就可以了。
POC:
于是我使用16進(jìn)制編輯器,UltraEdit打開我復(fù)制出來(lái)的數(shù)據(jù)包文件aa.txt
找到 transfer-encoding: buffered
把這一行之前的字符
注意括起來(lái)的兩個(gè)地方,把它們順序分別顛倒一下,兩個(gè)地方的“0D 0A”都改為“0A 0D”。改后如下:
原來(lái)包是這樣的:
Connection: keep-alive 這是字段1
transfer-encoding: buffered 這是字段2
Content-Length: 145 這是字段3
三個(gè)字段其實(shí)屬于同一個(gè)字符串,他們的間隔本來(lái)是“\r\n”,我們改為“\n\r”。一旦這個(gè)包發(fā)給apache后,apache認(rèn)為只有一個(gè)字段”Connection”過(guò)來(lái)了,接著就把這個(gè)字段原封不動(dòng)的交給tomcat。
可憐的tomcat看到這個(gè)包,卻認(rèn)為它是三個(gè)字段,解開了這個(gè)炸藥包,所以,砰。。。掛了
現(xiàn)在把我改后的文件,使用nc提交上去:
當(dāng)有信息返回時(shí),再看看tomcat的控制臺(tái),已經(jīng)一大堆異常了,測(cè)試apache后面的JBOSS也是一樣,統(tǒng)統(tǒng)掛掉。
所以,遇到這樣的漏洞,能對(duì)服務(wù)器造成極大危害,而我們的架構(gòu)又剛好符合官方描述的“安全狀態(tài)”時(shí),可以放緩處理,但是不能不處理。很多官方最喜歡做的,就是完全站在開發(fā)產(chǎn)品的角度,不懂安全的含義,就直接針對(duì)POC,出一套解決方案。無(wú)數(shù)的事實(shí)證明,這樣的方案,是最容易被繞過(guò)的。
apache的http proxy后面的tomcat和JBOSS,需要及時(shí)修補(bǔ),大家就不要存在僥幸心理了。
【編輯推薦】