Erkennen einer dll-injection
-
Hallo,
danke für die Antwort.
Gegen eine Injektion aber, die nur einen Speicherblock allokiert und diesen aktiviert ist man relativ machtlos.
Wieso?
Stehen Desktop-Firewalls dem etwa auch machtlos gegenüber?
-
Ausserdem braucht man ja dazu auch die API-Funktionen und die werden gehookt.
Ist ein Programm dass ne dll injecten will gezwungen die dll des Systems zu verwenden oder kann es eine Kopie einer dll eines "frischen" Systems verwenden?(Ich stelle die Frage, da die Firewall ja die Funktionen selbst verändern kann)
Da dürfte ne Firewall dann machtlos sein oder?
mfg
-
muhi schrieb:
Gegen eine Injektion aber, die nur einen Speicherblock allokiert und diesen aktiviert ist man relativ machtlos. Wieso?
Wenn man z.B. mit VirtualAllocEx () von aussen Speicherplatz in einem Prozess allokiert, wird dieser Prozess vom Betriebssystem darüber nicht benachrichtigt.
Anders bei Threads :
Wenn mit CreateRemoteThread () ein Thread erzeugt wird, benachrichtigt das Betriebssystem sämtliche bereits vom Prozess geladenen DLL's.muhi schrieb:
Ausserdem braucht man ja dazu auch die API-Funktionen und die werden gehookt.
Ich glaube nicht, dass eine "Desktop-Firewall" sämtliche API-Funktionen hookt. Das wäre schlecht für die Performance.
-
danke für die Antwort,
Wenn mit CreateRemoteThread () ein Thread erzeugt wird, benachrichtigt das Betriebssystem sämtliche bereits vom Prozess geladenen DLL's.
Was meinst du damit? Dass es leicht is, so eine dll-injection zu entdecken?
Und wie ich oben gefragt habe:
Kann die Desktop-Firewall nicht einfach die Import-Table (der exe) mit den geladenen dll's vergleichen? Wenn ja könnte man das dann nicht untergraben in dem man die dll gleichbennent? oder werden da Adressen kontrolliert?
mfg
-
muhi schrieb:
Was meinst du damit?
Einen Remote-Thread kann man daran erkennen, dass z.B. in einer selbstgeschrieben DLL die "DLLMain" mit "fdwReason == DLL_THREAD_ATTACH" durchlaufen wird.
Der Programmierer der EXE weiss ja, ob es sich dann um einen eigenen Thread oder einen "fremden" Thread handelt.muhi schrieb:
Dass es leicht is, so eine dll-injection zu entdecken?
Unter Win2000 / WinXP eigentlich kein Problem :
-> LoadLibrary () hooken und immer kontrollieren, welche DLL geladen wird.
Genauso lassen sich Hooks entdecken :
-> CallNextHookEx () hooken.
Beide Funktionen werden schliesslich immer im Kontext des eigenen Porgramms aufgerufen.
muhi schrieb:
Kann die Desktop-Firewall nicht einfach die Import-Table (der exe) mit den geladenen dll's vergleichen?
Das wird nicht viel bringen. Viele Programme laden sich ihre "API" via LoadLibrary () und GetProcAddress () dynamisch zur Laufzeit erst.
Diese sind dann in keiner Table verzeichnet.
-
muhi schrieb:
Hallo,
danke für die Antwort.
Gegen eine Injektion aber, die nur einen Speicherblock allokiert und diesen aktiviert ist man relativ machtlos.
Wieso?
Stehen Desktop-Firewalls dem etwa auch machtlos gegenüber?
Desktop Firewalls machen das AFAIK über Hooks die nicht Teil der normalen API sind, nur zur Verfügung stehen wenn man Admin Rechte hat etc. - könnte sogar sein dass das Kernelmode Hooks sind.
Man könnte also theoretisch dasselbe machen wie eine gute Desktop Firewall macht, bloss ob der Aufwand dafürsteht ist die Frage.
-
Danke für die Antworten,
Mir fällt gerade eine andere Frage ein,
kann man ohne CreateRemoteThread eine dll in den neu allokierten Speicher laden bzw diese dann auch auszuführen?Kann man sich da nicht irgendwas mit WriteProcessMemory "basteln" ?
-
Ja, klar, bloss musst du dazu irgendwie das Programm hijacken.
Ich meine irgend ein Thread muss ja deinen Code ausführen, und wenn du nicht selbst einen mittels CreateRemoteThread erstellst... welcher sollte es dann sein?
-
Die "normale" API bietet einen mächtigen Debugger-Support.
Einige dieser Funktionen "unkonventionell" angewendet, ermöglichen alles.
-
Wie kann man über die offiziell dokumentierten API Funktionen ein WriteProcessMemory erkennen? (Im Zielprozess natürlich. p.S.: oder in einem "Drittprozess".)
-
Ich meinte damit, dass die dokumentierten Debugger-Funktionen ein "Thread-Hijacking" ermöglichen.
Damit lässt sich Code ausführen ohne Remote-Thread. Sehr üble Sache sowas.Einen Remote-Thread kann ein Programm aber erkennen (z.B. via DLL). Hooks auch.
Aber einem Read/WriteProcessMemory () oder einem VirtualAllocEx () gegenüber ist ein Programm im Prinzip völlig hilflos ausgeliefert.
Dagegen gibt es weder eine dokumentierte noch eine undokumentierte API.
-
Wenn aber ein Debugger aktiv ist, kann man das zumindest auch feststellen in senem Programm. Auch hier ist man nicht hilflos.
-
Hallo,
was nützt einem eigentlich "nur" WriteProcessMemory() und VirtualAllocEx() bzw umgekehrt? eben ohne einen Thread ausführen zu können?
mfg
-
Wennman bestehenden Code liest und manipuliert, der ausgeführt wird nützt es einem was...
-
Wennman bestehenden Code liest und manipuliert, der ausgeführt wird nützt es einem was...
-
Mit WriteProcessMemory () kannst Du z.B. Code und Daten in Prozessen manipulieren.
Mit VirtualAllocEx () kannst Du z.B. zur Laufzeit Daten in Prozessen "verstecken".
Ob das einen "Nutzen" hat, mag jeder für sich selbst entscheiden. "Unschön" ist sowas allemal.
-
hustbaer schrieb:
Ja, klar, bloss musst du dazu irgendwie das Programm hijacken.
Ich meine irgend ein Thread muss ja deinen Code ausführen, und wenn du nicht selbst einen mittels CreateRemoteThread erstellst... welcher sollte es dann sein?Da gibt es noch weitere (un)schöne Möglichkeiten, z.B. APC
Schau mal hier unter "New techniques for codeinjection", ist von mir:
http://rootkit.com/Prinzipiell würde ich mal sagen ist es kein Problem Code/Daten unbemerkt in einen fremden Prozess zu laden, sie auszuführen dagegen schon eher.
Martin Richter schrieb:
Wenn aber ein Debugger aktiv ist, kann man das zumindest auch feststellen in senem Programm. Auch hier ist man nicht hilflos.
Und wie? Mit IsDebuggerPresent? PEB->BeingDebugged auf FALSE setzen und schon ist man wieder fein raus (= der Fremdprozess verarscht).
-
CreateFile (), RegOpenKey (), OutputDebugString (je länger, desto besser).
Möglichkeiten gibt es genug. Aber die Präsenz eines Debuggers bedeutet noch längst nicht "Gefahr".
Ein Debugger sollte schliesslich auf jedem PC installiert sein.
-
Prinzipiell würde ich mal sagen ist es kein Problem Code/Daten unbemerkt in einen fremden Prozess zu laden, sie auszuführen dagegen schon eher.
Eben das meinte ich. Die einzige mir bekannte "saubere" Möglichkeit die Ausführung injizierten Codes hinzubekommen ist eben CreateRemoteThread.
Ansonsten muss man schon etwas brutaleres machen, z.B. den Anfang einer Funktion zu überschreiben deren Adresse man kennt (irgendwas aus KERNEL32 oder GDI oder so), und die das Programm wohl verwendet (GetMessage/HeapAlloc/... irgendeine der "beliebten" Funktionen halt).
Das meinte ich mit "hijacken".----
was nützt einem eigentlich "nur" WriteProcessMemory() und VirtualAllocEx() bzw umgekehrt? eben ohne einen Thread ausführen zu können?
Naja, nicht viel eben, ausser man ist etwas "brutal" (siehe oben).
----
Aber einem Read/WriteProcessMemory () oder einem VirtualAllocEx () gegenüber ist ein Programm im Prinzip völlig hilflos ausgeliefert.
Dagegen gibt es weder eine dokumentierte noch eine undokumentierte API.Sicher? Ich bin mir nämlich fast sicher dass man für diese Funktionen globale Hooks setzen kann - wahrscheinlich bloss ausm Kernelmode raus, was u.U. einen Hilfstreiber nötig macht, aber naja. Gehen sollte es. Muss nochmal sehen ob ich genauere Infos dazu finde.
