Zum Inhalt springen

Rootkits

10 Antworten3'870 AufrufeGestartet von Punktmann ·

PunktmannThemenstart372 Beiträge
#1
Ich habe mich in der letzten zeit um die problematik der rootkits bissl niteressiert und dabei nicht gerade erfreuerliches festgestellt. Erstens scheinen von weitem nicht alle gängigen antivirenprogramme in der lage zu sein, sie zuverlässig zu erkennen und 2. wenn schon ein gefunden wird, könne man es meist nicht mehr heilen, eine komplette system-neuinstallation sei notwendig, um es loszuwerden (und um einen kurze zeit danach uu. erneut zu schnappen :x :evil: :| ).

Was ist so euer standpunkt zu dieser sache? Wie schützt ihr euch davor? Habt ihr schon mal eins gehabt?

nanocool324 Beiträge
#2
Was ist so euer standpunkt zu dieser sache?
Ja, Rootkits gibt es und wenn man sich einen einfängt, hat man Pech oder einfach nicht gut genug aufgepasst.

Wie schützt ihr euch davor?
Ich nutze ein Linux-System um im Netz unterwegs zu sein. Es ist zwar auch auf Linux möglich Rootkits zu schreiben, aber ungleich schwerer eines drauf zu kriegen.

Mit Windows war ich jeweils mit Sandboxie unterwegs.

Habt ihr schon mal eins gehabt?
Nicht das ich wüsste - ausser Starforce, aber das habe ich ja bewusst drauf geladen gehabt.

salami102 Beiträge
#3
Wie schützt ihr euch davor?
In meinem Fall: Gesunder Menschenverstand /emoticons/default_smile.png Bin seit Jahren mit aktuellen Windosen ohne irgendwelche Virenscanner unterwegs und wenn man die grundlegensten Sicherheitstipps befolgt sehe ich überhaupt keine Gefahr. Kommen doch mal Zweifel an einer ausführbaren Datei auf verwende ich http://virusscan.jotti.org/en der einem einen schönen Überblick über die verschiedenen Scanner liefert. Nach ein paar Scans kommt man dann schnell mal zum Schluss dass kein einzelner davon auch nur annähernd ausreichend Schutz bieten würde, hingegen unglaublich viele Falscherkennungen produziert...

Punktmann372 Beiträge
#4
Ich nutze ein Linux-System um im Netz unterwegs zu sein. Es ist zwar auch auf Linux möglich Rootkits zu schreiben, aber ungleich schwerer eines drauf zu kriegen.
Ich denke mir, ob du dich hiermit nicht in falscher sicherheit wähnst. Meinen recherchen nach seien die ersten rootkits überhaupt gerade auf Unix-basierten systemen entstanden. So schwierig dürfte es also nicht sein. :? :| :?:

Kommen doch mal Zweifel an einer ausführbaren Datei auf...
Wie kommt man zu einem solchen verdacht? Ich habe das gefühl, eine solche datei nur so zu entdecken gleicht dem finden einer nadel im heuhaufen. Einzig, wo bei mir verdacht aufkommen kann, wenn sich der rechner allgemein irgendwie seltsam benimmt, und das würde heissen, alles zu scannen. Nota bene die Rootkits verstecken sich nicht wie die üblichen viren in irgendwelchen zusatzdateien, die evtl. durch den namen vortäuschen, zum system zu gehören, nur befinden sie sich vlt. am "falschen" ort oder ist der name doch nicht der systemdatei ganz gleich usw., sondern direkt in den systemdateien selbst, die sie einem HI-virus ähnlich von innen abgeändert haben, um durch gewöhnliche mittel nicht enttarnnt werden zu können - das ist gerade das fieseste daran.
dreael322 Beiträge
#5
Was ist so euer standpunkt zu dieser sache?
Also wenn Du mich schon als IT Security-Experte fragst: Zuerst einmal hoffe ich, dass Du den Unterschied zwischen Rootkit und "normaler" Malware kennst: Letztere wird beispielsweise als Prozess in "tasklist" sichtbar, beim Rootkit jedoch nicht, d.h. ein Rootkit manipuliert das Betriebssystem-API derart, dass Ergebnisse nicht mehr der Wahrheit entsprechen => Du kannst einer Abfrage nicht mehr vertrauen! Herkömmliche Virenscanner sind auf diese API jedoch angewiesen -> Gaukelt das Rootkit etwas "Sauberes" vor, hat der Virenscanner nicht mehr viel Chance!

Gegenmassnahme, um mit einem Rootkit fertig zu werden: Malware-Scanning von einem separat gebooteten Betriebssystem (z.B. Windows PE, Live-CD einer Linux-Distribution, Systemplatte als D:\ in einen anderen Rechner mit garantiert sauberem Betriebssystem eingebaut usw., damit die Malware keine Möglichkeit mehr hat, ihr manipuliertes API in den Arbeitsspeicher zu installieren, wie dies beim regulären Windows-Booten ab verseuchter Festplatte immer passiert.

Punktmann372 Beiträge
#6
Zuerst einmal hoffe ich, dass Du den Unterschied zwischen Rootkit und "normaler" Malware kennst
Allerdnigs. Darum habe ich das thema aufgeworfen, weil ich sie als eine ziemlich grosse gefahr sehe, besonders wenn heute unter allmöglichen vorwänden von allen seiten immer mehr versucht wird, die privatsphäre eines normalen individuums zu unterwandern. Und schon die enttarnung alleine ist schwierig, man lebt immer mehr in angst vor den allgegenwärtigen augen des "grossen bruders" /emoticons/default_sad.png

Gegenmassnahme, um mit einem Rootkit fertig zu werden: Malware-Scanning von einem separat gebooteten Betriebssystem (z.B. Windows PE, Live-CD einer Linux-Distribution, Systemplatte als D:\ in einen anderen Rechner mit garantiert sauberem Betriebssystem eingebaut usw., damit die Malware keine Möglichkeit mehr hat, ihr manipuliertes API in den Arbeitsspeicher zu installieren, wie dies beim regulären Windows-Booten ab verseuchter Festplatte immer passiert.
Ist ziemlich einleuchtend. Ist es dann aber sicher, dass der schädling so entdeckt wird? Da denke ich mir, dass man hier nur nach einer liste bekannter rootkits vorgehen kann, andersfalls müsste man alle anfälligen dateien zeitraubend bit nach bit testen, ob sie noch intakt sind. Die heuristik kann hier wahrscheinlich kaum etwas verrichten - oder?
dreael322 Beiträge
#7
andersfalls müsste man alle anfälligen dateien zeitraubend bit nach bit testen, ob sie noch intakt sind. Die heuristik kann hier wahrscheinlich kaum etwas verrichten - oder?
In diese Richtung kann es längerfristig durchaus gehen. Auch hier wieder mein "Senf" als IT Security-Experte dazu: Die aktuelle Betriebssystemarchitekturen haben bereits länger zurückliegende Wurzeln, welche mittlerweilen die notwendigen Sicherheitsanforderungen nicht mehr erfüllen können!

Dazu ein Vergleich: Jemand von Euch benötigt einem Handwerker, um meinetwegen ein kurzes Stück Rohr mit Wasserhahn ziehen zu lassen. Frage: Würdet Ihr diesem Handwerker einfach so Euren kompletten Schlüsselbund in die Hand drücken mit dem Kommentar "Sie können sich nun bei mir frei bewegen, um überall hinzukommen."? Vermutlich sicher nicht, denn der Handwerker soll sich schliesslich nicht noch gleichzeitig mit dem Doppelbartschlüssel an Eurem Tresor hinter dem Gemälde selber bedienen können...

Aber exakt das Beschriebene macht jeder auf seinem PC, wenn er sich als lokaler Administrator einloggt bzw. in Vista der UAC-Abfrage zustimmt und SETUP.EXE startet: Dem Code in SETUP.EXE gebt Ihr voll und ganz das beschriebene "Narrenrecht in Eurer Wohnung"! Die fertig installierte Software bekommt gleich nochmals zu ihrem "Narrenrecht": Es darf einfach _alle_ APIs und DLL-Bibliotheken ohne Eure explizite Zustimmung benützen. Klassisches, mir bekanntes Beispiel: TeamViewer lässt sich Ad Hoc auch als eingeschränkter Benutzer starten, d.h. auch als Benutzer mit minimalen Rechten hat man im Grunde genommen immer noch zu viele Freiheiten.

Und übrigens hat jeder gewusst: Software muss ihre Uninstall-Routine selber mitbringen (=Prinzip wie beim kooperativen Multitasking, d.h. als Bösewicht-Prozess kann ich den CPU-Slice beliebig lange für mich behalten, so dass niemand anders mehr Rechenzeit bekommt), d.h. es gibt kein "Wächter", der in einer nicht manipulierbaren Datenbank über sämtliche Resourcen Buch führt, so dass eine unterwünschte Software bei Bedarf auch "mit Gewalt" sauber entfernt werden kann (=Prinzip von präemptiven Multitasking, d.h. Prozess wird mit "höherer Gewalt" unterbrochen, so dass garantiert jeder Prozess Rechenleistung bekommt).

Somit hat also ein Software-Entwickler auch jetzt immer noch das "Narrenrecht" und kann auf der EDV, so seine Programme zum Einsatz kommt, praktisch alles machen, was Gott verboten hat...

Aufgrund der zuvor geschilderten Situation sehe ich langfristig nur eine Besserung, wenn das bei den Java-Applets begonnene Sandbox-Prinzip noch viel konsequenter fortgesetzt wird: Einer beliebigen Software will ich eigentlich explizit mitteilen können, welche APIs sie überhaupt benutzen können soll. Generell sollte auch ein fremdcode-freier Installationsprozess Einzug halten: Software nur noch in .ZIP-archivartigen Format mit Beschreibungsheader u.a. gehören in diesen Header auch die gewünschten Privilegien, welche beim Installationsprozess als Liste erscheinen sollen, so dass man sie als Systemverantwortlicher explizit genehmigen kann.

Könnte man in der Zentralinstaller-Routine von meinen Next Generation-OS sogar sehr schön grafisch lösen, in dem man jedes Privileg durch einen Farbbalken kennzeichnet, wie hoch das Potenzial für bösartige Handlungen ist, so dass jemand vollkommen zurecht etwas mit "Also nein, meinen Hosensack will ich jetzt dem Tool XY doch nicht gleich so offen zugänglich machen!" ablehnt. PC-Zeitschriften könnten dann in ihren Tests ein neues Kritierium "benötigte Privilegien" einführen - je weniger API-Rechte eine Software braucht, desto besser ist sie programmiert!

Farbbalken-Beispiele:

- Vollbildmodus: hellgrün-gelb (Warum ist über den ganzen Bildschirm verfügen gefährlich? Weil ein Bösewicht "Diese Arbeitsstation ist gesperrt ..." als Phishing perfekt fälschen kann, was er bereits nicht kann, wenn er nicht den Anwendungen-Standardfensterrahmen zum Verschwinden bringen kann!)

- direkte Dateisystembenutzung: orange (Warum? Selbst, wenn ich "chroot"-mässig nur "Eigene Dateien" vom aktuelle Profil erlaube, kann ein bösartiger Code immer noch alles lesen oder gar verschlüsselt zurückschreiben im Sinne von Ransomware)

- direktes Sektorlesen: rot (Dies wäre jetzt ein typisches Privileg für ein CHKDSK-ähnliches Tool. Maximalstufe, weil ich damit mittels eigenem Dateisysteminterpreter sämtliche ACLs umgehen kann. Für derartige APIs benutzen zu dürfen muss der Programmierer gewissermassen bereits einen einwandfreien Bankkassier-Leumund besitzen, damit man das Software-Produkt bedenkenlos einsetzen kann)

- Netzwerk-API müsste man zusätzlich differenzieren. So braucht ein HTTP-Daemon sicherlich Port 80-Listen-Recht, aber sicher kein connect()-Recht, d.h. ich möchte diesem Prozess nur ein Telefon geben, auf dem man keine Nummer wählen kann, sondern nur klingelnde Anrufe annehmen kann. Umgekehrt einem Client möchte ich Ziel-Port und evtl. IP-Range mitgeben können -> typische Personal Firewall-"Arbeit" schon beim Aufsetzen des Programms erledigt.

Vielleicht sollten wir alle einmal ein Projekt "Ideal OS" ins Leben rufen. 🙂

Punktmann372 Beiträge
#8
Ausführlich beschrieben, allerdings werde ich vermutlich noch ein paar mal darauf zurückkommen müssen, bis ich dem allen auch wirklich voll folgen kann, im moment verstehe ich das ganze nur teilweise. Vorerst eine konkrete naive :wink: frage: Was ist mit den farbbalken genau gemeint? Wo sind die, resp. sollen sie sein?

Sonst habe ich jetzt eine aktuelle frage:

Ich gehe regelmässig in ein forum, wo seit einiger zeit ein typ verkehrt, der ein bischen seltsames verhalten an den tag legt, hat anscheinend überdurchschittliche informatik-kenntnisse und befasst sich ua. mit hacking. Nun nicht nur er, sondern auch mein rechner verhält sich seit nicht allzulanger zeit bissl seltsam. Nicht nur mir scheint es so, dass irgendien prozess darin am laufen ist, der im TaskManager nicht angezeigt wird. Also was mich jetzt drückt:

Inwiefern ist denkbar, dass so jemand anhand meiner IP, mit der ich eingeloggt bin, bei mir einen keylogger-rootkit oder soawas installieren könnte, womit er dann zugriff auf meinen rechner hätte? Meine befürchtung: Für einen, der sich auskennt, ein kinderspiel. Ist es so oder braucht es schon "etwas mehr" dazu?

Seltsam ist auch, dass in der vergangenen woche bei meiner festplatte mitten im bootvorgang, als ich schon das logo-bild am monitor hatte, plötzlich DOS den zugriff aufs C: nicht mehr bekam. In der folge habe ich mir auf eine frische festplatte Windows komplett neu installiert. Booten kann ich jetzt zwar, allerdings der Windows-sound bekommt dabei gleich wie in den letzten wochen bis monaten zuvor einen hustenanfall und weiter ScanDisk C: ist idr. nicht in der lage bis zum ende zu laufen, startet seine tests mitten in der ordnerprüfung immer neu, bis er mir nach 10 erfolglosen versuchen den abbruch vorschlägt (unter Windows, derjenige von DOS läuft perfekt, allerdings bei mir BIOS-bedingt nur bis 8 GB) - das ist im mmoment das auffälligste (ausnahmen, wo ers im 2. bis 4. versuch mit mühe schafft, gibt es ab und zu).

Als rootkits-schutz habe ich den Avast installiert, allerdings erst seit etwa 4. wochen. Das husten des Windows-sounds begann einige zeit früher (damals hatte ich nur die grad auslaufende, noch nicht rootkit-fähige version von AVG, die erst noch über keinen direkten download-scan verfügte), das ScanDisk-problem allerdings erst nachher, wobei das abstellen der laufenden Avast-prüfungen daran nichts ändert. Und bei der jetzt neuen Windows-installation (etwa 1 woche alt) habe ich die grundversion von Avast noch vorm 1. besuch im Internet off-line installiert, die 1. aktualisierung allerding online).

Nexus2k826 Beiträge
#9
Inwiefern ist denkbar, dass so jemand anhand meiner IP, mit der ich eingeloggt bin, bei mir einen keylogger-rootkit oder soawas installieren könnte, womit er dann zugriff auf meinen rechner hätte? Meine befürchtung: Für einen, der sich auskennt, ein kinderspiel. Ist es so oder braucht es schon "etwas mehr" dazu?
Solange du ein Router vor deinem Computer hast, der NAT macht ist das unproblematisch. Wenn du jedoch nur ein Modem hast und somit direkt die öffentliche IP an deinem PC "anliegt", dann ist dies gerade bei veralteten Betriebsystemen wirklich möglich und unterumständen ein Kinderspiel. Andernfalls könnte ich mir auch automatisch runtergeladene Software durch irgendwelche Sicherheitslücken im Internet Explorer 5 oder 6 vorstellen. Oder wenn du Links oder Ahnänge in Mails geöffnet hast, dann ist die Wahrscheinlichkeit gross.

Per IP gehackt worden zu sein: Wahrscheinlichkeit eher gering.

Seltsam ist auch, dass in der vergangenen woche bei meiner festplatte mitten im bootvorgang, als ich schon das logo-bild am monitor hatte, plötzlich DOS den zugriff aufs C: nicht mehr bekam. In der folge habe ich mir auf eine frische festplatte Windows komplett neu installiert. Booten kann ich jetzt zwar, allerdings der Windows-sound bekommt dabei gleich wie in den letzten wochen bis monaten zuvor einen hustenanfall und weiter ScanDisk C: (unter Windows, der von DOS läuft, allerdings bei mir BIOS-bedingt nur bis 8 GB) ist idr. nicht in der lage bis zum ende zu laufen, startet seine tests mitten in der ordnerprüfung immer neu, bis er mir nach 10 erfolglosen versuchen den abbruch vorschlägt - das ist im mmoment das auffälligste (ausnahmen, wo ers im 2. bis 4. versuch mit mühe schafft, gibt es ab und zu).
Das tönt wiederum stark danach, als ob demnächst die Festplatte abraucht. Wäre ein typisches Symptom. Plötzliche Leseschwirigkeiten, Fehler bei ScanDisk etc.

Wahrschienlichkeit: hoch

Punktmann372 Beiträge
#10
Bei mir spricht gegen ein baldiges abrauchen der festplatte, dass ich ihre oberfläche gerade heute ohne einen einzigen fehler getestet habe, genauso wie diejenige, die mir das booten verweigert. Und es wäre seltsam, dass sie beide als vorzeichen des abrauchens zuvor probleme in denselben dateien, bzw. prozessen machen würden, während alles andere einwandfrei läuft; der jeweilige schadenort müsste sich ja am mehr oder weniger zufälligen ort befinden, nota bene dass es von bauart her 2 recht verschiedene teile sind. Die jetzt lauffähige habe ich erst zuvor noch frisch aufbereitet - also daten gelöscht, sektore getestet (analog dem test beim formatieren) und dann noch schnell-formatiert und das alles ist glatt ohne ein einziges zucken abgalaufen.

Sonst hier ist das bootlog, derjenigen, die nicht starten will:

[0013CBCE] Loading Device = C:\WINDOWS\SETVER.EXE

[0013CBCF] LoadSuccess = C:\WINDOWS\SETVER.EXE

[0013CBCF] Loading Device = C:\WINDOWS\COMMAND\DISPLAY.SYS

[0013CBD1] LoadSuccess = C:\WINDOWS\COMMAND\DISPLAY.SYS

[0013CBD1] Loading Device = C:\WINDOWS\HIMEM.SYS

[0013CBD2] LoadSuccess = C:\WINDOWS\HIMEM.SYS

[0013CBD2] Loading Device = C:\WINDOWS\DBLBUFF.SYS

[0013CBD3] LoadSuccess = C:\WINDOWS\DBLBUFF.SYS

[0013CBD3] Loading Device = C:\WINDOWS\IFSHLP.SYS

[0013CBD3] LoadSuccess = C:\WINDOWS\IFSHLP.SYS

[0013CBD8] C:\WINDOWS\COMMAND\MODE.COM[0013CBD8] starting

[0013CBDC] C:\WINDOWS\COMMAND\MODE.COM[0013CBDC] starting

[0013CBDF] C:\WINDOWS\COMMAND\KEYB.COM(Logo disabled)

[0013CBDF] starting

hier bleibt sie mit der DOS-meldung "Allgemeiner Fehler beim Lesen von Laufwerk C: / Abbrechen, Wiederholen, Ignorieren, Fehler?" stecken. Welcher schritt bringt das logo-bild auf die anzeige sehe ich daraus allerdings nicht, einzig es das hier zuletzt - bei KEYB.COM - wieder ausgeblendet wird (seltsamerweise kommt es im anderen, kompletten bootlog nur an diesem ort, obwohl das logo mehrmas ein und aus geht, bevor die tapete vom desktop kommt).

Es ist mir auch unklar, warum bei einigen schritten das wort "starting" steht, 1x sogar als ein selbstendiger schritt und erst noch ausgerechnet dort, wos abbricht. Weiter auch warum der MODE.COM 2x gleich nacheinender kommt und was genau die zahlen in eckigen klammern bedeuten - irgendwelche adressen und auch klar, dass sie tendenziell steigend sind, weniger jedoch, warum sie oft mehrfach gleich bleiben).

Hier noch zum vergleich das bootlog der gesunden HD, mit der ich jetzt fahre:

[000083A4] Loading Device = C:\WINDOWS\COMMAND\DISPLAY.SYS

[000083A4] LoadSuccess = C:\WINDOWS\COMMAND\DISPLAY.SYS

[000083A4] Loading Device = C:\WINDOWS\HIMEM.SYS

[000083A4] LoadSuccess = C:\WINDOWS\HIMEM.SYS

[000083A4] Loading Device = C:\WINDOWS\DBLBUFF.SYS

[000083A4] LoadSuccess = C:\WINDOWS\DBLBUFF.SYS

[000083A4] Loading Device = C:\WINDOWS\IFSHLP.SYS

[000083A4] LoadSuccess = C:\WINDOWS\IFSHLP.SYS

[000083B7] C:\WINDOWS\COMMAND\MODE.COM[000083B6] starting

[000083B8] C:\WINDOWS\COMMAND\MODE.COM[000083B6] starting

[000083B8] C:\WINDOWS\COMMAND\KEYB.COM(Logo disabled)

[000083B6] starting

[000083DB] Loading Vxd = VMM

[000083ED] LoadSuccess = VMM

[000083ED] Loading Vxd = C:\WINDOWS\SMARTDRV.EXE

[000083ED] LoadSuccess = C:\WINDOWS\SMARTDRV.EXE

[000083ED] Loading Vxd = C:\DBLSPACE.BIN

[000083ED] LoadSuccess = C:\DBLSPACE.BIN

[000083ED] Loading Vxd = vnetsup.vxd

[000083ED] LoadSuccess = vnetsup.vxd

[000083ED] Loading Vxd = ndis.vxd

[000083ED] LoadSuccess = ndis.vxd

[000083ED] Loading Vxd = ndis2sup.vxd

[000083ED] LoadFailed = ndis2sup.vxd

[000083EE] Loading Vxd = JAVASUP.VXD

[000083ED] LoadSuccess = JAVASUP.VXD

[000083ED] Loading Vxd = CONFIGMG

[000083ED] LoadSuccess = CONFIGMG

[000083ED] Loading Vxd = NTKERN

[000083EE] LoadSuccess = NTKERN

Es geht noch weiter, aber es ist zu lang und der rest ist für das problem, warum die andere nicht startet, irelevant.

--------------------------------

In der heutigen Situation von ständig neuartigen Bedrohungen der Datensicherheit ist es für den Anwender und Betreiber aufwändig und ermüdend, sich neben der produktiven Tätigkeit über angemessene Massnahmen zu informieren und diese auch umzusetzten.
Genau das ist der punkt, selbst wenn man die mittel hat, damit jemand vertrauensvollen extern zu betrauen! Und dazu gesellt sich jetzt noch das auge des »Grossen Bruders«, dass sich je länger desto mehr legale grundlagen für seine willkürliche schnüffelei verschafft :roll: :twisted:
Nexus2k826 Beiträge
#11
Wenn ich es also richtig verstehe, dann hast du die 2te Platte komplett neuinstalliert und trotzdem im Bootlog eine leer "starting" Zeile drin ? Dann wird das wohl normal sein.

Andernfalls würde sich evtl. mal ein Blick in die autoexec.bat lohnen da der Teil vor den VXD afaik von der Autoexec.bat kommt.

Andere gängige Methoden wären auch mal ein HiJackthis scan zu machen.

Seite 1 von 1 · 11 Beiträge in diesem Thema