Comment s'est produite la fuite de données d'Optus et comment l'éviter ?

1. Introduction#

En septembre 2022, Optus, l'un des principaux fournisseurs de télécommunications en Australie, a subi une fuite de données ayant exposé les informations personnelles de près de 10 millions de clients. Cet incident a marqué l'une des plus importantes cyberattaques de l'histoire australienne, suscitant de vives inquiétudes quant à la confidentialité des données et aux pratiques de sécurité dans le pays.

Cet article se concentrera sur les questions suivantes :

• Quelles failles de sécurité Optus présentait-elle pour mener à la fuite de données ?
• Quelles sont quelques-unes des contre-mesures qu'Optus aurait pu utiliser pour éviter cette faille de sécurité ?

2. Les failles de sécurité ayant mené à la fuite de données d'Optus#

Vous trouverez ci-dessous les 5 failles de sécurité de la fuite de données chez Optus.

2.1 Faille de sécurité n°1 : Une API publique exposée#

La première faille de sécurité majeure dans la violation d'Optus a été l'utilisation d'une API (Interface de Programmation d'Application) publique qui a facilité l'accès à des données internes sensibles. Les API publiques sont conçues pour permettre à des systèmes externes d'interagir avec les services d'une entreprise, mais lorsque ces API ne sont pas correctement sécurisées, elles peuvent devenir une passerelle pour les attaquants.

À quoi servent les API publiques ?

Les API publiques sécurisées, comme par exemple l'API de Google Maps ou de météo, fournissent des données limitées et non sensibles aux systèmes externes. Elles sont conçues pour isoler toute donnée partagée des opérations commerciales principales, les rendant intrinsèquement plus sûres.

Pourquoi les API publiques posent-elles problème dans ce cas ?

Contrairement aux API sécurisées, l'API d'Optus a exposé des informations clients sensibles et manquait de protections essentielles. Cela l'a rendue vulnérable aux attaquants qui ont pu la localiser via des analyses Internet.

Comment les attaquants ont-ils pu exploiter cette API ?

Sans authentification ni isolation des données, les attaquants ont pu se connecter directement à l'API et récupérer des informations clients confidentielles, contournant ainsi les mesures de sécurité internes.

2.2 Faille de sécurité n°2 : Une API non sécurisée accordant l'accès à des données clients sensibles#

La deuxième faille de sécurité majeure de la fuite de données d'Optus était que l'API n'était pas sécurisée. Elle accordait donc l'accès à des données clients hautement sensibles. Alors que le premier problème tournait autour du fait que l'API était publique, le problème critique ici était son manque de contrôles d'accès appropriés, ce qui a permis un accès sans restriction à des informations confidentielles.

Lorsqu'un client d'Optus accède à son compte via l'application mobile ou le site Web d'Optus, les API facilitent la communication entre les systèmes front-end et back-end pour récupérer les données nécessaires. Ces processus back-end manipulent souvent des informations sensibles pour charger les profils des clients.

Dans ce cas, l'API exposée a fourni aux attaquants un accès direct aux types de données personnelles suivants, particulièrement précieux pour l'usurpation d'identité et la fraude :

• Numéros de permis de conduire • Numéros de téléphone • Dates de naissance • Adresses personnelles

Une analyse des enregistrements publics du DNS (Domain Name System) a révélé plus tard que cette API était probablement publique et accessible à quiconque sur Internet pendant un maximum de trois mois.

2.3 Faille de sécurité n°3 : L'utilisation d'identifiants clients incrémentaux#

La troisième faille de sécurité de la fuite de données d'Optus a été l'utilisation d'identifiants clients incrémentaux. Dans le monde numérique, les identifiants uniques des clients — composés de séquences aléatoires de chiffres et de lettres — sont utilisés pour différencier les comptes de manière sécurisée. Les meilleures pratiques en matière de cybersécurité dictent que ces identifiants doivent être aléatoires et sans lien, afin d'empêcher les pirates d'identifier des schémas.

L'identifiant client d'Optus : Dans ce cas, les identifiants clients suivaient un schéma prévisible, différant d'un incrément de 1. Par exemple, si l'identifiant d'un client était 5332, le suivant serait 5333. Une fois que le pirate a eu accès à la base de données, il a pu écrire un script automatisé pour récupérer chaque enregistrement simplement en incrémentant l'identifiant.

Cette approche automatisée a accéléré le processus de vol de données, permettant à l'attaquant d'exfiltrer des données clients sensibles à grande échelle. Le défaut de conception prévisible a permis à la violation d'Optus de se produire plus rapidement et d'affecter plus de clients que ce qui aurait été possible autrement.

2.4 Faille de sécurité n°4 : Des contrôles d'accès affaiblis à cause d'une erreur de codage#

Outre les vulnérabilités de l'API et des identifiants clients, il y a eu d'autres problèmes de sécurité : en 2018, une erreur de codage a affaibli les contrôles d'accès sur certains domaines d'Optus, les rendant moins sécurisés. Bien qu'Optus ait corrigé ce problème sur son site Web principal en août 2021, l'entreprise n'a pas appliqué le même correctif à un site Web secondaire qui était accessible sur Internet. Ce domaine secondaire est resté vulnérable jusqu'à la découverte de la fuite en septembre 2022.

Cet oubli a laissé une faille de sécurité importante. Les domaines publics sont une cible courante pour les attaquants, et toute faille non corrigée augmente le risque d'accès non autorisé. Dans ce cas, l'erreur de codage a permis aux attaquants de contourner les contrôles d'accès et d'accéder à des données sensibles.

Négliger des domaines secondaires ou moins visibles peut laisser des vulnérabilités critiques ouvertes, que les attaquants peuvent exploiter avec facilité. Des audits réguliers et des tests approfondis sont essentiels pour s'assurer que les mises à jour de sécurité sont appliquées partout où elles sont nécessaires.

2.5 Faille de sécurité n°5 : Un second domaine vulnérable#

Ce manque de supervision adéquate s'est étendu au domaine secondaire, qui a joué un rôle clé dans la violation. Bien que le domaine n'ait pas été activement utilisé, il est resté en ligne et non protégé pendant une longue période. Bien qu'il ne soit pas nécessaire aux opérations quotidiennes, il n'a été ni sécurisé avec des contrôles d'accès appropriés ni mis hors service, créant un point d'entrée facile à exploiter pour les attaquants.

Même lorsqu'ils ne sont pas utilisés activement, de tels domaines peuvent toujours servir de vecteurs d'attaque si des vulnérabilités existent. Pour atténuer ces risques, les entreprises doivent auditer régulièrement leurs actifs numériques, mettre rapidement hors service les domaines inutilisés ou appliquer le même niveau de sécurité qu'aux systèmes actifs.

3. Comment éviter de telles fuites de données ?#

Pour éviter des fuites de données similaires au piratage d'Optus et atténuer le risque d'atteinte à la réputation, les organisations peuvent adopter différentes stratégies de sécurité que vous trouverez ci-dessous :

3.1 Contre-mesure n°1 : Se référer au projet de sécurité des API de l'OWASP#

Le projet de sécurité des API de l'OWASP est une ressource régulièrement mise à jour qui met en évidence les risques de sécurité connus liés aux API. Il est essentiel pour les équipes de cybersécurité de surveiller régulièrement cette base de données afin d'identifier et de traiter les vulnérabilités qui pourraient avoir un impact sur leur entreprise. Il couvre un large éventail de risques potentiels, par exemple :

• Rupture de l'autorisation au niveau des objets (BOLA) : Des failles dans les permissions d'accès des utilisateurs permettant un accès non autorisé aux données.

• Exposition excessive des données : Des API retournant plus d'informations que nécessaire, augmentant le risque de fuite de données sensibles.

• Défauts de configuration de sécurité : Des paramètres mal ajustés ou par défaut qui exposent des API sensibles aux attaques.

• Failles d'injection : Des attaquants exploitant des API pour injecter des commandes ou des données malveillantes.

3.2 Contre-mesure n°2 : Sécuriser toutes les API avec un protocole d'authentification#

Le projet de sécurité des API de l'OWASP souligne que les API non authentifiées constituent la deuxième vulnérabilité la plus courante. Ces API ne nécessitent pas de nom d'utilisateur, de mot de passe ou d'une autre méthode d'authentification pour établir une connexion, les laissant extrêmement vulnérables à l'exploitation. Ce type de faiblesse a joué un rôle central dans la fuite de données d'Optus.

Dans certains cas, les API sont intentionnellement laissées sans authentification pour maintenir la compatibilité avec les systèmes hérités ou à des fins de test. Il est probable qu'Optus ait laissé son API sans authentification pour des raisons similaires. Cependant, quelle que soit l'importance des tests ou des exigences des systèmes hérités, le déploiement d'une API — qu'elle soit interne ou publique — sans authentification constitue un risque de sécurité important.

Comment prévenir l'exploitation d'API non authentifiées

Pour protéger vos API, chaque demande de connexion doit être sécurisée par l'authentification multifacteur (MFA). La MFA ajoute une couche de protection supplémentaire en exigeant plusieurs formes de vérification, ce qui en fait l'un des moyens les plus efficaces et simples de bloquer l'accès non autorisé aux API et aux comptes utilisateurs.

Identification des vulnérabilités cachées des API

Une politique de sécurité des API n'est efficace que si toutes les API nécessitant une protection sont prises en compte. Mais que se passe-t-il si votre organisation est involontairement exposée par une API publique, comme ce fut le cas avec Optus ?

Les API cachées ou négligées sont difficiles à détecter à l'aide d'outils d'analyse standard. Le moyen le plus efficace de les découvrir est d'effectuer des tests d'intrusion pour exposer des vulnérabilités telles que :

• Des mécanismes d'authentification faibles : Les systèmes acceptant des mots de passe en texte clair ou des identifiants mal hachés.

• L'exposition aux attaques de bourrage d'identifiants ou de force brute : L'exploitation de noms d'utilisateur et de mots de passe volés à grande échelle.

• La manipulation des paramètres de l'API : La révélation de détails d'authentification sensibles dans les URL ou les réponses.

4. Conclusion#

En conclusion, la fuite de données d'Optus souligne l'importance critique de mettre en œuvre des mesures de cybersécurité robustes et d'auditer régulièrement les actifs numériques. L'échec de la sécurisation des API, de l'application de protocoles d'authentification appropriés et de la résolution des vulnérabilités négligées sur les domaines secondaires a grandement contribué à cet incident. En adoptant les meilleures pratiques de l'industrie, telles que celles décrites dans le projet de sécurité des API de l'OWASP, et en priorisant des stratégies de sécurité complètes, les organisations peuvent se prémunir contre des fuites similaires, protéger les données sensibles des clients et, plus important encore, conserver la confiance de leurs utilisateurs.

À propos de Corbado

Corbado est la Passkey Intelligence Platform pour les équipes CIAM qui gèrent l'authentification client à grande échelle. Nous vous montrons ce que les logs IDP et les outils d'analytics génériques ne voient pas : quels appareils, versions d'OS, navigateurs et gestionnaires de credentials prennent en charge les passkeys, pourquoi les enrôlements ne deviennent pas des connexions, où le flux WebAuthn échoue et quand une mise à jour OS ou navigateur casse silencieusement la connexion — le tout sans remplacer Okta, Auth0, Ping, Cognito ni votre IDP interne. Deux produits : Corbado Observe ajoute l'observabilité pour les passkeys et toute autre méthode de connexion. Corbado Connect apporte des passkeys managés avec analytics intégrés (aux côtés de votre IDP). VicRoads gère les passkeys pour plus de 5M d'utilisateurs avec Corbado (+80 % d'activation passkey). Parler à un expert Passkey →

Foire aux questions#

Quelles données personnelles ont été volées lors de la fuite d'Optus et pourquoi est-ce si préjudiciable ?#

L'API exposée a donné aux attaquants un accès direct aux numéros de permis de conduire, aux numéros de téléphone, aux dates de naissance et aux adresses personnelles. Ces types de données sont particulièrement précieux pour l'usurpation d'identité et la fraude, rendant la violation particulièrement dommageable pour les clients concernés.

Pourquoi une entreprise laisserait-elle une API non authentifiée en premier lieu ?#

Les API sont parfois intentionnellement laissées sans authentification pour maintenir la compatibilité avec les systèmes existants ou à des fins de test, ce qui était probablement le cas pour Optus. Cependant, déployer une API, qu'elle soit interne ou publique, sans authentification constitue un risque de sécurité important, quelle que soit la justification opérationnelle.

Comment les équipes de sécurité peuvent-elles découvrir les API cachées ou négligées avant que les attaquants ne les exploitent ?#

Les outils d'analyse standard ont du mal à détecter les API cachées ou négligées. L'approche la plus efficace est le test d'intrusion, qui peut exposer des mécanismes d'authentification faibles, l'exposition aux attaques de bourrage d'identifiants et la révélation de détails d'authentification sensibles dans les URL ou les réponses de l'API.

Qu'est-ce que le projet de sécurité des API de l'OWASP et comment aide-t-il les organisations à éviter des violations comme celle d'Optus ?#

Le projet de sécurité des API de l'OWASP est une ressource régulièrement mise à jour répertoriant les risques de sécurité connus liés aux API, tels que la rupture de l'autorisation au niveau des objets, l'exposition excessive des données, les défauts de configuration de sécurité et les failles d'injection. Les équipes de cybersécurité devraient le surveiller régulièrement pour identifier et traiter les vulnérabilités avant que les attaquants puissent les exploiter.