Nieuw patchalarm dns-servers na openbaarmaken kwetsbaarheid

Een hacker heeft details over een dns-kwetsbaarheid vroegtijdig in de openbaarheid gebracht, twee weken voordat het lek op de Black Hat-hackersconferentie uit de doeken zou worden gedaan.

Ontdekker Dan Kaminsky wilde de details nog even geheim houden om isp's, bedrijven en overheden in de gelegenheid te stellen het probleem te patchen, en riep de securitygemeenschap dan ook op om niet openlijk te speculeren over de aard van de kwetsbaarheid.

Reverse-engineering-expert Thomas Dullien, bekend onder de hackersnaam Halvar Flake, deed echter toch een gooi, aldus het Security Bytes-blog. Dat gebeurde naar alle waarschijnlijk na bestudering van een set patches die eerder deze maand werd vrijgegeven. Vervolgens bevestigde Matasano Security, één van de door Kaminsky over het lek ingelichte bedrijven, dat Flake het bij het rechte eind had. Het weblog waarin Matasano zei dat 'de aap uit de mouw' was, werd al na vijf minuten offline gehaald, maar toen circuleerden er al verschillende kopieën over het internet.

Het lek maakt het mogelijk om dns-servers op een dusdanige manier met requests te bombarderen, dat een query van een internetter die een bepaalde website probeert te bezoeken, op een nepsite uitkomt. Die site heeft schijnbaar de juiste url en steelt vervolgens bijvoorbeeld inloggegevens. De aanvalstechniek omvat het vervuilen van de dns-cache, wat met de begin deze maand ontdekte kwetsbaarheid zeer snel kan gebeuren.

Omdat de destijds uitgebrachte fixes al werden gezien als tijdelijke pleisters op de wonde, werd reeds gewerkt aan een definitievere patchset. In hoeverre toepassing van de tijdelijk patches de kwetsbaarheid opheft is onduidelijk, maar het is aannemelijk dat de openbaring van Flake de kans op een succesvolle aanval op een gepatche server aanzienlijk vergroot. Een blik op US-Certs Vulnerability Note leert bovendien dat lang niet iedereen de nu beschikbare patches al toe heeft gepast.

Hoofdonderzoeker Thomas Ptacek van Matasano Security gaat op het bedrijfsblog diep door het stof voor het feit dat hij de werking van de kwetsbaarheid in de openbaarheid bevestigde. Ptacek noemt het zowel professioneel als persoonlijk een pijnlijke zaak. Kaminsky wilde de juistheid van Flake's theorie aanvankelijk niet zelf bevestigen, maar plaatste vervolgens een oproep op zijn eigen weblog om als de wiedeweerga te patchen. De tevergeefs ingetrokken bevestiging van Matasano, met uitgebreide uitleg over de kwetsbaarheid, is op onder meer Jbib.net te lezen.

Reacties (48)

[Parasietje]

De exploit die Kaminsky heeft gevonden is eigenlijk doodsimpel. bron

Er zijn basically twee technieken om DNS cache te poisonen.

Truc 1: Packet forgery. Mijn DNS server (laten we de machine Alice noemen) stuurt een request uit voor 'www.victim.com'. Normaalgezien antwoordt Bob (de nameserver voor domein victim.com) met het juiste IP adres. Als Mallory (de booswicht) nu echter sneller dan Bob een vals pakketje stuurt naar Alice met 'www.victim.com == my-evil-server.com', dan heeft hij de cache gepoisont. Gelukkig is het zo makkelijk niet, elke DNS transactie heeft een QID-nummer van 16 bits, die Mallory moet raden. Ook moet de UDP source port geraden worden (weer 16 bits). Daarom is het gebruik van UDP source port randomization belangrijk. Mallory zal steeds pas later dan Bob een pakketje met juiste QID-nummer kunnen sturen. Bovenstaande scenario kan zich maar 1 keer afspelen: als Alice het juiste adres krijgt, blijft het een tijdje in de cache zitten. Zo kan bovenstaande race dus maar om de twee uur gebeuren. Deze techniek heet 'DNS forgery', het nabootsen van legitieme antwoorden van Bob.

Truc 2: DNS antwoorden bevatten drie dingen: authority, answer en glue. Voorbeeld: ik vraag www.wikipedia.org op. De .org-server antwoordt: vraag het aan ns.wikipedia.org (authority). Ik heb geen answer. De glue is het ip-adres van ns.wikipedia.org. Als ik nu een DNS-server op ns.evil.com zet, die bij elk pakketje ook de glue 'www.victim.com is my-evil-ip-address' bijzet, dan heb ik de cache gepoisont. De fix hiervoor is simpel: aanvaard geen glue van niet-authorative nameservers.

Wat Kaminsky heeft gedaan, is beide attacks combineren. Hij vraagt Alice naar het IP-adres van 'AAAA.victim.com', en probeert dan te racen met Bob om het antwoord voor AAAA.victim.com na te bootsen. Dit lukt niet voor 'AAAA.victim.com', maar je kan nog eens proberen voor 'AAAB.victim.com', 'AAAC,victim.com' enz.
Nu boots je niet zomaar 'AAAA.victim.com == my-evil-server' na, maar je voegt ook glue toe: 'www.victim.com == my-evil-server'. Omdat de glue voor hetzelfde domein is als je originele request, wordt de glue ook gecachet!

Met deze techniek kunnen dus zelfs top-level domains gepoisont worden. De workaround is heel simpel: overschrijf nooit je bestaande cache zolang die nog TTL heeft.
Tot elke DNS-beheerder die fix heeft toegepast, is DNS cache poisoning heel erg makkelijk! Zeker omdat bind niet aan UDP source port randomization doet; je hoeft enkel het QID-nummer te raden.

[Reactie gewijzigd door Parasietje op 27 juli 2024 11:50]

[Arietje]

Op http://member.dnsstuff.com/tools/vu800113.php kan je testen of je dns servers kwetsbaar zijn.

[Parasietje]

Dat tooltje kijkt alleen of uw DNS-server source port randomization doet. Hij test niet of DNS-servers kwetsbaar zijn voor de bug die Kaminsky vermeld.

[Little Penguin]

De website die je opgeeft, die geeft aaan dat'ie geen DNS-server kan vinden en dat terwijl ik zeker weet dat ik op dit moment draai met een nog steeds ongepatchte server (privé DNS servertje) - m.a.w. aan die site hebben we niet veel.

Bij het vorige bericht over deze lek ben ik een link tegengekomen die ik toen getest heb op een gepatchte server en nu net om m'n privé server die dus nog ongepatcht is en daar kwam inderdaad het juiste resultaat uit - bij de gepatchte werd 't goed aangegeven en op m'n privé server ook.

Het adres van die checker is: http://www.doxpara.com/

Hieronder de uitvoer:

Your name server, at <mijn privé IP> appears vulnerable to DNS Cache Poisoning.
All requests came from the following source port: 62500

Do not be concerned at this time. IT administrators have only recently been apprised of this issue, and should have some time to safely evaluate and deploy a fix.Requests seen for d7d87c41fafb.toorrr.com:
<mijn privé IP>:62500 TXID=49290
<mijn privé IP>:62500 TXID=24645
<mijn privé IP>:62500 TXID=41183
<mijn privé IP>:62500 TXID=19493
<mijn privé IP>:62500 TXID=33139

Bij een gepatchte server werd netjes aangegeven dat die source port niet iedere keer hetzelfde is.

* Little Penguin gaat nu alsnog de DNS server fixen - 't wel privé, maar ik wil wel met enige zekerheid op t.net komen

[HoeZoWie]

Grappig, ik heb gepatcht om mijn WS2003-DNS-Server maar hij geeft in de uitvoer window; een 404 Error van mijn IIS6.x Firewall issue?

[Bor]

Handig dergelijke sites omdat men gelijk een lijst met aan te vallen servers kan aanleggen...

[Hans van Eijsden]

Mensen die PowerDNS gebruiken: don't worry, sinds 2006 is deze al niet vulnerable meer voor deze bug.

[zeroxcool]

Op de US-CERT site vind je de volledige lijst:

http://www.kb.cert.org/vuls/id/800113

Voor alle djb lovers, djbdns heeft 'zoals gewoonlijk' niets te vrezen . Kom maar met die flames .

* zeroxcool is ook djb lover...

[Parasietje]

Ok, graag.

De bovenstaande US-CERT addresseert de twee issues apart. De fix introduceert UDP source port randomization, en de allang bestaande fix voor glue records van non-authorative nameservers.
Voor het forgen van answers met evil glue records in, is deze fix NIET van toepassing.
PowerDNS en djb zullen langer standhouden tegen een poisoning. Maar geef me een uurtje en uw cache zal evengoed gepoisont zijn...

[Little Penguin]

Hoewel het belangrijk is dat de DNS server je naar de juiste server loods, is er voor algemene sites (t.net, /., nieuwssites, persoonlijke sites) waar je geen gegevens achter laat eigenlijk nog niet zo veel aan de hand.

Dit soort lekken zijn daarentegen wel mogelijk gevaarlijk voor e-commerce sites en banken e.d. Het is dus te hopen dat er vlug een nieuwe en betere patch komt die voorkomt dat er aan cache-poisioning gedaan gaat worden - voor zover dat eigenlijk wel mogelijk is binnen het DNS protocol zoals dat er nu is...

Als ik het goed begrijp is de lek in het asynchroon zijn van het request en het bijbehorende antwoord, als dit niet uit te zetten is dan moeten we met z'n alle misschein versneld op DNSSec over?

Edit - Jbib.net nog eens doorgelezen:
Aan de andere kant moet er wel een gerichte aanval gedaan worden op de DNS server zelf, waardoor de kans 1 op heel veel DNS-servers is dat er een aanval gedaan wordt...

[Reactie gewijzigd door Little Penguin op 27 juli 2024 11:50]

[elevator]

Je vergeet voor het gemak even dat zelfs op een simpele site als Tweakers.net er gegevens rond gaan (denk V&A, jouw mod punten / karma rating, moderatie rechten op het forum of nieuwspost rechten op de frontpage) waarvan je gewoon liever niet hebt dat ze bij iemand anders terecht komen.

[Little Penguin]

Natuurlijk is het vervelend als mijn gegevens van t.net door derden beheerd kunnen worden - t.net vraagt echter niet voor niets om een wachtwoord, zodat het hebben van een sessis-cookie niet voldoende is om die gegevens ook daadwerkelijk te wijzigen.

Een man-in-the-middle attack is echter altijd mogelijk en als je dan op dat moment nu net de gegevens gaat bijwerken, dan heeft men ook je wachtwoord.

Toch blijf ik erbij dat dit lek het gevaarlijkst is voor sites als PayPal en online banking...

[gassiepaart]

Wat wij tweakers misschien wel doen en velen daarvan waarschijnlijk ook niet, is per site een andere gebruikersnaam en zeker een ander wachtwoord kiezen.... Als je eenmaal userX met passwordY hebt kan je allerlei sites, zoals gmail, hotmail en paypal proberen. Ik schat dat 1 op de 5 pogingen van alle combinaties hier op tweakers ook vruchtbaar zijn op andere sites...

[Verwijderd]

Klopt, maar wat als ze de logingegevens van je (web)mail (ervan uitgaande dat je er maar één gebruikt) hebben? Ben je heel creatief bezig geweest met passwords verzinnen (en waarschijnlijk nog creatiever met ezelsbruggetjes om ze te onthouden ), maar via een 'forgot my password'-link komen ze er alsnog aan..

[freaky]

www.keepass.info (keepassx.sf.net)

Mijn grootste probleem is dat de meeste sites bijv. wel 40 karakter wachtwoorden accepteren bij het aanpassen c.q. aanmaken van de account, maar dat ze daarna niet werken. Meer dan 20 karakters geeft vaak problemen. 16 is redelijk veilig. Leestekens geven ook bij veel sites problemen.

[Verwijderd]

Toch blijf ik erbij dat dit lek het gevaarlijkst is voor sites als PayPal en online banking...

En dat is nu precies de reden waarom EVL-SSL certificaten zo successvol zijn met het tegenhouden van fraude, en waarom PayPal dus één van de eerste bedrijven was met zo'n certificaat.

Een hacker moet ontiegelijk veel moeite doen om de groene balk werkend te krijgen, ook al kunnen zo zowel de PayPal DNS omleiden als de certificaat servers.

[Jasper Janssen]

Maar een fake paypal site die gewoon op http draait en geen certificaat heeft is alleen maar te onderscheiden van de echte door iemand die erop let. 5% van de gebruikers dat doen is t al veel.

[dasiro]

een simpele community site zal niet direct het target worden van kwaadwilligen, die richten hun pijlen op financiële sites of sites waar effectief transacties gebeuren

[J.J.J. Bokma]

Misschien niet voor jou, maar er zijn tal van mensen die gewoon een exe downloaden van een nieuwsite als die nieuwsite maar hard genoeg roept dat het een patch is om veiliger te internetten.

[darkfader]

Ook om alleen informatie op te zoeken is het vervelend. Stel je voor dat wikipedia.org verwijst naar uncyclopedia of encyclopediadramatica

[Rixard]

Ik heb zojuist een probleem gehad om gmail.com te bereiken. Mogelijk dat dit ermee te maken had. Ik kreeg eerst een melding van microsoft (MSN) dat de pagina/ het domein niet gevonden kon worden. Later kreeg ik i.p.v. gmail.com een pagina met links en reclame!

[Little Penguin]

Ik denk niet dat er op dit moment een grote kans is dat er ook daadwerkelijk DNS-servers aangevallen worden - de kans is groter dat je spyware opgelopen hebt dan dat de DNS-servers van jouw ISP aangevallen zijn.

Ik zou dus maar eens beginnen om je computer te scannen en pas daarna DNS de schuld te geven.

Hoewel er natuurlijk altijd een kans is dat nu net jouw ISP de eerste is waarvan de DNS servers aangevallen zijn/worden.

[gassiepaart]

hehe... Je denkt dat je op tweakers reageert, maar stiekem zit je op mijn nep site...

[Rixard]

Het was ook mijn eerste gedachte dat het spyware kan zijn, maar het was een pc bij mij op het werk. Die pc's hebben absoluut geen spyware. Bovendien was het na 10 minuten ook weer voorbij.

[arjankoole]

heb je toevallig een ISA server in je netwerk tussen de pc's en de buitenwereld? Die hebben dit soort geintjes wel eens.

[Rixard]

@arjankoole: Dat zou het natuurlijk ook best kunnen verklaren!

[Jake V]

Zoiets had ik vanmiddag ook : ipv google ging ik naar gratisrealtone...snapte er niks van..
Inderdaad iets vergelijkbaars, of het er mee te maken had weet ik nu ook nog niet.

[Dutch2007]

en MS 2003/2008 DNS is niet affectec, woot eens een keer microsoft niet affected

[gertvdijk]

Niet waar.
link
Alleen een Itanium based 2008 server en Vista zijn niet vulnarable.

[Parasietje]

Heb je de link goed bekeken? Het security bulletin behandelt twee problemen.

1) DNS Insufficient Socket Entropy Vulnerability - CVE-2008-1447
Ok, ze hebben nu UDP source port randomization toegepast. Het duurt nu gewoon langer om de cache te poinsonen met bovenstaande exploit (32 bits instead of 16b).

2) DNS Cache Poisoning Vulnerability - CVE-2008-1454
In de CVE-database staat er dat dit een issue is voor glue records die niet tot de authority van de answering server behoren. Deze exploit doet dat niet, hier zijn de glue records wel authority van de responding (forged) nameserver.

Conclusie:
Het security bulletin zal niet beschermen tegen bovenstaande exploit.

* Parasietje buigt

[Kabouterplop01]

Dit gaat om ALLE DNS servers Van ANS tot BIND.
Als jouw nameserver het antwoord niet weet gaat deze een stapje hoger in de boom kijken. Tot in de ROOT toe. Het gaat om het DNS protocol inderdaad, dus alle DNS machines op de hele wereld.

[paella]

Nee, sommige DNS servers hebben het probleem niet. Veel wel.

[Little Penguin]

Zoals ik Jbib.net lees gaat het vooral om een ontwerpfout in het DNS-protocol, alle DNS servers zijn dus kwetsbaar - alleen waren diverse veel gebruikte DNS servers in het verleden kwetsbaarder dan andere.

Natuurlijk kun je nog proberen om lokaal een extra beveiliging toe te voegen zonde dat je het DNS protocol hoeft te veranderen - ik kan er zo 1 verzinnen, maar in hoeverre dat ook echt iets oplevert is de vraag ...

[DiedX]

Klopt niet. Onderaan wordt (terecht) aangegeven dat djdns niet lek is. Ik maak zelf gebruik van PowerDNS, ook niet lek.

Let wel: het protocol is lek, maar dat betekend niet dat mensen dit niet eerder wisten. Het werd alleen niet serieus genomen...

[Milt]

SimpleDNS ook niet... Alhoewel ze aan de hand van deze bugs nog wel een extra update hebben uitgebracht met verbeteringen. Maar de versie daarvoor was ook al veilig.

[Parasietje]

Milt, DiedX: waarom zijn die implementaties niet lek? Zover ik heb gelezen, is hun enige fix UDP source port randomization, wat enkel wat meer resilience geeft, maar geen echte fix is.

[Milt]

Deze implementaties doen er in ieder geval alles aan wat mogelijk is binnen de specificaties van het protocol om cache poisoning te voorkomen. En dat is niet alleen source port randomization, maar ook transaction ID randomization en geen multiple outstanding request. Theoretisch blijft cache poisoning echter altijd mogelijk.

[Little Penguin]

Hoewel de ROOT-servers in theorie ook kwetsbaar zouden kunnen zijn, hebben ze voor zover ik kan overzien toch geen last van dit lek.

De ROOT-servers cachen namelijk niet, ze servers alleen maar authoritative zones.

[thys]

Over welke DNS servers gaat dit? Root servers?

Lijkt me sterk dat het voor alle DNS servers is, precies dezelfde bug komt toch niet voor in software van verschillende makers?

Edit: na lezen van jbib blijkt de fout in het DNS protocol zelf te zitten

[Reactie gewijzigd door thys op 27 juli 2024 11:50]

[SKiLLa]

Nee, dit gaat vooral om DNS servers van ISPs. Met root-servers heb je als "gemiddelde" gebruiker weinig te maken. En het is ook geen software "bug", het is gewoon een kwetsbaarheid in het (sterk verouderde) protocol, net zoals spam en SMTP.

Lees gewoon de Jbib.net link er maar op na; daar staat het in hapklare brokken uitgelegd. Veel encryptie-hacks zijn ook te herleiden aan zwakke/slechte random-generatoren ...

[Nico de Vries]

Merk op dat sites met een valide SSL certificaat hiermee niet kunnen worden gekaapt. Mits men goed oplet zijn kritische sites als die van banken dus nog steeds veilig m.b.t. deze DNS hack.

[epic007]

http://www.ietf.org/rfc/rfc1034.txt DNS stamt uit 1987, dat er nu nog een kwetsbaarheid gevonden wordt..

[arjankoole]

in windows (no flame nor pun intended) werd een jaartje geleden een bug / security issue gevonden die er al in zat vanaf windows 3.11 (tot aan vista toe dus).

nog korter geleden een bug in de unix malloc, die er al ruim 30 jaar in zat

dat ie niet gevonden wordt, betekend niet dat ie er niet is.

[MLM]

Op zich komt het ook doordat het systeem veroudert is. Het feit dat DNS pakketjes maar 16b identifiers hebben (65536 mogelijkheden maar) is in het internet van 2008 een beetje verouderd...

In 1987 (30 jaar geleden) hadden de bedenkers vast ook niet gedacht dat 16b niet genoeg zou zijn....

(Goed, tegenwoordig kan je met port randomization naar 32b gaan, maar dat is ook maar uitstel natuurlijk )