Audit de sécurité de la plateforme cloud MCS

SkyShip Dusk par SeerLight

La construction de tout service implique nécessairement un travail constant sur la sécurité. La sécurité est un processus continu qui comprend une analyse et une amélioration continues de la sécurité des produits, la surveillance des nouvelles sur les vulnérabilités et bien plus encore. Y compris - audits. Les audits sont effectués à la fois par eux-mêmes et par des experts externes qui peuvent considérablement aider à la sécurité, car ils ne sont pas plongés dans le projet et ont une vision claire.

L'article porte sur cette vision très impopulaire d'experts externes qui ont aidé l'équipe Mail.ru Cloud Solutions (MCS) à tester le service cloud, et sur ce qu'ils ont trouvé. En tant que «forces externes», MCS a choisi la sécurité numérique, connue pour sa grande expertise dans la communauté de la sécurité. Et dans cet article, nous analyserons certaines vulnérabilités intéressantes qui ont été trouvées dans le cadre d'un audit externe - afin que vous obteniez le même rake lorsque vous effectuez votre service cloud.

Description du produit

Mail.ru Cloud Solutions (MCS) est une plate-forme pour la construction d'une infrastructure virtuelle dans le cloud. Il comprend IaaSs, PaaSs, un marché d'images d'applications prêtes à l'emploi pour les développeurs. Compte tenu de l'architecture de MCS, il était nécessaire de vérifier la sécurité du produit dans les domaines suivants:

• protection de l'infrastructure de l'environnement de virtualisation: hyperviseurs, routage, pare-feu;
  
• protection de l'infrastructure virtuelle des clients: isolation les uns des autres, y compris le réseau, les réseaux privés dans SDN;
  
• OpenStack et ses composants ouverts;
  
• Propre développement S3;
  
• IAM: projets multi-locataires avec un modèle;
  
• Vision (vision industrielle): API et vulnérabilités lors de l'utilisation d'images;
  
• interface Web et attaques Web classiques;
  
• vulnérabilités des composants PaaS;
  
• API de tous les composants.
  

Peut-être que tout ce qui est essentiel pour l'histoire ultérieure est tout.

Quel type de travail a été effectué et pourquoi est-il nécessaire?

Un audit de sécurité vise à identifier les vulnérabilités et les erreurs de configuration pouvant entraîner une fuite de données personnelles, une modification des informations sensibles ou une violation de la disponibilité des services.

Pendant le travail, qui dure en moyenne 1 à 2 mois, les auditeurs répètent les actions des attaquants potentiels et recherchent les vulnérabilités dans les parties client et serveur du service sélectionné. Dans le cadre de l'audit de la plateforme cloud MCS, les objectifs suivants ont été identifiés:

1. Analyse de l'authentification dans le service. Des vulnérabilités dans ce composant permettraient d'accéder immédiatement aux comptes d'autres personnes.
   
2. L'étude du modèle de rôle et du contrôle d'accès entre différents comptes. Pour un attaquant, la possibilité d'accéder à la machine virtuelle de quelqu'un d'autre est une cible bienvenue.
   
3. Vulnérabilités côté client. XSS / CSRF / CRLF / etc. Peut-être est-il possible d'attaquer d'autres utilisateurs via des liens malveillants?
   
4. Vulnérabilités côté serveur: RCE et toutes sortes d'injections (SQL / XXE / SSRF et ainsi de suite). Les vulnérabilités des serveurs sont généralement plus difficiles à trouver, mais elles conduisent à la compromission de nombreux utilisateurs à la fois.
   
5. Analyse de l'isolement des segments de réseau des segments d'utilisateurs. Pour un attaquant, le manque d'isolement augmente considérablement la surface d'attaque des autres utilisateurs.
   
6. Analyse de la logique métier. Est-il possible de tromper une entreprise et de créer des machines virtuelles gratuitement?
   

Dans ce projet, le travail a été réalisé selon le modèle de la boîte grise: les auditeurs ont interagi avec le service avec les privilèges des utilisateurs ordinaires, mais possédaient partiellement le code source de l'API et ont eu l'occasion de clarifier les détails avec les développeurs. C'est généralement le modèle de travail le plus pratique et le plus réaliste: des informations privilégiées peuvent toujours être collectées par un attaquant, ce n'est qu'une question de temps.

Vulnérabilités trouvées

Avant que l'auditeur commence à envoyer diverses charges utiles (charge utile, qui est utilisée pour attaquer) à des endroits aléatoires, vous devez comprendre comment cela fonctionne, quelles fonctionnalités sont présentées. Il peut sembler qu'il s'agit d'un exercice futile, car dans la plupart des endroits étudiés, il n'y aura pas de vulnérabilités. Mais seule une compréhension de la structure de l'application et de la logique de son fonctionnement permettra de trouver les vecteurs d'attaque les plus complexes.

Il est important de trouver des endroits qui semblent suspects ou quelque chose de très différent des autres. Et la première vulnérabilité dangereuse a été trouvée de cette façon.

IDOR

Les vulnérabilités IDOR (Insecure Direct Object Reference, liens directs non sécurisés vers des objets) sont l'une des vulnérabilités les plus courantes dans la logique métier qui permet d'une manière ou d'une autre d'accéder à des objets auxquels l'accès n'est en fait pas autorisé. Les vulnérabilités IDOR créent la possibilité d'obtenir des informations utilisateur de différents degrés de criticité.

L'une des options IDOR consiste à effectuer des actions avec des objets système (utilisateurs, comptes bancaires, marchandises dans le panier) en manipulant des identificateurs d'accès pour ces objets. Cela conduit aux conséquences les plus imprévisibles. Par exemple, la possibilité de substitution du compte de l'expéditeur, grâce à laquelle vous pouvez les voler à d'autres utilisateurs.

Dans le cas de MCS, les auditeurs viennent de découvrir la vulnérabilité IDOR associée aux identifiants non système. Dans le compte personnel de l'utilisateur, pour accéder à tous les objets, des UUID ont été utilisés, qui semblaient, comme disent les agents de sécurité, incroyablement non grossiers (c'est-à-dire protégés contre les attaques par force brute). Mais pour certaines entités, il a été découvert que des nombres prévisibles ordinaires sont utilisés pour obtenir des informations sur les utilisateurs de l'application. Je pense que vous vous rendez compte qu'il était possible de changer l'ID utilisateur par un, d'envoyer à nouveau la demande et ainsi obtenir des informations en contournant l'ACL (liste de contrôle d'accès, règles d'accès aux données pour les processus et les utilisateurs).

Falsification de requêtes côté serveur (SSRF)

Les produits OpenSource sont bons car ils ont un grand nombre de forums avec une description technique détaillée des problèmes qui se posent et, si vous êtes chanceux, avec une description de la solution. Mais cette pièce a un revers: des vulnérabilités bien connues sont également détaillées. Par exemple, le forum OpenStack a de merveilleuses descriptions des vulnérabilités [XSS] et [SSRF] , que pour une raison quelconque personne n'est pressé de corriger.

La fonctionnalité d'application fréquente est la possibilité pour l'utilisateur d'envoyer un lien vers le serveur sur lequel le serveur clique (par exemple, pour télécharger une image à partir d'une source spécifiée). Avec un filtrage de sécurité insuffisant des liens ou des réponses eux-mêmes renvoyés du serveur aux utilisateurs, une telle fonctionnalité est facilement utilisée par les attaquants.

Les vulnérabilités SSRF peuvent considérablement faire progresser le développement des attaques. Un attaquant peut obtenir:

• accès limité au réseau local attaqué, par exemple, uniquement sur certains segments de réseau et sur un certain protocole;
  
• un accès complet au réseau local, si une rétrogradation est possible du niveau de l'application au niveau du transport et, par conséquent, une gestion complète de la charge au niveau de l'application;
  
• accès à la lecture des fichiers locaux sur le serveur (si le schéma file: /// est supporté);
  
• et bien plus.
  

OpenStack est connu depuis longtemps pour sa vulnérabilité SSRF «aveugle»: lorsque vous accédez au serveur, vous n'en obtenez pas de réponse, mais vous obtenez différents types d'erreurs / retards, selon le résultat de la demande. Sur cette base, vous pouvez analyser les ports sur les hôtes du réseau interne, avec toutes les conséquences qui en découlent, qui ne doivent pas être sous-estimées. Par exemple, un produit peut avoir une API pour le back-office, disponible uniquement à partir du réseau d'entreprise. Possédant de la documentation (n'oubliez pas les initiés), un attaquant peut employer des méthodes internes utilisant SSRF. Par exemple, si vous avez réussi à obtenir une liste approximative d'URL utiles, alors en utilisant SSRF, vous pouvez les parcourir et exécuter une demande - relativement parlant, transférer de l'argent d'un compte à un autre ou modifier les limites.

Ce n'est pas le premier cas de détection de vulnérabilités SSRF dans OpenStack. Dans le passé, il était possible de télécharger des images ISO VM via un lien direct, ce qui a également entraîné des conséquences similaires. Cette fonctionnalité est actuellement supprimée d'OpenStack. Apparemment, la communauté considérait que c'était la solution la plus simple et la plus fiable au problème.

Et dans ce rapport accessible au public du service HackerOne (h1), l'exploitation d'un SSRF non aveugle avec la possibilité de lire les métadonnées d'instance conduit à un accès root à l'ensemble de l'infrastructure Shopify.

Dans MCS, à deux endroits avec des fonctionnalités similaires, des vulnérabilités SSRF ont été découvertes, mais elles étaient presque impossibles à exploiter en raison de pare-feu et d'autres protections. D'une manière ou d'une autre, l'équipe MCS a quand même résolu ce problème, sans attendre la communauté.

XSS au lieu de charger des obus

Malgré des centaines d'études écrites, d'année en année, XSS (attaque de script intersite) est toujours la vulnérabilité (ou attaque ?) La plus courante sur le Web.

Le téléchargement de fichiers est un lieu de prédilection pour tout chercheur en sécurité. Souvent, il s'avère que vous pouvez charger un script arbitraire (asp / jsp / php) et exécuter des commandes OS, dans la terminologie des pentesters - «load shell». Mais la popularité de ces vulnérabilités fonctionne dans les deux sens: elles sont mémorisées et ont développé des outils contre elles, si récemment la probabilité de «charger le shell» tend à zéro.

L'équipe attaquante (représentée par Digital Security) a eu de la chance. OK, dans MCS, côté serveur, le contenu des fichiers téléchargés a été vérifié, seules les images ont été autorisées. Mais SVG est aussi une image. Et que peuvent être des images SVG dangereuses? Parce que vous pouvez y incorporer des fragments JavaScript!

Il s'est avéré que les fichiers téléchargés sont disponibles pour tous les utilisateurs du service MCS - ce qui signifie que vous pouvez attaquer d'autres utilisateurs du cloud, à savoir les administrateurs.


Un exemple d'utilisation d'un formulaire de connexion de phishing à l'aide d'une attaque XSS

Exemples d'exploitation d'une attaque XSS:

• Pourquoi essayer de voler une session (d'autant plus que maintenant partout les cookies HTTP uniquement sont protégés contre le vol à l'aide de scripts js) si le script téléchargé peut accéder immédiatement à l'API de ressources? Dans ce cas, la charge utile peut modifier la configuration du serveur via des requêtes XHR, par exemple, ajouter la clé SSH publique de l'attaquant et obtenir un accès SSH au serveur.
  
• Si la politique CSP (politique de protection du contenu) interdit l'implémentation de JavaScript, un attaquant pourrait s'en passer. En HTML pur, créez le faux formulaire de connexion du site et volez le mot de passe administrateur par un tel hameçonnage avancé: la page d'hameçonnage de l'utilisateur est à la même URL, et il est plus difficile à détecter pour l'utilisateur.
  
• Enfin, un attaquant peut organiser un DoS client - définir des cookies supérieurs à 4 Ko. Il suffit à l'utilisateur d'ouvrir le lien une fois et l'ensemble du site devient inaccessible jusqu'à ce que vous deviniez spécialement de nettoyer le navigateur: dans la grande majorité des cas le serveur web refusera d'accepter un tel client.
  

Regardons un exemple d'un autre XSS révélé, cette fois avec un fonctionnement plus délicat. Le service MCS vous permet de combiner les paramètres du pare-feu en groupes. XSS a été découvert dans le nom du groupe. Sa particularité était que le vecteur ne fonctionnait pas immédiatement, non pas lors de la visualisation de la liste des règles, mais lorsque le groupe était supprimé:



Autrement dit, le scénario était le suivant: un attaquant crée une règle de pare-feu avec une «charge» dans le nom, l'administrateur le remarque après un certain temps, lance le processus de suppression. Et ici, le JS malveillant remplit également.

Pour les développeurs MCS, pour se protéger contre XSS dans les images SVG téléchargeables (si elles ne peuvent pas être abandonnées), l'équipe de sécurité numérique a recommandé:

• Héberger des fichiers téléchargés par des utilisateurs sur un domaine distinct qui n'a rien à voir avec un «cookie». Le script sera exécuté dans le contexte d'un autre domaine et ne constituera pas une menace pour MCS.
  
• Dans la réponse HTTP du serveur, donnez l'en-tête «Content-disposition: attachment». Ensuite, les fichiers seront téléchargés par le navigateur et ne seront pas exécutés.
  

De plus, les développeurs disposent désormais de nombreux moyens pour atténuer les risques liés à l'exploitation de XSS:

• en utilisant l'indicateur «HTTP uniquement», vous pouvez rendre les en-têtes de session des cookies inaccessibles à JavaScript malveillant;
  
• une stratégie CSP correctement implémentée compliquera considérablement le fonctionnement de XSS pour un attaquant;
  
• les moteurs de modèles modernes, tels que Angular ou React, effacent automatiquement les données utilisateur avant de les afficher dans le navigateur de l'utilisateur.
  

Vulnérabilités d'authentification à deux facteurs

Pour augmenter la sécurité du compte, il est toujours conseillé aux utilisateurs d'activer 2FA (authentification à deux facteurs). En effet, il s'agit d'un moyen efficace d'empêcher un attaquant d'accéder au service si les informations d'identification de l'utilisateur ont été compromises.

Mais l'utilisation du deuxième facteur d'authentification garantit-elle toujours la sécurité du compte? Dans une implémentation 2FA, il existe de tels problèmes de sécurité:

• Recherche approximative du code OTP (codes uniques). Malgré la simplicité de fonctionnement, des erreurs comme le manque de protection contre la brute OTP sont également rencontrées par les grandes entreprises: l' affaire Slack , l'affaire Facebook .
  
• Algorithme de génération faible, par exemple, la capacité de prédire le code suivant.
  
• Erreurs logiques, par exemple, la possibilité de demander l'OTP de quelqu'un d'autre sur votre téléphone, comme c'était le cas avec Shopify.
  

Dans le cas de MCS, 2FA est implémenté sur la base de Google Authenticator et Duo . Le protocole lui-même a déjà été testé par le temps, mais la mise en œuvre de la vérification du code côté application mérite d'être vérifiée.

Le MCS 2FA est utilisé à plusieurs endroits:

• Lors de l'authentification des utilisateurs. Ici, il y a une protection contre la force brute: l'utilisateur n'a que quelques tentatives pour entrer un mot de passe à usage unique, puis l'entrée est bloquée pendant un certain temps. Cela bloque la possibilité d'effectuer la suppression OTP.
  
• Lors de la génération de codes de sauvegarde hors ligne pour exécuter 2FA, ainsi que de la désactiver. Ici, la protection contre la force brute n'a pas été implémentée, ce qui a permis de régénérer les codes de sauvegarde ou de désactiver complètement 2FA s'il y avait un mot de passe pour le compte et une session active.
  

Étant donné que les codes de sauvegarde se trouvaient dans la même plage de valeurs de ligne que celles générées par l'application OTP, la chance de récupérer le code en peu de temps était beaucoup plus élevée.


Le processus de sélection d'OTP pour désactiver 2FA à l'aide de l'outil Burp: Intruder

Résultat

En général, MCS en tant que produit s'est avéré sûr. Au cours de l'audit, l'équipe Pentester n'a pas pu accéder aux machines virtuelles clientes et à leurs données, et les vulnérabilités trouvées ont été rapidement corrigées par l'équipe MCS.

Mais ici, il est important de noter que la sécurité est un travail continu. Les services ne sont pas statiques, ils évoluent constamment. Et développer un produit complètement sans vulnérabilités est impossible. Mais vous pouvez les trouver à temps et minimiser les risques de répétition.

Maintenant, toutes les vulnérabilités mentionnées dans MCS sont déjà corrigées. Et afin de minimiser le nombre de nouveaux et de raccourcir leur durée de vie, l'équipe de la plateforme continue de le faire:

• effectuer des audits réguliers par des sociétés externes;
  
• pour soutenir et développer la participation au groupe Mail.ru du programme Bug Bounty ;
  
• pour faire de la sécurité. :)