Connexion
Benjamin Code , le développeur préféré de votre développeur préféré, a reçu ce week-end un e-mail d'achat bidon avec le mot pentester dedans. En grattant un petit peu, il a découvert que quelqu'un s'amusait à trifouiller l'un de ses SaaS sans le prévenir.
Visiblement, c'est un autre créateur, Melvyn (melvynx), qui lui propose des formations autour de l'IA, qui pour les besoins d'une vidéo a fait tourner Kimi K3 en mode "hack" pour poutrer certains sites et montrer, vidéo à l'appui, que l'IA trouvait les failles toute seule.
Depuis, X s'écharpe. D'un côté, ceux pour qui la faille est corrigée et tout le monde y gagne, zéro dégât. De l'autre, ceux qui parlent d'accès illégal, pur et simple.
Alors qu'en est-il exactement ?
Eh bien, parlons de la loi d'abord, parce qu'en France, elle est limpide. L'article 323-1 du Code pénal punit "le fait d'accéder ou de se maintenir, frauduleusement" dans un système informatique de "trois ans d'emprisonnement et de 100 000 € d'amende". Créer un faux compte, simuler un paiement avec de faux numéros de CB, toucher aux données, ça aggrave les choses et on passe rapidement à cinq ans et 150 000 € (article 323-3).
Pour moi, l'argument du "il n'a rien cassé" ne tient pas une seconde en droit. Dans l'affaire Bluetouff, la Cour de cassation a validé une condamnation pour maintien frauduleux alors que les fichiers étaient accessibles sans mot de passe, tout simplement parce que Bluetouff avait continué en sachant l'accès anormal. Je trouve que ce qui est arrivé à Bluetouff, c'était abusé, mais peu importe mon avis, cela montre bien qu'aux yeux de la loi, zéro dégât ne veut pas dire qu'il n'y a pas d'infraction.
Ce qui fait basculer un pentest légal en délit, ce n'est ni la compétence, ni la bonne intention de la personne derrière, ni même ce que j'en pense. C'est UNE seule chose : L'autorisation préalable du propriétaire du système. Et je ne crois pas que Benjamin Code pratique le bug bounty sur ses systèmes...
Si on parle d'un point de vue hacking éthique, voire tout simplement en matière de nétiquette, la règle (et le bon sens, et la courtoisie) c'est d'abord d'avoir l'accord écrit avant de faire le test, et puis bien sûr de signaler la faille en privé à l'éditeur, tout en lui laissant assez de temps pour la corriger avant de communiquer dessus publiquement.
Par exemple, un bug bounty, c'est ça... C'est un périmètre défini, un canal de signalement, une protection pour le chercheur qui reste bien dans ce cadre. En dehors, il n'y a aucune protection. Et le dispositif français qui couvre les lanceurs d'alerte (article L2321-4 du Code de la défense) ne protège que le signalement de bonne foi à l'ANSSI, jamais l'intrusion elle-même.
Melvyn a reconnu lui-même juste après son "exploit" que "certains tests sur des SaaS tiers n'ont pas été précédés d'une autorisation écrite". Tu m'étonnes...
Alors les kikoulol de X.com peuvent bien jouer les spécialistes en long en large ou en travers, ça ne change rien. Kimi K3 ou pas, dégâts ou pas, tester le système d'un autre sans son feu vert, même avec une IA autonome, ça a un nom dans le Code pénal...
Maintenant, je ne pense pas que ça ait besoin d'aller plus loin que ça... Dans un monde idéal, ce qui serait super, c'est que Melvyn fasse des excuses publiques à Benjamin Code et aux autres créateurs de SaaS qu'il a "poutrés", et puis qu'il évite de refaire ce genre de conneries dans le futur.
Source : le billet de Melvyn sur Codelynx
478 binaires Unix peuvent servir à devenir root sur un système mal configuré.
C'est ce que recense GTFOBins , le projet open source monté par Emilio Pinna et Andrea Cardaci, qui est devenu LE bookmark obligatoire de tout pentester Linux.
Ce ne sont pas des exploits, hein, mais juste des fonctions parfaitement légitimes de programmes installés partout, et qui dans le bon contexte (genre un bit SUID oublié, qui fait tourner un binaire avec les droits du propriétaire, souvent root) permettent de spawner un shell, lire un fichier protégé, ou grimper d'un cran dans la hiérarchie des privilèges. Petit rappel quand même, faut déjà avoir un pied sur la machine, ce n'est pas une porte d'entrée magique depuis Internet.
Une fois sur leur site, vous tapez le nom d'un binaire dans le moteur de filtre (ou vous cliquez sur une fonction), et hop, vous tombez sur les commandes exactes à recopier-coller, et c'est plié en moins de dix secondes.
Par exemple, si votre cible a un sudo find sans mot de passe, le site vous donne sur un plateau d'argent sudo find . -exec /bin/sh \; -quit.
Un mawk qui tourne en SUID root ? Direct, mawk 'BEGIN {system("/bin/sh")}' et bonjour le shell privilégié. Un vim mal configuré (compilé avec le support Python ou Lua, ce qui est le cas dans la plupart des distros desktop) ? La page documente comment l'utiliser via :py ou :lua pour exécuter du code arbitraire et retomber sur ses pattes.
C'est donc la fin des recherches désespérées sur StackOverflow à 3h du matin pendant un CTF...
La philosophie de ce projet est claire... on ne casse rien, on détourne juste l'usage prévu. Le hic, c'est que la frontière entre détournement et exploitation est mince quand un sudoers mal écrit donne accès à un binaire trop puissant.
Les 478 binaires sont rangés selon 11 fonctions et 4 contextes d'exécution. Côté fonctions, vous avez : Shell (228 binaires permettent de spawner un shell, oui presque la moitié du catalogue), File-read (199), File-write (84), Inherit (71), Upload (34), Download (32), Command (30), Reverse-shell (21), Privilege-escalation (14), Library-load (11), et Bind-shell (7). Côté contextes : Unprivileged, Sudo, SUID, et Capabilities.
Et sur la page d'un binaire, chaque case du tableau vous dit super clairement "voilà comment t'en sors selon ce que tu as sous la main".
Les champions toutes catégories ce sont les langages interprétés et les shells eux-mêmes. zsh, socat, ruby, python, php, node, lua plus bash, tous cumulent 7 fonctions différentes chacun. C'est logique, dès que vous avez un interpréteur sous la main vous pouvez faire à peu près tout (lire, écrire, exécuter, ouvrir une socket).
D'ailleurs c'est pour ça que les sysadmins paranoïaques tirent une tête bizarre quand on leur dit qu'on a installé Python sur un serveur de prod sans cas d'usage explicite. Pfff... je les comprends, un Python qui traîne sur un serveur Debian avec un sudo NOPASSWD au-dessus, c'est game over en trois lignes.
Y'a un autre détail que je trouve cool également, c'est l'intégration
MITRE ATT&CK
. Chaque fonction du site est mappée à une technique du framework officiel, accessible via /mitre.json.
Donc pour les blue teams qui veulent justifier une règle de détection en réunion, c'est tout simplement cadeau !! Et pour ceux qui automatisent leurs scans, l'API JSON complète est dispo sur /api.json, du coup vous pouvez parser les 478 entrées avec un jq ou un petit script Python pour générer des règles de monitoring custom.
Bref, GTFOBins c'est aussi un cadeau pour les défenseurs, à condition de retourner la logique du projet. Voilà, ça vaut le coup d'y passer dix minutes par mois sur un audit.
Pour les Windowsiens qui se sentent oubliés, sachez que l'équivalent existe et s'appelle LOLBAS (Living Off The Land Binaries And Scripts), bien suivi par les analystes Windows depuis 2018. Même philosophie, même format, même utilité, juste appliqué aux exécutables Microsoft signés que Windows installe par défaut.
Les deux projets se citent mutuellement et forment ensemble la cartographie communautaire des techniques de Living Off The Land cross-OS. Si vous bossez sur les deux côtés du fossé, gardez les deux onglets ouverts en permanence ^^ !
Maintenant si l'angle élévation de privilèges via shell restreint vous intéresse, j'avais déjà couvert une vieille faille sudo qui permettait carrément de sortir d'un chroot , et plus largement la bibliothèque Payloads All The Things qui complète bien GTFOBins sur tout ce qui est exploitation web et post-exploitation. Les deux projets sont complémentaires, GTFOBins se concentre sur les binaires Unix et les abus locaux de fonctionnalités légitimes (shells, transferts, lectures, élévation conditionnelle), PayloadsAllTheThings ratisse plus large côté exploitation web.
Côté admin, le réflexe utile, à vrai dire c'est de lister vos binaires SUID avec find / -perm -4000 -type f 2>/dev/null, vérifier /etc/sudoers plus les fichiers /etc/sudoers.d/* avec sudo -l, puis de passer chaque candidat dans le filtre GTFOBins.
Si une entrée matche, c'est qu'il y a une fuite potentielle à boucher. Attention quand même, l'absence dans GTFOBins ne valide pas une règle sudo ou un SUID custom (wildcards, variables d'env, paths inscriptibles peuvent toujours créer un chemin d'évasion). Bref, c'est à faire avant de filer le moindre sudo NOPASSWD à quelqu'un !
Lateo.net - Flux RSS en pagaille (pour en ajouter : @ moi)