SSH MITM Proxy Server für Security Audits einsetzen

Gastbeitrag von Manfred Kaiser

SSH erschien 1995 und entwickelte sich seither zu einem der meistbenutzten Standardwerkzeuge
für die Administration von Linux/Unix basierten Servern. Durch die immer größere Verbreitung
von IoT Geräten wurden Angriffe auf SSH häufiger. Gerade diese IoT Geräte sind ein lohnendes Ziel,
weil diese keine oder nur selten Updates bekommen – auch sind solche Geräte oft aus dem Internet erreichbar.

SSH-MITM Server und »Man in the Middle«-Angriffe

In vielen Fällen sind diese Geräte nur durch ein Standardpasswort oder ein einfach zu erratendes Passwort geschützt. Dies ist mitunter auch ein Grund, warum diese Geräte oft rasch in Botnetze integriert werden. In diesem Artikel wird beschrieben, wie ein »Man in the Middle«-Angriff (MITM) auf SSH funktioniert und diese Techniken für Security Audits von SSH Clients oder dem Monitoring von Honey Pots eingesetzt werden können. Als Software wird das Open Source Tool SSH-MITM verwendet, dass als Python PIP Package verfügbar ist.

SSH-MITM Server

SSH-MITM Server ist ein Tool, mit dem es möglich ist, einen »Man in the Middle«-Angriff auf SSH Verbindungen durchzuführen. Bei einem »Man in the Middle«-Angriff wird versucht die Verbindung zwischen dem Client und dem Server auf einen dritten Server umzuleiten. Dies kann durch die Konfiguration von statischen Routen oder ARP-Spoofing gemacht werden.

Natürlich ist es auch möglich den Client so zu konfigurieren, dass sich dieser mit dem MitM Server verbindet. Welche Methode verwendet werden soll, hängt vom jeweiligen Szenario ab und kann nicht pauschal beantwortet werden. In unserem Szenario gehen wir davon aus, dass sich der Client bewusst mit dem MitM- Server verbindet, was den Versuchsaufbau wesentlich erleichtert.

Installation des SSH MITM Proxy Servers

Als MITM-Proxy-Server wird der in Python geschriebene SSH MITM verwendet. Hierbei handelt es sich um ein sogenanntes Python PIP-Package, was sich unter Linux sehr einfach installieren lässt. Die einzige Voraussetzung ist Python 3.6 oder aktueller. Für die Installation sollte eine virtuelle Python Umgebung eingerichtet werden:

python3 -m venv ~/sshmitmenv

Diese wird aktiviert mit:

source ~/sshmitmenv/bin/activate

Danach kann der SSH MITM Proxy Server installiert werden:

pip install ssh-mitm

Anmerkung:
Sollte es bei der Installation zu Problemen kommen, liegt dies meist daran, dass die verwendete Version von PIP nicht aktuell genug ist. SSH-MITM verwendet die Bibliothek cryptography, welche in der aktuellen Version auf Rust umgestellt wurde und mit älteren Versionen von PIP nicht installiert werden kann. In diesem Fall reicht es aus, PIP mit folgendem Befehl zu aktualisieren:

pip install -U pip

Starten des Proxy Server

Als Gegenstelle benötigen Sie einen weiteren SSH Server. Sollten Sie keinen zusätzlichen Server verwenden wollen, können Sie SSH auch auf Ihrem lokalen Rechner installieren. Wir gehen in diesem Szenario davon aus, dass Sie sich mit ihrem lokalen Rechner verbinden möchten und dass Sie sich dort mit Benutzername und Passwort über SSH anmelden können. Um den Proxy-Server auf Port 22 starten zu können, müsste dieser mit privilegierten Rechten ausgeführt werden, was aber ein Sicherheitsrisiko darstellt. Aus diesem Grund ist es empfehlenswert, mit iptables eine Port-Umleitung zu machen:

iptables -t nat -A PREROUTING -p tcp –dport 22 -j REDIRECT –to-ports 10022

Auf diese Weise ist der Proxy Server über Port 22 von Außen erreichbar und kann über einen Netzwerkscan oder die Suchmaschine Shodan relativ einfach von einem Angreifer als SSH Service identifiziert werden. Um den Proxy-Server mit dem Honeypot als Ziel zu starten, muss über den Parameter --remote-host die IP-Adresse oder der Hostname des Honeypots angegeben werden:

ssh-mitm --remote-host 127.0.0.1

Nachdem der SSH-MITM gestartet wurde, kann man einen ersten Verbindungsversuch machen.
Der Proxy Server startet standardmäßig auf Port 10022:

ssh -p 10022 localhost

Beim Verbindungsaufbau werden wir gefragt, ob wir den den Fingerprint akzeptieren möchten:

The authenticity of host '[localhost]:10022 ([127.0.0.1]:10022)' can't be established.
RSA key fingerprint is SHA256:2nwwoCg0H+3eC3kl6H43g5Q65od2t7pDcvxWjjY6ni4.
Are you sure you want to continue connecting (yes/no)?

Interessant an dieser Log-Ausgabe ist die 2. Zeile, in der offenbar wird, dass der Client gegenüber CVE-2020-14145 anfällig ist. Ein sogenanntes Information Leak ermöglicht es einem SSH-Server zu erkennen, ob ein Client bereits den Fingerprint eines Server akzeptiert hat oder nicht. Dies kann von einem »Man in the Middle«-Angreifer dahin gehend ausgenutzt werden, dass er nur Clients abfängt, die keine Fehler ausgeben.

Verbindet sich der Client ein weiters Mal mit dem SSH-MITM-Server, nachdem der Fingerprint akzeptiert wurde, wird dies erkannt und eine entsprechende Log-Meldung ausgegeben:

2021-02-11 15:42:42,057 [INFO]  CVE-2020-14145: Client has a locally cached
remote fingerprint!

Diese Sicherheitslücke wurde in OpenSSH 8.4 teilweise behoben, sofern der Server den Algorithmus ecdsa-sha2 unterstützt. Wird dieser Algorithmus jedoch vom Server nicht angeboten, ist es immer noch möglich zu erkennen, ob sich der Client bereits einmal mit dem Remote Server verbunden hat. In der Dokumentation von SSH-MITM ist beschrieben, wie man OpenSSH Clients so konfigurieren kann, dass diese nicht mehr gegenüber dieser Sicherheitslücke anfällig sind.

Anmeldedaten auslesen und Übernahme der Shell- Verbindung

Nachdem das Passwort eingegeben wurd, gibt SSH-MITM die Anmeldedaten im Log aus:

2021-02-11 15:44:23,734 [INFO]  Client connection established with parameters:
    Remote Address: 127.0.0.1
    Port: 22
    Username: user
    Password: supersecret
    Key: None
    Agent: None
2021-02-11 15:44:24,367 [INFO]  created mirrorshell on port 41579. connect with: 
ssh -p 41579 127.0.0.1

Eine weitere Log-Zeile weist darauf hin, dass eine mirrorshell gestartet wurde und gibt auch gleich das Kommando aus, welches verwendet werden kann, um die aufgebaute Session zu übernehmen. Die mirrorshell wird von SSH-MITM dazu verwendet, um bei einem Security Audit in eine bestehende Verbindung eingreifen zu können. Nachdem man sich mit dieser Shell verbunden hat, werden sämtliche Ausgaben des Servers an beide SSH Clients übertragen. Es ist auch möglich, eigene Kommandos über die mirrorshell auszuführen.

Speichern der Terminal Session und übertragenen Dateien

Die einzelnen Sessions werden dann im Verzeichnis ~/sshlogs abgelegt und können dort mit einem Editor oder mit dem Terminal-Befehl scriptreplay analysiert werden. Für die Verwendung von scriptreplay wird auch ein sogenanntes Timing-File erstellt, das notwendig ist, um die gespeicherte Session abzuspielen. Näheres dazu vermittelt die Manpage zu scriptreplay.

Bei der Übertragung von Dateien muss zwischen SCP und SFTP unterschieden werden. Der Proxy Server unterstützt beide Übertragungsverfahren. Jedoch müssen diese separat konfiguriert werden. Dies erfolgt ebenfalls über Kommandozeilenparameter. Um per SCP übertragene Dateien zu speichern sind folgende Parameter anzugeben:

--scp-interface store_file --scp-storage ~/scpfiles

Für die mit SFTP übertragenen Dateien sind diese Parameter anzugeben:

--sftp-handler store_file --sftp-storage ~/sftpfiles

Die Dateien werden in den entsprechenden Ordnern mit einer eindeutigen ID als Namen abgelegt. Über das Logfile bzw. die Log-Ausgabe des Proxy-Servers kann die entsprechende Dateiübertragung mit der abgelegten Datei zusammengeführt werden.

Ausblick

Der SSH MITM Proxy Server stellt eine Alternative zu klassischen Honeypots dar, weil das Monitoring und der Honeypot voneinander getrennt werden können. Dadurch ist es für den Angreifer schwierig, die Überwachung zu erkennen und er hat auch keine Möglichkeit, das Monitoring des Honeypots zu unterbinden oder zu manipulieren. Ebenso eignet sich SSH-MITM dazu, um ein Security Audit bei SSH Clients durchzuführen.

In diesem Artikel wurde beschrieben, wie der SSH MITM Proxy Server installiert und gestartet werden kann.
Um die einzelnen Sessions zu analysieren, können Standard Linux Tools wie z.B. scriptreplay verwendet werden. Ebenso können die übertragenen Dateien, falls notwendig, einem Reverse Engineering unterzogen werden.