Contourner l'authentification forte d'Office 365 (MFA) en 3 lignes (et la corriger 😉)

Avant d’entrer dans le vif du sujet, je dois juste expliquer rapidement quelques notions.

L’authentification forte est une authentification réalisée avec un identifiant (login, mail…) et, au moins, deux facteurs différents parmi :

• Ce que je sais (mon mot de passe, une phrase…) ;
• Ce que je suis (biométrie comme : empreinte, rétine, haleine fétide…)
• Ce que je sais faire (signature, geste codé https://twitter.com/mynameisv_/status/1258372512628555779…) ;
• Ce que je possède (un téléphone recevant un code par SMS, un smartphone recevant une notification, un petit jeton générant des codes à usage unique ou OTP dérivés du temps et d’un secret, ou la même chose mais en application sur un smartphone…) ;
• L’endroit où je suis (géolocalisation) ;
• … L’authentification forte est souvent appelée en franglais « Multi Factor Authentication / MFA » et parfois aussi appelé « Two-Factor Authentication / 2FA », une sous classe du MFA limité à l’utilisation de 2 facteurs. Mais par abus de language, le MFA concerne généralement l’authentification forte avec 2 facteurs.

Pour plus des détails, je vous renvoi vers le dieu Wikipédia : https://fr.wikipedia.org/wiki/Authentification_forte

Une fois authentifié sur un système (site web, API, application…), en général, vous récupérez un identifiant de session (cookie, jeton, JWT, PHPSESSIONID…) valide pendant une durée donnée, renvoyé à chaque actions, afin d’éviter de se réauthentifier.

Oui, il y’a beaucoup de « … » 😉.

Il ne faut donc pas confondre :

• Authentification et Identification, l’authentification est une identification avec une preuve sous la forme d’un authentifiant (comme par exemple un mot de passe) ;
• Authentification simple (un login et un mot de passe) et authentification forte ;
• Authentification forte « de merde » avec deux mots de passe et véritable authentification forte.

Office 365 c’est votre mail (et pleins d’autres choses) géré chez Microsoft, par Microsoft en SaaS et que vous payez tous les mois sans amortissement possible.

La solution est adaptée à un grand nombre d’entreprises (hors secteur très concurrentiel ou secret), fonctionne vraiment bien, simplifie la gestion de votre mail (et d’une partie du système d’information comme SharePoint), permet d’avoir un niveau de sécurité souvent plus élevé que lorsque le mail était géré en interne.

Le problème est que les cyberdélinquants attaquent massivement les entreprises utilisant Office 365 car cela donne un point d’entrée quasi unique permettant d’utiliser les mêmes outils d’attaque avec des techniques simples :

• Password spraying, qui consiste à essayer de s’authentifier sur pleins de comptes mais avec très peu de mots de passe comme « NomEntreprise2020! », permettant de ne pas bloquer les comptes avec trop de tentatives en échec ;
• Password Reuse, qui consiste à récupérer des fuites (leak) publiques contenant des utilisateurs ainsi que leur mot de passe et à essayer ces mots de passe, en ayant précédemment retrouvé les entreprise de ces utilisateurs, leur mail pro… ;
• Hameçonnage (phishing), qui consiste à envoyer des mails contenant un lien vers un faux formulaire d’authentification Office 365 afin de voler l’identifiant et le mot de passe des utilisateurs.

Beaucoup d’entreprises se font compromettre des comptes Office 365 du fait de mots de passe faibles, prévisibles ou réutilisés. En général, cela donne des compromissions de comptes par dizaines chaque semaine, coûtant beaucoup de temps et d’énergie aux gens de la sécurité.

La solution la plus simple pour bloquer ces attaques est la mise en place de l’authentification forte. Même si l’attaquant trouve votre mot de passe, il sera bloqué par la demande du second facteur d’authentification.

Pour bénéficier du MFA sur Office 365, à ce jour, il faut juste une licence (plan) Microsoft 365 (ou de l’Azure AD Premium P1 ou P2). Vous disposez de nombreuses documentations chez Microsoft sur les différentes manières d’activer le MFA, la principale étant ici : https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-userstates

A noter qu’en bonus, certaines entreprises utilisent en interne un identifiant (I5178Y1, X171819, abricot pour Alexandre BRICOT…) mais pas le mail complet. Si l’entreprise utilise une authentification Office 365 reposant sur un référentiel d’identités conservé en interne (ADFS), l’authentification forte se fait alors en plusieurs étapes sur le site web Office 365 :

• Saisie du mail sur le portail ;
• Redirection vers l’ADFS ;
• Saisie de l’identifiant et du mot de passe ;
• Redirection vers Office 365 ;
• Saisie du second facteur d’authentification. Dans ce cas, si les identifiants internes ne sont pas triviaux, alors l’entreprise dispose presque d’une sorte de sécurité supplémentaire 😉.

Le MFA c’est super mais il est malheureusement possible de le contourner et il s’agit d’une fonctionnalité !

Par contre, il est toujours nécessaire de disposer d’un identifiant valide et de son mot de passe (mais si vous saviez le nombre de personnes qui mettent « NomEntreprise2019! » ou 2020, comme mot de passe…).

Généralement, vous utilisez un de ces deux moyens accès :

• Votre navigateur, supportant l’authentification forte par nature (ce qui est vrai et faux, car ce n’est pas le navigateur qui supporte le MFA mais le fait d’accepter des redirections mais passons, faisons simple) ;
• Votre client lourd comme Outlook, Teams, Word, App Mail sur iOS… supportant le MDA et qui fonctionne avec le protocole Outlook Anywhere (du RCP over HTTP avec ou sans chiffrement SSL/TLS mais c’est mieux avec 😉) ou avec le protocole Messaging Application Programming Interface / MAPI (protocole basé sur SOAP et contenant l’XML immonde de Microsoft « over HTTP » avec toute la doc ici : https://docs.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxprotlp/30c90a39-9adf-472b-8b5b-03c282304a83?redirectedfrom=MSDN)){:target="_blank"} Microsoft étant le spécialiste de la rétrocompatibilité, tout naturellement, Office 365 support un trèèèèèèèès grand nombre de moyens d’accès au mail (je simplifie pour éviter de faire des listes à rallonge de ce qui peut être accédé : mail, contacts, calendrier et parfois fichiers, sharepoint, fonctionnalités azure…), dont plusieurs ne supportant pas ce fameux MFA, ce qui permet de le contourner.

Vous trouverez dans cet article plusieurs de ces contournements, utilisant MailSniper : https://www.blackhillsinfosec.com/bypassing-two-factor-authentication-on-owa-portals/

Voici la liste des différents protocoles et moyens de contournement :

• Panneau de Configuration Exchange (ECP), il s’agit en fait de la section «options» de Outlook Web Access / OWA, le client web d’Outlook ;
• ActiveSync, l’accès mobile, utilisé depuis les applications de messagerie natives iPhone / Android ;
• Services Web Exchange (EWS), généralement utilisé pour l’accès au contenu de la boîte mail ou pour accéder aux informations de disponibilité du calendrier, mais surtout par Outlook pour Mac ;
• POP et IMAP, les vieux protocoles des années 80 ;
• PowerShell ;
• L’API REST, une autre méthode d’accès aux boîtes mail, qui a (devait ?) être remplacée par EWS ;
• La découverte automatique (Autodiscover), moyen de découvrir les options de configuration d’une boite mail. Ici, nous allons nous intéresser à EWS, sorti en 2007, basé sur du SOAP et ne supportant que l’authentification « basic auth », vieux protocole d’authentification web qui envoie le login et le mot de passe en clair (quasiment). Pour plus de détails avec des schémas, vous pouvez consulter cet article : https://blog.behrouze.com/basic-auth/

A noter que EWS devait être déprécié le 13 octobre 2020 (https://techcommunity.microsoft.com/t5/exchange-team-blog/upcoming-changes-to-exchange-web-services-ews-api-for-office-365/ba-p/608055) mais du fait du COVID, sa fin est décalée à mi-2021 (cf. dernier commentaire de l’article). Ceci dans le but de privilégier des protocoles modernes comme OAuth 2.0 (je vais faire un article prochainement sur OAuth, SAML, OpenID Connect…).

Voici mon compte chez un client avec comme MFA l’envoi d’un code par SMS :

Et voici comment contourner le MFA en 3 lignes (et encore, je suis généreux sur le comptage), avec l’utilisation de l’outil MailSniper (https://github.com/dafthack/MailSniper) qui par défaut va chercher les mails contenant « password », « creds »… :

powershell -exec bypass

Import-Module .\MailSniper.ps1

Invoke-SelfSearch -Mailbox vladimir.kolla@****.com -ExchHostname outlook.office365.com -remote

En 1 ligne pour s’amuser :

powershell -exec bypass -c “Import-Module .\MailSniper.ps1; Invoke-SelfSearch -Mailbox vladimir.kolla@****.com -ExchHostname outlook.office365.com -remote;”

Cela donne l’ouverture d’une fenêtre pour demander (à nouveau) le mail et surtout le mot de passe, mais pas de second facteur :

Puis la magie opère, je suis connecté à mon mail en contournant le MFA et l’outil cherche les mots clefs dans mes mails (je m’étais envoyé des mails avec le mot « password » pour avoir un résultat) :

Vous pouvez également le faire manuellement en PowerShell, voici un exemple (crado) listant les titres des 200 premiers mails de chaque boite mail :

Nan mais mes experts en détection vont détecter ta technique de rebus des enfers !

Avoir des logs c’est bien, les regarder c’est mieux.

Par contre, comme nous opérons dans le monde de la sorcellerie, si vous utilisez l’outil d’analyse de logs CloudAppSec de Microsoft, vous ne verrez pas ces accès.

C’est beau !

De ce que j’ai compris, cette catégorie d’accès est filtrée en amont et n’apparait pas dans les outils de sécurité de Microsoft pour ne pas polluer la console. Donc soit vous faites activer ce qu’il faut pour et serez noyez dans des logs inutiles soit… euh… Joker !

Donc en l’état, si quelqu’un utilise cette technique et vole tous les mails d’un utilisateur, cela sera quasiment invisible.

Pour voir ces accès, il faut aller dans le portail d’administration Azure (https://portal.azure.com) > puis dans :

Azure Active Directory

Sign-Ins (oui, le truc à gauche, tout en bas, presque caché, comme s’ils avaient honte😉)

Créer un filtre « Client App » avec le bouton « Add Filter »

Paramétrer ce filtrer pour sélectionner « Exchange Web Services » (car dans mon cas j’ai utilisé EWS mais sinon, il faudrait sélectionner tous les moyens de contournement cités plus haut)

Et là, enfin, sous vos yeux ébahis, vous pouvez visualiser les utilisateurs utilisant légitimement un protocole qui sera bientôt déprécié ou … des cybercriminels Tadjik du sud de la Corée du nord de la CIA (à noter que j’ai ajouté un filtre n’affichant que les succès) :

Contre-mesures

Tout d’abord, comme dit plus haut, Microsoft déprécie progressivement tous ces vieux moyens d’accès avec un fort risque de casser des trucs mais c’est votre problème, pas le leur : << Welcome to the jungleCloud !!! >>

En attendant, vous devrez créer une stratégies d’accès conditionnels, appliquée à tous les utilisateurs et bloquant ces vieux accès. Par contre, pensez bien à l’activer car récemment, malgré un accompagnement de Microsoft, un « none » a été mis au lieu d’un « All cloud apps » ce qui permettait de continuer à contourner le MFA 😉 :

A noter aussi que l’activation de la stratégie peut mettre 24h à être appliqué (cf. commentaires) : https://techcommunity.microsoft.com/t5/exchange-team-blog/modern-auth-and-unattended-scripts-in-exchange-online-powershell/ba-p/1497387