Shims unter Windows (5) - Die Ergebnisse der Sicherheitsforscher, Teil 2
Sie wissen bereits was Shims sind und wie die Shim-Infrastruktur aufgebaut ist (und wie es theoretisch mit ihrer Sicherheit aussieht). Danach haben Sie erfahren, dass Entwickler die Shims außer in einigen Ausnahmefällen gar nicht benötigen und dass sie zum Umgehen von Schutzfunktionen und zum Verstecken von Schadcode missbraucht werden können. Aber was kann schon nicht für böse Zwecke missbraucht werden? Alles, was sich zum Guten verwenden lässt, lässt sich immer auch irgendwie für etwas Schlechtes verwenden.
Was die Sicherheitsforscher dazu herausgefunden haben habe ich ihnen zum Teil bereits gezeigt, und das waren alles theoretische Gefahren. Leider gab es auch Angriffe über die Shim-Infrastruktur "in the Wild", und mit deren Analyse geht es weiter:
FixIt-Patches in Angreiferhand, und das "in the Wild"
Auf der BruCON 2015 haben William Ballenthin und Jonathan Tomczak die Analyse eines tatsächlichen Angriffs über die Shim-Infrastruktur beschrieben (PDF). Eine als sich selbst entpackendes RAR-Archiv auf den Rechner gelangte Schadsoftware hat neben vielen anderen Funktionen eine Funktion, die zwei (32-/64-Bit) hartkodierte Shim-Datenbanken auf dem System installiert und aktiviert. Darüber wird dann Schadcode eingeschleust.
Da das allein für einen Vortrag etwas wenig Material war haben die beiden Forscher auch weitere, bisher nur im Labor untersuchte Angriffe vorgestellt. Zum Beispiel ist es möglich, über Shims Argumente auszutauschen und einem Programm zum Beispiel einen anderen Pfad als den erwarteten unter zu schieben. Zum Beispiel, um vertrauliche Daten in ein Verzeichnis schreiben zu lassen, aus dem die Schadsoftware sie dann lesen kann. Ebenso ist es möglich, Code einzuschleusen und persistent zu halten. Was ja bereits bekannt war, hier aber erneut und ausführlicher beschrieben wurde.
Das ist natürlich unerfreulich, und damit die Zuhörer nicht zu sehr deprimiert wurden gab es auch eine gute Nachricht: William Ballenthin und Jonathan Tomczak haben auch beschrieben, wie die Shim-Datenbanken analysiert und den Angriffen auf die Spur gekommen werden kann.
FixIt-Patches in Angreiferhand, in der Theorie und in der Praxis
Auf der DEF CON 23 im August 2015 hat Sean Pierce Angriffe mit Hilfe der Shims vorgestellt (Video auf YouTube). Genauer: Die Möglichkeiten, die die Shims einem Angreifer bieten, der einen Rechner bereits erfolgreich kompromittiert hat. Der eingeschleuste Schadcode kann die Shims nämlich vielseitig nutzen, um weiteren Code auszuführen oder in andere Programme einzuschleusen, Informationen zu sammeln, sich zu verbergen, ... . Und das nicht nur in der Theorie, sondern auch in der Praxis: Sean Pierce listet 6 Schädlinge auf, die bereits Shims missbraucht haben. Um die UAC zu unterlaufen, laufende Programme zu manipulieren oder Persistenz zu erlangen.
Jede Menge Tools!
Das sind schlechte Nachrichten, also mussten auch wieder gute her: Auch Sean Pierce hat die Aufdeckung und Analyse der Angriffe beschrieben und zusätzlich dafür hilfreiche Tools veröffentlicht:
- Den Shim-Process-Scanner zur Suche nach Application Compatability Shims.
- Shim-Guard und Shim-Guard-Lite zur Ausgabe der aktuell installierten Shims samt ihren Ort und der Installationszeit. Shim-Guard registriert sich auch für Events zur Installation von neuen Shim-Datenbanken (SDB-Dateien).
- Shim-Process-Scanner-Lite, ein einfaches Batch-Skript zur Ausgabe der Prozesse, die über Shims geänderte DLLs nutzen.
- Den sdbScanner, ein Volatile-Plugin zur Suche nach durch Shims geänderten Prozessen.
- SdbIngestModule, ein Autopsy Ingest Module zur Erkennung von Shim Database (SDB) Dateien.
Um diese Tools und ihren Einsatz ging es auch in einem Vortrag, den Sean Pierce auf der Black Hat Europe 2015 im November gehalten hat: "Defending Against Malicious Application Compatibility Shims". Zumindest offiziell, denn tatsächlich war es mehr oder weniger der gleiche Vortrag wie auf der DEF CON. Diesmal gibt es aber ein Whitepaper zum Vortrag, in dem alles ausführlicher beschrieben ist.
Untersuchung des Windows Application Compatibility Cache
Fred House, Claudiu Teodorescu und Andrew Davis von FireEye haben in einem Blogpost die forensische Analyse des Windows Application Compatibility Cache eines kompromittieren Rechners beschrieben. Dabei kommt ein selbst geschriebenes Tool in Form eines PlugIns für das Volatility Framework zum Einsatz: ShimCacheMem. Das parst die Windows Application Compatibility Cache Datenbank aus dem Speicher und liefert damit die immer aktuellsten Daten. Andere Forensik-Tools analysieren nur die bei einem Restart in der Registry gespeicherte Version der Datenbank, wodurch entweder veraltete Daten analysiert oder ein Neustart des Rechners durchgeführt werden muss. Was bei einer forensischen Analyse beides ungünstig ist.
Was das nützlich oder konnte das weg?
In Windows 10 mit seinen erweiterten Schutzfunktionen werden Shims nicht mehr in der bisherigen Form unterstützt. Es wäre ja auch ziemlich unschön, wenn man einfach so mal eben über Shims in signierten Code Code-Teile austauschen könnte. Die Funktion zur Integration der Shims steht nicht mehr zur Verfügung. Microsoft wird sich wahrscheinlich eine nicht dokumentierte Möglichkeit zur eigenen Verwendung offen gehalten haben, aber für Dritte stehen die Shims nicht mehr zur Verfügung.
Generenn waren und sind Shims eine sehr nützliche Erfindung. Allein schon soweit es ihre Verwendung zur Beseitigung von Inkompatibilitäten betrifft. Noch besser ist natürlich ihr Einsatz zur Implementierung von Workarounds für aktuell ausgenutzte Schwachstellen. Übrigens nutzte auch das (inzwischen in Windows 10 integrierte und als eigenständiges Tool nicht mehr erhältliche) Enhanced Mitigation Experience Toolkit (EMET) teilweise Shims, um seine Schutzfunktionen zu realisieren.
Es gab also keinen Grund, Shims und das Application Compatibility Toolkit zu verteufeln und womöglich gar zu deaktivieren. Auch wenn die Angreifer seine Möglichkeiten missbrauchen. Denn die missbrauchen auch alle anderen Windows-APIs und -DLLs, wenn es ihren Zwecken dient. Und die will ja wohl auch niemand aus dem Verkehr ziehen, oder?
Die Entwicklung eigener Shims war von Microsoft nie vorgesehen, und das aus gutem Grund. Die Gefahr eines Missbrauchs wäre viel zu groß. Schon mit den vorhandenen Shims konnte ein Angreifer Schaden anrichten, vor allem mit dem gar nicht offiziell dokumentieren Shim für die In-Memory-Patches.
Darüber, wieso Microsoft die Shims nicht mehr offiziell unterstützt habe ich keine Informationen gefunden. Ich vermute, die Shims bzw. allgemein die Manipulation vorhandenen (i.A. signierten) Codes passen einfach nicht mehr so wie bisher ins (Sicherheits-)Konzept. Man könnte sie dafür sicher anpassen, z.B. durch eine Signatur der Shims samt der individuellen Anpassungen an den jeweiligen Anwendungsfall. Aber Microsoft scheint auch ohne Shims in der bisherigen Form klar zu kommen. Und dann ist die Einstellung der Unterstützung nur logisch - was nicht (mehr) da ist kann auch nicht für einen Angriff missbraucht werden.
Damit ist das Thema "Shims unter Windows" erledigt. Womit es in der nächsten Folge weiter geht habe ich noch nicht endgültig entschieden.
Trackbacks