Les demandes d’accès aux buckets du service AWS S3 conduisent le titulaire à payer des sommes qui peuvent devenir très élevées, même lorsque ces demandes sont refusées, avec des implications importantes en cas d’utilisation inappropriée pouvant conduire à de véritables attaques. C’est la découverte de Maciej Pocwierz, un développeur polonais qui s’est retrouvé avec une facture de plus de 1 200 après avoir choisi, par pur hasard, de donner à son bucket sur S3 un nom également utilisé dans l’exemple de configuration d’un projet open source. La cause réside dans le fait que Jusqu’à présent, AWS a également facturé les accès refusés. aux ressources hébergées dans S3. Un problème qui sera peut-être résolu après l’attention suscitée par cette affaire.
Problèmes avec AWS S3 : la dénomination des compartiments peut entraîner des factures élevées
Comme il l’explique sur son blog, Pocwierz a commencé à travailler avec un bucket S3 dans la région il y a quelques semaines ue-ouest-1 d’AWS, en le laissant vide. Les buckets sont des conteneurs (littéralement « buckets ») sur le service de stockage S3 et peuvent contenir des fichiers et des objets ; ils sont souvent utilisés pour stocker de grandes quantités de données, en particulier dans les entreprises.
Deux jours après sa création, le développeur a vérifié son panier et a découvert que la facture avait atteint 1 300 dollars (un peu plus de 1 200 dollars aux taux de change actuels). La raison réside dans le fait qu’il avait choisi, non sans malheur, un nom pour le seau. également utilisé par un projet open source comme valeur par défaut qui doit être remplacée lors de l’installation. Cependant, beaucoup ont laissé ce nom inchangé, ce qui a eu pour résultat que le seau de Pocwierz a été inondé de demandes.
Bien qu’ils aient été rejetés, car les utilisateurs essayant (sans le savoir) d’accéder au bucket n’avaient pas l’autorisation de le faire, ces demandes ont été facturées à Pocwierz. C’est, comme l’a confirmé le support de l’entreprise, la norme : même les demandes rejetées sont facturées, même si l’utilisateur n’a aucun contrôle sur elles.
Le problème de cette approche, comme le signalent de nombreux développeurs et ingénieurs système sur Internet, est qu’il n’existe pas de véritable défense. Choisir un nom difficilement identifiable pour les buckets est certes une bonne pratique, mais cela ne protège pas contre le fait qu’un attaquant le découvre cela peut cependant bombarder le seau de demandes et ainsi conduire à des factures très élevées.
Pocwierz a également souligné que dans ce cas précis il y a un problème de sécurité des données: puisque le nom de son bucket est celui utilisé sur de nombreuses installations de l’outil open source, en ouvrant le bucket à l’écriture par n’importe qui il a pu récolter en quelques minutes environ 10 Go de données auprès d’utilisateurs inconscients qui avaient conservé le nom par défaut nom du compartiment. Il ne s’agit pas d’un problème dans le service AWS en tant que tel, mais d’un problème général dans la gestion des valeurs par défaut ; bien entendu, compte tenu des politiques AWS, l’option de créer un compartiment inaccessible portant le même nom que celui de la documentation devient une option non viable. Cet aspect de la sécurité reste cependant théorique, car aucune attaque de ce type n’est connue à ce jour.
Cette histoire a suscité un vif débat, qui a conduit Jeff Barrévangéliste en chef chez AWS, pour confirmer le https://twitter.com/jeffbarr/status/1785386554372042890 comment l’entreprise travaille pour modifier ce mécanisme, même si aucun calendrier précis n’a été donné pour l’intervention. Il n’est même pas clair si l’entreprise décidera de rendre indisponible le nom du bucket concerné par le problème : bien que Pocwierz ait décidé de supprimer le sien, il reste la possibilité que quelqu’un d’autre en ouvre un et puisse ainsi collecter les données envoyées par l’open source. outil .
Nous avons demandé plus de détails au bureau de presse, mais pour le moment il n’y a rien d’autre que le tweet de Barr qui nous a été indiqué : il y a seulement la promesse que nous recevrons des mises à jour à l’avenir.
 même pour les demandes d’accès refusées){kind=link}