GTFOBins

• Eine Liste von Unix-Binärdateien ist nach Funktionen geordnet, und die möglichen Aktionen jeder Binärdatei sind direkt über Detailseiten und Anker-Links erreichbar
• Wiederkehrende Kategorien sind Shell, File read, File write, Command, Inherit, Upload, Download, Reverse shell, Library load und Privilege escalation; bei einigen Einträgen kommt zusätzlich Bind shell vor
• File read und Shell sind sehr breit vertreten, und Werkzeuge wie dd, sed oder sqlite3 beherrschen Lesen und Schreiben zugleich, wodurch die Grenze zu reinen Anzeige-Tools verschwimmt
• Werkzeuge wie apt, git, journalctl und systemctl enthalten häufig Command und Inherit; zudem erscheinen wiederholt multifunktionale Binärdateien wie bee, pipx, sqlmap und die vim-Familie, die Netzwerktransfer und Shell-Aktionen zugleich bieten
• Privilege escalation erscheint nur bei einigen Binärdateien mit eigenem Link; die breite Liste von 7z bis zypper macht die Unterschiede in den Aktionskombinationen gewöhnlicher Tools auf einen Blick sichtbar

---

Verteilung der wichtigsten Funktionen

• Einträge, die ausschließlich oder überwiegend Dateien lesen, sind sehr breit verteilt
  • 7z, cat, grep, jq, od, tail, wc, zcat usw. sind schwerpunktmäßig mit File read verknüpft
• Es gibt auch sehr viele Einträge mit Shell-Ausführung
  • bash, awk, find, less, python, ruby, tar, vi, zsh verfügen über Shell
• Viele Einträge vereinen File write und Lesen, wodurch die Grenze zu reinen Anzeige-Tools unschärfer wird
  • dd, cpio, ed, emacs, nano, sed, sqlite3, xxd gehören dazu
• Command-Ausführung oder Rechtevererbung treten häufig bei Paketmanagern, Systemwerkzeugen und interaktiven Programmen auf
  • apt, apt-get, git, journalctl, man, systemctl, timedatectl, zless sind typische Vertreter

Multifunktionale Binärdateien

• Multifunktionale Binärdateien, die mehrere Aktionen zugleich beherrschen, tauchen wiederholt auf

• Multifunktionale Einträge auf Inherit-Basis

  • apport-cli, batcat, cargo, crash, gcloud, git, journalctl, man, opencode, psql, run-mailcap, systemd-resolve bündeln zusammen mit Inherit Shell, Command, File read und File write

• Einträge inklusive Netzwerk und Dateitransfer

  • bee, byebug, dstat, easy_install, facter, irb, knife, pipx, poetry, rake, sqlmap, vagrant, volatility verfügen zusätzlich über Reverse shell, Upload, Download und Library load

• Editoren- und Debugger-Familie

  • gdb, nvim, rvim, view, vim, vimdiff bündeln zusammen mit Inherit Shell, Reverse shell, Bind shell oder File read/write, Upload, Download und Library load

• Paketmanager- und Laufzeit-Familie

  • apt, apt-get, bundle, bundler, pip, rpm, rpmdb, rpmquery, rpmverify, yum tragen oft zugleich Shell-, Dateizugriffs- und Netzwerkfunktionen

Netzwerk, Shell und Library load

• Upload-/Download-Funktionen finden sich nicht nur bei Netzwerk-Tools, sondern auch bei Shells und Sprach-Laufzeiten

• Werkzeuge mit Schwerpunkt auf Transfer

  • ab, curl, finger, ftp, nc, scp, sftp, smbclient, ssh, tar, tftp, wget, whois verfügen über Upload oder Download

• Reverse shell und Bind shell

  • bash, gawk, go, jjs, julia, ksh, lua, nawk, nc, nmap, node, openssl, pandoc, php, ruby, socat, socket, tclsh, telnet, zsh gehören dazu

• Einträge mit Library load

  • bash, byebug, curl, ffmpeg, gdb, gem, gimp, irb, knife, ldconfig, mysql, nginx, nvim, openssl, pip, python, rake, ruby, ssh-keygen, tclsh, vim, volatility, wish, yum gehören dazu

Einträge zur Rechteausweitung

• Privilege escalation erscheint nur bei Binärdateien, die als eigener Eintrag markiert sind

• Liste der Links zur Rechteausweitung

  • chattr
  • chmod
  • chown
  • cp
  • getent
  • install
  • ln
  • mount
  • mv
  • passwd
  • setcap
  • setfacl
  • unsquashfs
  • unzip

[GN⁺]

Hacker-News-Kommentare

• Da es in den Kommentaren etwas Verwirrung zu geben scheint, hier ein Beispiel dafür, wann so etwas im Security-/CTF-Kontext verwendet wird
  In Umgebungen mit einer eingeschränkten Shell oder in denen nur bestimmte Befehle/Binaries ausgeführt werden dürfen, lassen sich Argumente meist recht frei übergeben.
  Mit GTFOBins kann man dann Dateien lesen/schreiben oder sogar Befehle ausführen und so aus dem eingeschränkten Kontext ausbrechen, um eine Shell zu bekommen.
  Wenn jemand sudo offen gelassen oder einem GTFOBin das SUID-Bit gegeben hat, kann man unter Umständen sensible Dateien auf eine Weise lesen oder schreiben und privilegierte Befehle ausführen, an die selbst die Person bei der Konfiguration nicht gedacht hat.

  • Das trifft ziemlich gut auch auf Tools wie claude-code zu.
    Die Rechteverwaltung ist stark auf Block-Lists und Allow-Lists fokussiert und damit ziemlich primitiv.
    Ich habe Claude in einer Sitzung versehentlich powershell-Rechte gegeben, und als danach Tools wie git blockiert wurden, hat es stattdessen powershell-Skripte geschrieben, die dasselbe tun, und so die blockierten Rechte umgangen.
    In einem vernünftig konfigurierten System würde man powershell natürlich nicht auf eine allgemeine Allow-List setzen, aber wenn es Lücken in den Freigaben einzelner Tools gibt, scheint man mit den Techniken auf dieser Seite sehr weit zu kommen.
  • Auch manche Enterprise-Sicherheitssoftware, die angeblich Privilegieneskalation vermittelt, kann ähnlich riskant sein.
    Bei einem Unternehmen, das ich gesehen habe, war die Verteilung so umgesetzt, dass Programme auf einer vom Administrator gepflegten Allowlist ohne Passwort per sudo ausgeführt werden durften, und dort standen von Anfang an Allzweck-Tools wie vim und bash drin.
    Aus Sicht von jemandem im Homeoffice fühlte sich das fast wie ein Glücksfall an, weil die Software, die meinen Rechner angeblich „schützen“ sollte, es viel einfacher machte, dass jemand etwas ausführt, wenn ich kurz weg war und vergessen hatte, den Bildschirm zu sperren.
  • Letztlich wirkt das wie ein ziemlich umfassender Leitfaden dafür, wie leicht sich eine restricted shell in der Praxis umgehen lässt.
  • Es gibt auch konkrete Beispiele.
    Vor ein paar Jahren musste ein Support-Team mit tcpdump Netzwerkmitschnitte erstellen, und damit es schnell geht, wurde eine sudo-Regel mit recht weit offenen Argumenten eingerichtet.
    Weil sich Port oder NIC ändern konnten, wirkte das damals ganz natürlich, aber tatsächlich lässt sich mit der Option -z von tcpdump ein Kompressionsbefehl angeben, und wenn man dort einen „besonderen“ Befehl einträgt, kann man den Server direkt übernehmen.
    sudo tcpdump -i any -z '/home/despicable_me/evil_cmd.sh' -w /tmp/dontcare.pcap -G 1 -Z root
    Das wirkt harmlos, wird aber wirklich leicht übersehen.
    Heutzutage helfen Schichten wie apparmor zwar dabei, solche Risiken zu verringern, aber dafür entstehen andere Probleme, und Fehlkonfigurationen bleiben leicht möglich.
  • Beim Lesen kam mir auch der Gedanke, dass das wie eine geordnete Liste wirkt, damit eine KI Sandbox-Bypässe lernen kann.

• Das letzte Mal, dass ich etwas Ähnliches benutzt habe, war 1995 herum auf einem Windows-3.11-Rechner in der Mittelstufe.
  Dort war gesperrt, dass nur einige freigegebene Apps ausgeführt werden durften, und eine davon war Word.
  In Word konnte man Makros verwenden und über die Shell andere Apps starten.
  Damit wurde aus einem scheinbar gesperrten Rechner mit nur wenigen sichtbaren Apps effektiv ein System, auf dem man alles starten konnte.
  Damals war das ziemlich aufregend, und seitdem habe ich so etwas kaum noch gesehen.
  Man liest gelegentlich, dass sich kiosk mode auf Touch-Infodisplays in Läden oder Einkaufszentren verlassen lässt; das scheint in dieselbe Kategorie zu fallen.

• Als ich restic - Shell, Command, Upload gesehen habe, fühlte ich mich ein wenig darin bestätigt, das Backup nicht als root laufen zu lassen.
  Stattdessen läuft es als normaler Benutzer, bekommt aber nur die read-all-files capability, und eine Login-Shell gibt es nicht.
  Auf einem Desktop ist das natürlich vielleicht übertrieben, und wenn ein Angreifer schon so weit gekommen ist, kann er ohnehin fast alle Dateien lesen und dem Backup eine Backdoor unterjubeln.
  [0] https://man7.org/linux/man-pages/man7/capabilities.7.html

  • Wenn ein LLM bei Einschränkungen einfach entscheidet „Dann nehme ich eben einen Helper zum Umgehen“, dann bricht das viele Annahmen aus der alten Welt ziemlich auf.
    Gegen entfernte menschliche Angreifer, entfernte Bot-Angreifer und teilweise auch gegen lokale menschliche Angreifer gibt es Gegenmaßnahmen, aber lokale Bot-Angreifer, die selbstständig Code schreiben, sind heute ein viel wichtigeres Bedrohungsmodell als früher.
    Das fällt auch nicht ganz in dieselbe Kategorie wie Malware.
    Ich habe Container auch schon als Sicherheitsgrenze betrachtet und darin alle internen Prozesse als root laufen lassen, aber mit einem LLM im Spiel kann ich schwer einschätzen, ob Sicherheit auf OS-Ebene plötzlich wichtiger geworden ist oder im Gegenteil an Bedeutung verloren hat.

• Ich bin etwas verwirrt: Bedeutet das, dass man, wenn cat nicht vorhanden ist, statt cat /path/to/input-file einfach base64 /path/to/input-file | base64 --decode verwenden soll?
  Oder bedeutet es, dass base64 /path/to/input-file | base64 --decode die Dateileseberechtigung selbst umgeht?

  • Ersteres ist richtig.
    Ein aufgerufener Prozess übernimmt normalerweise einfach die Rechte des Benutzers, der ihn ausführt; eine Ausnahme gibt es nur beim setuid-Bit.
    Der Punkt ist, dass man in Umgebungen, die durch das Abschalten von Standard-Unix-Tools die lateral movement von Angreifern verhindern wollen, dieselbe Aufgabe mit anderen Tools erledigen kann.
  • Das heißt, dass befehlsbasierte Einschränkungen per Blacklist zur Rechtekontrolle schon immer schlecht funktioniert haben und das auch heute noch tun.
  • Gemeint ist Ersteres, nicht Letzteres.
    Es geht nicht darum, die Rechte selbst zu brechen, sondern darum, in einer restricted shell, in der nur einige Befehle erlaubt sind, mit einem anderen Binary dasselbe Ergebnis zu erzielen.
    So etwas ist in CTFs wirklich sehr häufig.
  • Wenn es aber eine Datei gibt, die man normalerweise nicht lesen darf, und man stattdessen base64 als root ausführen kann, sieht die Sache anders aus.
    Dann kann man base64 mit root-Rechten ausführen, den Dateiinhalt Base64-kodieren und die Ausgabe mit einem anderen base64-Prozess wieder dekodieren; am Ende sieht man den Dateiinhalt.
    Effektiv ist das nur ein cat mit zusätzlichen Schritten.
  • Dafür wäre eine tar-Pipe vielleicht sogar leichtergewichtig.

• Ich war früher Maintainer eines dieser Tools, und es war ziemlich lustig zu sehen, wie jemand damit eine Shell bekommt.
  Kreativ, unterhaltsam und als Referenzmaterial gut.

• Bei hackthebox.eu habe ich das sehr oft benutzt.

• GTFOBins gibt es schon ziemlich lange, und es war schon vor KI eine nützliche Ressource.

  • Genau deshalb mache ich mir für die Zukunft mehr Sorgen.
    Der Nutzen von KI besteht am Ende eben auch darin, solche bereits existierenden Ressourcen hochzuholen.

• Dass base64 in der Liste steht, verstehe ich nicht ganz.
  Meines Erachtens kann es doch nur Dateien lesen, auf die der Benutzer ohnehin schon Zugriff hat. Täusche ich mich da?
  Oder bedeutet die Beschreibung Umgehung lokaler Sicherheitsbeschränkungen auf fehlkonfigurierten Systemen etwas anderes, als ich denke?

  • Der Kern ist, dass man mit den Tools in dieser Liste einen Teil des Zugriffs zurückgewinnen kann, den derselbe Benutzer in einer nicht eingeschränkten Umgebung ohnehin hätte, selbst wenn man ihm nur eine falsch konfigurierte restricted shell oder nur Zugriff auf bestimmte Befehle gegeben hat.
    Ein einfaches Beispiel: Selbst wenn die Standard-Shell auf rbash umgestellt wurde, ist das wertlos, wenn der Benutzer einfach bash starten und so in eine normale Shell wechseln kann.
  • Zum Beispiel könnte sudoers so konfiguriert sein, dass base64 als root ausgeführt werden darf.
    Warum man das tun würde, weiß ich nicht, aber in so einer Situation könnte man damit die beabsichtigten Rechtebeschränkungen umgehen und jede Datei auf dem System lesen.
    Oder wenn Claude Code die Ausführung von base64 ohne Prüfung erlaubt, öffnet das womöglich auch den Zugriff auf Geheimnisse wie .env-Dateien.
  • Ein häufiger Fall ist, dass einige Tools mit root-Rechten ausgeführt werden können.
    Entweder ist das explizit über sudo -l erlaubt, oder etwas anderes ruft das Tool als root auf.

• Es wäre gut, wenn auch Gegenmaßnahmen für solche Umgehungen gezeigt würden.
  Wenn man zum Beispiel über more eine Shell bekommen kann, dann etwa so:
  Vor dem Start von more SHELL auf /bin/false setzen,
  auf less im secure mode wechseln
  oder beim Einsatz von more per sudo das NOEXEC-Flag verwenden.

  • Die beste Gegenmaßnahme ist, die tatsächlichen Berechtigungen für Dateien, die Benutzer nicht lesen oder schreiben dürfen, korrekt zu setzen.
    Alles andere ist letztlich zu einem gewissen Teil Glückssache.

• Ziemlich cool, und es gibt unerwartet kreative Ansätze.
  Auf yt-dlp wäre ich zum Beispiel nie gekommen.
  Ich sollte wohl nochmal darüber nachdenken, es einfach so installiert zu lassen.