Wie überprüft eine Firewall ob eine dll-injection stattgefunden hat bzw stattfindet?

Ein Bestandteil der Kontrolle wäre zb die API-Funktionen zu hooken.
Das lässt sich aber umgehen in dem man die Adressen der Funktionen direkt anspringt. (aber bei Inline-Hooking bringt das nichts oder?)
Dann ob die dll in der import table ist oder?

Welche Methoden fallen euch noch ein?

Bzw welche Arten von dll-injections gibt es denn?

Man hört immer es gäbe verschiedenste Arten.

mfg

Gegen eine Injektion aber, die nur einen Speicherblock allokiert und diesen aktiviert ist man relativ machtlos.

Es gibt Message Hooks und CreateRemoteThread sowie Brut-Force (direktes manipulierend des fremden Prozesscodes). Andere Methoden hat man nicht in einen fremden Prozess hineinzukommen.

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?

(Ich stelle die Frage, da die Firewall ja die Funktionen selbst verändern kann)

Da dürfte ne Firewall dann machtlos sein oder?

mfg

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.

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

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.

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.

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" ?

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.

was nützt einem eigentlich "nur" WriteProcessMemory() und VirtualAllocEx() bzw umgekehrt? eben ohne einen Thread ausführen zu können?

mfg

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).

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.