25.01.2021 07:10

DNSpooq: Wie sehr spukt's in Österreich?

Am 2021-01-19 veröffentlichte JSOF eine Reihe von Schwachstellen in dnsmasq, einer populären DNS-Resolver Software für kleine Netzwerke.

Ihr Blogpost dazu fasst diese Lücken unter dem Namen “DNSpooq" zusammen und beschreibt zwei mögliche Angriffsszenarien:

DNS Cache Poisoning:

Diese Art von Schwachstelle ist keineswegs unbekannt und wurde bereits 2008 von Dan Kaminsky entdeckt, weshalb sie oft als "Kaminsky Bug" bezeichnet wird.¹ Dabei können AngreiferInnen falsche Einträge in den Cache eines DNS-Resolvers einschleußen und dadurch DNS-Anfragen von Clients, die sich auf den Resolver verlassen, manipulieren.

Für dieses Szenario sind sämtliche Versionen von dnsmasq vor 2.83 anfällig.

Buffer Overflow:

Insgesamt drei Buffer Overflows konnte JSOF in dnsmasq finden, wobei sie nicht versucht haben, diese voll auszunutzen, d.h. funktionierende Exploits zu entwickeln. Dementsprechend ist aktuell unklar, ob diese auch zum Ausführen beliebiger Befehle über das Netzwerk (Remote Code Execution, kurz “RCE") missbraucht werden können.

Die Buffer Overflows sind alle in der Funktion sort_rrset zu finden, die Teil von dnsmasqs DNSSEC Implementierung ist, d.h nur aufgerufen wird, wenn dnsmasq so konfiguriert ist, dass es DNSSEC validiert.

Daraus ergibt sich, dass sämtliche Instanzen von dnsmasq Resolvern unter Version 2.83 für DNS Cache Poisoning anfällig sind und all jene, die DNSSEC unterstützen auch noch für Buffer Overflows, die wiederum potentiell zu RCEs “erweitert" werden könnten.

Grund genug, uns die Situation in AT einmal etwas genauer anzuschauen: Dazu haben wir initial via Shodan alle Installationen von dnsmasq, die in Österreich aus dem Internet erreichbar sind, gesucht und deren wahrscheinliche Versionsnummer identifiziert – die liefert Shodan praktischerweise gleich mit. Der komplexe dazugehörige Dork für die Suche ist übrigens “dnsmasq".

Erstes Ergebnis: Mit Stand 2020-01-20 gab es 1255 erreichbare dnsmasq Instanzen, von denen keine einzige Version 2.83 war. Dies ist aber wenig verwunderlich, da das Update erst 2020-01-19 veröffentlicht wurde und Shodans Daten nicht immer tagesaktuell sind. Die genaue Aufteilung sieht wie folgt aus:

Zu dieser Gesamtübersicht noch ein kurzer Blick auf die neuesten Versionen, die wir im Output finden:

Es sind also lt. Shodans Angaben etwa die Hälfte der Instanzen fünf oder weniger Minor Versions von 2.83 entfert – ob das erfreulich ist, sei dahingestellt.

Als zweites wollten wir wissen, wieviele Instanzen DNSSEC unterstützen. Bei der Ausarbeitung der dazu notwendigen Anfragen und der korrekten Interpretation der Antworten hatten wir tatkräftige Unterstützung von Arsen Stasic vom ZID der Universität Wien, bei dem wir uns an dieser Stelle herzlich bedanken wollen.

Um festzustellen, ob die Resolver DNSSEC validieren, stellten wir folgende Anfrage:

  dig @${resolver-ip} at NS +dnssec +tries=1 +time=2

d.h. wir beschränkten uns auf eine einzige Query mit einem Timeout von zwei Sekunden.² Wenn die Antwort das “ad"-Flag gesetzt hatte, gingen wir von einer korrekten DNSSEC-Antwort aus. Zusätzlich haben wir mit dem Befehl

  dig @${resolver-ip} o-o.myaddr.l.google.com TXT +short +tries=1 +time=2

potentielle Upstream-Resolver identifiziert.³ Grund dafür ist, dass wir im Falle eines Upstream-Resolvers nicht wissen, ob die DNSSEC-Validierung von diesem durchgeführt und vom dnsmasq-Resolver nur korrekt weitergegeben wurde, oder ob der dnsmasq-Resolver sie selbst durchgeführt hat.

Ergebnis: Nur 150 der 1255 dnsmasq Instanzen hatten das “ad"-Flag gesetzt und damit eine korrekte DNSSEC-Response gegeben. Von diesen 150 hatten jedoch 148 einen Upstream-Resolver zurückgeliefert, d.h. nur bei zwei Resolvern kann mit Sicherheit davon ausgegangen werden, dass sie eigenständig DNSSEC validieren.

Dementsprechend sind also maximal etwas mehr als 10% der dnsmasq Installationen die lt. Shodan Österreich zuzuordnen sind, für die DNSSEC-Schwachstellen von DNSpooq anfällig.

Wir haben am 2021-01-20 eine Aussendung an alle BetreiberInnen der von Shodan identifizierten dnsmasq-Instanzen gemacht, und sie darum gebeten, ein Update durchzuführen, sofern das möglich ist und werden den Scan in einiger Zeit wiederholen, um herauszufinden, ob sich die Landschaft in AT verändert hat und wenn ja, wie.