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 l'analyse régulière et l'amélioration de la protection du produit, la surveillance des actualités sur les vulnérabilités et bien plus encore. Cela inclut également les audits. Les audits sont réalisés tant par les équipes internes que par des experts externes, qui peuvent grandement aider à la sécurité, car ils ne sont pas plongés dans le projet et ont un regard neuf.

Cet article concerne ce regard neuf des experts externes, qui ont aidé l'équipe de Mail.ru Cloud Solutions (MCS) à tester le service cloud, et ce qu'ils ont trouvé. En tant que « forces externes », MCS a choisi la société Digital Security, reconnue pour sa haute expertise dans les cercles de la cybersécurité. Dans cet article, nous allons examiner certaines vulnérabilités intéressantes trouvées lors de l'audit externe - afin que vous n'ayez pas les mêmes écueils lorsque vous créerez votre service cloud.

Description du produit

Mail.ru Cloud Solutions (MCS) est une plateforme pour la construction d'infrastructures virtuelles dans le cloud. Elle comprend des IaaS, des PaaS, un marketplace d'images d'applications prêtes 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 au niveau réseau, réseaux privés dans un SDN ;
• OpenStack et ses composants ouverts ;
• S3 développé en interne ;
• IAM : projets multitenants avec modèle basé sur les rôles ;
• Vision (vision par ordinateur) : API et vulnérabilités lors du travail avec des images ;
• interface web et attaques web classiques ;
• vulnérabilités des composants PaaS ;
• API de tous les composants.

Sans doute, c'est tout ce qui est essentiel pour l'histoire à venir.

Quels travaux ont été réalisés et pourquoi sont-ils nécessaires ?

L'audit de sécurité vise à identifier les vulnérabilités et les erreurs de configuration qui peuvent entraîner la fuite de données personnelles, la modification d'informations sensibles ou perturber la disponibilité des services.

Au cours des travaux, qui durent en moyenne 1 à 2 mois, les auditeurs reproduisent les actions des potentiels attaquants et recherchent des vulnérabilités dans la partie cliente et serveur du service choisi. Dans le cadre de l'audit de la plateforme cloud MCS, les objectifs suivants ont été définis :

1. Analyse de l'authentification dans le service. Les vulnérabilités dans ce composant permettraient d'accéder immédiatement à d'autres comptes.
2. Étude du modèle de rôles et de la séparation des accès entre différents comptes. Pour un attaquant, la possibilité d'accéder à une machine virtuelle étrangère est un objectif très désirable.
3. Vulnérabilités de la partie cliente. XSS/CSRF/CRLF/etc. Existe-t-il une possibilité d'attaquer d'autres utilisateurs par le biais de liens malveillants ?
4. Vulnérabilités de la partie serveur : RCE et toutes sortes d'injections (SQL/XXE/SSRF, etc.). Les vulnérabilités serveur sont généralement plus difficiles à détecter, mais elles entraînent la compromission de plusieurs utilisateurs à la fois.
5. Analyse de l'isolation des segments utilisateurs au niveau réseau. Pour un attaquant, l'absence d'isolation augmente considérablement la surface d'attaque sur d'autres utilisateurs.
6. Analyse de la logique métier. Est-il possible de tromper le système et de créer des machines virtuelles gratuitement ?

Dans ce projet, les travaux ont été réalisés selon le modèle « Gray-box » : les auditeurs interagissaient avec le service en ayant les privilèges d'utilisateurs ordinaires, mais disposaient partiellement des codes source de l'API et pouvaient poser des questions aux développeurs. C'est généralement le modèle de travail le plus pratique et réaliste : les informations internes peuvent tout de même être collectées par un attaquant, c'est seulement une question de temps.

Vulnérabilités trouvées

Avant qu'un auditeur ne commence à envoyer divers payloads (charge utile utilisée pour réaliser une attaque) à des endroits aléatoires, il est nécessaire de comprendre comment tout cela fonctionne, quel est le fonctionnel proposé. Cela peut sembler une tâche inutile, car dans la plupart des endroits étudiés, il n'y aura pas de vulnérabilités. Mais seule la 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 qui diffèrent considérablement des autres. La première vulnérabilité dangereuse a été trouvée précisément de cette manière.

IDOR

Les vulnérabilités IDOR (Insecure Direct Object Reference, références directes d'objets non sécurisées) sont l'un des types de vulnérabilités les plus fréquents dans la logique métier, permettant d'accéder, d'une manière ou d'une autre, à des objets auxquels l'accès n'est en réalité pas autorisé. Les vulnérabilités IDOR rendent possible l'obtention d'informations sur les utilisateurs de différents niveaux de criticité.

L'une des variantes de l'IDOR consiste à effectuer des actions sur des objets du système (utilisateurs, comptes bancaires, articles dans le panier) en manipulant les identifiants d'accès à ces objets. Cela peut avoir des conséquences imprévisibles. Par exemple, cela peut permettre de substituer le compte d'un expéditeur de fonds, ce qui permet de les voler à d'autres utilisateurs.

Dans le cas de MCS, les auditeurs ont découvert une vulnérabilité IDOR liée à des identifiants non sécurisés. Dans le cabinet personnel de l'utilisateur, des identifiants UUID étaient utilisés pour accéder à des objets, qui semblaient, selon les spécialistes de la sécurité, remarquablement résistants à une attaque par force brute (c'est-à-dire protégés contre l'attaque par essai). Mais pour certaines entités, il a été découvert que des numéros prévisibles étaient utilisés pour obtenir des informations sur les utilisateurs de l'application. Je pense que vous devinez qu'il suffisait de modifier l'ID utilisateur de un, de renvoyer la requête et d'obtenir ainsi des informations en contournant la ACL (access control list, règles d'accès aux données pour les processus et utilisateurs).

Server Side Request Forgery (SSRF)

Les produits OpenSource sont appréciés pour la grande quantité de forums avec des descriptions techniques détaillées des problèmes rencontrés et, si vous avez de la chance, des solutions. Mais cette médaille a un revers : les vulnérabilités connues sont également décrites en détail. Par exemple, le forum OpenStack contient d'excellentes descriptions de vulnérabilités. [XSS] et [SSRF], qui apparemment, personne ne se presse à corriger.

Une fonctionnalité courante des applications est la possibilité pour l'utilisateur d'envoyer au serveur un lien sur lequel le serveur se rend (par exemple, pour charger une image à partir d'une source indiquée). Avec une filtration insuffisante des liens ou des réponses retournées par le serveur aux utilisateurs, cette fonctionnalité peut facilement être exploitée par des attaquants.

Les vulnérabilités SSRF peuvent faire avancer considérablement une attaque. L'attaquant peut obtenir :

• un accès limité au réseau local attaqué, par exemple seulement à certains segments du réseau et par un certain protocole ;
• un accès complet au réseau local, si un downgrade est possible du niveau applicatif au niveau de transport, et par conséquent un contrôle total sur la charge au niveau applicatif ;
• un accès en lecture aux fichiers locaux sur le serveur (si le schéma file:// est supporté) ;
• et bien plus encore.

Dans OpenStack, une vulnérabilité SSRF connue depuis longtemps présente un caractère « aveugle » : lorsque vous interrogez un serveur, vous ne recevez pas de réponse de sa part, mais vous obtenez différents types d'erreurs/délays, selon le résultat de la requête. Sur cette base, il est possible d'effectuer une analyse de ports sur des hôtes dans le réseau interne, avec toutes les conséquences qui en découlent et qu'il ne faut pas sous-estimer. Par exemple, un produit peut avoir une API pour le back-office, accessible uniquement depuis le réseau d'entreprise. En possédant la documentation (sans oublier les initiés), un attaquant peut utiliser SSRF pour accéder à des méthodes internes. Par exemple, s'il a pu obtenir d'une manière ou d'une autre une liste approximative de fichiers URL valables, il peut passer par celles-ci avec SSRF et exécuter une requête — pour simplifier, transférer des fonds d'un compte à un autre ou modifier des limites.

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

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

Dans MCS, deux endroits avec une fonctionnalité similaire ont révélé des vulnérabilités SSRF, mais il était pratiquement impossible de les exploiter en raison des pare-feux et autres protections. Quoi qu'il en soit, l'équipe MCS a quand même corrigé ce problème sans attendre la communauté.

XSS au lieu de charger des « shells »

Malgré des centaines d'études rédigées, année après année, le XSS (attaque de script intersite) reste la vulnérabilité web la plus fréquemment rencontrée (ou attaque?).

Le téléchargement de fichiers est un lieu favori pour tout chercheur en sécurité. Il arrive souvent qu'il soit possible de télécharger un script arbitraire (asp/jsp/php) et d'exécuter des commandes système, ce que les testeurs de pénétration appellent « uploader un shell ». Mais la popularité de ces vulnérabilités joue dans les deux sens : on s'en souvient et on développe des moyens de s'en protéger, si bien que dernièrement la probabilité de « uploader un shell » tend vers zéro.

L'équipe attaquante (représentée par Digital Security) a eu de la chance. D'accord, dans le MCS, le contenu des fichiers téléchargés était vérifié du côté serveur, seuls les fichiers images étaient autorisés. Mais un SVG, c'est aussi une image. Et en quoi les images SVG peuvent-elles être dangereuses ? Parce qu'elles peuvent contenir des fragments de JavaScript !

Il s'est avéré que les fichiers téléchargés étaient accessibles à tous les utilisateurs du service MCS – il était donc possible d'attaquer d'autres utilisateurs du cloud, notamment les administrateurs.

Exemple d'injection via une attaque XSS d'un formulaire de connexion de phishing

Exemples d'exploitation d'une attaque XSS :

• Pourquoi essayer de voler une session (surtout que maintenant il y a des cookies HTTP-Only, protégés contre le vol par des scripts JS), si le script téléchargé peut directement accéder à l'API de la ressource ? Dans ce cas, la charge utile peut, via des requêtes XHR, modifier la configuration du serveur, par exemple en ajoutant la clé SSH ouverte d'un pirate et obtenir un accès SSH au serveur.
• Si la politique CSP (politique de sécurité du contenu) interdit l'injection de JavaScript, l'attaquant peut s'en passer. Sur du HTML pur, il peut créer un faux formulaire de connexion au site et voler le mot de passe de l'administrateur grâce à un phishing sophistiqué : la page de phishing pour l'utilisateur apparaît sur la même URL, et il est plus difficile pour l'utilisateur de la détecter.
• Enfin, l'attaquant peut provoquer un DoS client en définissant des cookies d'une taille supérieure à 4 Ko. L'utilisateur n'a qu'à ouvrir le lien une seule fois — et tout le site devient inaccessible, jusqu'à ce qu'il devine de nettoyer son navigateur : dans la grande majorité des cas, le serveur web refusera d'accepter un tel client.

Considérons un exemple d'une autre XSS identifiée, cette fois avec une exploitation plus astucieuse. Le service MCS permet de regrouper les règles de pare-feu. C'est dans le nom du groupe qu'une XSS a été découverte. Sa particularité était que le vecteur ne se déclenchait pas immédiatement, pas lors de l'affichage de la liste des règles, mais lors de la suppression du groupe :

Ainsi, le scénario était le suivant : un attaquant crée une règle de pare-feu avec un « chargement » dans le nom, l'administrateur la remarque après un certain temps et initie le processus de suppression. C'est à ce moment-là que le JS malveillant s'exécute.

Pour protéger les développeurs de MCS contre les XSS dans les images SVG téléchargées (si elles ne peuvent pas être évitées), l'équipe de Digital Security a recommandé :

• De placer les fichiers téléchargés par les utilisateurs sur un domaine séparé, sans lien avec les « cookies ». Le script s'exécutera dans le contexte d'un autre domaine et ne représentera pas de menace pour MCS.
• D'inclure dans la réponse HTTP du serveur l'en-tête « Content-disposition: attachment ». Ainsi, les fichiers seront téléchargés par le navigateur et non exécutés.

De plus, il existe aujourd'hui de nombreuses façons pour les développeurs d'atténuer les risques d'exploitation des XSS :

• L'utilisation du drapeau « HTTP Only » peut rendre les en-têtes de session « Cookies » inaccessibles au JavaScript malveillant ;
• Une politique CSP correctement implémentée rendra considérablement plus difficile l'exploitation des XSS pour l'attaquant ;
• Les modèles modernes, comme Angular ou React, nettoient automatiquement les données des utilisateurs avant de les afficher dans le navigateur de l'utilisateur.

Vulnérabilités de l'authentification à deux facteurs

Pour améliorer la sécurité des comptes, il est toujours recommandé aux utilisateurs d'activer le 2FA (authentification à deux facteurs). En effet, c'est un moyen efficace d'empêcher un attaquant d'accéder au service si les identifiants de l'utilisateur ont été compromis.

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

• La brute force sur le code OTP (codes à usage unique). Malgré la simplicité de l’exploitation, de telles erreurs, comme l’absence de protection contre la force brute pour les OTP, se retrouvent même chez de grandes entreprises : le cas de Slack, le cas de Facebook.
• Un algorithme de génération faible, par exemple la possibilité de prédire le code suivant.
• Des erreurs logiques, par exemple la possibilité de demander l’OTP d’un autre sur son téléphone, comme cela c'était a été le cas chez Shopify.

Dans le cas de MCS, le 2FA est basé sur Google Authenticator et Duo. Le protocole lui-même est éprouvé, mais il vaut la peine de vérifier l'implémentation de la vérification du code du côté de l'application.

Dans MCS, le 2FA est utilisé à plusieurs endroits :

• Lors de l'authentification d'un utilisateur. Un système de protection contre les tentatives répétées est en place : l'utilisateur a seulement quelques essais pour saisir le mot de passe temporaire, après quoi la saisie est bloquée pendant un certain temps. Cela empêche la possibilité de deviner le code OTP par essai-erreur.
• Lors de la génération de codes de sauvegarde hors ligne pour la mise en œuvre de la 2FA, ainsi que pour sa désactivation. Ici, il n'y avait pas de protection contre les tentatives répétées, permettant ainsi, avec le mot de passe du compte et une session active, de régénérer les codes de sauvegarde ou de désactiver complètement la 2FA.

Étant donné que les codes de sauvegarde étaient situés dans la même plage de valeurs que les OTP générés par l'application, la chance de deviner un code en peu de temps était considérablement plus élevée.

Le processus de devinette d'un OTP pour désactiver la 2FA à l'aide de l'outil « Burp: Intruder ».

Résultat

Dans l'ensemble, MCS en tant que produit s'est révélé sécurisé. Au cours de l'audit, l'équipe de test de pénétration n'a pas réussi à accéder aux VM des clients ni à leurs données, et les vulnérabilités trouvées ont été rapidement corrigées par l'équipe MCS.

Cependant, il est important de noter que la sécurité est un travail continu. Les services ne sont pas statiques, ils évoluent constamment. Concevoir un produit complètement exempt de vulnérabilités est impossible. Mais il est possible de les identifier à temps et de minimiser la chance qu'elles se reproduisent.

À présent, toutes les vulnérabilités mentionnées dans MCS ont déjà été corrigées. Afin de minimiser le nombre de nouvelles vulnérabilités et de réduire leur existence, l'équipe de la plateforme continue de faire cela :

• réaliser régulièrement des audits par des entreprises externes ;
• maintenir et développer la participation au programme Bug Bounty de Mail.ru Group;
• se préoccuper de la sécurité. 🙂

Source : habr.com