Sbíráme otisky: metody

V diskusi pod prvním dílem jste se vyjádřili, že chcete jít více do hloubky. Dobrá tedy, podíváme se zblízka na některé možnosti sledování stop a konkrétní ukázky si necháme na později, nikam nám neutečou.

Obecně

Existuje celá řada technik určených k rozpoznávání operačních systémů na vzdálených počítačích. Program, který je implementuje, ovšem musí vykazovat jistou dávku inteligence. Není pochopitelně možné ani nutné vyzkoušet všechny metody najednou.

Obvykle postačí několik pokusů k tomu, abyste rozeznali přibližnou rodinu systémů a určili, zda se jedná o Solaris, Linux, MS Windows nebo třeba nějaké BSD. Pak už jen několika cílenými dotazy zjistíte zbytek, tedy konkrétní verzi nebo skupinu. Mnoho testů ani nepotřebuje aktivní účast scanneru, ale vyhodnocují se průběžně s ostatními. Příkladem je například zjištění hodnoty IPID nebo inicializačního TCP okna.

Obvykle se tedy postupuje od obecného ke konkrétnímu, podobně jako při určování rostlin podle klíče. Bohužel ne vždy se vám podaří tímto způsobem zjistit naprosto přesnou verzi systému. V případě, že se několik verzí TCP stack výrazně neměnil, není podle čeho verze rozeznat.

Problém to nebývá u systémů jako jsou MS Windows, které se od sebe docela podstatně liší, což je dáno jednak pokrokem, ale také velmi dlouhým vývojovým cyklem, kdy je podstatná část systému přestavěna.

Naopak například u Linuxu, kde probíhá vývoj velmi překotně, se můžete často dozvědět, že na druhé straně běží Linux 2.1.122 – 2.2.16. Konkrétní výsledek také záleží na nastavení firewallu a mnoha dalších okolnostech. O tom, jak testy oblafnout, si budeme určitě povídat někdy příště, protože se jedná také o velmi zajímavé téma.

Konkrétně

O první metodě jsem se už zmínil, ale pro úplnost ji zopakuji:

Paket FIN

Systému se pošle FIN paket, nebo jiný, který neobsahuje SYN/ACK flag. Podle RFC by systém neměl zareagovat, ale některé špatně napsané systémy pošlou zpět RESET. Zužuje se nám tak množina možných systémů na MS Windows, BSDI, CISCO, HP/UX, MVS a IRIX.

TCP ISN Sampling

Další používaná metoda je založena na zkoumání inicializační sekvence TCP. Každý systém má určitou metodu, kterou používá při vymýšlení ISN (Initial Sequence Number). Podle regulí by se toto číslo mělo generovat náhodně, ale znáte to. Myšlenka je tedy následující: Uděláme několik spojení, zapamatujeme si hodnotu ISN a najdeme mezi nimi podobnost. Můžeme zjistit zhruba toto:

• Tradiční 64K (staré Unixy)
• Náhodné navyšování (Solaris, IRIX, FreeBSD a další)
• Skutečně náhodné (Linux, OpenVMS, AIX a další)
• Časově závislé – po určitém čase se samy konstantně zvyšují (MS Windows)
• Pořád stejné (ano, i taková zařízení existují)

Nutno poznamenat, že poslední dvě možnosti jsou skutečně hloupé, protože je možno poměrně snadno odhadnout aktuální okno a velmi lehce provozovat TCP injection a jiné veselé hrátky s pakety.

Hodnota IPID

Pakety jsou označovány identifikační hodnotou IPID, která se obvykle v závislosti na čase mění. Většina systémů to dělá jednoduše tak, že zvýší tuto hodnotu pro každý paket, který pošle, o 1. Některé systémy (třeba OpenBSD) ovšem generují IPID náhodně nebo jej zvyšují o jinou hodnotu. MS Windows například zvyšují po 256. Jelikož je IPID naprosto veřejně odesílán do světa, je možno podle něj velmi dobře určit skupinu systémů.

Odbočka: Zombie scan

Ještě se zmíním o jedné velmi zajímavé možnosti skenování, které se často říká Zombie scan nebo Idle proxy. Neslouží k přímému fingerprintingu, ale k oťukávání stroje a má přímou návaznost na předchozí IPID test. Navíc vás jistě potěší závěrečná pointa.

Princip je poměrně jednoduchý, ale velmi vtipný a účinný. Využívá metody postranních kanálů ke zjišťování informací přes prostředníka. V síti si vyhlédneme jednu oběť, která bude naší zombie. Mělo by to být zařízení, které není příliš vytížené, aby nedocházelo ke zkreslování údajů.

Nejprve od zombie zjistíme aktuální hodnotu IPID a tu si zapamatujeme. Pak odešleme paket na cílové zařízení, které nás zajímá, ale u paketu zfalšujeme odesílatelovu adresu tak, aby to vypadalo, že se ptá naše zombie. V běžné situaci bychom samozřejmě odpověď nedostali, ale my víme, že pokud je náš cílový port otevřen, odpoví počítač paketem SYN/ACK a bude se snažit se zombie pokračovat v komunikaci. Zombie ovšem nic takového nechce a tak odešle zpět RST, aby zrušila žádost. Tím se jí ovšem také navýší IPID, který my opět přímo u zombie ověříme.

V případě, že je cílový port uzavřen, odešle dotazované zařízení RST, na který zombie nijak nezareaguje a my zjistíme, že se mezi našimi dvěma dotazy IPID nezměnil.

Takový postup má také svou další praktickou výhodu: Celá akce je velmi dobře maskovaná a pokud někdo sleduje provoz, bude to vypadat, že se zombie a cíl vzájemně skenují. :-)

Inicializační okno TCP

Další zajímavý test sleduje velikost oken v paketech odesílaných cílovým strojem. Z ní je možno zjistit překvapivě mnoho informací. Například v novějších MS Windows je nastaveno okno na 0×402E, stejně jako v OpenBSD nebo FreeBSD. AIX zase používá 0×3F25.

Hrátky s ICMP

ICMP pakety mohou být obecně velmi slušným zdrojem informací. RFC například udává, jak mají vypadat chybové hlášky zasílané systémem. V případě požadavku na nedostupný port posílá většina implementací zpět IP hlavičku a osm bytů dat. Například Solaris ale posílá i data navíc a Linux jich posílá ještě mnohem víc. Je to jednoduchá možnost, jak rozeznat Linux a Solaris i v případě, že jsou všechy cílové porty uzavřeny a není s kým komunikovat.

Dalším využití ICMP vychází z RFC 1812, které navrhuje omezení zasílání chybových hlášení. Linux například omezuje generování těchto chybových paketů na 80 za čtyři sekundy. Při překročení této hranice navíc trestá odesilatele 250 ms nečinnosti. Stačí tedy v krátkém časovém úseku odeslat hromadu paketů na neexistující UDP port a počítat odpovědi.

Poslední hrátkou s ICMP, o které se zmíním, je sledování TOS (Type Of Service) příznaku v chybovém hlášení. Obvykle je nastavená nula, ale Linux nastavuje tento příznak na 0×C0. Další z možností, jak ho odhalit.

SYN Flood

Některé chytřejší systémy se snaží předcházet DoS útokům a jiným problémům tím, že omezují počet zaslaných SYN paketů. Pokud je jich moc, systém na nějakou dobu odmítne sestavit další spojení. Mnoho systémů přijme maximálně osm SYN paketů. Stačí tedy poslat osm žádostí o spojení a pak sledovat, jak douho bude trvat obnovení standardního stavu.

Závěrem

Určitě se nejedná o kompletní výpis všech možností, ale většina těch zajímavých a podstatných popsaná byla. Minimálně by měly stačit k tomu, abyste získali obrázek „jak se to asi dělá”.