Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 63 reacties

Het Internet Systems Consortium waarschuwt voor een kwetsbaarheid in de breed gebruikte Bind 9 dns-serversoftware. Door een gemanipuleerd ip-pakketje naar een dns-server te sturen zou een aanvaller deze onderuit kunnen halen.

Versie 9 van Bind, wat staat voor Berkeley Internet Name Daemon, is de meestgebruikte dns-server. Het Internet Systems Consortium stelt echter dat in een groot aantal versies uit de 9.x-serie een kwetsbaarheid is gevonden, die betrekking op zowel authorative als recursive Bind 9-servers heeft.

Volgens de ISC kan een aanvaller een Bind 9-server afsluiten door er een speciaal aangepast ip-pakketje naar te sturen. Hierdoor kan het dns-systeem in de problemen komen. De problemen treden op in zowel de 9.6x-, 9.7x- en de 9.8x-serie. Er zouden momenteel geen workarounds bekend zijn om dns-servers te beveiligen, al zouden firewalls met packetfilters aanvallen kunnen tegenhouden. De ISC stelt dat de beheerders van dns-server kunnen upgraden naar Bind 9.6-ESV-R4-P3, 9.7.3-P3 of 9.8.0-P4.

Moderatie-faq Wijzig weergave

Reacties (63)

Als ik wat verder zoek vind ik dat het uitzetten van 'recursion' al genoeg is. Wie heeft dat zowiezo aan staan? En anders toch minimaal met een ACL.
Daarmee is de angel nog niet voor alle publieke servers eruit gehaald. Denk aan caching/forwarders van ISP's. Nogal wiedes dat die recursion moeten doen. Daarnaast is een inside attack ook nog een mogelijkheid.

Edit:
Nice, Infoblox heeft reeds 33 dagen geleden deze exploit gepatched in hun eigen systemen. Infoblox is een DNS appliance, gebaseerd op bind.
Releasenotes over RESOLVED ISSUES IN 5.1r3-10

NIOS-30253 This release addresses the following vulnerability:
BIND 9: Denial-of-service vulnerability in recursive and authoritative DNS servers in which a
specially crafted packet sent to the servers could cause the “named” process to fail. (CERT
VULNERABILITY NOTE CVE-2011-2464). This issue affected NIOS 5.1r2-0 and later releases.

[Reactie gewijzigd door Dennizz op 5 juli 2011 18:14]

Denk aan caching/forwarders van ISP's.
Die gebruiken doorgaans al jaren geen bind meer, maar dnscache oid. (veel lichter/sneller dan bind)
NEE!
ISC heeft vandaag 2 advisories uitgebracht.

Het gaat hier om CVE-2011-2464 , niet om CVE-2011-2465 !!!

De eerste, waar hier op gedoeld wordt, kent geen workaround:
There are no known workarounds for publicly available servers. Administrators of servers that are not publicly available may be able to limit exposure via firewalls and packet filters.
Bron : http://www.isc.org/software/bind/advisories/cve-2011-2464

Dus ook als je recursion uit hebt staan, upgraden!!

edit: link naar bron

[Reactie gewijzigd door flabber op 5 juli 2011 18:07]

Hoe kom ik erachter of mijn host bind gebruikt? Want dan zal ik hem eens vertellen om te updaten.
Kleine kans dat dit werkt, but worth trying. Er bestaat een DNS query om de bind versie uit te lezen. Deze oer je als volgt uit:

Open DOS venster en voer de volgende commando's uit:

nslookup
server x.x.x.x (x.x.x.x = DNS server IP)
set q=txt
set class=CHAOS
version.bind.

Goede kans dat je een nxdomain (not existing domain) terug krijgt, of een bogus antwoord, zoals bij level3 :)

>server 4.2.2.2
>set q=txt
>set class=CHAOS
> version.bind.
Server: vnsc-bak.sys.gtei.net
Address: 4.2.2.2

version.bind text = "If you have a legitimate reason for requesting this info, please contact hostmaster@Level3.net"
Of met dig indien linux: dig @ip.adres.hier version.bind txt chaos
dig @localhost version.bind txt chaos
version.bind. 0 CH TXT "9.6-ESV-R4-P3"
:)
Ik heb geen Windows, en je bedoelt Command Line, niet DOS.
Gelukkig heeft OS-X ook het dig programma.

Wat ik dus terug krijg is:
version.bind. 0 CH TXT "9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2"

Welk dus een oude versie is die niet kwetsbaar is voor deze exploit(?)

[Reactie gewijzigd door Wolfos op 5 juli 2011 22:36]

Is die oude versie inderdaad niet kwetsbaar hiervoor? Heb namelijk ook een oude versie.
tuurlijk,

als je je bind niet beveiligd hebt dan kan dat ja.

Maar ik krijg

dig @localhost version.bind txt chaos

;; ANSWER SECTION:
version.bind. 0 CH TXT "0.0.0"

questie van "version "0.0.0"; in je bind zetten.

Stap 1 in je beveiliging, NOOIT je versies van je software openbaar maken.
Laat ze maar gokken die script kiddies..
Stap 1 van jouw beveiliging komt dus neer op "obscurity"? Goed plan.
Je moet een bepaald pakketje naar de DNS en direct erna een DNS query. Als de query niet werk gebruikt jouw hoster een verkeerde bind versie.
Ik zou eigenlijk gewoon upgraden naar iets anders dan BIND, wat al gedurende z'n hele levensduur een security risk is. En zodoende draai ik al jaren geen BIND meer.

[Reactie gewijzigd door CyBeR op 5 juli 2011 17:47]

gewoon upgraden naar iets anders dan BIND
Gewoon?
Er zijn diverse andere nameservers ( http://en.wikipedia.org/w...on_of_DNS_server_software ), maar zoals je kan zien in de vergelijking, zijn ze vaak opgezet voor een meer specifieke toepassing en missen er vele een of meer mogelijkheden die BIND wel biedt.
Tel daarbij het omzetten van zone files, eventueel aanleren van nieuwe syntax, configuratie en dergelijke en het wordt wel iets meer dan 'gewoon upgraden'.

En dan nog kan dat alleen bij systemen waar BIND als apart package is geinstalleerd. Alle *nix based appllances die ook BIND gebruiken zul je niet zo maar 'upgraden'
[...]


Gewoon?
Er zijn diverse andere nameservers ( http://en.wikipedia.org/w...on_of_DNS_server_software ), maar zoals je kan zien in de vergelijking, zijn ze vaak opgezet voor een meer specifieke toepassing en missen er vele een of meer mogelijkheden die BIND wel biedt.
Tel daarbij het omzetten van zone files, eventueel aanleren van nieuwe syntax, configuratie en dergelijke en het wordt wel iets meer dan 'gewoon upgraden'.
PowerDNS kan alles wat BIND kan (inclusief zone files lezen) op één ding na, en dat is split-horizon DNS. En laat dat nou iets vies zijn.
En dan nog kan dat alleen bij systemen waar BIND als apart package is geinstalleerd. Alle *nix based appllances die ook BIND gebruiken zul je niet zo maar 'upgraden'
True, maar hoeveel mensen gebruiken een DNS 'appliance', precies?

Anyway. BIND is nu nog de meest gebruikte omdat 't lange tijd de defacto-standaard was, net als Apache voor web servers. Het is gelukkig on the way out. Vooral PowerDNS wint aan populariteit.
Je vergeet DNSSEC wat pas sindskort in PowerDNS zit (en dan ook nog een beta volgens mij). Ik gebruik nu al een jaar of 7 PowerDNS met LDAP backend. Die backend wordt helaas niet meer doorontwikkeld, wat betekent dat DNSSEC alleen naar de LDAP backend komt als ik het er zelf in ga bouwen (en dat staat nog op de TODO). Sowieso bevalt database replication (LDAP sync replication is super) me een stuk beter dan dat hele gedoe met AXFR en master/slave servers.
PowerDNS kan alles wat BIND kan (inclusief zone files lezen) op één ding na, en dat is split-horizon DNS. En laat dat nou iets vies zijn.
Op Windows draaien kan het ook niet, in tegenstelling tot BIND. Gezien de MS DNS server zo flexibel is als een baksteen, is BIND de enige waardige oplossing. Hoe goed PDNS dan wel mag zijn, ik kan er niets mee aanvangen.
Voor mijn authorative servers draai ik ook alleen nog maar pdns, bind was leuk, maar behalve voor recursors en interne lan dns servers gebruik ik het in ieder geval niet meer...
Ik zou eigenlijk gewoon upgraden naar iets anders dan BIND, wat al gedurende z'n hele levensduur een security risk is. En zodoende draai ik al jaren geen BIND meer.
In alle software zitten wel een paar lekken, dat wil nog niet zeggen dat het per definitie slechte software is. Bind is in een hoop opzichten goed, en in een aantal opzicht minder fijne software. Qua security issues heeft ISC echter een goede staat van dienst. Ik gebruik bind nu al minsten 13 jaar, en het weet mij niet genoeg te irriteren om over te stappen. (ik heb met de meeste alternatieven al wel eens gespeeld)
Nou ik weet al wat ik vandaag ga doen. :P
Maar ik vraag me af hoe serieus ik dit moet nemen, zelfs al gaat de bind daemon op z'n gat dan is die in een paar seconden weer up.
Met een paar zones misschien wel, maar er zijn er genoeg die duizenden/tienduizenden zones serveren, daar duurt het 'even' voordat bind herstart is.
In mijn geval zijn het er ook maar een paar. Uiteraard als je er duizenden hebt dan duurt het wel wat langer ja.
Een paar seconden + de tijd die nodig is om in te loggen + rca uitvoeren (het ding crashed immers niet voor niets)

Dat kost toch meer tijd (en dus geld) dan even restarten.

[Reactie gewijzigd door psyBSD op 6 juli 2011 10:09]

Uiteraard moet er wel gecontroleerd worden waarom die crashed, maar dat wil niet zeggen dat ik vrolijk de log files ga doorlezen terwijl de service down is. Eerste prioriteit is de service online brengen en houden en vervolgens kijken waarom die down ging.
In het bron-artikel staat dat niet-publieke servers met firewalls afgeschermd kunnen worden, niet dat het speciale ip-pakketje geblokkeerd kan worden.
Nou ja, als KPN toch al die DPI klaar heeft staan, kunnen ze ook gelijk even alle ip-pakketjes die er zo uitzien simpelweg blokkeren ;)

Komen ze er toch nog even positief mee in het nieuws.

Vreemd dat ze dit overigens zomaar publiceren... bij de vorige grote BIND hack hadden ze het stilgehouden (de DNS groep althans, de computer-security groep heeft het binnen twee weken gelekt)
Vreemd dat ze dit overigens zomaar publiceren...
Zomaar?

Version 1.0 - 14 June 2011: Phase One Disclosure Date
Version 1.1 - 20 June 2011: Phase Two Disclosure Date with updates.
Version 1.2 - 21 June 2011: Updates on beta, RC, and clarity editing
Verison 1.3 - 21 June 2011: Sent Hold Notices to Phase I constituents, extended Acknowledgments
Version 1.4 - 23 June 2011: Updated -P versions to include Advanced Security Patches release to Phase I, and "Upgrade to:" versions
Version 1.5 - 24 June 2011: Added document URL, sent schedule update to Phase I constituents.
Version 1.6 - 28 June 2011: Updated Versions Affected, extended Acknowledgments, sent Phase I updates
Version 1.7 - 30 June 2011: Updated attribution text.
Version 1.8 - 4 July 2011: Phase Three and Four Disclosure Date
version 2.0 - 5 July 2011: Public Disclosure


Deze mensen gaan echt niet zomaar over 1 nacht ijs hoor!
Ik begrijp dat het niet leuk is als je DNS server afsluit, maar dan laat je hem toch gewoon in een scriptje loopen (als ie afsluit start ie zichzelf weer op)?
Als ze nou root toegang konden krijgen, maar dat is niet echt het geval...

Het is voor zover ik begrijp slechts een mogelijk ongemak, niet echt een gevaarlijk beveligingslek
Beveiliging stopt niet bij het installeren van een firewall of het hebben van en off-site backup. En het uitschakelen van DNS is meer dan slechts een ongemak.

Waarom? Er is geen data gestolen, verwijderd, openbaar gemaakt of iets dergelijks, toch?

Beschikbaarheid van data valt ook onder beveiliging.
En zonder DNS zullen veel verbindingen wegvallen, hoe je het ook went of keert.

Heel de nederlandse infrastructuur is afhankelijk van DNS: artsen, ziekenhuizen, apothekers, farmaceutische industrie, hulpdiensten, maar ook zaken als camerabewaking van wegen (ongevallen-/file detectie) en nog heel veel meer zaken.

Ik denk niet dat de wereld vergaat binnen een uur nadat de rootservers plat gaan, maar er zullen snel erg veel problemen opduiken.
het is nog nooit iemand gelukt de root-servers succesvol aan te vallen. nog nooit. Die dingen staan overal (en in clusters), en kunnen gigantische hoeveelheden requests aan.

De patch is al beschikbaar, ik durf te wedden dat de meeste rootservers voor het publiek live gaan van het probleem, die patch al hadden.
Een beveiligingslek is het zeker wel. Allereerst zijn de meeste systemen niet ingericht om BIND automatisch opnieuw op te starten. Deze workaround zal dan ook eerst door de beheerders geïmplementeerd moeten worden.

Daarnaast is het steeds onderuit laten gaan van het proces nog een redelijk effectieve denial of service attack.
Het gaat hier niet om standaard firewalls. Maar om deep packet firewalls. Bijvoorbeeld snort in combinatie met andere software. Deze kunnen wel de pakketjes er uit filteren. Als je een juiste filter in stelt natuurlijk.

OT: ik denk dat bind wel erg veel gebruikt word. Ver alle linux hosters gebruiken deze :s
Hoe lang gaat het duren voor bepaalde groepen gewoon dns servers gaan plat smijten.

edit: typo's

[Reactie gewijzigd door GuardMoony op 5 juli 2011 17:54]

Als je een juiste filter in stelt natuurlijk.
Aangezien ISC zelf zegt dat er geen workaround is, ben ik bang dat 'het juiste filter' wel eens zou kunnen betekenen dat je in de praktijk alle DNS requests blokkeert.
En dat zegt het ISC eigelijk ook: een packet filter firewall kan gebruikt worden om toegang tot de BIND server tegen te houden.
[...]


Aangezien ISC zelf zegt dat er geen workaround is, ben ik bang dat 'het juiste filter' wel eens zou kunnen betekenen dat je in de praktijk alle DNS requests blokkeert.
En dat zegt het ISC eigelijk ook: een packet filter firewall kan gebruikt worden om toegang tot de BIND server tegen te houden.
Nee, je kunt een slimme firewall gebruiken om te zien of iets een goed of slecht (invalide) DNS pakketje is. Alleen de slechte drop je dan.
Ik lees: als er een vervormd pakketje verstuurd wordt naar bind, is dat niet goed.

Maar wat kan er fout gaan? Of is "het onderuithalen van Bind" het enige?
Als je Bind er uit ligt dan doet DNS het niet en val je effectief van internet af.
In een thuis-netwerk betekend het dat je internet het niet meer doet (al draaien normale mensen natuurlijk geen eigen DNS-server).
Voor bedrijven kan het betekenen dat hun website en e-mail onbereikbaar worden.
Beetje aparte bewoording. Je valt niet van het internet af, de koppeling tussen domein en ip valt weg. De server waar naar verwezen wordt, is nog gewoon op internet en nog altijd bereikbaar....alleen niet via het naampje, maar via ip. Nee, daar heb je niet veel aan :)

Gelukkig werken verreweg de meeste ISP's met caching DNS-servers en heeft ieder domein een TTL (meestal een dag). Het is dus niet zo dat je per definitie voor alle bezoekers direct wegvalt en compleet van internet 'afgevallen' bent.

Vervelend is het natuurlijk wel...

[Reactie gewijzigd door EnigmA-X op 5 juli 2011 19:38]

Hoezo heb je alleen aan het IP niets? Je kan met het betreffende IP netzo veel, als met de domain die aan het betreffende IP hangt.

/edit
Aan die over een vhost zeuren, Dit valt gewoon onder de HTTP specs. Je browser connect gewoon met het IP en vraagt vervolgens de betreffende host op.

Dan die het hebben over, weet je IP van deze site of die. Om eerlijk te zijn, ik weet de meeste websites niet uit mijn hoofd.

[Reactie gewijzigd door wica op 5 juli 2011 22:54]

En hoeveel sites maken er gebruik van vhost'ing denk je?
Natuurlijk kun je http://xx.xx.xx.xx/ in je browser opgeven, maar helaas zal menig webserver toch echt niet weten wat 'ie met je query aanmoet omdat de hostheader ontbreekt.

En een IP adres hebben is erg leuk, maar zonder DNS moet je alle zonefiles van alle nameservers op internet hebben wil je dat IP adres opzoeken.
Weet je toevallg het ip adres van www.googlelabs.com uit je hoofd? Of van de ntp1.nasa.org?

En wat dacht je van antispam maatregelen? Zonder de mogelijkheid tot DNS queries valt een groot deel van alle antispam maatregelen weg.

En laten we het dan maar helemaal niet hebben over IPv6 adressen.

Nee, het is leuk als je vanuit huis een telnet op kan zetten naar een mailserver die je toevallig kent en vervolgens handmatig je SMTP sessie afhandelt van HELO tot afsluitende punt, maar in de praktijkkun je niet zonder DNS.
SPF record en gelijke, horen naar mijn mening niet thuis in DNS.
En IPv6 is maar 32 char lang, wat in de meeste gevallen nog af te korten is ook.

Ik zeg niet dat het ideaal is, maar om te zeggen dat je alleen met een IP niets kan, gaat mij te ver.
SPF record en gelijke, horen naar mijn mening niet thuis in DNS.
SPF is leuk, maar inderdaad nog niet echt heel erg praktisch qua inzet.
Maar ik dacht meer aan standaard controles als double reverse lookups en alle (openbare) RBL lijsten op internet.
Weet jij dan het bijbehorende ip van alle domeinen die je gebruikt uit je hoofd? Denk het niet ;) Het ontbreken van DNS is dus best vervelend hoor.

Ontopic: Vervelende kwetsbaarheid dit waar zo te lezen inderdaad nog niets aan te doen is voor publieke DNS servers. Goede monitoring lijkt me belangrijk en kan wat pronlemen voorkomen, maar ja als iemand je eenmaal in het vizier heeft en dit soort pakketten blijft sturen dan is het wel snel afgelopen natuurlijk.
Errrr, Een webserver hangt aan een IP. een Website hangt echt aan een hostname vast.

Dus als je DNS er uit ligt moet je wel eerst je c:/windows/system32/drivers/etc/hosts file de ip addressen en de bijbehorende hostnaam in kloppen om bijvoorbeeld bij tweakers te komen. (edit) To flabber: Zo dus

http://213.239.154.35
Wrong host
The host 213.239.154.35 is not known on this location
Apache at tweakers.net (Ares)

offtopic edit:
Hoe veel procent haalt eigenlijk internet en world wide web door elkaar. of denkt dat het het zelfde is.

[Reactie gewijzigd door daft_dutch op 6 juli 2011 20:13]

/edit
Aan die over een vhost zeuren, Dit valt gewoon onder de HTTP specs. Je browser connect gewoon met het IP en vraagt vervolgens de betreffende host op.
Het is geen gezeur. Je bewwert zelf:
Je kan met het betreffende IP netzo veel, als met de domain die aan het betreffende IP hangt.
Dus stel ik de vraag : HOE krijg jij je browser zo ver dat 'ie connect naar een IP adres en wel een hostheader meestuurt?
Ik ben prima in staat om HTTP/1.1 te 'praten' via telnet of met fetch, wget of een andere tool een webpage op te halen, maar gewoon praktisch browsen zonder DNS?

De noodzaak van een werkend en betrouwbaar DNS wordt nog eens onderstreept door de ontwikkeling/invoering van DNSsec.
Caches en monitoring niet vergeten he ;)
Yup, maar das meer dan genoeg, aangezien dat een vrij effectieve DoS attack kan zijn voor het onbereikbaar maken van een domein.

@johnkeates
Klopt, maar niet alles leeft in cache. Daarnaast kan ik me voorstellen dat je, door continue de attack packets the playen, de server wel effectief onbruikbaar kan maken, omdat je daemon steeds aan het herstarten is.

[Reactie gewijzigd door Dennizz op 5 juli 2011 19:51]

Je hebt dan altijd nog de TTL die zorgt dat je in de caches blijft, en meestal heb je ook een instelling voor zones om ze zelfs als de authorative server plat is de chaches overal een tijdje langer te laten leven. Plus, als je een beetje server hebt, gebruik je een systeem dat je daemons controleert. Op sommige servers gebruik ik zelfs launchd van Apple om dingen in de gaten te houden, het is een stuk actiever dan passive meetresultaten van munin/cacti of nagios.
en meestal heb je ook een instelling voor zones om ze zelfs als de authorative server plat is de chaches overal een tijdje langer te laten leven.
Je hoeft maar 1 pakketje te sturen, dus een beetje exploit doet eerst een NS query om de secondaries/slaves op te vragen, legt dan de server plat en gaat verder met de slaves.

En wie weet, zitten er tussen al die duizenden caching nameservers waarop iedereen nu lijkt te vertrouwen wel heel mischien ook een paar BIND servers?
Hmm dit is niet echt wenselijk zeg maar. Zeker omdat er geen workarounds zijn en een firewall leuke kosten met zich mee brengt (not). Ach wie online wilt zijn zal zich moeten beveiligen tegenwoordig :)
Zoals FiscBiker hieronder al aangeeft, een firewall heeft geen enkele zin.
Het gaat hier om een kwetsbaarheid die diep in het protocol en de wijze waarop BIND deze geimplementeerd heeft zit.
Omdat BIND in ook in erg veel appliances gebruikt wordt voorzie ik een grote hoeveelheid upgrades; er mag nu nog geen bekende exploittool bekend zijn, maar zodra die er wel is, zullen niet gepachte nameservers om de haverklap worden getroffen ben ik bang.
Een goede firewall moet het wel tegenhouden. De tijd dat alleen naar IP en poort nummers werd gekeken is achter ons.
De laatste keer dat ik een firewalls beheerde vulde je het protocol in dat je wil doorlaten en hield de firewall niet goed gevormde pakketjes tegen. En dat was 6 jaar terug.
Jij hebt het over een firewall die DPI (Deep Packet Inspection) doet.
Behalve dat zulke firewalls nog steeds redelijk duur zijn en vrij veel beheer vragen is het nog maar de vraag of er een eenduidige "signature" is op te stellen waarmee de gemanipuleerde IP packetjes te herkennen zijn waar het hier over gaat.
Update voor het artikel: ik heb op Ubuntu 11.04 zojuist al een patch binnen gehaald.
De kracht van Open Source!

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True