Archives de catégorie : AWS

S3

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.

frame

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).

frame

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
    • Des milliers de données électorales américaines ont été exposées publiquement par une petite société (Robocall) qui les commercialisait12.
    • Une société israélienne expose des données de 14 millions de clients13 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é14.
  • 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é astronomique15 de données récoltées auprès des utilisateurs surveillés accessibles sur S316.
  • Avril 2019
    • Intéressant : 146 Go de données d’utilisateurs Facebook laissés en accès ouvert par des éditeurs tiers17.
  • 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.

Voir aussi

Articles externes

EBS

Elastic Bloc Store, ou EBS, est un service d’espace de stockage destiné à être utilisé par les machines virtuelles d’AWS (EC2).

Chiffrement

Un des principaux (seuls) moyens de protéger les informations stockées sur des volumes de données est de les chiffrer. Mais que peut-on chiffrer sur un volume EBS ? La règle fournie par Amazon est simple :

  1. Les volumes créés à partir d’images chiffrées sont chiffrées.
  2. Les volumes créés à partir d’images non chiffrées ne le sont pas.
  3. Les volumes crées vides peuvent être chiffrés.

Conséquence : le volume EBS sur lequel vous installez un système d’exploitation issu d’une image machine (« ami ») non chiffrées ne le sera pas. Or c’est le cas de toutes les images machines fournies par AWS, ce qui s’explique car sinon, pour créer une instance EC2, il faudrait fournir la clé à chacun des clients, ce qui serait totalement contreproductif, vu que d’une part un chiffrement n’est utile que si la clé de chiffrement est secrète, et que d’autre part les clients d’AWS ne pourraient créer aucun instance sans disposer de cette clé, ce qui rend le processus très lourd.

Comment chiffrer les volumes de données

Il n’y a aucune astuce ni piège : il suffit de cocher la case « Chiffrement » puis de choisir la clé de chiffrement désirée en dessous. Cette clé peut être n’importe quelle clé à laquelle l’utilisateur a accès.

center

Comment chiffrer un volume EBS système ?

Il faut d’abord créer une ami non chiffrée à partir de la machine « modèle », puis faire une copie de l’ami ainsi produite et la chiffrer (je n’ai pas trouvé d’autre méthode).

center

Sources

  • https://d0.awsstatic.com/whitepapers/KMS-Cryptographic-Details.pdf