☰

Vorgehensweise zur Analyse, ob ein Prozess gehackt/geknackt wurde

tag-icon • tag-icon linux security
Vorgehensweise zur Analyse, ob ein Prozess gehackt/geknackt wurde

Durch reinen Zufall habe ich entdeckt, dass ein Prozess manchmal 100 % eines Kerns beansprucht, wenn ich nicht am Computer bin: Bei Verwendung der CPU liegt die Auslastung unter 1 %, aber wenn der Computer im IDL-Modus ist, d. h. der Bildschirm ausgeschaltet ist und niemand den PC eine Zeit lang berührt, beginnt dieser Prozess manchmal, die CPU intensiv zu nutzen. Sobald eine Eingabe den Bildschirm aufweckt, wird der Prozess wieder „normal“.

Ich habe ein Skript erstellt, um zu protokollieren, welche Prozesse viel CPU-Leistung verbrauchen, und habe herausgefunden, dass es sich dabei um kwin(cmdline = kwin-session1011dcae5a5000144224709...) handelt.

Irgendwas sagt mir, dass ein Fenstermanager die CPU-Leistung nicht zu 100 % nutzen sollte, wenn der Bildschirm ausgeschaltet ist. Deshalb suche ich nach einem Crack/Hack für meinen Computer.

Meine Frage ist:

  • Welches Verfahren muss befolgt werden, um festzustellen, ob dieser Prozess geknackt/gehackt ist?
  • Ist diese Annahme sinnvoll?

Hinweis: Ich habe den größten Teil des /proc/xxxOrdners kopiert, daher verfüge ich über ziemlich viele Informationen.

Antwort1

  • Welches Verfahren muss befolgt werden, um festzustellen, ob dieser Prozess geknackt/gehackt ist?

Die einzige Möglichkeit, zu sehen, was ein einzelner Prozess in einem aktuell laufenden System tut, besteht darin, diesen Prozess oder das gesamte System (den Kernel) zu debuggen. Ersteres ist ziemlich einfach, und mehrere Tools ermöglichen es Ihnen, dies live auf dem verdächtigen Prozess zu tun. Sie können sehen strace, welche Systemaufrufe er ausführt und ltracewelche gemeinsam genutzten Bibliotheksfunktionen er aufruft, oder sogar gdbals Ganzes, um zu sehen, welche Anweisungen er derzeit ausführt. Beachten Sie, dass Sie für Letzteres diesen Prozess einfrieren (im Standardmodus), und Sie benötigen einen Quellcode, der kwinan der richtigen Stelle liegt, damit gdb ihn laden und Ihnen eine Zeile anzeigen kann, in der er angehalten wurde. Andernfalls werden Ihnen nur Maschinenanweisungen mit speziellen Befehlen angezeigt.

Um den Kernel zu debuggen, benötigen Sie ein spezielles Setup, das bei einem bereits laufenden System wahrscheinlich nicht möglich ist (wenn es nicht beim Booten für ein solches Setup vorbereitet wurde). Es ermöglicht Ihnen, das gesamte System lokal (kgdbs kdb) oder remote (kgdb mit gdb) anzuhalten und Speicher und Register zu überprüfen, einige nützliche Informationen auszugeben und den Code zu disassemblieren. Um es jedoch effektiv interpretieren zu können, müssen Sie zumindest die Grundlagen von x86 asm kennen.

Der Kernel stellt zumindest eine Pseudodatei /proc/pid/mem bereit, die im normalen Modus nicht lesbar ist, aberhttps://github.com/siblynx/lynxware/blob/master/dumpmem.cist ein Wrapper, der diese Sparse-Datei basierend auf den in /proc/pid/maps bereitgestellten Zuordnungen liest. Sie können die gedumpte Datei dann mit dem Disassembler prüfen. Wenn Sie sich nicht für den Prozessstatus interessieren, können Sie ihn mit zum Dumpen des Kernels zwingen kill -SEGV pid. Wenn es jedoch beim Start nicht erlaubt war, Kerndateien zu dumpen ( ulimit -c size), wird er keinen Kernel dumpen, aber trotzdem abstürzen und alle Informationen verlieren, die Sie erhalten möchten.

Es gibt auch speziellere Forensik-Tools für die gleiche Aufgabe, die sich jedoch normalerweise an erfahrene Benutzer richten.

  • Ist diese Annahme sinnvoll?

Ich glaube nicht. Ich wäre etwas beunruhigt, wenn mein fvwm oder sogar twm (wenn ich daran gewöhnt wäre) sich so verhalten würde, aber was kwin (und KDE im Allgemeinen) betrifft, erwarte ich dieses Verhalten, weil das heutige KDE riesig ist und eine solche Aktivität dafür „normal“ ist.

Wenn es beispielsweise ein solches Verhalten mit fvwm gäbe, würde ich zuerst prüfen, ob /proc/pid/exe dieses Prozesses auf die richtige Binärdatei verweist, dann die Erstellungszeit dieser Binärdatei mit prüfen stat -c %z /path/to/binary, sie dann stratifizieren, wenn sie legitim war, oder sie andernfalls zu meinem stets bereiten KDB verschieben, wodurch das System eingefroren würde. Die meisten „verschwendeten“ Aktivitäten sind Programmfehler oder aufgeblähte Software.

  • Hinweis: Ich habe den größten Teil des /proc/xxxOrdners kopiert, daher verfüge ich über ziemlich viele Informationen.

Dies ist nicht sinnvoll, da /proc-Dateien rein virtuell sind und einige wichtige davon (wie etwa die memPseudodatei) bei einer normalen Anforderung nicht lesbar sind.

verwandte Informationen