Exploration des compartiments AWS S3 25K

Les problèmes liés aux autorisations des compartiments AWS S3 sont aussi anciens que le service lui-même. Je pense que 2 les recherches les plus connues sur ce problème ont été effectuées par Skyhigh, soulignant que 7% de tous les seaux S3 sont ouverts et Rapid7 soulignant que même 17% sont ouverts. Nous sommes en 2018 et j’ai décidé de vérifier l’état actuel du problème. De plus, je souhaite présenter mes techniques pour effectuer de telles recherches. Si je manque une technique intelligente, merci de me le faire savoir dans les commentaires.

Commençons par une théorie

Tous les compartiments AWS S3 peuvent être accessibles à l'aide des URL suivantes:

https: // [nom du compartiment] .s3.amazonaws.com /
https: // [aws_endpoint] .amazonaws.com / [nom du compartiment] /

ou en utilisant AWS CLI:

$ aws s3 ls --region [nom_région] s3: // [nom_seau]

Peu de gens soulignent la nécessité d'utiliser un paramètre de région. Cependant, certains compartiments ne fonctionnent pas sans spécifier de région. Je ne vois pas de motif quand cela fonctionne et quand ce n’est pas le cas, il est donc bon d’ajouter toujours ce paramètre :)

Donc, en règle générale, trouver un seau valide équivaut à trouver un sous-domaine de s3.amazonaws.com ou [aws_endpoint] .amazonaws.com. Ci-dessous, je vais passer en revue 4 méthodes qui peuvent être utiles dans cette tâche.

Bruteforcing

Chaque nom de compartiment doit être unique et ne peut contenir que 3 à 63 caractères alphanumériques, à quelques exceptions près (peut contenir «- -» ou «.», Mais ne peut pas être démarré ou terminé). Cela dit, nous disposons de suffisamment de connaissances pour trouver tous les seaux S3, mais soyons honnêtes: cela fonctionnerait plutôt pour les noms abrégés. Néanmoins, les utilisateurs ont tendance à utiliser certains modèles pour nommer, par exemple: [nom_entreprise] -dev ou [nom_entreprise] .backups. Une fois que vous recherchez le compartiment d’une société particulière, vous pouvez facilement automatiser un processus de vérification de modèles aussi connus à l’aide d’outils tels que LazyS3 ou aws-s3-bruteforce. Disons que nous avons une société appelée Rzepsky. Une commande simple: $ ruby ​​lazys3.rb rzepsky révèle un seau rzepsky-dev:

Mais que se passe-t-il si vous souhaitez récolter autant de seaux que possible sans nom spécifique? Continuez à lire ce post;)

Machine de retour

Avez-vous déjà entendu parler de la Wayback Machine? Citant Wikipedia:

La Wayback Machine est une archive numérique du World Wide Web et d’autres informations sur Internet créées par Internet Archive.

Certaines ressources de cette archive numérique sont stockées sur l'infrastructure Amazon. Cela dit, si la Wayback Machine a indexé une seule photo sur un compartiment S3, nous pouvons récupérer ces informations et vérifier si ce dernier contient des ressources publiques. Même lorsque la photo indexée est déjà supprimée (ou que l'accès y est refusé), vous avez toujours le nom du compartiment, ce qui donne l'espoir de trouver des fichiers intéressants à l'intérieur. Pour demander à l’API de la machine Wayback, vous pouvez utiliser un module Metasploit appelé enum_wayback:

Comme vous vous en souviendrez peut-être depuis le début de cet article, vous pouvez vous référer au contenu du compartiment en utilisant également une URL avec la spécification de région. Ainsi, pour obtenir des résultats encore meilleurs, nous pouvons vérifier les sous-domaines de tous les points de terminaison Amazon S3 possibles, à l'aide d'un simple bas-ligne:

$ pendant la lecture de la région; do msfconsole -x "use \ auxiliaire / scanner / http / enum_wayback; set DOMAIN $ region; \
set OUTFILE $ region.txt; courir; exit "; done 

Très souvent, Wayback Machine vous permet de récupérer quelques milliers d'images placées dans un seul seau. Vous devez donc effectuer certaines opérations pour extraire uniquement les noms de compartiment valides et uniques. Des programmes comme Cut et Awk sont d'excellents amis ici.

La Wayback Machine m'a donné 23498 seaux potentiels sous la forme de fichiers txt de 398,7 Mo. 4863 de ces seaux étaient ouverts au public.

Interroger des tiers

Une autre technique que je voudrais vous présenter consiste à interroger des tiers, tels que Google, Bing, VirusTotal, etc. Il existe de nombreux outils permettant d'automatiser le processus de collecte d'informations intéressantes à partir de services externes. L'un d'eux est le Sublist3r:

De nouveau, nous devrions rechercher les sous-domaines de chaque région et extraire ensuite uniquement les noms de compartiment uniques. Un rapide bash one-liner:

$ pendant la lecture de la région; faire python3 sublist3r.py -d $ region \
> $ region.txt; done 

donne comme résultat 756 dont… un seul seau était à collectionner. Bière pour les administrateurs!

Recherche dans les journaux de transparence des certificats

La dernière technique que je voudrais vous présenter consiste à rechercher des noms de compartiment en consultant les journaux de transparence des certificats. Si vous ne connaissez pas bien la transparence des certificats, je vous recommande de regarder cette présentation. Fondamentalement, chaque certificat TLS émis est consigné et tous ces journaux sont accessibles au public. Le but principal de cette idée est de vérifier si un certificat n’est pas utilisé par erreur ou par malveillance. Cependant, l'idée de journaux publics révèle tous les domaines, y compris… ouais, les compartiments S3 également. La bonne nouvelle est qu’il existe déjà un outil qui effectue une recherche pour vous - le seau d’activités. Mieux encore, cet outil vérifie également les autorisations sur le compartiment trouvé. Alors, essayons:

$ python3 bucket-stream.py --threads 100 --log

Après avoir vérifié les possibilités de 571134, le scanneur à godets m'a rendu 398 seaux valides. 377 d'entre eux étaient ouverts.

Vérification du contenu du compartiment

Bon, nous avons trouvé des milliers de noms de seau et quelle suite? Eh bien, vous pouvez par exemple vérifier si l'un de ces compartiments autorise un accès public ou tout autre utilisateur AWS authentifié (ce qui est fondamentalement identique à public). Pour cela, vous pouvez utiliser mon script BucketScanner - il répertorie simplement tous les fichiers accessibles et vérifie également les autorisations WRITE vers un compartiment. Cependant, aux fins de cette recherche, j'ai modifié une méthode bucket_reader de la manière suivante:

def bucket_reader (bucket_name):
    region = get_region (bucket_name)
    si région == 'Aucun':
        passer
    autre:
        bucket = get_bucket (bucket_name)
        résultats = ""
        essayer:
            pour s3_object dans bucket.objects.all ():
                si s3_object.key:
                    print "{0} est collectable" .format (bucket_name)
                    results = "{0} \ n" .format (bucket_name)
                    append_output (résultats)
                    Pause

Même si ce n’est pas la façon la plus élégante de faire son travail - si un seul fichier était récupérable dans le compartiment, mon scanner modifié indique que ce dernier est collectable.

Les risques

Parmi les fichiers accessibles au public, vous pouvez trouver des fichiers vraiment intéressants. Mais la fuite de données sensibles n'est pas le seul risque.

Certains seaux sont accessibles au public. Bien sûr, un attaquant peut utiliser ce compartiment en tant que point de distribution de logiciels malveillants. C’est encore plus effrayant si vous utilisez un tel compartiment pour distribuer un logiciel légitime à vos employés - imaginez un tel scénario: vous demandez à tous les nouveaux arrivants d’installer un logiciel à partir du compartiment de la société et ce logiciel est déjà écrasé par un attaquant avec installateur infecté. L’autre variante de ce scénario serait de suivre les chercheurs S3 - par exemple. en téléchargeant un fichier infecté avec un nom tentant, tel que «Rapport de salaire - 2017.pdf» (bien sûr, tous les chercheurs responsables téléchargent toujours des fichiers non fiables dans un environnement en bac à sable, n'est-ce pas?)

Un autre risque associé aux compartiments accessibles au public en écriture est… de perdre toutes vos données. Même si vous ne disposez pas des autorisations DELETE sur les objets du compartiment, mais seulement d’une autorisation WRITE, vous pouvez toujours écraser n’importe quel fichier. Cela étant dit, si vous écrasez un fichier avec un fichier vide, cela signifie que ce fichier n'est plus disponible pour personne. Jetons un coup d’œil à cet exemple:

Le seul mécanisme qui peut enregistrer vos données dans un tel scénario est l'activation d'un contrôle de version. Cependant, ce mécanisme peut être coûteux (il double la taille de l'espace utilisé dans votre compartiment) et peu de personnes décident de l'utiliser.

J'ai aussi entendu un argument:

Oh, c’est juste un seau à des fins de test.

Eh bien, si votre panier «de test» devient un espace de stockage pour le contenu illégal, alors… désolé mec, mais votre carte de crédit est liée à ce compte.

Un avenir meilleur?

Le problème avec les autorisations des compartiments S3 existe toujours et je ne prévois pas de changement spectaculaire dans un avenir proche. Les personnes à mon humble avis donnent au public l’accès, parce que cela fonctionne toujours - vous n’aurez plus à vous soucier de spécifier des autorisations lorsqu'un service S3 coopère avec d’autres services. L'autre raison peut être une simple erreur dans la configuration des autorisations (par exemple, l'insertion d'un caractère «*» au mauvais endroit dans une stratégie de compartiment) ou la non-compréhension des groupes prédéfinis (par exemple, un groupe «Tout compte AWS authentifié» peut toujours être configuré via AWS. CLI).

Un autre problème est de savoir comment signaler de tels problèmes? Il n’ya pas d’e-mails bloqués dans le panier, vous ne pouvez donc jamais savoir avec qui vous devez contacter. Les noms des compartiments peuvent indiquer qu'ils appartiennent à la société X, mais souvenez-vous que n'importe qui peut le nommer de manière approximative. Alors méfiez-vous des trollers!

Sommaire

Pour 24652 compartiments analysés, j'ai pu collecter des fichiers dans 5241 compartiments (21%) et télécharger des fichiers arbitraires dans 1365 compartiments (6%). Sur la base des résultats, je peux affirmer sans l'ombre d'un doute que le problème existe toujours. Certains seaux sont intentionnellement ouverts (par exemple, des images, des brochures d’entreprise, etc.), mais aucun d’entre eux ne devrait être accessible en écriture. Je suis presque sûr qu'il existe d'autres méthodes intéressantes pour trouver encore plus de compartiments. La seule contre-mesure raisonnable semble donc être de… définir de bonnes autorisations pour votre compartiment.

Veuillez également trouver mon Guide en sept étapes pour protéger votre royaume AWS.