Was ist eine eingeschränkte Shell und warum sind Jumping-Shell-Angriffe wichtig?
Eingeschränkte Shells werden verwendet, um zu kontrollieren, welche Befehle Benutzer ausführen können. Sie verhindern oft Aktionen wie cd, das Starten neuer Shells oder das Exportieren von Umgebungsvariablen. Sie werden typischerweise in CI/CD Agenten oder Build-Umgebungen, um das Benutzerverhalten einzuschränken. Angreifer suchen jedoch nach Möglichkeiten, eine Jumping Shell auszuführen, eine Methode, mit der sie eingeschränkten Shell-Umgebungen entkommen und Zugriff auf uneingeschränkte Shells erhalten, wie z. B. bin/bash. Einmal drinnen ithat der Angreifer die volle Kontrolle über die Befehlszeile und umgeht alle Einschränkungen der eingeschränkten Umgebung.
So funktioniert Jumping Shell: Von Restricted zu bin/bash
Das Ziel einer springenden Shell ist es, Schwächen in eingeschränkten Umgebungen auszunutzen und einen Shell-Ausbruch auszulösen, der zu bin/bashZu den gängigen Techniken für Angriffe mit eingeschränkter Fluchtmöglichkeit gehören:
$ ls
/bin/bash
$ /bin/bashIf bin/bash zugänglich ist, wird es durch diesen einfachen Aufruf vervollständigt.
Eine weitere gängige Methode:
$ echo "/bin/bash" > run.sh
$ sh run.sh
Angreifer können auch Editoren wie vi or weniger:
vi
:set shell=/bin/bash
:shell
Diese Methoden veranschaulichen, wie leicht eine springende Muschel zu bin/bash Ausführung, wodurch eingeschränkte Shell-Schutzmaßnahmen effektiv umgangen werden.
Die tatsächlichen Risiken dieser Angriffe in DevOps
In geteilten CI/CD Umgebungen werden eingeschränkte Shells verwendet, um Builds zu isolieren und das Risiko zu reduzieren. Aber wenn ein Angreifer mit einer Jumping Shell erfolgreich ist und erreicht bin/bashbricht das Sicherheitsmodell zusammen.
Zu den Risiken gehören:
- Unbefugter Zugriff auf Umgebungsgeheimnisse
- Rechteerweiterung über uneingeschränkte bin/bash
- Manipulation des Builds pipelines oder Artefakte
- Einsatz von persistenten Tools innerhalb der pipeline
Die Flucht beschränkte Schale auf bin/bash öffnet die Tür zur vollständigen Kompromittierung des Systems, oft der erste Schritt in einer umfassenderen DevSecOps-Angriff.
Überwachen und Erkennen von Jumping Shell- und Bin/Bash-Escapes
Um das Verhalten springender Shells zu erkennen und Versuche zu blockieren, aus denen Shells mit Fluchtbeschränkung ausbrechen können, müssen Sicherheitsteams:
- Protokollieren Sie alle Shell-Aktivitäten, insbesondere / bin / bash Ausführung
- Überwachen Sie den Missbrauch des Editors und die Verwendung von Skripten als Shell-Spawn-Vektoren
- Verfolgen Sie den Zugriff auf Shell-Konfigurationsdateien wie .bashrc or Bash_profile
Verhaltensmuster wie das Starten bin/bash aus einer eingeschränkten Umgebung sollten als Warnungen mit hoher Priorität betrachtet werden. Eine frühzeitige Erkennung kann eine tiefere laterale Bewegung verhindern.
Verhindern von Escape Restricted Shell-Angriffen und Exploits
Um das Risiko von Jumping Shells zu minimieren und Angreifer daran zu hindern, bin/bash:
- Eingeschränkte Schalen härten: Entfernen oder blockieren Sie die Zugang
- Verwenden Sie AppArmor oder SELinux, um die Befehlsausführung einzuschränken
- Erzwingen Sie die geringsten Privilegien über CI/CD Rollen und Läufer
- Containerisieren Sie Builds mit Distroless-Images ohne Shells wie bin/bash
- Validieren Sie Umgebungen vor und nach dem Erstellen, um Anomalien zu erkennen
Um das Entkommen aus eingeschränkten Shell-Szenarien zu verhindern, sind mehrstufige Kontrollen erforderlich, nicht nur das Vertrauen auf eingeschränkte Shells. Gehen Sie nicht davon aus, dass eingeschränkte Shells sicher sind, wenn bin/bash ist sogar potenziell erreichbar.
Fazit: Shell-Escapes sind Einstiegspunkte
Eingeschränkte Shells sind eine Verteidigungsschicht, aber keine Garantie. Jumping-Shell-Angriffe zielen auf schwache Isolation und unzureichende Validierung ab. Einmal drinnen / bin / bashAngreifer können die DevSecOps-Infrastruktur umstellen, beibehalten und kompromittieren.
Erkennung und Isolierung sind unerlässlich. Die Kombination aus Befehlsprotokollierung, eingeschränkten Umgebungen und der ordnungsgemäßen Bereinigung von Paketmanagern verringert das Risiko.
Schließlich sind Tools wie Xygeni bieten Einblick in diese Risiken. Sie helfen, die Code-Integrität zu gewährleisten, ungewöhnliches Shell-Verhalten zu erkennen und Sichern Sie Ihre pipelines vor internen und externen Bedrohungen, einschließlich derjenigen, die mit einer einfachen springenden Muschel beginnen, um / bin / bash oder Versuche, eingeschränkten Shell-Umgebungen zu entkommen.
