Exemple de mission

Pentest Cloud : Prestataire informatique

Prestataire informatique

5 jours

Microsoft Azure

Pentest Cloud

Contexte et résultats adaptés à des fins d’illustration et de confidentialité.

Contexte de la mission

Le défi

Contexte

Un prestataire informatique a migré ses applications et son stockage vers Azure. Il héberge des données clients et souhaite vérifier les conséquences d’un compte compromis avant de présenter les résultats de ses tests à ses donneurs d’ordre.

Le pentest commence avec un compte en lecture seule sur un abonnement et porte sur les ressources Azure, les identités applicatives et les accès aux secrets de cet environnement.

Objectifs

Évaluer la sécurité de l'environnement Azure après migration complète
Tester la possibilité de devenir administrateur depuis un compte avec des droits limités
Documenter les risques et les corrections à présenter aux donneurs d’ordre

Déroulement

Découvertes clés

Périmètre testé

Annuaire des utilisateurs et gestion des accès (Entra ID)
Applications hébergées dans le cloud (App Services)
Coffre-fort numérique pour les mots de passe et clés (Key Vault)
Stockage de fichiers et réseau virtuel
Tests simulant un attaquant ayant obtenu un compte avec des droits limités (Reader)

Méthodologie

Approche « on simule qu'un attaquant a déjà un accès limité » : l'auditeur part d'un compte en lecture seule et tente de progresser jusqu'aux droits d'administrateur en exploitant les mauvaises configurations.

Critique

Une identité applicative disposait de droits de lecture excessifs sur les secrets du coffre Key Vault

Critique

Une faille applicative exposait un fichier de configuration contenant le secret de cette identité applicative

Élevé

Paramètres de sécurité par défaut désactivés et règles d'accès conditionnel mal configurées

Moyen

Aucune alerte configurée sur les actions sensibles : un changement de droits ou un accès au coffre-fort passerait inaperçu

Élevé

Règles réseau trop permissives exposant des services internes à Internet

Moyen

Ressources de production supprimables sans contrôle ni validation

Résultats

Bilan et recommandations

Bilan

14 vulnérabilités : 2 critiques, 3 élevées, 4 moyennes, 5 faibles

Le compte en lecture seule a permis de repérer une application exposée, dont une faiblesse a donné accès à un fichier de configuration contenant le secret d’une identité applicative.

Cette identité pouvait lire les secrets de Key Vault, dont celui d’une autre identité disposant de droits d’administration sur l’abonnement Azure, ce qui a permis d’accéder aux ressources du périmètre.

À la suite du rapport recensant 14 vulnérabilités, le prestataire a remplacé les secrets exposés, réduit les permissions et corrigé l’application en un mois. Un test de suivi a vérifié que le chemin d’attaque initial ne fonctionnait plus.

Recommandations

Limiter les droits de chaque application au strict nécessaire
Corriger l’exposition du fichier de configuration et remplacer les secrets compromis
Réactiver les paramètres de sécurité par défaut ou corriger les règles d'accès conditionnel
Restreindre les connexions aux pays autorisés uniquement
Vérifier régulièrement les droits attribués à chaque compte et application

Enseignements

Leçons apprises

Le compte de départ ne permettant pas de lire directement les secrets, la compromission de l’application exposée a été nécessaire pour poursuivre le chemin d’attaque.
Le coffre Key Vault protégeait les valeurs stockées mais une identité applicative disposait de droits de lecture trop larges.
Le remplacement des secrets devait être accompagné d’une réduction des permissions pour empêcher la reproduction du même chemin d’attaque.

Continuité

Prochaines étapes

Audit de sécurité semestriel des configurations Azure
Mise en place d'alertes sur les actions sensibles (changements de droits, accès au coffre-fort, connexions inhabituelles)
Réaliser un nouveau pentest lors d’une évolution importante de l’environnement Azure