DLL Injection verhindern
-
Böser Bube schrieb:
Aber nicht wenn ich den Thread, der das überwacht, auffresse
Der Witz ist ja grade, daß das alles ohne "Guard-Thread" funktioniert. :p
audacia|off schrieb:
Oben vorgeschlagenem Thread-Detektionsansatz könnte man dann begegnen, indem man vor der Erstellung eines Threads DisableThreadLibraryCalls() aufruft, dann mittels IPC die injizierende Anwendung dazu bringt, mit CreateRemoteThread() einen Thread zu erstellen, so daß es der attackierten Anwendung nicht hilft, CreateThread() zu hooken.
Mal abgesehen davon, wann und wo das aufgerufen werden soll, kennt eine Anwendung zu jeder Zeit die Anzahl ihrer Threads.
audacia|off schrieb:
Bleibt also das Hooken von WinAPI-Aufrufen als Anwendungsmöglichkeit.
Dann greift alles vorhin schon gesagte. Gehookte WinAPI-Aufrufe zu erkennen gehört bereits zum Standardrepertoire.
-
Gehookte WinAPI-Aufrufe zu erkennen gehört bereits zum Standardrepertoire.
Und wie geht das konkret?
-
Zum Beispiel durch Vergleichen der ersten "paar" Bytes der API-Funktion mit denen in der entsprechenden DLL auf der Festplatte.
-
Und wie soll dieser Vergleich stattfinden, wenn ich CreateFile und Co. alles gehooked habe und solche Versuche gleich abfange?
-
Sämtliche Funktionen gehookt? Ein etwas unrealistisches Szenario.
-> Brauche ich CreateFile und Co. um an eine Datei auf der Festplatte heranzukommen?
-
ja
-
LoadLibraryEx mit LOAD_LIBRARY_AS_DATAFILE ?
Konsequenterweise müßte der Hook dann sämtliche Sprungadressen entsprechend anpassen.
-
LoadLibrary ruft doch auch nur NtCreateFile auf
-
Bei mir aber NTDLL.LdrLoadDll.
Btw. sollen etwa (zur Sicherheit) sämtliche NTDLL-Funktionen gehookt werden?
Und soll auch noch so ein fetter Hook nicht auffallen?
-
wieso soll der auffallen? und wieso sämtliche funktionen?ich sagte doch CreateFile und ggf. 2,3 andere reichen vollkommen. und am besten macht man das mit nem kleinen treiber der einfach die einträge in der KeServiceDescriptorTable ändert. was is daran fett?
-
MisterX schrieb:
ich sagte doch CreateFile und ggf. 2,3 andere reichen vollkommen.
Vorausgesetzt der Programmierer hält sich auch dran.
MisterX schrieb:
und am besten macht man das mit nem kleinen treiber der einfach die einträge in der KeServiceDescriptorTable ändert.
Ist ja unter WIN64 auch kein Problem.
-
... selbst unter 32bit auf Vista oder Windows 7 wirst Du etwas Probleme haben, diesen Treiber in Betrieb zu nehmen!
-
desinjector schrieb:
MisterX schrieb:
ich sagte doch CreateFile und ggf. 2,3 andere reichen vollkommen.
Vorausgesetzt der Programmierer hält sich auch dran.
wie? alles geht über NtCreateFile, da kommt er nicht drum herum
-
Hatten wir vorhin schon :
Vorausgesetzt wird einfach, daß CreateFile die einzige Möglichkeit ist, um an eine Datei auf der Festplatte heranzukommen.
-
ist es auch weil alle anderen apis über diesen system call gehen. verstehst du dies denn nicht?
-
MisterX schrieb:
ist es auch
Greift ein Betriebssystem allen Ernstes bei jedem Dateizugriff immer auf die Festplatte zu?
-
nö wieso sollt es? dafür gibs doch den cache manager.
-
Folglich muß CreateFile oder NtCreateFile nicht der einzig mögliche Weg sein.
-
was hat das denn damit tun? ob ein ReadFile von der festplatte oder ausm cache befriedigt wird ist doch vollkommen egal
-
desinjector schrieb:
Nachtrag:
Eine gut programmierte Multithread-Anwendung bemerkt immer wenn ein selbsterzeugter Thread irgendwie "verschwindet".Er. NEIN!
Eine paranoid programmierte Anwendung bemerkt sowas.Da könntest du gleich behaupten "eine gut programmierte Anwendung bemerkt wenn man ihr ein File-Handle zumacht". Oder einfach irgendeins der milliarden Dinge tut die man gefälligst nicht zu tun hat, und auf die sich eine Anwendung ruhig verlassen darf (verlassen darauf dass sie nicht passieren).
Threads sterben nicht einfach so. Code zu bauen der überprüft ob Threads "einfach so" sterben ist total paranoid und plem. Und eine zusätzliche Fehlerquelle, da man ja bei der (oft vielleicht nicht trivialen) Überprüfung Fehler machen könnte...
Oh Mann die Kids...
