☰

Kaminsky-Bug - Vogteien

tag-icon • tag-icon security domain-name-system
Kaminsky-Bug - Vogteien

Ich habe über den Kaminsky-DNS-Bug gelesen, um besser zu verstehen, wie er funktioniert. Ich glaube, ich habe das Wesentliche verstanden, aber Dan erwähnt Bailiwicks, die verwendet werden, um DNS-Server hinter Firewalls anzugreifen.

Kann jemand erklären, was ein Bailiwick ist, und ein Beispiel geben, wie es verwendet wird, um Server hinter Firewalls anzugreifen und den Kaminsky-Bug auszunutzen?

Antwort1

Vogtei

Das Linux JournalArtikelDasEhtyarDer Beitrag enthält eine ziemlich gute Erklärung, was ein Bailiwick ist und wie es mit DNS zusammenhängt. Im Grunde werden einer DNS-Antwort zusätzliche Datensätze hinzugefügt, um die Suche nach delegierten DNS-Servern zu erleichtern. Um das Beispiel aus dem Artikel zu zitieren:

$ dig @ns1.example.com www.example.com
;; ANSWER SECTION:
www.example.com.    120      IN    A    192.168.1.10

;; AUTHORITY SECTION:
example.com.        86400    IN    NS   ns1.example.com.
example.com.        86400    IN    NS   ns2.example.com.

;; ADDITIONAL SECTION:
ns1.example.com.    604800   IN    A    192.168.2.20
ns2.example.com.    604800   IN    A    192.168.3.30


Attacke

Einzelheiten zum Angriff finden Sie in Dan'sFolien(siehe Folien 24/25). So greifen Sie einen Server hinter einer Firewall an:

  • Es wird eine Suche nach einer Subdomäne einer Domäne 1.badguy.comausgelöst, die der Angreifer kontrolliert (z. B. „ “).
  • Der angreifende Server antwortet mit einem CNAME-Eintrag für die Domäne, die er zu vergiften versucht (z. B. „ debian.org“). Dies führt zu einer DNS-Abfrage vom Ziel an „ debian.org“.
  • Sobald der angreifende Server den CNAME-Verweis sendet, beginnt er mit dem Streaming von gefälschten DNS-Antworten, die eine zusätzliche Antwort enthalten (z. B. „ security.debian.org“, die auf die IP-Adresse von „ badguy.com“ verweist).
  • Wenn die Transaktions-ID in der Antwort richtig erraten wurde, geht der Server hinter der Firewall nun davon aus, dass „ security.debian.org“ sich in die Adresse des Bösewichts auflöst.

Es gibt viele Möglichkeiten, den Server hinter der Firewall dazu zu bringen, eine IP-Adresse abzurufen, interne Client-Anfragen abzurufen, IP-Adressen in Server-Logs aufzulösen usw.bortzmeyererwähnt, dass die Firewall bei diesem Angriff weitgehend irrelevant ist.

Antwort2

Wie Mark Johnson erwähnte, ist der Zuständigkeitsbereich eines DNS-Servers die Menge der Domänen, für die er maßgebend ist. Zu einer Zeit akzeptierten rekursive Nameserver Daten außerhalb des Zuständigkeitsbereichs von maßgebenden Nameservern. Der für foo.example maßgebende Nameserver konnte also zusätzliche Daten in seine Antwort einfügen, indem er die IP-Adresse von www.bar.example angab, und ihm wurde geglaubt. Dies war die Grundlage derKashpureff-Angriff. Nameserver glauben schon lange nicht mehr an Daten außerhalb ihres Zuständigkeitsbereichs, wie es vonRFC 2181, Abschnitt 5.4.1.

Der Kaminsky-Angriffnichtverwenden Daten außerhalb des Zuständigkeitsbereichs und arbeiten daher auch mit aktuellen Nameservern. Die Linux JournalDer von Luke Quinane erwähnte Artikel erklärt es sehr gut (aber der Rest von Luke Quinanes Beitrag, insbesondere über Firewalls, ist fragwürdig.)

Was Firewalls betrifft, ist dies größtenteils ein unabhängiges Problem. Wenn ein Nameserver Antworten auf seine Anfragen erhalten möchte, muss er erreichbar sein. Daher spielt es keine Rolle, ob er eine Firewall davor hat oder nicht: Der Kaminsky-Angriff benötigt nur einen Kanal, nämlich den DNS-Kanal.

Da der Kaminsky-Angriff auf den Nameserver erfolgt, den die Client-Rechner verwenden, spielt es keine Rolle, ob diese Rechner durch die Firewall geschützt sind oder nicht. (Ein gutes Beispiel dafür, warum eine Firewall kein Zaubermittel ist und nicht alles schützt.)

verwandte Informationen