
Proof-of-Concept-Skript, das die Benutzeraufzählung in LiquidFiles über den Passwort-Reset-Endpunkt demonstriert und so die Identifizierung gültiger Benutzer für Brute-Force-Angriffe ermöglicht.
Diese Schwachstelle wurde in LiquidFiles Version 4.1 und älter identifiziert.
Beim Initiieren eines Passwort-Resets über den Endpunkt „POST /password_reset“ reagiert die Anwendung unterschiedlich, je nachdem, ob die angegebene E-Mail-Adresse registriert ist. In beiden Fällen wird eine Weiterleitung ausgelöst, und die Antwort enthält das Cookie „_filetransfer_session“. Wenn dieses Cookie verwendet wird, um auf den Root-Pfad („/“) zuzugreifen, unterscheidet sich die resultierende Fehlermeldung je nach Gültigkeit der übermittelten E-Mail-Adresse.
Dies ermöglicht es einem Angreifer effektiv, eine Liste gültiger Benutzer zu erstellen, die anschließend für Angriffe wie Brute-Force- oder Password-Spraying-Angriffe genutzt werden kann.
Passwort-Reset-Antwort – bestehende/gültige Benutzer
Passwort-Reset-Antwort – nicht existierende/ungültige Benutzer
Nach mehreren Passwort-Reset-Versuchen wird als Sicherheitsmaßnahme eine IP-basierte Sperre ausgelöst, die weitere Anfragen von derselben IP-Adresse verhindert. Dieser Mechanismus ist jedoch unzureichend, da er mit kostenlosen Tools umgangen werden kann. Beispielsweise lässt sich die Sperre mithilfe von AWS-API-Gateway-Proxys in Kombination mit der Erweiterung „IP Rotate“ in Burp Suite umgehen. Das Skript erwartet einen lokalen Proxy auf Port 8080.
Verwendete App zur Umgehung der IP-basierten Sperre:
Diese Diskrepanz in den Fehlermeldungen ermöglicht die automatisierte Enumeration gültiger Benutzernamen oder E-Mail-Adressen. Um dies zu demonstrieren, habe ich ein Proof-of-Concept-Skript erstellt, das eine Liste potenziell registrierter E-Mail-Adressen verarbeitet und anhand des Antwortverhaltens der Anwendung gültige Adressen identifiziert.
Ausgabe des Benutzer-Enumeration-Skripts:

Sobald gültige Benutzernamen identifiziert wurden, können diese für Brute-Force- oder Password-Spraying-Angriffe genutzt werden. Da einige Benutzer möglicherweise schwache oder wiederverwendete Passwörter verwenden, stellt dies ein hohes Sicherheitsrisiko dar.
Die Wahrscheinlichkeit einer Ausnutzung ist hoch, aktuelle Sicherheitsmaßnahmen lassen sich leicht umgehen, und die Ausnutzung ist unkompliziert. Die Auswirkung wird als mittel eingestuft, da man nach Erhalt einer Liste gültiger Benutzer weiterhin ein Konto durch Password-Spraying- oder Brute-Force-Angriffe kompromittieren muss.
Beachten Sie, dass diese Anwendung von vielen verschiedenen Organisationen genutzt wird und fast immer öffentlich über das Internet erreichbar ist. Dies macht es lediglich zu einer Frage des Sammelns von Mitarbeiter-E-Mail-Adressen oder -Namen aus dem Internet und des Password-Sprayings gegen die Anwendung.
Infolgedessen stellt dieses Problem ein hohes Risiko dar.
Version 4.2 behebt dieses Problem durch die Einführung benutzerbasierter Sperrmechanismen und durch die Deaktivierung unterschiedlicher Fehlermeldungen, die standardmäßig eine Benutzer-Enumeration ermöglichen.