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.
Kategorien: Grundlagen
Trackbacks
Dipl.-Inform. Carsten Eilers am : Shims unter Windows (5) - Die Ergebnisse der Sicherheitsforscher, Teil 2
Vorschau anzeigen