patois/winmagic_sdTechnischer Bericht über und PoC-Exploit für CVE-2020-11519 und CVE-2020-11520
Datum: Juni 2020
Autor: Dennis Elser (Code: github)
Gemäß seiner Webdarstellung ermöglicht Winmagic SecureDoc „Unternehmen, die Sicherheit ihrer IT-Umgebung effizient zu verwalten, unter Nutzung von Funktionen wie: Full Disk Encryption (FDE), Multi-Faktor-Authentifizierung, Removable Media Container Encryption (RMCE) und File and Folder Encryption (FFE). Diese Funktionen helfen Unternehmen, die Sicherheit zu erhöhen, Geschäftsrisiken zu mindern und behördliche sowie gesetzliche Anforderungen an die Festplattenverschlüsselung zu erfüllen."
Das Winmagic SecureDoc-Produkt, das in eigenständigen und Enterprise-Editionen erhältlich ist, ist in den Versionen 8.3 und 8.5 von zwei lokalen Privilegieneskalations-Schwachstellen betroffen (CVE-2020-11519 und CVE-2020-11520). Nachdem die Schwachstellen Ende März an Winmagic gemeldet worden waren, veröffentlichte der Anbieter Mitte Juni 2020 einen Patch (Version 8.5SR2). Es stellte sich jedoch heraus, dass dieser Patch die Schwachstellen nur unzureichend behob, was auch Version 8.5SR2 anfällig für die gemeldeten Fehler machte. Obwohl technische Details zu den Schwachstellen aus diesem Grund zurückgehalten wurden, sind die Fehler seitdem als öffentlich bekannt zu betrachten. Laut Anbieter befand sich ein weiterer Patch noch in der Pipeline, etwa 106 Tage nach der ersten Schwachstellenmeldung an Winmagic. Am 15. Juli, 111 Tage nach der ersten Schwachstellenmeldung an den Anbieter, veröffentlichte Winmagic SecureDoc v8.5 SR2 HF1 für Kunden, das Berichten zufolge CVE-2020-11519 und CVE-2020-11520 behebt. Versionen von SecureDoc älter als 8.3 wurden nicht getestet, können aber basierend auf dem Code der betroffenen Komponente ebenfalls als betroffen angenommen werden.
Eine erfolgreiche Ausnutzung einer der Schwachstellen führt bei lokal authentifizierten Angreifern zu einer Privilegienausweitung auf SYSTEM.
Beide Schwachstellen betreffen die Komponente „SDDisk2k.sys", einen Kernel-Treiber, der mit dem Winmagic SecureDoc-Produkt ausgeliefert wird. Die Sicherheitslücken wurden mittels manueller statischer Analyse mit Hilfe des Hex-Rays IDA Pro Disassemblers und Decompilers identifiziert. Rückblickend hätten die Schwachstellen mit deutlich geringerem Aufwand entdeckt werden können, wenn stattdessen dynamische Testansätze wie Fuzzing angewendet worden wären. Dies liegt daran, dass der Treiber von eingeschränkten Benutzermodus-Anwendungen angesprochen werden kann und standardmäßig davon ausgeht, dass deren Eingaben wohlgeformt sind.
Aufgrund der unsicheren Erstellung eines „SecureDocDevice"-Geräteobjekts durch den Treiber „SDDisk2k.sys" und des Fehlens von Code, der einen geeigneten Sicherheitsdeskriptor einrichten würde, erhalten selbst eingeschränkte Benutzerkonten die Möglichkeit, mit der API-Funktion CreateFile() ein Handle auf das Gerät zu erlangen. Indem der Treiber einer Benutzermodus-Anwendung ein Handle auf sein Geräteobjekt gewährt, öffnet er damit einen direkten Pfad zu seiner Angriffsfläche im Kernel-Bereich.``` c RtlInitUnicodeString(&DestinationString, L"\Device\SecureDocDevice"); RtlInitUnicodeString(&SymbolicLinkName, L"\DosDevices\SecureDocDevice"); if ( IoCreateDevice(v1, 0xDD8u, &DestinationString, 0x8D1Fu, 0, 0, &DeviceObject) >= 0 ) // <--- unsafe { memset(DeviceObject->DeviceExtension, 0, 0xDD8ui64); DeviceObject->Flags |= 4u; DeviceObject->AlignmentRequirement = 0; if ( IoCreateSymbolicLink(&SymbolicLinkName, &DestinationString) < 0 ) IoDeleteDevice(DeviceObject); IoObject = DeviceObject; }
Nach der Reverse-Engineering einer Reihe von IOCTL-Service-Handlern des Treibers "SDDisk2k.sys" wurde festgestellt, dass einer von ihnen kritische Funktionalität für den Benutzermodus bereitstellt, indem er Lese- und Schreibvorgänge auf den Rohdatenträgersektoren eines beliebigen Laufwerks ermöglicht – und das absichtlich. Darüber hinaus wurde bei der Interaktion mit ebendiesem Code festgestellt, dass der Treiber alle exklusiven Sperren ignoriert, die möglicherweise zuvor auf einem Laufwerk gesetzt wurden. Infolgedessen werden gleichzeitige Lese-/Schreibvorgänge ermöglicht, was Race Conditions begünstigt und Datenverlust riskiert.