FireAway – Tool zur Umgehung von Next-Generation-Firewalls

========= v0.2

Fireaway ist ein Tool zur Überprüfung, Umgehung und Exfiltration von Daten gegen Layer‑7-/AppID‑Inspektionsregeln auf Next‑Generation‑Firewalls sowie gegen andere Deep‑Packet‑Inspection‑Abwehrmechanismen wie Data‑Loss‑Prevention (DLP) und anwendungsbewusste Proxys. Diese Taktiken beruhen auf dem Prinzip, dass Verbindungen durch die NGFW aufgebaut werden müssen, um Layer‑7‑Daten zur Filterung zu sehen, sowie auf der Nachahmung von Anwendungen, um Kommunikationskanäle in den Firewall‑Protokollen als normalen Benutzerverkehr (z. B. Internetsurfen) zu tarnen. Bei der Umgehung von Data‑Loss‑Prevention‑Tools sendet Fireaway Daten in kleinen „Chunks“, die keine regulären Ausdrücke oder andere DLP‑Regeln auslösen, und bettet Daten in gefälschte HTTP‑Header legitimer Anwendungen ein, die die meisten DLP‑Technologien nicht prüfen sollen. Das Tool konnte zudem durch die Fähigkeit, Anwendungsheader zu fälschen und Daten darin zu verstecken, Anomalie‑Erkennungs‑ und Heuristik‑Engines erfolgreich überlisten.

Starten des FireAway‑Servers: Typischerweise wird der FireAway‑Server auf der egress‑Seite der Firewall (z. B. ein Server im Internet) gestartet und horcht auf einem Port, der vermutlich geschlossen ist, um zu prüfen, ob anwendungsbasierte Regeln Datenverkehr auf diesem Port erlauben, oder um rohe Datenblöcke zu empfangen, um zu sehen, ob DLP‑ oder Anwendungsproxy‑Lösungen sie identifizieren können:

python fa_server.py <port to listen on>  <mode number>

Der Server kann in vier Modi gestartet werden:

• Testmodus (Modus 0) – Empfängt sequenziell oder zufällig gesendete Testdaten. Die Daten werden wie empfangen geschrieben, es ist keine Zusammenstellung erforderlich.

• Sequenzieller Chunk‑Empfang (Modus 1) – Daten werden an einen oder mehrere Server in der vom Client festgelegten Chunk‑Größe gesendet. fa_server zeichnet den Zeitstempel des Eingangs jedes Chunks in der Ausgabe auf und verwendet die Empfangszeit als Sortierschlüssel für die Zusammenstellung. Es wird außerdem ein „Reassembly‑Key“ vom Server generiert, der mit fa_assembler.py verwendet wird. Dabei handelt es sich um einen zufällig erzeugten 4‑Zeichen‑Schlüssel, der als Trennzeichen zwischen den Chunks dient, mit der Idee, dass diese Zeichen in den übertragenen Datenblöcken nicht vorkommen.

• Zufälliger Chunk‑Empfang (Modus 2) – Daten werden in zufälliger Reihenfolge an einen oder mehrere Server gesendet. Dieser Modus ist abhängig von der Übertragung einer „Sequence‑Key“‑Nachricht vom Client an einen zufälligen Server im Pool. Beim Starten jedes Servers wird der Server zur Eingabe eines „Sequence‑Key‑Identifiers“ auffordern. Dies sollte ein Muster sein, das in der übertragenen Datei nicht vorkommt, damit der Server die als Sequence‑Key empfangenen Daten über eine Verbindung korrekt identifizieren kann. ACHTUNG: DER GLEICHE SEQUENCE‑KEY‑IDENTIFIER MUSS AUF ALLEN SERVERN VERWENDET WERDEN! Der Client wählt zufällig einen Server aus, an den der Sequence‑Key gesendet wird. Daher ist es wichtig, dass alle Server den Sequence‑Key in ihren empfangenen Daten lokalisieren können. Der Sequence‑Key wird vom empfangenden Server in einer Datei namens 'SequenceKey.txt' aufgezeichnet.

• Spoofed‑App‑Chunk‑Empfang (Modus 3) – Base64‑codierte Daten werden in HTTP‑Headern, die legitime Anwendungen imitieren, an einen oder mehrere Server gesendet. Auch dieser Modus generiert einen „Reassembly‑Key“ für die Verwendung mit dem fa_assembler‑Skript.

Alle Daten, die von den Servern auf dem angegebenen Port empfangen werden, werden in der Datei ReceivedData.txt im Verzeichnis, aus dem der Server gestartet wurde, gespeichert. Wenn der Server unterschiedliche Größen der empfangenen Datenmengen feststellt (was auf das Eingreifen der Firewall‑Filterung hindeutet), wird diese Ausgabe auf der Server‑Konsole angezeigt:

Got the same or lower amount of data on two consecutive runs.  If sending test data, maximum data leak size may have been reached.

Starten des FireAway‑Clients / Application‑Spoofers: Der FireAway‑Client hat drei Modi:

• Testmodus (Modus 0) – Sende zufällige Daten in inkrementell größeren Blöcken, um zu ermitteln, wie viele Daten gesendet werden können, bevor Layer‑7‑Kontrollen eingreifen und den Datenverkehr stoppen.

• Sequenzieller Exfiltrationsmodus (Modus 1) – Öffnen einer Datei und Senden in Blöcken einer bestimmten Größe. Die Daten werden sequenziell übertragen.

• Zufälliger Exfiltrationsmodus (Modus 2) – Öffnen einer Datei und Senden in Blöcken einer bestimmten Größe, jedoch in zufälliger Reihenfolge. Bei Verwendung dieses Modus fragt der Client nach dem Sequence‑Key‑Identifier. Dies ist der auf den entfernten Servern angegebene Wert. Der Client kennzeichnet den generierten Sequence‑Key mit dem Identifier, der an einen zufälligen Server gesendet wird (sofern eine Liste angegeben ist) oder an die angegebene Server‑IP, bevor die Datei übertragen wird.

Starten des Basis‑Clients:

python fa_client.py <FireAway server IP or path of server list file> <Fireaway Server Port> <Client mode>

Die Serverliste sollte eine einfache Textdatei sein, die eine Liste von IP‑Adressen enthält, eine pro Zeile. Wenn nur ein Server verwendet wird, kann stattdessen eine einzelne IP angegeben werden.

Der Application‑Spoofing‑Client hat drei Modi:

• Testmodus (Modus 0) – Sende zufällige Testdaten innerhalb von HTTP‑Headern in stufenweise größeren Blöcken, um zu ermitteln, wie viele Daten gesendet werden können, bevor Layer‑7‑Kontrollen eingreifen und den Datenverkehr stoppen.

• Base64‑codierter Exfiltrationsmodus (Modus 1) – Base64‑Codierung einer Eingabedatei und Übertragung von Teilen der codierten Datei innerhalb von zufällig generierten HTTP‑Headern, um DLP zu umgehen und die Übertragung als legitime Anwendung zu tarnen.

Starten des Application‑Spoofing‑Clients:

python fa_spoof.py <FireAway server IP or path of server list file> <Fireaway Server Port> <Client mode>

Application‑Spoofing fügt zufällige HTTP‑Header innerhalb von legitim aussehenden Anwendungs‑Headern (z. B. Facebook, LinkedIn usw.) mit den Datenblöcken ein, um die Protokolle mit verschiedenen Anwendungen zu füllen und so die Datenexfiltration zu tarnen.

Fireaway‑Zusammensteller (Reassembler): Der Fireaway‑Zusammensteller (fa_assembler.py) wird verwendet, um die von den Fireaway‑Servern empfangenen Daten wieder zusammenzusetzen. Der Assembler hat drei Modi, die den Modi der Server entsprechen, die die Daten empfangen haben:

• Modus 1 – Setzt Daten zusammen, die von Servern in Modus 1 in sequenzieller Reihenfolge empfangen wurden. Der Assembler fragt nach dem Reassembly‑Key für die Datei mit den empfangenen Daten jedes Servers. Dies ist der zufällige Wert, den der Server beim Start generiert und angezeigt hat. Dieser Wert kann auch durch Untersuchen der Dateien mit den empfangenen Chunks und Betrachten der ersten vier Zeichen ermittelt werden.

• Modus 2 – Setzt Daten zusammen, die von Servern in Modus 2 in zufälliger Reihenfolge empfangen wurden. Der Assembler fragt nach dem Pfad zum Sequence‑Key, der während der Übertragung von einem zufälligen Server vom Client empfangen wurde. Außerdem wird nach den Reassembly‑Keys für jede Datei gefragt.

• Modus 3 – Setzt Base64‑codierte Daten zusammen, die in Spoofed‑Application‑HTTP‑Headern empfangen wurden. Diese Daten fragen, ähnlich wie Modus 1, ebenfalls nach dem Reassembly‑Key.

Starten des Assemblers:

python fa_assembler.py <reassembly mode> <comma separated paths to files to reassemble>

Die Ausgabe wird unter dem angegebenen Dateinamen gespeichert.

Bitte melden Sie Probleme oder Fragen über Github.