Sociálne siete

SecIT.sk na Facebooku SecIT.sk na Google+ SecIT.sk na Twitteri

Podporte nás


V prípade, že Vám obsah nášho portálu niekedy nejakým spôsobom pomohol, či bol pre Vás prínosom prosím podporte jeho chod ľubovoľnou čiastkou. Ďakujeme!

Prihlásenie

Štítky

Vyhľadávanie

You are here

Domov
Upozornenie: Obsah je licenčne chránený a bez písomných súhlasov autora článku a vlastníka webovej stránky nesmie byť v žiadnej forme ďalej kopírovaný a šírený v pôvodnom, či v akokoľvek upravenom stave.

DHCPv6 flooding - ako podvrhnúť DHCP server?

DHCP server sa stal v podstate neoddeliteľnou súčasťou IPv4 lokálnych sieti. Aká je situácia pri IPv6 LAN? Ako možno získať kontrolu nad LAN vyradením a podvrhnutím legitímneho DHCPv6 servera? DHCPv6 flood je pomerne zákerný útok, ktorý umožňuje útočníkovi po odstavení skutočného DHCP servera prideľovať vlastné sieťové parametre, a tak veľmi elegantne a účinne prevziať kontrolu nad celou sieťou.

Upozornenie: Všetky publikované informácie a postupy slúžia výhradne na študijné účely, prevádzané len na sieťach, ktoré patria pod vaše vlastníctvo, ak týmto konaním priamo, či nepriamo nezasiahnete ich používateľov. Vykonávanie týchto postupov na sieťach s reálnou prevádzkou môže byť ilegálne a v každom prípade ide o amorálne počínanie. Autor článku nenesie žiadnu zodpovednosť za škody, ktoré môžu vzniknúť v dôsledku realizácie týchto postupov.

Okrem bez-stavovej konfigurácie môžu byť IPv6 adresy pridelené i stavovo, automaticky za pomoci DHCPv6 servera. K tomuto kroku správcov sietí často núti fakt, že v základnom nastavení alebo implementácií nedokáže bez-stavová konfigurácia poskytnúť napr. informácie o DNS serveroch, či ďalšie pokročilé sieťové parametre. V súčasnosti je možné toto rozšírenie bez-stavovej konfigurácie v určitých implementáciách už riešiť a doplniť. Bez ohľadu na to je však DHCPv6 server určitou komfortnosťou pre celú lokálnu sieť. Server DHCPv6 sa v základnom princípe neodlišuje od DHCP servera pre protokol IPv4. Detailný popis by však vyšiel na mnoho strán a mohol by byť námetom pre samostatný článok. Preto je jeho princíp popísaný len veľmi stručne s dôrazom na bezpečnostné aspekty a samotný útok.

DHCPv6 a LAN

DHCPv6 používa 3 typy zariadení:

  • Klient – stanica žiadajúca o IPv6 adresu.
  • Server – poskytovateľ IPV6 adresy a ostatných sieťových informácií.
  • Relay (sprostredkovateľ) – zaisťuje kontakt medzi 2 vyššie uvedenými časťami, je totiž možné, že sa klient a server nenachádzajú na rovnakej sieti.
  • Agent – je pojem použitý na súhrnné označenie serverov a sprostredkovateľov, na danej sieti poskytne buď vlastnú, alebo sprostredkovanú DHCPv6 odpoveď.

Ak je na IPv6 lokálnej sieti prítomný DHCPv6 server, stanice sa tento fakt zvyčajne dozvedajú v správe RA. Klient by mal reagovať správou DHCP Solicit na multicastovú adresu ff02::1:2, čo predstavuje skupinu pre všetkých DHCP agentov a synchronizačné servery (relay).

Následne by mal klient – žiadateľ získať odpovede všetkých dostupných DHCPv6 serverov s ich ponukami. Prednosť by mal dostať server s najvyššou preferenciou (závislé na implementácií). Ak je implementácia viacerých serverov totožná, závisí od posúdenia poskytovaných parametrov (napr. IPv6 adresa). Opäť je tu istá závislosť na konkrétnej implementácií.

Po výbere preferovaného servera zašle požiadavku na pridelenie sieťových údajov, ktorú akceptuje len ním vybraný server (vidia ju totiž aj všetky ostatné DHCPv6 servery prítomné na danej sieti). DHCPv6 server odošle späť požadované údaje. Aj v tejto fáze môže dôjsť v zriedkavých prípadoch k odmietnutiu pridelenia údajov DHCPv6 serverom. Po získaní sieťových údajov si klient adresu overí už v predošlých článkoch spomínanou detekciou duplicitných adries – DAD. Údaje obsahujú aj dobu platnosti, po ktorej ich bude nutné obnoviť, rovnako môže prísť takáto žiadosť aj zo strany samotného DHCPv6 servera, či klienta (napr. po reštarte PC).

Pri celom procese zohráva dôležitú úlohu identifikátor DHCP Unique Identifier – DUID. Jedná sa o jednoznačný, podľa možností nemenný identifikátor pridelený všetkých participantom podieľajúcim sa na DHCP procese – serverom i klientom. Môže byť odvodený rôznymi metódami. Druhým identifikačným prvkom je Identity Asociation – IA. Ide o konfiguračné informácie pridelené vždy jednému rozhraniu danej klientskej stanice určené jednoznačným, opäť pokiaľ možno nemenným identifikátorom IAID. Tým musí disponovať každé rozhranie, ktoré sa chce zúčastniť procesu pridelenia sieťových údajov za pomoci DHCPv6.

Cisco v súčasnosti napr. v rámci systému IOS neponúka rozsiahle konfiguračné možnosti pre protokol IPv6, (tento fakt platil v dobe tvorby práce a situácia sa už mohla zmeniť) obmedzuje sa len na DNS servery, či servery SIP. neponúka ani možnosť spravovania rozsahov prideľovaných adries (tzv. IP pool). Preto je pre plnohodnotné využitie DHCPv6 serveru nasadiť implementáciu tretej strany.

Ako prebieha útok

Samotný útok spočíva v tom, že útočník vytvorí svoj vlastný falošný DHCPv6 server. Tento server bude následne poskytovať podvrhnuté sieťové informácie. V tomto prípade tak útočník získa kompletnú kontrolu nad sieťovo komunikáciou, za istých okolností aj naprieč celou IPv6 LAN. Získané dáta môže sledovať, či modifikovať a následne rozhodnúť o ich zaslaní skutočnej cieľovej destinácií.

Predpoklad útočníka však, je, že jeho falošný DHCPv6 server musí byť akceptovaný ako jediný legitímny. Ak sa však na IPv6 LAN nachádza aj legitímny skutočný DHCPv6 server, spoľahnúť sa môže len na náhodu. Z implementačného hľadiska totiž netuší ako zareagujú klienti na sieti a aký DHCP server uprednostnia. Ak chce útočník svoj útok poistiť vykoná záplavu legitímneho DHCPv6 servera tým, že vyčerpá všetky ním ponúkané IPv6 adresy. Avšak tento útok je veľmi závislý na množstve poskytovaných IPv6 adries. Ak je pool veľmi rozsiahly včerpanie je v podstate nereálne. Ak je správcom siete obmedzený, tak je vyčerpanie legitímnych adries možné a následne sa tak stane jedinou možnosťou pre klientov na lokálnej sieti žiadanie IPv6 adries od podrhnutého DHCPv6 servera.


model
Obrázok 1 - Znázornenie priebehu útoku v praxi.

DHCPv6 flooding

Simulovaný bol len samotný flooding (záplava regulérneho DHCPv6 servera a vyčerpanie ním poskytovaných IPv6 adries), keďže to je signifikantný moment pre správcu siete, i samotný senzor, ktorý sa testuje v tejto práci. Na realizáciu útoku bol použitý nástroj flood_dhcpc6 z balíka THC-IPv6.

Pre potreby simulácie tohto útoku bolo nutné zriadiť DHCPv6 server. Pre tieto účely bol použitý voľne dostupný DHCPv6 server Dibbler 0.8.2.1. Útok má zmysel iba ak je pool prideľovaných IPv6 adries rozsahovo v desiatkach až stovkách. V reálnom živote ide napr. o prípad, keď si správca siete potrebuje zachovať absolútnu kontrolu nad spôsobom prideľovania adries. Vtedy určí vyšší prefix, tak aby bolo pridelených len niekoľko adries. V prípade, že by sa použil nízky prefix, útok nemá zmysel. Útočník by totiž musel vynaložiť obrovský výkon, aby vyčerpal niekoľko miliónov IPv6 adries, ktoré tak vzniknú.

Pre simuláciu tak bol zvolený prefix /119. Ten umožnil správcovi obmedziť adresný rozsah na prijateľných 512 adries. Jednalo sa o sieť 2001:bac:1:1::, s rozsahom: 2001:bac:1:1:: -2001:bac:1:1::1ff. Do konfigurácie bol tiež pridaný odkaz na 2 DNS servery 2001:bac:1:1::dd1, 2001:bac:1:1::dd2 a fiktívna doména, ktorá slúžila ako prípona pre DNS záznamy testx.sk. Potrebné bolo upraviť i konfiguráciu Cisco smerovača. Jednalo sa o 2 hlavné zmeny: v nastavení konkrétneho sieťového rozhrania bolo potrebné, aby smerovač v správach RA oznámil staniciam, že bude vyžadovaná stavová konfigurácia. Kvôli prehľadnosti bolo potrebné úplne deaktivovať bez-stavovú automatickú konfiguráciu na testovacej sieti. Následne je celá sieť pri prideľovaní IPv6 adries závislá už len na DHCPv6 serveri.

Útok v praxi

Pre účely otestovania tohto útoku boli na sieti 4 stanice. Útočník (Kali Linux), klient Windows 7, Linux Debian (klient), Linux Debian (DHCPv6 server). Počítač s Windows 7 získal nasledovné údaje:


model
Obrázok 2 - Sieťové údaje získané klientom po pripojení DHCPv6 servera.

Rovnako pridelená pomocou DHCPv6 servera bola IPv6 adresa pre systém Linux Debian, ktorý využíval honeypot 6guard. Išlo o adresu 2001:bac:1:1::1bb. Útočník - 2001:bac:1:1::ee. Následne bol zahájený útok. Útok z náhodne generovaných IPv6 link-local adries mal za úlohu vyčerpať celý rozsah globálnych IPv6 adries, ktoré poskytoval legitímny DHCPv6 server.


model
Obrázok 3 - DHCPv6 Solicit pakety, ktorých úlohou je vyčerpať adresy z celého poolu.

Po uplynutí času prenájmu pridelenej IPv6 adresy, ktorý bol nastavený na 120 sekúnd, sa stanica ocitla bez globálnej IPv6 adresy. Nemohla tak komunikovať mimo hraníc lokálnej siete. V tejto chvíli by mohol útočník pripojiť svoj falošný DHCPv6 server a poskytnúť klientom podvrhnuté sieťové informácie, ako napr. adresy DNS serverov.


model
Obrázok 4 - IPv6 adresa s globálnou platnosťou nie je pridelená.

Obrana

Pri obrane majú správcovia v zásade možnosť použiť sofistikované ochranné prvky, ktoré ponúkajú manažovateľné L3 prepínače ako napr. Cisco. Rovnako je možné použiť rôzne IDS/IPS systémy, ale napr. aj open-source riešenie ako 6guard honeypot. Ten spomeniem v ďalšom článku. Nepriamu obranu môže predstavovať i veľký pool prideľovaných IPv6 adries, ktoré útočník nebude mať možnosť reálne vyčerpať.

Záver

Týmto útokom sme ukončili prehľad najčastejších IPv6 útokov na lokálnej sieti. I keď v praxi sa často s IPv6 LAN ešte pravdepodobne nejaký ten čas nestretneme, nemožno zabúdať ani na tzv. "spiacu" IPv6 LAN, ktorá môže vzniknúť automaticky pri zariadenach, ktoré podporujú IPv6 a zdieľajú rovnakú lokálnu sieť. Skôr či neskôr sa však aj IPv6 LAN siete stanú realitou. Finálny článok o problematike bezpečnosti na IPv6 LAN nabudúce venujeme spôsobu ochrany, ktorú ponúka open-source nástroj.


Podporte nás


Páčil sa Vám tento článok? Ak áno, prosím podporte nás ľubovoľnou čiastkou. Ďakujeme!


ITC manažer Security-portal.cz Soom.cz
Hoax.cz Antivirove centrum Crypto-world.info