Je sais ce qu’Azure a fait l’été dernier – Gratuit : Audit complet de votre site internet

Avant de commencer !

Je sais ce qu'Azure a fait l'été dernier
Share on facebook
Share on twitter
Share on pinterest

De plus en plus d’entreprises décident de déplacer leurs infrastructures dans des environnements cloud proposés par Microsoft Azure, Google Cloud Computing, Amazon AWS et bien d’autres.

À notre époque moderne et en évolution rapide, les grandes et petites entreprises trouvent les infrastructures cloud à la fois pratiques et économiques, mais le besoin de plus de puissance de calcul a été un problème… et maintenant il existe une bonne solution pour cela.

Bien qu’il y ait beaucoup de miel dans les solutions de Cloud Computing, il y a aussi une piqûre à prendre en compte. S’appuyer sur «l’ordinateur de quelqu’un d’autre» signifie également se fier aux mesures de sécurité de quelqu’un d’autre. Nous avons vu de nombreuses attaques qui se sont concentrées sur les faiblesses de la configuration du cloud – et voir et comprendre ces vulnérabilités nous aide à fortifier nos environnements cloud. Mais qu’en est-il des vulnérabilités que nous ne connaissons pas? Sommes-nous prêts pour cela?

Ce blog explore une vulnérabilité que j’ai trouvée dans le portail Microsoft Azure qui pourrait entraîner la prise en charge d’un environnement Azure par des attaquants malveillants.

TL; DR

Prendre en charge votre environnement cloud est un réel risque. Avec cette vulnérabilité de Microsoft Azure, les attaquants pourraient prendre le contrôle des comptes Azure en exploitant un bogue de mauvaise configuration dans le manifeste du portail Azure. Le manifeste est un fichier de configuration – dans ce cas, un fichier JSON, qui indique les paramètres de l’application Web.

Au cours de nos recherches sur le portail Azure, nous avons vu des rapports de télémétrie envoyés à un domaine inexistant et la plupart de ces demandes de télémétrie incluaient des jetons d’accès. Dans ce cas, le jeton d’accès dispose des autorisations de l’utilisateur (portée «user_impersonation») et est valide pour toute ressource Azure, y compris les machines virtuelles et les serveurs de stockage (BLOB), les gestionnaires de trafic, etc. Une fuite de ce jeton sensible pourrait permettre à des attaquants malveillants de compromettre de nombreux Comptes Azure.

Il existe plusieurs façons d’exploiter ce bogue à travers diverses techniques de manipulation DNS que nous couvrons dans ce billet de blog.

La vulnérabilité Azure expliquée
Si vous ne connaissez pas Azure, il s’agit de l’ensemble de services cloud de Microsoft en constante évolution.
Il est conçu pour permettre aux clients de créer, gérer et déployer des applications sur un réseau mondial massif.

Le portail Azure est le nom de la plateforme Web de gestion Azure, qui vous permet d’accéder à toutes vos applications et de les gérer en un seul endroit. Il vous permet également de gérer, créer, déployer et surveiller d’autres types de ressources, des applications simples aux environnements cloud complexes. Pour cette raison, les environnements Azure contiennent souvent de nombreuses ressources sensibles et précieuses comme les environnements de production, les données client, les secrets et autres informations confidentielles.

Imaginez un scénario dans lequel un attaquant malveillant parvient à accéder à vos informations d’identification d’utilisateur les plus privilégiées dans un tel environnement – ce serait un désastre, non? Ce scénario pourrait servir toutes vos machines virtuelles, serveurs de stockage et vos données client à être cryptées par un ransomware – ou rendre tous vos mots de passe, secrets et données confidentielles à gagner. En bref, un attaquant pourrait détruire ou voler toute ressource sensible ou précieuse dans cet environnement compromis par le cloud.

Extensions, manifestes et ce qui pourrait mal tourner
Le portail Azure est construit à partir de nombreux composants, appelés extensions, et chaque extension représente une fonctionnalité différente fournie par le portail. Habituellement, les paramètres des extensions sont spécifiés en un seul endroit – dans ce cas, il se trouve dans un fichier JSON appelé «ExtensionManifest». Le manifeste indique au code JavaScript des extensions comment il doit se comporter et quelles ressources externes il doit récupérer et utiliser. Un bon exemple d’extension est la page «Mon tableau de bord», comme le montre la figure 1.

Figure 1: page «Mon tableau de bord» du portail Azure. Le fichier manifeste spécifie les URL de ressource et les noms de domaine que l’extension de code JavaScript peut utiliser.

Maintenant que l’arrière-plan est à l’écart, approfondissons la recherche.

En surfant sur le portail Azure, j’ai remarqué des requêtes étranges sortant de mon navigateur. Au début, je pensais que cela devait être un bug de serveur temporaire ou qu’il y avait peut-être un problème avec mon navigateur, mais, peu de temps après, j’ai compris que ce bug affectait chaque Utilisateur Azure. Eh bien, cela a piqué mon intérêt et je devais enquêter davantage.

J’ai commencé par rechercher tout ce qui avait une connexion avec le nom d’hôte «urehubs», qui est l’endroit où les demandes étaient envoyées (comme le montre la figure 2). Dans l’un des fichiers, j’ai réussi à trouver un indice qui éclairait ce bug.

Figure 2: Demandes envoyées à https: // urehubs / envoyées depuis portal.azure.com.

Bogue ExtensionManifest

Dans le ExtensionManifest, il y a une extension nommée « HubsExtension ».
Le « HubsExtenstion » était un peu différent de l’autre extension, car son attribut URI manquait « // » ou tout autre attribut de format de domaine approprié (comme portal.azure.com), au lieu de cela, il semble que ce ne soit qu’un chemin URL. (Voir figure 3.)

Figure 3: Instantané de l’objet HubsExtension à partir du manifeste du portail Azure.

Bien que ce soit intéressant, il n’était toujours pas clair pourquoi ce bogue étrange s’est produit – j’avais besoin de trouver le code JavaScript spécifique qui fait ces demandes. J’ai regardé dans le code JavaScript pour le code spécifique gérant l’analyse de cet objet d’extension… et je l’ai trouvé. J’ai commencé à définir des points d’arrêt dans le code JavaScript pour mieux comprendre le bogue.

le Bug d’analyse syntaxique JavaScript

La fonction «tt» (comme illustré dans la figure 4) est appelée dans le cadre du processus normal de chargement du manifeste (mis en cache ou frais), qui se produit chaque fois que vous surfez sur le portail Azure.

Figure 4: un instantané de la fonction «tt» de «Content_Dynamic_uLKj31Z9Yqa.js».

La fonction «tt» se trouve dans «Content_Dynamic_uLKj31Z9Yqa.js» et prend en paramètre l’attribut URI de l’objet d’extension, qui se trouve dans le fichier manifeste, et l’analyse.

Consultez la figure 5 pour le code non obscurci avec des fonctionnalités similaires, que j’ai créé pour rendre le code de la figure 4 plus facile à suivre.

Figure 5: Instantané du code de fonction «tt» réécrit et non obscurci. Passons maintenant à la logique du code.

La fonction obtient le paramètre URI et recherche ensuite les deux barres obliques («//») qui devraient se trouver au début de l’URI. Comme nous le savons, l’attribut URI problématique de «HubsExtenstion», «AzureHubs / Hubs» ne contient pas ces «//», de sorte que la variable slashesLocation sera 0.
La variable de protocole obtiendra la chaîne de schéma de protocole de page actuelle, qui sera «https:»
Le endOfUrlPath sera neuf, car le premier «/» de l’URI est situé juste avant la deuxième chaîne «Hubs». La variable domainName sera la sous-chaîne de l’URI en commençant par le deuxième caractère (slashesLocation + 2 -> 0 + 2) et jusqu’à l’index de 9 caractères. Le résultat de ceci est «urehubs».

Cela semble familier, n’est-ce pas?

Et à la fin, la valeur de retour sera l’objet de la figure 6.

Figure 6: Instantané de l’objet renvoyé à partir de la fonction «tt».

En examinant de plus près les résultats, nous pouvons voir que la propriété origin dans l’objet renvoyé est définie sur le serveur local «urehubs».

Maintenant, pour connecter tous les points:

  • L’attribut URI «HubsExtenstion» ne contient pas la chaîne «//».
  • La chaîne n’est pas bien analysée dans le code JavaScript. La fonction renvoie donc un objet dont l’attribut d’origine est défini sur « https: // urehubs ».
  • Les demandes de télémétrie avec des jetons d’accès sensibles sont ensuite envoyées à «https: // urehubs /».

De plus, les jetons d’accès spécifiques envoyés par les demandes de télémétrie ont une étendue d’autorisations «user_impersonation» vers la ressource «https://management.core.windows.net/».

Cela signifie que, si vous disposez de ce jeton, vous pouvez prendre des mesures au nom de son propriétaire.

Cette combinaison de facteurs permet de voler le jeton d’autorisation et de prendre des mesures au nom de la victime dans son environnement Azure.

Mais peut-il être exploité dans la vraie vie? Oui en effet.

Les vecteurs d’attaque

Au cours de nos recherches, nous avons exploité deux principaux vecteurs d’attaque: l’exploitation du domaine local et son exploitation dans le Web sauvage.

Exploitation de l’environnement local

Pour exploiter ce bogue dans un environnement de domaine local, l’attaquant devrait configurer les composants suivants:

  1. Un serveur HTTP avec le nom d’hôte « ureuhbs »
  2. Un certificat signé par une autorité de certification racine ou par l’autorité de certification racine du domaine local

Finalement, chaque utilisateur Azure de ce domaine local qui surfe involontairement sur le portail Azure enverra son jeton d’accès au serveur de l’attaquant.

Exploiter le bug dans la nature
Les serveurs DNS, la plupart du temps, font leur travail et ils le font bien – mais certains serveurs DNS peuvent en fait le faire «trop bien». Laisse-moi expliquer.

Certaines configurations de serveurs DNS peuvent ajouter un suffixe du TLD communément connu (com, net, org, etc.) aux noms d’hôte locaux lorsqu’ils ne parviennent pas à le résoudre par leur enregistrement local.

Dans ce cas, le serveur DNS, lorsqu’il essaie de résoudre «urehubs», essaie également de résoudre urehubs.com, urehubs.net, etc.

Un attaquant potentiel pourrait abuser de ce comportement en achetant de nombreux domaines «urehubs» différents avec des suffixes différents et en les exploitant.

Pourtant, cela ne suffira pas, car l’attaquant a toujours besoin d’un certificat valide pour le serveur local signé par une autorité de certification racine publique.

Depuis le 1er novembre 2015, CA / Browser Forum n’autorise plus les certificats SSL de confiance publique à inclure ces noms locaux, tels que les noms de serveurs internes et les adresses IP réservées (car cela pourrait conduire à MiTM dans un réseau local.) Mais, il existe des AC racines malveillantes qui ont été compromises au fil des ans (Commodo en 2011 ou DigiNotar en 2013, par exemple).

Par mesure de protection et de responsabilité, nous avons acheté 27 domaines «urehubs» avec différents suffixes pour empêcher les attaquants malveillants d’exploiter ce bogue, notamment urehubs.com, urehubs.net, urehubs.org, etc.

Un autre point important à souligner est que les fonctionnalités de sécurité sont excellentes, mais uniquement lorsqu’elles sont activées. Certains utilisateurs désactivent la fonction de validation de certificat dans leur navigateur en raison d’erreurs de navigation sur le navigateur ou de la nécessité d’accéder à des sites Web non signés de temps en temps. Et sérieusement, ne faites pas ça – quand vous le faites, vous vous exposez à des risques


POC d’exploitation
Dans un POC que nous avons fait, nous avons réussi à exploiter cette vulnérabilité et avons obtenu un jeton Azure d’une organisation externe (voir figure 7).

Figure 7: Instantané du jeton d’accès compromis.

The Fix
Vendredi 6 septembre 2019, nous avons remarqué une modification du portail Azure dans certains fichiers JavaScript. Microsoft a ajouté trois lignes de code pour corriger la vulnérabilité (voir figure 8). En ajoutant l’URL à l’attribut href, Microsoft a réussi à atténuer la vulnérabilité en s’assurant que l’URL n’est pas seulement le chemin d’accès, mais également une URL valide complète.

Si une URL n’inclut aucun schéma au début, le JavaScript la traitera comme un chemin d’accès relatif au domaine de page actuel. Ce qui, dans ce cas, signifie qu’au lieu d’obtenir «https: // urehubs», nous obtiendrons désormais https://portal.azure.com/AzureHubs/Hubs.

Figure 8: Instantané de la fonction «tt» corrigée, que nous avons renommée «l».

Microsoft a résolu le problème avec une simple modification de code JavaScript qui corrigeait le bogue d’analyse d’URL dans le fichier JavaScript et laissait ExtensionManifest tel quel.

En ce qui concerne les formats d’URI dans le Manifeste d’extensions, je pense qu’il vaut peut-être la peine de s’en tenir à un seul format d’URI, car ne pas le faire pourrait être la cause principale de nombreux autres bogues qui pourraient apparaître au fil du temps.


Conclusion

Nous pensons que la vulnérabilité a existé pendant près de deux semaines, donc un attaquant potentiel aurait pu l’exploiter pour accéder à de nombreux réseaux en enregistrant des domaines et en fournissant un certificat valide pour un domaine local à chaque demande. Il est important de noter qu’il peut exister des vulnérabilités similaires dont nous ne sommes pas conscients qui pourraient potentiellement exposer l’infrastructure cloud afin de prendre le relais.

Les services cloud sont d’excellentes options pour de nombreuses entreprises. Cependant, vous devez vous rappeler que compter sur «l’infrastructure de quelqu’un d’autre», c’est compter sur les mesures de sécurité de quelqu’un d’autre – ce qui peut être une entreprise risquée. Lorsque vous vous lancez dans une initiative cloud, n’oubliez pas que vous n’êtes pas obligé d’utiliser uniquement les mesures de sécurité de votre fournisseur. En substance, vous avez également la responsabilité d’assurer la sécurité des applications, du système d’exploitation, de l’infrastructure de support et des autres actifs s’exécutant dans le cloud.

Il est important de noter que bien que cette recherche soit spécifiquement liée à Microsoft Azure, ce type de vulnérabilité pourrait se produire dans d’autres solutions similaires. Donc, lorsque vous voyez un trafic ou un comportement étrange dans un service, un programme ou similaire, ne l’ignorez pas – essayez de mieux le comprendre. Il pourrait y avoir une vulnérabilité ou un bogue se trouvant juste en dessous, attendant d’être découvert.

Divulgation TimeLine

28/08/19 – La vulnérabilité a été trouvée.

05/09/19 – Nous avons réussi à exploiter la vulnérabilité et à créer un POC pleinement fonctionnel.

09/06/19 – Microsoft a corrigé le bogue avant de pouvoir le signaler.

*** Ceci est un blog syndiqué de Security Bloggers Network de CyberArk rédigé par Omer Tsarfati. Lisez l’article d’origine sur: https://www.cyberark.com/threat-research-blog/i-know-what-azure-did-last-summer/

Inscris-toi à notre newsletter !

Partage cet article avec tes amis !

Share on facebook
Share on google
Share on twitter
Share on linkedin