Warum ist es möglich rootkits vor process listener Programmen zu verstecken?
-
Da scheint jemand nicht verstanden zu haben warum das Rootkit heisst! Was für eine Frage!
-
Tobiking2 schrieb:
ps_ schrieb:
Also z.b. dass man dem ps (Process listener) die höchste Priorität gibt und die liste aller aktuellen Prozesse in einem Bereich gespeichert werden, in dem rootkits keinen Zugang haben?
Wenn der Rootkit sich im Kernel eingenistet hat, gibt es keinen Bereich zu dem er keinen Zugriff hat. Da müsste man schon gezielt die Hardware mit einbeziehen, was in Richtung Trusted Computing geht und seine eigenen Probleme mit sich zieht. Zumal dort auch immer wieder Lücken gefunden werden.
Das ist mir schon klar. Aber warum verhindert das OS nicht, dass Programme mit Adminrechten überhaupt am Kernel herumpfuschen können.
Viele Tools schaffen das verstecken ja sogar on the fly bei laufenden System, ohne das der Kernel neu gebootet werden muss.
Ein Beispiel wäre z.B. das Tool fu.
https://www.aldeid.com/wiki/FU-RootkitUnd würde man den Kernel per Update updaten müssen, dann könnte man ja eine explizite Routine im Kernel schreiben, die die einzige ist, die die Kerneldateien auf der Festplatte überhaupt verändern kann und zu dem noch eine Signaturprüfung durchführt.
So hätte es Malware selbst dann schwer, die rootkit Software durch einen reboot des Kernels zum Laufen zu bringen, denn sie würde ja dann daran scheitern, die Dateien des Kernels überhaupt zu updaten.@dummduemmernochduemmer
Wenn du von der tieferen Materie die hinter meine Frage steckt keine Ahnung hast, dann solltest du besser deine Fresse halten.
-
ps_ schrieb:
@dummduemmernochduemmer
Wenn du von der tieferen Materie die hinter meine Frage steckt keine Ahnung hast, dann solltest du besser deine Fresse halten.
Er hat nicht ganz unrecht. Der rootkit läuft naturgemäß mit Rootrechten, also darf er auch alles, was root darf. Dein Vorschlag mit den erhöhten Kernelrechten geht am Problem vorbei. Wer gibt denn beispielsweise dem Kernel in deinem Beispiel den Befehl zum Update? Ein Nutzer mit Rootrechten! Und wenn du nun einwendest, dass der Kernel bei dir spezielle Privilegien hat, die der Rootnutzer nicht hat, dann hast du bloß die Namensgebung geändert und Kernelrechte sind die neuen Rootrechte und Rootkits heißen von nun an Kernelkits¹.
Das eigentliche Problem, dass es zu verhindern gilt, ist, dass eine Malware überhaupt erst an Rootrechte gelangt. Wenn eine Malware erst einmal Rootrechte hat, dann ist es zu spät, noch Schäden verhindern zu wollen.
¹: Die Idee entspricht dem Trusted Computing, wie bereits in einer anderen Antwort angesprochen wurde. Es verlagert das Problem auf eine Ebene über dem OS-Kernel. Aber dann spielt sich eben das gleiche Spiel auf dieser Ebene ab. Es gab bereits Rootkits, die auf einer Ebene über dem OS operierten, indem sie sich beispielsweise vor dessen Bootvorgang schalteten. Und mit UEFI eröffnen sich völlig neue Möglichkeiten, da nun selbst die innerste Operationsebene des Computers komplexe Software speichern und ausführen kann.
-
SeppJ schrieb:
ps_ schrieb:
@dummduemmernochduemmer
Wenn du von der tieferen Materie die hinter meine Frage steckt keine Ahnung hast, dann solltest du besser deine Fresse halten.
Er hat nicht ganz unrecht.
Doch, denn:
Der rootkit läuft naturgemäß mit Rootrechten, also darf er auch alles, was root darf. Dein Vorschlag mit den erhöhten Kernelrechten geht am Problem vorbei. Wer gibt denn beispielsweise dem Kernel in deinem Beispiel den Befehl zum Update? Ein Nutzer mit Rootrechten! Und wenn du nun einwendest, dass der Kernel bei dir spezielle Privilegien hat, die der Rootnutzer nicht hat, dann hast du bloß die Namensgebung geändert und Kernelrechte sind die neuen Rootrechte und Rootkits heißen von nun an Kernelkits¹.
Bsp:
Der Kernel inkl. der Kernel Update und Signaturprüffunktion läuft in ring 0.
root läuft in ring 1.Wenn root nun den Kernel updaten will, dann ruft er die Updatefunktion in ring 0 auf und übergibt dieser einen BLOB, der z.b. den neuen Kernel erhält oder eben das, was verändert werden soll.
Mit der bloßen Übergabe ist aber noch gar nichts erreicht. Denn jetzt nimmt diese Kernel Update Funktion den Blob und überprüft dessen Signatur.
Stimmt diese, dann macht sie weiter und modifiziert die Kerneldateien.
Stimmt die Signatur nicht, dann wird das Updaten verweitert.Wie will jetzt ein rootkit Programmer da einen rootkit auf Kernelebene einschleußen?
Er kann zwar die Funktion aufrufen und ihr seinen modifizierten Code übergeben, aber an der Signaturprüffunktion kommt er nicht vorbei, da müsste er schon den Code so modifizieren, das die Signaturprüffunktion das auch nicht merkt, aber wie wir wissen, ist das kein Kinderspiel.Das eigentliche Problem, dass es zu verhindern gilt, ist, dass eine Malware überhaupt erst an Rootrechte gelangt. Wenn eine Malware erst einmal Rootrechte hat, dann ist es zu spät, noch Schäden verhindern zu wollen.
Nicht ganz.
Denn mit root kann man zwar viel anstellen, aber wenn man auch die Prozessliste modifizieren kann, dann hat es ein Admin auch schwer das rootkit überhaupt zu finden.
Ist die Prozessliste aber in ring 0 geschützt und root nur in ring 1 tätig, dann kommt das root kit zumindest daran nicht heran.
Der Hacker kann dann zwar jede Menge Müll mit den root Rechten bauen, aber er kann sein rootkit nicht verstecken.
Wenn man nämlich ein kompromitiertes System von einem nicht kompromitierten System unterscheiden will, dann ist obscurity durchaus ein Problem, denn es kostet auf jede Fälle schon einmal Zeit.
Mit einer geschützten Prozessliste ist obscurity nicht möglich. Da bräuchte man schon ein rootkit das den Kernel vor dem booten modifiziert.
¹: Die Idee entspricht dem Trusted Computing, wie bereits in einer anderen Antwort angesprochen wurde. Es verlagert das Problem auf eine Ebene über dem OS-Kernel. Aber dann spielt sich eben das gleiche Spiel auf dieser Ebene ab. Es gab bereits Rootkits, die auf einer Ebene über dem OS operierten, indem sie sich beispielsweise vor dessen Bootvorgang schalteten.
Ja, die Bootkits.
Die funktionieren aber nur, weil man von einem bestehenden System aus mit rootrechten den Bootloader modifizieren kann.
Auch hier wäre es somit sinnvoll, das mit einem Signaturverfahren im Kernel in ring 0 zu verhindern.Und mit UEFI eröffnen sich völlig neue Möglichkeiten, da nun selbst die innerste Operationsebene des Computers komplexe Software speichern und ausführen kann.
Das ist mir bekannt.
Diese extra Funktionen wie Kernel und Bootsektor updaten, Prozesse auflisten usw. müssten natürlich besonders schlank sein.
Bei UEFI ist das nicht der Fall, da hat man das ganze Zeugs mit Maus-, Netzwerktreibern usw. und viel weiterem Zeugs deutlich aufgeblasen.
Das ist nett für ein hübsches Gimmick, aber Sicherheitstechnisch wäre dieser Schritt nicht nötig gewesen.
Es hätte genügt, wenn man Windows entsprechend ändert, wie oben beschrieben.
-
Deine Frage und deine Wortwahl lassen auf eine tiefe Materie schliessen. Früher hat man solche Leute gebannt, heute werden sie in Talkshows eingeladen.
-
Das Beispiel bezieht sich natürlich auf ein gedachtes System wie es mir vorschwebt, also nicht falsch verstehen. Es bedeutet nicht, dass Windows so funktioniert.
ps_ schrieb:
Bsp:
Der Kernel inkl. der Kernel Update und Signaturprüffunktion läuft in ring 0.
root läuft in ring 1.Wenn root nun den Kernel updaten will, dann ruft er die Updatefunktion in ring 0 auf und übergibt dieser einen BLOB, der z.b. den neuen Kernel erhält oder eben das, was verändert werden soll.
...
-
dummdümmernochdümmer schrieb:
Deine Frage und deine Wortwahl lassen auf eine tiefe Materie schliessen. Früher hat man solche Leute gebannt, heute werden sie in Talkshows eingeladen.
Meine Wortwahl war für nen Dummscheißer wie dich angemessen und jetzt gib ruh.
-
Du verstehst echt nicht was ein infiziertes System ist, oder?
-
Warum kann ein infiziertes System nicht nicht infiziert reagieren?
-
Du definierst bloß Worte um. Du nennst also ab nun einen eingeschränkten Account mit leicht gehobenen Nutzerrechten root und sagst, dass das rootkits verhindert, weil root nun nicht mehr alle Rechte hat. Das ist ein Versuch, das Problem durch Umdefinition zu lösen. Das funktioniert aber bei keinem Problem auf der Welt. Auf jedem Rechner existiert irgendeine Nutzerebene, die alles darf, denn sonst könnte der Rechner nicht funktionieren. Wie du diese Ebene nennst, ändert nichts an der Tatsache, dass, wenn diese Ebene kompromittiert ist, der ganze Rechner kompromittiert ist.
-
SeppJ schrieb:
Du definierst bloß Worte um. Du nennst also ab nun einen eingeschränkten Account mit leicht gehobenen Nutzerrechten root und sagst, dass das rootkits verhindert, weil root nun nicht mehr alle Rechte hat. Das ist ein Versuch, das Problem durch Umdefinition zu lösen. Das funktioniert aber bei keinem Problem auf der Welt. Auf jedem Rechner existiert irgendeine Nutzerebene, die alles darf, denn sonst könnte der Rechner nicht funktionieren. Wie du diese Ebene nennst, ändert nichts an der Tatsache, dass, wenn diese Ebene kompromittiert ist, der ganze Rechner kompromittiert ist.
Ich habe doch ein sinnvolles Beispiel gebracht.
Und in Ring 0 muss man nicht alles dürfen.
Es geht darum die Funktionalität in Ring 0 deutlich einzuschränken und wenn man das so machen würde wie ich sagte, dann würde kein rootkit da reinkommen.Wenn du da jetzt mit Worte umdefinieren kommst, dann liegt das daran, dass du unter rootkit eine Ring 0 Anwendung meinst, aber das ist nicht einmal richtig, denn selbst die Wikipedia sieht das nicht so.
Sie definiert z.b. auch userspace rootkits, obwohl die nicht in ring 0 arbeiten.Es geht also um das technische und wie man was erreicht und nicht wie man irgendwelche Begriffe betrachtet.
Mit anderen Worten, ein hacker der nen Exploit ausnutzt und es damit auf die adminebene in ring 1 schafft, der kann seinen Trojaner trotzdem nicht verstecken, da ihm der Zugriff auf ring 0 verwehrt ist. Das ist eine Technische Lösung.
-
ps_ schrieb:
rotzdem nicht verstecken, da ihm der Zugriff auf ring 0 verwehrt ist. Das ist eine Technische Lösung.
Und es ist übrigen auch genau die, nach der ich in meinem Eingangsposting gefragt habe.
Ach ja, der Wikipedia Artikel:
https://en.wikipedia.org/wiki/Rootkit#User_mode
-
Derzeit: Ein Hacker, der es auf Ring 0 schafft, kann sein Rootkit perfekt verstecken. Ein Hacker, der das nicht schafft, muss rumtricksen und hoffen, dass er nicht gefunden wird.
Nach deinem Vorschlag: Ein Hacker, der es auf Ring 0 schafft, kann sein Rootkit perfekt verstecken. Ein Hacker, der das nicht schafft, muss rumtricksen und hoffen, dass er nicht gefunden wird.
Was ist der Unterschied?
-
SeppJ schrieb:
Derzeit: Ein Hacker, der es auf Ring 0 schafft, kann sein Rootkit perfekt verstecken. Ein Hacker, der das nicht schafft, muss rumtricksen und hoffen, dass er nicht gefunden wird.
Nach deinem Vorschlag: Ein Hacker, der es auf Ring 0 schafft, kann sein Rootkit perfekt verstecken. Ein Hacker, der das nicht schafft, muss rumtricksen und hoffen, dass er nicht gefunden wird.
Was ist der Unterschied?
Er schafft es im zweiten Fall vom System heraus nicht auf Ring 0.
-
Mit einer auf das nötigste signaturgeprüften Ring 0 Ebene, inkl. Kernelupdate- und Process Listenerfunktion wäre das hier nicht passiert:
-
ps_ schrieb:
Da ich mal davon ausgehe, dass die OS Schreiber bei Microsoft und CO nicht blöd sind, frage ich mich, warum es trotzdem vorkommt und möglich ist, dass sich rootkits vor ps Anwendungen verstecken können.
Also erstmal kannst du das ganze ja haben wenn du willst. Du brauchst halt ein neueres Windows dazu (idealerweise Windows 10) und ein Trusted Platform Module.
Verwendet wird es deswegen wenig bis kaum, da unter Windows so verdammt viel in Ring 0 läuft, dass es recht unpraktisch wäre wenn alles was in Ring 0 laufen darf signiert sein muss. Auf Grund der Archtektur von Windows ist das wohl auch recht schwierig zu ändern.
Und so geworden ist es deswegen, weil das Thema Security zu dem Zeitpunkt wo Windows entworfen wurde noch ganz anders bewertet wurde. Die Idee dass man sich gegen bösen Code schützen müsse, der von Usern mit Admin-Rechten freiwillig installiert wird (weil sie nicht wissen dass der Code böse ist) war damals kein Thema. Genau so war noch kein Bewusstsein dafür da dass es Exploits geben könnte mit denen man sich in Ring 0 reinhacken kann ohne dafür Admin-Rechte zu brauchen.Ansonsten ist die Überlegung natürlich korrekt: Je weniger in Ring 0 läuft, desto eher ist es akzeptabel von allem was in Ring 0 läuft zu verlangen dass es offiziell signiert ist. Zusammen mit einer Boot-Lösung die ebenfalls nur signierten Code akzeptiert, hätte man damit ein System dessen Sicherheit in der Praxis wesentlich besser ist als die von z.B. Windows ohne TMP/Secure-Boot, die es einem aber gleichzeitig noch erlaubt die meisten unsignierten Treiber zu installieren.
-
ps_ schrieb:
Ja, die Bootkits.
Die funktionieren aber nur, weil man von einem bestehenden System aus mit rootrechten den Bootloader modifizieren kann.
Auch hier wäre es somit sinnvoll, das mit einem Signaturverfahren im Kernel in ring 0 zu verhindern.Bootkits kannst du mit dem OS Kernel nicht verhindern. Also nicht das Laden von Bootkits. Höchstens das Installieren von Bootkits.
Wenn dir jemand den PC allerdings z.B. von nem USB Stick bootet wo böser Code drauf ist der das böse Bootkit installiert, dann hast du das Bootkit trotzdem drauf. Und wenn du dann wieder normal bootest, dann ist es zu dem Zeitpunkt wo der Kernel deines OS geladen wird bereits zu spät. Weil das Bootkit da bereits einen Hypervisor installiert hat, der das Bootkit vor dem Kernel versteckt. Ähnlich wie auch eine VM nicht einfach so auf die Speicherbereiche des Hosts oder anderer VMs zugreifen kann.D.h. du brauchst diese Funktion im BIOS/EFI.
-
Hustbaer, wenn ein unautorisierter Zugriff auf die Hardware des Computers hat, dann hat er mehr Möglichkeiten als von einem Usb-Stick zu booten.
Soweit sollte man es gar nicht erst kommen lassen
