Snellere methode voor dns-cachevervuiling dwingt patchronde af

Een oude kwetsbaarheid van dns-servers kan dankzij nieuwe exploitatietechnieken zeer snel misbruikt worden om netwerkverkeer om te leiden. Voor de belangrijkste dns-pakketten zijn inmiddels patches verschenen.

Het vervuilen van de cache van dns-servers is een methode die al langer bekend was: door de juiste dns-entry keer op keer te vervangen door vervalste informatie, kunnen hackers gegevens in dns-servers aanpassen en zo verkeer naar wens routeren. De informatie die de cachende server bij een 'authoritative' dns-server opvraagt en opslaat, kan op die manier vervalst worden. Deze zogenoemde dns cache poisoning-aanvallen zijn onder meer in trek bij phishers, die er verkeer mee naar vervalste websites omleiden. Ook maakt een dergelijke aanval op dns-servers het mogelijk om ander verkeer, zoals e-mail, om te leiden. De nieuwe methode versnelt het vervuilen van de cache aanzienlijk: waar voorheen uren tot dagen nodig waren om de servers voor de gek te houden, zou het nu nog maar tienden van secondes duren. Zowel de de facto standaard Bind als Microsofts dns-server zijn kwetsbaar voor de aanvallen.

Zowel cachende dns-servers als servers die alleen voor hun eigen domein adressen naar ip-adressen vertalen, kunnen misbruikt worden door gebrekkige implementatie van het zogenoemde transaction id. Dit getal van zestien bits wordt willekeurig gegenereerd. Gebruik van velden van minder dan zestien bits voor de transaction id en gebrekkige rng's kunnen de benodigde tijd voor cache poisoning verder verkorten. Ook het uitzetten van meerdere identieke verzoeken voor dns-entries en het gebruik van steeds dezelfde poorten voor die verzoeken, kunnen de snelheid voor aanvallen vergroten.

De Amerikaanse computerveiligheidsdienst US-Cert heeft een uitgebreide beschrijving van het probleem online gezet. Naast het patchen van de dns-software geeft de organisatie een aantal adviezen om de kans op cache-vervuiling te beperken. Er zijn inmiddels ongeveer tachtig softwareproducten bekend die kwetsbaar zijn voor dns cache poisoning. Voor Bind en de dns-servers van Cisco, Microsoft en Sun zijn inmiddels patches beschikbaar.

Reacties (13)

[mindcrash]

Deze patches zijn gerealiseerd na onderzoek van de security researcher Dan Kaminsky, die de fout vond. Op zijn site is een online tool te vinden die onderzoekt of jij of je Service Provider een DNS server draait die (nog) niet is gepatched.

Ik heb zelf gekeken of de servers van mijn DNS provider OpenDNS kwetsbaar zijn met deze tool, en dat lijkt niet het geval te zijn. Dat zou dus een mooi (tijdelijk) alternatief zijn voor tweakers die het niet zien zitten om te wachten tot hun ISP de DNS servers heeft gepatched.

Overigens is naar aanleiding van deze exploit ook een interview gehouden met de heer Kaminsky. Deze is hier terug te vinden.

(Met enige dank aan /. voor de links naar de tool en de podcast.)

[AndriesLouw]

Is er ook een manier om met dit tooltje zelf een adres in te vullen om hem te checken? Ik zou graag een aantal nameservers controleren die in mijn beheer zijn, maar niet door mijzelf gebruikt worden.

[Pruts0r]

Het is vrij eenvoudig om even tijdelijk van andere nameservers gebruik te maken, op openDNS (zie link in post van mindcrash) staat precies uitgelegd hoe.

Overigens zou ik nog willen toevoegen dat Ziggo/Casema's DNS servers kwetsbaar zijn (ik heb al een storingsformulier ingevuld).

[_JGC_]

Behalve DNS servers hebben ook linux clients hier last van. De ingebouwde resolver library op systemen met glibc (alle linux systemen) stamt af van BIND 8, welke helemaal niet aan randomization doet. Wil je niet vatbaar zijn voor DNS poisoning, dan moet je in je netwerk of op de machine zelf een caching DNS installeren die niet vatbaar is voor dit probleem.
Dat Microsoft zijn DNS server ook lek is, is niet vreemd: het ding stamt af van een oude versie van BIND en is in de loop der jaren grondig verbouwd. Van BIND zijn door de jaren heen ook diverse rewrites geweest en ook BIND 9, de huidige versie, was vatbaar voor dit probleem.
Voor de mensen die nu nog BIND 8 in produktie gebruiken voor recursing nameservers: uitfaseren die troep. Recursors horen niet op code te draaien die al vanuit de basis niet veilig ontworpen is. Of upgraden naar de laatste gepatchte versie van BIND 9, of vervangen door iets als pdns-recursor.

[n4m3l355]

Zal het ook niet sterk te maken hebben dat sommige servers out of the box installeren zonder verdere wijzigingen toe te passen? Zo zijn eigenlijk wel veel services vastbaar zoals vroeger ook mysql admin vatbaar was omdat dan er een default user erin bleef staan die zelfs te googlen was. Ik denk dat eigenlijk dit niet zozeer een probleem voor de dns servers is maar eerder hoe sommige admins met software omgaan of hun gebrek aan kennis.
Het vervelende is dan uiteindelijk dat niet zozeer de admin hier problemen ondervind maar de eindgebruiker. Zou het niet mogelijk zijn om je hier tegen te beschermen met een blacklist van dns servers in je antivirus die mbv een firewall bepaalde dns´s filterd? Ik heb meer vertrouwen in antivirus ontwikkelaars dan in laakse admins.

[_JGC_]

Nee, dit heeft niks te maken met out of the box configuraties. Je DNS server gaat het internet op om requests te doen voor data die jij opvraagt bij je DNS server. Hierbij wordt bij lekke DNS servers altijd dezelfde sourceport gebruikt, of in het geval van recentere versies met dit lek, een te simpele random number generator met voorspelbare uitkomsten.
De linux client library die door zowat elk programma gebruikt wordt gebruikt hetzelfde algoritme als BIND 8 en is dus ook vatbaar voor dit probleem. Als jij het netwerk tussen jouw linuxmachine en de DNS server waar jij je requests naar doet niet kunt vertrouwen, ben je vatbaar voor deze bug.
Leuker wordt als er straks een update voor glibc komt die deze bug oplost, zit je met al die rare statisch gecompileerde closed binaries die nog steeds last hebben van deze bug

edit: het blijkt hier niet eens om source ports te gaan, maar om voorspelbare transaction IDs met hetzelfde effect.

[Reactie gewijzigd door _JGC_ op 27 juli 2024 05:05]

[freaky]

Nee dit valt niet met configuratie van het product in kwestie op te lossen. Afgezien van het feit dat ze het dan vast wel vermeld hadden...

[serkoon]

Ik ben benieuwd waar de volgende tekst vandaan komt:
"De nieuwe methode versnelt het vervuilen van de cache aanzienlijk: waar voorheen uren tot dagen nodig waren om de servers voor de gek te houden, zou het nu nog maar tienden van secondes duren."

Er is in de advisories en in interviews met Kaminsky namelijk niks gezegd over wat er nu nieuw is aan het huidige issue en hoeveel dit issue de huidige attacks kan versnellen.

Het is al jaren bekend dat in het beste geval (uitgezonderd source port randomization) je maar enkele tienduizenden packets nodig hebt om cache poisoning uit te voeren. Op een snel systeem met een 100MBit/s of 1Gbit/s link kun je dat in fracties van een seconde. Dat is dus niet nieuw. Aangezien Kaminsky normaalgesproken niet zomaar wat roept, heeft hij ongetwijfeld iets gevonden dat -wel- nieuw is. Bijvoorbeeld dat je op basis van enkele packets kunt bepalen wat het ID van de volgende zal zijn en je dus ipv enkele tienduizenden packets er maar 10 hoeft te sturen..

Iemand die al meer weet?

[Reactie gewijzigd door serkoon op 27 juli 2024 05:05]

[Little Penguin]

Vanmorgen was er ook al aandacht voor dit probleem op de BBC Worldservice en werd er bij gezegd dat er nog geen exploit was en dat dit toch wel lastig zou zijn (om dit binnen een paar dagen te realiseren). Als ik dit zo lees dan krijg ik het idee dat het toch niet zo heel erg lastig is.

Zowel cachende dns-servers als servers die alleen voor hun eigen domein adressen naar ip-adressen vertalen, kunnen misbruikt worden

Maar moet je bij cachende dns-servers niet al binnen in een organisatie zitten om dit te kunnen misbruiken, of heb ik 't dan bij het verkeerde eind?

[_JGC_]

Je caching DNS server moet toch op een of andere manier zijn gegevens van het internet halen. Aangezien de wat oudere servers altijd dezelfde source ports gebruiken voor DNS requests, kunnen spoofers er gewoon pakketjes tussen drukken die de server aanneemt als antwoord op de DNS query.
Edit: gaat in dit geval niet eens om de source ports zoals de vorige keer het geval was, maar om voorspelbare transaction IDs die je ook kunt spoofen.

[Reactie gewijzigd door _JGC_ op 27 juli 2024 05:05]

[jhu]

Ik moet zeggen dat het verhaal me echt wel aan het denken heeft gezet.

Dat zoveel apparaten een eigen DNS implementatie hebben en dat ze vrijwel allemaal kwetsbaar zijn. Voor Bind en dergelijke in servers is het makkelijk op te lossen, maar reeds geïnstaleerde apparaten (Cisco apparaten oa) kan lastiger zijn.

Zoals JGC al zei is de PowerDNS recursor momenteel een veilige optie en ook in de basis veiliger dan Bind

[Verwijderd]

Dan Bernstein, maker van DJBDNS heeft hier reeds in 2001 voor gewaarschuwd http://cr.yp.to/djbdns/forgery.html. Zijn DNS server is hier dan ook al op voorzien