S3 (Amazon Simple Storage Service) est un service de stockage d’objets en ligne d’Amazon Web Services (AWS). Bien que très pratique, il peut être très mal utilisé. Résultat : on assiste en ce moment à un florilège de divulgation de données via des S3 fonctionnant très bien mais mal paramétrés.
Il existe des variantes avec d’autres produits mal configurés, comme le service ElasticSearch, qui peut se révéler tout aussi fatal aux informaticiens peu consciencieux (ou débordés), ou la base MongoDB mal sécurisée par défaut.
Responsabilité partagée
La presse se fait souvent l’écho de fuite d’informations liées à S3, allant parfois jusqu’à annoncer une faille sur S3. Or il s’agit d’un service d’infrastructure (IaaS), dont la sécurité est partagée entre le fournisseur d’accès et le client utilisateur du service : le fournisseur est responsable de la sécurité du cloud, le client est responsable de la sécurité dans le cloud.
Le fournisseur est responsable du bon fonctionnement du service, rien de moins mais rien de plus : il doit juste répondre au contrat de service. Par exemple, s’il y a un mécanisme d’autorisation d’accès, il doit s’assurer qu’il est efficace et qu’il fonctionne comme attendu, sans erreur, sans interruption, etc.
De l’autre côté, le client paramètre ce mécanisme d’autorisation d’accès comme il le souhaite. S’il laisse son compartiment S3 ouvert à tout vent (par erreur, par mégarde, par bêtise), c’est de sa faute.
Les failles S3, à qui la faute ?
Et bien jusqu’à présent, toutes les failles sur S3 sont dues à un mauvais paramétrage par le client. Pourtant AWS indique en grand le risque encouru, lors du paramétrage.
Tant et si bien qu’à partir de février 2018, AWS ajoute gratuitement le contrôle sur les droits d’accès sur S31 dans son service Trusted Advisor (ce contrôle était jusqu’alors réservé aux clients ayant un niveau de support payant). Début 20182, on estimait que 7% des buckets S3 étaient accessibles en lecture sans restriction (ce qui est parfois voulu, pour l’hébergement d’éléments web statiques), et que 2% étaient également accessible en écriture sans contrôle (là je suis moins sûr que ça soit normal).
Aujourd’hui ?
Il faut vraiment être neuneu pour laisser un bucket ouvert : AWS a rajouté plein d’outils, de procédures, d’informations affichées pour qu’on ne se prenne plus les pieds dans le tapis.
Quelques exemples
- Mars 2018
- 1,3 millions de données client de Walmart (bijouterie) exposés3.
- Keeper, un gestionnaire de mots de passe, laisse traîner des fichiers en lecture-écriture4.
- Avril 2018
- 1,2 To de données correspondant à 48 millions de personnes, non protégées par LocalBox, une société de profilage publicitaire au profil douteux5.
- Mai 2018
- Divulgation de données de 15 ou 20 000 joueurs de cricket indiens67.
- Divulgation de données du service social de Los Angeles8.
- Mots de passe de l’application TeenSafe en clair9.
- Une société d’assurance (AgentRun) laisse des milliers de données de souscripteurs10 en accès libre
- Honda laisse à disposition les informations de 50 000 véhicules et de leur propriétaires11.
- Juillet 2018
- Août 2018
- GoDaddy, un célèbre hébergeur web, laisse des informations d’infrastructures de 24 000 machines sur un bucket S3 mal configuré14.
- Septembre 2018
- Avril 2019
- Juin 2019
- 1 Tb de données de sauvegardes (comprenant des clés privées) exposées par Attunity (qui a des clients de l’envergure de Netflix ou Ford).
La faute d’Amazon ?
Il n’y a pas qu’Amazon qui soit touché puisque la plupart des fournisseurs de services nuagiques proposent des services permettant le partage de façon publique ; on a vu que Google via Groups recelait de très nombreux documents18 qui n’ont pas à être exposés au grand public. Or les personnes ayant le rôle d’administrateur Google Groups n’ont pas toujours de hauts compétences en administration19, ce qui est normal vu le public visé par le service de Google.
Répétons : le problème ne vient pas du fournisseur de services, ni du service, mais de son utilisation.
Faut-il utiliser S3 ?
A mon humble avis, il faut l’éviter autant que faire se peut. Certes les usages potentiels sont nombreux, certains sont justifiés, d’autres non.
Hébergement de site web statique
AWS met en avant cet usage qui est parfaitement stupide. En effet, avec AWS, comme rien n’est gratuit, on paye à la bande passante utilisée mais aussi en fonction du nombre d’accès. Et ça va très vite…
Le seul usage raisonnable que je vois est de stocker des objets de livraison, qui doivent être accessibles facilement et dont on ne se sert qu’épisodiquement (pour construire une machine virtuelle, déployer une application, etc.).
Alors pourquoi AWS met en avant des usages du type site web statique ou fichiers statiques ? Simple : vous imaginez AWS vous dire d’économiser votre budget et de ne rien dépenser sur leurs infrastructures ?
Innovons dans les attaques
Parfois, il est normal et voulu que des fichiers soient stockés sur un bucket public : on peut même faire un site web statique rien qu’avec S3. Dans ce cas, les fichiers sont disponibles publiquement et c’est le comportement désiré.
Alors les attaquants se sont tournés vers ces fichiers publics pour les compromettre et tenter d’injecter du code ou n’importe quelle cochonnerie, par exemple sur Magecart20. Dans ce cas là, il s’agit d’un problème de gestion des droits, mais de façon plus fine, dans le contrôle d’accès de S3.
