par SeerLight
Construire 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 constantes de la sécurité des produits, la surveillance des informations sur les vulnérabilités et bien plus encore. Y compris les audits. Les audits sont réalisés à la fois en interne et par des experts externes, qui peuvent radicalement aider en matière de sécurité car ils ne sont pas immergés dans le projet et ont l'esprit ouvert.
L'article présente le point de vue le plus simple des experts externes qui ont aidé l'équipe Mail.ru Cloud Solutions (MCS) à tester le service cloud, ainsi que ce qu'ils ont trouvé. En tant que « force externe », MCS a choisi la société Digital Security, connue pour sa grande expertise dans les milieux de la sécurité de l’information. Et dans cet article, nous analyserons quelques vulnérabilités intéressantes trouvées dans le cadre d'un audit externe - afin que vous évitiez le même râteau lorsque vous créez votre propre service cloud.
Описание продукта
est une plateforme permettant de créer une infrastructure virtuelle dans le cloud. Il comprend IaaS, PaaS et un marché d'images d'applications prêtes à l'emploi pour les développeurs. Compte tenu de l'architecture MCS, il était nécessaire de vérifier la sécurité du produit dans les domaines suivants :
- protéger l'infrastructure de l'environnement de virtualisation : hyperviseurs, routage, pare-feu ;
- protection des infrastructures virtuelles des clients : isolement les uns des autres, y compris réseau, réseaux privés en SDN ;
- OpenStack et ses composants ouverts ;
- S3 de notre propre conception ;
- IAM : projets multi-tenants avec un modèle ;
- 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.
C’est peut-être tout ce qui est essentiel pour la suite de l’histoire.
Quel type de travail a été effectué et pourquoi était-il nécessaire ?
Un audit de sécurité vise à identifier les vulnérabilités et les erreurs de configuration qui pourraient entraîner une fuite de données personnelles, une modification d'informations sensibles ou une interruption de la disponibilité du service.
Au cours du travail, qui dure en moyenne 1 à 2 mois, les auditeurs répètent les actions des attaquants potentiels et recherchent des 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 :
- Analyse de l'authentification dans le service. Les vulnérabilités de ce composant permettraient d'accéder immédiatement aux comptes d'autres personnes.
- Étudier le modèle de rôle et le 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 un objectif souhaitable.
- Vulnérabilités côté client. XSS/CSRF/CRLF/etc. Est-il possible d’attaquer d’autres utilisateurs via des liens malveillants ?
- Vulnérabilités côté serveur : RCE et toutes sortes d'injections (SQL/XXE/SSRF etc.). Les vulnérabilités des serveurs sont généralement plus difficiles à trouver, mais elles conduisent à la compromission de plusieurs utilisateurs à la fois.
- Analyse de l'isolement des segments d'utilisateurs au niveau du réseau. Pour un attaquant, le manque d’isolement augmente considérablement la surface d’attaque contre les autres utilisateurs.
- Analyse de la logique métier. Est-il possible de tromper les entreprises et de créer des machines virtuelles gratuitement ?
Dans ce projet, le travail a été réalisé selon le modèle « Gray-box » : les auditeurs interagissaient avec le service avec les privilèges des utilisateurs ordinaires, mais possédaient partiellement le code source de l'API et avaient la possibilité de clarifier les détails avec les développeurs. Il s’agit généralement du modèle de travail le plus pratique et en même temps le plus réaliste : des informations internes 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 ne commence à envoyer diverses charges utiles (la charge utile utilisée pour mener l’attaque) vers des endroits aléatoires, il est nécessaire de comprendre comment les choses fonctionnent et quelles fonctionnalités sont fournies. Il peut sembler que cet exercice soit inutile, car dans la plupart des lieux étudiés, il n’y aura aucune vulnérabilité. 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 sont très différents des autres d'une manière ou d'une autre. Et c’est ainsi que la première vulnérabilité dangereuse a été découverte.
IDEUR
Les vulnérabilités IDOR (Insecure Direct Object Reference) sont l'une des vulnérabilités les plus courantes de la logique métier, qui permet à l'un ou l'autre d'accéder à des objets auxquels l'accès n'est réellement pas autorisé. Les vulnérabilités IDOR créent la possibilité d'obtenir des informations sur un utilisateur plus ou moins critiques.
L'une des options d'IDOR consiste à effectuer des actions avec les objets système (utilisateurs, comptes bancaires, articles dans le panier) en manipulant les identifiants d'accès à ces objets. Cela conduit aux conséquences les plus imprévisibles. Par exemple, la possibilité de remplacer le compte de l'expéditeur des fonds, grâce auquel vous pourrez les voler à d'autres utilisateurs.
Dans le cas de MCS, les auditeurs viennent de découvrir une vulnérabilité IDOR associée à des identifiants non sécurisés. Dans le compte personnel de l'utilisateur, les identifiants UUID étaient utilisés pour accéder à tous les objets qui semblaient, comme le disent les experts en sécurité, incroyablement peu sécurisés (c'est-à-dire protégés contre les attaques par force brute). Mais pour certaines entités, il a été découvert que des numéros prévisibles réguliers sont utilisés pour obtenir des informations sur les utilisateurs de l'application. Je pense que vous pouvez deviner qu'il était possible de changer l'ID utilisateur par un, de renvoyer la demande et ainsi d'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).
Contrefaçon de demande côté serveur (SSRF)
L'avantage des produits OpenSource est qu'ils disposent d'un grand nombre de forums avec des descriptions techniques détaillées des problèmes qui surviennent et, si vous avez de la chance, une description de la solution. Mais cette médaille a un revers : les vulnérabilités connues sont également décrites en détail. Par exemple, il existe de merveilleuses descriptions de vulnérabilités sur le forum OpenStack и , que, pour une raison quelconque, personne n'est pressé de réparer.
Une fonctionnalité courante des applications est la possibilité pour l'utilisateur d'envoyer un lien au serveur sur lequel le serveur clique (par exemple, pour télécharger une image à partir d'une source spécifiée). Si les outils de sécurité ne filtrent pas les liens eux-mêmes ou les réponses renvoyées par le serveur aux utilisateurs, cette fonctionnalité peut facilement être utilisée par des attaquants.
Les vulnérabilités SSRF peuvent considérablement accélérer le développement d’une attaque. Un attaquant peut obtenir :
- accès limité au réseau local attaqué, par exemple, uniquement via certains segments de réseau et en utilisant un certain protocole ;
- un accès complet au réseau local, si le passage du niveau applicatif au niveau transport est possible et, par conséquent, une gestion complète de la charge au niveau applicatif ;
- accès pour lire les fichiers locaux sur le serveur (si le schéma file:/// est pris en charge) ;
- И многое другое.
Une vulnérabilité SSRF est connue depuis longtemps dans OpenStack, qui est de nature « aveugle » : lorsque vous contactez le serveur, vous ne recevez pas de réponse de sa part, mais vous recevez différents types d'erreurs/retards, en fonction du résultat de la requête. . Sur cette base, vous pouvez effectuer une analyse des ports sur les hôtes du réseau interne, avec toutes les conséquences qui en découlent et qui ne doivent pas être sous-estimées. Par exemple, un produit peut disposer d’une API de back-office accessible uniquement depuis le réseau de l’entreprise. Avec la documentation (n'oubliez pas les initiés), un attaquant peut utiliser SSRF pour accéder aux méthodes internes. Par exemple, si vous parvenez d'une manière ou d'une autre à 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 à l'autre ou modifier les limites.
Ce n'est pas la première fois qu'une vulnérabilité SSRF est découverte dans OpenStack. Dans le passé, il était possible de télécharger des images ISO de VM à partir d'un lien direct, ce qui entraînait également des conséquences similaires. Cette fonctionnalité a maintenant été supprimée d'OpenStack. Apparemment, la communauté considérait cela comme la solution la plus simple et la plus fiable au problème.
Et dans rapport accessible au public du service HackerOne (h1), l'exploitation d'un SSRF qui n'est plus aveugle avec la possibilité de lire les métadonnées de l'instance conduit à un accès root à l'ensemble de l'infrastructure Shopify.
Dans MCS, des vulnérabilités SSRF ont été découvertes à deux endroits avec des fonctionnalités similaires, mais elles étaient presque impossibles à exploiter en raison des pare-feu et 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 shells
Malgré des centaines d'études rédigées, année après année, l'attaque XSS (cross-site scripting) reste la plus vulnérabilité Web (ou ?).
Les téléchargements de fichiers sont un lieu de prédilection pour tout chercheur en sécurité. Il s'avère souvent que vous pouvez charger un script arbitraire (asp/jsp/php) et exécuter des commandes du système d'exploitation, 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 des remèdes sont développés contre elles, de sorte que récemment, la probabilité de « charger un obus » tend vers 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 étaient autorisées. Mais SVG est aussi une image. En quoi les images SVG peuvent-elles être dangereuses ? Parce que vous pouvez y intégrer des extraits de code 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 qu'il est possible d'attaquer d'autres utilisateurs du cloud, notamment les administrateurs.
Un exemple d'attaque XSS sur un formulaire de connexion de phishing
Exemples d’exploitation d’attaques XSS :
- Pourquoi essayer de voler une session (d'autant plus que désormais les cookies HTTP uniquement sont partout, protégés contre le vol à l'aide de scripts js), si le script chargé peut accéder immédiatement à l'API des ressources ? Dans ce cas, la charge utile peut utiliser les requêtes XHR pour modifier la configuration du serveur, par exemple, ajouter la clé SSH publique de l'attaquant et obtenir un accès SSH au serveur.
- Si la politique CSP (content protection Policy) interdit l’injection de JavaScript, un attaquant peut s’en passer. En utilisant du HTML pur, créez un faux formulaire de connexion pour le site et volez le mot de passe de l'administrateur grâce à ce phishing avancé : la page de phishing destinée à l'utilisateur aboutit à la même URL, et il est plus difficile pour l'utilisateur de la détecter.
- Enfin, l'attaquant peut organiser — définissez des cookies de plus de 4 Ko. L'utilisateur n'a besoin d'ouvrir le lien qu'une seule fois, et l'ensemble du site devient inaccessible jusqu'à ce que l'utilisateur pense à nettoyer spécifiquement le navigateur : dans la grande majorité des cas, le serveur web refusera d'accepter un tel client.
Regardons un exemple d'un autre XSS détecté, cette fois avec un exploit plus intelligent. Le service MCS vous permet de combiner les paramètres du pare-feu en groupes. Le nom du groupe correspond à l'endroit où le XSS a été détecté. Sa particularité était que le vecteur ne se déclenchait pas immédiatement, non pas lors de la visualisation de la liste des règles, mais lors de la suppression d'un groupe :
Autrement dit, le scénario s'est avéré être le suivant : un attaquant crée une règle de pare-feu avec « load » dans le nom, l'administrateur le remarque après un certain temps et lance le processus de suppression. Et c’est là que fonctionne le JS malveillant.
Pour les développeurs MCS, afin de se protéger contre XSS dans les images SVG téléchargées (si elles ne peuvent pas être abandonnées), l'équipe de sécurité numérique a recommandé :
- Placez les fichiers téléchargés par les utilisateurs sur un domaine distinct qui n'a rien à voir avec les « cookies ». Le script sera exécuté dans le contexte d'un domaine différent et ne constituera pas une menace pour MCS.
- Dans la réponse HTTP du serveur, envoyez l'en-tête "Content-disposition: attachment". Ensuite, les fichiers seront téléchargés par le navigateur et non 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 le drapeau « HTTP Only », vous pouvez rendre les en-têtes « Cookies » de session inaccessibles au JavaScript malveillant ;
- rendra beaucoup plus difficile l’exploitation de XSS par un attaquant ;
- les moteurs de modèles modernes tels que Angular ou React nettoient automatiquement les données utilisateur avant de les envoyer au navigateur de l'utilisateur.
Vulnérabilités d'authentification à deux facteurs
Pour améliorer 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 pour empêcher un attaquant d'accéder à un service si les informations d'identification de l'utilisateur ont été compromises.
Mais l’utilisation d’un deuxième facteur d’authentification garantit-elle toujours la sécurité du compte ? Il existe les problèmes de sécurité suivants dans la mise en œuvre de 2FA :
- Recherche par force brute du code OTP (codes à usage unique). Malgré la simplicité de fonctionnement, des erreurs telles que le manque de protection contre la force brute OTP sont également rencontrées par les grandes entreprises : , .
- Algorithme de génération faible, par exemple la capacité de prédire le code suivant.
- Erreurs logiques, telles que la possibilité de demander l'OTP de quelqu'un d'autre sur votre téléphone, comme celle-ci de Shopify.
Dans le cas de MCS, 2FA est implémenté sur la base de Google Authenticator et . Le protocole lui-même a déjà fait ses preuves, mais la mise en œuvre de la vérification du code côté application mérite d'être vérifiée.
MCS 2FA est utilisé à plusieurs endroits :
- Lors de l'authentification de l'utilisateur. Il existe une protection contre la force brute : l'utilisateur ne dispose que de quelques tentatives pour saisir un mot de passe à usage unique, puis la saisie est bloquée pendant un certain temps. Cela bloque la possibilité de sélection par force brute d’OTP.
- Lors de la génération de codes de sauvegarde hors ligne pour effectuer 2FA, ainsi que de sa désactivation. Ici, aucune protection contre la force brute n'a été mise en place, ce qui permettait, si vous disposiez d'un mot de passe pour le compte et d'une session active, de régénérer les codes de sauvegarde ou de désactiver complètement le 2FA.
Étant donné que les codes de sauvegarde se trouvaient dans la même plage de valeurs de chaîne que celles générées par l'application OTP, les chances de trouver le code en peu de temps étaient beaucoup plus élevées.
Le processus de sélection d'un OTP pour désactiver 2FA à l'aide de l'outil « Burp : Intruder »
Résultat
Dans l’ensemble, le MCS semble être un produit sûr. Lors de l'audit, l'équipe de test d'intrusion n'a pas pu accéder aux machines virtuelles des clients 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 il est impossible de développer un produit totalement sans vulnérabilités. Mais vous pouvez les détecter à temps et minimiser les risques de récidive.
Désormais, toutes les vulnérabilités mentionnées dans MCS ont déjà été corrigées. Et afin de limiter au maximum le nombre de nouveaux et de réduire leur durée de vie, l'équipe de la plateforme continue de le faire :
- réaliser régulièrement des audits par des sociétés externes ;
- soutenir et développer la participation;
- s'engager dans la sécurité. 🙂
Source: habr.com