Violation du trimestre : les défauts de configuration des espaces de stockage dans le cloud public

Depuis plusieurs années, le nombre d’entités publiques ou privées ayant recours aux offres de cloud augmente sensiblement. Ce type de service présente l’assurance d’une disponibilité quasi-constante et d’une mise à l’échelle ou élasticité (« scalability » en anglais) automatique en fonction du trafic sur les serveurs. Le stockage proposé est le plus souvent un stockage dit « objet », lesquels sont placés dans des « conteneurs » (« buckets » en anglais).

Ces services, accompagnés de fonctionnalités de sécurité, permettent aux organismes qui les utilisent de déléguer une partie de la gestion de leurs infrastructures informatiques. Néanmoins, les configurations par défaut ne permettent pas de refléter les besoins de sécurité de chacune d’elles. Dans ce modèle, devenu majoritaire, la source d’une fuite de données personnelles n’est souvent pas due à une faille matérielle ou logicielle des systèmes gérés par les fournisseurs de cloud, mais bien à une mauvaise configuration de ces outils par les clients eux-mêmes.

Comment fonctionne ce type d’attaque ?

Julie travaille au département informatique d’une mutuelle de santé. Lundi dernier, en arrivant au bureau, après avoir bu un café et allumé son ordinateur, elle commence par dépiler ses courriels non lus. L’un d’eux l’interpelle : il provient d’un assuré qui l’informe que ses documents d’identité et ses derniers remboursements de santé sont accessibles librement sur internet, sans autre détail que l’URL permettant d’accéder à ces documents.

Après avoir vérifié que l’émetteur du courriel est bien l’un des clients de sa société et que l’URL transmise redirige bien vers le site web de la mutuelle, elle s’aperçoit que les données sont effectivement accessibles publiquement et que d’autres clients sont concernés.

Les causes potentielles de l’incident

Julie passe en revue rapidement les causes potentielles qui pourraient mener à l’accès libre de ces données :

• Un conteneur en accès public ? Lorsqu'un conteneur est « public », tout le monde dispose alors de droits pour voir ou insérer des objets dans le conteneur, ainsi que pour lire et éditer les autorisations du conteneur. Par ailleurs, même si le conteneur est toujours en accès « privé », il est nécessaire de bien configurer les politiques d’accès aux objets dans celui-ci.
• Des droits trop permissifs ? Dans la hâte ou par négligence, il peut arriver que des développeurs accordent par erreur à tous les utilisateurs (authentifiés ou non) des droits en écriture, des droits de suppression, voire le contrôle complet des objets dans le conteneur en dépit de leur sensibilité.
• Des mécanismes d’authentification inadéquats ? Souvent, les actions opérées sur les conteneurs ou les objets qu’ils contiennent sont réalisées sans la moindre authentification des utilisateurs ou avec une authentification faible, alors qu’une authentification forte, ou une authentification à deux facteurs ou plus, aurait été plus pertinente. Combinées à des droits trop permissifs, ces erreurs de configuration pourraient permettre à n’importe qui de supprimer le contenu complet d’un conteneur.

Julie sait que la première et principale difficulté pour un tiers malveillant est de trouver des conteneurs de stockage présentant des erreurs de configuration de sécurité, notamment celles permettant un accès libre à ces conteneurs.

De manière générale, pour les services de stockage cloud, les conteneurs sont le plus souvent désignés par des noms choisis par les utilisateurs qui les ont créés.

Les URLs de ces conteneurs ont une forme standardisée, par exemple :

Conteneurs S3 d’Amazon Web Services : « http[s]://NOM_DU_CONTENEUR.s3-REGION.amazonaws.com/ »
Conteneurs d’Alibaba Cloud OSS : « http[s]://NOM_DU_CONTENEUR.oss- REGION.aliyuncs.com/ »
Conteneurs d’Outscale Object Storage : « https://NOM_DU_CONTENEUR.oos.REGION.outscale.com/ »

Ce nom ou cette URL n’ont pas besoin d’être publiés pour qu’un attaquant exploite les vulnérabilités du conteneur qu’ils désignent car ils peuvent être cherchés et trouvés.

Par conséquent, pour découvrir un conteneur mal sécurisé, l’attaquant a dû les chercher de manière plus ou moins exhaustive et a pu procéder selon l’une ou plusieurs des recherches suivantes :

• Recherche par force brute : Le tiers malveillant cherche au hasard en essayant un nom de conteneur possible car ils sont souvent faciles à deviner. Par exemple, si l’attaquant cible l’organisme « CNIL », il va essayer des noms de conteneurs comme « cnil_personnel » ou « cnil_rh ».
• Recherche via des requêtes élaborées sur un moteur de recherche standard (type Google dorks) : En l’absence d’une configuration spécifique, par exemple via un fichier robots.txt, les conteneurs publics sont souvent indexables par des moteurs de recherche publics. Par exemple, un internaute peut rechercher via un moteur de recherche un fichier dans un conteneur ouvert grâce à l’une des recherches suivantes :

site:s3.amazonaws.com inurl:gouv.fr
site:blob.core.windows.net intext:CONFIDENTIAL
site:oss-eu-central-1.aliyuncs.com filetype:xlsx
site:fr-par.scw.cloud filetype:xlsx

Les opérateurs « site: », « filetype: » ou encore « intext: » permettent de restreindre la recherche sur des conteneurs de fournisseurs particuliers, contenant des termes précis ou des objets au format spécifiés dans la requête.

• Recherche via des outils de recherche de conteneurs ouverts : de nombreux utilitaires en ligne permettent de trouver des conteneurs ouverts, comme des scanners de conteneurs ou des moteurs de recherche dédiés à l’énumération de conteneurs ouverts.

La journalisation, une mesure indispensable pour détecter des accès non autorisés

Le conteneur étant disponible publiquement et après avoir pris contact avec le responsable de la sécurité des systèmes d’information (RSSI) de sa société, Julie vérifie les journaux (logs) à sa disposition. Si l’attaquant n’a pas été en mesure d’effacer ses traces, elle pourra peut-être trouver parmi les actions effectuées :

• une consultation des options de configurations du conteneur, et notamment les accès et les autorisations ;
• l’affichage d’une liste des objets contenus dans le conteneur ;
• sur la base des permissions qui ont été accordées sur ce conteneur et selon les protections mises en place (authentification, mot de passe, etc.), l’attaquant a peut-être :
  • stocké un nouvel objet, comme un programme malveillant, dans le conteneur (upload) ;
  • récupéré ou synchronisé localement un objet existant dans le conteneur (download, sync) ;
  • modifié un objet existant dans le conteneur ;
  • modifié les accès et les permissions des objets et du conteneur ;
  • chiffré les objets présents sur le conteneur, notamment en vue de demander une rançon contre leur déchiffrement ;
  • supprimé un objet existant dans le conteneur ;
  • supprimé les journaux.

Julie retrouve plusieurs de ces éléments : une consultation d’abord et une modification des droits d’accès aux conteneurs. Elle constate également un grand nombre de téléchargements ainsi que le chiffrement d’une partie des données présentes sur le conteneur.

Le délégué à la protection des données (DPO), mis au courant dès le début de ses investigations, lui confirme ses doutes : il s’agit d’une violation de données, au sens du RGPD. En plus des investigations à mener, elle va devoir travailler avec le DPO sur la notification de violations de données à envoyer à la CNIL.

Comment prévenir les erreurs de configuration et les attaques qui les exploitent ?

Pour éviter de vivre le même lundi matin que Julie, il est recommandé d’accorder une attention particulière aux points suivants :

1. Connaître son infrastructure

Savoir qui s’occupe de quoi, entre le fournisseur de cloud et ses propres services : une infrastructure cloud n’est pas un prestataire à qui on confie son infogérance.

Configurer les options de sécurité : ne pas laisser le paramétrage par défaut, en particulier les accès publics et privés aux conteneurs.

2. Faire l’inventaire de ses ressources dans le cloud

Avant de stocker des données dans le cloud, classer les données selon leur degré de sensibilité.

Séparer le stockage des données personnelles et sensibles des autres données.

Cartographier les ressources présentes dans le cloud et réexaminer leurs configurations de sécurité.

3. Limiter les accès aux conteneurs et aux objets qu’ils contiennent

Mettre les conteneurs en accès restreint par défaut et bloquer les accès publics aux conteneurs stockant des données personnelles.

N’accorder les accès qu’aux utilisateurs habilités, en supprimant les comptes génériques et en n’utilisant que des comptes individuels.

Limiter les autorisations et appliquer le principe de moindre privilège pour les accès aux conteneurs.

Mettre en place une authentification forte (à deux facteurs) pour les actions sensibles.

4. Chiffrer les données

Chiffrer les données en transit.

Chiffrer les données au repos.

Appliquer une gestion appropriée des clés cryptographiques.

5. Effectuer des sauvegardes régulières

Prévoir, mettre en place et tester une procédure de sauvegarde des conteneurs.

6. Tracer, surveiller et auditer

Activer et configurer la journalisation au niveau du conteneur et des objets.

Sécuriser les journaux.

Auditer régulièrement les conteneurs et leurs configurations de sécurité.

7. Sensibiliser les utilisateurs

Sensibiliser régulièrement en interne sur les risques des défauts de configuration.

Former les personnes amenées à manipuler les données stockées dans le cloud.