Point de contrôle de sécurité de Vercel

• Il n’y a pas d’informations substantielles dans le corps du texte, ce qui ne permet pas de confirmer la nature de l’incident ni son déroulement
• Dans le titre sur Hacker News, il est indiqué qu’une triche pour Roblox et un outil d’IA ont affecté la plateforme Vercel
• Le titre original est présenté comme Vercel Security Checkpoint
• La cause précise, l’étendue de l’impact et la méthode de réponse ne peuvent pas être vérifiées faute d’éléments dans le corps du texte
• Avec les seules informations fournies, il est impossible de résumer l’importance de l’incident ou ses détails techniques

---

Aucun contenu

[GN⁺]

Réactions sur Hacker News

• Le texte donne beaucoup trop l’impression d’être généré par IA. On dirait qu’il essaie délibérément de dissimuler ça avec une grammaire maladroite, mais je ne sais pas si cela est indépendant de l’exactitude du contenu

  • J’ai arrêté en cours de lecture. Je suis devenu trop sensible au style LLM ; ça ressemblait quasiment à « ChatGPT, lis cet article et réécris-le de façon décontractée », avec presque aucune véritable voix d’auteur. Pour ce genre de billet, sur HN, il vaudrait mieux autant que possible apporter une source primaire
  • Je ne comprends pas pourquoi ce commentaire est downvoté. Cet article se rapproche du spam de blog IA, il n’apporte pas plus d’informations factuelles que des papiers comme https://www.darkreading.com/application-security/vercel-employees-ai-tool-access-data-breach, et semble rempli de formulations creuses typiques des LLM. Je trouve assez déprimant que les gens aient si volontiers envie de lire ce genre de texte
  • J’ai vu que le site de l’auteur était hébergé sur Vercel. Du coup, je suppose qu’il était réellement exposé à ce problème et avait un intérêt direct dans l’affaire. Rien que pour ça, c’est déjà un cran au-dessus d’un contenu entièrement généré par IA
  • Le style ressemble clairement à de la prose de LLM, mais pas du début à la fin. On dirait plutôt qu’une partie a été réécrite. Ce qui m’inquiète davantage, c’est que ce genre de texte passe tranquillement même sur HN, où beaucoup de gens sont familiers des LLM. Je n’ai pas envie que ça devienne la norme, mais ce qui me frappe surtout, c’est que ce n’est même pas la première fois que du contenu généré par IA suscite des réactions sérieuses sur HN. Utiliser l’IA pour le code, pourquoi pas si un humain vérifie vraiment ; mais voir de plus en plus de prose de LLM envahir la page d’accueil, je trouve ça franchement mauvais
  • J’ai eu exactement la même impression. En général, les gens n’écrivent pas comme ça

• Je pense que l’interprétation de « sensitive » ici est erronée. À ma connaissance, les variables d’environnement de Vercel sont toutes chiffrées au moment du stockage, et la case sensitive sert à empêcher un développeur de revoir la valeur dans l’interface. C’est donc plus proche d’un fonctionnement en écriture seule ; l’application doit bien pouvoir lire la variable d’environnement, donc la chiffrer de façon à ce qu’elle soit illisible par l’app n’aurait aucun sens. Si on ne coche pas la case, on peut voir la valeur dans l’UI du projet, ce qui est plus pratique pour des réglages ordinaires comme DEFAULT_TIME_ZONE. Je comprends donc sensitive comme un indicateur de visibilité dans l’interface, pas de chiffrement. Je ne travaille pas chez Vercel, mais je l’ai un peu utilisé, et critiquer ce point me semble relever de l’homme de paille

  • Oui, c’est aussi ce passage qui m’a troublé. Une variable d’environnement qu’un programme doit réellement utiliser finit forcément par être injectée en clair. On peut la chiffrer au stockage, mais il faut bien la déchiffrer avant l’exécution ; ce n’est pas un problème propre à Vercel, c’est une limite de l’architecture des systèmes elle-même. Peut-être qu’un jour le chiffrement entièrement homomorphe améliorera ça, mais l’overhead pour un programme complet est encore beaucoup trop lourd pour être réaliste
  • À chaque fuite, il y a toujours des gens pour crier « il fallait chiffrer », alors qu’ils ne comprennent souvent pas vraiment les limites du chiffrement, ni sur le plan théorique ni en pratique. Le chiffrement n’est pas un synonyme de secure ou safe
  • Je ne sais pas exactement comment cela fonctionne chez Vercel, mais sur d’autres plateformes, ce marquage signifie souvent aussi que la valeur est masquée dans les logs
  • Là où je travaille, on a commencé à utiliser Vault, et la clé permettant d’aller chercher les clés du vault est placée dans une variable d’environnement ordinaire non masquée. Je pense que c’est probablement une architecture plus robuste
  • D’autres clouds font pareil. Par exemple DigitalOcean fonctionne aussi comme ça

• Je n’ai pas envie de choisir un bouc émissaire facile, mais voir un employé de Context.ai jouer sur sa machine de travail et, en plus, y installer un logiciel de triche d’origine douteuse, ça pose quand même question. Les arguments sur la defense in depth et les couches de sécurité sont évidemment valables, mais il y a aussi clairement une responsabilité individuelle ici. On peut voir l’erreur de Vercel comme un échec défensif au niveau de l’entreprise et du management, mais installer un cheat, c’est un problème grave d’un tout autre ordre

  • Je pense que le niveau d’OpSec est globalement faible dans les entreprises qui adoptent l’IA. Aujourd’hui, la sécurité n’est tout simplement pas une fonction centrale de la prise de décision. Il suffit de regarder la compromission de McDonalds il y a deux ans pour voir une dynamique similaire
  • On ne sait pas encore vraiment si cet employé l’a installé sur son poste de travail. En tout cas, ce n’est pas dans cet article, et je n’ai rien trouvé non plus dans d’autres sources. Beaucoup d’entreprises autorisent aussi l’accès VPN au réseau interne ou la connexion directe à certains systèmes internes depuis Internet ; ce n’est pas idéal, mais c’est bien plus courant qu’on ne le pense. Ça rappelle aussi le piratage de Disney, qui était parti d’un logiciel compromis installé sur un PC personnel. D’après ce que j’ai vu moi-même, l’IT de beaucoup d’entreprises est bien plus laxiste qu’on ne l’imagine
  • Moi, j’en voudrais davantage au service IT d’avoir laissé les utilisateurs installer des logiciels arbitraires
  • Je suis entièrement d’accord. L’idée même de traiter le travail et les usages personnels sur un seul et même laptop me semble déjà très discutable. Dans l’une des dix plus grosses entreprises mondiales par capitalisation, les ingénieurs avaient sur leur bureau un ordinateur de travail sans accès Internet et, séparément, une machine connectée à un autre réseau pour Internet. Mon poste de travail principal ne faisait même pas de bruit. Il n’avait même pas de son. Pour la plupart des gens, un ordinateur principal sans son suffit largement pour travailler. Je ne suis pas technophobe, j’utilise plein de NUC, Raspberry Pi et laptops, mais je n’ai absolument pas besoin de regarder YouTube ou de jouer sur mon poste de travail principal. Les réunions sur un autre laptop, la vidéo sur un autre laptop, ça me va. Cette culture du laptop qu’on emmène au café, au bureau, et avec lequel on joue aussi, c’est ce qui a fait tomber Vercel, et ça fera encore tomber beaucoup d’autres entreprises
  • Je pense que ce n’est qu’une cause parmi d’autres. Bien sûr que c’est un mauvais choix, mais la sécurité des autres systèmes ne doit jamais dépendre du fait que « le laptop pro ne sera absolument jamais compromis ». Si c’est votre seule ligne de défense, vous allez finir par avoir un problème

• Je pense qu’il y a des inexactitudes dans cet article. Les variables d’environnement de Vercel sont toutes chiffrées at rest, et la case sensitive signifie qu’on ne peut plus relire la valeur après configuration, donc dans une situation comme celle-ci cela aurait sans doute aidé. Et lire un article pareil sans un seul lien vers les sources, c’était aussi assez agaçant

  • Cette décision d’UI est assez intéressante. La liste des variables d’environnement est masquée comme des mots de passe, avec un bouton pour afficher, si bien qu’avant de lire l’advisory je n’avais pas immédiatement perçu à quel point le flag sensitive était important. Nous aussi, on a des secrets non marqués comme sensibles, donc on est en train de faire tourner tout ça en urgence
  • Cela dit, puisque certaines variables d’environnement de clients ont bien été exposées, on peut aussi se demander si elles n’étaient donc pas non chiffrées

• Sur la douzaine d’outils IA que j’ai personnellement validés au cours de l’année écoulée, neuf demandaient l’accès à tous les e-mails de Google Workspace ainsi qu’à l’intégralité de Drive. Et comme j’étais débordé pendant l’onboarding, j’ai tout approuvé sans vraiment lire les permissions. Je me demande si même les gens à l’aise avec la technique font vraiment ça. Personnellement, donner à quelqu’un l’accès à mes e-mails et à mon Google Drive me ferait perdre le sommeil ; j’essaie de limiter au maximum les permissions et de révoquer tout de suite les applis que je n’utilise pas. À ce niveau-là, j’ai l’impression qu’il faut partir du principe que tout ce qui relève des NDA ou du confidentiel dans les mails a déjà fuité

  • Au travail, on m’a demandé d’aider une autre équipe à intégrer à Google Workspace un outil IA de comptes rendus de réunion qu’elle avait acheté. Le fournisseur voulait qu’on active Domain-wide Delegation pour lire et écrire les e-mails et les fichiers Drive ; cela faisait que tous les utilisateurs de l’organisation étaient automatiquement inscrits, sans possibilité d’opt-out. J’ai donc contacté le fournisseur pour lui demander d’ouvrir une autre voie, « moins recommandée », où chaque utilisateur se connecte lui-même et accepte l’écran de permissions OAuth. Mais pendant tout ce processus, à la fois le fournisseur et notre organisation traitaient cela comme une perte de temps. Si quelqu’un veut volontairement accorder de larges permissions, libre à lui ; mais activer ça pour tout le monde, sans droit de refus, pour un outil qui n’est même pas central, je trouve ça contraire à l’éthique. Sans parler des inquiétudes de sécurité. Le plus inquiétant, c’est qu’à partir du moment où c’est lié de près ou de loin à l’IA, les gens arrêtent de réfléchir. Il y a cinq ans, des personnes pourtant intelligentes n’auraient jamais fait ce genre de demande ; aujourd’hui, elles considèrent que c’est normal parce que tout le monde le fait
  • Moi, personnellement, je ne fais pas ça. Une phrase lue il y a quelques jours me revient souvent : « à force de vouloir être prudent, on finit tous par converger vers l’informatique monastique version Stallman ». https://news.ycombinator.com/item?id=47796469#47797330 C’est drôle, mais ça sonne vrai. J’aimerais profiter des avantages de l’automatisation par agents qui manipulent librement mes données personnelles, mais je m’en abstiens. Les fonctionnalités que je rate ont l’air chouettes, bien sûr, mais les permissions ne concernent pas seulement le présent. Une fois accordées, elles restent en pratique pour très longtemps
  • Je suis sûr que c’est extrêmement courant. La fatigue des permissions et la fatigue des pop-ups sont bien réelles. Aujourd’hui, les applis et les sites bombardent l’utilisateur de dizaines de fenêtres avant même qu’il atteigne ce qu’il voulait faire ; une bonne partie relève du marketing, une autre de demandes juridiques absurdes, et seule une petite fraction compte vraiment. À la fin, les gens cliquent sur « oui, d’accord, avance » et la sécurité passe par la fenêtre. J’essaie toujours de garder en tête que la sécurité informatique est, au fond, presque une illusion, et que les données sur une machine connectée au réseau doivent être traitées comme des informations semi-publiques. Le fait qu’une grande partie de l’infrastructure moderne repose sur des ordinateurs connectés à Internet est le genre de chose sur laquelle il vaut mieux ne pas trop réfléchir pour préserver sa santé mentale
  • J’ai l’impression que la réalité, c’est ça : le manager dit « fais-moi un truc vite fait avant la grosse réunion de cet après-midi », et l’ingénieur se dit qu’il acceptera tout dans l’assistant de configuration, qu’il rangera ça plus tard. Puis six mois après, cette démo bricolée est toujours en production
  • Je ne vois pas ça comme « j’ai approuvé sans lire parce que j’étais occupé ». En réalité, c’est l’onboarding qui exigeait ces permissions, et il n’y avait tout simplement pas de possibilité de refuser. Si on refusait, on ne pouvait pas utiliser l’application ; c’était donc une contrainte déguisée. Je trouve l’idée elle-même mauvaise. Quand un utilisateur clique sur « refuser », l’application ne devrait même pas être informée du refus ; elle devrait simplement voir les données demandées comme absentes. L’application pourrait alors demander les permissions qu’elle souhaite, et l’utilisateur pourrait continuer à s’en servir sans les accorder. À mes yeux, c’est la vraie solution

• Si je devais spéculer, je dirais qu’il ne s’agissait pas d’une application Google Workspace quelconque, mais probablement d’un problème d’accès à Gmail. L’attaquant a sans doute obtenu un accès large à la boîte de réception de la victime, puis s’est connecté à certains systèmes internes via des magic links ou des codes à usage unique. Dans ce cas, on peut se demander pourquoi il n’y avait pas de 2FA, et surtout pourquoi un accès aussi large avait été accordé dès le départ. Sinon, l’autre possibilité serait que des identifiants API aient été stockés dans Google Workspace, ce qui reste possible mais me semblerait une architecture assez étrange

• Que ce soit pour un simple cheat Roblox, c’est hallucinant. Mon fils s’est déjà fait compromettre son compte à cause d’un cheat Roblox, donc je prends ça au sérieux ; à l’époque, ils avaient volé son cookie Gamepass pour acheter quatre licences Minecraft, et Microsoft l’avait remboursé rapidement

  • Dit comme ça, on a presque l’impression que Vercel s’est fait compromettre par des script kiddies ados. Cela dit, si on veut voir le bon côté des choses, on peut espérer que des arrestations ne tarderont pas
  • Ce qui m’étonne déjà, c’est pourquoi un cheat de jeu pouvait être exécuté. On se demande si ces entreprises n’ont aucun contrôle des appareils, ou si elles en ont un mais ne s’en préoccupent pas. On dirait que l’employé a répété le genre d’erreur vu dans l’affaire LastPass/Plex

• Cet article affiche une erreur de vérification du navigateur

  • Ce qui est ironique, c’est que le site est hébergé sur Vercel

• En lisant la phrase « combien de développeurs savaient qu’il y avait cette case à cocher, et combien supposaient que les identifiants de base de données et les clés API étaient chiffrés par défaut », j’ai eu la réaction inverse. Si je ne vois pas d’astérisques dans un champ où l’on saisit un secret, je ne clique même pas sur enregistrer. Peut-être que certains les ont injectés par programmation, mais même dans ce cas, j’aurais attendu au minimum quelque chose comme un flag secret à renseigner explicitement. Qu’une entreprise comme Vercel ait eu ce genre de problème me paraît franchement étrange

  • Dans ce type de champ, il faut partir par défaut du principe que quelqu’un va y saisir des informations sensibles. Donc le chiffrement par défaut me semble être le seul choix raisonnable
  • On ne demande pas à un ingénieur des ponts : « vous n’auriez pas oublié de renforcer les piliers ? » ; même quand je connaissais mal la sécurité, ça me semblait être la base absolue. Je comprends que des gens soient en colère après s’être retrouvés confrontés aux conséquences d’un stockage en clair d’informations sensibles, mais au fond ils paient aussi le prix de leurs propres pratiques. Cela ne veut pas dire qu’il faille blâmer uniquement les victimes, et Vercel doit évidemment assumer sa part de responsabilité dans cette situation absurde. Mais malgré tout, il reste un côté FAFO

• Ironiquement, on dirait qu’ils ont renforcé davantage les contrôles de sécurité maintenant. En essayant de lire l’article original avec une ancienne version de Firefox, je n’ai vu que Failed to verify your browser, Code 11 et le message Vercel Security Checkpoint. Franchement, c’était assez agaçant