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

Geen opmerkingen:

Een reactie posten