Ich habe viele Artikel darüber gelesen und verstehe nicht, wie Cache Poisoning möglich ist, wenn:
- Die Abfrage wird abgebrochen und als Fehler markiert, wenn die Transaktions-ID der Antwort nicht entspricht (Angreifer können die Transaktions-ID also nicht mit Brute Force erzwingen, da nur die erste Antwort akzeptiert wird).
- Der rekursive Resolver sendet jeweils nur eine Anfrage für dieselbe Domäne/denselben Typ/dieselbe Klasse. Das bedeutet, dass die Angreifer nicht viele Anfragen für dieselbe Domäne auslösen können, um die Transaktions-ID mit Brute Force zu erzwingen.
Wie ist in dieser scheinbar einfachen Konfiguration eine Cache-Vergiftung möglich, wenn die Angreifer die Transaktions-ID erraten müssen? Werden die Angreifer den rekursiven Resolver zwingen, dieselbe Domäne immer wieder aufzulösen, um mehr Versuche zu haben? In diesem Fall könnte das Stunden dauern …
Antwort1
Vor allem Ihr erster Aufzählungspunkt ist ungenau:
- Die Abfrage wird abgebrochen und als Fehler markiert, wenn die Transaktions-ID der Antwort nicht entspricht (Angreifer können die Transaktions-ID also nicht mit Brute Force erzwingen, da nur die erste Antwort akzeptiert wird).
Wenn eine unbekannte Transaktions-ID empfangen wird, wird diese Antwort verworfen. Ihre Annahme, dass die ausstehende Abfrage irgendwie als fehlgeschlagen betrachtet wird, ist jedoch nicht wahr.
Tatsächlich wird dieses Angriffsszenario für den Angreifer zu einem Wettlauf, eine gültige Antwort zu erhalten, bevor die Antwort vom echten Nameserver eintrifft.
Das Problem mit Ihrer Annahme ist, dass der ganze Sinn der Transaktions-ID (+ UDP-Quellport) darin besteht, die Antwort auf eine ausstehende Abfrage abzugleichen. Wenn es jedoch eine Antwort gibt, bei der diese Werte falsch sind (die mit keiner Abfrage übereinstimmt), wie können Sie dann feststellen, welche Abfrage Sie als fehlgeschlagen betrachten sollten?
Und wenn Sie eine Art teilweise Übereinstimmung zulassen würden, wie würden Sie dies auf eine Weise implementieren, die ein für den Angreifer etwas lästiges Wettrennen nicht durch einen trivial ausnutzbaren DoS-Angriff ersetzt?
Möglichkeiten für „echten“ Schutz:
- DNSSEC ermöglicht dem Abfrageersteller, die Authentizität der Datensätze in der Antwort zu validieren. Dadurch wird sichergestellt, dass eine vom Angreifer generierte Antwort für Namen in signierten Zonen nicht akzeptiert wird.
- Bei Anfragen von einer Art Client/Forwarder speziell an einen Resolver-Server vermeiden DoT und DoH auch das Cache-Poisoning-Problem.für diesen besonderen "Hopfen"(DoT/DoH sichern nur einen Kommunikationskanal zwischen zwei Hosts, DNS-Auflösungen haben in der Regel mehrere solcher „Hops“).
(Selbst eine bloße Abfrage über TCP verbessert das jeweilige Szenario in der Frage, aber die auf Kryptografie basierenden Lösungen sind offensichtlich viel umfassender in Bezug auf die Angriffe, mit denen sie umgehen.)