Stack Labs Blog moves to Dev.to | Le Blog Stack Labs déménage sur Dev.to 🚀
AWS - Erreurs de configuration courantes - Partie 1
Temps de lecture estimé : 6 minutes
Il est fréquent de voir dans l’actualité un leak causé par un bucket mal configuré… Dans cette série d’articles nous allons aborder les erreurs de configurations les plus communes et comment les détecter.
Souvenez-vous, vous êtes à un bucket mal configuré de faire la prochaine une des journaux 😉
Cette série d’articles s’appuiera sur l’excellent site flaws.cloud développé par Scott Piper. Ce site est présenté sous la forme d’une suite d’exercices dans lesquels il faut trouver le lien vers le prochain niveau. Chaque exercice présente une erreur de configuration connue et nous invite à trouver un moyen de l’exploiter. L’exercice suivant explique l’erreur et comment l’éviter ; un article tiré des actualités démontre aussi les impacts qu’une telle mauvaise configuration peut avoir.
Dans ce premier chapitre nous traiterons des Bucket S3. Nous verrons comment il est possible de détecter si un site statique est hebergé sur un bucket et comment avoir accès à son contenu s’il est public.
Dans ce cadre j’aimerais aussi vous présenter l’outil buckets de Gray Hat Warfare. Il s’agit d’un site web qui crawl et répertorie tous les buckets exposés en public. L’interface permet ensuite de chercher des fichiers ou des buckets. Il suffit de chercher des mots clés tels que “wp_config”, “creds” ou encore “id_rsa” pour comprendre l’ampleur du problème.
A présent, commençons l’exercice de flaws.cloud. Le premier exercice nous propose d’apprendre comment vérifier si un site est hébergé sur bucket S3.
Voici ma résolution
stack-labs@debian:$ dig +noall +answer flaws.cloud A
flaws.cloud. 5 IN A 52.218.208.99
Dig est un utilitaire présent dans le paquet dnsutils et permet de faire des requêtes DNS.
L’option +noall permet de désactiver tous les flags et +answer réactive juste l’affichage de la réponse.
Le A précise que nous voulons l’enregistrement DNS de type adresse (pour plus d’infos sur les records: wiki).
stack-labs@debian:$ nslookup 52.218.208.99
Server: 192.168.1.254
Address: 192.168.1.254#53
Non-authoritative answer:
99.208.218.52.in-addr.arpa name = s3-website-us-west-2.amazonaws.com.
Authoritative answers can be found from:
Une fois l’adresse IPv4 récupérée, nous pouvons faire une requête pour retrouver le nom de domaine associé. La requête ne retourne pas la réponse exacte mais elle permet d’identifier que c’est bien un bucket S3 et qu’il est hébergé dans la région us-west-2.
stack-labs@debian:$ aws s3 ls s3://flaws.cloud --no-sign --region us-west-2
2017-03-14 04:00:38 2575 hint1.html
2017-03-03 05:05:17 1707 hint2.html
2017-03-03 05:05:11 1101 hint3.html
2018-07-10 18:47:16 3082 index.html
2018-07-10 18:47:16 15979 logo.png
2017-02-27 02:59:28 46 robots.txt
2017-02-27 02:59:30 1051 secret-dd02c7c.html
Avec les éléments précédents nous pouvons vérifier si le bucket est accessible en lecture, sans authentification (no-sign).
Le contenu du fichier secret-dd02c7c.html a l’air intéressant.
Avec la commande aws s3 cp suivi de -, il est possible d’en afficher directement le contenu:
stack-labs@debian:$ aws s3 cp s3://flaws.cloud/secret-dd02c7c.html - --no-sign --region us-we
st-2
<html>
<head>
<title>flAWS</title>
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
<style>
body { font-family: Andale Mono, monospace; }
:not(center) > pre { background-color: #202020; padding: 4px; border-radius: 5px; border-color:#00d000;
border-width: 1px; border-style: solid;}
</style>
</head>
<body
text="#00d000"
bgcolor="#000000"
style="max-width:800px; margin-left:auto ;margin-right:auto"
vlink="#00ff00" link="#00ff00">
<center>
<pre >
_____ _ ____ __ __ _____
| || | / || |__| |/ ___/
| __|| | | o || | | ( \_
| |_ | |___ | || | | |\__ |
| _] | || _ || ` ' |/ \ |
| | | || | | \ / \ |
|__| |_____||__|__| \_/\_/ \___|
</pre>
<h1>Congrats! You found the secret file!</h1>
</center>
Level 2 is at <a href="http://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud">http://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud</a>
Le niveau 2 est identique au niveau 1 à une nuance près donc je vais aussi le couvrir dans cet article. Pour commencer, il faut accéder à la page suivante avec le lien trouvé précédemment (appelé flag): http://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud
Comme spécifié sur le site, il faudra un compte AWS pour compléter le niveau. Un compte gratuit (Free Tier) est suffisant. Si vous créez votre compte pour la première fois, il est bon de savoir qu’Amazon vous demandera un numéro de carte bleue et je vous recommande de prendre connaissance de la tarification et de mettre en place les alertes nécessaires afin d’éviter tous frais.
Voici la solution pour le second niveau
Après une rapide vérification avec la technique utilisée précédement on constate que le site est hébergé sur un bucket S3 lui aussi :
stack-labs@debian:$ dig +noall +answer level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud A
level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud. 5 IN A 52.218.201.3
stack-labs@debian:$ nslookup 52.218.201.3
Server: 62.201.129.99
Address: 62.201.129.99#53
Non-authoritative answer:
3.201.218.52.in-addr.arpa name = s3-website-us-west-2.amazonaws.com.
Authoritative answers can be found from:
Cependant, si on essaie de lister son contenu on obtient une erreur:
stack-labs@debian:$ aws s3 ls s3://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/ --no-sign
An error occurred (AccessDenied) when calling the ListObjects operation: Access Denied
L’accès en lecture pour tous les comptes (y compris les anonymes) a été désactivé. Cependant, il existe sur AWS, un groupe qui correspond aux utilisateurs AWS authentifiés. Cela signifie que toute personne possédant un compte AWS sera en mesure d’avoir accès, dans notre cas, au bucket.
Pour le tester il faut enregistrer son compte dans l’outil aws-cli. AWS fourni un bon guide qui explique comment configurer l’outil AWS pour y insérer notre profil et comment créer le compte de service dans un premier temps.
stack-labs@debian:$ aws configure --profile stack-labs
AWS Access Key ID [None]: AAAAAAAAAAAAAAAAAAAA
AWS Secret Access Key [None]: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Default region name [None]: us-west-2
Default output format [None]:
Après avoir configuré notre compte nous pouvons rééssayer de lister le bucket mais cette fois-ci en signant notre requête.
stack-labs@debian:$ aws --profile stack-labs s3 ls s3://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud
2017-02-27 03:02:15 80751 everyone.png
2017-03-03 04:47:17 1433 hint1.html
2017-02-27 03:04:39 1035 hint2.html
2017-02-27 03:02:14 2786 index.html
2017-02-27 03:02:14 26 robots.txt
2017-02-27 03:02:15 1051 secret-e4443fc.html
Le bucket était effectivement configuré en autorisant tous les utilisateurs authentifiés.
Le contenu du fichier secret-e4443fc.html contient le lien vers le niveau suivant:
stack-labs@debian:$ aws --profile stack-labs s3 cp s3://level2-c8b217a33fcf1f839f6f1f73a00a9ae7.flaws.cloud/secret-e4443fc.html -
<html>
<head>
<title>flAWS</title>
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
<style>
body { font-family: Andale Mono, monospace; }
:not(center) > pre { background-color: #202020; padding: 4px; border-radius: 5px; border-color:#00d000;
border-width: 1px; border-style: solid;}
</style>
</head>
<body
text="#00d000"
bgcolor="#000000"
style="max-width:800px; margin-left:auto ;margin-right:auto"
vlink="#00ff00" link="#00ff00">
<center>
<pre >
_____ _ ____ __ __ _____
| || | / || |__| |/ ___/
| __|| | | o || | | ( \_
| |_ | |___ | || | | |\__ |
| _] | || _ || ` ' |/ \ |
| | | || | | \ / \ |
|__| |_____||__|__| \_/\_/ \___|
</pre>
<h1>Congrats! You found the secret file!</h1>
</center>
Level 3 is at <a href="http://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud">http://level3-9afd3927f195e10225021a578e6f78df.flaws.cloud</a>
Et voilà notre lien vers le prochain niveau !
Ces deux exercices montrent des exemples de mauvaises configurations d’accès d’un bucket S3.
Comme à chaque fois, cela ne s’applique pas uniquement aux buckets, il faut attribuer le niveau d’accès minimum nécessaire aux personnes ou ressources.
Rassurez-vous, par défaut AWS crée un bucket privé et vous devez explicitement spécifier que vous voulez le rendre public.
Pour auditer les autorisations de vos buckets, il faut se rendre dans la console, dans la partie stockage S3 (faites attention à la région). On peut ainsi voir quel type d’accès est configuré sur ses buckets.
Le prochain article aura aussi comme sujet le bucket S3 mais il abordera les problèmes des secrets committés par erreur dans un repository.
Restez informés en vous abonnant au flux RSS du blog.
P.S.: Nous avons caché un easter egg sur le blog, saurez-vous le trouver ? 🥚