Passer

Part 1 : Privacy dans le Cloud Public ? Tirer les leçons du BuckHacker gate

(PART 1/1) Fin 2017 et début 2018 ont été particulièrement marqués par la divulgation de données sensibles stockées sur le Cloud public. Ces fuites, plus ou moins graves, ont touché indistinctement des sociétés diverses et variées (i.e. Accenture) et des institutions étatiques (i.e. NSA, US army, etc.) et posent la question des bonnes pratiques de sécurité sur le Cloud et de la compréhension du modèle de responsabilité partagée proposé par les acteurs du Cloud public.


Comprendre le BuckHacker gate

AWS, Azure, Google … Les grands acteurs du Cloud public proposent tous un modèle de responsabilité partagée, où le fournisseur de services Cloud est responsable de la sécurité du Cloud et le client responsable de la sécurité dans le Cloud. C’est-à-dire que les providers assurent la protection de l’infrastructure (matériels, logiciels, réseaux et installations) et qu’il revient au client d’effectuer toutes les configurations de sécurité et tâches de gestion nécessaires. En d’autres termes, si les acteurs du Cloud public fournissent des serrures multipoints, il est de la responsabilité de l’utilisateur de verrouiller sa porte, et de ne pas distribuer de doubles de ses clés !

Dans le cas de BuckHacker, ce sont de multiples services de stockages non-sécurisés qui ont été visés : Amazon S3, Digitalocean spaces, Azure Blob storage, Google storageMais qu’est ce qu’un bucket S3 ? S3 est un service de stockage objets mis à disposition par AWS, la filiale IT Cloud du groupe Amazon. AWS S3 est utilisé dans de nombreux cas, pour la synchronisation de fichiers et de partage ou la sauvegarde. Les buckets S3 sont des compartiments dans lesquels peuvent être chargés un nombre illimité d’objets. Par défaut, ces buckets S3 sont privés. Mais alors, que s’est-il passé ? Des grandes entreprises comme Accenture ou la NSA ont tout simplement failli à appliquer les protocoles les plus basiques de sécurité.

Une mauvaise configuration qui peut mettre votre entreprise à risque

Il arrive souvent aux opérationnels IT d’utiliser des permissions trop larges lorsqu’ils ont besoin de transmettre des fichiers entre applications. Pour donner un rapide exemple, un développeur qui souhaite partager un sous-dossier ou l’ensemble d’un bucket entre plusieurs applications, décide de rendre ce dossier public. De cette manière, l’ensemble des applications peut accéder rapidement au contenu du dossier via une simple URL. Ceci représente une très mauvaise pratique d’un point de vue sécurité, mais pour des contraintes de délai de production cela peut représenter un rapide contournement pour le développeur qui pense revenir dessus une fois ses objectifs atteints. Sauf que la plupart du temps ces buckets ou sous-dossiers ne sont jamais reconfigurés et restent ainsi ouverts sur l’Internet.

Notons, toutefois, qu’il est bien moins aisé de détecter ces buckets ouverts sur Internet que pour une base de données classique où un attaquant est en mesure de scanner très rapidement un range de ports et d’adresses IP via des scripts automatisés. S3 est en effet un service complexe qui ne repose pas sur une seule machine physique mais un conteneur virtualisé sur plusieurs machines redondées sur plusieurs DataCenters, ces machines pouvant elles-mêmes héberger de nombreux buckets différents.

Pour simplifier, le service S3 repose sur un range d’adresses IP et le seul moyen de joindre un bucket en particulier est via son URL. Des outils de scan adaptés ont toutefois été conçus dès les débuts d’AWS pour effectuer des requêtes sur des domaines via une liste de mots spécifiques. Par ailleurs, même avec ces outils, l’attaquant sera toujours limité par sa capacité à trouver rapidement de nouveaux noms de buckets.

Retrouvez toutes nos recommandations sur l’article Part 2 : Privacy dans le Cloud Public ? Tirer les leçons du BuckHacker gate