Übersicht
Das SonicWall Capture Labs Bedrohungsforschungsteam wurde auf die Bedrohung CVE-2024-36412 aufmerksam, bewertete deren Auswirkungen und entwickelte Maßnahmen zur Behebung dieser Schwachstelle.
CVE-2024-36412 ist eine kritische Sicherheitslücke, die SuiteCRM, eine von SalesAgility entwickelte Open-Source Customer Relationship Management (CRM)-Software, betrifft. Dieser Fehler, der in Versionen vor 7.14.4 und 8.6.1 auftritt, beinhaltet eine unsachgemäße Neutralisierung von Benutzereingaben in SQL-Befehlen, wodurch Angreifer SQL-Injection-Angriffe durchführen können. Während die Schwachstelle theoretisch unbefugte Manipulationen der Datenbank, wie z. B. den Zugriff, die Änderung oder das Löschen sensibler Daten, ermöglichen könnte, zeigte das getestete praktische Ausnutzungsszenario vor allem eine JavaScript-XSS-Blind-SQL-Injection. In unseren Tests wurden Abfragen wie SELECT LOAD_FILE('/etc/passwd') im Speicher ausgeführt, gaben aber keine Ausgabe zurück, da in responseEntryPoint.php kein Code zur Anzeige der Daten vorhanden war. Die Schwachstelle, die mit CWE-89 in Verbindung gebracht wird, hat eine maximale CVSS-Basisbewertung von 10,0 und eine EPSS-Wahrscheinlichkeit von 4,62%, womit sie im 93. Perzentil der wahrscheinlich auszunutzenden Schwachstellen liegt. Die Versionen 7.14.4 und 8.6.1 enthalten Patches zur Behebung dieser Sicherheitslücke. Den Benutzern wird dringend empfohlen, ihre Systeme zu aktualisieren, um sich gegen eine mögliche Ausnutzung zu schützen. Weitere Informationen finden Sie in dem von SalesAgility auf GitHub veröffentlichten Advisory.
Technischer Überblick
Der bereitgestellte Code (Abbildung 1) und die zugehörigen Funktionen - cleanan_incoming_data(), securexss() und securexsskey() - sollen das Risiko von Cross-Site-Scripting (XSS) und anderen auf Injektion basierenden Angriffen verringern, indem sie sowohl die Schlüssel als auch die Werte der eingehenden Anfragedaten bereinigen. clean_incoming_data() wendet XSS-Filter auf Benutzereingaben in den folgenden superglobalen Variablen $_REQUEST, $_POST und $_GET an und verwendet dann clean_string() und verwandte Logik, um Parameter wie login_theme oder module auf der Grundlage vordefinierter Zeichensätze zu bereinigen. Gleichzeitig konzentriert sich securexss() auf die Umwandlung potenziell gefährlicher Zeichenketten durch Ersetzen von HTML-Sonderzeichen und javascript:-Substrings, um das Risiko der Ausführung bösartiger Skripte innerhalb der Anwendung zu verringern. Darüber hinaus stellt securexsskey() sicher, dass Parameternamen selbst keine schädlichen Zeichen enthalten, wodurch Angreifer daran gehindert werden, ausgeklügelte XSS-Vektoren zu starten, die sich auf verdorbene Schlüssel stützen.
Abbildung 1: clean_incoming_data()
Trotz dieser Maßnahmen zielen die Bereinigungsroutinen (Abbildung 2) in erster Linie auf bösartigen HTML-Code, JavaScript und andere clientseitige Injektionstechniken ab. Sie gehen die Risiken der SQL-Injektion nicht gründlich an. Wie im javascript:"-Nutzlastszenario (Abbildung 3) zu sehen ist, unterbricht der Code zwar erfolgreich die javascript: Teilzeichenkette und kodiert potenziell gefährliche Zeichen, versäumt es aber, angehängte SQL-Befehle, die nach dem bereinigten Teil versteckt sind, zu erkennen oder zu entfernen. Bei einem blinden SQL-Injektionsangriff nutzt ein Angreifer diese verbleibenden SQL-Anweisungen, um die zugrunde liegenden Datenbankabfragen der Anwendung zu manipulieren, indem er häufig Sleep-Funktionen oder andere Datenbankoperationen einführt, die messbare Zeitunterschiede erzeugen.
Abbildung 2: securexss() mit/preg_replace()
Der vorhandene Code bietet einen wesentlichen Schutz gegen herkömmliche XSS-Angriffe, insbesondere durch die Integration mit der AntiXSS-Engine, die gefährliche Attribute wie style und onerror entfernt, aber Nutzlasten, die JavaScript-ähnliche Strings mit versteckten SQL-Injektionsvektoren mischen, nicht vollständig neutralisiert. Obwohl die von der AntiXSS-Bibliothek angebotene xss_clean()-Methode HTML- und Skripteingaben effektiv bereinigt, ist sie nicht dafür ausgelegt, SQL-Befehle zu erkennen oder zu entfernen, die tief in vom Benutzer bereitgestellte Strings eingebettet sind. Um solche blinden SQL-Injection-Bedrohungen umfassend zu entschärfen, sollten Entwickler ihre auf XSS ausgerichteten Maßnahmen durch eine robuste serverseitige Parametrisierung und eine sichere Datenbankbehandlung ergänzen. Dieser mehrgleisige Ansatz, der die Stärken der AntiXSS-Filter mit einer ordnungsgemäßen SQL-Sanitization kombiniert, gewährleistet eine weitaus robustere Verteidigung gegen ein breites Spektrum von Injektionsangriffen.
Auslösung der Schwachstelle
Die Schwachstelle erfordert, dass der Angreifer einen Eingabeparameter erstellt, der zunächst wie eine JavaScript-basierte XSS-Nutzlast aussieht, tatsächlich aber eingebetteten SQL-Injection-Code enthält. Diese Kombination erfordert die folgenden Schritte.
- Fügen Sie eine javascript: Teilzeichenkette gefolgt von verschlüsselten oder verdeckten SQL-Anweisungen in den Abfrageparameter ein.
- Verwenden Sie den Delegate-Parameter oder einen anderen akzeptierten Parameter, um die Nutzlast zu übertragen, z. B. javascript:" +AND+(SELECT...).
- Greifen Sie auf den anfälligen Endpunkt (z. B. index.php) mit sorgfältig konstruierten GET-Parametern zu, die entschärftes JavaScript mit angehängtem SQL-Injection-Code kombinieren.
- Beobachten Sie zeitliche Verzögerungen oder Änderungen im Verhalten der Anwendung, die auf eine erfolgreiche Ausführung der injizierten SQL-Befehle hindeuten.
Ausbeutung
In der Demonstration in Abbildung 3 nutzen wir die Burp Suite, um die identifizierte Schwachstelle auszunutzen, indem wir eine speziell gestaltete GET-Anfrage an den Zielendpunkt senden. Durch das Einfügen einer bösartigen Nutzlast in einen Parameter, der zunächst mit einer JavaScript-Funktionalität verbunden zu sein scheint, können wir die auf XSS ausgerichteten Sanitization-Layer umgehen. Diese Nutzlast enthält versteckte SQL-Befehle, die von der Eingabefilterung des Servers nicht entfernt werden können, was zu einem blinden SQL-Injection-Szenario führt. Mit den Funktionen der Burp Suite können wir die Anfrage in Echtzeit abfangen und ändern, die Antworten des Servers analysieren und zeitliche Unterschiede beobachten, die die erfolgreiche Ausführung der injizierten Abfragen bestätigen.
Abbildung 3: JavaScript XSS Blind SQL Injection Demonstration
SonicWall-Schutzmaßnahmen
Um sicherzustellen, dass SonicWall-Kunden auf eine mögliche Ausnutzung dieser Sicherheitslücke vorbereitet sind, wurden die folgenden Signaturen veröffentlicht:
- IPS: 20542 SuiteCRM JavaScript XSS Blind SQL Injection
Empfehlungen zur Behebung von Mängeln
Um die von dieser Schwachstelle ausgehenden Risiken zu verringern oder zu beseitigen, sollten Sie die folgenden Maßnahmen ergreifen:
- Entfernen oder ersetzen Sie alle fest kodierten Anmeldedaten in der Codebasis.
- Verwenden Sie aktuelle Signaturen des Intrusion Prevention Service (IPS), um den Netzwerkverkehr effektiv zu filtern.
- Schränken Sie die Benutzerrechte nach dem Prinzip der geringsten Berechtigung ein, um unnötige Zugriffe auf höherer Ebene zu verhindern.
- Regelmäßige Updates und Patches für Systeme, einschließlich der Anwendung und ihrer Abhängigkeiten, um bekannte Schwachstellen zu beheben und zu verhindern.
