mcorybillington/suitecrm-rceWriteup zu CVE-2020-28328: Remote Code Execution über SuiteCRM-Logdateien plus etwas Bonus Cross-Site-Scripting
Ich habe kürzlich zwei Schwachstellen in SuiteCRM entdeckt, die eine Angriffskette für einen Benutzer mit geringen Rechten ermöglichen, um Code auf dem zugrunde liegenden Betriebssystem auszuführen. Die Angriffskette ist Cross-Site Scripting, das verwendet werden kann, um Cross-Site Request Forgery durchzuführen, was zu Remote-Code-Ausführung führt, indem die Anwendungskonfiguration manipuliert und eine Log-Datei vergiftet wird. Dies wird alles über einen Datei-Upload erreicht, der bösartiges JavaScript enthält, das ein Benutzer mit geringen Rechten einem Benutzer mit Administratorrechten unterjubeln kann, sodass dieser es ausführt. Die von mir beigefügten Proof-of-Concept-Dateien und das Video zeigen, wie ein Benutzer mit geringen Rechten diesen Angriff durchführt und eine Reverse Shell auf dem System erhält, das SuiteCRM hostet.
Dies wurde in Version 7.11.17 von SuiteCRM gepatcht.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Ich stimme dieser Bewertung nicht vollständig zu, da der Exploit Administratorzugriff erfordert, was PR:L zu PR:H ändern würde und den endgültigen Score von 8.8 auf 7.2 anpasst.
Ich würde ihn wie folgt bewerten: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Referenz: https://nvd.nist.gov/vuln/detail/CVE-2020-28328
SuiteCRM Version 7.11.15
Die gespeicherte Cross-Site Scripting existiert im Datei-Upload von 'Create Documents'. Ein Benutzer mit geringen Rechten kann eine Datei mit beliebigem Inhalt hochladen. Der Benutzer kann dann den Link untersuchen, der zum Herunterladen dieses Dokuments bereitgestellt wird, und den Speicherort der Datei im Dateisystem ermitteln, indem er den Parameter id lokalisiert. Dieser lange, zufällige Wert ist der Name der Datei im Verzeichnis /uploads/. Der Benutzer kann beliebiges JavaScript in dieser Datei platzieren und den Link dann an einen anderen Benutzer senden. Dies kann verwendet werden, um die Sitzung eines anderen Benutzers zu übernehmen und/oder Aktionen in dessen Namen durchzuführen, wie im PoC-Video gezeigt wird.
Nachdem ich herausgefunden hatte, dass ich durch Session-Hijacking über die Cross-Site Scripting zum Admin werden konnte, entdeckte ich, dass ich die Systemeigenschaften unter 'Admin → System Settings' kontrollieren konnte, nämlich die Log-Datei-Eigenschaft. Log-Datei-Erweiterungen waren ziemlich gut blockiert, aber ich konnte BurpSuite verwenden, um den Wert 'Log File Name' auf einen beliebigen Wert zu setzen, einschließlich .php-Erweiterungen. Ich tat dies, indem ich eine Anfrage ohne Änderungen abschickte und die POST-Anfrage abfing, die die Werte tatsächlich aktualisiert. Ich änderte den Dateinamen über den Parameter logger_file_name auf shell.php und setzte einfach das Feld 'Extension' auf leer. Das ergab eine PHP-Datei, auf die ich im Browser im Webroot zugreifen konnte, aber ich brauchte PHP-Code in der Datei, um sie auszuführen.
Als Nächstes untersuchte ich die Ausgabe in der Datei und stellte fest, dass ich die Eingabe in die Datei über Benutzereigenschaften steuern konnte, wenn ich einen Benutzer aktualisierte (z. B. den Vor- oder Nachnamen des Benutzers), sofern das Logging auf info gesetzt war (was meiner Meinung nach standardmäßig der Fall war...). Also fing ich eine Anfrage in Burp ab und fügte einigen PHP-Code <?php $id =`id`; echo $id; ?> in das Formularfeld last_name ein. Dies führte zur Ausgabe des Befehls id auf Linux im Kontext des Webserver-Benutzers www-data. Die einzigen Zeichen, von denen ich feststellen konnte, dass sie in der Log-Datei escaped werden, sind einfache Anführungszeichen, doppelte Anführungszeichen und Backslashes. Du kannst dies überprüfen, indem du die SQL-Log-Datei auf dem Backend mit tail anzeigst.
Ich konnte all dies als Admin-Benutzer ausführen, weil ich Session-Cookies erhalten konnte. Für eine funktionierende Kette musste ich dies jedoch über JavaScript im Kontext des Admin-Benutzers ausführen. Ich konnte dies mit einigen Fetch-Requests skripten, um jede dieser POST-Anfragen auszuführen. Die erste aktualisierte die Systemeigenschaften, die zweite aktualisierte das Feld 'Last Name' des Admin-Benutzers, und die letzte führte eine GET-Anfrage auf der neu erstellten Log-Datei mit bösartigem PHP-Code aus. Der bösartige PHP-Code würde eine Curl-Anfrage an meinen Rechner senden, eine Bash-Reverse-Shell herunterladen und die Ausgabe dieser Curl-Anfrage direkt an Bash weiterleiten, wodurch der Code ausgeführt wird. Ich lud dies dann mit derselben Methode hoch, die ich im XSS-Abschnitt besprochen habe, und rief den neuen Link als Admin-Benutzer erneut auf. Mit einem Webserver, der meine Bash-Datei hostete, und einem laufenden Netcat-Listener konnte ich eine Reverse Shell erhalten.
Stelle sicher, dass du AllowOveride All in Apache gesetzt hast. nginx hat diese Einstellung nicht und ich habe es nicht auf nginx getestet.
Aktualisiere auf die neueste Version von SuiteCRM oder zumindest auf Version 7.11.17.
Dies ist der spezifische Fix. Commit 1618af16eaa494c4551bac961e5ac8fc3d87ab8c
SuiteCRM war während des gesamten Meldeverfahrens sehr reaktionsschnell. Sie erkannten die RCE an, die gepatcht wurde. Die XSS war das Ergebnis einer Webserver-Konfiguration, daher erkannten sie sie nicht als Schwachstelle an. Sie wiesen jedoch darauf hin, dass sie die Dokumentation angesichts dessen aktualisieren würden.
06 AUG 2020 -> Beide Probleme an [email protected] gemeldet
07 AUG 2020 <- SuiteCRM bestätigt den Eingang des Berichts und leitet das Problem an das interne Sicherheitsteam weiter
21 AUG 2020 -> Ich kontaktierte [email protected] für eine Rückfrage
25 AUG 2020 <- SuiteCRM antwortet bezüglich Webserver-Konfiguration/XSS
26 AUG 2020 -> Ich antworte, dass der Vorschlag von AllowOveride All XSS abschwächt
16 SEP 2020 -> Ich kontaktierte [email protected] für eine Rückfrage
17 SEP 2020 <- SuiteCRM antwortet und bestätigt das Problem als Teilproblem
29 OKT 2020 Update veröffentlicht
03 NOV 2020 -> Ich kontaktiere [email protected], um sicherzustellen, dass ihrerseits nichts weiter benötigt wird, bevor ich den Writeup veröffentliche
05 NOV 2020 <- SuiteCRM antwortet
Jetzt haben wir einen Patch für dieses Problem veröffentlicht und er ist in der öffentlichen Domäne. Aus unserer Sicht spricht nichts dagegen, dass du einen Blogbeitrag über die Schwachstellen schreibst.
05 NOV 2020 -> CVE von mir beantragt
06 NOV 2020 <- CVE-2020-28328 vergeben
https://www.exploit-db.com/exploits/49001
Sie waren sehr angenehm in der Zusammenarbeit, und ich habe definitiv vor, weiterhin nach Schwachstellen in dieser Software zu suchen und sie zu melden!
