Hallo Leute...

Vorneweg etwas zu meiner Person:
Ich bin neben meinem Beruf als Ausgleich leidenschaftlicher Hobbyprogger, programmiere aber nicht in Delphi (kann aber wohl Quelltexte in Delphi verstehen) - zur Zeit tüftele ich unter anderem an einem kleinen RootKit Scanner für Prozesse unrer 2000/XP/Vista herum.

Ich habe kaum einen Cent zur freien Verfügung in der Tasche und meine Rechner sind alle aus irgendeiner Mülltonne herausgekramt worden - deshalb bitte über manche Sachen und Fragen nicht wundern - ich weiß es dann einfach nicht besser, weil mir die passende Hardware und Software fehlt und ich deshalb in manchen Bereichen einfach ein Idiot bin.

Mein RootKit Scanner soll neben versteckten Prozessen auch Prozesse anzeigen, die sich als svchost.exe tarnen. Da unter anderem die API GetModuleFileNameEx die Daten des Prozesses aus dem Usermode ausliest, ist das Tarnen eine recht einfache und unkomplizierte Geschichte - bei Bedarf poste ich hier gerne als Beispiel eine nicht schädliche EXE mit sichtbarem Fenster, die dieses Vorgehen demonstriert.

Hier meine Fragen und Diskussionsanstöße:
- Gibt es Viren, die sich als svchost.exe tarnen, ohne die originale svchost.exe zu ersetzen - bzw. ist diese Technik des "Versteckens" überhaupt eine Gefahr? Ich habe bislang keine RootKits gefunden, die diese Technik verwenden.
- Ist jemand von euch, der sich mit solchen Verstecktechniken unter 2000/XP/Vista auskennt, bereit mir eine EXE mit Fenster zu bauen, die sich selbst möglichst effektiv als svchost.exe tarnt, um mir damit zu helfen, meine Scantechniken zu testen und zu verbessern?
a) Es dürfen keine schädlichen Aktionen durch die EXE ausgeführt werden (warum ist, denke ich, klar).
b) Die EXE muss ein sichtbares Fenster erzeugen und soll darüber ohne Probleme beendbar sein (damit sie nicht mit einem Virus verwechselt wird und demnächst unter §202c fällt).
c) Die EXE darf für die Tarnfunktionen keine DLLs oder Treiber verwenden (damit kein anderer aus diesem Testprogramm für Sicherheitszwecke oder aus Teilen davon einen Virus bastelt).
d) Nur EXE, keinen Code und keine Erklärungen! Ich will andere nicht auf irgendwelche bösen Ideen bringen.

Gruß

AHT

Compiliere ein leeres Projekt und bennene es in svchost um. Im normalen Taskmanager erscheint die dann auch unter diesem Namen. Du findest aber heraus das es keine orginale ist, wenn du den Dateipfad dir anguckst (oder habe ich das in dienen Anforderungen übersehen?)

Grüße
Heiko

Sagen wir's so: Such nach uallCollection, schau Dir an, was damit geht, spiele ein wenig und du wirst sehen, dass man sowas problemlos mit Delphi, ohne Treiber bauen kann. Da ich aber keinen auf eine Idee bringen will, schreib ich keine Details; allein der Hinweis auf die uallCollection sollte einem versierten Nutzer schon ausreichen.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Tja.... du müsstest aber auch irgendwie in den Prozessbaum der services.exe rein. Schließlich laufen alle 'normalen' svchost.exe unterhalb dieser (werden von services.exe gestartet), und als Test wäre das zumindest ein Baustein.
Ob man das allerdings simulieren kann, weiß ich nicht.

Ja Martok, geht ganz einfach:
Admin-Rechte holen (ist unter Windows nicht schwer), in den Services einen neuen Dummy anlegen, die eigene EXE eintragen, SCM beauftragen, den dienst zu starten, Dummy wieder killen Ansonsten Prozess-Injection in Services.exe (auch das geht relativ einfach) und von dort aus ein CreateProcess ausführen ^^ Alles nur ne Frage der Technik.

@AHT: Schau Dir mal den Rootkit Revealer von SysInternals an. Das Teil ist recht gut, auch wenn es inzwischen von M$ aufgekauft wurde ...

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Hallo Heiko...


Das ist witzlos. "Jeder" andere Taskmanager zeigt zum Prozessnamen auch den Pfad an.

Hallo BenBE...

Hooks meinte ich nicht. Das geht viel einfacher, auch ohne DLLs. Wer Hooks nutzt , bastelt sich eher ein RootKit - und die findet mein Scanner ebenfalls. Da der Prozesspfad auch ohne Zugriff auf die API ausgelesen werden kann, wäre ein Hook, denke ich, sowieso nicht die beste Lösung.

Hallo Martok...

Ich poste hier mal ein Beispiel:
www.angelfire.com/pl...spfad_vorgaukeln.zip
[url=www.bilder-hochladen...les/2tvs-p-gif.html][/url]
Bitte mal mit irgendetwas testen, das einen Pfad zur prozesserzeugenden EXE anzeigt (RootKit Unhooker zum Beispiel - will hoffen, das die EXE überall funzt). Mein Scanner soll solche Sachen finden (und findet sie bereits).
Ich möchte mich nur mal umhören, ob man das jemand noch besser machen kann als ich das hier getan habe und ich beim Scannen noch auf andere Sachen achten sollte.

AHT hat folgendes geschrieben:

Hallo BenBE... Hooks meinte ich nicht. Das geht viel einfacher, auch ohne DLLs. Wer Hooks nutzt , bastelt sich eher ein RootKit - und die findet mein Scanner ebenfalls. Da der Prozesspfad auch ohne Zugriff auf die API ausgelesen werden kann, wäre ein Hook, denke ich, sowieso nicht die beste Lösung.

Wo habe ich das Wort Hooks erwähnt??? Die uallCollection kann neben Hooks u.a. auch direkt Speicher verändern, was man hervorragend dazu nutzen kann, nicht nur die API, sondern auch Funktionen, die direkt versuchen solche Dinge auszulesen, abzuwähren.
Dein Demo Beispiel zeigt dies

AHT hat folgendes geschrieben:

Hallo Heiko... Das ist witzlos. "Jeder" andere Taskmanager zeigt zum Prozessnamen auch den Pfad an.

Beim ProcessExplorer steht zwar "Prozess-Pfad" C:\WinNT\System32\svchost.exe, ein kleiner Blick darunter auf die Kommandozeile zeigt aber ganz eindeutig, dass es sich dabei um "C:\DOKUME~1\BENBE\LOKALE~1\Temp\Rar$EX00.625\SVCHOST.EXE" handelt. Satz mit X also ^^

AHT hat folgendes geschrieben:

Hallo Martok... Ich poste hier mal ein Beispiel: www.angelfire.com/pl...spfad_vorgaukeln.zip Bitte mal mit irgendetwas testen, das einen Pfad zur prozesserzeugenden EXE anzeigt (RootKit Unhooker zum Beispiel - will hoffen, das die EXE überall funzt). Mein Scanner soll solche Sachen finden (und findet sie bereits). Ich möchte mich nur mal umhören, ob man das jemand noch besser machen kann als ich das hier getan habe und ich beim Scannen noch auf andere Sachen achten sollte.

Für diese EXE brauchte ich also nicht mal nen RootkitScanner, da er selber schon offensichtlich genug war. Aber wie in der PN geschrieben: Wer im Kernelmode angreift, wird von einem Usermode-Scanner nur bei groben Fehlern entlarvt werden.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

AHT hat folgendes geschrieben:

Ich poste hier mal ein Beispiel: [url]www.angelfire.com/pl...spfad_vorgaukeln.zip [/url] Bitte mal mit irgendetwas testen, das einen Pfad zur prozesserzeugenden EXE anzeigt (RootKit Unhooker zum Beispiel - will hoffen, das die EXE überall funzt). Mein Scanner soll solche Sachen finden (und findet sie bereits). Ich möchte mich nur mal umhören, ob man das jemand noch besser machen kann als ich das hier getan habe und ich beim Scannen noch auf andere Sachen achten sollte.

Das meinte ich zwar nun gar nicht, bringt aber eh nix. Benny hat mich da schon eher verstanden
Und zwar gehts mir im die Prozesshierarchie, wie sie z.b. der ProcessExplorer anzeigt. Und da steht immer noch dass die von Winzip.exe gestartet wurde.

Aber dein... Moment, da wirds Orange.
Ben, wie kannst du so schnell schreiben?

Hallo BenBE...

Richtig, die Commandozeile habe ich absichtlich offen gelassen. Die ist genausogut im Usermode zu änder wie der Rest. Mit den Usermode Scannern hast du meiner Meinung nach nur bedingt Recht - sag mir ein RootKit (oder schreibe selbst eins), das diese Fehler nicht macht und ich teste das mal zum Spaß aus. Es kann sehr gut sein, dass es solche RootKits gibt, ich habe bislang aber vergeblich danach gesucht.

Gruß

AHT

Wichtig ist doch weniger, welches Rootkit einen bestimmten Fehler nicht macht, sondern inwiefern es ohne allzu großen Aufwand möglich ist, in einem Rootkit eine Funktion zu integrieren. IMHO ist ein Monitoring Rootkit wesentlich gefährlicher, als ein reines "Veränderungsrootkit", was bewusst Daten manipuliert. Und von den Tarntechniken kannst Du dich gern mal an den CCC wenden: Die haben mal als Proof of Concept ein Rootkit geschrieben, was absolut keine Resourcen im System benötigt hat und trotzdem vollständigeNetzwerk-Funktionalität hatte.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Hallo BenBE...

Ich habe ja schon geschrieben, dass ich in mancher Beziehung ein Idiot bin und will jetzt hoffen, dass wir nicht aneinander vorbeireden: Ich nehme mal an, dass du mit "Monitoring Rootkit" ein über Kernel- oder Usermode Hooks funktionierendes RootKit meinst. Im Prinzip hast du da recht, denn wo schon was eingeschleust ist, kann man ohne weiteres die eine oder andere Funktion hinzufügen und die ebenfalls abfangen. Das könnte durchaus ein Grund dafür sein, dass solche Verstecktechniken in der Praxis wenig genutzt werden (Fu nehme ich da jetzt mal raus, das vollzieht ja ähnliches im Kernel - und da gibt es einige Viren, die darauf basieren).
Wenn dem so wäre, würde die Scantechnik, die ich mir im Augenblick ausgedacht habe, schon ausreichen, denn es würde sich wohl kaum jemand die Arbeit machen, so tief in undokumentierten Usermode Strukturen zu wühlen, wenn er ähnliches durch API Hooks erreichen kann, die er sowieso verwendet.

Könnte es da noch andere Schwachstellen bei dieser Technik, seine eigene EXE als anderen Prozess zu maskieren geben?

AHT hat folgendes geschrieben:

Wenn dem so wäre, würde die Scantechnik, die ich mir im Augenblick ausgedacht habe, schon ausreichen, denn es würde sich wohl kaum jemand die Arbeit machen, so tief in undokumentierten Usermode Strukturen zu wühlen, wenn er ähnliches durch API Hooks erreichen kann, die er sowieso verwendet.

Der Anreiz, doch in die undokumentierten Ecken zu gehen, wird aber größer, wenn durch einen RootKit Schutz der API-Hook Weg versperrt wird.

Gruß
alias5000

Wichtig ist im Endeffekt doch eigentlich nur, dass man die Daten, die man ändert, so gründlich geändert sind, dass man die alten Werte nirgens mehr finden kann.

Nehmen wir also an, ich schreib ein Programm malicious.exe, was nicht erkannt werden will. Ich als Autor des Programms weiß, dass es einen Scanner Verify.exe gibt, der versucht, meinen wahren Prozessnamen rauszubekommen. Ziel für mich als Autor ist es nun, in meinem Prozess jegliche Kennungen so zu verbiegen, dass nirgends von Verify.exe mehr meine wahre Identität nachggelesen oder überprüft werden kann. Dies benötigt keine Hooks, da alle benötigten Daten irgendwo im RAM oder ggf. auf Festplatte stehen.

Wenn Verify.exe nun hingegen prüft, ob der Dateiinhalt von Secure.exe, als die sich Malicious.exe ausgibt, mit dem Speicherabbild übereinstimmt, könnte ich sogar fatal deinen Scanner täuschen, indem ich lediglich mit einem Hook auf die Dateisystem-Funktionen, den Zugriff auf meine eigene Datei umbiege. Auch hier kann ich mir theoretisch einen API-Hook sparen, da ich die für den Dateizugriff benötigten Daten direkt auf dem Datenträger verbiegen könnte. Dein Scanner würde in diesem Fall einen False Positive in Secure.exe melden; mein Prozess wäre aber wiederum unangetastet, da deine Prüfung ja erfolgreich die korrekten Daten liefert.

IIn jedem Fall ließe sich aber eine Täuschung einfacher erzeugen, als diese vom Scanner zu erkennen wäre.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Also ein Programm, wlches einen falschen Dateipfad vortäuscht, stürzt bei mir ab:

Zitat:

--------------------------- Anwendungsfehler --------------------------- Exception EAccessViolation in Modul ntdll.dll bei 00013547. Zugriffsverletzung bei Adresse 7C923547 in Modul 'ntdll.dll'. Lesen von Adresse 02A2A5CA. --------------------------- OK ---------------------------

Windows XP SP2 alle Updates und Hotfixes.

Hallo BenBE...

Das ist richtig, nur braucht das OS bestimmte Daten, um überhaupt dem Programm z.B. Prozessorzeit und eine Priorität zuweisen zu können. Diese Daten dürfen also nicht verändert werden und müssen auslesbar bleiben. Ein weiteres Problem liegt bei den Resourcen, die du vorher schon angesprochen hast. Es gibt zig Möglichkeiten, diesen "Resourcen" nachzuspüren, die ja nicht nur im eigenen Prozess geöffnet sind, sondern teilweise auch im Subsystem referenziert sind.

Bislang habe ich noch kein RootKit gefunden, bei dem des zwingend nötig gewesen wäre, im Kernel zu kramen, um dessen Anwesenheit festzustellen. Das liegt daran, dass gar keine großen Fehler nötig sind, um die Anwesenheit eines RootKits zu verraten, sondern nur sehr kleine - teilweise unbekannte.

Hallo Luckie...

Ich schau mal, wo ich da Mist gemacht habe.

Gruß

AHT

Hallo Luckie...

Besten Dank!
Ich hatte bei der Umrechnung eines Counted Ansi-Strings in einen Counted-Unicode-String die Größenangabe des Ansi-Strings falsch gesetzt . Will hoffen, dass ich mir da nicht noch mehr Stolpersteine eingebaut habe .
www.angelfire.com/pl...spfad_vorgaukeln.zip

Gruß

AHT

Ich überlege gerade, ob das Tarnen des Prozesspfades auch eine Möglichkeit wäre, den Pfad eigener Sicherheitsprozesse, die auch zur Not in einem Adminaccount laufen sollen, zusätzlich zu tarnen...

Ich habe deshalb mal noch ein Update hochgeladen, das auch die Kommandozeile des Programmes ändert (Downloadadresse weiter oben).

Meine Fragen:
a) Wo stürzt das Programm noch ab?
b) Kennt jemand Programme, die den richtigen Pfad anzeigen (vielleicht auch selbstgeschrieben)?
c) Wo funktioniert das Programm?

Gruß und besten Dank für eure Antworten, die ihr bislang hier mir schon gegeben habt

AHT

Mal eine andere Frage: Warum sollte so ein Programm svchost.exe heißen?
Ein Rootkit kann sich doch ganz anders installieren.
Z.B. durch eine (harmlos wirkende) Anwendung, die nach dem Start bei Windows enorm viel Speicher anfordert, dass Windows Speicher auslagern muss. Dann wird in der Swap-Datei ein Treiber gesucht und mit eigenem Code "ergänzt". Nach Beenden der Anwendung wird der Speicher wieder freigegeben, Windows lädt alles zurück und schon ist der "neue" Code als Systembestandteil versteckt und kann tun was er will. Das hat übrigens eine Russin MicroSoft vorgeführt
Und da kann kein herkömmlicher Scanner was entdecken.
Aber das nur mal als Randbemerkung

Das ist richtig. Einige RootKits tarnen sich aber vor RootKit Scannern, indem sie sich während des Scans für kurze Zeit wieder sichbar machen. Erscheint dann im RootKit Scanner eine Datei xy mit dem Pfad xyz fällt die plötzliche Änderung sofort auf und das RootKit ist sehr schnell enttarnt. Ist der Pfad aber geändert und der Prozess erscheint als svchost.exe, erweckt das unter Umständen nicht so viel Verdacht und der Aufwand dafür ist sehr gering.
Es wäre also meiner Meinung nach recht sinnvoll etwas zu schreiben, dass direkt beim Scannen schon anzeigt, ob da wirklich svchost.exe läuft oder eben nicht.

Nur weil eventuel, irgendjemand Viren schreiben könnte, die dein Virenscanner nicht erkennt, schaffst du doch deinen Virenscanner auch nicht ab - oder???
Nur weil es möglich ist, ohne Probleme eine Firewall zu umgehen (wenn man genug Ahnung vom System hat) surfst du im Netz doch auch nicht ohne Firewall - oder???

Injizierten Code kann man unter Umständen auf andere Art und Weise scannen - der Scanner an dem ich arbeite soll das erst einmal nicht tun. Habe ein anderes Programm geschrieben, was manchen unsichtbaren Code schon recht gut findet.

Desweiteren wäre es vielleicht sehr interessant einem User zwar "erweiterte Rechte" auf einen Prozess zuzugestehen (PROCESS_VM_READ, PROCESS_QUERY_INFORMATION) ihm aber unter keinen Umständen zu erlauben, den Pfad des gestarteten Programms zu ermitteln .

Gruß

AHT