Microsoft a corrigé récemment plusieurs importantes failles de sécurité dans son bouquet de services Office 365.
Les vulnérabilités ont été découvertes par le chercheur indien Sahad Nk pour le compte du portail de sécurité Safetydetective. Mises bout à bout, elles permettent à terme la prise de contrôle d’un compte si le pirate peut amener l’utilisateur ciblé à cliquer sur un simple lien.
Source du problème selon le chercheur, un sous-domaine success.office.com insuffisamment protégé. Il a ainsi pu en changer le CNAME, se retrouvant en capacité de détourner le trafic y transitant vers son propre serveur.
Une fois découvert la manière d’enchainer les failles, il décrit une grande simplicité d’exploitation. Il a pu utiliser son propre compte Microsoft et sa double authentification pour prendre le contrôle du sous-domaine, renvoyant les données vers son compte Azure. Conséquence supplémentaire, l’implémentation d’OAuth était donc défaillante également à cet endroit.
Et comme si la découverte n’était déjà pas assez gênante, Sahad Nk ajoute que les applications Office, le Store et Sway peuvent envoyer leurs jetons d’authentification vers le sous-domaine nouvellement contrôlé.
Selon Safetydetective, le lot de failles a pu affecter jusqu’à 400 millions d’utilisateurs. On ne sait malheureusement pas s’il y a des victimes : le chiffre est théorique, et Microsoft n’a pas réagi au-delà de la correction des failles.
« Consolation », les détails des brèches ne sont normalement pas publics. Ils ont été communiqués confidentiellement à Microsoft par Safetydetective, expliquant la correction rapide. Sahad Nk a confirmé à TechCrunch avoir reçu une récompense via le bug bounty de Microsoft, mais le montant n’est pas précisé.
Commentaires (3)
#1
Je serais quand même curieux de savoir comment il a réussi à changer le CNAME d’un sous domaine de office.com.
#2
Je pense que il s’agit d’un “subdomain takeover”:
https://labs.detectify.com/2014/10/21/hostile-subdomain-takeover-using-herokugithubdesk-more/
L’attaquant ne change pas le CNAME mais crée le serveur cloud/service web vers lequel le CNAME pointe (aws, heroku, shopify etc).
Services vulnérables:
https://github.com/EdOverflow/can-i-take-over-xyz
Il est possible que un des sous-domaines de nextinpact soit aussi vulnérable, mais il faut un compte Microsoft Azure pour tester. (si quelqu’un en a je peux donner les instructions pour le tester)
#3
Merci pour les détails ! J’ai désormais compris
" />
Du coup si je récapitule :
Il était une fois success.office.com qui était un CNAME vers toto.azurewebsites.net (c’est un exemple). L’équipe Office déprovisionne la ressource toto.azurewebsites.net sans enlever le CNAME et l’attaquant la provisionne avec son code malicieux. Vu que c’est wildcard pour les return_url openid/oauth des applis office, l’attaquant peut donc utiliser le client_id d’une vraie application pour forger une requete d’autorisation avec une url success.office.com comme redirect_uri et ainsi il peut voler l’id_token+access_token pour faire des choses au nom de l’utilisateur sur les api MS.