it-swarm-eu.dev

Systemaufrufe überwachen (zuverlässig und sicher)

Gibt es eine zuverlässige Methode zur "Überwachung" von Systemaufrufen unter Linux?

Es gibt strace zum Beispiel, um Systemaufrufe und Signale zu überwachen. Gibt es eine Möglichkeit für einen Prozess, aus strace auszuweichen? Wenn ja, gibt es eine andere zuverlässige und sichere Methode zum "Überwachen" von Systemaufrufen (und möglicherweise zum Empfangen von Signalen), der sich ein Prozess nicht entziehen kann (unter der Annahme einer ordnungsgemäßen Linux-Implementierung)?

15

Unter Linux können Sie eine Auswahl von Systemaufrufen oder Dateizugriffen mit dem Audit-Subsystem zuverlässig überwachen. Stellen Sie sicher, dass der Daemon auditd ausgeführt wird, und konfigurieren Sie dann, mit was Sie sich anmelden möchten auditctl . Jeder protokollierte Vorgang wird in /var/log/audit/audit.log Aufgezeichnet (bei typischen Konfigurationen).

Sie finden einfache Beispiele für die Verwendung von auditctlauf dieser Site , auf Serverfehler und auf nix Stack Exchange .

strace oder zugehörige Programme, die ptrace verwenden, sind zuverlässige Methoden zur Überwachung von Systemaufrufen, aber ich wäre vorsichtig, wenn ich sie in einem Schadprogramm verwenden würde. Ich konnte Ihnen nicht sagen, wie weit ich gekommen bin, aber es sollte möglich sein, dass ein überwachtes Programm die richtigen ptrace Aufrufe ausführt, um der Überwachung zu entgehen.

Beachten Sie, dass ein Schadprogramm einen Prozess auslösen kann, der nicht überwacht wird, und Code ausführen kann, der nicht protokolliert wird. Beispielsweise könnte es mmap verwenden, um in eine Datei zu schreiben, ohne dass der Dateiinhalt jemals als Argumente für Systemaufrufe angezeigt wird, diese Datei ausführbar zu machen und einen Prozess zu erzeugen, der sie ausführt. Der erzeugte Prozess kann normalerweise den Prozessbaum mit etwas wie ssh localhost Unterbrechen. Wenn Sie alle von einem bestimmten Benutzer ausgeführten Prozesse überwachen (im Gegensatz zu nur einem einzelnen Prozess und seinen Nachkommen), können Sie alles protokollieren.

Wenn ja, gibt es eine andere zuverlässige und sichere Methode zum "Überwachen" von Systemaufrufen (und möglicherweise zum Empfangen von Signalen), die dieser Prozess nicht unterbrechen kann (unter der Annahme einer ordnungsgemäßen Linux-Implementierung)?

Um etwas anders zu wiederholen, was D.W. hat bereits gesagt, ptrace ist ein Systemaufruf, den strace, gdb und dergleichen ausführen, um die Aktionen eines Prozesses zu überwachen. Bei diesem Ansatz gibt es zwei Probleme:

  1. Wie Sie wahrscheinlich wissen, ist das Verknüpfen von Systemaufrufen eine bevorzugte Technik von Rootkit-Autoren. Es ist durchaus möglich, ptrace zu ersetzen, die Ausgabe eines anderen Prozesses oder eines anderen solchen Fehlverhaltens bereitzustellen.
  2. Prozesse werden nicht immer so geschrieben, dass sie bereitwillig an Debugger gesendet werden. Vielleicht möchten Sie dieses Herausforderungsset (win32-fokussiert - sehen Sie sich den ersten Eintrag an und lesen Sie weiter, um es schwierig zu machen) von einer Appsec-Firma lesen (ich habe keine Links zu ihnen). Während sie sich auf den Mechanismus IsDebuggerPresent() konzentrieren, gibt es ähnliche Lösungen für ptrace . Wenn Sie dies in freier Wildbahn sehen möchten und Skype auf einer Linux-Box installiert haben möchten, versuchen Sie, es zu debuggen.

    Wenn man diese Techniken hier wiederholt, gibt es zwei klare Anti-Ptrace-Mechanismen:

    if (ptrace(PTRACE_TRACEME, 0, 0, 0) < 0) {
        printf("being ptraced\n");
        exit(1);
    }
    

    Diese Methode beruht auf der Tatsache, dass ein Prozess nicht zweimal verfolgt werden kann. Wenn Sie sich nicht verfolgen können, werden Sie verfolgt.

    struct timespec spec;
    
    signal(SIGALRM, SIG_IGN);
    alarm(1);
    spec.tv_sec = 2;
    spec.tv_nsec = 0;
    if (nanosleep(&spec, NULL) < 0) {
        /* EINTR */
        printf("being ptraced\n");
        exit(1);
    }
    

    Um dies zu erklären, schauen Sie sich nanosleep() an und lesen Sie den Originalartikel. In einfachen Worten, nanosleep() ist ein nicht neu startbarer Systemaufruf und wird früh zurückkehren, wenn ein Signal vom Prozess verarbeitet wird. Dieser bestimmte Prozess verarbeitet, wenn er nicht debuggt wird, dieses bestimmte Signal einfach nicht und wird daher nicht aufgeweckt. Ein verfolgter Prozess wird dies jedoch verarbeiten, wodurch nanosleep vorzeitig zurückkehrt. Ein weiteres Beispiel, in dem dies geschieht, ist der Systemaufruf select().

Letztendlich können Sie die Auswirkungen von 1 abschwächen, indem Sie die Integrität Ihres Systems sicherstellen, bevor Sie ausreichende Sicherheitsmaßnahmen und einen entsprechend konfigurierten Kernel starten und anwenden.

Was können Sie zuverlässig gegen 2 tun? Nicht viel, ohne den ursprünglichen Binärcode zu ändern, da jede Technik zum Debuggen irgendwo beobachtbare Inkonsistenzen oder Implementierungsprobleme verursachen wird.

tl; dr ptrace hilft Ihnen, wenn der Zielprozess nicht für Debugger geschrieben wurde.

10
user2213

Das Linux Audit Framework unterstützt die Syscall-Überwachung - ich glaube, es ist das, wonach Sie suchen.

5
john

Ja. strace ist eine vernünftige Methode zur Überwachung von Systemaufrufen und deren Argumenten, solange der überwachte Prozess nicht böswillig ist. Wenn der überwachte Prozess böswillig ist und geschrieben wurde, um Strace zu umgehen, gehe ich davon aus, dass dies möglich ist. strace wurde nicht als Sicherheitstool geschrieben, und ich kann verschiedene Möglichkeiten annehmen, wie der Prozess es besiegen könnte. Siehe z. B. Robert Watson, Ausnutzen von Sicherheitslücken bei Parallelität in Systemaufruf-Wrappern oder Tal Garfinkel, Fallen und Fallstricke: Praktische Probleme in auf Systemaufruf-Interposition basierenden Sicherheitstools .

Wenn Sie sich Sorgen über bösartigen Code machen, sollten Sie eine Sandbox verwenden, die für die Sicherheit entwickelt wurde, und nicht ein Tool wie strace, das nicht für die Sicherheit entwickelt wurde. Der allgemeine Ansatz zum Erstellen einer solchen Sandbox besteht darin, die Interposition von Systemaufrufen sowohl zur Eindämmung des überwachten Prozesses als auch zur Überwachung seiner Aktionen zu verwenden. Eine tragbare Methode ist die Verwendung von ptrace. Dies kann jedoch zu einem nicht trivialen Leistungsaufwand führen, da bei jedem Systemaufruf ein Kontextwechsel erzwungen wird. Unter Solaris können Sie/proc verwenden. Mit/proc können Sie die Teilmenge der Systemaufrufe angeben, die Sie umbrechen möchten. Auf diese Weise können Sie auf Kosten der Kompatibilität eine bessere Leistung erzielen.

Schauen Sie sich Plash, Systrace und Subterfugue an, um einige funktionierende Systeme zu sehen, die diese Art von Methoden verwenden. Schauen Sie sich auch die Sandbox von Chrome an, die eine Vielzahl von Mechanismen verwendet (einschließlich seccomp unter Linux).

4
D.W.

Was ist mit der Überwachung der Systemaufrufe auf der Seite des Kernels mithilfe einer externen GDB-Instanz?.

Dies kann durch Einrichten einer virtuellen Maschine erfolgen, die für die Ausführung des interessierenden Codes konfiguriert ist. Dann müssen QEMU und KVM (meines Wissens)) so konfiguriert werden, dass ein Port für das GDB-Debugging des Kernels geöffnet wird. (Siehe Anleitungen blasen.)

Wenn dies VM wird gestartet), könnte gdb während des Startvorgangs an seinen Kernel angehängt werden.

Der nächste Schritt besteht darin, GDB-Eigenschaften und Haltepunkte so festzulegen, dass sie bei allen Execute (und Consorts) ausgelöst werden, die den interessierenden Code als neues Programm festlegen. Lassen Sie dann die GDB laufen, bis sie diesen Haltepunkt erreicht. Zu diesem Zeitpunkt während der Ausführung des Programms konnte die PID des Prozesses, auf dem der interessierende Code ausgeführt wird, extrahiert und in gdb Haltepunkte gesetzt werden, die bei jedem Systemaufruf dieses Prozesses (einschließlich Fork und Execve) (im Kernel-Code) getroffen werden Aufrufe, die zu zusätzlichen zu beobachtenden Prozessen führen können).

Theoretisch sollte dies eine gute Lösung sein, die schwer zu finden ist.

Ein Problem ist, dass alles im Gastsystem furchtbar langsam wird und Sie möglicherweise eine große Anzahl unerwünschter Anrufe als Beifang erhalten (die Sie mit gdb filtern müssen ...). Zusätzliche GDB muss möglicherweise mit python) erweitert werden, damit die bedingten Haltepunkte mit den erforderlichen Bedingungen funktionieren (insbesondere für eine automatische Erkennung untergeordneter Prozesse).

Anleitungen zum Verbinden von gdb mit dem Gast: Whamcloud Wiki , ReadHat Helpdesk , Stackoverflow

(Ich habe diese Anleitungen nicht ausprobiert. Ich habe vor einigen Jahren gdb verwendet, um einige Details des Kernels für ein Schülerprojekt zu debuggen. Dort habe ich eine einfache Bedingung an einem Haltepunkt verwendet, um Fork-Aufrufe eines bestimmten Prozesses zu erkennen.)

Darüber hinaus gibt es einige andere Techniken, um einen Kernel zu debuggen .

PS: Beachten Sie, dass es Möglichkeiten gibt, einer virtuellen Maschine zu entkommen (ein altes Beispiel ).

0
msebas