L'IA de Google a pénétré dans trois vraies entreprises. Tout ce qu'il lui fallait, c'était un mot de passe faible.
Le 19 septembre, Google a confirmé un incident inhabituel qui s'était produit quatre mois plus tôt et qui n'avait pas été rendu public jusqu'à présent : son modèle Gemini a pénétré de manière autonome dans les systèmes de trois vraies entreprises.
Ce n'était pas une cyberattaque délibérée.
Cela s'est produit lors d'un exercice contrôlé de capture du drapeau organisé par Irregular, la société israélienne de sécurité IA. Le modèle a reçu une tâche apparemment simple : récupérer des informations des systèmes d'une entreprise fictive dans un environnement de test.
Sauf que deux choses ont mal tourné.
Le modèle n'était pas censé avoir accès à Internet — mais il en avait.
Et le nom de l'entreprise fictive choisi pour l'exercice appartenait en fait à une vraie entreprise.
À partir de là, tout s'est déroulé rapidement.
Gemini a recherché sur le web, identifié des systèmes qu'il croyait faire partie de l'environnement d'exercice, et y est entré.
Dans les trois cas, il s'est arrêté au moment où il a compris que les systèmes étaient réels.
Mais ce qui compte ici, ce n'est pas qu'une IA ait réussi à pénétrer dans un système.
Ce qui compte, c'est comment elle l'a fait.
Pas un zero-day. Pas une vulnérabilité sophistiquée. Un mot de passe.
Dans un cas, Gemini a simplement essayé encore et encore de deviner le mot de passe — jusqu'à ce que cela fonctionne.
Dans les deux autres cas, il a trouvé des identifiants qui avaient été accidentellement engagés dans un dépôt public et les a utilisés.
C'est tout.
Pas de nouvel exploit. Pas de zero-day. Pas d'attaque de la chaîne d'approvisionnement.
Juste deux techniques très anciennes :
Deviner un mot de passe, ou en trouver un que quelqu'un a laissé exposé.
Et c'est exactement pourquoi cet incident est important.
Les trois entreprises n'étaient pas des cibles spéciales. Elles n'ont rien fait d'inhabituel. Leurs systèmes étaient simplement accessibles depuis Internet, et leurs identifiants étaient faibles ou déjà exposés.
Cette description correspond à d'innombrables serveurs de production aujourd'hui.
Ce qui a réellement changé
Deviner des mots de passe existe depuis des décennies.
La nouveauté n'est pas la technique.
La nouveauté est qui l'effectue.
Un attaquant humain doit choisir des cibles, rassembler des informations, essayer, échouer, changer de direction et continuer.
Un agent autonome peut faire tout cela tout seul.
Il recherche des informations publiques, croise des sources, identifie des services, essaie des identifiants, lit les réponses, ajuste son étape suivante et continue.
Sans se fatiguer.
Sans s'ennuyer.
À la vitesse de la machine.
Dans ce cas, personne ne lui a même demandé d'attaquer.
On lui a donné une tâche légitime avec des limites qui n'étaient pas suffisantes — et trois vraies entreprises ont été compromises en conséquence.
Et c'est peut-être le point le plus important de tous :
Si un agent peut faire cela par accident, vous pouvez imaginer à quel point la barre est basse pour le faire intentionnellement.
Pourquoi un WAF ou un CDN ne sera pas nécessairement utile ici
Au moment où vous entendez "l'IA a attaqué un serveur", l'instinct est de penser à un WAF, un CDN ou un pare-feu cloud.
Mais dans ce cas, aucun d'eux n'était sur le chemin.
L'agent n'a pas "passé par le bord."
Il a trouvé des systèmes exposés sur Internet et s'est connecté directement à eux.
Et c'est là que réside la distinction importante.
Une couche de bord ne peut protéger que le trafic qui passe par elle.
Si votre serveur d'origine a une adresse IP publique, et qu'un service est ouvert directement sur Internet, il peut être atteint sans passer par le CDN ou le WAF.
En d'autres termes :
Le seul endroit qui voit de manière fiable chaque connexion arrivant à votre serveur est le serveur lui-même.
Chaque autre couche ne protège que le trafic qui passe réellement par elle.
Qu'est-ce qui aurait pu arrêter Gemini ?
Ici, il est important d'être précis.
Pour la devinette de mot de passe — oui.
Deviner un mot de passe ne fonctionne que si l'attaquant a suffisamment d'essais.
nuDefend détecte les échecs d'authentification répétés et bloque automatiquement l'adresse source après un petit nombre de tentatives.
Le blocage se produit au niveau du pare-feu du noyau — avant que la prochaine tentative n'atteigne même le service.
Un agent qui a besoin de centaines de tentatives ne les obtient tout simplement pas.
Sur deux de nos propres serveurs de production ordinaires, dans une seule fenêtre de 24 heures, nous avons enregistré :
144 échecs de tentative SSH provenant de 25 adresses différentes sur un serveur.
344 tentatives sur le second.
73 de ces tentatives visaient directement le compte root.
Tous bloqués automatiquement.
Et ce ne sont pas des serveurs sous une attaque ciblée.
C'est simplement le bruit de fond constant d'Internet.
Le même type de comportement que Gemini a affiché lors de l'exercice — mais à l'échelle mondiale, tout le temps.
Pour les identifiants exposés dans un dépôt — non.
Si quelqu'un a stocké un mot de passe, une clé API ou un jeton dans un dépôt public, c'est un échec de processus.
Aucun agent fonctionnant sur le serveur ne peut rétroactivement corriger un identifiant qui a déjà fui.
Quiconque promet le contraire vend une illusion.
Vous devez scanner les dépôts, exécuter une analyse des secrets, faire tourner les identifiants exposés et vous assurer qu'ils n'entrent jamais dans le code en premier lieu.
Et pour l'accès à Internet de Gemini — également non.
C'était un problème de bac à sable et de permissions du côté de Google.
Le modèle a reçu une capacité de communication qu'il n'était jamais censé avoir.
Aucun logiciel de protection fonctionnant dans l'entreprise compromise ne peut corriger une erreur de permissions dans l'environnement IA de quelqu'un d'autre.
En d'autres termes :
nuDefend n'aurait pas empêché les trois cas.
Il aurait arrêté l'un d'eux.
Mais précisément celui qui se répète encore et encore, jour après jour, sur presque chaque serveur public sur Internet.
C'est exactement pourquoi la défense appartient au serveur
nuDefend s'installe directement sur le serveur et fonctionne là où la connexion arrive réellement.
Il bloque les adresses IP malveillantes connues directement au niveau du pare-feu du noyau — à la fois entrant et sortant — avant que le trafic n'atteigne votre application.
Il détecte et bloque les tentatives répétées de deviner des identifiants.
Sa liste de menaces signées se rafraîchit toutes les 30 minutes, donc une adresse IP qui est devenue malveillante aujourd'hui peut être bloquée sur vos machines aujourd'hui, sans aucune action manuelle requise.
nuDefend montre également quels services écoutent actuellement sur votre serveur, et à quel point chacun est réellement exposé.
Cela compte, car c'est exactement ce qu'un agent autonome fait au début d'une attaque :
d'abord, il essaie de comprendre ce qui est ouvert.
La différence est que vous pouvez le voir avant qu'il ne le fasse.
Les rapports sont générés localement et restent sur votre serveur.
Mais cette histoire pointe vers un problème plus grand
L'échec le plus intéressant dans l'incident de Google n'était pas aux trois entreprises compromises.
C'était à l'IA.
Il y avait une charge de travail autonome avec un accès sortant — et cet accès n'était jamais censé exister.
Ce qui nous ramène à la question.
Si vous exécutez aujourd'hui :
un serveur d'inférence local,
un agent IA,
un système d'automatisation,
une base de données vectorielle,
ou un agent connecté à des systèmes internes,
savez-vous réellement où ce processus est autorisé à se connecter ?
En général, la réponse est non.
Nous savons quels ports sont ouverts à l'entrée.
Nous savons quels processus sont en cours d'exécution.
Mais il est beaucoup plus difficile de répondre :
à qui chaque processus parle-t-il réellement, à la sortie ?
Et c'est précisément la direction de la prochaine couche que nous construisons dans nuDefend.
Pas seulement voir le trafic sortant.
Mais apprendre au fil du temps avec quelles destinations chaque charge de travail communique normalement — et ensuite autoriser uniquement ce dont elle a besoin.
En d'autres termes :
Apprenez d'abord. Autorisez uniquement ce qui appartient.
Pas parce que l'IA est plus "dangereuse" que tout autre logiciel.
Mais parce qu'un agent autonome prend des décisions de lui-même.
Et une fois qu'un processus prend ses propres décisions, vous ne pouvez pas compter sur lui pour se comporter simplement comme vous l'aviez prévu.
Il a besoin de limites.
En attendant ? Les choses ennuyeuses fonctionnent toujours.
Ne laissez pas les services ouverts sur Internet si vous n'en avez pas besoin.
N'utilisez pas de mots de passe faciles à deviner.
Ne stockez pas d'identifiants dans le code.
Et ne laissez rien essayer encore et encore jusqu'à ce que cela réussisse.
L'IA peut être en train de changer le paysage de la cybersécurité.
Mais un grand nombre de violations commencent toujours par la même vieille erreur :
Nous avons laissé la porte ouverte trop longtemps.
Sources : CNN Business · The Hacker News · ABC News