secu.si - S3

Contenu

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 S3¹ dans son service Trusted Advisor (ce contrôle était jusqu’alors réservé aux clients ayant un niveau de support payant). Début 2018², 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és³.
- Keeper, un gestionnaire de mots de passe, laisse traîner des fichiers en lecture-écriture⁴.
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 douteux⁵.
Mai 2018
- Divulgation de données de 15 ou 20 000 joueurs de cricket indiens⁶⁷.
- Divulgation de données du service social de Los Angeles⁸.
- Mots de passe de l’application TeenSafe en clair⁹.
- Une société d’assurance (AgentRun) laisse des milliers de données de souscripteurs¹⁰ en accès libre
- Honda laisse à disposition les informations de 50 000 véhicules et de leur propriétaires¹¹.
Juillet 2018
- Des milliers de données électorales américaines ont été exposées publiquement par une petite société (Robocall) qui les commercialisait¹².
- Une société israélienne expose des données de 14 millions de clients¹³ de l’opérateur téléphonique Verizon.
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é¹⁴.
Septembre 2018
- Une société disons de surveillance (= qui produit un logiciel d’espionnage, surfant sur la vague de peur pour alimenter celle de l’insécurité) a laissé une quantité astronomique¹⁵ de données récoltées auprès des utilisateurs surveillés accessibles sur S3¹⁶.
Avril 2019
- Intéressant : 146 Go de données d’utilisateurs Facebook laissés en accès ouvert par des éditeurs tiers¹⁷.
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 documents¹⁸ 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 administration¹⁹, 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…

Why You Shouldn’t Use AWS S3 or CloudFront to Deliver Static Assets

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 Magecart²⁰. 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.