Vous avez un serveur, un NAS, quelques services qui tournent chez vous ou au boulot, et vous vous demandez si tout ça est bien sécurisé ? Alors plutôt que d'attendre qu'un petit malin vous le fasse savoir de manière désagréable, autant prendre les devants avec un scanner de vulnérabilités.

Attention : si vous scannez le réseau de votre boulot, demandez toujours une autorisation écrite avant car scanner sans permission, c'est illégal et ça peut vous coûter cher. Et ne comptez pas sur moi pour vous apporter des oranges en prison.

OpenVAS (Open Vulnerability Assessment Scanner), c'est l'un des scanners open source les plus connus, maintenu par Greenbone. Une fois en place sur votre réseau, il scanne vos services exposés et vous balance un rapport avec ce qui craint : Ports ouverts, services mal configurés, failles connues, certificats expirés... De quoi repérer une bonne partie de ce qu'un attaquant pourrait exploiter.

L'interface principale d'OpenVAS

Ce qui est cool, c'est que vous restez en mode défensif. C'est pas un outil de pentest offensif ou de hacking pur et dur mais juste un audit de votre propre infra pour savoir où vous en êtes. Et ça tourne avec un feed de vulnérabilités (le Greenbone Community Feed) qui est régulièrement mis à jour, ce qui permet de détecter les failles récentes.

Pour l'installer, une des méthodes c'est de passer par Docker. Greenbone fournit une stack complète avec docker-compose. Après vous cherchez plutôt à analyser spécifiquement vos images de conteneurs, Grype pourrait aussi vous intéresser .

Pour OpenVAS, vous créez un répertoire, vous téléchargez leur fichier de config (jetez toujours un œil dedans avant de l'exécuter, c'est une bonne pratique), et hop :

mkdir -p ~/greenbone-community-container
cd ~/greenbone-community-container
curl -f -O -L https://greenbone.github.io/docs/latest/_static/docker-compose.yml
docker compose pull
docker compose up -d

L'assistant de configuration initiale

Après ça, vous accédez à l'interface web via http://localhost:9392.

Et pour le login, attention, car sur les versions récentes du conteneur communautaire, le mot de passe admin est généré aléatoirement au premier démarrage. Il faut donc aller voir les logs pour le récupérer (docker compose logs -f). Si ça ne marche pas, tentez le classique admin/admin, mais changez-le direct.

La première synchro des feeds peut prendre un moment, le temps que la base de vulnérabilités se télécharge. Vous avez le temps d'aller vous faire un café, c'est pas instantané.

Niveau config machine, la documentation recommande au moins 2 CPU et 4 Go de RAM pour que ça tourne, mais pour scanner un réseau un peu costaud, doublez ça (4 CPU / 8 Go) pour être à l'aise. Et une fois connecté, direction la section scans pour créer une cible avec votre IP ou plage d'adresses. Ensuite vous pouvez lancer un scan avec le profil de votre choix :

Le mode "Discovery" se contente de lister les services et ports ouverts tandis que le mode "Full and Fast" lance une batterie complète de tests de vulnérabilités. Il est conçu pour être "safe" (ne pas planter les services), mais le risque zéro n'existe pas en réseau donc évitez de scanner votre prod en pleine journée sans prévenir.

Les résultats arrivent sous forme de rapport avec un score de criticité comme ça vous avez le détail de ce qui pose problème et souvent des pistes pour corriger. Genre si vous avez un service SSH avec une config un peu lâche ou un serveur web trop bavard, le rapport vous le dira.

Par contre, c'est vrai que l'interface est assez austère comparée à des solutions commerciales comme Nessus mais c'est gratuit, c'est open source, et ça fait le taf pour un audit interne. La version Community a quand même quelques limitations (feed communautaire vs feed entreprise, support, etc.), mais pour surveiller son infra perso ou sa PME, c'est déjà très puissant.

Du coup, si vous voulez savoir ce qui traîne sur votre réseau avant que quelqu'un d'autre le découvre, OpenVAS est un excellent point de départ. Et c'est toujours mieux de découvrir ses failles soi-même que de les lire dans un mail de rançon... enfin, je pense ^^.

A découvrir ici !

Si vous utilisez GitHub Copilot ou ChatGPT pour coder plus vite, voici une nouvelle qui va peut-être vous refroidir un peu. Une fintech a découvert que des attaquants avaient extrait des données clients via un endpoint API qui n'était documenté nulle part. Personne dans l'équipe ne se souvenait l'avoir créé et après 3 semaines d'enquête, le verdict est tombé : c'est Copilot qui l'avait généré pendant une session de code nocturne.

Bienvenue dans l'ère des "phantom APIs" les amis !

J'avoue que le concept m'a fait marrer car on parle quand même d'endpoints qui existent en production mais dont personne n'a connaissance. Ahahaha... y'a pas de documentation, pas de tests, pas de validation de sécurité. C'est juste un peu de code généré par une IA qui a trouvé ça "logique" de créer un /api/v2/admin/debug-metrics qui balance du PII à quiconque tombe dessus par hasard.

J'ai vu le dernier rapport Veracode GenAI Code Security et les chiffres font un peu flipper c'est vrai ! Ils ont testé plus de 100 LLM sur 80 tâches de codage différentes, et le résultat fait mal puisque 45% du code généré par IA contient des vulnérabilités classées OWASP Top 10. En gros, presque une fois sur deux, votre assistant IA vous pond du code troué comme une passoire. Java est le grand gagnant avec 72% de taux d'échec, suivi par Python, JavaScript et C# qui tournent autour de 38-45%.

En effet, l'IA ne pense pas comme un dev qui s'est déjà fait hacker. Par exemple, quand un dev crée un endpoint, il réfléchit authentification, rate limiting, exposition de données, documentation. Alors que l'IA, elle, génère juste ce qui lui semble statistiquement logique vu son dataset d'entraînement, sans comprendre les implications sécurité ou les politiques de l'organisation.

D'ailleurs une autre étude Apiiro montre que les assistants IA ont multiplié par 10 les vulnérabilités introduites en seulement 6 mois dans les dépôts étudiés. Les chemins d'escalade de privilèges ont explosé tout comme les défauts architecturaux. Et le pire c'est que les développeurs qui utilisent l'IA exposent leurs credentials cloud (clés Azure, Storage Access Keys) deux fois plus souvent que les autres.

Y'a aussi le problème du "slopsquatting". Oui, encore un gros mot, je sais... En fait, l'IA peut vous recommander d'installer un package qui n'existe tout simplement pas. Genre elle hallucine un nom de librairie et un attaquant un peu moins con que les autres, peut enregistrer ce nom sur npm ou PyPI et y foutre du code malveillant.

Et là que ça devient vraiment problématique, c'est que les outils de sécurité traditionnels ne voient rien. L'analyse statique compare votre code à des specs documentées, sauf que les phantom APIs n'existent dans aucune spec. Les API gateways protègent les endpoints enregistrés mais laissent passer des routes non déclarées sans authentification.

Pour s'en sortir, certaines boîtes commencent donc à analyser le trafic en temps réel pour détecter les endpoints qui traînent. Y'a aussi l'audit de code spécifique IA pour repérer les patterns de génération algorithmique, et la comparaison continue entre les specs et ce qui tourne vraiment en production.

Bref, relisez votre code généré par IA comme si c'était un stagiaire collégien de 3e qui l'avait écrit, et si vous découvrez un endpoint bizarre dans votre base de code dont personne ne se souvient, y'a des chances que ce soit un "fantôme" laissé par votre copilote préféré...

Ce serait cool si on pouvait réunir les Avengers des LLMs pour les faire bosser ensemble sur de la recherche de faille de sécurité ? OpenAI, Anthropic, X.AI et Meta ensemble contre les forces du mal, c’est maintenant possible avec Deep Eye , un super scanner de vulnérabilités qui transforme les quatre IA rivales en équipe de pentesteurs. Vous allez voir, c’est assez génial !

Deep Eye, c’est donc un outil Python open source qui scanne les sites web et les API pour trouver des vulnérabilités. SQL injection, XSS, command injection, SSRF, path traversal, authentication bypass, au total y’a plus de 45 méthodes d’attaque automatisées. Vous lui indiquez une URL, et il teste tout en switchant entre les services d’IA selon le contexte.

Dans le contexte d’un pentest légitime, Deep Eye a même trouvé comment parler aux IA pour qu’elles acceptent de pondre du code un peu sensible. Et ça tombe bien car chaque IA a ses forces et ses faiblesses. GPT-4 par exemple excelle sur les payloads créatifs et les contournements de filtres. Claude lui est plus méthodique, et capable de mieux analyser le contexte et de génèrer des attaques adaptées au framework détecté. LLAMA en local quand à lui est rapide et ne coûte rien en appels API. Et Grok ? Bah il a le mérite d’être dispo même s’il est loin d’être le meilleur.

Deep Eye en tout cas est capable des les utiliser toutes selon la situation. Pour l’installer, ça se passe en 3 commandes :

Vous installez ça comme ceci :

git clone https://github.com/zakirkun/deep-eye.git
cd deep-eye

cd scripts
./install.ps1

chmod +x scripts/install.sh
cd scripts
./install.sh

python deep_eye.py -u https://example.com

Vous avez une caméra de surveillance connectée chez vous ? Du genre petite caméra Yi à 15 balles achetée sur AliExpress pour surveiller le salon ou le chat quand vous n’êtes pas là ? Alors tenez-vous bien parce qu’un chercheur a réussi à faire tourner DOOM dessus. Et sans toucher au firmware s’il vous plait ! Il a juste exploité le stream vidéo et quelques bugs bien sentis de l’appareil.

Luke M a publié son projet Yihaw sur GitHub et ça fait un peu peur car si quelqu’un peut hijacker le stream de votre caméra pour y balancer un FPS des années 90, il peut aussi faire pas mal d’autres trucs beaucoup moins rigolos.

Le hack est assez cool d’ailleurs car ces caméras Yi tournent sur un petit processeur ARM sous Linux. Elles ont donc une app mobile qui vous permet de voir le stream en temps réel et Luke M a trouvé plusieurs vulnérabilités dans la stack réseau de la caméra. Je vous passe les détails mais avec ces bugs, il peut injecter du code arbitraire sans modifier le firmware.

Il peut alors créer trois threads qui tournent en parallèle. Le premier récupère les frames YUV420p directement depuis le capteur de la caméra. Le deuxième convertit ça en h264. Le troisième, au lieu d’envoyer le flux vidéo normal, envoie DOOM. Du coup, vous ouvrez l’app Yi IoT sur votre smartphone et vous voyez le Doomguy buter des demons au lieu de voir votre salon. C’est rigolo, hein ?

Ces caméras Yi, il y en a des millions installées partout dans le monde. Bureaux, maisons, magasins…etc car elles sont pas chères, elles marchent plutôt bien, elles ont une app correcte, mais leur sécurité c’est une vraie passoire. C’est bourré de bugs qu’on trouve en une après-midi avec un fuzzer basique.

Luke M liste plusieurs exploits dans son repo GitHub et c’est un vrai buffet à volonté pour quelqu’un qui veut prendre le contrôle de ces caméras. Bien sûr ce serait illégal alors personne ne le fait, surtout parce que ça demande quand même un peu de boulot pour chaque modèle de caméra. Mais les outils existent, les vulnérabilités sont connues, et si un chercheur solo peut le faire pour s’amuser avec DOOM, imaginez ce qu’un botnet bien pensé pourrait faire.

Tous ces trucs qu’on a chez nous, qui tournent sur du Linux embarqué avec des stacks réseau écrites à l’arrache par des équipes chinoises sous-payées qui doivent sortir un produit tous les trois mois.

C’est beau non ?

Source (c’est du PDF)

Vous connaissez peut-être ces machines à mélanger les cartes qu’on trouve dans tous les casinos américains ?

Moi je ne savais même pas que ça existait, mais apparemment, le Deckmate 2, fabriqué par Shufflemaster (devenu depuis Light and Wonder), c’est la Rolls des shufflers. Un shuffler c’est pas un légume dégeu, c’est un mélangeur de cartes et on en trouve notamment au World Series of Poker (La biz à Patrick Bruel ^^), et dans tous les grands poker rooms de Vegas.

Cela permet d’automatiser le mélange pour accélérer le jeu et surtout éviter que ceux qui distribuent les cartes (les dealers) trichent avec de faux mélanges. La machine a même une caméra intégrée qui scanne chaque carte pour détecter si quelqu’un essaie de retirer un as ou d’ajouter un sept de pique.

En septembre 2022, il y a eu un scandale qui a secoué le monde du poker. Au Hustler Casino Live de Los Angeles, une joueuse relativement débutante, Robbi Jade Lew, gagne un pot de 269 000 dollars avec un call complètement fou. Elle avait valet-quatre dépareillés (un truc nul), et son adversaire Garrett Adelstein bluffait avec huit-sept. Techniquement, son call était correct, mais aucun joueur sensé n’aurait misé 109 000 dollars sur une main pareille sans savoir que l’adversaire bluffait… Le casino a donc lancé une enquête et conclu que le shuffler ne pouvait pas être compromis.

Mais même si ce n’était pas le cas pour cette affaire, est ce que c’est vrai ? Est ce qu’un Deckmate 2 peut être hacké ? Pour le chercheur en sécurité, Joseph Tartaro, ça s’est présenté comme un nouveau défi personnel !

Il a donc acheté un Deckmate 2 d’occasion avec deux collègues et a passé des mois à le démonter… pour finalement trouver quelques trucs intéressants, vous allez voir.

Il a découvert que la machine a un port USB accessible sous la table, là où les joueurs posent les genoux. Tartaro a donc créé un mini-ordinateur de la taille d’une clé USB qui, une fois branché, réécrit le firmware de la machine. La seule sécurité qu’il y a, c’est au démarrage, quand la machine vérifie que le code n’a pas changé en comparant son empreinte à une valeur connue.

C’est une simple comparaison de hash et le problème est que Tartaro peut modifier cette valeur de référence aussi… Du coup, le système de vérification contrôle que le code piraté correspond au hash piraté. C’est ballot ^^. Et une fois le firmware modifié, la machine continue à fonctionner normalement sauf qu’elle transmet maintenant l’ordre exact des 52 cartes via Bluetooth vers une app smartphone. Et comme la caméra interne de ce Deckmate 2 scanne déjà toutes les cartes pour détecter les fraudes, il suffit d’exploiter cette fonctionnalité.

Un journaliste de Wired a décidé de mettre ça en pratique dans des conditions réelles et vous allez voir, c’est sympa à voir.

Et si on pouvait pirater une IA non pas en la forçant, mais en la convainquant qu’elle est toujours du bon côté de la barrière ?? Ce serait pas un truc fun à faire ça quand même ? Hé bien c’est exactement ce que vient de faire une équipe de chercheurs en sécurité avec LatentBreak, une technique qui ressemble plus, je trouve, à de l’hypnose qu’à du véritable hacking.

Ainsi, plutôt que de bombarder ChatGPT ou Llama avec des prompts bizarres bourrés de caractères spéciaux pour les faire bugger (comme le font les anciennes techniques de jailbreak), LatentBreak joue sur la perception interne du modèle. L’IA croit en fait sincèrement répondre à une question innocente alors qu’elle génère du contenu dangereux. Un peu comme quand votre pervers narcissique préféré vous manipule pour vous faire croire que vous faites un truc bien et important alors que c’est de la merde et que ça vous enfonce encore plus…

Comme expliqué dans le document de recherche , les anciennes attaques comme GCG , GBDA ou AutoDAN ajoutaient des suffixes louches aux prompts, ce qui augmentait ce qu’on appelle la “perplexity”. La perplexity, c’est un indicateur de bizarrerie textuelle et cela, les filtres de sécurité sont maintenant capables de les détecter et de les bloquer.

LatentBreak contourne donc le problème en restant parfaitement naturel. L’algorithme remplace des mots par des synonymes, mais pas n’importe comment puisqu’il choisit chaque substitution pour déplacer la représentation interne du prompt vers les zones “sûres” du modèle, c’est à dire celles qui ne déclenchent aucune alarme. Le prompt reste alors fluide, compréhensible, inoffensif en apparence mais dans l’“inconscient” de l’IA, dans cet espace latent invisible où elle calcule ses réponses, le sens glisse subtilement vers quelque chose de complètement différent.

À chaque itération, l’algorithme de LatentBreak prend un mot du prompt et génère jusqu’à 20 alternatives via un autre modèle comme GPT-4o-mini et chaque variante est évaluée sur deux critères : est-ce qu’elle rapproche le vecteur interne du prompt d’un “centre de sécurité” dans l’espace latent, et est-ce que le sens global reste cohérent ?

La meilleure option est alors intégrée, et le nouveau prompt est testé sur le modèle cible. Si ça provoque une réponse normalement interdite, c’est gagné. Sinon, on recommence jusqu’à 30 fois de suite.

Et apparemment, les résultats sont impressionnants. Ils ont testé cette approche sur 13 modèles différents dont Llama-3, Mistral-7B, Gemma-7B, Vicuna-13B et Qwen-7B et LatentBreak affiche un taux de réussite entre 55 et 85% selon les cas. Les anciennes techniques tombant de toute façon à zéro face aux défenses modernes et tout ça en allongeant que de très peu la longueur du prompt.

LatentBreak passe d’ailleurs à travers des défenses réputées solides… Par exemple, R2D2 et Circuit Breakers, des systèmes qui analysent les signaux internes des neurones pour détecter les anomalies, se font totalement avoir parce qu’ils scannent le texte visible et les patterns de surface, mais pas la “pensée interne” du modèle.

Cette technique révèle quelque chose de fondamental à comprendre sur l’architecture des LLM modernes. Ces derniers ont une forme de dissonance cognitive qui est exploitable. Leur représentation interne ne correspond pas toujours à leur comportement affiché, et d’ailleurs les substitutions les plus efficaces se produisent près des dernières couches du modèle, là où la “décision” finale se forme. C’est à ce moment précis qu’on peut glisser le prompt dans une zone cognitive différente sans que les alarmes ne sonnent.

Bien sûr, LatentBreak nécessite un accès aux structures internes du modèle (donc pas de panique, ChatGPT ne va pas se faire pirater comme ça demain), ce qui limite son usage à des contextes de recherche ou aux modèles open source.

Le parallèle avec les techniques de social engineering qu’on connait est d’ailleurs frappant parce que quand vous manipulez quelqu’un, vous ne le forcez pas brutalement. Vous trouvez les bons mots, le bon contexte, vous lui donnez une perception qui correspond à ce que vous voulez… Bref, vous faites en sorte que la personne croie agir selon ses propres valeurs alors qu’elle fait exactement ce que vous voulez. Hé bien LatentBreak fait à peu près la même chose avec les IA en n’attaquant pas de front les protections, mais en les contournant en douceur en réécrivant la “mémoire de travail” du modèle.

Sympa non ?

Source

Tous les mardis soir, c’est la même chose dans le petit monde de la cybersécurité : Microsoft balance ses patches, et dès le mercredi matin, c’est la ruée vers l’or pour les experts sécu. Bienvenue dans l’univers déjanté de l’Exploit Wednesday, où des chercheurs du monde entier se transforment en cyber-archéologues pour y déterrer les vulnérabilités avant que les méchants ne s’en emparent afin de coder des exploits.

Et un nouvel outil vient de débarquer pour pimenter cette course folle : Diffrays .

Imaginez… il est 3h du matin, on est mercredi et pendant que vous dormez tranquillement, des milliers de chercheurs en sécurité sont déjà en train de comparer frénétiquement les binaires de Windows fraîchement patchés avec leurs versions vulnérables.

Pourquoi est-ce qu’ils font ça ? Hé bien c’est parce que chaque seconde compte. L’IA a réduit de 40% le temps nécessaire pour identifier une vulnérabilité à partir d’un patch et ce qui prenait des jours prend maintenant des heures, notamment aux cybercriminels, du coup, la course s’est transformée en sprint.

Et c’est là que Diffrays entre en scène. Cet outil, conçu par pwnfuzz, fait ce qu’on appelle du “patch diffing”. Pour les non-initiés, le patch diffing, c’est l’art de comparer deux versions d’un programme pour trouver ce qui a changé. Un peu comme comparer deux photos pour jouer au jeu des 7 différences, sauf que là, on cherche des bugs qui valent potentiellement des millions.

Pour cela, Diffrays utilise IDA Pro et sa nouvelle IDA Domain API pour extraire le pseudocode des fonctions et les comparer de manière structurée. Et ce n’est un vulgaire comparateur de texte…non… Diffrays génère en fait une base de données SQLite complète avec toutes les différences trouvées, et lance même un serveur web local pour naviguer dans les résultats. Vous tapez diffrays diff old.exe new.exe, puis diffrays server --db-path results.sqlite, et hop, vous avez une jolie interface web sur http://localhost:5555 pour explorer ces changements.

Grâce à cet outil, chacun peut savoir exactement comment Microsoft corrige ses bugs. Prenez par exemple l’analyse du driver Clfs.sys montrée dans la documentation de Diffrays . Les chercheurs ont téléchargé deux versions du driver. La première vulnérable (10.0.22621.5037) et la seconde patchée (10.0.22621.5189) puis ont laissé Diffrays faire son travail… Et en quelques minutes, l’outil a identifié exactement quelles fonctions avaient été modifiées et comment.

Évidemment, Diffrays n’est pas seul sur ce marché juteux. Google a son BinDiff , il y a aussi Diaphora, et maintenant même des outils boostés à l’IA comme DeepDiff qui convertissent le code en “embeddings” (des représentations mathématiques) pour trouver des similarités. Mais Diffrays a un avantage, il est open source, gratuit, et surtout, il est conçu spécifiquement pour la recherche. Pas de conneries marketing, juste du code qui fait le taf.

D’ici 2026 , les experts prédisent que le patch diffing assisté par IA sera la norme dans toutes les red teams et programmes de bug bounty. On parle même de plateformes de diffing en temps réel avec des bases de données de vulnérabilités crowdsourcées.

Voilà, donc si vous voulez vous lancer dans ce genre d’analyses comparatives de binaires, sachez que Diffrays est sur GitHub , et qu’il est prêt à transformer vos mercredis matins en séances de fouilles intensives. Et n’oubliez pas… avec un grand pouvoir vient une grande responsabilité ! Sinon, c’est la zonzon, comme pour Sarko !

Hier, j’étais en train de lire un bulletin de sécurité Microsoft (oui, je sais, passion de ouf) quand j’ai réalisé que je passais pas mal de temps à chercher des infos sur les CVE surtout que les mecs ne mettent pas forcement de liens pour en savoir plus. Bah ouais, la CVE-2024-21762, ça vous parle ? Non ? Normal, personne ne retient ces codes à la con. Mais avec l’extension Vulners Lookup que je viens de découvrir, c’est devenu carrément plus simple.

Le principe est tout bête… L’extension scanne automatiquement toutes les pages web que vous visitez et surligne en orange chaque identifiant CVE qu’elle trouve. Un simple survol avec la souris et boom, vous avez toutes les infos importantes dans une petite carte qui s’affiche : le score CVSS pour la sévérité, l’EPSS pour la probabilité d’exploitation, et même un Score IA qui estime l’impact réel. Comme ça, plus besoin d’ouvrir 15 onglets pour comprendre si une vulnérabilité est vraiment dangereuse ou si c’est juste du bruit.

Pour fonctionner, cette extension utilise la base de données Vulners.com qui agrège plus de 200 sources différentes. Vulners, c’est 250 Go de données sur les vulnérabilités, constamment mise à jour. Et pas besoin de vous créer un compte, pas d’abonnement, c’est gratuit et ça marche direct après l’install.

Pour les techos qui veulent aller plus loin, Vulners propose aussi une API REST pour intégrer ces données dans vos propres outils. Il y a même un plugin Nmap et une extension Burp Suite pour ceux qui font du pentest. Sans oublier la bibliothèque Python mise à jour en août dernier pour automatiser vos recherches de vulnérabilités.

Un truc cool aussi, c’est l’indicateur KEV (Known Exploited Vulnerabilities) qui vous dit si la vulnérabilité fait partie du catalogue CISA des vulnérabilités exploitées . C’est super utile pour prioriser entre une faille avec un CVSS élevé mais pas encore exploitée et une faille avec un score moyen mais activement utilisée…

Pour l’installer, c’est du classique, vous allez sur le Chrome Web Store , vous cliquez sur le bouton d’installation et c’est parti. L’extension demandera juste la permission de lire le contenu des pages pour détecter les CVE, rien de plus. Pas de tracking, pas de collecte de données perso, juste de la détection de patterns CVE-XXXX-XXXXX à l’ancienne.

Bref, pour ceux qui bossent dans la sécu (SOC, équipes IR, pentesters, DevSecOps), c’est clairement un truc à avoir pour éviter de jongler entre les onglets ou de maintenir des bookmarks de bases de vulnérabilités. Tout est accessible en un survol de souris, directement là où vous travaillez.

Amusez-vous bien !

Les grands modèles de langage (LLM), comme le célèbre GPT-4 d’OpenAI, font des prouesses en termes de génération de texte, de code et de résolution de problèmes. Perso, je ne peux plus m’en passer, surtout quand je code. Mais ces avancées spectaculaires de l’IA pourraient avoir un côté obscur : la capacité à exploiter des vulnérabilités critiques.

C’est ce que révèle une étude de chercheurs de l’Université d’Illinois à Urbana-Champaign, qui ont collecté un ensemble de 15 vulnérabilités 0day bien réelles, certaines classées comme critiques dans la base de données CVE et le constat est sans appel. Lorsqu’on lui fournit la description CVE, GPT-4 parvient à concevoir des attaques fonctionnelles pour 87% de ces failles ! En comparaison, GPT-3.5, les modèles open source (OpenHermes-2.5-Mistral-7B, Llama-2 Chat…) et même les scanners de vulnérabilités comme ZAP ou Metasploit échouent lamentablement avec un taux de 0%.

Heureusement, sans la description CVE, les performances de GPT-4 chutent à 7% de réussite. Il est donc bien meilleur pour exploiter des failles connues que pour les débusquer lui-même. Ouf !

Mais quand même, ça fait froid dans le dos… Imaginez ce qu’on pourrait faire avec un agent IA qui serait capable de se balader sur la toile pour mener des attaques complexes de manière autonome. Accès root à des serveurs, exécution de code arbitraire à distance, exfiltration de données confidentielles… Tout devient possible et à portée de n’importe quel script kiddie un peu motivé.

Et le pire, c’est que c’est déjà rentable puisque les chercheurs estiment qu’utiliser un agent LLM pour exploiter des failles coûterait 2,8 fois moins cher que de la main-d’œuvre cyber-criminelle. Sans parler de la scalabilité de ce type d’attaques par rapport à des humains qui ont des limites.

Alors concrètement, qu’est ce qu’on peut faire contre ça ? Et bien, rien de nouveau, c’est comme d’hab, à savoir :

• Patcher encore plus vite les vulnérabilités critiques, en priorité les « 0day » qui menacent les systèmes en prod
• Monitorer en continu l’émergence de nouvelles vulnérabilités et signatures d’attaques
• Mettre en place des mécanismes de détection et réponse aux incidents basés sur l’IA pour contrer le feu par le feu
• Sensibiliser les utilisateurs aux risques et aux bonnes pratiques de « cyber-hygiène »
• Repenser l’architecture de sécurité en adoptant une approche « zero trust » et en segmentant au maximum
• Investir dans la recherche et le développement en cybersécurité pour garder un coup d’avance

Les fournisseurs de LLM comme OpenAI ont aussi un rôle à jouer en mettant en place des garde-fous et des mécanismes de contrôle stricts sur leurs modèles. La bonne nouvelle, c’est que les auteurs de l’étude les ont avertis et ces derniers ont demandé de ne pas rendre publics les prompts utilisés dans l’étude, au moins le temps qu’ils « corrigent » leur IA.

Source

Les failles de sécurité dans le code sont le cauchemar des développeurs et des équipes de sécurité et font surtout le régal des hackers. Alors pour y remédier, GitHub a décidé de sortir l’artillerie lourde avec Code Scanning Autofix ! Attention les yeux, cet outil mêle IA et analyse statique et nous fait la promesse de corriger les vulnérabilités en un clin d’œil pendant que vous codez.

Concrètement, Code Scanning Autofix (actuellement en bêta publique) est activé par défaut sur tous les dépôts privés des clients GitHub Advanced Security. Et devinez quoi ? Il gère déjà plus de 90% des types d’alertes pour JavaScript, TypeScript, Java et Python. De quoi mettre une sacrée claque à la dette de sécurité applicative !

En coulisse, cette magie opère grâce à deux technologies de pointe made in GitHub : Copilot pour l’IA et CodeQL pour l’analyse statique. Une fois Code Scanning Autofix activé, il vous propose des correctifs quasi tout cuits qui sont censés régler les deux tiers des vulnérabilités détectées, le tout sans trop d’efforts de votre part.

Voici un exemple de correctif proposé :

Pour chaque faille repérée dans un des langages pris en charge, vous obtenez une explication en langage naturel du correctif suggéré, avec un aperçu du bout de code à valider, modifier ou rejeter. Cela peut inclure des changements dans le fichier en cours, d’autres fichiers, voire des dépendances du projet. Bien entendu, vous gardez le contrôle et pouvez vérifier si le correctif résout bien le problème sans casser la fonctionnalité.

L’intérêt est donc de décharger les experts en sécurité de la fastidieuse traque aux vulnérabilités introduites pendant le développement. Ils pourront alors se concentrer sur la sécurité globale de leur projet.

GitHub promet d’étendre prochainement Code Scanning Autofix à d’autres langages, en commençant par C# et Go. Et pour en savoir plus, foncez sur la doc de GitHub !

Source