Možnosti útočníků a virů v IPv6 sítích Kamil Okáč Vysoká škola ekonomická Praha
[email protected]
Abstrakt Protokol IPv6, nástupce IPv4, si pomalu nachází cestu ke stále většímu počtu uživatelů. Jeho rozšíření s sebou logicky přináší bezpečnostní rizika, která nemusí plynout pouze ze specifik IPv6, ale mohou být pouhým přizpůsobením známých postupů útoků novým podmínkám, kdy útočník může těžit z nezkušenosti uživatelů či absence obranných prostředků. Právě těmto „starým známýmÿ bude věnován tento příspěvek, s konkrétním zaměřením na následující: (1) „Zmapování trhuÿ rootkitů (pro platformy Linux a Windows) s cílem zjistit, zdali některé podporují vzdálené backdoory skrze IPv6 a zda jsou schopny tato IPv6 spojení tajit před uživatelem; pokud podpora IPv6 chybí, zjistit náročnost úprav, nutných pro funkčnost pod IPv6. (2) Možnosti šíření virů (resp. červů typu W32.Blaster) v IPv6 Internetu — jak (a jestli vůbec) mohou červi řešit problémy, které by jim vyvstaly při použití IPv6 (především „řídkýÿ adresní prostor IPv6). (3) Popdpora IPv6 u síťových nástrojů a firewallů.
IPv6 je nástupcem současného internetového protokolu IPv4. Jeho smyslem je řešit problémy a nedostatky IPv4, které jsou v poslední stále citelnější. Mezi ně patří především nedostačující adresní prostor (a s tím související potíže s NATy a privátními adresami), potřeba vyšší bezpečnosti či mobility. Jelikož se IPv6 začíná pomalu rozšiřovat i k běžným uživatelům, nastává ten pravý čas začít pátrat, zdali se o tento protokol zajímá i blackhat komunita a zda a jak jej může využít pro své nekalé praktiky. Příspěvek se nebude věnovat samotnému návrhu IPv6 protokolu, ale spíše zkoumat, jaké prostředí poskytuje IPv6 pro současné problémy — bude se tedy věnovat internetovým červům, rootkitům, síťovým nástrojům či firewallům. Od čtenáře předpokládá alespoň základní povědomí o IPv6 (struktura a rozdělení IPv6 adres, jejich přidělování, konfigurace uzlů a objevování sousedů). V případě zájmu doporučuji českou publikaci IPv6 od RNDr. Pavla Satrapy[1].
1
Šíření červů v IPv6 sítích
V posledních několika letech zažívají nečekaný rozmach síťoví samoreplikující se intruzivní agenti — síťoví červi. Ačkoliv první červ byl stvořen již v roce 1978 ve výzkumném ústavu firmy XEROX a vetší pozornost vzbudil až červ Morris v roce 1988 [2], je to právě asi posledních 5 let, kdy se z červů začíná stávat skutečný problém a díky jejich činnosti vznikají nemalé škody. Proč tomu tak je? Hlavní příčinou je jistě dostatečná „živná půdaÿ pro šíření červů — počet zařízení, připojených k Internetu (a tedy i potenciálních obětí), se neustále zvyšuje, navíc u koncových stanic panuje silná homogenita operačních systémů, což je pro autory červů jistě dobrá zpráva. Vzhledem k tomu, že IPv6 si pomalu hledá cestu až na naše stoly a blackhat komunita nespí, nebude jistě úplně od věci položit si otázku, jak se červi dokážou s novým protokolem vyrovnat. IPv6 na jednu stranu předpokládá, že každé zařízení bude mít globální, veřejně dostupnou adresu (nebo dokonce adres několik), což pro červy znamená více možných obětí, na straně druhé je adresní prostor IPv6 natolik obrovský (79 228 162 514 264 337 593 543 950 336x vetší, než prostor IPv4), že se z vyhledávání možných hostitelů stává základní problém. 1.1
Hledání hostitelů „hrubou silouÿ
Všichni dosavadní IPv4 červi, vyhledávající nové oběti, postupovali vetšinou metodou hrubé síly — náhodným scanováním celého IPv4 prostoru. Při simulaci tohoto chování bylo dosaženo přibližně 3% pravděpodobnosti nalezení dosažitelného hostitele, mezi kterými bylo možno přibližně u jedné třetiny identifikovat operační systém Windows. Budeme-li tedy předpokládat, že červ je schopný scanovat 1000 IP za sekundu (čehož se na dnešních linkách dá bez problémů dosáhnout), pak během jedné minuty má 600 potenciálních obětí. Jak by takový červ dopadl, kdyby se o totéž pokoušel v IPv6 internetu? Pokud by scanoval náhodně celý 128bitový prostor, nepodařilo by se mu pravděpodobně nalézt ani jedno zařízení, i kdyby prohledával po celou dobu, co existuje vesmír. Zkusme tedy zmírnit svůj požadavek: dokážeme v rozumném časovém úseku prohledat alespoň nejmenší možný IPv6 segment (64bitů prefix, 64bitů identifikátor rozhraní)? Náš červ by v takovém případě musel odeslat
264 ICMP paketů o velikosti 74 oktetů (včetně ethernet a IPv6 hlaviček). Tím se dostáváme k zajímavému číslu 1184 Exbibytů (260 Bytů). Takový provoz je možno na 100Mbit síti odeslat přibližně za 3,4 milionu let (a to navíc v tomto případě nepočítáme s tím, že scanování probíhá znatelně pomaleji), což opět dalece přesahuje možnosti praktického využití. 1.2
Lokální segment — multicastová skupina všech uzlů
Zkusme tedy na to jít z druhé strany — jak si může červ pomoci, pokud se chce rozšířit po lokálním IPv6 segmentu? Zde má červ překvapivě situaci snažší, než na IPv4 síti (resp. měl by, pokud by byla dodržována RFC, viz dále). Každý IPv6 uzel musí být povinně členem lokální multicastové skupiny FF02::1, která nahrazuje broadcastové IPv4 adresy. Pokud je na tuto multicast adresu zaslán ICMP Echo Request (ping), tak (podle RFC 2463 [3]) by každý uzel měl odpovědět. Uzly tak skutečně číní, ovšem s výjimkou zařízení s Windows XP a nainstalovaným Advanced Networking Pack (což je doporučené rozšíření, vylepšující podporu IPv6). Tento totiž obsahuje IPv6 firewall, blokující — jak bývá u firewallů od MS zvykem — ICMP Echo Request/Reply. 1.3
Lokální segment — využití adresování dle schématu EUI-64
Další možností, která by mohla připadat v úvahu na lokálních IPv6 segmentech, kde se používá bezestavová autokonfigurace uzlů, je omezit prohledávání segmentu na IPv6 adresy, vytvořené pomocí schématu EUI-64 [4]. Taková IPv6 adresa je tvořena z prefixu sítě (64 bitů) a z 48-bitové MAC adresy daného rozhraní, doplněné o dalších 16 bitů (FFFE). Pokud navíc budeme předpokládat, že se na síti vyskytují síťové adaptéry několika málo výrobců (prvních 24bitů MAC adresy tvoří identifikátor výrobce [5], při testování bylo 70% adaptérů od 12 výrobců), můžeme počet testovaných adres snížit na 12 ∗ 224 , což je približně 200 milionů adres. Vzledem k tomu, že se jedná o lokální segment, je možné předpokládat vyšší rychlosti scanování, než v případě celého internetu (lokální síť mívá větší propustnost, nemusíme se obávat zahazování ICMP packetů směrovači)
— na 100Mbit síti lze dosáhnout desítek tisíc IP/s. Tímto tempem bychom scanováním 200 milionů adres strávili řádově jednotky hodin, což už pro autory červů může být alternativa ke zvážení. 1.4
Lokální segment — další možnosti
Jak ještě mohou zkusit červi hledat případné hostitele? Odchytáváním ICMP provozu — ICMP slouží např. pro autokonfiguraci uzlu či objevování sousedů — v takovém případě jsou ICMP pakety odesílány jako broadcasty (na linkové vrstvě) a červ tak může získat IP adresu zdroje i adresáta zprávy. Předpoklad lidského faktoru při přidělování adres. Poněvadž jsou IPv6 adresy znatelně delší, než stávající IPv4, dá se očekávat, že síťoví administrátoři budou některým uzlům nebo i celým segmentům přidělovat adresy tak, aby se jim snáze pamatovaly. Na mnoha segmentech tak můžeme nalézt router, který ma posledních 64 bitů nulových, či na konci adresy má nízké číslo (ve zkráceném zápisu vypadají takové adresy např. 2001:718:1e02:88:: nebo 2001:718:1e02::1). Něco podobného se dá očekávat i v sítích, kde nebude použita bezestavová autokonfigurace, ale DHCPv6 — zde budou často přidělovány stanicím adresy, odvozené z jejich IPv4 ekvivalentu. Červ, využívající těchto poznatků, by mohl v mnoha případech uspět, tento úspěch ale bude záviset na tom, jak dobře autor červu dokáže odhadnout způsoby přidělování IPv6 adres. „Prohlášením seÿ za směrovač — Červ může do sítě odesílat ICMP zprávu „ohlášení směrovačeÿ (Router advertisement, viz RFC2461 [6]) a tím se prohlásit za jeden z implicitních směrovačů pro daný segment. Uzly na této síti začnou napadenému stroji posílat provoz ke směrovaní, čímž červ získá jejich IP. Pokud červ poté odesílatele přesměruje ICMP zprávou „redirectÿ (RFC2461) na původní směrovač, nebo skutečně jako směrovač fungovat začne (v takovém případě má šanci získat více cílových adres), nebude síťový provoz nijak dotčen.
Využitím NDP cache a aktivních spojení — NDP (neighbor discovery protocol) je pro IPv6 to, co je pro IPv4 arp. Každý uzel si drží seznam IPv6 a jim odpovídajících MAC adres — tento seznam je přístupný skrze ’ndp -a’ a může být červem, stejně jako výstup z netstat, využit pro hledání obětí. 1.5
Hostitelé mimo lokální síť
V tuto chvíli tedy můžeme předpokládat, že se červ úspěšně rozšířil po lokálním segmentu. To ale jistě není to, s čím by se autor chtěl spokojit a bude hledat možnosti, jak se dostat ven. Jak již bylo zmíněno výše, slepé scanování celého adresního prostoru k cíli nepovede. Jistě by mohlo pomoci zůžení množiny adres způsobem, zmíněným v kapitole 1.3 (využití schématu EUI-64), tento způsob ale jednak předpokládá bezestavovou autkonfiguraci na vybraném segmentu, ale co hůře, řeší pouze posledních 64 bitů adresy (adresa rozhrání). Stále nám zbývá si tipnout 64bitový prefix sítě. Můžeme si vzít na pomoc seznam všech přidělených IPv6 prefixů [7] — tyto jsou převážně 32bitové, zbývají nám tedy násobky 56bitového prostoru (32 bitů z 64bitového prefixu a 24 z 64bitové adresy rozhraní). Není potřeba opakovat zběsilé výpočty k tomu, abychom zjistili, že je to opět příliš velké sousto. Je otázkou, do jaké míry by byl úspěšný postup červa, který by zkoušel trasovat spojení na adresu, tvořenou z prvních 32 bitů výběrem z RIPE databáze, dalších 32 bitů náhodných a libovolných posledních 64 bitů. V závislosti na konfiguraci směrovačů na cestě by červ při troše štestí měl šanci po relativně krátké době získat odpověď od směrovače, příslušícímu k 48 nebo dokonce 64bitovému segmentu. Na tomto segmentu potom může zkusit použít metodu z kapitoly 1.3, která může na dostatečně rychlé lince vést k uspokojivým výsledkům. Další alternativou bude jistě sledování aktivních spojení (netstat) — které by dle mého názoru mohlo být v budoucnu primárním zdrojem obětí. IPv6 totiž předpokládá (díky neexistenci privátních adres a NAT) mnohem vetší využití end-to-end konektivity (P2P aplikace, messengery, síťové hry) a dá se tedy očekávat, že počet aktivních spojení s globálními adresami bude vyšší, než v současné době na IPv4.
Červi také mohou zkusit k vyhledávání hostitelů či sítí využít některé další informace, uložené na napadeném stroji — např. hlavičky e-mailů, cache www browserů či logy serverových aplikací. Úspěch takových metod závisí na inteligenci červa při sbírání informací. V poslední řadě nemůžeme nezmínit šíření červů skrze e-mail, které díky důvěřivosti (hlouposti) uživatelů s námi bude asi již navždy, nezávisle na jakémkoliv novém protokolu. 1.6
Šíření červů — shrnutí
Obrovská velikost adresního prostoru IPv6 bude znamenat pro autory červů nemalý problém, nad kterým jistě stráví mnoho bezesných nocí. Nejedná se ovšem o problém zcela neřešitelný a nelze tedy očekávat, že červi díky IPv6 zcela vymizí. Jak tomu ovšem bude ve skutečnosti, na to bude potřeba počkat, až se IPv6 dostatečně rozšíří.
2
Rootkity a IPv6
Co je to rootkit? Rootkitem rozumíme nástroj (či sadu nástrojů), nainstalovaný útočníkem na napadený stroj a který poskytuje služby, jejichž cílem je především zamaskování přítomnosti útočníka a jeho nekalé činnosti. Často bývá doplněn o backdoor, umožňující vzdálený přístup ke stroji a tím obejít standardní přihlašování (např. skrze ssh). Proč se v současné době zabývat tím, jak jsou na tom rootkity s podporou IPv6? Důvod je ten, že IPv6 je nyní ve fázi, kdy se pomalu dostává až ke koncovým stanicím. Uživatelé s ním začínají experimentovat, ale chybí jim zkušenosti a, pro síťovou existenci tolik potřebná, paranoia. V některých případech mohou dokonce mít stanice IPv6 konektivitu, aniž by o tom uživatelé vůbec tušili. Zcela v bezpečí nejsou ani uzly na sítích, IPv6 nepodporujících, neboť útočníci mohou na napadeném stroji využít možnosti tunelování IPv6 provozu přes IPv4. 2.1
SucKIT
Rootkit pro linux, prezentovaný v #58 e-zinu Phrack [8], lišící se od vetšiny ostatních tím, že neinfiltruje kernel pomocí LKM (Loadable
Kernel Modules), ale skrze /dev/kmem (což může být výhodné např. tam, kde jsou LKM zakázány). Tento rootkit disponuje základními funkcemi, které od něj čekáme (schovávání souborů, procesů, síťových spojení a backdoor). Backdoor je implenetován jako „connectbackÿ: řídící spojení naváže napadený stroj po přijetí speciálního paketu od útočníka, díky čemuž dokáže obejít vetšinu firewallů. Kód pro backdoor je ovšem psán pouze pro IPv4, není tedy možné se k němu připojit přes IPv6. Jinak je tomu se zneviditelňováním síťových spojení, neboť ta jsou schovávána podle příslušnosti k procesům — nainstaluje-li útočník libovolný IPv6 server a pomocí SucKITu schová jeho PID, budou schovány i příslušející IPv6 sockety a pro uživatele tak bude zcela neviditelný. 2.2
Hacker Defender [9]
Jedná se o rootkit pro Microsoft Windows NT/2000/XP, instalovaný jako systémová služba, umožňující skrývání souborů, běžících procesů, klíčů v registry, služeb a síťových spojení. Síťová spojení schovává podle čísla portu, IPv6 spojení se s ním podařilo bez problémů skrýt. Hacker Defender implementuje neviditelný backdoor, a to poněkud netypickým způsobem: „přilepíÿ se ke všem procesům, které poslouchají na TCP portech a pokud se na kterýkoliv z těchto portů připojuje backdoor klient, rootkit jej rozpozná a spojení převezme. V ostatních případech spojení přenechá původnímu procesu. Zdali backdoor naslouchá na IPv6, se nepodařilo zjistit, neboť klient k backdooru podporu IPv6 nemá. 2.3
Knark
Knark [10] je linuxový LKM rootkit, disponující typickými službami (skrývání souborů, síťových spojení, změna uid a gid běžících procesů, lokální a vzdálený backdoor). U vzdáleného backdooru platí totéž, co u všech předchozích, podpora IPv6 chybí. Při troše štěstí se s ním ovšem podaří skrývat IPv6 spojení. 2.4
Další rootkity a shrnutí
Zkoušel jsem ještě několik dalších rootkitů (mj. Adore-ng, Kis), ale u všech platí v menší či větší míře to samé, co u výše zmíněných — žadný nenabízí IPv6 backdoor, některé dokážou schovat IPv6 spojení.
Neznamená to ovšem, že se můžeme v IPv6 síti cítit bezpečně, podporu IPv6 do rootkitů implementovat není nijak extrémně náročné a dá se čekat, že se v nejbližší budoucnosti skutečné IPv6 rootkity objeví (neexistují-li již v současnosti).
3
Síťové nástroje a IPv6
K čemu by nám byla podpora IPv6, kdybychom neměli k dispozici alespoň pár nástrojů, usnadňujícím náš život na síti. K těm základním patří příkazy ping6, traceroute6 (tracert6 na OS Windows), netstat s podporou IPv6 a na OS typu UNIX navíc ndp (obdoba arp). Dále si uvedeme některé další aplikace, které podporu IPv6 buď mají, nebo ji v brzké době chystají. 3.1
Nmap
Nmap [11] je pravděpodobně nejpoužívanější open-source nástroj pro zkoumání sítí a bezpečnostní audity. Poskytuje několik druhů portscanů pro TCP i UDP, ping-scan pro vyhledání dostupných zařízení, či možnost odhadnutí typu OS, běžícím na vzdáleném stroji. Od verze 3.10alpha nabízí základní podporu IPv6 (neumožňuje ale např. zmíněný OS fingerprinting nebo scanování více IPv6 adres zádáním zadáním masky nebo rozsahu). K dalším, podobným nástrojům pro skenování portů s podporou IPv6, patří např. HalfScan6 [12] nebo Strobe. 3.2
Nessus
Projekt Nessus [13] si klade za cíl komplexní síťový bezpečnostní audit, umožňující kontrolu jednotlivých hostitelů i celých sítí. Jednotlivé testy jsou implementovány jako pluginy, jejichž databázi lze snadno pravidelně aktualizovat. Popdpora IPv6 bohužel zatím chybí, je plánována do verze 2.2 (v současné je k dispozici stabilní verze 2.0 a vývojová 2.1). 3.3
Netcat6
Netcat6 [14] je IPv6 klon původní unixové utility netcat [15], sloužící ke čtení a zápisu síťových dat a který bývá označován jako „Švýcarský nůž pro TCP/IPÿ. Své využití nalezne především při testování
či (díky snadné integraci s ostatními nástroji a skripty) vytváření vlastních jednoduchých serverových aplikací.
3.4
Tcpdump
Další z užitečných síťových pomocníků je tcpdump [16], sloužící k odchytávání síťového provozu. Je značně oblíben díky podpoře mnoha protokolů od linkové až po aplikační vrsvu, přehledným výstupům a snadnému definování filtrovacích podmínek. Od verze 3.5 (leden 2000) se může chlubit podporou IPv6, která je v současné době již na velmi dobré úrovni.
4
Firewally a podpora IPv6
Firewally patří bezesporu k jedněm ze základních pílířů bezpečné existence na síti. Jejich autoři si toho jsou vědomi a proto již dnes nacházíme podporu IPv6 (na různé úrovni) v několika z nich. V tabulce 1 najdeme výčet několika běžně užívaných, které si s IPv6 poradí. Tabulka 1. IPv6 Firewally Firewall
OS/Platforma
Stavový
IPFilter (ipf)
*BSD, Solaris
ano
ipfw (ip6fw) FreeBSD, NetBSD packet filter (pf) ip6tables/netfilter Internet Connection Firewall
Poznámka
ne
OpenBSD
ano
Linux
ne
Win XP
ne
SP1 + Advanced Netw. Pack
Windows Firewall
Win XP
ano
SP2
Filtrování IPv6 nalezneme i v routerech Cisco či Juniper či ve firewallech Checkpoint.
5
Závěr
Shrneme-li všechny výše uvedené poznatky, dojdeme k následujícímu: – Červi budou mít v IPv6 díky velkému adresním prostoru ztíženou situaci, nelze ovšem očekávat, že by to vedlo k jejich zániku. – V současné době nejsou známy rootkity s IPv6 backdoorem, přesto mohou být relativně snadno o tuto funkci rozšířeny a některé z nich již v současné podobě mohou být útočníkům v záškodnické IPv6 činnosti nápomocny (díky schovávání síťových spojení). – Podpora IPv6 u síťových nástrojů je na slušné úrovni, což je ale dobrá správa jak pro administrátory, tak pro útočníky. V tuto chvíli se zdá, že se utočníci doposud nerozhodli hojně IPv6 využívat, je to ale pouze otázka času, než jim přijde k chuti. Do té doby se rozhodně vyplatí zdravě paranoidní přístup a při experimentování s IPv6 neponechávat nic náhodě — nakonfigurovat firewall, monitorovat síťový provoz a sledovat, zdali nám něco neposlouchá na portu, na kterém by nemělo.
Reference 1. SATRAPA, Pavel. IPv6. Praha: Neocortex, 2002. ISBN 80-86330-10-9 2. Wikipedia - Computer Worm http://en.wikipedia.org/wiki/Computer worm 3. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification http://rfc.net/rfc2463 4. Transmission of IPv6 Packets over Ethernet Networks. http://rfc.net/rfc2464.html 5. OUI Listing http://standards.ieee.org/regauth/oui/oui.txt 6. Neighbor Discovery for IP Version 6 (IPv6) http://rfc.net/rfc2461 7. Global IPv6 allocations made by the Regional Internet Registries http://www.ripe.net/cgi-bin/ipv6allocs 8. Linux on-the-fly kernel patching without LKM http://www.phrack.org/show.php?p=58&a=7 9. Hacker Defender Home http://hxdef.czweb.org/ 10. Knark v2.4.3 http://packetstormsecurity.nl/UNIX/penetration/rootkits/knark-2.4.3.tgz
11. Nmap security scanner http://www.insecure.org/nmap/ 12. Halfscan6 http://www.habets.pp.se/synscan/programs.php?prog=halfscan6 13. The Nessus Project http://www.nessus.org/ 14. The Netcat6 Homepage http://netcat6.sourceforge.net/ 15. The GNU Netcat http://netcat.sourceforge.net/ 16. TCPDUMP Public Repository http://www.tcpdump.org/
Bc. Kamil Okáč : V současné době se blíží k závěru studia oboru Informační technologie na Vysoké škole ekonomické v Praze. Prezentované téma bude tvořit část jeho diplomové práce.
