article://twilio-cloudflare-phishing-2022

Twilio et Cloudflare face au phishing en 2022

Des SMS très proches ont conduit à deux résultats différents. La comparaison aide surtout à voir ce qui se passe après la saisie du mot de passe.

Cette page existe dans une autre langue. EN

À quelques semaines d’intervalle, Twilio et Cloudflare ont raconté des campagnes de phishing par SMS qui se ressemblaient beaucoup. Les messages se faisaient passer pour des communications internes et renvoyaient vers de fausses pages Okta. Des salariés ont saisi leurs identifiants dans les deux cas. C’est ensuite que les trajectoires divergent.

Twilioaccès obtenu
  1. SMS usurpant une fonction interne
  2. identifiants saisis sur une fausse page
  3. accès à des outils internes
  4. informations clients atteintes
Cloudflareaccès bloqué
  1. SMS et fausse page Okta
  2. trois saisies d’identifiants
  3. clé physique encore exigée
  4. aucun système compromis selon Cloudflare

Ce qui s’est passé chez Twilio

Le bilan final de Twilio, publié le 27 octobre 2022, parle de SMS envoyés à des salariés actuels et anciens. Les messages imitaient des fonctions informatiques ou administratives. Après la saisie des identifiants sur les fausses pages, les attaquants ont pu entrer dans des outils internes et consulter certaines informations clients.

Twilio indique que 209 clients et 93 utilisateurs Authy ont été affectés. Ce sont deux catégories différentes, pas un total homogène qu’il suffirait d’additionner. Le point important est plutôt la portée d’un compte interne : quelques accès peuvent ouvrir sur les données de nombreuses personnes qui n’ont jamais reçu le SMS frauduleux.

Le rapport public ne permet pas de reconstituer chaque règle d’authentification appliquée à l’époque. Je préfère donc éviter le raccourci selon lequel Twilio n’aurait eu « aucune MFA ». Ce que l’on sait, c’est qu’un accès exploitable a été obtenu et que l’entreprise a ensuite réinitialisé des identifiants, révoqué des sessions, bloqué des indicateurs et demandé la suppression de domaines frauduleux.

Pourquoi Cloudflare s’est arrêté une étape plus tôt

Cloudflare situe sa campagne au 20 juillet 2022. Trois salariés ont saisi leurs identifiants sur la fausse page. Les applications visées demandaient encore une preuve fournie par une clé de sécurité physique. La page frauduleuse ne pouvait pas fabriquer cette preuve pour le vrai service. Cloudflare dit n’avoir constaté aucune compromission de ses systèmes pendant cet épisode.

Les trois saisies restent utiles à analyser : le message a fonctionné sur le plan humain. Mais elles n’ont pas eu le même effet qu’une connexion réussie. Le dispositif technique a absorbé l’erreur et empêché la transition suivante.

Cette résistance dépend de la couverture réelle du contrôle. Une clé protège peu si une application oubliée accepte un facteur plus faible, si la récupération de compte contourne l’exigence ou si une exception devient le chemin normal. Cloudflare a d’ailleurs publié séparément un retour d’expérience sur le déploiement progressif de FIDO2 et la couverture de ses applications.

Une comparaison utile, avec des limites

Il ne s’agit pas d’une expérience contrôlée. Les utilisateurs, les droits, les applications et les informations rendues publiques ne sont pas identiques. Les deux entreprises racontent elles-mêmes leurs incidents, avec le niveau de détail qu’elles ont choisi de publier.

La comparaison permet néanmoins d’isoler une différence concrète : chez Cloudflare, le mot de passe récupéré ne suffisait pas à franchir l’étape suivante. Chez Twilio, un accès interne exploitable a été obtenu. Cela ne permet pas de classer globalement les deux entreprises, mais cela montre ce qu’apporte une preuve liée au service auquel on se connecte.

Après la connexion, les droits comptent aussi

L’histoire ne s’arrête pas à l’écran de connexion. Un compte d’assistance ou d’administration peut donner accès à des informations appartenant à plusieurs clients. Le moindre privilège réduit cette portée : droits limités à la tâche, accès temporaires pour les opérations sensibles et traces suffisamment précises pour comprendre ce qui a été consulté.

Je retiens donc trois mesures séparées : la personne a-t-elle répondu au leurre, l’attaquant a-t-il obtenu un accès, et cet accès a-t-il produit un préjudice ? Les regrouper dans un unique « taux d’échec humain » cache justement la partie intéressante de ces deux incidents.

Sources

nav@bacchus:~

bacchus-dev.com navigation console · v1.0.0

Tapez help pour afficher les commandes.

Tab autocomplete · ↑↓ history · Esc close · inputs stay local