└── README.md /README.md: -------------------------------------------------------------------------------- 1 | [![Follow on Twitter](https://img.shields.io/twitter/follow/opendevsecops.svg?logo=twitter)](https://twitter.com/opendevsecops) 2 | [![Codacy Badge](https://api.codacy.com/project/badge/Grade/8d095fd957fe404da20ab90ef0db8770)](https://www.codacy.com/app/OpenDevSecOps/guide-aws-hacking?utm_source=github.com&utm_medium=referral&utm_content=opendevsecops/guide-aws-hacking&utm_campaign=Badge_Grade) 3 | 4 | # AWS Hacking 5 | 6 | This guide provides some basic instructions how to compromise AWS. The hope is that by knowing how to take advantage of various types of AWS weaknesses you will be verse enough to provide the correct countermeasures. 7 | 8 | > **WARNING**: There will be spelling errors and incorret grammer all over the place because we are not checking for such things at this point in time. It will get better. At this stage we are looking to build the content. 9 | 10 | ## Introduction 11 | 12 | When you hear about AWS security vulnerabilities we often think of misconfigured S3 buckets. No wonder. For some uknown reason s3 buckets happen to be particularly tricky to get right in the majority of organisations and every bucket ever created is a one click away from complete security disaster. 13 | 14 | Although s3 buckets are the pinnacle of AWS security, there is so much more one can do. And as it happens, attackers do! 15 | 16 | The purpose of this project is to provide some guidelines of the various tips, tricks and techniques that take to compromise an AWS account. 17 | 18 | ## Fingerprinting 19 | 20 | The more you know about the target organisation the better you can do when you try to find security vulnerabilities. This principle broadly applies to anything and AWS is no exception. Generally, we try to find AWS account ids, ARNs, IP addresses, Role Names and other related AWS information. 21 | 22 | Basically the better job you do at anumerating the target the higher the chance of finding something that is useful. There is no single tool that will do this for you. You need to use what you know and be creative. 23 | 24 | ### AWS Login URLs 25 | 26 | AWS provides a number of user-friendly URLs for login into AWS Console or as AWS SSO User. 27 | 28 | | Description | | 29 | |------------------------------------|-----------------------------------------------------| 30 | | IAM User Sign In Link (name) | https://**name**.signin.aws.amazon.com/console | 31 | | IAM User Sign In Link (account id) | https://**accountid**.signin.aws.amazon.com/console | 32 | | AWS SSO Start Page | https://**name**.awsapps.com/start | 33 | 34 | We would like to find out the target name is associated with either IAM Sign In Page or SSO Start Page. This could help us to perform bruteforce attacks if there is nothing else to try. 35 | 36 | > **NB**: You can use [Pown Recon](https://pownjs.com) to perform this type of enumeration. `pown recon t awsie `. 37 | 38 | ### Public Code Repositories 39 | 40 | Public code repositories belonging to the target organisation could contain artifacts related to AWS accounts such as ARNs (Amazon Resource Names). [Gitleaks](https://github.com/zricethezav/gitleaks) is a tool which comes extremely useful in such situations. In fact, OpenDevSecops official [Gitleaks Docker Build](https://github.com/opendevsecops/docker-gitleaks) contains prebuilt configuration files that can be used to enumerate AWS resources. Here is an example: 41 | 42 | ```sh 43 | docker run opendevsecops/gitleaks --config=/run/configs/aws-enum.toml --github-org=target --exclude-forks -v 44 | ``` 45 | 46 | > **NOTE**: Gitleaks is great but it is a memory hog. Sounds like something that could be automated with pownjs in the future. 47 | 48 | You can use [recon](https://github.com/pownjs/pown-recon) from the [pown](https://pownjs.com/) toolkit to quickly find github account you would like to target. Here is an example how this could work: 49 | 50 | ```sh 51 | pown recon t githublistmembers 52 | pown recon t githublistrepos 53 | ``` 54 | 55 | Use the method above to dump the leaks once you identify all repositories. 56 | 57 | Pay particular attention to personal dotfile repositories. It is very common to see such things discloused online. 58 | 59 | ### Docker Hub 60 | 61 | It is worth checkout the target docker hub for target related images. If the image is not built with a public Dockerfile there is a chance it may container some interesting artifacts. 62 | 63 | There are no known tools to automate this process at present. 64 | 65 | > **NOTE**: Sounds like something that can be done with pownjs. 66 | > **TODO**: There is a tool to discover each change in the image. What was the name? 67 | 68 | ### Package Manager (NPM, Gem, Maven, Etc.) 69 | 70 | Companies who use AWS tend to have very diverse software stacks. It is not too uncommon to find references to AWS artifacts in package repositories (especially old ones). 71 | 72 | There are no known tools to automate this process at present. You need to download each individual package version and check for useful information. 73 | 74 | > NOTE: Sounds like something that can be done with pownjs or perhaps build custom solutions with the language that is supported by the package manager. 75 | 76 | ### Mobile Apps (iOS, Android) 77 | 78 | Mobile apps often contain more than they should like header files, readmes, configuration files and more. Some developers do not know how to slice (conditionally compile) their soure code such as it does not contain sensitive debug/testing information which often could lead to revealing some interesting aspects about the target including AWS account information and secrets. 79 | 80 | ### Web Search Engines 81 | 82 | Needless to say, the target organisation may already disclouse this information somewhere such as GitHub, Stackoverflow, etc. Some basic searches could produce fruitful results: 83 | 84 | ``` 85 | "arn:aws:" target 86 | ".amazonaws.com" target 87 | ``` 88 | 89 | Mix the above a little bit for more targeted results. For example, the following search query will try to find AWS-related information in trello boards: 90 | 91 | ``` 92 | "arn:aws:" target site:trello.com 93 | ``` 94 | 95 | It is also possible to discover other types of resources in AWS that could lead to fruitful results. For example, elastic search instances can be discovered with simple searches like this: 96 | 97 | ``` 98 | target inurl:/_plugin/kibana site:es.amazonaws.com 99 | ``` 100 | 101 | ### Shodan, ZoomEye, Censys 102 | 103 | These sites can be used to find potentially interesting information that relates to the target. Try all of them and see what you can get. Again, the aim to find things that are related, not just some random open targets on the internet, which plenty can be found with ease. 104 | 105 | Once you discover something that could be related to the target, pay attention to adjacent ranges. You might need to portscan these as well or at the very least look them up with the search engine of choice. This is not always a fruitful task but it could return some interesting results. 106 | 107 | Pay attention to banners. ZoomEye will automatically match versions to known vulnerabilities which is particularly useful. Exploits for these vulnerabilities could be found in known places like Exploit-Db and Metasploit but also have a good look at GitHub. There are a lot of exploits in there too. 108 | 109 | You can use Pown Recon for this. For example: 110 | 111 | ``` 112 | pown recon t zoomeyescrapesearchresults target 113 | ``` 114 | 115 | ### Web Sites 116 | 117 | Websites belonging to the target organisation may contain various types of leaks including AWS ARNs. There is no easy way to go about this. You need to download the site content and look for strings. You can look at tools such as `httrack` to do this for you. There is also a large collection of tools that can be used in this domain over [here](https://github.com/BruceDone/awesome-crawler). 118 | 119 | > **NOTE**: SecApps Cohesion might be able to help with this task. 120 | 121 | > **NOTE**: SecApps Unfold might be able to help with this task as well. 122 | 123 | ### AWS Bugs 124 | 125 | From time to time you may encounter a bug which you can use to map emails to account ids and so on. Be on a constant lookout for these bugs. AWS appears tight in this regard but it like any other software is has its own challanges. 126 | 127 | > **NOTE**: this section needs to be organised better 128 | 129 | ## Phishing 130 | 131 | Emails that look like coming from AWS could be used for phishing. For example, AWS Trust Advisor does send some relatively easy to spoof emails and they come frueqnet enough to fool most people. 132 | 133 | ## Other Ways To Get In 134 | 135 | ### Corporate Network 136 | 137 | Company networks are often direclty connected to the AWS cloud environment. Breaking in the company network will give you AWS access as well in most cases. Obviously a classic APT will work really well but you might be lucky if you get access to guest network, which could be misconfigured and as a result get you access to AWS. This is particularly true if the company is using ACLs to allow access to company ranges from AWS resources like API Gateway. The public IP listed in these ranges could be the office network IP space which often might not be a dedicated IP space but shared with others. Think of co-working spaces. 138 | 139 | ### Developer Environments 140 | 141 | Once we know who works for the org (see above) we can identify what they are working on and what sort of dependencies they might be interested in. This is kind of getting into advanced APT but the bottom line is compromising a node in the chain will inavitably lead to comromising the target organisations. Hacking into an NPM dependency is all it takes. 142 | 143 | ### Developer Social Profiles 144 | 145 | Hackers don't hack computers. They hack people. So following peopple online (twitter, reddit, etc) will also help in many circulstances understand the target landscape. 146 | 147 | > **/NOTE**: 148 | 149 | ## Access 150 | 151 | If you are lucky and you know have some access tokens in the form of AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and/or AWS_SESSION_TOKEN you can start interogating the AWS environment itself. You have done some pretty good job but there is still a lot to be done. 152 | 153 | ## Persistence 154 | 155 | ## AWS Technologies 156 | 157 | The following section is dedicated to various AWS technologies and various type of peculiarities that are subject to abuse. 158 | 159 | ### CloudFront 160 | 161 | > Amazon CloudFront speeds up distribution of your static and dynamic web content, such as .html, .css, .php, image, and media files. When users request your content, CloudFront delivers it through a worldwide network of edge locations that provide low latency and high performance. 162 | 163 | #### Introduction 164 | 165 | CloudFront provides CDN services. In essense it is a a reverse proxy to web services with support for aggresive cashing. You can stick CloudFront infront of anything including internal AWS services like lambda. 166 | 167 | CloudFront is composed of origins. Each origin provides a URL mapping from CloudFront to the internal service where the requests are proxied to. This means that a CloudFront distribution can be used to expose resources from multiple backends. For example the same CloudFront distribution can expose resources from both an s3 bucket and some internal service at the same time. These are mapped as origins. 168 | 169 | #### Enumeration 170 | 171 | It is particularly useful to run a directory/web bruteforcing on CloudFront distributions as that will reveal different backends. Pay attention on subtle differences in the HTTP response server header, response code, length and other types of metadata that may indicate a different backend. Discovering the different backends will help not only help understand the target infrastructure but also help choose the correct type of attack. 172 | 173 | #### Useful Facts 174 | 175 | * The origin will always see `Amazon CloudFront` for the User-Agent. The client user-agent is not supplied. 176 | * In fact, no request headers will be provided to the origin (unless configured, as it can be done for cookies). 177 | 178 | ### API Gateway 179 | 180 | > TODO 181 | 182 | ## Methodology 183 | 184 | The key to success is having a well defined system. While this rule applies to life as a whole it is particularly useful when performing security assessments. The following table can be used to kickstart any AWS security assessment project: 185 | 186 | | Category | Question | Complience (Yes/No/Partial) | 187 | |--------------------|--------------------------------------------------|-----------------------------| 188 | | **Fingerprinting** | Are AWS resources leaked on GitHub repositories? | | 189 | | | Are AWS resources leaked on in search engines? | | 190 | | | Are AWS resources leaked on target sites? | | 191 | 192 | ## Defaults 193 | 194 | The key AWS environments are 195 | 196 | | Name | Purpose | 197 | |------|---------| 198 | | AWS_ACCESS_KEY_ID | | 199 | | AWS_SECRET_ACCESS_KEY | | 200 | | AWS_SESSION_TOKEN | | 201 | 202 | You will find AWS credentials in the following locations: 203 | 204 | | OS | Path | 205 | |-------------|------------------------------------| 206 | | Window | C:\Users\USERNAME\.aws\credentials | 207 | | Linux/Unix | /home/USERNAME/.aws/credentials | 208 | 209 | Additionally the following URLs can be queried for sensitive information if you already have access to AWS (EC2). 210 | 211 | | URL | Description | 212 | |-----------------------------------------------------------------------------------|-----------------------------------------| 213 | | http://169.254.169.254/latest/meta-data/iam/security-credentials/ | Name of the attached instance profile | 214 | | http://169.254.169.254/latest/meta-data/iam/security-credentials/the_profile_name | The actual credentials from the profile | 215 | | http://169.254.169.254/latest/meta-data/iam/security-credentials/dummy | Same as above but works with AWS Glue | 216 | 217 | ## Tools 218 | 219 | * [Bucket Search By Grayhatwarfare](https://buckets.grayhatwarfare.com) 220 | * [Pacu AWS Exploitation Framework](https://github.com/RhinoSecurityLabs/pacu) 221 | 222 | ## Links 223 | 224 | Rhino Security Labs has a tone of tutorials on how to hack into AWS. 225 | 226 | * [Using AWS Account ID’s for IAM User Enumeration](https://rhinosecuritylabs.com/aws/aws-iam-user-enumeration/) 227 | * [Assume the Worst: Enumerating AWS Roles through AssumeRole](https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/) 228 | * [Cloud Breach: Compromising AWS IAM Credentials](https://rhinosecuritylabs.com/aws/aws-iam-credentials-get-compromised/) 229 | * [AWS IAM Enumeration 2.0: Bypassing CloudTrail Logging](https://rhinosecuritylabs.com/aws/aws-iam-enumeration-2-0-bypassing-cloudtrail-logging/) 230 | * [AWS Privilege Escalation – Methods and Mitigation 231 | ](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/) 232 | * [Cloud Security Risks (Part 1): Azure CSV Injection Vulnerability](https://rhinosecuritylabs.com/azure/cloud-security-risks-part-1-azure-csv-injection-vulnerability/) 233 | * [Cloud Security Risks (P2): CSV Injection in AWS CloudTrail](https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/) 234 | * [Penetration Testing AWS Storage: Kicking the S3 Bucket 235 | ](https://rhinosecuritylabs.com/penetration-testing/penetration-testing-aws-storage/) 236 | 237 | ## Labs 238 | 239 | * [Terraform AWS Goat](https://github.com/opendevsecops/terraform-aws-goat) 240 | * [Cloud Goat](https://github.com/RhinoSecurityLabs/cloudgoat) 241 | * [Flaws](http://flaws.cloud/) 242 | * [Flaws2](http://flaws2.cloud/) 243 | 244 | ## Authors 245 | 246 | * [@pdp](https://twitter.com/pdp) 247 | 248 | ## Sponsors 249 | 250 | * [Websecurify](https://websecurify.com) 251 | * [SecApps](https://secapps.com) 252 | * [GNUCITIZEN](https://gnucitizen.org) 253 | --------------------------------------------------------------------------------