Résumé

  • Retool a divulgué que le 29 août 2023, il a informé 27 clients cloud d'un accès non autorisé à leurs comptes après une attaque d'ingénierie sociale ciblée du 27 août contre un employé de Retool.
  • Qui avait le contrôle pratique sur la vérification du canal de support des employés, l'inscription MFA et les contrôles de récupération, la dépendance au compte Google, l'isolement de l'environnement client, la détection, la divulgation et la preuve que les workflows de support ne pouvaient pas remplacer les garanties d'identité?
  • Le problème de responsabilité est que les plateformes d'automatisation d'entreprise peuvent hériter du risque d'ingénierie sociale des canaux de support des employés lorsque les chemins de support ou de récupération permettent de contourer dans la pratique les hypothèses d'authentification forte.
  • Les clients de Retool, les utilisateurs internes, les équipes de support, les fournisseurs d'identité, les workflows crypto et fintech, les auditeurs et les équipes de sécurité d'entreprise avaient besoin de preuves que la confiance dans le canal de support était réduite à un processus d'exception contrôlé.
  • Cet article traite du post-mortem de Retool comme le dossier public principal. La documentation Retool, la documentation Google, FIDO, CISA, NIST, Okta et des enregistrements sélectionnés de l'écosystème sont utilisés pour évaluer les modèles de contrôle et les limites de preuve.

Pourquoi ce cas fait partie d'un dossier de risque et de responsabilité

Retool fait partie d'un dossier de risque et de responsabilité car il montre comment une plateforme logicielle d'entreprise peut échouer par l'écart entre "MFA existe" et "MFA ne peut pas être contournée par ingénierie sociale." Retool est une plateforme pour construire des outils internes, workflows, panneaux d'administration et applications opérationnelles. Les clients l'utilisent souvent pour connecter des bases de données, API, opérations de paiement, processus de support, workflows financiers, outils de conformité, opérations crypto et autres systèmes internes privilégiés.

Si le chemin de support interne d'un fournisseur peut prendre le contrôle des comptes clients, le processus de support de la plateforme devient partie intégrante de la frontière de sécurité du client.

Le dossier principal est le billet de blog du 13 septembre 2023 de Retool, "When MFA isn't actually MFA," àhttps://retool.com/blog/mfa-isnt-mfa. Retool a déclaré que le 29 août 2023, il a informé 27 clients cloud qu'il y avait eu un accès non autorisé à leurs comptes. Il a dit qu'il n'y avait pas eu d'accès aux comptes sur site ou gérés. Il a décrit une attaque de spear-phishing le 27 août où des employés ont reçu des SMS ciblés concernant un problème de compte lié à une inscription ouverte et à une migration récente vers Okta. Un employé s'est connecté à un portail factice qui incluait un formulaire MFA. Retool a déclaré que l'attaquant a ensuite téléphoné à l'employé, se faisant passer pour un membre de l'équipe IT, a utilisé une voix familière deepfakée et un contexte interne, et a obtenu un code MFA supplémentaire.

L'incident est alors passé de l'identité de l'employé à l'impact client. Retool a déclaré que l'accès au compte Google de l'employé a donné à l'attaquant accès aux codes MFA stockés dans Google Authenticator via la synchronisation cloud. Avec ces codes et la session Okta, l'attaquant a eu accès au VPN et aux systèmes d'administration internes de Retool. Retool a déclaré que cela a permis à l'attaquant de lancer une attaque de prise de contrôle de comptes sur un ensemble spécifique de clients dans le secteur crypto en changeant les e-mails des utilisateurs et en réinitialisant les mots de passe.

Retool a dit qu'il a révoqué les sessions authentifiées internes, verrouillé les comptes affectés, informé les clients concernés, restauré les comptes à leur état d'origine et annulé les 27 prises de contrôle.

Ces faits rendent l'incident plus qu'une simple histoire de phishing. Le chemin a traversé SMS, migration d'identité, confiance de type help-desk, ingénierie sociale vocale, garde de codes d'authentification, accès VPN, une instance Retool de support interne, administration cloud client et récupération de compte client. Chaque maillon avait un propriétaire différent. L'attaquant contrôlait la tromperie. Retool contrôlait les processus de support employé, la conception d'accès interne, les outils d'administration, la réponse aux incidents et la notification client.

Google contrôlait la conception de synchronisation Authenticator et la sécurité des comptes Google. Okta fournissait l'infrastructure d'identité. Les clients contrôlaient leur propre conception d'applications Retool, permissions utilisateurs, garanties de transactions en aval et choix entre déploiement cloud, géré ou auto-hébergé.

La question de responsabilité est le contrôle pratique, pas le blâme abstrait. Retool n'a pas dit que tous les clients Retool étaient affectés. Il a dit que 27 clients cloud ont été informés et que les comptes sur site et gérés n'ont pas été accédés. Cette limite doit être respectée. En même temps, le chemin affecté était grave car un processus de support interne pouvait modifier les détails du compte client et réinitialiser les mots de passe.

Pour un produit d'automatisation d'entreprise, la prise de contrôle de compte n'est pas seulement un événement d'identité; cela peut devenir un événement de contrôle opérationnel si les applications affectées peuvent exécuter des requêtes, déclencher des workflows ou approuver des actions irréversibles.

L'attaque a exploité la confiance dans le canal de support, pas seulement les invites d'authentification

Le post-mortem de Retool est utile car il décrit une séquence d'ingénierie sociale plutôt qu'un simple clic. Le SMS a été programmé autour des avantages des employés et d'une migration Okta. L'URL factice était déguisée en portail d'identité interne. Le portail factice a collecté les données de connexion et MFA. L'attaquant a ensuite téléphoné à l'employé et a utilisé un contexte organisationnel. Retool a déclaré que l'employé est devenu méfiant pendant la conversation mais a quand même fourni un code MFA supplémentaire.

C'est la véritable leçon du canal de support: les attaques peuvent réussir en combinant légitimité partielle, timing, urgence, vocabulaire interne, familiarité vocale et une demande qui ressemble à une étape de support ou de récupération.

De nombreuses organisations conçoivent les processus de support autour de la commodité en période de stress. Les employés sont formés pour résoudre rapidement les problèmes d'accès car un accès bloqué peut arrêter le travail. Les équipes IT aident les utilisateurs lors des migrations. Les processus RH créent des délais. Les appels de support nécessitent souvent une vérification. Les attaquants ont exploité ce schéma familier.

Si le canal de support peut demander un code, ajouter un appareil, approuver un flux de récupération ou guider un utilisateur à travers une réinitialisation d'identité, alors le canal de support fait partie du système d'authentification. Il doit être conçu comme un contrôle à haut risque, pas comme une porte d'entrée amicale.

Le propre post-mortem de Retool a décrit l'instance Retool de support interne comme la voie par laquelle les prises de contrôle de comptes clients ont été exécutées. L'authentification pour cette instance interne incluait VPN, SSO et un système MFA final. Retool a déclaré qu'une session Google Workspace valide seule n'aurait pas été suffisante. Ce détail est important car il montre que Retool avait plusieurs couches.

L'échec n'était pas l'absence de MFA; c'était l'effondrement de la séparation lorsque le contrôle d'un compte et les secrets d'authentificateur synchronisés ont permis à l'attaquant de passer les couches supplémentaires.

C'est pourquoi le titre du post-mortem de Retool est important. "When MFA isn't actually MFA" n'est pas une affirmation que MFA est inutile. C'est un avertissement que les facteurs doivent rester indépendants. Si le mot de passe, la session de compte, les secrets d'authentificateur, le chemin de récupération et le processus de support deviennent tous accessibles via un seul compte compromis ou une seule conversation d'ingénierie sociale, l'architecture peut sembler multi-facteurs tout en se comportant comme un seul facteur composite.

Il en va de même si un employé de support peut contourner une authentification forte sans un processus séparé, vérifiable et à haute assurance.

Le standard de réparation publique devrait donc se concentrer sur la conception du canal de support. Un appel de support employé peut-il jamais demander un OTP? L'IT peut-elle ajouter ou réinitialiser des dispositifs MFA sans approbation séparée? Les flux de récupération sont-ils liés à des méthodes résistantes au phishing? Les actions administratives dans les outils de support internes sont-elles verrouillées par une élévation matérielle? Les changements d'e-mail et les réinitialisations de mot de passe pour les clients sont-ils doublement contrôlés?

Les clients à haut risque, comme les équipes crypto ou fintech, sont-ils soumis à des workflows plus stricts? Les actions de support sont-elles journalisées d'une manière que les clients peuvent auditer? Ces questions découlent directement du chemin d'attaque décrit par Retool.

Les codes à usage unique synchronisés dans le cloud ont changé le modèle de menace MFA

La conclusion la plus débattue de Retool concernait la synchronisation de Google Authenticator. Google a annoncé le 24 avril 2023 que Google Authenticator prendrait en charge la synchronisation des codes à usage unique via le compte Google àhttps://security.googleblog.com/2023/04/google-authenticator-now-supports.html. La page d'aide de Google àhttps://support.google.com/accounts/answer/1066447explique que les utilisateurs peuvent synchroniser les codes de vérification entre appareils en se connectant à un compte Google. Cette fonctionnalité répond à un véritable problème d'utilisabilité: les utilisateurs perdent leurs téléphones, changent d'appareils et se retrouvent bloqués lorsque les graines des codes à usage unique sont uniquement locales. La commodité est évidente.

Le post-mortem de Retool a soutenu que cette commodité a créé un nouveau chemin d'attaque dans son environnement. Retool a déclaré que l'accès au compte Google de l'employé a donné accès à tous les codes MFA détenus dans ce compte, et que c'était la raison principale pour laquelle l'attaquant a pu entrer dans les systèmes internes.

Retool a décrit le changement comme rendant ce qui avait été une authentification multi-facteurs silencieusement devenue une authentification à un seul facteur pour les administrateurs, car le contrôle du compte Okta a conduit au contrôle du compte Google, qui a conduit au contrôle des OTP synchronisés. C'est l'affirmation de Retool concernant son environnement, et il convient de la traiter comme l'interprétation de l'incident par l'entreprise plutôt que comme une conclusion réglementaire contre Google.

La leçon de contrôle plus large est solide. Un mot de passe à usage unique basé sur le temps reste un secret partagé. Si la graine est copiée dans un compte cloud accessible via le même chemin d'identité protégé, l'indépendance du facteur peut être affaiblie. L'utilisateur peut encore voir deux invites, mais l'attaquant peut travailler via un seul écosystème de compte compromis. Ceci est différent d'un modèle de clé matérielle résistante au phishing ou de passkey où l'authentificateur prouve la possession d'une clé privée liée à la partie légitime et ne produit pas un code qui peut être lu à un attaquant.

La fiche d'information de la CISA sur les MFA résistantes au phishing àhttps://www.cisa.gov/sites/default/files/2023-01/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf, la norme NIST SP 800-63B àhttps://pages.nist.gov/800-63-4/sp800-63b.html, et la documentation de la FIDO Alliance àhttps://fidoalliance.org/fido2/ethttps://fidoalliance.org/passkeys/soutiennent toutes la distinction entre les facteurs basés sur un code et les méthodes à clé publique résistantes au phishing. Retool lui-même a recommandé des clés de sécurité matérielles utilisant FIDO2 dans son post-mortem. La leçon n'est pas que chaque organisation doit rejeter tout produit d'authentificateur synchronisé. C'est que les administrateurs doivent comprendre où les graines d'authentificateur sont stockées, qui peut les synchroniser, si la politique d'entreprise peut désactiver la synchronisation, et si les systèmes d'administration à haut risque reposent sur des codes phishables ou relayables.

Les conseils d'Okta à ses clients sont pertinents car l'attaque a eu lieu lors d'une migration vers Okta. La documentation d'Okta sur les authentificateurs et la politique d'authentification àhttps://help.okta.com/oie/en-us/content/topics/identity-engine/authenticators/about-authenticators.htmethttps://help.okta.com/oie/en-us/content/topics/identity-engine/policies/about-authentication-policies.htmdonne aux organisations des outils pour exiger des facteurs plus forts pour les applications sensibles. Ces documents ne sont pas des conclusions sur l'incident. Ce sont des preuves que les entreprises ont des choix de configuration. Un panneau d'administration de support, un VPN et un système de gestion de comptes clients devraient être parmi les premières applications à exiger une authentification résistante au phishing, liée à l'appareil, ou à haute assurance.

Les outils d'administration internes peuvent devenir des plans de contrôle orientés clients

La propre catégorie de produit de Retool rend l'incident particulièrement instructif. Retool est utilisé pour construire des outils internes. Dans l'incident, Retool a déclaré qu'une instance Retool interne utilisée pour le support client faisait partie du chemin des prises de contrôle de comptes clients. Cela crée un problème de responsabilité récursif: une plateforme pour construire des outils d'administration opérationnels doit sécuriser ses propres outils d'administration opérationnels avec un soin inhabituel. La puissance du produit est le risque.

Une interface d'administration interne peut changer les e-mails des clients, réinitialiser les mots de passe, visualiser l'état opérationnel, déclencher des actions de support ou inspecter des applications. Même si ce n'est pas une base de données de production, cela peut être un plan de contrôle orienté client.

La page des pratiques de sécurité de Retool àhttps://docs.retool.com/legal/securitydécrit les responsabilités de sécurité pour les déploiements hébergés et auto-hébergés à un niveau élevé. Le guide des journaux d'audit de Retool àhttps://docs.retool.com/org-users/guides/monitoring/audit-logset la référence des événements journalisés àhttps://docs.retool.com/org-users/reference/logged-eventsmontrent que l'auditabilité fait partie de l'attente du produit. Les conseils de sécurité bien architecturés de Retool àhttps://docs.retool.com/education/coe/well-architected/securitymettent l'accent sur les permissions, les ressources, les secrets, le chiffrement et la surveillance. Ces documents sont pertinents car ils montrent que les mêmes principes dont les clients ont besoin pour leurs propres applications s'appliquent également aux applications de support internes de Retool.

Les workflows de prise de contrôle de comptes sont particulièrement sensibles. Changer l'e-mail d'un utilisateur et réinitialiser un mot de passe peut transférer le contrôle même si les données de l'application cliente sous-jacente ne sont pas directement volées via l'outil de support. Si l'application Retool d'un client est connectée à un système crypto, financier, de santé ou opérationnel, la prise de contrôle du compte utilisateur peut permettre à l'attaquant d'utiliser les permissions de l'application du client.

Le post-mortem de Retool a déclaré que les clients qui avaient construit des applications sécurisées et compris leur matrice de menace ont été efficaces pour repousser l'attaque malgré les prises de contrôle de comptes. C'est un détail clé: la conception de l'application en aval peut limiter les dégâts, mais l'action de support interne du fournisseur a créé l'événement initial de contrôle du compte.

La question de responsabilité n'est donc pas seulement de savoir si Retool a restauré les 27 comptes. C'est de savoir si le processus de support interne a été modifié de sorte qu'une compromission de compte d'employé ne peut pas effectuer les mêmes actions d'administration client sans contrôles supplémentaires. Les actions à haut risque devraient nécessiter une revue humaine dans la boucle, une approbation indépendante, une notification client, des fenêtres de délai, une approbation détenue par le client, une élévation matérielle, ou des règles de politique basées sur la sensibilité du client.

Retool a déclaré avoir déjà mis en place des mesures de type humain dans la boucle en interne et prévoyait de mettre en œuvre de tels workflows dans le produit. Le dossier public ne montre pas tous les détails de ces changements, donc le test durable est basé sur les preuves plutôt que sur l'intention.

Les clients ont également besoin de leurs propres contrôles. Les documents de Retool sur le provisioning SCIM àhttps://docs.retool.com/sso/guides/scim-user-provisioning, les journaux d'audit, et le durcissement de sécurité pour les déploiements auto-hébergés àhttps://docs.retool.com/self-hosted/self-managed/concepts/best-practices/security-hardeningindiquent une gouvernance côté client: gérer centralement les utilisateurs, révoquer les utilisateurs partis, surveiller les événements sensibles, durcir les paramètres de déploiement, et éviter de donner à un seul compte Retool un pouvoir opérationnel irréversible sans contrôles compensatoires. Un incident de plateforme devrait inciter les clients à examiner quels utilisateurs Retool peuvent exécuter des requêtes à haut risque, modifier des enregistrements, approuver des retraits ou déclencher des actions externes.

Les limites entre cloud, géré et auto-hébergé ont compté

La distinction publique de Retool entre les comptes cloud, gérés et sur site est importante. Retool a déclaré que l'incident a affecté un petit sous-ensemble de clients cloud et qu'aucun compte sur site ou géré n'a été accédé. Il a également déclaré que Retool sur site fonctionne dans un environnement de confiance zéro, ne fait pas confiance au cloud Retool, est entièrement autonome et ne charge rien depuis l'environnement cloud. La documentation auto-hébergée de Retool àhttps://docs.retool.com/self-hosteddécrit les options auto-hébergées et gérées par Retool, y compris les déploiements où les clients conservent la propriété et le contrôle des données, des clés de chiffrement et de l'accès dans leur propre infrastructure.

Cette limite ne doit pas être exagérée. L'architecture auto-hébergée peut réduire la dépendance au cloud Retool, mais les clients doivent toujours gérer leur propre identité, réseau, base de données, secrets, mises à jour et surveillance. La déclaration de Retool selon laquelle le sur site n'a pas été affecté est une limite d'incident confirmée pour cet événement, pas une affirmation universelle que l'auto-hébergement élimine tout risque lié à Retool. Néanmoins, la distinction est importante car elle montre comment l'architecture de déploiement peut façonner le rayon d'explosion.

Un chemin d'administration support cloud peut avoir une portée sur les comptes clients cloud. Un déploiement autonome peut supprimer ou réduire cette portée.

La dépendance au service cloud est donc une décision commerciale, pas seulement un choix d'hébergement. Le cloud Retool peut réduire la charge opérationnelle et accélérer l'adoption. Retool auto-hébergé peut donner aux clients plus de contrôle sur la localisation des données, l'isolement réseau et les limites de support. Les modèles gérés auto-hébergés peuvent se situer entre ces extrêmes. Le bon choix dépend du modèle de menace, du secteur, des effectifs, de la conformité et des conséquences d'une prise de contrôle de compte de support.

Le propre post-mortem de Retool a encouragé les clients dans les secteurs sensibles à considérer le sur site si la sécurité est importante, tout en notant que de nombreux clients crypto et plus grands utilisaient déjà le sur site.

L'incident montre également que l'isolement doit être testé au niveau de la couche administrative. Un client peut croire que les données sont isolées car les bases de données et les ressources sont dans son propre cloud, mais une prise de contrôle de compte dans la plateforme peut toujours compter si l'attaquant peut utiliser les propres permissions de l'application du client. Inversement, un outil de support peut ne pas détenir directement de données client mais peut déclencher des changements de compte qui débloquent des chemins d'accès.

Une frontière de déploiement solide doit considérer ensemble le contrôle d'identité, le contrôle de support, le contrôle des actions d'administration et les permissions des applications en aval.

La preuve est le facteur décisif. Les clients devraient demander à Retool ou à tout fournisseur de logiciel d'entreprise similaire comment l'accès de support cloud est séparé des environnements auto-hébergés, quelles actions de support nécessitent une approbation, quels événements clients sont journalisés, comment la récupération de compte est vérifiée, comment les secteurs à haut risque sont traités, et comment les clients sont informés des changements administratifs.

La documentation sur les journaux d'audit et la sécurité de Retool fournit un vocabulaire de départ, mais l'achat devrait demander des réponses spécifiques au déploiement.

Le préjudice client dépend du workflow construit sur la plateforme

Le post-mortem de Retool a déclaré que l'attaquant a exécuté des prises de contrôle de comptes contre des clients du secteur crypto, a changé des e-mails, réinitialisé des mots de passe et a fouiné dans certaines applications Retool. Il n'a pas nommé les clients affectés dans le billet. Des rapports tiers, notamment CoinDesk àhttps://www.coindesk.com/business/2023/09/13/phishing-attack-on-cloud-provider-with-fortune-203750644.htmlet la réponse de Fireblocks àhttps://www.fireblocks.com/blog/in-response-to-the-fortress-trust-hack-dated-september-12-2023, ont lié l'épisode plus large à Fortress Trust et à des allégations de perte de cryptomonnaie. Ces enregistrements sont un contexte utile, mais l'article ne devrait pas traiter chaque affirmation tierce comme un fait confirmé par Retool. Les faits confirmés par Retool sont les 27 prises de contrôle de comptes clients cloud et la limite cloud uniquement.

Le point sur le workflow est toujours essentiel. Retool peut être utilisé pour construire presque n'importe quoi. Un client peut construire un tableau de bord d'analyse en lecture seule. Un autre peut construire une console de support qui modifie les enregistrements clients. Un autre peut construire une interface d'opérations crypto. Un autre peut construire un workflow de back-office de santé. La même prise de contrôle de compte a des conséquences différentes selon ce que le compte peut faire.

Retool a explicitement dit aux clients de comprendre leur propre modèle de menace si leurs applications peuvent accéder à des actions dangereuses ou irréversibles. C'est une répartition sobre des responsabilités, mais cela n'absout pas le fournisseur de sécuriser le chemin de support qui a permis la prise de contrôle.

Les clients devraient donc évaluer les applications Retool comme des systèmes de production internes. Quelles requêtes peuvent muter des données? Quelles applications peuvent déclencher des transferts externes? Quelles ressources utilisent des identifiants de production? Quels groupes d'utilisateurs ont des droits d'administration? Quelles actions nécessitent une deuxième approbation? Quels journaux d'audit montrent l'exécution des requêtes, les vues de page, les connexions utilisateurs, les changements de ressources et les changements de comptes pilotés par le support?

Quels systèmes en aval peuvent détecter et inverser les actions malveillantes? La documentation des événements journalisés de Retool fournit des catégories, mais les clients ont besoin de leur propre modèle de risque autour de chaque application.

C'est là que l'automatisation des logiciels d'entreprise peut devenir un multiplicateur de préjudice. L'automatisation réduit le travail manuel en rendant les actions à fort impact faciles. C'est la proposition de valeur. Cela signifie aussi qu'un accès compromis peut exécuter rapidement des actions à fort impact. Un canal de support qui peut réinitialiser un e-mail ou un mot de passe n'est pas seulement en train d'aider un utilisateur. Il peut permettre l'accès à une surface d'automatisation qui peut atteindre de l'argent, des données clients, des stocks ou des enregistrements réglementés.

La conception plus sûre est de faire en sorte que les actions irréversibles ou de grande valeur nécessitent une confirmation indépendante en dehors du canal compromis.

L'étape de restauration des comptes de l'incident est également importante. Retool a déclaré avoir restauré les comptes affectés aux adresses e-mail d'origine et annulé les 27 prises de contrôle. La restauration ferme une couche de l'incident. Cela ne prouve pas nécessairement que chaque action côté client tentée pendant la fenêtre était inoffensive. Cette preuve dépend des journaux d'audit clients, de la conception de l'application, des permissions des ressources et des preuves des systèmes en aval.

Le post-mortem de Retool a reconnu que les clients avec des applications sécurisées ont été efficaces pour repousser l'attaque, ce qui implique que les garanties au niveau de l'application étaient importantes.

Les contrôles humains dans la boucle doivent être conçus contre l'ingénierie sociale

La leçon de Retool sur l'ajout d'un humain dans la boucle est utile mais incomplète à moins que le processus humain ne soit durci. Un deuxième humain peut empêcher l'automatisation d'exécuter silencieusement une action risquée. Mais un deuxième humain peut aussi être victime d'ingénierie sociale, pressé, contourné ou invité à approuver une demande sans preuve. Le contrôle doit spécifier qui approuve, quelles preuves ils vérifient, quel canal ils utilisent, si la demande est hors bande, comment la décision est journalisée et comment les clients à haut risque peuvent imposer leurs propres exigences.

Dans un processus de support, cela peut signifier que changer l'e-mail d'un utilisateur client nécessite une confirmation via un domaine contrôlé par l'admin client, pas via la session demanderesse. Les réinitialisations de mot de passe pour les utilisateurs privilégiés peuvent nécessiter l'approbation de l'admin client. Les réinitialisations MFA peuvent nécessiter une réinscription avec clé matérielle, des délais d'attente et une notification aux admins existants. Les employés de support ne devraient pas demander aux utilisateurs de lire des OTP par voix ou SMS.

Le personnel IT ne devrait pas appeler les employés pour collecter des codes. Toute demande de partage de code devrait être traitée comme hostile par défaut. Les outils de support internes devraient avertir et bloquer les actions qui ressemblent à des chaînes de prise de contrôle.

Les fournisseurs d'identité peuvent aider avec la politique, mais ils ne peuvent pas remplacer complètement la conception du processus. Okta, Google et d'autres fournisseurs peuvent imposer une authentification plus forte, la confiance dans l'appareil, des politiques de session et des journaux. Les journaux d'audit de Google Cloud àhttps://cloud.google.com/logging/docs/auditmontrent la valeur générale des enregistrements d'activité administrative dans les environnements cloud. Mais si un processus de support est autorisé à contourner l'identité en modifiant les enregistrements utilisateurs, le fournisseur d'identité peut seulement voir la connexion en aval. Le fournisseur et le client ont besoin de journaux de processus métier également.

Les conseils de la CISA sur la conception sécurisée par défaut àhttps://www.cisa.gov/securebydesignet les principes de sécurisé par défaut sont pertinents ici car le produit plus sûr devrait rendre les actions de support dangereuses plus difficiles par défaut. Le cadre de cybersécurité du NIST àhttps://www.nist.gov/cyberframeworkfournit la structure identifier, protéger, détecter, répondre et récupérer: identifier les actions de support à haut risque, les protéger avec une approbation et une authentification solides, détecter les schémas de prise de contrôle inhabituels, répondre en verrouillant les comptes et en révoquant les sessions, et récupérer en restaurant les comptes et en validant l'activité en aval. Ce ne sont pas des étiquettes de conformité abstraites; elles correspondent directement au chemin de l'incident Retool.

La leçon sur le canal de support s'applique également à l'IT interne. Les délais des avantages des employés, les problèmes de paie, les migrations SSO et les réinitialisations d'appareils sont des thèmes d'attaque prévisibles. Les organisations devraient préannoncer les schémas de support de migration, publier des canaux de support vérifiés, interdire les demandes de code, former les employés à terminer les appels inattendus et exiger une confirmation hors bande pour les actions d'identité. Les préoccupations liées au deepfake rendent la familiarité vocale informelle plus faible comme méthode d'assurance.

Le post-mortem de Retool a déclaré que l'attaquant a utilisé une voix familière deepfakée et une connaissance des processus internes. Qu'une future attaque utilise un deepfake audio ou un imposteur humain convaincant, la défense doit éviter de se fier uniquement à la voix.

Les achats et la réponse aux incidents devraient demander des preuves de processus

L'incident Retool modifie également ce que les achats d'entreprise devraient demander aux fournisseurs d'outils internes et d'automatisation. Un questionnaire de sécurité générique peut demander si le fournisseur prend en charge SAML, MFA, SCIM, journaux d'audit et chiffrement. Ces questions sont utiles, mais elles n'atteignent pas le problème du processus de support. La question plus importante est de savoir si les employés du fournisseur peuvent effectuer des actions de compte ayant un impact sur le client, sous quelles conditions, avec quelles approbations et avec quels journaux visibles par le client.

Une plateforme peut avoir SAML et MFA pour les utilisateurs clients tout en exposant les clients à des actions de support côté fournisseur qui modifient le contrôle du compte.

Les acheteurs devraient donc demander le modèle d'action administrative. Le personnel de support peut-il usurper l'identité des utilisateurs? Peut-il changer les adresses e-mail? Peut-il réinitialiser les mots de passe? Peut-il désactiver MFA? Peut-il voir les secrets ou les identifiants de ressources? Peut-il déclencher l'exécution d'applications? Peut-il accéder directement aux applications clientes? Quelles de ces actions sont impossibles, lesquelles sont possibles uniquement avec l'approbation du client, et lesquelles sont possibles lors d'un support d'urgence?

Le but n'est pas d'interdire toute action de support. Les clients d'entreprise veulent souvent que les équipes de support résolvent rapidement les problèmes de compte. Le but est de rendre le pouvoir de support explicite, journalisé, lié à la politique et aligné sur le risque du client.

Les mêmes questions devraient être posées en interne par les clients utilisant Retool. Un administrateur Retool client peut croire que l'incident du fournisseur est distant, mais le rôle de la plateforme dans l'environnement client détermine l'impact. Si une application Retool peut interroger une base de données de production avec des permissions d'écriture larges, alors un compte Retool compromis peut être beaucoup plus grave qu'un visualiseur de tableau de bord compromis. Si l'application ne peut que lire une vue de reporting limitée, la même prise de contrôle de compte peut être contenue.

Si un processus peut approuver un retrait, émettre un remboursement, modifier un enregistrement de paie ou mettre à jour un champ d'identité client, alors l'approbation au niveau de l'application et la détection d'anomalies comptent autant que la sécurité de la connexion.

La réponse aux incidents devrait également être préplanifiée. Les clients devraient savoir comment geler les utilisateurs Retool, révoquer les sessions, faire pivoter les identifiants de ressources, examiner les journaux d'audit, désactiver les applications à haut risque, informer les propriétaires métier et vérifier les systèmes en aval. La documentation de Retool donne quelques outils d'audit et de gestion des utilisateurs, mais chaque client doit les mapper à ses propres ressources.

Une application d'opérations crypto, un tableau de bord de gestion de prêts, une console de support client et un panneau d'administration d'entrepôt nécessiteront différentes étapes de confinement. Le chemin de prise de contrôle décrit par Retool rappelle que le premier événement visible peut être une connexion d'apparence ordinaire suivie d'actions légitimes de l'application.

Les fournisseurs devraient également fournir aux clients des artefacts spécifiques à l'incident qui vont au-delà d'un post-mortem narratif. Les artefacts utiles incluent les identifiants de compte affectés, les horodatages précis, les actions de support effectuées, les adresses IP et agents utilisateur lorsqu'il est sûr de les divulguer, les noms d'événements de journal d'audit, les champs restaurés, les actions requises du client et les limites connues de l'enquête. Certaines de ces informations doivent être traitées en privé pour éviter d'exposer des détails sensibles.

Mais sans cela, les clients doivent déduire si un compte restauré signifie qu'aucune action en aval n'a eu lieu. La charge de la preuve devrait correspondre au risque du workflow.

L'implication pour les achats n'est pas que chaque client doit auto-héberger Retool. C'est que le choix de déploiement devrait être lié à la puissance des applications construites. Un tableau de bord interne à faible risque peut être confortablement placé dans un service cloud géré. Une application qui peut déplacer des fonds, administrer l'identité client ou modifier des enregistrements réglementés peut justifier l'auto-hébergement, des clés détenues par le client, des restrictions d'accès au fournisseur, une conservation d'audit plus forte ou des limites de support contractuelles.

La propre distinction cloud vs sur site de Retool dans l'incident fait de ce choix architectural une partie de la responsabilité plutôt qu'un détail d'implémentation.

Pour les clients réglementés, les mêmes preuves devraient alimenter les dossiers de risque fournisseur et de conformité. Un rapport SOC ou un aperçu de sécurité peut montrer des contrôles de base, mais la responsabilité spécifique à l'incident demande si le fournisseur peut démontrer que l'ingénierie sociale, la récupération MFA, les outils de support internes et l'administration des comptes clients ont été reconçus après l'échec. Un client n'a pas besoin de chaque capture d'écran interne ou note médico-légale.

Il a besoin de suffisamment de preuves pour décider si le canal de support peut toujours modifier le contrôle client sans que le client ne le voie à temps.

Limites de preuve et inconnues

Les preuves publiques soutiennent plusieurs conclusions claires. Retool a divulgué un incident de spear-phishing et d'ingénierie sociale le 27 août 2023. Il a déclaré que 27 clients cloud ont été informés le 29 août d'un accès non autorisé à leurs comptes. Il a déclaré que les comptes sur site et gérés n'ont pas été accédés. Il a déclaré que l'attaquant a utilisé un leurre SMS, un portail d'identité factice, un appel téléphonique, une voix familière deepfakée et un code MFA supplémentaire.

Il a déclaré que l'accès au compte Google de l'employé a exposé les codes d'authentificateur synchronisés, permettant l'accès VPN et l'administration interne. Il a déclaré que l'attaquant a changé des e-mails, réinitialisé des mots de passe et a fouiné dans certaines applications Retool. Il a déclaré que Retool a révoqué les sessions, verrouillé les comptes, informé les clients, restauré les comptes et travaillé avec les forces de l'ordre et un cabinet d'expertise médico-légale tiers.

Les preuves publiques ne soutiennent pas des affirmations plus larges sans qualification. Elles n'identifient pas chaque client affecté dans le propre billet de Retool. Elles ne prouvent pas que tous les clients cloud de Retool étaient affectés. Elles ne montrent pas que les comptes sur site ou gérés ont été accédés. Elles ne fournissent pas le rapport médico-légal complet. Elles ne prouvent pas chaque action ou perte client en aval. Elles n'établissent pas une conclusion réglementaire contre Google, Okta ou Retool. Elles ne montrent pas chaque changement de contrôle interne que Retool a mis en œuvre après l'incident.

Ces inconnues devraient être nommées plutôt que comblées par des spéculations.

Il y a des lacunes de preuve importantes pour les acheteurs d'entreprise. Retool a-t-il supprimé les OTP basés sur des codes de tous les systèmes internes privilégiés? Quelles actions de support nécessitent maintenant une étape matérielle ou une double approbation? Les clients d'entreprise peuvent-ils imposer des politiques d'approbation de support personnalisées? Quels événements de journal d'audit montrent les actions de support Retool dans les environnements clients?

Comment les ingénieurs de support sont-ils empêchés de modifier les champs d'e-mail ou de mot de passe pour les clients à haut risque sans confirmation détenue par le client? Comment les notifications clients sont-elles déclenchées pour les changements administratifs? Comment Retool vérifie-t-il que les graines d'authentificateur synchronisées dans le cloud ne sont pas utilisées pour l'accès interne privilégié? La documentation publique ne répond qu'en partie à cela.

Les clients doivent également examiner leur propre côté. Leurs applications Retool avaient-elles des flux d'approbation pour les actions irréversibles? Les ressources de production étaient-elles exposées via des permissions Retool larges? Les journaux d'audit ont-ils capturé l'exécution des requêtes et les changements de compte pendant la fenêtre? Les systèmes en aval ont-ils pu détecter des actions inhabituelles provenant de sessions Retool légitimes? Les identifiants de ressources avaient-ils le moindre privilège?

Une prise de contrôle de compte utilisateur pouvait-elle effectuer des transferts, des exportations de données ou des mises à jour privilégiées sans confirmation indépendante? L'incident du fournisseur est le déclencheur, mais la conception de l'application client détermine une grande partie du préjudice.

La norme de preuve la plus forte est donc bilatérale. Retool devrait pouvoir prouver que les chemins d'identité et de support internes ont été durcis après l'incident. Les clients devraient pouvoir prouver que leurs applications Retool ne peuvent pas convertir une prise de contrôle de compte en un préjudice opérationnel non contrôlé. La documentation de Google et des fournisseurs d'identité devrait aider les organisations à comprendre où les facteurs d'authentification sont stockés et s'ils sont véritablement indépendants.

Le dossier de responsabilité est incomplet si une partie considère la présence d'une invite MFA comme la fin de l'analyse.

Pourquoi cela compte encore en 2026

L'incident Retool reste important en 2026 car les plateformes d'automatisation d'entreprise deviennent plus centrales dans les opérations. Les plateformes low-code et d'outils internes permettent aux équipes de construire plus vite, de connecter plus de systèmes et de déplacer les workflows métier hors des feuilles de calcul et des scripts ad hoc. C'est précieux. Cela signifie également que la gestion des comptes, les outils de support et la récupération d'identité peuvent devenir des plans de contrôle pour les workflows financiers, crypto, de santé, logistiques, de support et de conformité.

Une compromission du canal de support peut devenir une compromission du processus métier.

L'événement démontre également que les fonctionnalités de commodité peuvent modifier silencieusement les hypothèses de sécurité. Les codes d'authentificateur synchronisés dans le cloud aident les utilisateurs à récupérer après une perte d'appareil et à passer d'un téléphone à l'autre. Ils exigent également que les administrateurs comprennent si le facteur reste indépendant du compte protégé. Les migrations SSO facilitent la gestion de l'identité. Elles créent aussi des fenêtres d'attaque lorsque les employés s'attendent à des invites d'identité et à des messages de support.

Les outils de support internes rendent l'aide client plus rapide. Ils concentrent également des actions administratives qui nécessitent des contrôles plus stricts que l'utilisation ordinaire de l'application.

Pour les fournisseurs, la leçon durable est de concevoir le support comme un environnement hostile. Les employés de support ne devraient pas pouvoir contourner les garanties d'identité à la légère. Les changements de compte ayant un impact sur le client devraient être à friction élevée, journalisés et visibles pour les administrateurs clients. Les applications internes privilégiées devraient nécessiter une authentification résistante au phishing et une preuve de session liée à l'appareil. Les flux de récupération devraient supposer que les attaquants connaissent le vocabulaire interne et peuvent imiter des voix.

Les rapports d'incident destinés aux clients devraient séparer les faits confirmés, l'interprétation de l'entreprise et les inconnues avec suffisamment de précision pour que les clients puissent agir.

Pour les clients, la leçon est de traiter Retool et les plateformes similaires comme des logiciels de production, même lorsqu'ils sont construits par des équipes opérationnelles plutôt que par des équipes d'ingénierie traditionnelles. Les applications qui peuvent déplacer de l'argent, modifier des enregistrements clients, exposer des données réglementées ou déclencher des workflows irréversibles ont besoin de conception de rôles, d'approbations, de journaux d'audit, de moindre privilège pour les ressources et d'exercices de récupération.

Les clients devraient savoir s'ils utilisent un déploiement cloud, géré ou auto-hébergé et ce que cela signifie pour l'accès de support du fournisseur. Ils devraient demander comment les actions de support sont journalisées et s'ils peuvent exiger une approbation pour les changements de compte.

Pour les équipes d'identité, l'incident rappelle que le facteur n'est pas seulement l'invite. Le facteur est le modèle de garde derrière l'invite. Un TOTP affiché dans une application, copié dans un compte cloud, lu lors d'un appel téléphonique ou saisi dans un portail factice n'est pas équivalent à un authentificateur matériel résistant au phishing. L'architecture MFA doit être évaluée par le chemin de l'attaquant: que se passe-t-il si l'utilisateur est victime de phishing, si la session est volée, si le canal de récupération est abusé, ou si le canal de support est usurpé?

La conclusion finale de responsabilité est basée sur les preuves et bornée. Retool a confirmé publiquement qu'une attaque d'ingénierie sociale a contribué à un accès non autorisé affectant 27 comptes clients cloud et que les comptes sur site et gérés n'ont pas été accédés. Les preuves publiques ne justifient pas d'alléguer une compromission de tous les clients ou de tous les déploiements Retool. Les preuves publiques justifient de traiter l'incident comme un test de processus de support et de responsabilité MFA.

Le cas montre que la confiance dans l'automatisation d'entreprise dépend non seulement des fonctionnalités de l'application, mais aussi des processus de support et d'identité qui peuvent changer qui contrôle ces applications.

Registre des sources