Passwort vergessen? Account-Takeover nach Kaminskys Art

13.07.2021

Die „Passwort vergessen?“-Funktion und wie sie in Kombination mit DNS-Schwachstellen zur Übernahme von Benutzerkonten führen kann.

TL;DR

Mit der Analyse von 146 Webapplikationen auf Schwachstellen in ihrer DNS-Namensauflösung hat Timo Longin gezeigt, dass es auch noch heute verwundbare Webapplikationen gibt. Kaminsky- sowie IP- Fragmentierungs-Angriffe ermöglichen eventuell bei mehreren Webapplikationen die Übernahme von Benutzerkonten via "Passwort vergessen?"-Funktion. Zum Identifizieren von verwundbaren Webapplikationen wird der DNS Reset Checker bereitgestellt.

Betrifft mich dieser Angriffsvektor?
Wie kann ich mich schützen?
Sollte ich nach diesem Angriffsvektor Ausschau halten?

Diese und viele weitere Fragen werden im Q&A-Abschnitt behandelt.

Passwort vergessen?

Diese Frage ist bei Webapplikationen kaum noch wegzudenken.

E-Mail-Adresse angeben
Rücksetzungs-URL erhalten
Passwort ändern

Simpel! Doch was hat die „Passwort vergessen?“-Funktion mit DNS- Schwachstellen zu tun?

Folgendes Szenario bringt dies näher: Angenommen, ein Angreifer ist in der Lage beliebige DNS-Einträge in den Cache des verwendeten DNS-Resolvers einer Webapplikation einzuschleusen (DNS-Cache-Poisoning), dann kann ein Angreifer die Zuordnung von E-Mail-Domänen zu IP-Adressen bestimmen. Eine DNS- Namensauflösung von „gmail.com“ führt daher nicht mehr zwingend zur IP-Adresse des E-Mail-Servers von Google, sondern zum Beispiel zur

IP-Adresse des E-Mail-Servers des Angreifers.

Dadurch können alle für „gmail.com“ bestimmten E-Mails von einem Angreifer empfangen werden. Darunter auch E-Mails zur Passwortrücksetzung.

Folgende Grafik (Abbildung 1) veranschaulicht dies:

Abbildung 1: Umleiten von E-Mails via DNS-Cache-Poisoning [14]

Ist es einem Angreifer also möglich die DNS-Namensauflösung einer Webapplikation zu manipulieren, dann könnte dies in Kombination mit der „Passwort vergessen?“-Funktion zur Übernahme von Benutzerkonten führen.

Dieser Angriffsvektor wurde bereits 2008 von Dan Kaminsky auf der "Black Hat"-Konferenz [1] vorgestellt. Mit der folgend beschriebenen Analyse von 146 Webapplikationen, die im Zuge der Diplomarbeit "DNS-Schwachstellen in Webapplikationen" von Timo Longin [14] durchgeführt wurde, wird gezeigt, dass der Angriffsvektor aber auch noch heute relevant ist.

Abbildung 2: DNS-Verkehr zwischen Webapplikation, DNS-Resolver und ADNS der
Domäne "analyse.example" [14]

Die Basics

Wie überprüft man die DNS-Namensauflösung von 146 Webapplikationen auf Schwachstellen?

Durch das Registrieren von 146 Benutzern! Mehrmals!

Wird ein Benutzer bei einer Webapplikation registriert, wird in den meisten Fällen eine E-Mail zur Verifikation der E-Mail-Adresse geschickt. Die E-Mail-Adresse lautet beispielsweise „test@analyse. example“. Damit ein E-Mail-Versand möglich ist, muss vorerst die E- Mail-Domäne der E-Mail-Adresse in eine IP-Adresse aufgelöst werden. Für „analyse.example“ muss also die IP-Adresse des E-Mail-Servers ermittelt werden. Das führt nach einigen DNS-Anfragen dazu, dass eine DNS-Anfrage mit dem Typ „MX“ an den autoritativen Namensserver (ADNS) von „analyse.example“ geschickt wird (siehe Abbildung 2)

Abbildung 3: DNS-Verkehr fließt durch den DNS-Proxy [14]

Will man nun die DNS-Namensauflösung einer Webapplikation analysieren, dann bietet sich der DNS-Verkehr, der zu und vom ADNS fließt, an. Damit es auch möglich ist, DNS-Anfragen sowie -Antworten zu manipulieren, wurde die im nachfolgenden Schaubild dargestellte Softwarekomponente "DNS-Proxy" entwickelt (Abbildung 3):

Der DNS-Proxy erlaubt es, DNS-Anfragen sowie -Antworten, die zu und vom ADNS gesendet werden, zu lesen und zu ändern. So ist es möglich, passiv DNS-Nachrichten zu analysieren und aktiv DNS-Antworten zu manipulieren. Weiters ist der DNS-Proxy bzw. der Quellcode des gesamten Analyse-Servers frei auf GitHub verfügbar! (Mehr dazu folgt noch!)

Zusammengefasst: Wird ein Benutzer bei einer Webapplikation registriert, so können auf diese Weise die Eigenschaften der DNS-Namensauflösung der Webapplikation untersucht werden.

E-Mail-Adressen à la DNS-Analyse

Mit dem gezeigten Setup ist es also möglich, die DNS-Namensauflösung von Webapplikationen zu analysieren. Doch was passiert, wenn die E-Mail-Adresse „test@analyse.example“ bei mehreren Webapplikationen registriert wird?

Dies führt dazu, dass „analyse.example“ von mehreren Webapplikationen aufgelöst wird und man nicht mehr zwischen DNS-Anfragen von verschiedenen Webapplikationen differenzieren kann. Aus diesem Grund müssen Benutzer bei unterschiedlichen

Webapplikationen mit unterschiedlichen E-Mail-Adressen registriert werden. Hierfür wurde das folgende Format verwendet:

test@VVAAIIIIII.analyse.example

V: Versionierung

A: Die durchzuführende Methode zur Überprüfung einer Angriffsvoraussetzung

I: Identifikator der Webapplikation

Wird eine Webapplikation in Testdurchgang 1, mit der ersten Methode (beginnend bei 0) und dem Identifikator 1337 überprüft, so würde man einen Benutzer mit folgender E-Mail-Adresse registrieren:

test@0100001337.analyse.example

DNS-Angriffe und ihre Voraussetzungen

Nun ist es möglich zwischen DNS-Verkehr von verschiedenen Webapplikationen zu differenzieren. Doch was soll eigentlich analysiert werden?

Um das herauszufinden, werden bisherige DNS-Angriffe herangezogen und auf deren Angriffsvoraussetzungen heruntergebrochen. Dadurch kann festgestellt werden, welche Eigenschaften eine DNS-Namensauflösung besitzen muss, damit sie angreifbar bzw. verwundbar ist.

Folgend zwei Beispiele:

Angriffsvoraussetzung - IP-Fragmentierung: Der von Amir Herzberg und Haya Schulman entdeckte DNS-Angriff [2] setzt zum Beispiel voraus, dass IP-fragmentierte DNS-Antworten von einem DNS-Resolver akzeptiert werden. Diese Voraussetzung kann überprüft werden, indem aktiv DNS-Antworten mittels DNS-Proxy manipuliert werden. Eine DNS-Antwort zum Testen von IP-Fragmentierung sieht zum Beispiel folgendermaßen aus:

;; QUESTION SECTION:

;0100001337.analysis.example.          IN      MX



;; ANSWER SECTION:

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

0100001337.analysis.example.   5       IN      MX      10 a.jlguehdhzo.if.0100001337.analysis.example.

Diese DNS-Antwort ist so lang, dass sie die maximale Übertragungszeit (MTU) überschreitet und daher in mehreren IP-Paketen übertragen werden muss (IP-Fragmentierung). Wird diese fragmentierte DNS-Antwort von dem anfragenden DNS-Resolver akzeptiert, so versucht dieser "a.jlguehdhzo.if.0100001337.analysis.example" aufzulösen. Sobald der DNS-Proxy eine derartige DNS-Anrage erhält, kann davon ausgegangen werden, dass der DNS-Resolver der Webapplikation IP-Fragmentierung überstützt.

Angriffsvoraussetzung - Quell-Port-Randomisierung: Ein weiteres Beispiel sind Voraussetzungen eines Kaminsky-Angriffs [1]. Eine der Voraussetzungen ist, dass DNS-Anragen eine niedrige Entropie aufweisen und dadurch DNS-Antworten leicht erratbar sind. Diese niegriege Entropie ergibt sich dadruch, dass Quell-Ports nicht zufällig vergeben werden. Durch Speichern und Analysieren von Log-Dateien des DNS-Proxys kann auch diese Anforderung überprüft werden. Dazu bieten sich vor allem Streudiagramme besonders gut an:

Abbildung 4: Streudiagramm von zufällig verteilten UDP-Quell-Ports

In diesem Fall ist zu sehen, dass Quell-Ports zufällig gewählt werden und dadurch Kaminsky-Angriffe weitestgehend verhindert werden.

Die ewige DNS-Auflösung

An diesem Punkt ermöglicht es der DNS-Proxy unterschiedlichste Angriffsvoraussetzungen für unterschiedlichste Webapplikationen zu überprüfen. Doch ein wichtiges Detail muss noch über den DNS-Proxy angemerkt werden. Und zwar gibt der DNS-Proxy unter keinen Umständen die IP-Adresse des E-Mail-Servers preis. Warum?

Wenn eine Webapplikation es schafft eine E-Mail-Domäne in eine IP-Adresse aufzulösen, wird daraufhin die zu sendende E-Mail versandt. Das heißt, dass keine weiteren DNS-Anfragen von der Webapplikation gemacht werden müssen.

Aus diesem Grund werden DNS-Einträge, die die IP-Adresse des E-Mail-Servers preisgeben, in allen DNS-Antworten entfernt. Wird zum Beispiel versucht DNS-Einträge, die in einer IP-fragmentierten DNS-Antwort retourniert wurden („a.jlguehdhzo.if.0100001337.analyse.example“), aufzulösen, dann entfernt der DNS-Proxy die vom ADNS gesetzte Antwort-Sektion. Dadurch versucht die Webapplikation wiederholt die E-Mail-Domäne aufzulösen und es können nacheinander die unterschiedlichen Angriffsvoraussetzungen überprüft werden.

Abbildung 5: Testvorgang zur Überprüfung von Webapplikationen auf DNS- Schwachstellen [14]

Jetzt registrieren!

Nun ist es so weit! Der Untersuchung der DNS-Namensauflösung von 146 Webapplikationen steht nichts mehr im Weg! Der diesbezüglich Testvorgang sieht folgendermaßen aus (Abbildung 5):

Alles beginnt mit einer Registrierung. In diesem Fall wird die E-Mail-Adresse „test@0100000001.analyse.example“ verwendet, um sich bei der Webapplikation mit Identifikator „000001“ zu registrieren. Dadurch wird eine DNS-Namensauflösung initiiert, mit der eine oder mehrere Angriffsvoraussetzungen überprüft werden können. Um zu sehen, welche Angriffsvoraussetzungen bereits getestet wurden und welche noch fehlen, kann die Log-Datei des DNS-Proxys herangezogen werden. Abhängig von den bereits überprüften Voraussetzungen, müssen noch weitere Benutzer registriert werden. Damit die gleiche Angriffsvoraussetzung nicht mehrfach getestet wird, kann die durchzuführende Testmethode in der E-Mail-Adresse spezifiziert werden (01XX000001.analyse.example).

Nach zirka 20 Stunden reinem Registrierungsaufwand sowie mehreren hundert Stunden Recherche, Scripting und Analyse liegen nun die Ergebnisse vor.

Die DNS-(Un)Sicherheit der 146 Webapplikationen

Wie steht es nun um die DNS-Sicherheit von Webapplikationen? Insgesamt wurden 8 verschiedene Angriffsvoraussetzungen für 5 verschiedene DNS-Angriffe getestet. DNS-Angriffe, für die alle Angriffsvoraussetzungen zumindest einmal erfüllt wurden, sind folgende:

Kaminsky-Angriff: 2 von 146
IP-Fragmentierungs-Angriff: 62 von 146

Hinweis: Aufgrund laufender Disclosure-Prozesse werden keine konkreten Namen von Webapplikationen genannt.

Kaminsky-Angriff: Die für den Kaminsky-Angriff getesteten Angriffsvoraussetzungen sind bei 2 von den 146 Webapplikationen gegeben. Die Voraussetzungen sind konkret folgende:

Niedrige Entropie von DNS-Anfragen
Keine Verwendung/Erzwingung von DNS-Sicherheitsfeatures (DNSSEC, DNS-Cookies, etc.)
Es ist möglich eine große Anzahl an DNS-Anfragen an eine „Opfer“-Domäne (zum Beispiel „gmail.com“) auszulösen

Abbildung 6: Webapplikation mit statischer Quell-Port-Verteilung [14]

Hierbei ist vor allem die niedrige Entropie von DNS-Anfragen interessant. Wie bereits gezeigt kann diese mit Streudiagrammen von UDP-Quell-Ports visualisiert werden. Das Streudiagramm einer verwundbaren DNS-Namensauflösung eines Online-Casinos sieht wie folgt aus (Abbildung 6):

Jede zweite DNS-Anfrage erfolgt über den Quell-Port 30200, sonstige DNS-Anfragen verwenden inkrementelle Quell-Ports. Einem Angreifer ist es dadurch leicht möglich, verwendete Quell-Ports zu erraten und einen Kaminsky-Angriff durchzuführen.

Die zweite Webapplikation (ein Nachrichtensender) mit erratbaren Quell-Ports hat folgendes Streudiagramm (Abbildung 7).

Abbildung 7: Webapplikation mit inkrementeller Quell-Port-Verteilung [14]

In diesem Fall werden Quell-Ports inkrementell auf 3 "Ebenen" verteilt, wodurch sie ebenfalls leicht erraten werden können.

IP-Fragmentierungs-Angriff: 62 von den 146 getesteten Webapplikationen erfüllen die folgenden, für IP-Fragmentierungs-Angriffe analysierten, Angriffsvoraussetzungen:

IP-fragmentierte DNS-Antworten werden von DNS-Resolvern von Webapplikationen akzeptiert Keine Verwendung/Erzwingung von DNS-Sicherheitsfeatures (DNSSEC, DNS-Cookies, etc.)

Es ist möglich eine große Anzahl an DNS-Anfragen an eine „Opfer“-Domäne (zum Beispiel „gmail.com“) auszulösen

Hierbei ist zu berücksichtigen, dass lediglich die Voraussetzungen seitens DNS-Namensauflösung der Webapplikation überprüft wurden.

IP-Fragmentierungs-Angriffe setzen zum Beispiel ebenfalls voraus, dass ein Angreifer in der Lage ist, DNS-Antworten, die von einem ADNS an einen DNS-Resolver geschickt werden, zu fragmentieren.

Sonstige Daten: Wie steht es sonst um die DNS-Sicherheit? Wie sieht es mit DNSSEC und dergleichen aus? Folgend eine kurze Auflistung:

DNS SIcherheitsfeature	Verwendung*	Erzwingung**
DNSSEC	20 von 146	9 von 146
DNS Cookies	1 von 146	1 von 146
0x20 Enkodierung	0 von 146	0 von 146
EDNS Größenbeschränkung (<= 1232 Bytes)	0 von 146	0 von 146

*: Bei den oben angegeben Zahlen ist zu berücksichtigen, dass erst dann von einer Verwendung eines Sicherheitsfeatures ausgegangen wird, wenn es für jede DNS-Anfrage verwendet wird. Wird zum Beispiel

0x20-Enkodierung nur für „MX“-Anfragen verwendet, sind "A", "AAAA" und Anfragen für andere Eintragstypen noch immer ungeschützt. Ein Angreifer kann die Abwesenheit solcher Sicherheitsfeatures ausnutzen. Aus diesem Grund wird die Verwendung eines DNS-Sicherheitsfeatures erst dann gezählt, wenn es auch wirklich bei jeder DNS-Anfrage verwendet wird.

**:In manchen Fällen kommt es vor, dass DNS-Sicherheitsfeatures optional verwendet, aber nicht erzwungen, werden. Zum Beispiel können DNS-Resolver signierte DNS-Antworten anfordern aber nicht validieren. Werden Sicherheitsfeatures auf diese Weise verwendet, bieten sie keinen zusätzlichen Schutz. Die Spalte "Erzwingung" gibt demnach an, ob DNS-Sicherheitsfeatures verwendet sowie auch erzwungen werden.

Der DNS Reset Checker

Wie bereits erwähnt ist der verwendete Analyse-Server auf GitHub frei verfügbar. Er ist eines der zwei Tools des DNS Reset Checkers, welcher hier zu finden ist:

https://github.com/The-Login/DNS-Reset-Checker

Der DNS Reset Checker besteht aus dem Analyse-Server und einem Log-Analyzer.

Der Analyse-Server dient, wie bereits gezeigt, zur Beschaffung von DNS-Daten sowie zur Überprüfung von Angriffsvoraussetzungen. Der Log-Analyzer dient zur Auswertung dieser Daten. Streudiagramme, überprüfte Angriffsvoraussetzungen, DNS-Sicherheitsfeatures sowie vieles mehr kann mithilfe des Log-Analyzers analysiert werden. Neben den oben zu sehenden Streudiagrammen werden zum Beispiel folgende Informationen bereitgestellt:

Analysis of domain identifier: 999997

General Info

* Number of DNS resolver IPs: 64

* Public DNS resolvers: Outgoing IP addresses of big public DNS resolvers: 32 / 64

* Number of queries received: 346

* Active methods probed: ip_fragmentation, edns_removal, recursive_delegation

* EDNS maximum size: Not all DNS requests specified a response size.

* DNS cookies: At least one DNS query did not include a DNS cookie.

* DNSSEC: At least one DNS query did not require DNSSEC.

* Removal of EDNS (OPT): A response with a missing EDNS record was returned by the server and accepted by the resolver.

* IP fragmentation: An IP fragmented response was returned by the server but denied by the resolver.

* 0x20 Encoding: At least one DNS query did not use 0x20 encoding.

Ausschnitt der durch den Log-Analyzer bereitgestellten Infos

Eine genaue Anleitung zur Installation und Verwendung des DNS Reset Checkers ist auf GitHub zu finden.

Fragen und Antworten (FAQ)

Sollte ich nach diesem Angriffsvektor in zukünftigen Sicherheitsüberprüfungen Ausschau halten?

Ja, definitiv! Da dieser Angriffsvektor eventuell Benutzerübernahmen ermöglicht sollte er in Sicherheitsüberprüfungen inkludiert werden. Ebenfalls kann eine Überprüfung mit einem bereits aufgesetztem Analyse-Server schnell durchgeführt werden.

Betrifft mich dieser Angriffsvektor?

Falls Unsicherheit über verwendete DNS-Resolver und die DNS- Infrastruktur im Allgemeinen besteht, lässt sich das am einfachsten mit dem DNS Reset Checker herausfinden!

Wie kann ich mich schützen?

Um diesen Angriffsvektor zu verhindern sollte primär die DNS- Infrastruktur der Webapplikation abgesichert werden. Best-Practices zum Absichern der eigenen DNS-Resolver sind zum Beispiel bei Google[3] sowie bei DNS-Flag-Day[4] zu finden. Ebenfalls können große öffentliche DNS-Anbieter wie Google[5], Cloudflare[6] oder Cisco [7] verwendet werden. Gegenmaßnahmen für neue DNS-Angriffe [8] werden von diesen meist rasch implementiert.

Ob nach Absicherung der DNS-Infrastruktur noch immer Schwachstellen vorhanden sind, kann mit dem DNS Reset Checker überprüft werden.

Meine DNS-Resolver sind alle auf dem neuesten Stand, also bin ich sicher… oder?

DNS-Resolver auf dem neuesten Stand zu halten ist ein Schritt in die richtige Richtung, jedoch kann es noch immer zu Schwachstellen in der DNS-Namensauflösung kommen. Zum Beispiel kann Netzwerkinfrastruktur wie NAT/PAT-Geräte einen Einfluss auf die Zufälligkeit von UDP-Quell-Ports haben und dadurch Kaminsky-Angriffe ermöglichen (siehe Herzberg et al.[9] sowie Vulnerability Note VU#800113 [10]). Das ist ebenfalls der Grund warum nicht von der Sicherheit der DNS-Resolver, sondern von der Sicherheit der gesamten DNS-Namensauflösung die Rede ist.

Betreffen mich DNS-Schwachstellen auch, wenn ich keinen öffentlichen DNS-Resolver verwende?

Ja, zumindest teilweise. Wie Dan Kaminsky schon im Jahr 2008 angemerkt hat und nochmals in einer Lab-Umgebung überprüft wurde, schützt die Verwendung von privaten DNS-Resolvern nicht gegen Kaminsky-Angriffe.

Können DNS-Schwachstellen durch die Verwendung von TLS für E- Mail-Verkehr verhindert werden?

Grundsätzlich, ja. Wie auch in Browsern kann die Kritikalität von DNS- Schwachstellen durch die Verwendung von TLS relativiert werden. Hierbei ist jedoch zu berücksichtigen, dass TLS richtig verwendet werden muss. Oft wird zwar TLS verwendet, jedoch nur mit selbstsignierten und unvertrauten Zertifikaten (Mayer et al. [11]) . Dadurch ist zwar Schutz vor einem passiven Beobachter gegeben, aber nicht vor einem aktiven Angreifer (on-path).

Ist die Übernahme von Benutzerkonten die einzige Möglichkeit um DNS-Schwachstellen in Webapplikationen auszunutzen?

Nein, abhängig von anderen Funktionalitäten von Webapplikationen die das DNS verwenden könnten zum Beispiel auch Server-Side-Request- Forgery (SSRF) oder ähnliche Angriffe möglich sein. In diesem Artikel wurde sich auf die "Passwort vergessen?"-Funktionalität fokussiert, da diese bei vielen Webapplikationen verwendet wird.

Wie können Ergebnisse des DNS Reset Checkers bewertet werden?

Um die Ergebnisse des DNS Reset Checkers zu bewerten, können erfüllte Angriffsvoraussetzungen herangezogen werden. Abhängig von den erfüllten Angriffsvoraussetzungen kann der vorliegenden DNS Namensauflösung ein mehr oder weniger hohes Risiko zugeordnet werden.

Werden zum Beispiel erratbare UDP-Quell-Ports vergeben, ist damit eine Hauptvoraussetzung für Kaminsky-Angriffe erfüllt und es sind sehr wahrscheinlich Kaminsky-Angriffe möglich. Demnach liegt ein hohes Risiko vor.

Ist IP-Fragmentierung möglich, aber weitere Angriffsvoraussetzungen sind unklar, dann ist die Wahrscheinlichkeit eines erfolgreichen Angriffs eher gering. Demnach liegt ein niedrigeres Risiko vor.

Warum 146 Webapplikationen?

Bei ersten Testversuchen wurden Benutzer bei zirka 190

Webapplikationen (Alexa Top 500, etc.) registriert. Da manche Webapplikationen nur E-Mail-Adressen von großen Anbietern (gmail. com, outlook.com, etc.) erlauben oder keine Registrierungs-E-Mails versenden, wurden letztendlich 146 Webapplikationen überprüft.

Wurden Angriffsvoraussetzungen für neue Angriffe wie SAD (Side channel AttackeD DNS) und DNSpooq ebenfalls überprüft?

Nein, da Analysen bereits vor der Veröffentlichung dieser Angriffe abgeschlossen wurden. Überprüfungsmethoden für deren Angriffsvoraussetzungen können in zukünftigen Versionen des DNS Reset Checkers eingebaut werden.

Gab es bereits Überprüfungen der DNS-Sicherheit von Webapplikationen?

Teilweise sowie indirekt. Die meisten Analysen bezüglich DNS- Sicherheit im Internet befassen sich mit offenen DNS-Resolvern, die im Internet zur Verfügung stehen. Es kann dadurch zwar erkannt werden, dass ein DNS-Resolver verwundbar ist, aber nicht, dass eine Webapplikation diesen verwendet. Eine Analyse der DNS-Sicherheit von Webapplikationen wurde in Recherchen nicht gefunden.

Existieren nicht bereits Online-Tools zur Überprüfung der DNS- Sicherheit?

Es gibt mehrere Online-Tools zur Überprüfung der DNS-Sicherheit (z.B. GRC [12] oder DNS-OARC [13]). Diese testen jedoch nur die DNS- Namensauflösung des vom System angegebenen DNS-Resolvers. Da Webapplikationen teilweise DNS-Resolver verwenden, die nicht aus dem Internet erreichbar sind, kann auf diese Weise nur eingeschränkt getestet werden.

Wie wurde dieser Angriffsvektor wiederentdeckt?

Bei internen Sicherheitsüberprüfungen ist es üblich, die "Passwort vergessen?"-Funktion interner Webapplikationen auszunutzen, um an Passwortrücksetzungs-URLs in E-Mails zu kommen. Dies ist intern simpel möglich, da Man-in-the-Middle-Angriffe mittels ARP-Spoofing umgesetzt werden können, um von einzelnen Webapplikationen versendete Passwortrücksetzungs-E-Mails zum Angreifer umzuleiten. Basierend auf dieser Angriffsart und mit den potentiell verheerenden Folgen im Hinterkopf, wurde versucht dieses Konzept auf Webapplikationen im Internet umzumünzen.

Referenzen

[1] D. Kaminsky, Black ops 2008: It's the end of the cache as we know it, Black Hat USA 2, 2008.

[2] A. Herzberg und H. Schulman, „Fragmentation considered poisonous,“ in 2013 IEEE Conference on Communications and Network Security (CNS), 2013.

[3] https://developers.google.com/speed/public-dns/docs/security

[4] https://dnsflagday.net/2020/#action-dns-resolver-operators

[5] https://developers.google.com/speed/public-dns

[6] https://www.cloudflare.com/learning/dns/what-is-1.1.1.1

[7] https://www.opendns.com/cisco-opendns/

[8] https://blog.cloudflare.com/sad-dns-explained/

[9] A. Herzberg und H. Shulman, „Security of patched DNS,“ in European Symposium on Research in Computer Security, Berlin, Heidelberg, 2012.

[10] https://www.kb.cert.org/vuls/id/800113/

[11] W. Mayer, A. Zauner, M. Schmiedecker und M. Huber, „No need for black chambers: Testing TLS in the e-mail ecosystem at large,“ in 2016 11th International Conference on Availability, Reliability and Security (ARES), 2016.

[12] https://www.grc.com/dns/dns.htm

[13] https://www.dns-oarc.net/oarc/services/dnsentropy

[14] T. Longin, DNS-Schwachstellen in Webapplikationen: Eine Untersuchung der Sicherheit der DNS-Namensauflösung von Webapplikationen, 2020.

Über den Autor

[Translate to German:] Portrait of Timo Longin SEC Consult

Timo Longin
SEC Consult
Senior Security Consultant

Timo Longin (auch bekannt als Login) ist tagsüber Senior Security Consultant bei SEC Consult und nachts Sicherheitsforscher. Neben alltäglichen Sicherheitsüberprüfungen für Kunden veröffentlicht er Blogbeiträge und Sicherheitstools, hält Vorträge auf Konferenzen und Universitäten und hat eine Leidenschaft für CTFs. Als vielseitiger, offensiver Sicherheitsforscher versucht er, vergessene und neue Schwachstellen zu identifizieren, die das Undenkbare möglich machen!

Zurück