Hlavní navigace

Resetovací útoky na TCP spojení

2. 2. 2007
Doba čtení: 9 minut

Sdílet

 Autor: 29
V dnešním článku se podíváme, jak lze na dálku resetovat již vytvořené TCP spojení pomocí protokoů TCP a ICMP a jak se standardně ukončuje TCP spojení. Tento článek by měl být srozumitelný i uživatelům méně pokročilým v oblasti sítí.

Po delší odmlce jsem si pro vás připravil další článek zabývající se sítěmi a bezpečností. Tentokrát se podíváme na téma, které jsem vám již dříve sliboval, a to na útoky zaměřené na resetování TCP spojení. Probereme si základní teorii, která nám poslouží k lepšímu pochopení souvislostí; tento článek bude využívat některých znalostí získaných z článku Jak unést TCP spojení.

Ještě než se pustíme do vysvětlování, chtěl bych vám připomenout, že zkoušení těchto útoků proti cizím počítačům nebo uživatelům může být trestné a přinejmenším je neetické. Pokud nemáte dostatek vlastních počítačů, pak vám doporučuji použit nějaké virtualizační nástroje (například Vmware).

Teorie

O co se jedná?

Útok spočívá v přerušení již navázaného TCP spojení mezi dvěma počítači. K tomuto přerušení nám stačí znát IP adresy obou počítačů, použité porty a v horších případech potřebujeme znát sekvenční čísla.

Tento útok se hodí, pokud chceme sabotovat (přerušovat) cizí komunikaci. Například pokud odposloucháváme data na síti takovým způsobem, že je nemůžeme modifikovat, nebo když vůbec nevidíme data v síti, a nemáme tudíž jinou možnost manipulace s daty.

Aktuálnost útoku?

Útok si popíšeme pomocí TCP protokolu i pomocí protokolu ICMP. V současné době je většina systémů proti útoku pomocí ICMP protokolu chráněna (útok ovšem není vyloučen). Informace o tom, které systémy byly postiženy a jak to je s jejich opravami, najdete na stránkách serveru XForce. Nás nejspíše bude zajímat, jaká je současná situace u operačních systémů Microsoft Windows. U všech postižených operačních systémů Windows byla chyba opravena v dubnu 2005, podrobněji o tom píše Microsoft Security Bulletin MS05–019. Ovšem u operačních systémů Windows 98, 98 Second edition a Millenium edition tato chyba opravena nebyla, jelikož nebyla shledána kritickou. Postižena je i většina neupdatovaných operačních systémů Microsoft Windows, a to kvůli tomu, že mnoho lidí a firem neprovádí aktualizace. To udržuje tento útok stále mezi použitelnými.

Normální ukončení TCP spojení

Pro osvěžení znalostí si připomeneme, že TCP spojení se skládá ze tří fází – první fází je navazování spojení, následuje komunikace, a poslední fází je ukončování spojení. Pro snadnější pochopení jsem pro vás opět připravil obrázek; doufám, že se bude líbit.

TCP spojení

V levé části máme nakresleno, jak vypadá TCP spojení, jak jsem popisoval výše, v pravé části máme detailní pohled na to, jak vypadá ukončování TCP spojení. Jednotlivé body dále ještě popíšu. Fázi zahajování TCP spojení jsem popisoval v článku Jak unést TCP spojení.

Ještě bych chtěl znovu připomenout, co znamenají ony moje magické zkratky SČOB a SČPB. SČOB je zkratka ze spojení sekvenční číslo odesílaného bytu, v programech bývá pojmenováno jako sekvenční číslo (sequence numer a nebo pořadové číslo odesílaného bytu), a vyjadřuje pořadové číslo prvního bytu v datové části TCP segmentu (paketu) v toku dat od odesílatele k příjemci. Zkratka SČPB znamená sekvenční číslo přijatého bytu, v programech se používá acknowledgment number, a vyjadřuje pořadové číslo bytu, který je klient nebo server připraven přijmout (potvrzuje se jím, až po jaký byte byla data přijata). Pokud je to pro vás moc zamotané a nevíte, jak to se sekvenčními čísly je, tak doporučuji už několikrát zmiňovaný článek o únosu TCP spojení, kde jsem se touto problematikou zabýval více.

  1. Klient posílá serveru segment s příznakem FIN (finish), kterým říká, že už odeslal vše, co potřebuje. Tomuto kroku se říká aktivní uzavření. Ovšem tento krok neuzavírá celé spojení, ale jak víte, spojení je obousměrné, to znamená, že klient tímto krokem uzavírá pouze spojení pro přenos dat z klienta na server. Od této chvíle je u klienta spojení v tzv. stavu FIN_WAIT1. Nemusí to samozřejmě být klient, kdo bude provádět krok číslo 1, může to být i opačně.

    Další zajímavostí je, že i když tento segment nenese žádná data, tak má přesto délku 1 byte – je to z toho důvodu, že nastavení příznaku SYN nebo FIN vede zároveň k nastavení délky segmentu na 1, aby následně druhá strana mohla potvrdit, že přijala tento segment.

  2. V tomto kroku server potvrzuje klientovo přání uzavřít spojení pomocí TCP segmentu s příznakem ACK a správným SČPB. Server také změní stav tohoto spojení (u sebe) do stavu CLOSE_WAIT.
  3. Od této chvíle mohou aplikační data proudit pouze od serveru ke klientovi. Klient pouze potvrzuje příjem těchto dat (takto by to mělo být, tím, jak je to v praxi, si nejsem jist :-)). Příznakem PSH by měla být označována aplikační data, ovšem v praxi se to příliš nepoužívá. V tomto kroku posílá server 120 bytů aplikačních dat (pouze pro ilustraci).
  4. Klient potvrzuje přijetí těchto dat, takto by mohla pokračovat komunikace dále.
  5. Server již také nemá žádná data k poslání, proto posílá TCP segment s příznakem FIN, čímž ohlašuje konec spojení. Spojení se u serveru přesouvá do stavu LAST_ACK. Čeká na potvrzení právě odeslaného segmentu, a následně uzavře spojení.
  6. Klient potvrzuje přijetí segmentu,odesláním segmentu s příznakem ACK, spojení nechá chvilku čekat, a následně zruší všechny alokované zdroje a spojení je ukončeno.

Takto vypadá uzavření spojení, v praxi se můžete například setkat s tím, že v bodě 5 se pošle pouze TCP segment s příznaky RST a ACK, čímž se spojení ukončí rychleji.

ICMP Resetovací útok (Blind connection-reset attack)

O co se jedná?

Tento útok využívá k resetování TCP spojení protokol ICMP. Jak jsem se již zmínil výše, je tento útok použitelný proti některým nezáplatovaným (neupdatovaným) operačním systémům Microsoft Windows a i plně záplatovaným operačním systémům Microsoft Windows 98, 98 Second edition a Millenium edition.

Co je potřeba znát před provedením útoku?

Útok spočívá v prostém poslání ICMP paketu oběti. Při tom je potřeba znát IP adresu a TCP port (který používá ke komunikaci) oběti, IP adresu serveru/klienta, se kterým komunikuje, a jeho využívaný port. Pokud se podíváme na tyto požadavky, pak je nám jasné, že IP adresa oběti je jasná, stejně tak jako IP adresa a port serveru/klienta, se kterým oběť komunikuje (jelikož rušíme pouze konkrétní spojení). Jediná neznámá je pro nás port oběti. Jelikož je počet TCP portů pouze 65536, není problém vyzkoušet všechny. Naštěstí máme ale práci ulehčenou, pokud totiž víme, o jakou komunikaci se jedná (FTP, WWW, POP3), pak se porty vybírají vždy z určitého rozsahu (závisí na operačním systému nebo programu), tento rozsah bývá „pouze“ pár stovek portů, u některých služeb jsou dokonce známy oba porty (port klienta i port serveru).

Jaké ICMP zprávy se používají?

Ještě jsem vám ale neprozradil to nejdůležitější, a to je, jakou ICMP zprávu máme poslat. Na stránkách organizace IANA naleznete výpis všech možných ICMP zpráv. K tomuto útoku se používají zprávy „protokol nedostupný“ (typ 3 kód 2), „port nedostupný“ (typ 3 kód 3) a „fragmentování potřebné, ale nastaven bit nefragmentovat“ (typ 3 kód 4).

Co provede oběť po obdržení této zprávy a současná obrana?

Jakmile oběť dostane takovouto zprávu, znamená to, že v komunikaci se vyskytla závažná chyba (hard error) a spojení je ukončeno. Takto funguje náš útok. Tento útok vznikl kvůli špatné implementaci v některých operačních systémech, jelikož by správně měly kontrolovat sekvenční čísla, což ovšem nedělaly. Nyní už jsou operační systémy zabezpečeny právě tím, že kontrolují sekvenční čísla, a bylo provedeno ještě další zabezpečení týkající se kontroly výskytu těchto zpráv v souvislosti se stavem, v jakém se TCP spojení nachází, což pro nás činí tento útok nepoužitelným. Souvislost se stavy je myšlena tak, že pokud je TCP spojení ve stavu „navázáno“ (connected) a probíhá komunikace, je divné, když nám přijde ICMP zpráva oznamující, že cílový port je nedostupný.

Pokud si říkáte, jak se v ICMP zprávě vezme IP adresa a porty, tak je to jednoduché. Samozřejmě nejvyšším protokolem je protokol ICMP, který ovšem ve své datové části obsahuje IP a TCP hlavičku paketu, který vyvolal tento ICMP paket.

Program a užitečné odkazy

Jestliže vás tento útok zaujal, můžete si ho zkusit například pomocí programu icmp-reset (Linux), který má velice jednoduché ovládání, nebo doporučuji Hakin9 Live CD, které tento program obsahuje i s podrobným návodem k tomuto útoku v češtině. Pokud toto CD ještě nemáte, pak doporučuji stáhnout, jelikož to vypadá, že Hakin9 ho již nechce distribuovat dále zdarma. Dále doporučuji dokument o ICMP útocích od Fernanda Gonta, kde je popisován i tento útok.

SYN a RST resetovací útoky

O co se jedná?

Zde to bude trošku stručnější, oba dva útoky používají pro resetování TCP protokol. Princip je zde jednoduchý, pokud některá strana obdrží TCP segment s příznakem RST, pak se spojení ukončí. V případě segmentu s nastaveným příznakem SYN se spojení také ukončí, jelikož se jedná o závažnou chybu (SYN příznak se objevuje pouze ve fázi vytváření spojení).

Co je potřeba znát pro provedení útoku?

Aby vše nebylo tak jednoduché, potřebujeme zde znát opět obě IP adresy a oba TCP porty, krom toho je potřeba znát správné sekvenční číslo bytu, který oběť očekává, a jelikož sekvenční číslo je čtyřbytová hodnota, jak jsme si již řekli v jiných článcích, je rozsah opravdu velký. V současné době, kdy jsou systémy záplatovány, je třeba znát obě sekvenční čísla (SČOB, SČPB). Dříve se kontrolovalo pouze, zda příchozí data patří do intervalu očekávaných dat.

Situaci nám také usnadňují principy fungování TCP protokolu, kde se používá tzv. okno k odesílání dat. Ve zkratce se jedná vlastně o to, že můžeme najednou poslat více dat, aniž bychom čekali, než nám protějšek potvrdí příjem předchozích dat. Podrobné popisování by vydalo na samotný článek, já vás zde odkáži pouze na anglickou příručku TCP/IP Guide nebo výborný dokument pojednávající o resetovacích útocích pomocí TCP protokolu Slipping In the Window [DOC, 3,1 MB]. Dokument obsahuje výsledky pokusů o útok a spoustu čísel (velikosti oken u různých operačních systémů, dobu potřebnou pro útok atd.), a pokud vás toto téma zaujalo, pak ho vřele doporučuji pročíst.

Jak nám pomáhá okno (TCP Window)?

Okno, o němž jsem se zmiňoval o odstavec výše, nám usnadňuje uhodnutí sekvenčního čísla, jelikož nám stačí, abychom se pouze trefili do tohoto okna. Velikost okna se pohybuje v řádech kB, což znamená, že počet možných hodnot sekvenčních čísel se sníží na řády deseti tisíců, což už je daleko lepší než původní miliardy. Přičemž paket, který posíláme, má velikost cca 50 byte, linka o šířce pásma 1 Mbit/s nám tedy umožní odeslat cca 2560 takových to paketů. Útok by nám mohl zabrat průměrně cca 14 s (pokud bude velikost okna 65536 B a budeme znát obě IP adresy a porty).

BRAND24

Program a užitečné odkazy.

Pro tento útok můžete použít programu reset-tcp, který je distribuován ve zdrojovém kódu. Dále doporučuji přečíst si výše zmiňovaný dokument Slipping In The window [DOC, 3,1 MB] a článek Understanding TCP Reset Attacks.

Závěr

Doufám, že jsem vás dnešním článkem, který obsahuje trošku více teorie, nezklamal. Jedná se o poměrně složité téma, které jsem nenastínil příliš hluboce, díky čemuž by mělo být srozumitelné i nepříliš pokročilým uživatelům. Těm z vás, kdo máte rádi podrobnosti, doporučuji prohlédnout si odkazy, které jsem v průběhu článku uváděl, jelikož v nich najdete vše, co by vás mohlo okolo tohoto tématu zajímat. Bohužel jsou veškeré odkazy v angličtině, ale z výsledků předchozí ankety vyplynulo, že téměř všichni ovládáte angličtinu, takže by to pro vás nemusel být problém. Pokud jsem se dopustil někde v článku věcné chyby, budu rád, když mě v názorech pod článkem opravíte.

Považujete takovéto články za možnou hrozbu?

Byl pro vás článek přínosný?

Autor článku

Autor je spolumajitelem firmy PATRON-IT a celým srdcem technik. Specializuje se na kybernetickou bezpečnost a má zkušenosti etického hackera. Věří, že aby mohl síť dobře zabezpečit, musí ji nejprve umět prolomit.

Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).