Kernel Filtertreiber umgehen? Ist das möglich?

[hitzi]

Hallo,

ich bin im Netz über dieses PDF gestolpert: http://www.csnc.ch/static/download/m...snc_german.pdf
[EDIT]In diesem PDF wird die Verwendung eine Kernelfiltertreibers beschrieben, welcher die Funktion NTCreateProcess "hooked" und vor der Ausführung eines Programmes überprüft, ob dieses Programm ausgeführt werden darf.[/EDIT]

Ist dieses Vorgehen sicher oder gibt es Techniken, die solche Filtertreiber aushebeln könnten?

Gruß

[TKC]

Es gibt Techniken die das Problemlos aushebeln können.

[hitzi]

Gibt es dazu mehr Details?

[OldGrumpy]

Ich empfehle ausgedehntes Schmökern auf www.osronline.com, die kostenlose Mitgliedschaft dort, sowie die auf dem dortigen Newsserver vorhandenen Newsgroups ausführlich zu lesen. Das Thema ist relativ komplex, für den Einstieg sei nur gesagt, dass man sich die SDT (eine Art Sprungtabelle in der grundlegende Systemfunktionsadressen (Einsprungpunkte in den Kernel) zu finden sind) anschauen kann, und wenn eine der Adressen dort ausserhalb des Speicherbereichs des Kernels liegt, hat man den Hook gefunden. Es ist dann auch kein grosses Problem, entweder eigene Massnahmen zu ergreifen (nen Kopierschutz würde dann z.B. ein manipuliertes System vermuten und den Start verweigern) oder einfach "drumrum" zu laufen. Dazu sucht man einfach im Kernel nach einem charakteristischen Muster an dem man die gehookte Funktion erkennt (man könnte je nach gehookter Funktion natürlich auch einfach in den Exports nachschauen, aber wenn ich einen Hook entdeckt habe, muss ich auch davon ausgehen dass dort manipuliert wurde), und ruft dann die gefundene Adresse statt der regulären auf.

Nachtrag: Hab jetzt doch endlich das PDF komplett zum Anzeigen, und sehe dass da direkt im Kernel gepatcht werden soll. Sowas ist wirklich nicht die feine englische Art :D Das Vorgehen ist dabei praktisch gleich, nur etwas aufwendiger, weil man nicht nur einfach Adressen interpretiert sondern Assemblerbefehle. Man holt sich die Einsprungadresse und liest von dort einfach ein paar Bytes (je nachdem wie paranoid man ist :mrgreen:) und schaut ob Sprungbefehle dabei sind, die Ziele ausserhalb des Kerneladressbereichs haben. Zum Beispiel in der Art "ist der erste Befehl ein Sprung zu einer Adresse ausserhalb des Kernel-Adressbereiches, dann BUMM!" :)

Es bleibt noch der obligatorische Hinweis, dass das Rumwerkeln an den Betriebssystem-Innereien besser entsprechend fähigen Leuten überlassen werden sollte... Zumindest aber sollte man sich über die möglichen Konsequenzen seines Tuns wie Datenverlust und zerschossene Filesysteme im Klaren sein :mrgreen:

[sakura]

Jetzt stellt sich aber die Frage, wie ich das Programm zum Analysieren der Sprungtabellen geladen bekomme, wenn ich durch oben genanntes System den Start dieser bereits unterbinde, weil ich nur ausgewählte Programme zulasse.

...:cat:...

[OldGrumpy]

Das käme auf die konkrete Implementation des Blockers an. Die Möglichkeiten dazu sind vielfältig, aber wollen wir jetzt Exploittechniken diskutieren? Im einfachsten Fall hat der Blocker eine Liste mit erlaubten Prozessen, dann würde sich z.B. eine Explorer.exe oder soetwas anbieten :)
Nachtrag: Wenn die cmd.exe nicht geblockt ist, dann reicht mir auch die Kommandozeile um den Filter zu lokalisieren und Windows für den nächsten Start vom Laden dieses Filters abzuhalten.

Hier wird sehr schnell klar, dass so ein Prozessfilter kein Allheilmittel sein kann, sondern nur ein weiterer, kleiner Baustein in einem umfassenden Sicherheitskonzept. Leider verstehen die meisten Leute das aber nicht ("Trojaner? Pah, ich hab doch die Windows Firewall!") :roll:

[sakura]

Zitat:

Zitat von OldGrumpy

aber wollen wir jetzt Exploittechniken diskutieren

War es nicht seine Frage, wie man obiges (theoretisches) System aushebeln kann?

Zitat:

Zitat von OldGrumpy

DasIm einfachsten Fall hat der Blocker eine Liste mit erlaubten Prozessen, dann würde sich z.B. eine Explorer.exe oder soetwas anbieten :)

Mit dem passenden MD5/SHA...? Etwas mehr Hürde als nur den Dateinamen darfst Du schon erwarten...

...:cat:...

[OldGrumpy]

Natürlich kann man das Szenario jetzt beliebig komplex gestalten. Ich habe aber eigentlich keine Lust, mit mir selber nun das "Was wäre wenn"-Spiel zu spielen, da soll der Fragesteller entweder etwas konkreter werden oder selber Hirnschmalz investieren :) So allgemein wie hitzi fragte, gibts nur eine Antwort, und die lautet "ja, kann man umgehen" :)

[hitzi]

Mir geht es um die Sicherheit eines solchen Systems. Ausgangslage soll ein fertig abgesichertes System sein, d.h. nur authorizierte Programme können gestartet werden. Welche Möglichkeiten bestehen evt. diesen Schutz zu umgehen. Kann man Programme evt. noch anders starten lassen? By the way ... NTCreateProcessEx ist genauso "gehookt".

Mich fasziniert die Möglichkeit eines solchen Systems zum Beispiel noch unbekannte Viren abzuwehren, da diese "eigentlich" gar nicht erst auf dem abgesicherten System ausgeführt werden können. Die Userschnittstelle eines solchen Systems und somit der "Angriff" über diese, soll mal außen vor gelassen werden. Mir geht es nur darum, ob man so einen schon aktiven! Kernelfiltertreiber (läßt also unbekannte Programme nicht mehr starten) umgehen kann.

[OldGrumpy]

Das kommt ganz darauf an, welche Angriffsvektoren offen sind (offen sein müssen). Und das wiederum hängt in großem Maße davon ob, obs ein Einzelrechner ist, Teil eines Netzwerkes oder gar Teil einer Domäne. In Falle eines Netzwerkes reicht ja ein entsprechender kompromittierter Rechner aus, um über RPC alle möglichen Änderungen vorzunehmen. Und RPC abschalten ist wohl keine Alternative, da Windows selber intensiven Gebrauch davon macht.
Die Gretchenfrage ist halt, welche Prozesse laufen dürfen müssen, und inwieweit diese Prozesse exploitfähig sind. Und bei Lücken wie "Anzeigen eines JPEG-Bildes reicht zur Infektion" würde ich doch prinzipiell eher von der Unsicherheit des Systems ausgehen :) Holzauge sei wachsam :mrgreen: