Dipl.-Inform. Carsten Eilers

Shims erlauben es, die API-Aufrufe eines Programms zu manipulieren. Microsoft nutzt das zum Beispiel, um als sog. "FixIt-Patches" bzw. "FixIt-Tools" Workarounds für bereits ausgenutzte Schwachstellen bereit zu stellen. Ein Angreifer kann die Shims aber auch nutzen, um seinem Schadcode neue Fähigkeiten zu verschaffen.

Shims sind 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 nutzt auch das Enhanced Mitigation Experience Toolkit (EMET) teilweise Shims, um seine Schutzfunktionen zu realisieren. Es gibt 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 wurde von Microsoft nicht vorgesehen, und das aus gutem Grund. Die Gefahr eines Missbrauchs wäre viel zu groß. Schon mit den vorhandenen Shim kann ein Angreifer Schaden anrichten, vor allem mit dem gar nicht offiziell dokumentieren Shim für die In-Memory-Patches. Da das aber nur von Microsoft genutzt wird gehe ich davon aus, dass Microsoft bereits an Schutzmaßnahmen für das Shim arbeitet, zum Beispiel durch die Einführung einer Code-Signatur oder ähnliches. Microsoft wird sicher nicht seelenruhig zu sehen, wie die Cyberkriminellen die Shims missbrauchen.

Und hier noch die Links und Literaturverweise aus dem Artikel:

• [1] Microsoft TechNet: "Application Compatibility Toolkit (ACT) Technical Reference"
• [2] Eric Lai; Computerworld: "Your company's apps incompatible with Windows 7? Shim them, says Microsoft"
• [3] Chris Jackson; The App Compat Guy: "Windows Vista Shim Internals Basics: How Shims Work to Address Compatibility Issues (and What are the Ramifications?)"
• [4] Chris Jackson; The App Compat Guy: "What does the MoveIniToRegistry Shim Do?"
• [5] Microsoft TechNet: "Understanding Shims"
• [6] Application Compatibility Database
• [7] Deepinder Singh; Ask the Performance Team Blog: "Demystifying Shims – or – Using the App Compat Toolkit to make your old stuff work with your new stuff"
• [8] Vijay Raj; msigeek: "Creating a Shim/Fix Using Compatibility Administrator"
• [9] Ollie; Research, Develop, Assess, Consult & Educate Blog: "Windows AppCompat Research Notes - Part 1"
• [10] Ollie; Research, Develop, Assess, Consult & Educate Blog: "Windows AppCompat Research Notes - Part 2"
• [11] Mark Baggett; Derbycon 2013: "Windows is 0wned by Default!"
• [12] Jon Erickson; Black Hat Asia 2014: "Persist It: Using and Abusing Microsoft's Fix It Patches"
• [13] William Ballenthin, Jonathan Tomczak; BruCON 2015: "The Real Shim Shady" (PDF)
• [14] Sean Pierce; DEF CON 23: "Abusing native Shims for Post Exploitation" (Material)
• [15] securesean auf GitHub
• [16] Shim Database Tools
• [17] Sean Pierce; Black Hat Europe 2015: "Defending Against Malicious Application Compatibility Shims"
• [18] Fred House, Claudiu Teodorescu, Andrew Davis; FireEye Threat Research Blog: "Shim Shady: Live Investigations of the Application Compatibility Cache"
• [19] fireeye/Volatility-Plugins/shimcachemem auf GitHub

Carsten Eilers