Alles, was Sie mit einem kompromittierten Konto tun können, kann auch ein Angreifer tun.
Im Grunde liegt das daran, dass Linux nicht die Isolierung zwischen Benutzern anbietet zwischen einzelnen Prozessen, die unter demselben Benutzer ausgeführt werden. Jeder Prozess, der unter einem bestimmten Benutzer ausgeführt wird, hat die gleichen Fähigkeiten wie alle anderen Prozesse, die unter diesem Benutzer ausgeführt werden.
Stimmt es, dass die ausführbare System-Sudo-Datei auf diese Weise umgangen werden kann?
Ja, und auch sonst. Wenn Sie die Rechte auf root auf einem kompromittierten, nicht privilegierten Konto erhöhen, kompromittieren Sie root. Wenn Sie Berechtigungen von root mit su löschen zu einem unprivilegierten Konto kompromittieren Sie auch root! Sie können Berechtigungen für ein nicht vertrauenswürdiges Konto niemals sicher erhöhen. Es ist zwar möglich, das System mit PATH auszunutzen , ist es auch möglich, den Bash-Prozess selbst zu kapern, um Tasteneingaben auszuspähen. Ausführung mit noexec deaktivieren ist weiterhin nicht sinnvoll, da Interpreter (bash, python, perl, etc) weiterhin laufen. Die noexec Option ist und war nie als Sicherheitsmerkmal konzipiert, obwohl es regelmäßig als solches angeboten wird.
Eine unvollständige Liste von Möglichkeiten, wie ein Angreifer die Verwendung von sudo kapern könnte oder su :
-
Mit dem
LD_PRELOADVariable auf dem übergeordneten Prozess (z. B.bash). -
Einhaken des übergeordneten Prozesses mit
ptrace()oderprocess_vm_writev(). -
Mit dem X11-Protokoll Tastenanschläge in den Terminal-Emulator schnüffeln oder einfügen.
-
Aliase oder Funktionen erstellen, um den eigentlichen
sudozu umschließen ausführbar.
Ich habe diese ausführlicher in meiner Antwort auf eine andere Frage erläutert.
Warum sind Desktop-Linux-Systeme standardmäßig so eingerichtet, dass sie leicht ausgenutzt werden können?
Das Erhöhen von Berechtigungen für ein nicht vertrauenswürdiges Konto ist etwas, von dem Sie nicht erwartet werden machen. Ganz zu schweigen davon, dass Desktop-Linux ein nachträglicher Einfall im großen Schema der allgemeinen *nix-Architektur ist. Es ist ein Versagen des Sicherheitstheaters, das unaufhörlich dieselben schlechten Ratschläge wiederholt, nicht ein Versagen der Sicherheitsarchitektur von Linux selbst. Die Leute sagen immer wieder, dass sie sudo verwenden sollen für root, da viele neue Benutzer stattdessen alles ausführen als root, sogar ihre Browser! In diesem Fall ist es besser, sudo zu verwenden . Es ist schädlich, wenn der Benutzer bereits schlau genug ist, nicht für alles root zu verwenden.
Beachten Sie, dass sudo ist in hohem Maße konfigurierbar und kann so gestaltet werden, dass nur bestimmte Befehle zugelassen werden. Hier glänzt es wirklich. Sie können sudo konfigurieren damit Sie nur apt-get update ausführen können als root (mit oder ohne Passwort) und alles andere ablehnen. Das würde einen Angreifer zusätzlich daran hindern, irgendetwas anderes zu tun als ... naja ... ein Software-Update durchzuführen.
Es ist wichtig, sich daran zu erinnern, dass Sie sich selbst ins Knie schießen können, wenn Sie Programme auf die Whitelist setzen, die nicht dafür ausgelegt sind, über einen nicht vertrauenswürdigen Benutzer als Root ausgeführt zu werden, selbst wenn Sie es so konfigurieren, dass nur bestimmte Befehle als Root ausgeführt werden können. Ich habe ein reales Beispiel von jemandem gesehen, der versucht hat, VeraCrypt auf diese Weise auszuführen, und erklärt, warum es unsicher ist. Die Idee war, dass VeraCrypt sicher als Root ausgeführt werden kann, also sollte es sicher sein, sudo zu verwenden um es als nicht vertrauenswürdigen, nicht privilegierten Benutzer auf root zu erhöhen. Es stellt sich heraus, dass die Idee fehlerhaft ist und eine triviale Rechteausweitung zulässt!
Sollte die Standardmethode zum Aufrufen von sudo nicht sicherstellen, dass es sich tatsächlich um die vom System bereitgestellte ausführbare Datei handelt (niemand wird jedes Mal /usr/bin/sudo eingeben)?
Die Eingabe des vollständigen Pfads schützt Sie nicht! Sie können ganz einfach eine Funktion erstellen, die ein vorangestelltes / enthält , und es wird die echte ausführbare Datei überschreiben. Selbst wenn die ausführbare Datei sichergestellt hat, dass sie echt ist, und versucht hat, das Sniffing zu unterbinden, könnte ein böswilliger Prozess den bash entführen Tastenanschläge unabhängig von sudo verarbeiten und schnüffeln , was es unmöglich macht, aus seiner Sicht zu erkennen.
$ function /usr/bin/sudo { echo 'hijacked!'; }
$ /usr/bin/sudo id
hijacked!
In einer solchen Umgebung scheint die Verwendung von sudo grundsätzlich unsicher zu sein, und man wäre besser dran, die Anmeldung als root zu aktivieren und sich auf einem separaten TTY anzumelden.
Das ist immer der Fall. Beachten Sie, dass selbst die Anmeldung bei einem anderen TTY nicht absolut sicher ist. Sie sollten SAK, die Secure Attention Key-Kombination, verwenden, um sicherzustellen, dass Sie mit einer echten Anmeldesitzung interagieren (agetty oder logind , zum Beispiel). SAK ist eine Tastenkombination, auf die der Kernel lauscht (und daher nicht vom Userspace unterdrückt werden kann). Wenn es dies erkennt, beendet es jeden Prozess im aktuellen TTY und löst die Anzeige der Anmeldeaufforderung aus. Wenn Sie zu einem echten, nicht kompromittierten TTY gewechselt haben, wird die Eingabeaufforderung nur verschwinden und erneut angezeigt. Wenn Sie sich auf einem entführten TTY befinden, wird der bösartige Prozess beendet und die echte Anmeldeaufforderung zurückgegeben.