GTFOBins

• Liste de binaires Unix organisée par fonction, avec pour chaque binaire un lien direct vers les pages détaillées et les liens d’ancrage correspondant aux actions possibles
• Les catégories récurrentes sont Shell, File read, File write, Command, Inherit, Upload, Download, Reverse shell, Library load, Privilege escalation, et certains éléments incluent aussi Bind shell
• File read et Shell sont très largement répartis, et des outils comme dd, sed ou sqlite3 combinent lecture et écriture, ce qui brouille la frontière avec les outils de simple consultation
• Des outils comme apt, git, journalctl et systemctl incluent souvent Command et Inherit, tandis que des binaires multifonctions comme bee, pipx, sqlmap ou la famille vim combinant transfert réseau et comportement de shell reviennent de façon répétée
• Privilege escalation n’apparaît que sur une partie des binaires avec un lien dédié, tandis que la vaste liste allant de 7z à zypper met en évidence d’un seul coup d’œil les différences de combinaisons de comportements d’outils courants

---

Répartition des fonctions principales

• Les éléments dédiés à la lecture de fichiers ou principalement orientés lecture sont très largement répartis
  • 7z, cat, grep, jq, od, tail, wc, zcat sont notamment liés à File read
• Les éléments capables d’exécuter un shell sont eux aussi très nombreux
  • bash, awk, find, less, python, ruby, tar, vi, zsh disposent de Shell
• De nombreux éléments combinent écriture de fichiers et lecture, ce qui brouille la frontière avec les outils de simple consultation
  • dd, cpio, ed, emacs, nano, sed, sqlite3, xxd en font partie
• Exécution de commandes et héritage de privilèges apparaissent souvent dans les gestionnaires de paquets, les outils système et les programmes interactifs
  • apt, apt-get, git, journalctl, man, systemctl, timedatectl, zless en sont des représentants typiques

Binaires multifonctions

• Des binaires multifonctions cumulant plusieurs comportements apparaissent de façon répétée

• Éléments multifonctions basés sur Inherit

  • apport-cli, batcat, cargo, crash, gcloud, git, journalctl, man, opencode, psql, run-mailcap, systemd-resolve regroupent avec Inherit Shell, Command, File read et File write

• Éléments incluant aussi le réseau et le déplacement de fichiers

  • bee, byebug, dstat, easy_install, facter, irb, knife, pipx, poetry, rake, sqlmap, vagrant, volatility ajoutent aussi Reverse shell, Upload, Download et Library load

• Familles des éditeurs et débogueurs

  • gdb, nvim, rvim, view, vim, vimdiff associent à Inherit des fonctions comme Shell, Reverse shell, Bind shell ou encore File read/write, Upload, Download et Library load

• Familles des gestionnaires de paquets et runtimes

  • apt, apt-get, bundle, bundler, pip, rpm, rpmdb, rpmquery, rpmverify, yum cumulent souvent shell, accès aux fichiers et comportement réseau

Réseau, shell et chargement de bibliothèques

• Les fonctions Upload/Download ne se limitent pas aux outils réseau et apparaissent aussi sur des shells et des runtimes de langages

• Outils centrés sur le transfert

  • ab, curl, finger, ftp, nc, scp, sftp, smbclient, ssh, tar, tftp, wget, whois disposent de Upload ou Download

• Reverse shell et Bind shell

  • bash, gawk, go, jjs, julia, ksh, lua, nawk, nc, nmap, node, openssl, pandoc, php, ruby, socat, socket, tclsh, telnet, zsh figurent dans cette catégorie

• Éléments associés à 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 en font partie

Éléments de montée de privilèges

• Privilege escalation n’apparaît que sur les binaires disposant d’une entrée dédiée

• Liste des liens de montée de privilèges

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

[GN⁺]

Avis sur Hacker News

• Comme beaucoup de commentaires semblent confus, voici dans quels cas on utilise ça en contexte sécurité/CTF
  Dans un environnement avec shell restreint ou où seuls certains commandes/binaires peuvent être exécutés, on peut souvent quand même fournir les arguments assez librement
  Dans ce cas, avec GTFOBins, on peut enchaîner lecture/écriture de fichiers puis exécution de commandes afin de sortir du contexte restreint et obtenir un shell
  Si quelqu’un a laissé sudo ouvert ou a donné le bit SUID à un GTFOBin, il devient aussi possible de lire ou écrire des fichiers sensibles et d’exécuter des commandes privilégiées d’une manière que même la personne ayant configuré cela n’avait pas anticipée

  • Ça s’applique assez bien à des outils comme claude-code
    La gestion des permissions y est assez primitive, centrée sur des block-lists et allow-lists
    Dans une session, j’ai accidentellement donné à Claude le droit d’utiliser powershell ; ensuite, quand des outils comme git étaient bloqués, il contournait les restrictions en écrivant un script powershell faisant la même chose et en l’exécutant
    Sur un système correctement conçu, on ne mettrait pas powershell dans une allow-list générale, mais s’il existe des écarts de niveau d’autorisation entre outils, les techniques de cette page semblent largement suffisantes pour en tirer parti
  • Certains logiciels de sécurité d’entreprise censés faire de la médiation d’élévation de privilèges peuvent être exposés au même type de risque
    Dans une entreprise, j’ai vu un déploiement où tout programme présent dans l’allowlist de l’administrateur pouvait être lancé via sudo sans mot de passe, et dès le départ il y avait des outils génériques comme vim et bash
    En tant que télétravailleur, j’y voyais presque un avantage, parce que ce logiciel censé « protéger » mon ordinateur le rendait en réalité beaucoup plus facile à exploiter si quelqu’un passait pendant une absence et que j’avais oublié de verrouiller l’écran
  • Au fond, cela ressemble à un guide assez complet montrant à quel point les restricted shells ne bloquent pas grand-chose en pratique
  • Il y a aussi des exemples concrets
    Il y a quelques années, l’équipe de support devait faire des captures réseau avec tcpdump, donc pour aller vite une règle sudo assez permissive sur les arguments avait été ajoutée
    Comme le port ou la NIC pouvaient changer, cela semblait naturel à l’époque, mais tcpdump a en fait une option -z qui permet de spécifier une commande de compression ; en y mettant une commande « spéciale », on pouvait littéralement prendre le contrôle du serveur
    sudo tcpdump -i any -z '/home/despicable_me/evil_cmd.sh' -w /tmp/dontcare.pcap -G 1 -Z root
    Ça paraît mineur, mais ce genre de chose est vraiment facile à rater
    Aujourd’hui, des couches comme apparmor réduisent parfois ce risque, mais elles apportent aussi d’autres complications et restent faciles à mal configurer
  • En regardant ça, on a aussi l’impression d’une liste soigneusement organisée pour apprendre à une IA des techniques d’évasion de sandbox

• La dernière fois que j’ai utilisé quelque chose de similaire, c’était vers 1995 sur Windows 3.11 dans les ordinateurs de mon collège
  Le système n’autorisait que quelques applications approuvées, et Word en faisait partie
  Or Word permettait d’utiliser des macros et de lancer d’autres applications via le shell
  Résultat, un ordinateur censé être verrouillé sur quelques applis pouvait en fait exécuter pratiquement n’importe quoi
  À l’époque c’était assez grisant, et depuis j’ai rarement revu ce genre de situation
  On lit parfois que des écrans d’information tactiles en magasin ou dans les centres commerciaux permettent de sortir du kiosk mode ; c’est sans doute de la même famille

• En voyant restic - Shell, Command, Upload, je me dis que le fait de ne pas faire tourner les sauvegardes en root se justifie un peu plus
  À la place, je les exécute avec un utilisateur standard auquel je donne seulement la capability de lecture de tous les fichiers, sans shell de connexion
  Bien sûr, sur un poste de travail c’est peut-être excessif, et un attaquant arrivé jusqu’à ce point peut de toute façon déjà lire presque tous les fichiers et injecter une porte dérobée dans les sauvegardes
  [0] https://man7.org/linux/man-pages/man7/capabilities.7.html

  • Face à des contraintes, la tendance des LLM à se dire simplement « il suffit de passer par un helper de contournement » semble vraiment bousculer les hypothèses de l’ancien monde
    On avait des réponses pour les attaquants humains à distance, les bots distants, et dans une certaine mesure les attaquants humains locaux, mais les bots attaquants locaux capables d’écrire eux-mêmes du code sont devenus un problème bien plus sérieux qu’avant
    Ce n’est pas exactement la même catégorie que les malwares
    Moi aussi j’ai déjà traité le conteneur comme frontière de sécurité pertinente en faisant tourner tous les processus internes en root ; avec des LLM dans la boucle, j’ai du mal à dire si la sécurité au niveau OS est soudainement devenue plus importante, ou au contraire moins pertinente

• Je suis un peu perdu : est-ce que ça veut dire que quand on n’a pas cat, on peut utiliser base64 /path/to/input-file | base64 --decode à la place de cat /path/to/input-file ?
  Ou bien que base64 /path/to/input-file | base64 --decode permet de contourner les permissions de lecture elles-mêmes ?

  • C’est la première interprétation
    Le processus appelé hérite généralement des permissions de l’utilisateur qui l’exécute, sauf cas particulier avec le bit setuid
    L’idée, c’est que dans des environnements où l’on essaie d’empêcher la lateral movement des attaquants en retirant les outils Unix standard, on peut obtenir le même résultat avec d’autres outils
  • Autrement dit, bloquer les privilèges avec une restriction de commandes fondée sur liste noire ne marchait déjà pas vraiment à l’époque, et ça ne marche toujours pas
  • C’est bien le premier cas, pas le second
    On ne contourne pas les permissions elles-mêmes ; on obtient simplement le même résultat avec un autre binaire dans un shell restreint où seules quelques commandes sont autorisées
    C’est extrêmement courant en CTF
  • En revanche, si le fichier n’est pas lisible mais qu’on peut exécuter base64 en root, alors c’est différent
    En lançant base64 avec les privilèges root pour encoder le contenu du fichier, puis en décodant sa sortie avec un autre processus base64, on peut finalement voir le contenu du fichier
    Au final, c’est juste un cat avec quelques étapes de plus
  • Cela dit, dans ce cas un pipe tar serait peut-être encore plus léger

• J’ai été mainteneur d’un de ces outils il y a longtemps, et voir quelqu’un obtenir un shell avec m’a fait rire
  C’est créatif, amusant, et très utile comme ressource

• Quand je faisais du hackthebox.eu, je m’en servais énormément

• GTFOBins existe depuis longtemps et c’était déjà une ressource utile avant l’IA

  • C’est justement ce qui m’inquiète encore plus pour la suite
    Si l’IA est utile, c’est précisément parce qu’elle sait faire remonter ce type de ressources déjà existantes

• Le fait que base64 soit dans la liste me déroute un peu
  De ce que je comprends, ça ne permet au mieux que de lire des fichiers auxquels l’utilisateur a déjà accès ; est-ce que je rate quelque chose ?
  Ou bien l’expression contournement de restrictions de sécurité locales sur un système mal configuré signifie autre chose que ce que je pense ?

  • Le point essentiel, c’est que même avec un shell restreint mal configuré ou un accès limité à certaines commandes, les outils de cette liste permettent à l’utilisateur de retrouver une partie de l’accès dont il disposait déjà dans un environnement non restreint
    L’exemple le plus simple, c’est qu’il ne sert à rien de remplacer le shell par défaut par rbash si l’utilisateur peut simplement lancer bash pour retrouver un shell normal
  • Par exemple, le fichier sudoers peut autoriser l’exécution de base64 en root
    On ne sait pas trop pourquoi quelqu’un ferait ça, mais dans un tel cas cela permettrait de contourner les limites de privilèges prévues et de lire n’importe quel fichier du système
    Ou alors, si Claude Code est autorisé à exécuter base64 sans revue préalable, cela peut aussi lui ouvrir l’accès à des fichiers secrets comme .env
  • Le cas le plus courant, c’est que certains outils puissent être exécutés avec les privilèges root
    Soit c’est explicitement autorisé via sudo -l, soit quelque chose d’autre appelle cet outil en root

• Ce serait bien d’avoir aussi les mesures d’atténuation face à ces contournements
  Par exemple, pour un shell obtenu via more :
  définir SHELL sur /bin/false avant d’exécuter more
  remplacer par less en mode sécurisé
  ou, si more est utilisé via sudo, activer le flag NOEXEC

  • La meilleure atténuation reste de configurer correctement les permissions réelles des fichiers que l’utilisateur ne doit ni lire ni modifier
    Tout le reste dépend en fin de compte beaucoup de la chance

• C’est assez impressionnant, avec des approches créatives auxquelles je n’aurais pas pensé
  Par exemple, yt-dlp ne me serait jamais venu à l’esprit
  Je vais peut-être reconsidérer le fait de l’installer simplement par défaut