Im Beitrag Network Access Control – Was gibt es bei NAC noch zu beachten? beschreibt Dominik Altermatt die Grundlagen zu Network Access Control (NAC) und geht kurz auf die Umgehung eines solchen Kontrollmechanismus ein. In diesem Labs stellen wir eine praktische Lösung zur Umgehung einer port-basierten Netzwerkzugangskontrolle nach IEEE 802.1X vor.

Auf den Schultern von Riesen

Im Jahre 2011 stellte Alva Lease ‘Skip’ Duckwall IV an der Defcon 19 mit der Präsentation A Bridge Too Far eine Lösung zur Umgehung von 802.1X mittels einer Linux Transparent Bridge vor. Mit diesen Grundlagen hat Matt E das Bash-Skript NACkered v2.92.2 geschrieben. Dieses Skript dient wiederum als Basis für unsere Skript-Kollektion NAC-Bypass, die wir auf unserem GitHub-Account veröffentlicht haben.

Zu Beginn war geplant NACkered zu verwenden und wenn nötig punktuelle Anpassungen vorzunehmen. Nach und nach haben wir aber so viele Umstellungen vorgenommen, dass daraus eine separate Lösung entstanden ist. Als eine der Erweiterungen haben wir eine Unterstützung für das Tool Responder von Laurent Gaffié eingebaut. Denn die Kombination NAC-Bypass und Responder ist bei internen netzwerkbasierten Penetration Tests oder als Bestandteil eines Redteam-Assessments sehr nützlich, um an Zugangsdaten zu gelangen.

Voraussetzungen und Setup

Die Grundvoraussetzung für einen NAC-Bypass ist der Zugang zu einem bereits authentisierten Gerät. Mit diesem Gerät findet die Anmeldung am Netzwerk statt und anschliessend können über dieses Gerät Netzwerk-Pakete von einem fremden Gerät eingeschleust werden. Dazu wird das System des Angreifers zwischen den Netzwerk-Switch und dem authentisierten Gerät platziert. Dafür kann unter anderem ein Raspberry Pi mit zwei Netzwerkadaptern eingesetzt werden.

Das Skript NACkered und unsere Lösung nac_bypass_setup.sh wurde auf Debian basierenden Linux-Distributionen geschrieben und getestet. Beide sollten aber unter anderen Linux-Distributionen ebenfalls lauffähig sein. Die folgenden Software-Pakete werden benötigt:

• bridge-utils
• macchanger
• arptables, iptables und ebtables
• mii-tool
• tcpdump
• br_netfilter (Kernelmodul)

Bei arptables, iptables und ebtables ist zu beachten, dass nicht die Netfilter xtable tools (nft) verwendet werden, ansonsten funktioniert das Skript nicht wie gewünscht.

Das Skript nac_bypass_setup.sh verfügt über die folgenden Parameter:

nac_bypass_setup.sh v0.6.1 usage:
    -1 <eth>    network interface plugged into switch
    -2 <eth>    network interface plugged into victim machine
    -a          autonomous mode
    -c          start connection setup only
    -h          display this help
    -i          start initial setup only
    -r          reset all settings
    -R          enable port redirection for Responder
    -S          enable port redirection for OpenSSH and start the service

Die Parametern -1 und -2 definieren die zu verwendenden Netzwerkadapter, andererseits können diese auch im Skript direkt editiert werden. Mittels -a wird die Ausgabe von Log- und Debug-Informationen des Skripts unterdrückt und es ist keine manuelle Interaktion im Ablauf notwendig. Mit den Parametern -R und -S wird die Port-Weiterleitung für die Nutzung von SSH und Responder aktiviert. Die Parameter -c, -i und -r lösen nur bestimmte Abfolgen innerhalb des Skripts aus. Deren Einsatzzweck wird später genauer beschrieben.

Anwendung

Die Anwendung des Skripts nac_bypass_setup.sh zusammen mit einem legitimen Gerät sieht schematisch dargestellt so aus:

Das legitime Gerät Client ist zu Beginn nicht mit dem Netzwerk-Switch verbunden. Das Skript wird nun auf dem Angreifer-Gerät Bypass gestartet. Bei Bypass und Attacker handelt es sich um ein physisches Gerät. Die Figur Attacker symbolisiert Aktionen, die der Angreifer auf dem NAC-Bypass-Gerät durchführt. Zunächst wird die Initialkonfiguration vorgenommen: Zum Start werden unerwünschte Dienste wie NetworkManager beendet, IPv6 deaktiviert und allfällige DNS-Konfigurationen initialisiert. Danach wird die Bridge konfiguriert und gestartet. Damit das Bridging wie gewünscht funktioniert, muss eine Kernel-Konfiguration zur Weiterleitung von EAPOL-Frames vorgenommen werden. Ohne diese Anpassung findet keine 802.1X-Authentisierung statt.

Nach Abschluss der Konfiguration können die Netzwerkkabel verbunden werden und die Switch-Seite der Bridge ist nun als passive Weiterleitungsstelle aktiv. Das Gerät Bypass leitet allen Netzwerkverkehr vom Switch zum Client und zurück, kann selbst aber noch keine Pakete versenden. Der Client sollte sich nun beim Netzwerk-Switch authentisieren und erfolgreich am Netzwerk anmelden können.

Der gesamte Netzwerkverkehr wird über die Bridge geleitet und kann entsprechend analysiert werden. Dies wird genutzt, um Kerberos- und SMB-Pakete mit tcpdump aufzuzeichnen – da diese normalerweise in einem Windows-Netzwerk vermehrt auftreten – um daraus die Netzwerk-Konfiguration wie IP- und MAC-Adresse des Clients auszulesen. Mit diesen Informationen wird die Client-Seite der Bridge automatisch konfiguriert. Die Verbindung von Bypass ins Netzwerk bleibt aber noch blockiert, damit sichergestellt ist, dass Netzwerkpakete vom Angreifer-Gerät ins Netzwerk gelangen und zu einer Entdeckung führen. Wenn später Pakete des Attackers ins Netzwerk gesendet werden, wird durch eine ebtables-Regel die MAC-Adresse überschreiben, sodass die Pakete aussehen, als ob sie vom Client stammen. Das gleiche Prozedere wird mittels iptaples-Regeln auf IP-Ebene umgesetzt, sodass ausgehende TCP-, UDP- und ICMP-Pakete ebenso über die IP-Adresse des Clients verfügen. Schlussendlich kann die Verbindung vom Attacker ins Netzwerk geöffnet werden und der Angreifer kann Aktionen auf seinem eigenen Gerät durchführen.

Falls die Port-Weiterleitungen für SSH und Responder aktiviert wurden, leitet die Bridge alle Anfragen auf die jeweiligen Ports auf die Dienste des Attackers weiter. Dort kann eine Responder-Instanz betrieben werden, die Multicast-Poisoning vornimmt und als Authentisierung für Protokolle wie SMB, FTP oder HTTP agiert. Aus dem Netzwerk ist diese Instanz über die IP-Adresse des Clients erreichbar.

NAC-Bypass in der Endlos-Schlaufe

Das oben beschriebene Szenario wird nur dann möglich, wenn der Angreifer im Besitz eines legitimen Gerätes ist. Wenn der Angreifer aber nur physischen Zugang in ein Gebäude und deren Räume hat, und über kein eigenes Gerät verfügt, sind zusätzliche Schritte notwendig. Verfügt ein Raum um eine Netzwerk-Installation wie ein Sitzungszimmer oder ein Shared-Workspace, kann das Bypass-Gerät trotzdem platziert werden. Dabei muss aber beachtet werden, dass das NAC-Bypass-Setup agil ist und auf Veränderungen wie wechselnde Geräte reagieren kann. Beim Beispiel eines Shared-Workspaces wird morgens der Benutzer1 sein Gerät an die Dockingstation anschliessen. Das versteckt platzierte Bypass-Gerät richtet seine Konfiguration auf Benutzer1 ein. Sobald dieser den Shared-Workspace verlässt, setzt sich das Bypass-Gerät in den Ausgangszustand zurück und wartet auf neue Geräte. Wenn Benutzer2 sein Gerät an der Dockingstation anschliesst, darf das Bypass-Gerät nicht mehr mit der Konfiguration des Benutzer1 laufen, sondern muss die Angaben von Benutzer2 übernehmen, damit eine Netzwerkverbindung aufgebaut wird.

Dazu findet auf dem Bypass-Gerät eine Prüfung der Netzwerkkonnektivität in einem bestimmten Zeitintervall statt, welche dann auf Zustandsänderungen reagiert und die passenden NAC-Bypass-Prozedur aufruft. Eine einfache Form dieser Prüfung haben wir mit dem Skript awareness.sh implementiert. Dort wird der Netzwerkstatus eines Adapters alle 5s geprüft und bei Statusänderungen eine entsprechende Aktion ausgelöst.

while true
do
    NETWORK_STATE_INTERFACE=`cat "/sys/class/net/$INTERFACE/carrier"`

    if [ "$NETWORK_STATE_INTERFACE" -ne "$STATE_INTERFACE" ]; then

        STATE_COUNTER=0

        if [ "$NETWORK_STATE_INTERFACE" -eq 1 ]; then
            echo "[!] $INTERFACE is now up!"
        else
            echo "[!] $INTERFACE is now down!"
        fi
    else

        if [ "$STATE_COUNTER" -eq "$THRESHOLD_UP" ] && [ "$NETWORK_STATE_INTERFACE" -eq 1 ]; then
            echo "[!!] Set new config"
            bash nac_bypass_setup.sh -a -c

        elif [ "$STATE_COUNTER" -eq "$THRESHOLD_DOWN" ] && [ "$NETWORK_STATE_INTERFACE" -eq 0 ]; then
            echo "[!!] Reset config"
            bash nac_bypass_setup.sh -a -r
            bash nac_bypass_setup.sh -a -i
        fi

        echo "[*] Waiting"
        ((STATE_COUNTER++))
    fi

    STATE_INTERFACE=$NETWORK_STATE_INTERFACE
    sleep $TIMER
done

Zuerst wird das Basis-Setup für den NAC-Bypass eingerichtet, danach wird eine Schlaufe gestartet, die den Zustand der Netzwerkschnittstelle überwacht. Der zweite Teil des NAC-Bypass-Setups wird dann ausgeführt sobald die Schnittstelle aktiv wird. Wird die Netzwerkverbindung getrennt, dann erfolgt ein Reset der Konfiguration und der Initialvorgang wird gestartet. Zwischen den Statusänderungen sind noch konfigurierbare Zyklen festgelegt, um vorschnelle Konfigurationsänderungen zu vermeiden, wenn beispielsweise ein temporärer Netzwerkunterbruch auftritt. Mit diesem Skript kann ein Bypass-Gerät auf wechselnde Geräte reagieren und es ist möglich dieses ohne manuelle Eingriffe vorzunehmen über längere Zeit in einem geeigneten Raum zu platzieren.

Wie geht es weiter

Das Skript awareness.sh reagiert auf Statusänderungen und passt die NAC-Bypass-Konfiguration entsprechend an. Alle weiteren Aktionen müssen zurzeit manuell erfolgen, beispielsweise über SSH auf dem Gerät. Dieser Dienst SSH ist aber nur im Netzwerk des Opfers erreichbar. Als einer der nächsten Schritte ist die Integration einer zusätzlichen Management-Schnittstelle, in Form eines WLAN- oder ein Mobilfunk-Netzwerkadapters, geplant. Mit diesem Adapter wird eine autonome Verbindung etabliert und der Angreifer kann auf das Gerät zugreifen, ohne physisch vor Ort oder im Netzwerk sein zu müssen. Zusätzlich könnte das Awareness-Skript um Module erweitert werden, welche eine weitere Autonomität gewährleisten. So kann eine Kommunikation über Command-and-Control-Server (C2) aufgebaut werden, um Befehle zu empfangen oder Daten zu extrahieren. Das Projekt NAC-Bypass ist auf GitHub verfügbar. Wir freuen uns über jegliches Feedback und Pull Requests sind gerne gesehen.

Ü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://g-laurent.blogspot.com/
• https://github.com/lgandx/Responder
• https://github.com/p292
• https://github.com/p292/NACKered
• https://github.com/scipag
• https://github.com/scipag/nac_bypass
• https://github.com/scipag/nac_bypass/blob/master/awareness.sh
• https://raspberrypi.org/
• https://twitter.com/0×6d69636b/status/1067802857141911552
• https://wiki.nftables.org/wiki-nftables/index.php/Legacy_xtables_tools
• https://www.defcon.org/images/defcon-19/dc-19-presentations/Duckwall/DEFCON-19-Duckwall-Bridge-Too-Far.pdf