Exploit zur Berechtigungseskalation im Mechanismus einer Unteranwendungen von SteelSeries
Zusammenfassung
Der Sicherheitsforscher Tomer Peled von Akamai hat kürzlich zwei Schwachstellen in der SteelSeries-Anwendung entdeckt.
SteelSeries ist ein Hardwareunternehmen, das Computerperipherie herstellt und weltweit über 9 Millionen Kunden hat.
Den Sicherheitslücken wurden die CVE-Nummern CVE-2023-31461 und CVE-2023-31462 zugewiesen. SteelSeries hat diese Schwachstellen im Mai 2023 umgehend behoben.
Diese Sicherheitslücken ermöglichen es einem Angreifer, Code mit höheren Berechtigungen als ursprünglich erhalten und möglicherweise sogar mit ADMIN-Berechtigungen auszuführen. Um diese Schwachstellen auszunutzen, muss der Angreifer zwei lokale Pakete an einen überwachenden IPC-Server senden. Der Server führt die Payload des Angreifers dann mit erhöhten Berechtigungen aus.
Die Ursachen dieser Schwachstellen finden sich in der unsicheren Berechtigungsverarbeitung im IPC-Listener des Services und in einem mangelnden Schutz vor Pfadüberschreitung.
Die Akamai Security Intelligence Group (SIG) hat die Schwachstellen verantwortungsbewusst an die Support- und Engineering-Teams von SteelSeries weitergegeben und sie für die zugewiesenen CVEs an MITRE weitergeleitet.
Die SIG fand den anfälligen Service in mehreren von uns überwachten Rechenzentren und informierte Kunden über das Risiko und wie es gemindert werden kann.
- Wir bieten einen Machbarkeitsnachweis (Proof-of-Concept, PoC) des Angriffs sowie eine osquery zum Erkennen von Maschinen mit dem anfälligen Service.
Einführung
SteelSeries ist ein Hardwareunternehmen, das sich auf Computerperipherie wie Tastaturen, Mäuse, Kopfhörer usw. spezialisiert hat. Um diese Geräte individuell anzupassen, stellt SteelSeries seinen Nutzern eine Anwendung zur Verfügung – SteelSeries GG –, die von der Website heruntergeladen werden kann.
Diese Anwendung, die aus dem Hauptmodul von SteelSeries GG und mehreren Unteranwendungen besteht, ist ein Mechanismus, den SteelSeries zur Verbesserung des Nutzererlebnisses verwendet.
Bei unseren Nachforschungen haben wir zwei Möglichkeiten gefunden, unsere eigene Unteranwendung zu registrieren und anzugeben, welchen Code sie durchlaufen soll. Dies führt möglicherweise zu einer Codeausführung mit höheren Berechtigungen. In diesem Blogbeitrag stellen wir die technischen Details der Schwachstellen sowie einen Angriffs-PoC bereit.
Technische Details
SteelSeries GG wird standardmäßig auf mittlerer Integritätsebene und üblicherweise im Administratorkontext ausgeführt. Folglich kann sie unter bestimmten Umständen in einem Kontext mit hoher Integrität ausgeführt werden. Dieses Detail und die Tatsache, dass SteelSeries GG ein Listening-Prozess ist (Abbildung 1), machen SteelSeries GG zu einem guten Ziel für die Erforschung von Schwachstellen.
Abb. 1: Process Hacker und netstat zeigen die überwachende SteelSeries-GG-Anwendung
Der Mechanismus für die Unteranwendung und die prozessübergreifende Kommunikations-API
Der Unteranwendungsmechanismus dient der Verwaltung der optionalen SteelSeries-Funktionen und der Verbesserung des Nutzererlebnisses. Ein Beispiel für eine solche Unteranwendung ist Sonar, laut SteelSeries „eine fortschrittliche Suite von Audio-Software-Tools für Spiele, die jedem die Möglichkeit gibt, den in-Game-Sound, den Team-Chat und das Mikrofon separat anzupassen“. Unteranwendungen werden im Hintergrund ausgeführt. Sie kommunizieren mit dem Hauptmodul der Anwendung über eine prozessübergreifende Kommunikations-API (IPC).
Die IPC-API von SteelSeries GG stellt verschiedene Vorgänge zur Verfügung, die ein Nutzer anfragen kann, einschließlich Konfigurationsänderungen, administrative Aktionen, Änderungen an Nutzerprofilen usw. Interessanter ist allerdings Folgendes: Die API stellt eine Schnittstelle zur Verwaltung von Unteranwendungen bereit – von der Erstellung und dem Löschen bis hin zur Aktivierung und Deaktivierung.
Die API-Routing-Funktionalität (d. h. die Handhabung jeder API-Anforderung) wird mithilfe der Open-Source-Bibliothek gorilla/mux implementiert. Mit diesem Wissen können wir die Angriffsfläche leichter erkunden. Die Routing-Funktion selbst ist sehr groß, aber im Grunde ist sie nur eine Sammlung von if-Anweisungen für jede der verfügbaren API-Optionen (Abbildung 2).
Abb. 2: Die Implementierung von HTTP-Routing in SteelSeries GG
Diese API-Aufrufe stehen jedem zur Verfügung, der eine Verbindung mit dem Listening-Server ("SteelSeriesGG.exe") herstellt, und erfordern keine Authentifizierung.
Ich habe mich auf die Ereignis-Handler der Unteranwendung konzentriert, da dort das Potential für weitreichende Auswirkungen am größten ist. Nach der Neuordnung des disassemblierten Codes in IDA haben wir festgestellt, dass die Routing-Handler für Unteranwendungen den in Abbildung 3 dargestellten Prototyp aufweisen.
Abb. 3: Prototyp der Handler-Funktion im Code von gorilla/mux
Exploit des Mechanismus für Unteranwendungen
Einer der API-Aufrufe, die wir durchführen können, ist für das Erstellen einer neuen Unteranwendung. Dieser Prozess erfolgt durch Senden einer POST-Anfrage an die Route /subApps mit einer JSON-Payload, die mehrere Parameter enthält, von denen vier für uns von Interesse sind:"name", "executableName", "isEnabled" und "shouldAutoStart".
Mithilfe dieser Felder können wir praktisch eine neue Unteranwendung als nicht privilegierter Nutzer erstellen, sie auf eine ausführbare Datei an einem nicht privilegierten Speicherort verweisen und sie möglicherweise bei jedem Anwendungsstart planen.
SteelSeries GG erstellt den vollständigen Pfad zur ausführbaren Datei der Unteranwendung wie folgt:
<StellSeriesGG install location>\Apps\<name>\<executableName>.exe
Da die Felder „name“ und „executableName“ auf diese Weise verkettet sind, dachten wir, wir könnten einen Pfadüberschreitungs-Angriff versuchen. Wie es scheint, ist SteelSeries GG nicht resistent gegen Pfadüberschreitungen. Vor dem Pfad wurde „../../../../“ eingefügt, wie in Abbildung 4 gezeigt, und dies wurde akzeptiert.
Abb. 4: Beim Erstellen einer neuen Unteranwendung wird die Pfadüberschreitung akzeptiert
Wenn eine Unteranwendung erstellt wird, werden die Informationen darüber in der Datenbank von SteelSeries GG gespeichert. Gibt es vielleicht eine andere Möglichkeit, über diese Datenbank Unteranwendungen zu steuern? Tatsächlich befindet sich die Datenbank an einem unsicheren Speicherort. Das bedeutet, dass wir auch ohne Zugriff auf die Unteranwendung-API der Datenbank direkt eine Unteranwendung hinzufügen können. Angreifer müssen jedoch eine Schwachstelle finden, um diesen Designfehler zu missbrauchen, denn dieser kann allein nicht ausgenutzt werden und stellt somit kein unmittelbares Risiko dar.
Sie denken vielleicht, dass das Erstellen einer Unteranwendung an einem kontrollierten Speicherort bedeutet, dass wir eine Berechtigungseskalation erreicht haben (nachdem wir eine Binärdatei von diesem Pfad aus ausgeführt haben). Dabei haben wir jedoch eine weitere Einschränkung festgestellt: die Zertifikatsvalidierung. SteelSeries stellt zu Recht sicher, dass ausführbare Dateien für Unteranwendungen signiert und genehmigt werden. Um unsere eigene Payload auszuführen, müssen wir den Verifizierungsprozess umgehen.
Die Verifizierungsfunktion ruft die Funktion WinVerifyTrust auf sowie anschließend eine Kette von WinAPI-Funktionen, um bestimmte Felder im Zertifikat mit hartcodierten Zeichenfolgen in der Anwendung zu vergleichen.
Diese Validierung lässt sich auf zwei Arten umgehen, auch wenn diese etwas schwierig sind:
DLL-Hijacking
TOCTOU (Time-of-Check to Time-of-Use)
Der DLL-Hijacking-Vektor
Bei der DLL-Hijacking-Technik verlassen wir uns darauf, dass SteelSeries mehreren vorhandenen Binärdateien vertraut. Eine davon ist SteelSeriesEngine.exe, die die Bibliothek lädt SSEDEVICE.dll. Wir kompilieren unsere eigene Bibliothek mit demselben Namen, sodass unsere Bibliothek anstelle der ursprünglichen SSEDEVICE DLL geladen wird. Die von unserer eigenen DLL exportierten Funktionen werden die eigentlichen DLL-Funktionen aufrufen.
Die beim Laden unserer DLL aufgerufene Funktion implementiert jedoch unsere schädliche Logik (Abbildung 5). itm4n erläutert die Technik der Proxy-DLL ausführlicher in diesem Blogbeitrag.
Abb. 5: DLL-Hijacking von SSEDEVICE
Die Animation in Abbildung 6 zeigt den Prozess des Sendens des anfänglichen Pakets an die Ausführung der Payload des Angreifers (in unserem Fall das Öffnen einer cmd-Instanz) mit erhöhten Berechtigungen.
Abb. 6: Der Prozess vom Senden des anfänglichen Paket bis zur Ausführung der Payload des Angreifers mit erhöhten Berechtigungen
Der TOCTOU-Vektor
In diesem Fall nutzen wir die Zeitlücke zwischen der Zertifikatüberprüfung und der tatsächlichen Ausführung der Binärdatei (Abbildung 7). Mit anderen Worten, wir versuchen, eine Race-Bedingung zu überwinden, indem wir die legitime Datei schnell mit einer schädlichen Datei über das Tool BaitAndSwitch von James Forshaw austauschen. Wir möchten sie sofort nach der Überprüfung des Zertifikats ersetzen. Auf diese Weise wird eine legitime Datei überprüft, aber dann wird eine schädliche, nicht verifizierte Datei ausgeführt.
Es ist nicht garantiert, dass die Race-Bedingungen funktionieren. Um diesen Exploit zu stabilisieren, können wir versuchen, unser Zeitfenster zu erweitern.
Abb. 7: TOCTOU-Vektordarstellung
Denken Sie daran, dass die Zertifikatverifizierung auf zwei Tests beruht: Einem Aufruf an WinVerifyTrust und einer Überprüfung zwischen mehreren Feldern im Zertifikat und einer hartcodierten Zeichenfolge in der Anwendung. Wir können ein Zertifikat mit diesen exakten Werten in unsere ausführbare Datei implantieren. Diese Verbesserung ermöglicht dem Angreifer, die Race-Bedingung zu überwinden, selbst wenn der Wechsel zwischen den beiden Tests auftritt, da unsere schädliche Binärdatei alle Kriterien für den zweiten Test erfüllt.
Die Animation in Abbildung 8 zeigt den Prozess vom Warten auf den Start des Überprüfungsvorgangs mit BaitAndSwitch bis zur Ausführung der Binärdatei des Angreifers (in diesem Fall cmd.exe).
Abb. 8: Der Prozess vom Warten auf den Start des Überprüfungsprozesses mit BaitAndSwitch bis zur Ausführung der Binärdatei des Angreifers
Erkennung und Beseitigung
Um die Erkennung anfälliger Assets im Netzwerk zu erleichtern, stellen wir eine osquery bereit, um Instanzen von SteelSeries GG und der aktuell installierten Version zu finden:
SELECT name,version from programs where name LIKE '%SteelSeries%' |
Kunden von Akamai Guardicore Segmentation können diese Abfrage mit Insight verwenden, um Anwendungen zu finden, die gepatcht werden müssen.
SteelSeries aktualisiert die Anwendung mit jedem neuen Patch. Dies kann die Wahrscheinlichkeit verringern, dass Ihre Geräte von diesen Sicherheitsanfälligkeiten betroffen sind. Wir empfehlen Abwehrspezialisten, ihre SteelSeries-Version auf eine höhere Version als 39 zu aktualisieren.
Fazit
SteelSeries ist ein großes Unternehmen mit einem riesigen Nutzerstamm von mehr als 9 Millionen Kunden weltweit. Jede Schwachstelle in seinen Produkten hat von Natur aus große Auswirkungen. Die Folgen werden noch verschärft, wenn wir die einfache Ausnutzung dieser Schwachstellen und ihre Auswirkungen auf den Computer betrachten, d. h. wenn wir potentiell Binärdateien im ADMIN-Kontext ausführen können.
Die Auswirkungen sind nicht auf die Maschine beschränkt, die dem Nutzer gehört; auch Unternehmen können betroffen sein. Der Laptop eines Mitarbeiters, der mit einem anfälligen Gerät verbunden ist oder ein anfälliges Programm ausführt, kann später mit dem Unternehmensnetzwerk verbunden werden und so „Risiken“ in das Unternehmen „importieren“. Aus diesem Grund ist es für Unternehmen wichtig, eine BYOD-Richtlinie (Bring Your Own Device) zu implementieren und Mitarbeiter über die Gefahren der Verwendung solcher Geräte aufzuklären.
Wir haben die Netzwerke von Akamai-Kunden nach Instanzen der anfälligen Anwendung durchsucht und die entsprechenden Kunden informiert.
Im Rahmen unserer kontinuierlichen Bemühungen, unsere Kunden und die Community zu schützen, werden wir weiterhin Patches und andere Systeme auf Schwachstellen analysieren. Um über die neuesten Sicherheitsstudien von Akamai auf dem Laufenden zu bleiben, folgen Sie uns auf Twitter.
Chronik der Veröffentlichung
27.04.2023 – CVE-Anfrage an MITRE weitergeleitet
01.05.2023 – E-Mail an den Kundendienst von SteelSeries gesendet
02.05.2023 – CVEs von MITRE zugewiesen
03.05.2023–04.06.2023 – Gespräche mit dem Engineering-Team von SteelSeries
31.05.2023 – Fehlerbehebungen veröffentlicht
17.07.2023 – Blog-Entwurf von SteelSeries geprüft
18.07.2023 – Blogbeitrag veröffentlicht
