Les domaines expirés Google Workspace peuvent être compromis par les nouveaux propriétaires,quand l’abandon des domaines expose entreprises et utilisateurs à des cybermenaces
Lorsqu’une entreprise ou un utilisateur configure Google Apps (aujourd’hui connu sous le nom de Google Workspace), un domaine personnalisé est souvent utilisé pour gérer les emails et les services associés. Si ce domaine expire ou est abandonné, il peut être racheté par une autre personne. Cependant, Google conserve certains enregistrements liés au domaine dans ses systèmes. Cela signifie que si un tiers malintentionné rachète le domaine, il peut potentiellement récupérer les accès à certains services ou même intercepter des communications sensibles.
De nombreuses startups utilisent la suite de productivité de Google, connue sous le nom de Workspace, pour gérer le courrier électronique, les documents et d'autres aspects administratifs. De même, de nombreuses applications web à vocation commerciale utilisent OAuth de Google, le flux d'authentification qui propose de « Se connecter avec Google ». Il s'agit d'une boucle de rétroaction à faible friction, jusqu'à ce que la startup échoue, que le domaine soit mis en vente et que quelqu'un oublie de fermer toutes les applications Google.
Dylan Ayrey, de Truffle Security Co, suggère dans un rapport que ce problème est plus grave que quiconque, en particulier Google, ne le reconnaît. De nombreuses startups commettent l'erreur grave de ne pas fermer correctement leurs comptes, tant sur Google que sur d'autres applications web, avant de laisser leurs domaines expirer.
Compte tenu du nombre de personnes travaillant dans des startups technologiques (6 millions), du taux d'échec de ces startups (90 %), de leur utilisation des espaces de travail Google (50 %, selon les chiffres d'Ayrey) et de la vitesse à laquelle les startups ont tendance à s'effondrer, il y a beaucoup de domaines connectés à Google-auth qui sont à vendre à tout moment. Cela ne constituerait pas un problème en soi, sauf que, comme le montre Ayrey, l'achat d'un domaine avec un compte Google encore actif peut vous permettre de réactiver les comptes Google d'anciens employés.
Avec un accès administrateur à ces comptes, vous pouvez accéder à de nombreux services pour lesquels ils utilisaient OAuth de Google, comme Slack, ChatGPT, Zoom et les systèmes de ressources humaines. Ayrey écrit qu'il a acheté un ancien domaine de startup et qu'il a accédé à chacun d'entre eux par le biais de la connexion à un compte Google. Il s'est retrouvé avec des documents fiscaux, des détails d'entretiens d'embauche et des messages directs, entre autres documents sensibles.
J'ai parcouru l'ensemble des données de Crunchbase sur les startups et j'ai trouvé plus de 100 000 domaines actuellement disponibles à l'achat auprès de startups qui ont échoué.
Si chaque startup ayant échoué compte en moyenne 10 employés au cours de sa vie et utilise 10 services SaaS différents, nous parlons d'un accès aux données sensibles de plus de 10 millions de comptes.
Pour comprendre le problème, jetons un coup d'œil rapide à Oauth :
L'explication simplifiée de Dylan Ayrey sur le fonctionnement de Google (ou de la plupart des autres) OAuth lors de la connexion à un service tiers comme Slack.
Lorsque vous utilisez le bouton « Se connecter avec Google », Google envoie au service (par exemple, Slack) un ensemble d'informations sur l'utilisateur.
Exemple d'un ensemble de revendications par défaut.
Ces revendications sont généralement les suivantes
Le fournisseur de services (par exemple Slack) utiliserait l'une de ces revendications ou les deux pour déterminer si l'utilisateur peut se connecter.
L'allégation HD pourrait être utile pour dire « Tout le monde à exemple.com peut se connecter à l'espace de travail exemple.com »
Quant à l'allégation relative à l'adresse électronique, elle est utilisée pour connecter les utilisateurs à leur compte spécifique.
Voici le problème : Si un service (par exemple, Slack) repose uniquement sur ces deux revendications, les changements de propriété du domaine ne seront pas différents pour Slack. Lorsque quelqu'un achète le domaine d'une entreprise disparue, il hérite des mêmes revendications, ce qui lui permet d'accéder aux anciens comptes des employés.
Si chaque startup ayant échoué compte en moyenne 10 employés au cours de sa vie et utilise 10 services SaaS différents, nous parlons d'un accès aux données sensibles de plus de 10 millions de comptes.
Pour comprendre le problème, jetons un coup d'œil rapide à Oauth :
L'explication simplifiée de Dylan Ayrey sur le fonctionnement de Google (ou de la plupart des autres) OAuth lors de la connexion à un service tiers comme Slack.
Lorsque vous utilisez le bouton « Se connecter avec Google », Google envoie au service (par exemple, Slack) un ensemble d'informations sur l'utilisateur.
Exemple d'un ensemble de revendications par défaut.
Ces revendications sont généralement les suivantes
- hd (hosted domain) : Spécifie le domaine, par exemple, example.com.
- email : L'adresse électronique de l'utilisateur, par exemple user@example.com.
Le fournisseur de services (par exemple Slack) utiliserait l'une de ces revendications ou les deux pour déterminer si l'utilisateur peut se connecter.
L'allégation HD pourrait être utile pour dire « Tout le monde à exemple.com peut se connecter à l'espace de travail exemple.com »
Quant à l'allégation relative à l'adresse électronique, elle est utilisée pour connecter les utilisateurs à leur compte spécifique.
Voici le problème : Si un service (par exemple, Slack) repose uniquement sur ces deux revendications, les changements de propriété du domaine ne seront pas différents pour Slack. Lorsque quelqu'un achète le domaine d'une entreprise disparue, il hérite des mêmes revendications, ce qui lui permet d'accéder aux anciens comptes des employés.
- Accès aux données sensibles : Les nouveaux propriétaires du domaine peuvent utiliser la récupération de comptes pour accéder à des services Google associés au domaine.
- Usurpation d’identité : Avec un contrôle total sur le domaine, ils peuvent créer des adresses email similaires à celles utilisées auparavant par l’entreprise, facilitant ainsi des attaques de phishing ou la diffusion d’informations frauduleuses.
- Compromission de comptes tiers : Si des services externes utilisent l’email lié à l’ancien domaine pour des connexions ou des réinitialisations de mot de passe, les nouveaux propriétaires peuvent potentiellement compromettre ces comptes.
Les causes sous-jacentes
Ce problème découle principalement de la manière dont Google gère les domaines. Une fois configuré, un domaine est étroitement lié à son compte Google Apps, même après sa désactivation ou son abandon. En l’absence de nettoyage ou de dissociation proactive, les traces de l’ancien domaine restent exploitables.
Contacté pour un commentaire, un porte-parole de Google a fait une déclaration :
Nous apprécions l'aide apportée par Dylan Ayrey pour identifier les risques liés au fait que les clients oublient de supprimer les services SaaS tiers dans le cadre de l'arrêt de leurs activités. En tant que meilleure pratique, nous recommandons aux clients de fermer correctement les domaines en suivant ces instructions afin de rendre ce type de problème impossible. En outre, nous encourageons les applications tierces à suivre les meilleures pratiques en utilisant les identifiants de compte uniques (sub) pour atténuer ce risque.
Il est à noter que les méthodes d'Ayrey n'ont pas permis d'accéder aux données stockées dans chaque compte Google réactivé, mais sur des plateformes tierces. Bien que les cas de test et les données d'Ayrey concernent principalement les startups, tout domaine qui utilise des comptes Google Workspace pour s'authentifier auprès de services tiers et qui n'a pas supprimé son compte Google pour supprimer son lien de domaine avant de vendre le domaine pourrait être vulnérable.
« Ne pas corriger (comportement prévu) »
Ayrey écrit qu'il a communiqué ses conclusions à Google le 30 septembre 2024. Google a répondu le 2 octobre qu'il avait « pris la décision de ne pas le suivre en tant que bogue d'abus » et a mis son statut à « Ne pas corriger (comportement prévu) », selon les captures d'écran d'Ayrey. Un porte-parole de Google a écrit que la réponse initiale de l'entreprise était basée sur « une protection forte et appropriée », le champ « sub », qui existait déjà (plus d'informations à ce sujet plus loin).
Dix jours après qu'Ayrey a fait accepter un exposé sur ce sujet à la conférence de hackers Shmoocon, Google a rouvert le dossier, lui a versé une récompense de 1 337...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.