App_Init dll's

mad_martin

Tut mir leid, dass ich nur was OT sagen kann: Keine Personal Firewalls nutzen!!!
http://www.ntsvcfg.de/linkblock.html

gruß
Martin

yogle

Die Firewalls überprüfen ganz einfach wer etwas in diesen Registry-Zweig schreiben will und melden es dem User.

muhi

Das ist alles?

Bist du dir da sicher bzw kennt jmd andere Verhalten von (auch kommerziellen) Desktop-Firewalls?

Berechtigte Frage

Die Firewalls überprüfen ganz einfach wer etwas in diesen Registry-Zweig schreiben will und melden es dem User.

Joa... klingt gut. Könnte ich mir auch gut vorstellen. :p

Soweit ich weiß überprüfen aber solche Programme die IAT der ausführbaren *.exe. D.h. wenn du versuchst deine DLL in einen Prozess zu injecten passiert erst einmal noch gar nichts. Es wird zwar die DllMain() der Dll aufgerufen, aber solange die keinen Einfluss auf den Programmfluss des Exe-Images im Speicher nimmt, genießt deine Abwehrsoftware noch ihre Freizeit ^^.

Sobald du aber Einträge in der IAT des laufenden Images überschreibst, also z.B. den Aufruf der Funktion kernel32!LoadLibrary auf eine Funktion in deiner DLL durch direktes Überschreiben der Funktionsaddresse umleitest, so kann es sein, dass deine FW den Aufruf genauer überprüft.
Sie checkt also erst einmal, wohin dieser Call/Jump im Prozessraum hin springt und innerhalb welchem Modul (.dll) sich diese Addresse befindet. Doch - wer hätte das gedacht - dort ist ja eine Dll mit dem Namen 'injection.dll'. Die 'injection.dll' ist aber nirgendswo in der Import-Section deiner Anwendung standardmäßig eingetragen, also wo kommt das Viech dann her ???
An dem Punkt sollte deine Sicherheitssoftware schon mal stutzig werden. Inwiefern sie dann erkennt, dass es sich um bösartigen Code handelt gleicht dann IMHO aber eher der Arbeitsweise eines Antiviren-Kits: Codevergleich mit dem Viren-/Trojanerarchiv und wenn eine Übereinstimmung gefunden wurde...TADA
...und bei welcher Personal Firewall dann immer noch nicht die Alarmglocken läuten, die kannste dann sowieso vergessen :p

PS: Ich nehme mal an, dass ihr mit "Personal Firewall" eher an AntiVir denkt, als an eine umgangssprachliche Firewall. Also meine Firewall prüft nur den Datenverkehr meines Rechners. Von DLL-Injection ganz zu schweigen...^^

Greetings, Xzi-bit

muhi

Hallo,

danke für die Antwort.

Hmm aber die dll's die über diesen Registry-Key geladen werden, werden per LoadLibrary() geladen...

und das ist ja eine legitime Methode, denn viele Programme laden ihre Funktion erst zur Laufzeit

und ich meine doch eine Desktop-Firewall bzw ein Modul ^^

mfg

und das ist ja eine legitime Methode, denn viele Programme laden ihre Funktion erst zur Laufzeit

Genau. Du bringst es auf den Punkt :
Deshalb ist es ja gerade so schwierig zu erkennen, bei welcher Dll es sich um eine Bösartige handelt. Das ist ja das Problem der Firewalls.
Woher sollen sie wissen, dass es sich um eine Injection handelt ?...
Eine Möglichkeit das ansatzweise herauszufinden ist die Methode, die ich dir vorhin vorgestellt habe. Das gilt aber auch nur für IAT-Hooks.
Damit kann die Firewall zumindest schon einmal die DLLs herausfiltern, die dynamisch nachgeladen wurden. Und du hast absolut Recht, wenn du sagst, dass man Dlls ja auch dynamisch nachladen kann. Die meisten werden aber nicht(!) dynamisch geladen.
Dadurch wird die zu überprüfenden DLL-Menge für die FW immer kleiner, da sie einschränken kann. (->Performance)

Dass das bei Programmen, die z.B. mit Visual Basic 6 erstellt wurden nicht viel bringen wird, ist mir schon klar. Denn VB-Programme laden die meisten DLLs nur dynamisch zur Laufzeit.
Auch wenn man als Programmierer seine DLLs dynamisch in sein Programm nachladen will, hat die Methode der Firewall natürlich auch nichts gebracht.
Aber dafür gibt es ja auch noch den Codevergleich. Unter dieser kleineren Menge an Dlls, die aber (nicht in allen Fällen) noch übrig bleiben, erkennt die FW dann noch die Windows Standard Dlls wie kernel32, user32, ...
Irgendwann bleibt dann nur noch ein kleiner Rest übrig.
Und dann erst lohnt sich der Codevergleich. Ohne Codevergleich geht nix.
Die Injection selbst kann die FW ja gar nicht nachvollziehen.
Und wenn jemand meint, er kann das nachvollziehen, wenn sich eine DLL irgendwo einklinkt, dann muss er mir erst mal beweisen, dass es sich bei dieser Library nicht um eine gutartige handelt. Deshalb lohnt sich meiner Meinung nach eine derartige Firewall auch nicht. Weil ein Argument dagegen ist,dass es bis jetzt keiner geschafft hat, der DLL anzusehen, ob sie von einem "schlimmen Hacker" oder einem gutartigen Programmer geschrieben wurde. Das ist wie bei Menschen. Es gibt keine Allround-Methode jemandem anzusehen, ob er Gutes oder Schlechtes im Sinn hat.
That's the problem, you know ?

Greetins, Xzi-bit

PS: Schreib ich hier so viel ? :p

muhi

Hallo,

hmm nein schreibst eh nicht zu viel .

Hmmm ich glaub auch, dass Desktop-Firewalls einfach keine Verbindungen aus dll's zulassem oder? ich weiss technisch gesehen machts (denk ich) ned soo viel Unterschied ob von einer dll aus oder aus dem (Ur-)Programm heraus connected wird aber überprüfen lässts sich eben schon (auch ob in der dll ein connect() Aufruf ist was sich aber auch umgehen lässt) btw wird einfach connect() gehookt.

Kennt ihr Firewalls die dll's nicht connecten lassen bzw andere sogenannte Komponentenprüfungen?

mfg

Keiner der mir antwortet?

*push*

Ich würde mich freuen wenn mir jmd Auskunft geben könnte

mfg