Chez Synack, nous bénéficions vraiment de grandes vulnérabilités, que ce soit sur le web, le mobile, l’hôte ou même dans des appareils et des systèmes complètement scandaleux (piratage satellite de n’importe qui?). Mais nous gardons toujours confidentielles les grandes découvertes que nous et la SRT avons faites pour nos clients. Donc, bien que ce ne soit pas un article sur un grand vuln chez un client Synack, il couvre le type exact de chose que nous voyons chaque semaine ou parfois quotidiennement: Une vulnérabilité dans un système avec des millions d’utilisateurs qui conduit à un compromis complet de la sécurité du système.

J’ai récemment trouvé une vulnérabilité dans Microsoft Live.com système d’authentification, qui, si vous avez un compte avec un service Microsoft, vous aurait probablement affecté. Cet article décrit tous les détails de la vulnérabilité maintenant que Microsoft a corrigé le problème.

Introduction

La compréhension de la sécurité informatique par une personne moyenne a toujours été assez limitée. À l’époque, si quelqu’un entendait que vous étiez impliqué dans la sécurité informatique, la question standard serait « pouvez-vous pirater mon Hotmail », ou plus souvent, « pouvez-vous pirater le Hotmail de mon ami ». Je suppose qu’à l’époque, les gens utilisaient encore Yahoo mail et Microsoft n’avait pas encore acquis Hotmail, mais c’est un peu trop loin! Inévitablement, vous suggéreriez à la personne de deviner ses questions de réinitialisation de mot de passe ou d’installer Sub7. En fait, le piratage de Hotmail était forcément trop difficile, pour ne pas dire totalement illégal.

Le monde de la sécurité de l’information a beaucoup changé au cours des deux dernières années, et contrairement aux années passées, Microsoft encourage désormais pleinement les chercheurs en sécurité à tenter de « pirater Hotmail ». Bien sûr, Hotmail a été transformé en Outlook.com, et ces jours-ci, tout le monde veut savoir si vous pouvez pirater leur Facebook, mais c’est à côté du point.

Le programme Microsoft Online Services bounty a été récemment mis à jour pour inclure le « compte Microsoft » comme cible, qui est essentiellement les systèmes de connexion hébergés dans chacun de ces domaines:
– login.windows.net
– login.microsoftonline.com
– login.live.com

Dans la liste ci-dessus, login.live.com est le système d’authentification que vous passerez si vous tentez de vous authentifier Outlook.com et un grand nombre d’autres services Microsoft. J’ai décidé de l’examiner d’abord pour voir si je pouvais découvrir des problèmes. Comme prévu, les différentes API utilisées pour traiter une connexion semblaient bien durcies. Des couches de protection supplémentaires existaient à de nombreux endroits; par exemple, dans certains endroits, les mots de passe sont cryptés avec une clé publique avant la transmission malgré toutes les communications se faisant via HTTPS.

Après quelques heures de test, j’ai découvert quelques problèmes mineurs que j’ai signalés, mais rien de vraiment remarquable. Lorsque je teste des applications Web, je constate souvent que le flux de travail le plus courant est également le plus sécurisé, j’ai donc décidé d’examiner d’autres moyens qu’un utilisateur pourrait s’authentifier auprès du live.com système. Il y a près d’un an, j’avais trouvé plusieurs vulnérabilités OAuth dans Yammer qui était également une cible de primes des Services en ligne Microsoft, c’est donc là que j’ai cherché live.com . C’est là que commencent les découvertes intéressantes!

Contexte de la vulnérabilité

Avant d’entrer dans la vulnérabilité découverte, un aperçu rapide du système de sécurité malavisé connu sous le nom d’OAuth est nécessaire:

Wikipedia me dit que « OAuth fournit aux applications clientes un « accès délégué sécurisé » aux ressources du serveur pour le compte d’un propriétaire de ressource ». Wikipédia a également des commentaires cinglants sur son évolution et sa sécurité, qui valent la peine d’être lus pour bien rire. De manière réaliste, tout ce que fait OAuth est de permettre à un utilisateur d’accorder l’accès à tout ou partie de l’accès de son compte à un tiers. J’ai fait un dessin MS Paint pour illustrer cela parce que je n’en trouvais pas un grand sur Wikipedia.

Comme on peut le voir sur l’image ci-dessus, vous avez un Serveur que l’Utilisateur a autorisé à donner accès à son compte à une Application cliente. Le mécanisme qui gère cela en coulisses peut être construit de plusieurs manières différentes, qui sont définies dans la RFC OAuth. Une façon de le construire est un flux d’authentification « implicite », qui implique que le serveur d’authentification donne une clé d’accès directement au client. Une autre façon populaire consiste à utiliser une procédure de « code d’autorisation », où le serveur d’authentification émet un code d’autorisation, que le système client prend, puis échange contre une clé d’accès en utilisant sa valeur secrète client. Microsoft a une bonne description de leur utilisation de la façon dont ils ont implémenté ces mécanismes pour live.com ici:
https://msdn.microsoft.com/en-us/library/hh243647.aspx

Le graphique qu’ils ont fait pour le flux « code d’autorisation » ressemble à ceci:

Une image comme celle-là est idéale pour comprendre le processus, mais pour moi, en tant que testeur de stylo, cela montre également beaucoup d’opportunités et d’endroits où les choses tournent mal. Donc, avec cela comme arrière-plan, à ce qui a été découvert!

Qu’Est-Ce Qui Pourrait Mal Tourner ?

Comme indiqué dans la section ci-dessus, il y a beaucoup d’endroits où quelque chose pourrait mal tourner. L’une des étapes fondamentales de la procédure d’authentification OAuth consiste pour un utilisateur à choisir d’accorder l’accès à une application. Ceci est généralement accompli via une invite comme celle-ci:

Généralement, un utilisateur n’aura besoin d’accepter cette invite qu’une seule fois, mais jusqu’à ce qu’il l’accepte, cette application n’aura aucun accès à son compte (que l’utilisateur moyen autorise ou non l’application maléfique de Wes à y accéder est peut-être une question différente!).

En tant qu’attaquant, ce serait certainement génial si nous pouvions accepter la demande au nom de l’utilisateur. Malheureusement pour moi, l’en-tête « X-Frame-Options » a été défini sur « refuser » (les paramètres x-frame-options étaient également hors de portée pour cette prime). Alors que le clickjacking est sorti, j’ai décidé de mieux comprendre comment la demande elle-même fonctionnait. Si un utilisateur clique sur « Oui », la demande suivante est postée sur le serveur (plus quelques en-têtes ennuyeux):

Bien que le chemin d’URL ci-dessus inclut des jetons générés, les tests ont montré qu’ils n’étaient pas nécessaires pour que la demande réussisse. Un MESSAGE à l’URL suivante fonctionnerait tout aussi bien:

https://account.live.com/Consent/Update?ru=https://login.live.com/oauth20_authorize.srf%3flc%3d1033%26client_id%3d000000004C15E107% 26scope% 3dwl.basic%26response_type%3dcode%26redirect_uri%3dhttp: // exfiltrated.com &client_id=000000004C15E107 &rd=exfiltré.com& portée = wl.basic

Le cookie envoyé avec la demande nécessaire pour contenir un jeton de session valide dans « IPT ». Cette valeur de cookie est remplie parhttps://login.live.com/oauth20_authorize.srf avant que la page demandant l’autorisation de l’utilisateur ne s’affiche. Cela se produit indépendamment du fait qu’un utilisateur clique ou non sur « Oui », bien qu’il soit défini par un code Javascript, donc si nous attaquons ce processus, nous devrons forcer l’utilisateur à charger cette page à un moment donné.

Si vous suivez, j’espère que vous demandez maintenant: « OK, alors qu’en est-il de la demande POST elle-même et de cette valeur canari? ». J’avais d’abord examiné tous les autres paramètres et flux de communications, car voir une valeur étiquetée « canary » envoyée avec une requête POST signifie presque certainement qu’elle est utilisée comme jeton pour empêcher les attaques CSRF. Le but des tests de sécurité, cependant, est de vérifier que les hypothèses sont bien correctes. J’ai donc modifié la requête POST et changé la valeur canary en « hacks_go_here ». Au lieu de rediriger vers une erreur 500, le serveur a renvoyé une réponse positive!

CSRF à PoC

Étant donné que le jeton CSRF était la dernière chose que j’avais essayé de falsifier, je savais avec certitude que cela devrait constituer une vulnérabilité CSRF valide. Comme pour presque toutes les attaques CSRF, la seule condition préalable était que la victime soit connectée et ait un jeton de session valide dans son cookie. Contrairement à de nombreuses autres vulnérabilités Web, l’impact d’une vulnérabilité CSRF dépend entièrement de la fonction API affectée. Ce CSRF me permet de contourner l’étape d’interaction utilisateur du système d’authentification OAuth, mais un PoC vaut mille mots, donc l’étape suivante consistait à créer du code pour démontrer de manière appropriée l’impact de cette vulnérabilité.

Dans le flux d’authentification OAuth normal, après que l’utilisateur accorde l’accès, le serveur doit renvoyer un code d’accès à l’utilisateur. L’utilisateur transmet cela à l’application cliente, qui peut ensuite utiliser les autorisations accordées. A live.com l’application cliente peut demander un large éventail d’autorisations possibles. J’ai envisagé de simplement vider les contacts de l’utilisateur ou quelque chose comme ça, mais pourquoi sacrifier l’objectif de pirater Hotmail maintenant? Les autorisations dont mon PoC avait besoin à l’époque étaient:

wl.accès hors ligne + wl.imap

Hors ligne n’était pas si nécessaire, mais je l’ai jeté pour montrer qu’il serait accordé.

Avec les autorisations nécessaires choisies, il y a 4 étapes pour accéder au compte de messagerie d’un utilisateur:

1) Nous devons faire une demande d’autorisation pour notre application cliente en utilisant les autorisations ci-dessus. Le serveur invite l’utilisateur à accepter ou à refuser.
2) Lorsqu’un utilisateur accepte notre demande de ces autorisations, le serveur ajoute un paramètre « #access_token=< token> » à la redirection que nous lui demandons de prendre.
3) Étant donné que nos scripts côté serveur auront besoin d’accéder à cette valeur, nous devons créer une page simple pour extraire le jeton du champ URL du navigateur et le transmettre à notre serveur.
4) Enfin, nous avons besoin de scripts côté serveur pour prendre ce jeton et l’utiliser pour se connecter à IMAP. Microsoft a un processus quelque peu compliqué pour utiliser le jeton OAuth pour se connecter directement via IMAP. Quelques exemples de bibliothèques existent pour cela, et l’ensemble du processus est décrit sur cette page:
https://msdn.microsoft.com/en-us/library/dn440163.aspx

Ce flux de travail fonctionnerait bien en supposant que l’utilisateur choisisse de nous donner la permission. J’ai maintenant juste besoin de modifier le flux de travail pour inclure à la place le CSRF. Comme indiqué précédemment, le live.com le serveur d’authentification attend un jeton de session dans le cookie IPT. Nous pouvons nous assurer que cela est rempli en envoyant d’abord l’utilisateur à une page validhttps://login.live.com/oauth20_authorize.srf. Immédiatement après, nous pouvons exécuter la requête CSRF qui utilisera la valeur du cookie nouvellement renseignée. Cela peut maintenant remplacer l’étape 1 et forcer le serveur à passer immédiatement à l’étape 2.

Démo et impact

Microsoft a maintenant résolu ce problème, mais voici une vidéo rapide le montrant en action.

Comme on peut le voir dans la vidéo, tout ce qui est vraiment nécessaire est d’amener la victime à visiter votre page Web malveillante. La démo n’a pas été conçue pour être sournoise et s’exécuter en arrière-plan d’un site Web, ou dans le cadre d’une bannière publicitaire malveillante, mais elle aurait certainement pu être faite de cette façon.

L’utiliser comme attaque ciblée a certainement un impact élevé, mais c’est aussi le type de vulnérabilité idéal pour se transformer en ver. Avec l’accès IMAP et au carnet de contacts, un ver peut facilement envoyer par e-mail tous les contacts d’un utilisateur (ou du moins ceux qui utilisent Hotmail, Outlook.com , etc.), avec quelque chose de séduisant, le style de virus « ILOVEYOU », et se propage à chaque utilisateur qui clique sur le lien.

Réflexions finales et chronologie

La recherche de cette vulnérabilité et la création d’un PoC fonctionnel ont nécessité beaucoup d’efforts pour fouiller dans les différentes live.com API. En regardant tout cela cependant, il ne s’agit vraiment que d’une vulnérabilité CSRF classique. La seule chose qui est surprenante à ce sujet est que c’est dans un système d’authentification critique qui peut finalement être utilisé pour prendre en charge le compte de n’importe quel utilisateur.

En tant que testeur externe, je ne sais pas depuis combien de temps cette vulnérabilité a pu exister, ni si quelqu’un a déjà essayé de l’exploiter. Dans le même temps, ce sont des résultats comme celui-ci qui montrent définitivement l’intérêt de permettre aux testeurs externes de soumettre des vulnérabilités à votre entreprise avant que les attaquants ne les exploitent contre vous. Microsoft est loin devant la plupart des entreprises en matière de sécurité, et pourtant, il est toujours possible de résoudre des problèmes comme celui-ci. L’expérience de Synack a été que des vulnérabilités sont découvertes même dans des systèmes apparemment bien sécurisés lorsqu’un grand groupe de chercheurs externes teste ce système. C’est essentiellement la prémisse sur laquelle Synack opère, et c’est pourquoi de plus en plus d’entreprises proposent leurs propres programmes de primes (je recommanderais bien sûr le programme de Synack plutôt que de gérer le vôtre!).

Comme on peut le voir dans la chronologie ci-dessous, Microsoft a réagi en obtenant un correctif pour ce problème, ce qui était génial à voir.

Chronologie:
23 août 2015: Découverte d’une vulnérabilité
25 août 2015: Vulnérabilité signalée à Microsoft
31 août 2015: Numéro de cas Microsoft pour la vulnérabilité
15 septembre 2015: Microsoft publie un correctif pour le problème, émet une prime de 24 000 $ (promo double primes)