ISC waarschuwt voor beveiligingslek in dns-servers

Experts waarschuwen voor een BIND 9-exploit die gebruikt kan worden om deze dns-software te laten crashen. Het ISC, dat BIND onderhoudt, adviseert systeembeheerders om hun servers per direct van een upgrade te voorzien.

De exploit zou gebruikmaken van de dynamische-updatefunctie van de BIND-dns-server. Volgens het Internet Systems Consortium zijn alle servers vatbaar die als master voor een of meer zones zijn geconfigureerd. Voor zover bekend is er nog geen workaround beschikbaar, stelt het ISC. De enige effectieve bescherming is om nsupdate-berichten tegen te houden, maar dat vereist een firewall die tot deep packet inspection in staat is.

Het ISC raadt beheerders aan om per direct te upgraden naar versie 9.4.3-P3, 9.5.1-P3 of 9.6.1-P1. Deze BIND-versies zouden niet vatbaar zijn voor de exploit, die inmiddels veelvuldig in het wild zou voorkomen.

BIND is de de facto standaard voor dns-serversoftware. Het programma is begin jaren tachtig ontwikkeld door studenten van de Berkeley-universiteit. In 2000 verscheen versie 9, die geheel opnieuw was opgebouwd, onder meer om een einde te maken aan alle beveiligingsissues die zich in de loop der jaren hadden gemanifesteerd.

Reacties (41)

[Anoniem: 307386]

Jeej, we zullen met zen allen weer browsen naar russische namaak bank-websites. DNS-hacking is echt iets vies er kan enorm veel mee gedaan worden door gewoon de URI naar een ander ip te leiden.

Ik stop het e-banking voorlopig even, overweeg het zelf ook zou ik zo zeggen.

[Electrowolf]

Deze exploit heeft weinig met "DNS-hacking" te maken:

een BIND 9-exploit die gebruikt kan worden om deze dns-software te laten crashen

De exploit kan je dus beter zien als een goed middel om servers plat te leggen, niet om ze te manipuleren. De makkelijkste criminele activiteit die je hiermee kan associëren is denk ik het bedreigen van een ISP met het platleggen van hun DNS servers zodat hun klanten niet meer normaal kunnen browsen.

[Keypunchie]

Lijkt me makkelijker om dan de URL en het IP van je bank in je hostsfile te stoppen... weet je zeker dat hij nooit gehijacked wordt*...

Zo vaak verandert je bank niet van webserver.

*tenminste, als je lokale systeem niet gehijacked word. Nog meer secure: Aparte linux-bak alleen voor internetbankieren., na configuratie hosts-file het filesysteem op read-only zetten. Knappe hacker die je dan nog te pakken krijgt :-)

[Reactie gewijzigd door Keypunchie op 12 augustus 2024 20:32]

[blorf]

Windows heeft die hosts file ook.
Volgens mij was het c:/windows/system32/drivers/etc/hosts
Maar kun je niet gewoon het ip van je bank uit het hoofd leren? Lijkt me wat eenvoudiger.

[smartsys]

Dan werkt het SSL certificaat niet.

[ASS-Ware]

Dan werkt het SSL certificaat niet.

Dat werkt dan wel, het wordt alleen lastiger, je moet hem dan met de hand accepteren.
Wat er wel mis kan gaan is dat er middels hostheader records meerdere websites achter 1 IP adres worden gebruikt, dan gaat het IP adres niet werken.

[blorf]

Oh, werkt dat niet? Ik heb hem ooit wel eens gebruikt toen coolwebsearch.com nog aan de weg timmerde en iedereen altijd achter mijn pc zat. Nu geen Windows meer. Maar SSL had ik toen nog nooit van gehoord.

[Reactie gewijzigd door blorf op 12 augustus 2024 20:32]

[Anoniem: 146814]

Ja, ik zal m'n oma uitleggen dat ze voortaan op die manier moet internetbankieren.

[Daco]

wrm zou je dat moeten doen? je stelt het gewoon in voor haar o_O;

[_BladE2k_]

Kijk je kan het natuurlijk een beetje overdrijven / paranoide reageren, maar als je maar een *klein* beetje oplet waar je naar toe surft, dan merk je vaak al wel verschillen met de werkelijkheid en/of 'vreemde' zaken.

Ongeacht welke website, is het gewoon erg belangrijk of jij 'rare' dingen ziet en/of herkent. Nu zal het voor de NL websites al een stukje minder zijn qua spoofing, maar sites zoals PayPal worden toch met regelmaat 'nagemaakt'. De namaak is vaak heel makkelijk te herkennen, door bijv links die allen naar 1 pagina verwijzen, info die niet op plekken staan zoals je dat gewend bent etc etc.

Dus in plaats van tegelijk te stoppen, kijk gewoon waarmee je bezig bent, dan heb je 99% van de namaak zo herkend.

[robvanwijk]

Was het niet zo dat de meeste spoofing / phishing sites een man-in-the-middle aanval uitvoeren? Alle requests die jij naar ze toestuurt sturen ze lekker door naar de echte site, en alle replies die ze van de echte bank terugkrijgen worden doorgestuurd naar jou.
Het "forwarden" gebeurt net niet 1-op-1; als jij een overschrijving aanmaakt wordt het rekeningnummer van de ontvanger vervangen door een (russische/nigeriaanse/zwitserse) rekening van de eigenaar van de spoofing site en als de bank een pagina stuurt met daarin rekeningnummers dan worden die keurig vervangen door de "originele" rekeningnummers zoals jij ze ingevoerd had. Op dezelfde manier kunnen de bedragen die worden overgemaakt verhoogd worden.
Hij het bij andere banken zit weet ik niet precies, maar de TAN-code smsjes van de Postbank proberen dit te voorkomen door in het smsje het totaalbedrag te vermelden en (bij voldoende hoge bedragen) het rekeningnummer van de ontvanger.

Probeer dat maar eens te herkennen! In zo'n geval zijn certificates echt je enige verdediging...

Meeste informatie afkomstig uit een lezing van iemand van de Postbank een jaar of twee geleden

[brompot758]

Gewoon even het certificaat checken. De beveiliging bestaat niet alleen uit DNS. Natuurlijk is DNS hacking vies, maar dat wil niet zeggen dat elke server in de wereld nu ineens gefaked is.

[Nickname55]

Ik lees dat het mogelijk is de server te laten crashen, niet dat het mogelijk is om verbinding om te leiden.

[Anoniem: 307386]

Mmm na verder gekeken te hebben, inderdaad, maar ik stel me echter de vraag wie er in godsnaam op komt om een assert te schrijven bij het afhandelen van packet requests. Op die manier kan je natuurlijk heel snel het programma laten stoppen met werken.

Er wordt inderdaad geen buffer ofzo afgehandeld dus het gaat hier idd puur om een DDoS attack. Volgende keer zal ik eerst nakijken wat de bug nu eigenlijk inhoudt vooralleer ik er een opmerking over schrijf

[CAPSLOCK2000]

Mmm na verder gekeken te hebben, inderdaad, maar ik stel me echter de vraag wie er in godsnaam op komt om een assert te schrijven bij het afhandelen van packet requests. Op die manier kan je natuurlijk heel snel het programma laten stoppen met werken.

Ik heb er verder ook niet naar gekeken, maar ik denk eigenlijk dat die assert een erg goed idee was. Het programma crasht nu op de assert, en dat is precies waar een assert voor bedoeld is. Zonder de assert was het programma doorgedraaid met "foute" data en was het wel ergens anders gecrasht. Nu gebeurt het op een gecontroleerde manier, zonder dat het gebruikt kan worden om in te breken op computer.

[Anoniem: 307386]

Uiterst goed dat iedereen in dat bedrijf dan zonder internet zit.

Dit is helemaal geen goede manier om de fout af te handelen, men moet hier rekening mee houden, en niet redeneren dat als 1 iemand iets verkeerd doorstuurt dat heel het bedrijf/organisatie of meervoud van deze zonder internet zullen zitten.

Dit is naar mijn mening een compleet verkeerde aanpak.

De rede waarom ik dit vind is omdat een assert in c++ gewoon op waarde 0 checkt en indien dat het geval is dan stopt het programma, je kan dus evengoed dit schrijven:

if (checkValue == 0) {
handleError(whatever_parameters_you_need);
}

Deze manier van programmeren heeft geleidt dat het programma op zich een slechte reputatie gekregen heeft en erger ervoor geleidt dat vele bedrijven zonder internet zitten omdat de programmeur dacht van het programma gewoon te sluiten in plaats van de fout op een deftige manier af te handelen.

Ik ga dus helemaal niet akkoord met wat jij hier goed vindt. Het is inderdaad beter dan strcpy(myOverflowableBuffer, value); maar verre van een goede of beter gezegd doordachte oplossing!

Ja ik ben te algemeen door te zeggen "zonder internet"

[Reactie gewijzigd door Anoniem: 307386 op 12 augustus 2024 20:32]

[CAPSLOCK2000]

Ik heb dit specifieke stuk code niet bekeken, dus misschien dat ze hier iets heel geks doen, maar...

Normaal gesproken gebruik je asserts alleen voor dingen die je zelf onmogelijk acht. Als je assert triggered is er iets zo enorm mis dat je het redelijkerwijs niet meer op kan lossen.

Als er een mogelijkheid is om het probleem te herstellen, dan moet je die fout inderdaad opvangen en verder gaan.
Als het echter niet mogelijk is om het probleem op te lossen, dan kun je beter het programma gecontroleerd afbreken dan maar proberen door te draaien.

[Sfynx]

Als er een mogelijkheid is om het probleem te herstellen, dan moet je die fout inderdaad opvangen en verder gaan.
Als het echter niet mogelijk is om het probleem op te lossen, dan kun je beter het programma gecontroleerd afbreken dan maar proberen door te draaien.

In feite dus net zoiets als een kernel panic, maar dan op applicatieniveau Want als een kernel te maken krijgt met geheugencorruptie o.i.d., is het meestal ook over en uit, met als je geluk hebt een memorydump.

Als er iets misgaat buiten de applicatie, waar de applicatie geen invloed op heeft, kan het soms erg lastig of onmogelijk zijn om daar omheen te werken omdat je niet op iets kan anticiperen wat mogelijk onvoorspelbaar gedrag vertoont.

[Reactie gewijzigd door Sfynx op 12 augustus 2024 20:32]

[robvanwijk]

In een perfecte wereld, waarin programmeurs oneindig veel tijd en geen deadlines hebben, zou je gelijk hebben.

In het echt kost het schrijven van tientallen handleError() routines echter vreselijk veel tijd. Wat een assert() eigenlijk doet (ik heb de source niet bekeken, dus ik kan niet garanderen of dat echt de bug is in BIND9) is:

criticalValue = someSubroutine ( params );
// someSubroutine should never fail, criticalValue should never be zero
if (criticalValue = 0)
{
// if this code executes something really weird is happening
exit ( ASSERT_FAILED );
}

Is dit perfect? Nee, als je het perfect wilt doen dan zul je moeten bewijzen (op de wiskundige, waterdichte manier) dat die someSubroutine() inderdaad nooit 0 kan returnen. Maar, zelfs in dat geval zou ik er zelf voor kiezen om de assert() te laten staan: het kost weinig CPU-tijd en ik heb nog altijd liever een gecontroleerde crash, die exact aanwijst welke assert() fout ging (en dus welk bewijs kennelijk toch een fout bevat) dan ongecontroleerd verder draaien en we zien wel wanneer we ongecontroleerd crashen en of er misschien iets te exploiten is voor die tijd. Bovendien, zelfs al is dit niet perfect, het is vele malen beter dan de implementatie die meestal gekozen wordt:

someSubroutine ( params );

waarbij de returncode letterlijk weggegooid wordt en er überhaupt niet gecontroleerd wordt of er iets onverwachts is gebeurd!

[Anoniem: 174621]

Het idee van assert is oorspronkelijk dat dit een precompiler trucje is. Als je de build configuratie goed instelt, dan wordt tijdens het compileren de hele check uit het programma gegooid.
Asserts zijn bij uitstek bedoeld om de interne consistentie van het programma tijdens het testen te bewaken. Als je tests uitputtend genoeg zijn, dan ga je "alle" mogelijk codepaden door en dan kunnen asserts je in een vroeg stadium op een fout wijzen...

[arjankoole]

Jeej, we zullen met zen allen weer browsen naar russische namaak bank-websites. DNS-hacking is echt iets vies er kan enorm veel mee gedaan worden door gewoon de URI naar een ander ip te leiden.

Je opmerking is nogal onzinnig in deze context, daar deze exploit alleen gebruikt kan worden om Bind te laten crashen met een speciale dynamic update request. Ze kunnen er geen remote access mee krijgen, en geen valse informatie in gooien.

Het is dus leuk bruikbaar om te pesten, en een DoS mee te veroorzaken, maar ik denk dat op dit moment alle vitale nameservers allang geupdate zijn. (Ik zag de BSD Cert announce gisteren al, en alles is toen direct geupgrade)

[CAPSLOCK2000]

Je opmerking is nogal onzinnig in deze context, daar deze exploit alleen gebruikt kan worden om Bind te laten crashen met een speciale dynamic update request. Ze kunnen er geen remote access mee krijgen, en geen valse informatie in gooien.

Deze exploit kan wel worden gebruikt worden als "assistent" voor andere hacks. Als een domein 2 nameservers heeft, en je weet de ene te kraken, en de andere draait Bind, dan kun je die andere crashen en zo iedereen dwingen om de gekraakte server te draaien.
(Dat die ene server gekraakt kan worden is natuurlijk een veel groter probleem, maar dat terzijde).

[arjankoole]

leuke theorie, maar er zijn meer eenvoudige methoden

[lamko]

Gister al een update van Ubuntu gehad voor Bind dat zal deze dus wel geweest zijn.

[Keypunchie]

Het probleem met DNS is dat je er weinig aan hebt als je *zelf* update. Iedereen anders die name-servers draait moet ook updaten...

[brompot758]

Dat is voor deze bug niet waar. Het is een DOS attack, geen overname, poisoning e.d. Hooguit dus dat je bepaalde zones niet kan bereiken.

[Hakkow]

..Voor zover bekend is er nog geen workaround beschikbaar, stelt het ISC...

...raadt beheerders aan om per direct te upgraden naar versie 9.4.3-P3, 9.5.1-P3 of 9.6.1-P1. Deze BIND-versies zouden niet vatbaar zijn voor de exploit..

Dan is er toch een oplossing? Of zitten er ook nadelen aan een versie upgrade?

[arjankoole]

een workaround is dat je zonder upgraden / patchen toch niet kwetsbaar bent. (door een instelling of ACL bijvoorbeeld)

er is dus geen workaround, maar wel degelijk een fix.

[blorf]

http://security.freebsd.o...FreeBSD-SA-09:12.bind.asc

II. Problem Description

When named( receives a specially crafted dynamic update message an
internal assertion check is triggered which causes named( to exit.

To trigger the problem, the dynamic update message must contains a
record of type "ANY" and at least one resource record set (RRset) for
this fully qualified domain name (FQDN) must exist on the server.

Het is dus alleen irritant voor instanties die DNS caching-servers hebben draaien en daar ook echt van afhankelijk zijn.
Thuis ben je gewoon je lokale named service kwijt. Internet zal misschien iets langzamer worden omdat er niet meer gecached word.
Voordeel voor hackers als dat ding in de weg zit en in een jailed omgeving draait dat ie toch (tijdelijk) verwijderd kan worden
Sysadmins kunnen in geval van nood een scriptje schrijven om het named proces in de gaten te houden en een eventuele crash op te vangen.

[Reactie gewijzigd door blorf op 12 augustus 2024 20:32]

[CAPSLOCK2000]

Het is dus alleen irritant voor instanties die DNS caching-servers hebben draaien en daar ook echt van afhankelijk zijn.

De exploit op zich is inderdaad niet meer dan irritant, en makkelijk te omzeilen. Toch zie ik wel een paar aardige mogelijkheden om er onheil mee te zaaien. Als DNS blijft crashen is het voor de systeembeheerders een stuk moeilijker om uit te zoeken wat er aan de hand is, want ze kunnen niet internetten.
Een competente systeembeheerder komt er ook zo wel achter, en weet ook wel hoe hij het moet oplossen, maar er zijn nogal wat pruts beheerders.

[tjempeng]

De exploit betreft alleen tegen een master dns server die 1 of meerdere zones host.
Dus een beetje goeie ISP zorgt ervoor dat de master achter een goeie firewall staat en dat hij/zij in ieder geval 1 of 2 slaves heeft draaien. In het geval de master toch onderut wordt gehaald dan heb je nog altijd je slaves draaien die gequeried kunnen worden. En wil je het helelmaal goed doen dan maak je de master gewoon stealth.

[Roxsman]

Ik snap alleen één ding niet: Je kan een deep inspection firewall gebruiken of upgraden naar de laatste versies om het op te lossen, en daarna wordt er gezegd dat er geen workaround beschikbaar is. Wat zijn die 2 oplossingen dan?

Ik bedoel, ik heb zelfs thuis een deep inspection firewall draaien dus zo speciaal is dat nou ook weer niet.

[blorf]

Dan moet die firewall wel op de hoogte zijn van die exploit van gisteren. Je kunt packets zo diep inspecteren als je wil maar als je niet weet waar het over gaat weet je ook niet wat niet toegestaan is.
Buiten dat denk ik dat ze in de unixwereld onder een workaround een methode verstaan waarbij geen downtime van een bedrijfskritische service mag voorkomen.

[Reactie gewijzigd door blorf op 12 augustus 2024 20:32]

[Sfynx]

upgraden naar de laatste versie is natuurlijk nooit een workaround, dat is namelijk de definitieve oplossing

[Bacchusius]

Het wordt tijd dat we overgaan op DNSSEC.

[arjankoole]

DNSSEC had hier absoluut niet tegen geholpen.

[CAPSLOCK2000]

Volgens mij wel. Met DNSSEC zou een DNS server zo'n misvormd berichtje niet eens aannemen.

[blorf]

Dat snap ik niet. DNSSEC ziet toch alleen een bericht voor de server voorbij gaan die doorgelaten moet worden? Je kunt natuurlijk alle berichten met die kenmerken blokkeren, maar dan komen sommige goeie berichten ook niet aan.

[CAPSLOCK2000]

Ik weet niet zo veel van DNSSEC, dus misschien zit ik er naast. De fout zit in het zone-transfer gedeelte. Met DNSSEC kun je controleren of die transfer wel uit een betrouwbare bron komt. Een willekeurige kraker is natuurlijk niet betrouwbaar, en die berichten worden dan niet geaccepteerd.

[Roxsman]

Daarbij kan dan wel weer gezegd worden dat bijna nergens 1 dns server gebruikt wordt. Je hebt dus altijd de mogelijkheid om zonder downtime één voor één servers up to date te brengen. Maar dat om te miereneuken, ik snap je punt