dinsdag 25 februari 2014

Transitional Threats: SLAAC Attack

In deze blogpost zal ik de werking van een SLAAC aanval uitleggen en deze later testen op een intern netwerk. Een echte SLAAC aanval bestaat uit nog meer componenten (DHCP, DNS) maar deze worden hier niet in behandeld omdat we een intern netwerk testen om te kijken of deze aanval gewoon al lukt.


In de overgang van IPv4 naar IPv6 zijn er verschillende mogelijkheden om connectie over beiden te behouden. 1 daarvan is de dualstack methode. Dit wil gewoon zeggen dat mijn naast IPv4 ook IPv6 draait en verkeer langs beiden kan hebben. Nu vele OS of machines hebben IPv6 automatisch geenabled en hebben voor IPv6 ook nog eens een voorkeur zodat als men beiden zou draaien vaak traffic langs IPv6 herleid worden.

Nu wat heeft dit met deze aanval te maken? Het probleem is dat velen een volledig werkend IPv4 netwerk draaiende hebben en niet beseffen dat IPv6 standaard werkt. Ook al heb je niets geconfigureerd, de hosts zijn IPv6 "aware" en zullen dus bij eerste Router Advertisement (van een rogue router misschien) hunzelf automatisch configureren (SLAAC). Je kan dan denken, ok dan wordt alle traffic van IPv6 langs daar geroute, maar als dit een volledig werkend (en beveiligd) IPv4 netwerk hebben en er zijn maar heel weinig applicaties puur op IPv6 draaien. Je kan nu natuurlijk andere aanvallen op het netwerk afsturen, maar dit is niet de bedoeling van deze aanval.

Bij deze aanval is het de bedoeling dat je alle IPv4 (& dus ook IPv6) traffic langs je router stuurt, die verbonden is met de rest van hun IPv4 netwerk (of internet). Wat je nog extra nodig hebt is een manier om alle IPv4 netwerk ook nog eens te laten redirecten. De beste manier voor dit is het NAT-PT mechanisme te gebruiken. Dit is een mechanisme om de overgans normaliter makkelijker te maken. Maar dit heeft zoveel security threats dat IETF heeft besloten dit mechanisme als deprecated te beschouwen en wordt niet meer ondersteunt. Dit wil niet zeggen dat wij het niet meer kunnen gebruiken! Het grote voordeel voor ons is dat dit mechanisme automatisch werkt zonder interactie van het slachtoffer. Het zorgt ervoor dat IPv6 hosts naar IPv4 hosts kunnen connectie maken door IPv6 adressen te vertalen in IPv4 adressen. Je ziet dat zo onze IPv6 verbonden hosts hun verkeer langs ons gaan "vertalen" als het ware om te connecteren naar het IPv4 netwerk.

Voor NAT-PT te configureren op een router moet je eerst nat mogelijke maken op de specifieke interface. Vervolgens een pool aanmaken met IPv4 adressen waaruit de vertaling kan bestaan en als laatste een /96 prefix definieren (deze moet overeen komen met de /64 prefix die je gaat uitzenden voor je RA packet om IPv6 te autoconfigureren, zie voorbeeld). Dan zal een adres bestaan uit de /96 gedefineerde prefix en de laatste bits zullen dan bestaan uit het IPv4 adres dat de host hebben toegewezen gekregen.

Als je je router goed geconfigureerd hebt rest ons nog alleen een RA packet te forgen om zo de autoconfiguratie op gang te zetten. Dit kan makkelijk gedaan worden in scapy. Het enige waar specifiek op gelet moet worden is dat de /64 prefix die gedefineerd moet worden hezelfde is al de eerste 64 bits van de gekozen /96 prefix bij de configuratie van NAT-PT.

Even een voorbeeld:
-RA in scapy:


./scapy.py
>>>a = IPv6(dst=LLA)
>>>b= ICMPv6ND_RA()
>>>c = ICMPv6NDOptSrcLLAddr(lladr=SLLA)
>>>d = ICMPv6NDOptMTU()
>>>e = ICMPv6NDOptPrefixInfo(prefixlen = PREFL, prefix = “PREF”)
>>>display(a/b/c/d/e) /* Optional used to check if packet is correctly forged */
>>>send(a/b/c/d/e)



Het paket is onderverdeeld in de verschillende stukken om een beter overzicht te krijgen (je kunt dit natuurlijk omschrijven in een one-liner). Het eerste is een IPv6 pakket met een LLA, het LLA voor deze aanval is een LL Multicast adres om dit naar alle hosts in het IPv4 netwerk te versturen. Dan de aanmaak van een RA packet (b). Vervolgens worden de opties gedefinieerd (c, d). In c wordt het source LLA gedefineerd, dit is ons eigen MAC adres zodat alle traffic langs ons passeert. in e configureer je dan de prefix die de IPv6 adressen van de hosts moeten hebben. Zoals eerder gezegd is dit een /64 adres dat moet overeen komen met de eerste 64 bits van het gekozen /96 adres.

-NAT-PT op je rogue router

/* enables NAT-PT on that interface */
interface ETHPORT
    ipv6 nat

/*Sets Dynamic nat for IPv6 to IPv4 */
ipv6 nat v6v4 source list NAT_TRAFFIC pool IPV6_TO_IPV4

/* Specifies the dynamic NAT IPv4 pool */
ipv6 nat v6v4 pool IPV6_TO_IPV4 4ADRRANGEBEGIN 4ADRRANGEEND prefix-length 24

/*Specify the IPv6 NAT prefix */
ipv6 nat prefix PREFNAT

/* ACL to specify traffic eligible for NAT-PT */
ipv6 access-list NAT_TRAFFIC

     permit ipv6 any PREFNAT

Zoals je kunt zien is dit geconfigureerd op een cisco systeem. Je kan dit ook op een host configureren zodat je geen 2 devices moet configureren. In dit geval verwijs ik naar de onderstaande link van infosecInstitute men de opvolging van deze aanval uitgebreid uitlegt. Aangezien dit voor studiegerichte doeleinden wordt gebruikt, heb ik gekozen voor een simpele configuratie in een cisco systeem.

Je mag de begin en eind adressen  voor de IPv4 pool zelf kiezen. Het enige waar op gelet moet worden is de /96 prefix.

Met deze laatste configuratie kan je de host aansluiten en je zal zien bij het versturen van de RA packet dat de victim hosts een IPv6 adres bezitten dat zijn verkeer via ons herleid. En je hebt een succesvolle MITM aanval van een IPv4 netwerk met een IPv6 overlay!

NOOT: Deze aanval is in het kader van mijn stage opgemaakt voor test redenen. Zoals Dhr. Alec Waters configureert (zie link van infosecinsitute) is veel complexer en uitgebreider met nog DHCPv6 spoofing om effectief met het internet verbonden te kunnen worden en het gebruik van een DNS server. Ik kon natuurlijk gewoon volledig Dhr. Waters zijn aanval overnemen, maar mij leek het interessanter om zelf een vorm van deze aanval uit te voeren die past in het kader van de andere tests. Tevens heeft een een groep researchers van Neophasis labs een tool gecreĆ«erd genaamd Sudden Six om al deze complexe configuratie van Dhr. Waters in enkele minuten te laten overlopen. Nogmaals, hiervoor is niet gekozen omdat ik zelf een beter inzicht in deze aanval wou hebben.

CONCLUSIE:

Deze aanval maakt het mogelijk om zodra je een rogue device in een IPv4 netwerk kan plaatsen een makkelijke overlay te plaatsen van een IPv6 netwerk. Deze aanval is niet zo complex uit te voeren en is vooral destructief voor goed beveiligde IPv4 netwerken die nog niets aan hun IPv6 beveiliging gedaan hebben.

Referenties:
Info over de SLAAC aanval zelf:
- http://resources.infosecinstitute.com/slaac-attack-/
- http://www.informationweek.com/security/vulnerabilities-and-threats/windows-ipv4-networks-vulnerable-to-ipv6-attack/d/d-id/1097153?
- Cisco Press: IPv6 Security by Eric Vyncke (Hoofdstuk over Transitional Threats

RFC:
- http://tools.ietf.org/html/rfc4966

RA packet:
- http://samsclass.info/ipv6/proj/projL3-scapy-ra.html
- http://isc.sans.edu/diary/IPv6+MITM+via+fake+router+advertisements/10660

NAT-PT:
- http://blog.ine.com/2008/04/18/understanding-ipv6-nat-pt/



Geen opmerkingen:

Een reactie posten