一種新的帶寬攻擊方式

skipjack

本文檔的Copyleft歸skipjack所有，使用GPL發(fā)布，可以自由拷貝，轉(zhuǎn)載，轉(zhuǎn)載時(shí)請(qǐng)保持文檔的完整性，嚴(yán)禁用于任何商業(yè)用途。
郵箱: skipjack@163.com
來(lái)源：http://skipjack.cublog.cn

本思路是對(duì)
http://www.xfocus.net/articles/200505/796.html
攻擊思路的整理與提高，無(wú)意開(kāi)發(fā)新的攻擊器。如利用此原理的攻擊軟件問(wèn)世，與我本人skipjack無(wú)關(guān)。

引文章第一段（呵呵...有這一段足夠了）


在TCP三次握手后插入偽造的TCP包
一、說(shuō)明 用Socket的API Connect完成TCP建立連接的三次握手，同時(shí)子進(jìn)程抓包，抓完三次握手的包后，插入第四個(gè)包即可，從對(duì)端返回的第五個(gè)包來(lái)看插入成功了，但因?yàn)椴迦肓艘粋�(gè)TCP包，之后的連接將發(fā)生混亂�？梢詫⒉迦氲哪莻�(gè)包Data設(shè)置為HTTP Request，向WEB服務(wù)器提交請(qǐng)求。又如果目標(biāo)系統(tǒng)的TCP序列號(hào)是可預(yù)計(jì)算的，那么是否可以做帶偽源地址的Blind TCP three-time handshakes和插入，值得試驗(yàn)！


作者所做的實(shí)驗(yàn)其實(shí)什么也說(shuō)明不了，只是驗(yàn)證了一下TCP協(xié)議序號(hào)和檢驗(yàn)和計(jì)算函數(shù)而已。

我想作者八成是受了CC攻擊原理的啟發(fā)，想不通過(guò)代理的方式以達(dá)到CC攻擊效果。但在序號(hào)預(yù)測(cè)這個(gè)步驟上，說(shuō)實(shí)話沒(méi)有可行性。正常TCP協(xié)議采用的同步序號(hào)是隨機(jī)值，在43億的可選空間中，以百兆帶寬的速度進(jìn)行預(yù)測(cè)也將是杯水車(chē)薪。但是……
為了防御ddos，不少?gòu)S商的安全設(shè)備中都實(shí)現(xiàn)了無(wú)狀態(tài)的syn cookie算法，這種算法在大量syn沖擊下利用cookie序號(hào)在ack包回傳的方式判斷連接請(qǐng)求的合法性。所以他們的TCP協(xié)議握手部分不是一個(gè)健康的實(shí)現(xiàn)，本思路經(jīng)修改后用于攻擊此類(lèi)設(shè)備將會(huì)取得不錯(cuò)的效果。下面簡(jiǎn)單介紹攻擊者如何以64字節(jié)ACK包換取服務(wù)器1518大數(shù)據(jù)包重傳，如果源IP偽造成功，攻擊者從理論上將獲得20余倍的帶寬放大攻擊效果 。如果有兩個(gè)目標(biāo)網(wǎng)站，本方法將一箭雙雕。
攻擊原理：利用TCP協(xié)議收到ACK后的快速重傳機(jī)制

序號(hào)亂刀之一：攻擊正常TCP/IP協(xié)議棧示意圖
        當(dāng)我們獲得http response回應(yīng)后，立即回復(fù)一個(gè)ack數(shù)據(jù)包，此ack數(shù)據(jù)包的seq值是http response數(shù)據(jù)包中的ack seq值，而ack seq值為http response數(shù)據(jù)包的seq序號(hào)值。這樣當(dāng)server收到此ack數(shù)據(jù)包后，會(huì)認(rèn)為是自己剛才發(fā)送的http response包在網(wǎng)絡(luò)中已丟失，會(huì)利用快速重傳機(jī)制加以重傳。如果我們拼命發(fā)送大量的ack包，則服務(wù)器就會(huì)不斷進(jìn)行重傳。Ack數(shù)據(jù)包的大小只需64字節(jié)，但http response通常都在512字節(jié)左右，最長(zhǎng)可達(dá)1518字節(jié)。
        因?yàn)檎�常tcp協(xié)議序號(hào)的不可預(yù)測(cè)性，所以我們?cè)谶@次攻擊中暴露了自己的真實(shí)IP。




序號(hào)亂刀之二：攻擊采用靜態(tài)syn cookie的ddos設(shè)備防護(hù)下的服務(wù)器

        所謂靜態(tài)syn cookie就是以客戶(hù)端請(qǐng)求之syn包為參數(shù)計(jì)算回復(fù)syn ack中的seq值，并在ack包回傳時(shí)判斷連接合法性的方法，這種方法被ddos廠商大量采用，并且獲得數(shù)量可觀的國(guó)家發(fā)明專(zhuān)利，呵呵….。你經(jīng)常會(huì)聽(tīng)到ddos廠商的人說(shuō)他們的設(shè)備比防火墻“牛”多了，可輕松達(dá)到百兆線速syn防御，但百兆防火墻30M攻擊流量就可以干掉，說(shuō)這種話的ddos廠商，我可以打賭他們的設(shè)備80%采用了這種syn cookie算法。
Syn cookie算法的好處是只在synflood攻擊時(shí)消耗CPU資源，這對(duì)于X86下強(qiáng)悍的通用CPU來(lái)說(shuō)，正適用。
讀者可能會(huì)感到很奇怪，為什么如此成熟的技術(shù)防火墻不采用，而讓ddos廠商成天擠對(duì)？這有如下幾個(gè)方面的原因：
1:防火墻也用syn cookie進(jìn)行synflood防御的，但大多不是靜態(tài)syn cookie，而是嚴(yán)格記錄連接狀態(tài)采用動(dòng)態(tài)syn cookie，所以當(dāng)syn flood攻擊時(shí)不光消耗CPU，還要消耗大量?jī)?nèi)存。這也就是我本文開(kāi)頭提及的本方法可以攻擊大部分ddos廠商和小部分防火墻廠商的原因。
2:syn cookie/syn proxy是bsd系統(tǒng)內(nèi)核源碼的一部分，在Linux最新版的2.6內(nèi)核中syn proxy還沒(méi)有被包含。所以ddos設(shè)備也大多由bsd系統(tǒng)組成。當(dāng)然bsd是開(kāi)源的，移植也不是什么大問(wèn)題嘍。
3:防火墻大多以Linux下的開(kāi)源軟件netfilter為基礎(chǔ)，但netfilter中hash算法和連接表設(shè)計(jì)不是很優(yōu)秀，防火墻轉(zhuǎn)發(fā)性能的瓶頸就在于此，如果再加入syn proxy表項(xiàng)，會(huì)進(jìn)一步降低對(duì)數(shù)據(jù)包的處理能力或加大連接表體積。高端防火墻大都支持?jǐn)?shù)百萬(wàn)的連接數(shù)，這百萬(wàn)的表項(xiàng)就夠防火墻喝一壺的了，再加一個(gè)syn proxy表項(xiàng)，性能還不得掉的稀里嘩拉的？
4:防火墻很重要的一個(gè)網(wǎng)絡(luò)功能就是DNAT，在沒(méi)有DNAT操作前，防火墻不知道這些syn包的最終目的地是自身還是DMZ區(qū)的服務(wù)器，所以syn包必須DNAT后才知道是否要進(jìn)行syn cookie保護(hù)。但這時(shí)就已經(jīng)進(jìn)入到netfilter處理框架了，性能當(dāng)然就跟不上了。你見(jiàn)過(guò)幾個(gè)ddos設(shè)備支持NAT的？如果支持了，他的性能也會(huì)下降不少。如果防火墻工作在橋模式下，不經(jīng)過(guò)netfilter處理框架，防火墻就可以搖身一變成為性能卓越的抗ddos設(shè)備了，嗎功能都沒(méi)有，當(dāng)然一身輕松了。呵呵…但您買(mǎi)的是防火墻，會(huì)這么大材小用嗎？
言歸正傳，采用靜態(tài)syn cookie的ddos設(shè)備，我們只需要重放一個(gè)ack包就可以達(dá)到與服務(wù)器的三次握手效果，因此可以做到源IP地址偽裝。（這個(gè)偽裝的源IP地址是你以前用過(guò)的，并且與ddos設(shè)備通訊過(guò)，并保存下來(lái)的，現(xiàn)在將它重放而己。如果你看不懂我在說(shuō)什么，參照我寫(xiě)的《對(duì)國(guó)內(nèi)ddos廠商技術(shù)點(diǎn)評(píng)》一文，抓包分析一下就知道了）。第二步就是發(fā)送一個(gè)正常的http request請(qǐng)求，隨后就是大量的虛假ack請(qǐng)求重傳。
天知道，誰(shuí)在用我們偽裝的源IP地址，做為一個(gè)連帶的犧牲品。
你可能會(huì)認(rèn)為受害服務(wù)器B會(huì)回復(fù)rst包給受害服務(wù)器A。這是有可能，但如果服務(wù)器B前面加裝了一個(gè)“狀態(tài)檢測(cè)”防火墻，就會(huì)直接丟棄這個(gè)反射的http response數(shù)據(jù)包。



文章收錄到本人blog中了，歡迎大家討論。
                                                                   2006-05-12 15:50
                                                                                                            skipjack
2006-05-16 9:09


本思路有價(jià)值的地方：
1. 利用一條合法連接，對(duì)服務(wù)器進(jìn)行下行帶寬攻擊，現(xiàn)在的“狀態(tài)檢測(cè)”設(shè)備不一定可以發(fā)現(xiàn)
2. 目標(biāo)服務(wù)器應(yīng)用層程序感知不到這種攻擊，可以逃避基于應(yīng)用層流量統(tǒng)計(jì)的防御方式，因?yàn)橹貍魇荰CP協(xié)議特性，TCP協(xié)議自動(dòng)完成。重傳的數(shù)據(jù)包，對(duì)應(yīng)用層來(lái)說(shuō)是透明的。
3. 現(xiàn)在只是一種思路，不局限于TCP協(xié)議。UDP加入重傳機(jī)制后，也可以保證通訊可靠性。并且這是私人或公司獨(dú)立開(kāi)發(fā)的協(xié)議，漏洞會(huì)比TCP協(xié)議更大。
4. drdos的帶寬放大效果也只不過(guò)是6倍而己，并且消耗的是上行帶寬。
5. 真正的威脅不在現(xiàn)在，而是在對(duì)“長(zhǎng)肥管道”的攻擊效果。對(duì)方下行帶寬越寬，攻擊效果越明顯。TCP會(huì)禁用分片，所以重傳數(shù)據(jù)包大小依靠你與服務(wù)器之間最小的那個(gè)設(shè)備的MTU值，所以你見(jiàn)到的TCP協(xié)議的IP首部中的長(zhǎng)度字段不會(huì)超時(shí)1518。但在“長(zhǎng)肥管道”中，IP首部的長(zhǎng)度字段會(huì)達(dá)到65535的極大值，對(duì)這些數(shù)據(jù)包的重傳攻擊，會(huì)達(dá)到令人吃驚的1:1024的放大效果。
1M對(duì)1G
1G對(duì)1T
明白？就是因?yàn)檫@點(diǎn)，我才會(huì)提供本思路，否則1:25的消耗也是蠻力。

攻擊完善的TCP協(xié)議其實(shí)是很困難的：
1.具體可以參見(jiàn)RFC2581中關(guān)于Fast Retransmit/Fast Recovery的說(shuō)明部分。
2.你的ack包構(gòu)造不好，服務(wù)器協(xié)議棧還是會(huì)利用超時(shí)重傳，而不是快速重傳。


[ 本帖最后由 skipjack 于 2006-5-16 11:27 編輯 ]

Jambo

關(guān)注~！

在詳細(xì)些吧

skipjack

原帖由 Jambo 于 2006-5-12 16:49 發(fā)表
關(guān)注~！

在詳細(xì)些吧

補(bǔ)齊原理部分的說(shuō)明了，累死了

skipjack

有人看沒(méi)人回，為什么？
這是一種可以穿過(guò)防火墻對(duì)保護(hù)服務(wù)器進(jìn)行的帶寬攻擊方式，原理上對(duì)ddos保護(hù)下的服務(wù)器威害更大。
大家是感覺(jué)可行性不高，還是沒(méi)看懂啥意思呢？

playmud

那么是否可以做帶偽源地址的Blind TCP three-time handshakes和插入
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
我覺(jué)得不太可能吧，服務(wù)器端會(huì)對(duì)沒(méi)有記錄的ip進(jìn)行這種操作？
看了第一段描述，好像是告訴服務(wù)器數(shù)據(jù)沒(méi)有到達(dá)，讓其重發(fā)，這樣似乎還是蠻力，雖然以小數(shù)據(jù)包換得大數(shù)據(jù)包，但似乎不太有用，先去吃飯，回來(lái)再仔細(xì)看看。

teczm

原帖由 skipjack 于 2006-5-15 11:35 發(fā)表
有人看沒(méi)人回，為什么？
這是一種可以穿過(guò)防火墻對(duì)保護(hù)服務(wù)器進(jìn)行的帶寬攻擊方式，原理上對(duì)ddos保護(hù)下的服務(wù)器威害更大。
大家是感覺(jué)可行性不高，還是沒(méi)看懂啥意思呢？

沒(méi)看懂 慚愧

playmud

重新看了一遍，和上面看的差不多。
感覺(jué)沒(méi)什么實(shí)用價(jià)值。

playmud

syn flood的價(jià)值在于服務(wù)器端的timeout消耗的資源，和偽造source address.她發(fā)一個(gè)包過(guò)去，你那邊就要等，就要消耗資源，而攻擊方則輕松多了。

skipjack

原帖由 teczm 于 2006-5-15 12:37 發(fā)表

沒(méi)看懂 慚愧

其實(shí)ack包的作用就是發(fā)送錯(cuò)誤的TCP確認(rèn)序號(hào)，這就是為什么管它叫“序號(hào)亂刀”的原因。
呵呵...舉個(gè)例子，兩個(gè)人打招乎：

A君：你好
B君：你也好
A君：你吃了嗎？
B君：吃了呀
A君：你能把昨天的工作以流水賬的形式給我口述一遍嗎？
B君：當(dāng)然可以嘍，我：“早晨8點(diǎn)起床...9點(diǎn)到公司...10點(diǎn)寫(xiě)文檔...11點(diǎn)吃飯...下午....晚上17:30回家”（共說(shuō)了千八百字）
A君：不好意思，沒(méi)聽(tīng)清楚，再來(lái)一遍。
B君：OK，我：“早晨8點(diǎn)起床...9點(diǎn)到公司...10點(diǎn)寫(xiě)文檔...11點(diǎn)吃飯...下午....晚上17:30回家”（又說(shuō)了千八百字）

A君：沒(méi)聽(tīng)清楚，再來(lái)一遍。
B君：OK，我....8點(diǎn)
A君：沒(méi)聽(tīng)清楚，再來(lái)一遍。
B君：OK，我....9點(diǎn)
A君：沒(méi)聽(tīng)清楚，再來(lái)一遍。
B君：OK，我....10點(diǎn)
A君：沒(méi)聽(tīng)清楚，再來(lái)一遍。
B君：OK，我....11點(diǎn)
A君：沒(méi)聽(tīng)清楚，再來(lái)一遍。
B君：OK，我....12點(diǎn)
A君：沒(méi)聽(tīng)清楚，再來(lái)一遍。
B君：OK，我....13點(diǎn)
A君：沒(méi)聽(tīng)清楚，再來(lái)一遍。
B君：OK，我....14點(diǎn)
A君：沒(méi)聽(tīng)清楚，再來(lái)一遍。
B君：OK，我....15點(diǎn)
A君：沒(méi)聽(tīng)清楚，再來(lái)一遍。
B君：OK，我....16點(diǎn)

A君：還是沒(méi)清楚，再來(lái)一遍。（真是個(gè)傻冒�。�
B君：.......（冒煙中ing）

skipjack

原帖由 playmud 于 2006-5-15 13:10 發(fā)表
syn flood的價(jià)值在于服務(wù)器端的timeout消耗的資源，和偽造source address.她發(fā)一個(gè)包過(guò)去，你那邊就要等，就要消耗資源，而攻擊方則輕松多了。

我這個(gè)和syn flood沒(méi)有任何相似性，syn flood對(duì)于ddos設(shè)備來(lái)說(shuō)威害和ping flood差不多。它們同屬1:1的資源消耗。而作者文章本意也不是這個(gè)意思。作者想通過(guò)猜測(cè)序號(hào)的方式來(lái)劫持TCP會(huì)話，然后再利用CC原理進(jìn)行1:N的CPU資源消耗。
我的修改建議是：不猜序號(hào)僅利用握手的ACK包重放，而輕松做到1:N的帶寬消耗。威力雖然減小了，但可行性已大幅提高。