trycatchhcf/packetwhisperPacketWhisper: Heimlich Daten exfiltrieren und die Zuordnung mittels DNS-Abfragen und textbasierter Steganographie umgehen. Vermeiden Sie die Probleme, die mit typischen DNS-Exfiltrationsmethoden verbunden sind. Übertragen Sie Daten zwischen Systemen, ohne dass die kommunizierenden Geräte direkt miteinander oder mit einem gemeinsamen Endpunkt verbunden sind. Kein Bedarf, einen DNS-Nameserver zu kontrollieren.
PacketWhisper – Daten unauffällig übertragen und Attribuierung umgehen mithilfe von DNS-Abfragen und textbasierter Steganographie, ohne dass angreiferkontrollierte Nameserver oder Domains benötigt werden; DLP/MLS-Geräte umgehen; Daten- und DNS-Nameserver-Whitelisting-Kontrollen überlisten. Konvertieren Sie jeden Dateityp (z. B. ausführbare Dateien, Office-Dokumente, ZIP-Archive, Bilder) in eine Liste von vollqualifizierten Domainnamen (FQDNs) und übertragen Sie die Daten mittels DNS-Abfragen. Einfach und dennoch äußerst effektiv.
(Update 27.05.2020: Ja, ich werde im Sommer 2020 alle meine Github-Projekte auf Python3 migrieren.)
Joe Gervais (TryCatchHCF)
Herkömmliche DNS-Exfiltration basiert auf einer der folgenden Methoden: DNS-Tunneling; Verstecken von Daten in DNS-Abfragefeldern; oder kodierte/verschlüsselte Nutzdaten, die aufgeteilt und als Subdomains in der DNS-Abfrage verwendet werden. Alle diese Methoden erfordern, dass der Angreifer eine Domain und/oder einen zugehörigen DNS-Nameserver kontrolliert, um die Daten zu empfangen, was zur Attribuierung führt. Diese Ansätze sind auch anfällig für DNS-Nameserver-Blacklisting (üblich) und Whitelisting (zunehmend üblich). Ein weiteres Problem ist, dass DFIR-Analysten mit diesen Methoden vertraut sind und SIEM-Systeme sie häufig erkennen und Alarm schlagen.
PacketWhisper überwindet diese Einschränkungen.
Was wäre, wenn Daten mithilfe der eigenen whitelisteten DNS-Server des Ziels übertragen werden könnten, ohne dass die kommunizierenden Systeme jemals direkt miteinander oder mit einem gemeinsamen Endpunkt verbunden sind? Selbst wenn die Netzwerkgrenze Daten-Whitelisting einsetzt, um Datenexfiltration zu blockieren?
Um dies zu ermöglichen, kombiniert PacketWhisper DNS-Abfragen mit textbasierter Steganographie. Unter Verwendung des Cloakify-Toolsets wird die Nutzlast in eine Liste von FQDN-Strings umgewandelt. PacketWhisper erstellt dann aus der Liste der FQDNs sequenzielle DNS-Abfragen, überträgt die Nutzlast über (oder innerhalb von) Netzwerkgrenzen hinweg, wobei die Daten im Klartext verborgen sind, und ohne dass die beiden Systeme jemals direkt miteinander oder mit einem gemeinsamen Endpunkt verbunden sind. Die von PacketWhisper verwendeten Cipher bieten mehrere Täuschungsebenen, um Warnmeldungen zu vermeiden und Analyseversuche in die Irre zu führen.
Um die Daten zu empfangen, erfassen Sie den Netzwerkverkehr, der die DNS-Abfragen enthält, mit der für Sie bequemsten Methode. (Siehe „Erfassen der PCAP-Datei“ weiter unten für Beispiele von Erfassungspunkten.) Anschließend laden Sie die erfasste PCAP-Datei in PacketWhisper (das auf einem beliebigen System ausgeführt wird), das die Nutzlast aus der Datei extrahiert und in ihre ursprüngliche Form enttarnt (Decloakify).
DNS ist ein attraktives Protokoll, da es – obwohl es eine relativ langsame Methode zur Datenübertragung ist – fast immer über Netzwerkgrenzen hinweg erlaubt ist, selbst in den sensibelsten Netzwerken.
Wichtiger Hinweis: Wir verwenden DNS-Abfragen zur Datenübertragung, nicht erfolgreiche DNS-Auflösungen. PacketWhisper muss niemals eine seiner DNS-Abfragen erfolgreich auflösen. Tatsächlich betrachtet PacketWhisper nicht einmal die DNS-Antworten. Dies erweitert unsere Anwendungsfälle und unterstreicht die Tatsache, dass wir niemals eine Domain, für die wir abfragen, kontrollieren müssen und niemals einen DNS-Nameserver kontrollieren müssen, der DNS-Anfragen bearbeitet.
Mit PacketWhisper verwandeln wir also eine Nutzlast, die so aussieht:
In eine Liste von FQDNs wie diese:
Die PacketWhisper in DNS-Abfragen umwandelt, die im Netzwerkverkehr so erscheinen:
Die Sie als PCAP-Datei an einem beliebigen Punkt entlang des DNS-Auflösungspfads erfassen und dann diese PCAP in Ihre lokale Kopie von PacketWhisper laden, um die Nutzlast wiederherzustellen:
Siehe die DEF CON 26-Folien (im Projekt enthalten) aus meinem Vortrag im Packet Hacking Village. Die Folien bieten Hintergrundinformationen zu DNS-Exfiltration, textbasierter Steganographie / dem Cloakify-Toolset und wie PacketWhisper diese zu einer Methode zur Datenübertragung kombiniert. Ich habe die Folien bewusst so erstellt, dass sie für sich allein nützlich sind, daher sollten die Hintergrundinformationen vollständig sein. Sie können sich jedoch auch das Video meines DC26-Packet-Hacking-Village-Vortrags ansehen, das zusätzlichen Kontext bietet.
Ich habe eine Beispiel-PCAP-Datei in das Projekt aufgenommen (passenderweise „sample.pcap“ genannt), die separate Nutzlasten für jeden der Cipher enthält. Sie hätten natürlich jeder Dateityp sein können, aber in diesem Fall habe ich lediglich Textdateien in die PCAP übertragen. Laden Sie sie in PacketWhisper und probieren Sie es aus!
Als schnellen Test in Ihrer eigenen Umgebung führen Sie PacketWhisper von einer VM aus aus, senden Sie dann eine Datei und führen dabei eine Paketerfassung auf dem Netzwerkinterface der VM über das Hostsystem durch. Anschließend können Sie die PCAP-Datei in eine beliebige PacketWhisper-Instanz laden, um die Datei zu dekodieren. Denken Sie daran, dass es sich nicht um eine schnelle Übertragung handelt. Kleinere Dateien und Geduld sind Ihre Freunde.
Frage: „Warum hast du nicht Scapy oder das dnspython-Toolset verwendet?“
Antwort: Ich hasse Projektabhängigkeiten in meinen operativen Tools. Ich halte meine Projekte so atomar und in sich geschlossen wie möglich, um maximale Zuverlässigkeit zu gewährleisten, insbesondere auf der Client-Seite, wo ich möglicherweise keine Kontrolle über die Umgebung habe und/oder nur minimale Rechte besitze. Durch die Struktur von PacketWhisper kann ich es auf einem eingeschränkten Shell-Host zum Laufen bringen, indem ich das Projekt einfach als Tar-Archiv packe und auf dem Zielhost extrahiere.
Frage: „Warum ist PacketWhisper kein Fork des Cloakify-Toolsets?“
Antwort: Gleiche Antwort wie oben. Wir benötigen nur eine sehr spezifische Teilmenge der Fähigkeiten von Cloakify, und alles andere zu PacketWhisper hinzuzufügen würde nur zu einem überladenen Verzeichnis und Tools/Ciphern führen, die von PacketWhisper nicht verwendet werden können. Da ich beide Projekte betreibe, verspreche ich, alle Änderungen zwischen beiden zu synchronisieren.
$ python packetWhisper.py
FQDN-basierte Cipher bestehen aus 3 Kategorien:
Einzigartige zufällige Subdomain-FQDNs
EMPFOHLENER CIPHER-MODUS FÜR DIE MEISTEN ANWENDUNGSFÄLLE
Hierbei handelt es sich um FQDNs mit randomisierten Elementen, die in die Subdomains eingebaut sind. Dies hilft, DNS-Caching zu verhindern, und ermöglicht gleichzeitig die Übertragung von Daten über NAT-fähige Netzwerkgeräte hinweg, die sich entlang des DNS-Abfragepfads befinden könnten. Da die IP-Adresse des sendenden Systems jenseits des NAT-Geräts nicht verfügbar ist, enthalten die vom Cipher generierten Subdomains eindeutige Tag-Elemente, um uns bei der Identifizierung von PacketWhisper-Nutzlasten im Paketmitschnitt zu helfen.
Diese Cipher ahmen die Formate verschiedener Dienste nach, die auf komplexe Subdomains als Mittel zur Identifizierung einer Sitzung, eines Benutzers, von zwischengespeicherten Inhalten usw. angewiesen sind. Dieser Ansatz hilft den DNS-Abfragen von PacketWhisper, sich in den restlichen Verkehr des Netzwerks einzufügen.
Der erste Teil des Subdomain-Namens ist tatsächlich ein String aus der Cipher-Liste. Der Rest des Subdomain-Namens wird randomisiert, um jede FQDN einzigartig zu machen, was verhindert, dass DNS-Caching den DNS-Abfragepfad vorzeitig unterbricht. Dann fügen wir den Domainnamen hinzu. Wir konstruieren die FQDNs auf diese Weise, damit sie wie die üblichen FQDNs der ausgewählten Domain aussehen und sich besser in den normalen Webverkehr einfügen, der in jedem Netzwerk zu sehen ist.
Einzigartige sich wiederholende FQDNs
Entwickelt, um sich von allen anderen DNS-Abfragen im Netzwerk abzuheben, jedoch ohne jegliche Randomisierung. Dies bedeutet, dass DNS-Caching stören kann, aber als Nebeneffekt werden Ihre DNS-Abfragen für Sie leicht zu finden sein, selbst in der größten Sammlung von Multi-Client-PCAPs. Dies liegt daran, dass die FQDNs ungewöhnliche Endpunkte sind, wie die Liste der „Johns“ (Red-Lectroid-Aliens) bei der fiktiven Yoyodyne Propulsion Systems aus dem Film „Buckaroo Banzai – Die 8. Dimension“.
FQDNs gängiger Websites
Dies sind FQDNs, die aus gängigen Website-URLs konstruiert werden.
HINWEIS: Da die meisten Umgebungen an der Peripherie NAT-fähig sind (was die Sichtbarkeit der Client-IP-Adresse entfernt), ist dieser Modus im Allgemeinen nur für die Übertragung von Daten zwischen Systemen nützlich, die mit demselben lokalen /24-Netzwerk verbunden sind (z. B. das Gäste-WLAN in Ihrem Lieblingscafé).
Da Common-Website-Cipher nur die Quell-IP-Adresse als Möglichkeit haben, ihre Abfragen von all den anderen ähnlichen DNS-Abfragen im Netzwerk zu unterscheiden, sendet PacketWhisper zu Beginn und am Ende der Nutzlast eine eindeutige „Klopfsequenz“-DNS-Abfrage, die uns später hilft, den sendenden Host aus der PCAP-Datei herauszufiltern.
Beispiel-FQDN: www.github.com
Sobald Sie einen Cipher ausgewählt haben, kodiert PacketWhisper die Nutzlast (Cloakifies) in eine Liste von FQDN-Strings gemäß dem gewünschten Cipher. Anschließend werden nacheinander DNS-Anfragen generiert, um die Daten entlang des DNS-Auflösungspfads zu senden. PacketWhisper fügt zwischen jeder DNS-Abfrage eine kleine Verzögerung ein, um außer der Reihe eintreffende DNS-Anfragen zu verhindern.
Das Schlüsselelement ist natürlich die Fähigkeit, den Netzwerkverkehr zu erfassen, der die von PacketWhisper generierten DNS-Abfragen enthält. Es gibt viele Optionen, da Sie sich nur irgendwo mit Sichtbarkeit auf den DNS-Abfragepfad befinden müssen.
Beispiele für Erfassungspunkte:
Nutzen Sie Ihre Fantasie. Jedes Gerät entlang des DNS-Auflösungspfads ist eine Option, einschließlich Wanddisplays. „Moment, was?“
HINWEIS: VPN-Verbindungen blockieren die Sichtbarkeit zwischen Host und VPN-Ausgangsknoten. Wenn der Client, von dem Sie übertragen, eine aktive VPN-Verbindung hat, können Sie keine DNS-Abfragen sehen, es sei denn, Sie können den Datenverkehr stromaufwärts vom VPN-Ausgangsknoten erfassen. Selbst das Erfassen auf demselben System wird fehlschlagen. Da viele von Ihnen wahrscheinlich VPNs verwenden, versuchen Sie, PacketWhisper von einer gehosteten virtuellen Maschine (VM) aus zu senden und den Verkehr auf dem Netzwerkinterface der VM auf dem Hostsystem zu erfassen.
Sobald Sie die PCAP-Datei erfasst haben, stellen Sie die Nutzlast wieder her, indem Sie PacketWhisper auf einem System ausführen, auf dem tcpdump (bei Linux & MacOS enthalten) oder WinDump (Windows) installiert ist. PacketWhisper fragt Sie, welcher Cipher verwendet wurde, extrahiert dann die Nutzlast aus der PCAP und dekodiert schließlich die extrahierte Nutzlast mit dem passenden Cipher.
Wichtiger Hinweis: Innerhalb derselben PCAP können Sie eine Nutzlast pro verwendetem Cipher übertragen. Eine PCAP, die mehr als eine Nutzlast mit demselben Cipher enthält, verursacht Probleme. Zum Beispiel enthält meine mitgelieferte „example.pcap“-Datei 5 Nutzlasten, eine für jeden der derzeit verfügbaren operativen Cipher. Wenn eine der Nutzlasten denselben Cipher wie eine andere verwendet hätte, würde PacketWhisper fehlschlagen, beide zu extrahieren. Die einfache Lösung besteht darin, die PCAP-Datei aufzuteilen (deshalb gibt der PacketWhisper-Sendecode die UTC-Datum/Uhrzeit beim Start und Ende der Übertragung aus). Ich arbeite daran, mehrere Nutzlasten mit demselben Cipher zu ermöglichen; die Lösung ist bereits vorhanden, ich muss sie nur noch umsetzen.
Stellen Sie sicher, dass Ihre PCAP-Datei tatsächlich das PCAP-Format hat. Wenn Sie tcpdump oder WinDump zum Erfassen der Datei verwendet haben, sind Sie auf der sicheren Seite. Wireshark bietet jedoch eine Vielzahl von „Speichern unter...“-Optionen zum Speichern von Wireshark-Verkehr, von denen nur eine tatsächlich tcpdump/PCAP-kompatibel ist. Ich arbeite an einer besseren Fehlerberichterstattung, um Fehler frühzeitig zu erkennen.
Kein sicheres Verschlüsselungsschema. PacketWhisper ist kein sicheres Verschlüsselungsschema. Es ist anfällig für Häufigkeitsanalyse-Angriffe. Verwenden Sie die Kategorie „Einzigartige zufällige Subdomain-FQDNs“ der Cipher, um Entropie hinzuzufügen und Häufigkeitsanalyse-Angriffe zu erschweren. Wenn Geheimhaltung der Nutzlast erforderlich ist, verschlüsseln Sie die Nutzlast unbedingt, bevor Sie PacketWhisper zur Verarbeitung verwenden.
Keine Hochbandbreiten-Übertragungsmethode. PacketWhisper basiert auf DNS-Abfragen, die UDP-basiert sind, was bedeutet, dass die Reihenfolge der Zustellung (oder sogar die erfolgreiche Zustellung) der Anfrage nicht garantiert ist. PacketWhisper fügt standardmäßig eine kleine Verzögerung (1/2 Sekunde) zwischen jeder DNS-Abfrage ein. Sie können Nutzlasten sicher mit einer Rate von etwa 7,2 KB pro Stunde (120 Bytes pro Minute) übertragen. Das bezieht sich auf die Größe der ursprünglichen Nutzlast, nicht auf die getarnte Ausgabedatei. Sie können sich für keine Verzögerung zwischen den Abfragen entscheiden, was die Übertragung drastisch beschleunigt, aber das Risiko von erhöhtem Netzwerkrauschen und beschädigter Nutzlast birgt.
Und seien wir ehrlich: Wenn Ihnen andere als DNS-basierte Datenübertragungsmodi zur Verfügung stehen, können Sie einfach das Haupt-Cloakify-Toolset verwenden, um die Datei im Klartext zu verstecken (vielleicht die Nutzlast in eine Liste von Pokémon-Go-Monstern mit LatLon-Koordinaten umwandeln) und die gesamte verfügbare hohe Bandbreite über FTP/HTTP usw. nutzen. DNS ist extrem nützlich, wenn andere Protokolle blockiert sind, aber seien Sie sich immer Ihrer Optionen bewusst.
DNS ist DNS. Unterschiedliche Betriebssysteme haben unterschiedliche DNS-Caching-Richtlinien usw. Netzwerke können ausfallen, isoliert sein usw. PacketWhisper enthält eine schnelle manuelle Überprüfung, ob es gängige FQDNs auflösen kann, aber DNS ist oft eine unordentliche Angelegenheit. Denken Sie an die alte IT-Fehlerbehebungs-Mantra: „Es ist immer DNS.“
Siehe die DEF CON 26-Folien (im Projekt enthalten) aus meinem Vortrag im Packet Hacking Village. Abwehrstrategien werden gegen Ende der Präsentation behandelt. Wie bei allem gilt: „Sicherheit in der Tiefe“ ist Ihr Freund, insbesondere da DNS-Auflösungspfade riesige Gebiete umfassen, die außerhalb der Kontrolle Ihrer Organisation liegen.
Ich werde Modi für MDNS- und LLMNR-DNS-Broadcast-Modi im lokalen Netzwerk hinzufügen. Diese sind für Systeme gedacht, die mit demselben lokalen Netzwerk verbunden sind, und werden die Notwendigkeit beseitigen, dass das erfassende Gerät beim Erfassen von WLAN-Paketen Zugriff auf den Promiscuous-Modus haben muss. (Diese Protokolle senden Verkehr an x.y.z.255 im Host-Netzwerk und senden diesen an alle anderen Systeme im selben lokalen Netzwerk.)
Ich werde auch weitere Cipher hinzufügen, aber für den täglichen Bedarf reicht die aktuelle Cipher-Sammlung völlig aus. Sie werden damit gute Ergebnisse erzielen.
Ich arbeite auch daran, mehrere Nutzlasten mit demselben Cipher in einer einzigen PCAP-Datei zu ermöglichen. Die Lösung ist bereits als Prototyp vorhanden, macht aber den PCAP-Extraktionsworkflow für den Benutzer unschöner. Operativ könnte es mehr Ärger machen, als es nützt. Ich bevorzuge immer sauberere operative Funktionalität gegenüber Schweizer-Taschenmesser-Komplexität.
