Aktuelle DNS Poisoning Sache

worel

Well-Known Member
Hi!

Ihr habt es sicher schon auf heise oä. gelesen, dass wieder mal eine allumfassende Sicherheitskeule um sich greift. Betrifft DNS und eine angebliche Cache Poisoning Attacke, welche aber noch nicht öffentlich verfügbar ist.

Was ich so mitbekommen habe sind etliche DNS Implementierungen betroffen, ein Design Fehler per se. Also Bind usw., wobei Bind8 NICHT gepatcht wird, Bind9 schon. Update auf die neueste, sichere Version ist ja nicht das Problem.

ABER: es gibt auch Patches für Clientsysteme welche DNS Abfragen fahren wie z.B. Ubuntu oder WinXP (Vista interessanterweise nicht), da auch deren DNS Cache angegriffen werden kann. Ich hab zwar keine Ahnung wie das gehen soll und wie dieser Angriff im Detail aussieht, wenn jemand ne Beschreibung hat wäre ich dankbar dafür.
Aber für FreeBSD habe ich noch nichts gefunden. Weder ein Advisory noch ein Update. Äh, wie siehts da nun aus? Nicht betroffen oder "wir wissen von nichts"?

Wiegesagt, die DNS Serversoftware ist mir klar, aber was ist mit den Clients? Anscheinend gibts da auch "Grund zum patchen"...
 
wenn du auf absolute nummer sicher gehen willst, dann lege dir am besten eine /etc/hosts an, wo du folgendes reinschreibst:

Code:
212.204.60.79 www.bsdforen.de bsdforen.de
195.140.127.130 www.sparkasse.de sparkasse.de
...

damit wird fuer deine wichtigen internetseiten kein dns-request mehr ausgeloest. stattdessen guckt der erstmal lokal bei dir nach.
 
Aber für FreeBSD habe ich noch nichts gefunden. Weder ein Advisory noch ein Update. Äh, wie siehts da nun aus? Nicht betroffen oder "wir wissen von nichts"?

Das Security-Team wurde nicht im Vorraus informiert, wie andere Security-Teams. An nem Patch wird bereits gefrickelt.
 
Außerdem, solche Sachen werden immer heißer gekocht als gegessen. Bis das ganze wirklich im großen Stil gezielt für Angriffe ausgenutzt wird, dürfte es noch einige Tage dauern, bis dahin ist sicher längst der Patch da. Der ganz hysterische Nutzer kann sich einen gepatchten BIND9 aus den Ports installieren...

Remko Lodder schreibt in seinem Blog dazu auch:
As people most likely already found out, there is a problem with DNS, and there was already a problem for some extensive time with DNS. There is the possibility to spoof the reply’s returning from a DNS server.

Beyond that, some discussion was raised last night with regard to the responsiveness of the FreeBSD Security Team.

The FreeBSD Security Team is a team of people, that were picked from a volunteer pool out of the FreeBSD Development Community. These volunteers, analyse, patch and create an advisory for incoming security problems. The latter is only done ofcourse after verifying that it is really a security problem.

The moment the FreeBSD Security Team enters an advisory stage, a lot of time investment is required. Which we ofcourse do not mind but it’s something that should be emphasized. For example, patches need to be generated, tested etc. Then after that the FreeBSD-Update builds have to be started and in parallel we also write the advisory.

The advisory is proof-read by multiple people, and the FreeBSD-Update process takes time to deliver the required patches. Because of that we need a little time to do the job right.

We also want to take the time, the moment something comes in, we properly need to evaluate the incoming items, and see whether it would harm the -RELEASE branches or not. Our -RELEASE branches are not something we would like to mess with if it generates a regression. We try to prevent that or emphasize that this will be the case after a required update.
 
Außerdem, solche Sachen werden immer heißer gekocht als gegessen.

Ich find, dass das dumm gelaufen ist. Extrem dumm sogar. Dan hat zum Glück eine längere Zeit angesetzt, um einen Exploit und nähere Erläuterungen zu veröffentlichen. Andere sind da nicht so fair.
Was ich als viel schlimmer einstufe ist die Tatsache, dass FreeBSD aussen vor ist, wenn ein wichtiger Patch von vielen Herstellern koordiniert ausgegeben wird. Das darf nicht passieren.
 
Ja, da hast du recht. Das war bescheuert. Nicht zuletzt auch deshalb, da FreeBSD das Betriebssystem ist auf dem eine nicht unwesentliche Anzahl an DNS-Servern läuft und auf welchem ISC das Ding entwickelt.
 
Ja, da hast du recht. Das war bescheuert. Nicht zuletzt auch deshalb, da FreeBSD das Betriebssystem ist auf dem eine nicht unwesentliche Anzahl an DNS-Servern läuft und auf welchem ISC das Ding entwickelt.

Ähnliches ging mir auch durch den Kopf. Es hat einen bitteren Nachgeschmack, auch wenn es hier nicht um eine Schwachstelle in einer SW geht, sondern um einen generellen Designfehler. Grad isc...
 
Versteh ich auch nicht die Sache dass BSD generell (alle?) nicht vorab so wie die größeren Hersteller informiert wurden. Hier wurde wohl etwas gepfuschet, aber man muss schon auch sagen dass abgesehen davon, die ganze Geschichte ziemlich koordiniert ablief.

Bzw.: auch ich stell mir schön langsam die Frage welches Schadenspotential dieser Flaw echt hat. Ok, ist unangenehm und es betrifft ALLE (sogar die big boys), aber wie hoch ist die Wahrscheinlichkeit dass etwas passiert im Vergleich zu einem grindigen openssl patch von debian ;-)
So wie ich das mitbekommen habe müsste ja wie beim ARP Poisoning der Angreifer auch den Verkehr direkt abfangen und injecten können, was vorraussetzt, dass ich mich im Netz des Opfers befinde (Internet gilt nicht :D ) Korrigiert mich wenn ich falsch liege...
 
Ganz einfach. Wenn zum Beispiel der DNS Eintrag von $BANK eine lifetime von 604800 hat und du einen DNS-Server _einmal_ dazu bringst als Auflösung die IP von $BÖSE_HAX0RSEITE auszugeben, dann wird der Eintrag zwischengespeichert und die nächsten 604800 Sekunden lang ausgegeben. Und das muss nicht im eigenen Netz passieren. Es reicht, wenn irgendein DNS-Server aus der Kette so zwischenspeichert. Die DNS-Caches, die in der Kette davor liegen, werden jetzt brav diese Auflösung auch zwischenspeichern.
 
Is klaaar. Sei dir bitte bewusst, dass DJB seine Perlen der Softwarekunst schon vor 8 Jahren gerne behalten konnte.
 
Zurück
Oben