Quand sauvegarde rime avec mégarde

 Le 22 novembre, Mitiga, entreprise spécialisée en cybersécurité, a publié les résultats d’un POC (proof of concept) montrant que :

• Des backups de base de données étaient fréquemment partagés publiquement sur AWS
• Il était très simple de les récupérer pour en extraire des données sensibles

On vous explique tout !

📚️ Explication des termes

En 2009, AWS lance son service de base de données dans le cloud : Amazon Relational Database Service (Amazon RDS). Ce service permet de facilement créer une base de données sans se soucier des problèmes d’infrastructure. Ce service est monté en popularité et est intégré dans une grande majorité des architectures hébergées sur AWS.

Sur une instance de RDS, il est possible de faire ce qui s’appelle des Snapshots : il s’agit d’une copie figée du contenu de la base de données à un instant précis, ce qui est très pratique pour faire un backup par exemple. Le tout reste stocké dans AWS.

Par défaut, le Snapshot est uniquement accessible au compte AWS qui l’a créé (compte personnel ou compte de l’entreprise). Cependant, il est possible de le partager à d’autres comptes. Sur ces derniers, la base de données pourra être restaurée à partir du Snapshot. Cela peut être utile pour partager un template de base de données par exemple. Pour cela, il y a 2 options :

• Le partager à une liste de comptes AWS précise
• Le partager publiquement, sans aucune restriction d’accès

Le problème : Beaucoup d’utilisateurs d’AWS ignorent que n’importe qui peut accéder à la liste des Snapshots publics et peuvent ainsi faire fuiter des données sensibles lors d’un partage.

💡 Explication et résultats du POC

Pour démontrer la facilité de récupération des données personnelles, l’équipe de Mitiga a développé un petit POC, qui serait très proche de ce qu’une équipe de hacker pourrait faire pour extraire des données personnelles. Il y a 6 grandes étapes dans leur processus automatique :

1. Scanner toutes les heures les Snapshot RDS publics, donc accessibles par tout le monde : c’est très simple et bien expliqué 👉 ici 👈 dans la documentation officielle de AWS. Mitiga aurait pu le faire encore plus fréquemment, pour être sûr de détecter un Snapshot qui aurait été créé juste pendant quelques minutes.
2. Cloner les Snapshots sur son propre compte AWS : une fois fait, la copie persiste, même si l’auteur supprime l’original
3. Lister les Snapshot qui pourraient être intéressants selon leurs métadonnées (suppression de Snapshot de test, de redondance)
4. Restaurer les Snapshots pour pouvoir en extraire la donnée
5. Extraire des données : le nom des tables et des colonnes (pour savoir ce que la base pourrait contenir) et les 10.000 premières lignes pour avoir des échantillons
6. Supprimer la base de données une fois l’extraction terminée, car maintenir une base de données en vie, ça coûte cher 💸

L’équipe de Mitiga a laissé tourner son algorithme pendant un mois, pour avoir des données représentatives. Et sans étonnement, ils ont été en capacité de récupérer 2.783 Snapshots, dont 650 susceptibles de contenir des informations personnelles ! 😱

Ils ont pu extraire plusieurs types de données personnelles :

• Permettant d’identifier l’utilisateur : prénom, nom, situation (mariage, célibataire), téléphone, date de naissance, sexe. Elles permettent à un hacker mal intentionné de facilement faire une campagne de phishing / spam.
• Propre à l’application (données de localisation, messages privés d’une application de rencontre, etc.) Le hacker peut utiliser ces informations précises pour se faire passer pour l’application et améliorer sa campagne de phising.

Lors du partage public d’un Snapshot, on ne peut pas connaître directement l’auteur qui l’a partagé (la personne et/ou son entreprise). Cependant, dans de nombreux cas, le nom donné au Snapshot contient directement le nom de l’entreprise ou le nom de l’auteur (donc on rajoute une recherche LinkedIn 🌐 et puis c’est bon). Dans ce cas, le hacker peut en plus faire du chantage à l’entreprise (blackmail) pour récupérer ainsi une coquette somme d’argent…

🛡 Comment s'en protéger ?

• Ne pas partager de Snapshot RDS publiquement qui contiennent des données réelles 🙃 Un partage public même de quelques secondes suffit à compromettre le contenu. Pour partager un Snapshot, le mieux est d’inclure spécifiquement l’ID du compte AWS ciblé, et même de le chiffrer (action non-réalisable pour un partage public).
• Pour éteindre l’incendie, vérifier puis supprimer le partage public s’il existe sur des Snapshots RDS à soi. 👉 Cet article 👈 nous explique comment faire.
• Utiliser un outil pour détecter des partages publics, comme Amazon Trust Advisor, l’ajout de règles sur AWS Config ou YATAS, développé par nos amis Padok. De plus, Amazon envoie de base un email pour prévenir dès qu’un Snapshot est partagé publiquement (mais ils peuvent facilement être masqués par cette magnifique newsletter).
  Cependant ces solutions n’empêchent pas à un employé de partager un Snapshot, et comme vu plus haut, même un partage de quelques minutes suffit à compromettre le contenu.
• Forcer des règles sur les comptes AWS de l’entreprise grâce aux SCPs (Service Control Policies) : en restreignant les commandes qui permettent de modifier les attributs d’un Snapshot, on peut empêcher au niveau d’une organisation de le partager publiquement, et pas même pour une fraction de seconde !

🏹 Le mot de la fin

• L’article original de l’équipe de recherche en sécurité de Mitiga
• La documentation officielle du partage public de Snapshot RDS

Nous avons pour ambition de sécuriser le web, et pour atteindre cet objectif, nous avons besoin de vous ! Si vous avez des questions, des suggestions ou le moindre doute, n'hésitez pas à contacter notre équipe sécurité security@theodo.fr.