Skip to content

Shims unter Windows (4) - Die Ergebnisse der Sicherheitsforscher, Teil 1

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.

Leider lässt sich mit den Shims aber auch tatsächlich Schaden anrichten, was sowohl in der Theorie als auch der Praxis bewiesen wurde. Darum geht es in dieser Folge.

FixIt-Patches in Angreiferhand - Vom Shim zum Exploit

Auf der Black Hat Asia 2014 hat Jon Erickson einen Vortrag mit dem Titel "Persist It: Using and Abusing Microsoft's Fix It Patches" gehalten. Konkret geht es um das von Microsoft im Rahmen von FixIt-Patches oft genutzte "In Memory Fix It", dass bis zur Veröffentlichung seiner Untersuchungsergebnisse nicht öffentlich dokumentiert war.

Ein Angreifer gelangt über die Analyse der vom FixIt-Patch durchgeführten Änderungen im Speicher des geschützten Programms an Informationen über den Patch. Über Reverse Engineering des Patches gelangt er dann an Informationen über die damit behobene Schwachstelle. Für die er dann einen Exploit entwickeln kann.

Der Vorteil der Analyse der als Workaround veröffentlichten FixIt-Patches im Vergleich zur Analyse des am Patchday veröffentlichten offiziellen Patches zum Beheben der Schwachstelle ist seine geringere Größe. Als Beispiel nennt Jon Erickson den FixIt-Patch für die Schwachstelle CVE-2013-3893, der zwei Änderungen im Speicher des Prozesses durchführt. Ein BinDiff zwischen den mit den Security Bulletins MS13-097 und MS14-010 veröffentlichten Versionen der betroffenen Bibliothek mshtml.dll ergibt insgesamt 481 geänderte Funktionen, da die neue Version mehr als nur die eine Schwachstelle behebt und es zusätzlich weitere, nicht sicherheitsrelevante Änderungen gab.

Diesen Teil des Vortrags darf man aber nicht überbewerten. Microsoft hat FixIt-Patches eigentlich immer nur dann veröffentlicht, wenn eine Schwachstelle bereits "in the Wild" ausgenutzt wird. Wenn erst mal ein Exploit im Internet unterwegs ist, gelangt der auch meist früher als später in die für Drive-by-Infektionen genutzten Exploit-Kits. Selbst dann, wenn er anfangs nur im Rahmen vereinzelter, gezielter Angriffe genutzt wird.

Ob ein Cyberkrimineller mehr oder weniger die Schwachstelle ausnutzt ist dann eigentlich egal. Ebenso, ob der nun einen selbst entwickelten Exploit nutzt oder den bereits bekannten verwendet. Mit einer einzigen Ausnahme, und die hängt leider mit den FixIt-Patches zusammen: Manchmal wurde damit nur der aktuelle Angriff abgewehrt, ein aus dem FixIt-Patch entwickelter Exploit könnte dann u.U. im Gegensatz zum ursprünglichen Exploit trotz angewendeten FixIts funktionieren.

Das ist dann natürlich schlecht. Ist aber, soweit ich weiß, nie vorgekommen. Cyberkriminelle denken ja auch wirtschaftlich: Wozu einen neuen Exploit entwickeln, wenn bereits einer vorhanden ist und Microsoft die Schwachstelle wahrscheinlich sowieso am nächsten Patchday beheben wird?

FixIt-Patches in Angreiferhand - Statt FixIt-Patch persistenter Schadcode

Kritischer ist der zweite Punkt, den Jon Erickson in seinem Vortrag behandelt hat: Ein Angreifer kann die Möglichkeiten der In-Memory-Patches missbrauchen, um Schadcode in laufende Programme einzuschleusen und Persistent zu halten. Zum Beispiel, indem er seinen Schadcode in den stets laufenden Prozess explorer.exe einschleust.

Das ist natürlich schlecht, allerdings muss der Angreifer bereits Code auf dem betroffenen Rechner eingeschleust und Administrator-Rechte erlangt haben, bevor er das "In Memory Fix It" missbrauchen kann. Zum Kompromittieren des Rechners eignet es sich nicht. Und einem Angreifer mit Administrator-Rechten stehen noch andere Wege offen, seinen Schadcode dauerhaft im System zu verankern und laufen zu lassen. Trotzdem ist diese Missbrauchsmöglichkeit unschön.

Kommen wir nun zu einer guten Nachricht: Bisher war das alles Theorie, die Forscher haben nur Möglichkeiten für Angriffe vorgestellt.

Leider gehört zu jeder guten Nachricht meist auch eine schlechte. Und die lautet in diesem Fall: Es gab Angriffe über die Shim-Infrastruktur "in the Wild". Und darum geht es in der nächsten Folge.

Carsten Eilers

>

        </div>
                
        <footer class= Kategorien: Grundlagen

Trackbacks

Dipl.-Inform. Carsten Eilers am : Shims unter Windows (5) - Die Ergebnisse der Sicherheitsforscher, Teil 2

Vorschau anzeigen
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