Cloud Security - Stealing temporary AWS access key via SSRF to access S3

By

This is a copy of my hacking demo published on Youtube some time ago. For the original video please check out my Youtube channel - 

https://www.youtube.com/watch?v=gwsooCD7liU&t=27s

Cloud security has been a hot topic. As more and more organizations go to the cloud, security breaches and incidents hitting the news headlines have been catching the eyes of the general public, making some people skeptical to embracing the cloud. However, when we look at the security controls of the cloud services providers, we find that most of them have actually been doing quite a nice and decent job, but then what actually happened in those cases to cause such perception?

Human learns best by examples, let's look at a simulated attack to discover some common themes and patterns. We have created a demo illustrating a chained exploit, which takes advantage of different mistakes made by the customer in cloud deployment. It is also how a serious breach might have happened in US hitting the news headline last year. We picked AWS in our demo not because AWS has any problem, just because it is more popular and the real hacks we are simulating were on AWS. 

In the first part of our demonstration, we can see a NodeJS web app running on AWS EC2 configured with IMDSv1 (Instance MetaData Service). IMDS provides a HTTP endpoint for the instance to query its metadata at an IP address not supposed to be routed outside i.e. 169.254.169.254, including the temporary credentials assigned to the role of the running instance. Sounds dangerous? Not quite given normally there is no way for an external attacker to access that endpoint. Then comes SSRF (Server Side Request Forgery), which is a software vulnerability that allows the attacker to pass in fabricated data or parameters, typically a URL, (blindly) trusted and used by the application to make HTTP requests and return the results. The application in the demonstration is vulnerable to SSRF. As a result, by passing in the IMDS endpoint address, the application makes an IMDS request on our behalf and returns us the metadata, including the temporary credentials, as if it is originated from the application legitimately. We can then use the stolen credentials to access the victim's other AWS services, in this case and in many real world incidents, S3 is the target.

To help the customers mitigate the risk, AWS, as well as other major cloud service providers, attempt to make it more difficult for unintentional access to the metadata service. While Google (no more v1Beta!!) and Microsoft Azure require a static header when accessing the metadata service, AWS goes one step further by requiring a HTTP PUT request first to obtain a token that must be passed along with a second request in order to retrieve the metadata, and here we have IMDSv2, born since end of last year (how AWS made that design decision? Read the rationale behind from AWS).

Now, if the same thing happens, like what we demonstrate in the first part of the demo, it is a software bug plus a mistake in AWS instance configuration. However, if we think that we are safe by configuring IMDSv2 and our credentials can no longer be stolen, think again. The whole idea of IMDSv2 as well as other static header implementation is based on the fact that in most typical SSRF attacks, the attacker can only control the URL, but not the header or even the HTTP method. What if the attacker can control these other aspects as well? Or what if the application has a more serious bug that can lead to RCE?

In the second part of our demonstration, we put our application (the same one) on an EC2 instance configured with IMDSv2. The problem is, the application is using an open source library to parse the input parameters, and this open source library has an insecure deserialization bug. So now in addition to SSRF, we have a second bug, and a more serious bug that allows us to inject arbitrary Javascript. The injected code will be dynamically evaluated by the vulnerable component, so that we can make any call we like. As a matter of fact, we can see in the later part of the demo that we have complete control of the instance by getting shell access (try curl the IMDSv2 endpoint if you like!!). The bug itself is serious enough, but don't forget the extended impact (e.g. your data in S3 might get stolen).

As best effort only, the cloud service providers try to provide more mitigating controls to help, like IMDSv2 from AWS, and very often, it is not a fundamental flaw in the cloud services, but application bugs plus user mistakes, again. The cloud just exposes lots of people's bad practice to the world, and amplifies it with bigger consequence. Remember some developers of a famous tech company checked in their AWS access keys in GitHub and got their GitHub repository compromised?

To conclude, when assessing the security risk of cloud deployment and its impact, do not just focus on security features or functions like firewalls, encryption, IAM, etc, and an attacker mindset is required. Most of the time, lots of security features and functions have been put in place in the architecture, but when we look at examples like this one and those in the real world, it has very little to do with the security software, it is more about software security, and security software is not software security. At the same time, like most air crash accidents, security incidents often involve a series of mistakes chained together to cause tremendous impact. A threat modeling exercise may be a good start to analyze potential attack paths, it would also help the penetration test team to test the deployment in a more efficient way. Next step: incident response, but before that, setup monitoring of your cloud logs, implement application logging on security events and stream your cloud and application logs to data analytics platform. Tools and data are the essential weapons for security operations and threat hunting.

My Youtube channel - https://www.youtube.com/channel/UCXSZyDvr7tpT62t3XvdCc3w

Popular posts from this blog

Cloud Security - Exploring the AWS Lambda runtime execution environment

By
Serverless computing has been gaining popularity especially in the cloud. While the service provides much convenience for most users who have no access to the underlying environment, hackers are interested in understanding how things work behind the scene, and we want to answer some basic cybersecurity questions. For instance, what is the software used, including operating system and middleware, in the application stack? Where does the service store credentials in the environment? And most importantly, how can a serverless deployment be hacked or leveraged in an attack if ever possible? In the following video demonstration, we try to explore the AWS Lambda runtime execution environment, which is used in lots of use cases from developing application APIs to configuring cloud resources. A malicious Lambda reverse shell backdoor function is written and deployed allowing us to explore the runtime execution environment interactively - https://www.youtube.com/watch?v=khF1PMjQv_E&t=10s T
Read more

AirGap Hacking - Malware infiltration via USB HID driver and data exfiltration via near ultrasound

By
This is my favourite piece of work that I published and presented in conference a few years ago. Here is the original demo video from my Youtube channel -  https://www.youtube.com/watch?v=a0kpUNOfoQM&t=5s  (with subtitles, no audio) Or you may visit my interview by an online media in which I explained how it works briefly - https://www.youtube.com/watch?v=pZwwuHwmyhM&feature=youtu.be In this demonstration, the computer on the left is the victims's machine with no network connectivity. Here we refer to it as an airgap computer. Moreover, USB drive is disabled and our best friend, antivirus, is enabled on this locked down machine. It is a common setup in certain environment such as OT network and highly secure financial trading system, with the assumption that the isolated machine cannot be hacked.  However, there has been high profile malware attack on such environment including utilities plant and closed financial network. In real life scenarios the targeted machine may not
Read more

Mobile Security - TV interview and demo

By
In one of the TV programs I was interviewed a few years ago, an active internet user was invited to participant in a test to assert her awareness of security when using her mobile phone. She was asked to join an interview about all the things she would do online, and during the few minutes amid the interview I was tasked to take over her PayPal account. As a matter of fact, she was quite vigilant about protecting herself online and to avoid any liability issue, both mobile devices used by her and the TV program host were prepared by me ahead of time, and new PayPal accounts, both owned by the TV program producer and host, were created on-site during the test. She was asked to open a PayPal account and setup a password during the interview, and the host immediately transferred HKD 10,000 to her account. After a few minutes, I signalled the host that I was done, and the participant was asked to check her account balance, and obviously she failed to login back to her account. She suspecte
Read more