CSV Injection in Azure Logs

With the global migration to the cloud, enterprises had to rethink how they track malicious activity in their environments. Some of the old monitoring mechanisms (such as packet capture) are no longer available, and the event logs have gained new prominence. Often, they are the only tool you have to keep track of what is going on in your infrastructure.

Cloud providers have had growing pains when it comes to implementing logging functionality. Azure, in particular, has been dealing with multiple log quality issues. Logs also present a juicy recon target for attackers looking to map out your environment, and sensitive information can be  leaked there.

As serious as these problems can be, they are "passive" - information exposure is the worst that can happen. However, logs can occasionally become the carrier for attacks against the enterprise. We will describe one such exploit in this blog.

Log Injection and CSV Injection

A log injection is an attack where an adversary can influence the contents of a log by adding a specially crafted malicious payload to it. This happens because user actions frequently result in new records added to the logs, and such records often contain the data the user has control over: user IDs, email addresses, message subjects, and so on. When this data is maliciously crafted, the application that processes the logs may be tricked into executing an attack. For example, one could submit a fake email address containing an XSS (Cross-Site Scripting) payload in an account signup form. And the application administrator that opens this log in a browser may become the victim of an XSS attack.

Logs in Azure can be downloaded as CSV (Comma-Separated Values) files, which are vulnerable to a CSV Injection technique. In this type of attack, if a CSV file contains an Excel formula (usually beginning with an equals sign - '='), it is executed by Excel when it opens the file. Some formulas can be malicious, causing OS Command Execution or other exploits. It can be hazardous not only because arbitrary commands can be run but also because users don't usually know about it, thinking that CSV files are just plain text files that cannot possibly cause any damage. 

We have found a new instance of Log Injection combined with CSV Injection in Azure, which can be used to attack Azure administrators. Such vulnerabilities have been reported in the past, but this instance is more dangerous because it can be executed unauthenticated, i.e. you do not have to have an account in the cloud environment.

Attack Scenario

The attack consists of two stages:

1. Pollute Azure logs

2. Social engineer a victim admin into opening the logs as a CSV file

*Note that the attack will not work on a fully updated MS Excel instance (more on this later).

Polluting Azure Logs with Malicious User Agent

To pollute the logs with a malicious command, you don't need any special permissions or even an account on the victim system. You just need the username of an existing user.

We start by submitting the injection payload as a user agent string:

1. Start Microsoft Edge (any browser will work as long as you can manipulate the user agent as detailed below, as will any attack proxy like Burp or ZAP)

2. Open Developer Tools (Ctrl+Shift+I), click the menu on the top right and select Run Command (Ctrl+Shift+P):

3. Type "network conditions" and press Enter:

4. In the drawer that opens, uncheck "Use browser default" and paste the following string into the bottom field:

=msexcel|'\..\..\..\Windows\System32\cmd.exe /c calc.exe'!'A1'

This sample Excel formula will use Dynamic Data Exchange (DDE) protocol to start Calculator. A real-life payload will be something more destructive (e.g. a PowerShell command that downloads the next stage of infection).

5. Without closing the drawer, go to https://portal.azure.com and enter the e-mail of any existing account in your target system.

6. When asked for a password, enter any string (it's not our goal to log in successfully!):
   
    

Getting the Victim to Open the Logs

The sign-in logs in the target Azure tenant now contain the poisoned log record (it may take a few minutes to actually deliver it).

Now, you can social engineer the target admin into opening the logs. There are two services in the portal where this can be done: Log Analytics and Microsoft Entra ID. We will describe the former.

Any user with read access to Azure Log Analytics is sufficient, so it does not have to be an administrator with top-level privileges. 

A variety of possible pretexts are possible. For example, an "Azure technical support engineer" can contact the admin to request assistance investigating "suspicious login attempts."

The steps are as follows:  

1. Instruct the target to open Azure Log Analytics and load the SigninLogs table into the query window (double-click it). Click the Run button to execute the default query:
   
   

2. The log will load, and one of the entries will contain our payload:

3. Instruct the target to load the log as a CSV file in Excel for "ease of analysis":
   
   

4. The logs will load in Excel. A warning message will appear, which the target should ignore:
   
   

5. Another warning message will appear, which the target should also ignore. Note that the application it complains about is "MSEXCEL.EXE," which is less suspicious than something like "CMD.EXE":  
   

6. The Calculator instance will pop up (just as our payload intended):
   
   

You can see the attack in action in this video:

Dealing with Excel DDE Protection

This vulnerability does not trigger out of the box in the latest updated version of MS Excel. Microsoft implemented mitigations to prevent the DDE server from launching from Excel formulas by default. For the payload to work correctly, the target has to be using an older version of Excel or have DDE Server Launch enabled in the latest version of Excel (e.g. by being instructed by the attacker as part of the social engineering stage).

To disable this protection in Excel, go to File > Options > Trust Center > Trust Center Settings... > External Content and check Enable Dynamic Data Exchange Server Launch (not recommended):

Beyond DDE

The restriction of DDE calls may seem to leave users safe, but that safety is deceptive. Several other dangerous formulas that do not require DDE can be injected. Here are some examples (most will generate a warning message upon opening the file):

Disclosure

We responsibly disclosed this vulnerability to Microsoft:

2022-09-13 - Reported to MSRC
2022-09-21 – MSRC responded: “…vulnerability really exists in how Microsoft Excel opens files. It also requires clicking-through a warning in Microsoft Excel. We could consider blocking CSV injection payloads as a DND precaution as a fix in Next Version releases.”

Microsoft seemed non-committal to making changes to prevent CSV injection payloads, and the vulnerability exists to this day. 

Mitigation

While Microsoft was correct in stating that security updates in Excel prevent the triggering of DDE payloads, there are several other factors to consider:

• Victim may have an old, unpatched version of Excel installed or be social engineered to drop the defenses. We demonstrated one scenario for this above.

• There are non-DDE formulas in Excel that could be dangerous. We have outlined several examples of that. Additionally, Microsoft is adding new Python functionality to Excel formulas, and invoking Python code through injection may bring new, unexpected consequences.  

• Other applications could open CSV files, possibly resulting in new exploits. For example, on Linux, LibreOffice is a popular office suite that will be used to open CSV files. It executes Excel formulas and supports DDE, too.

• Finally, it's important to practice "defense in depth." It would be consistent with this practice not only to rely on an Excel fix but also to eliminate the possibility of formula injection at the source in CSVs generated by Azure.

We believe that the right course of action is for Microsoft to sanitize values in CSV file cells that begin with "=" (and some others cells that start with "+", "-", "@", and some other characters can also be interpreted as formulas). The original values do not have to be removed (after all, they may be important to the defender). Prefixing them with some string that clarifies the intent (e.g. "<INSERTED TO MITIGATE POSSIBLE CSV INJECTION>") will be sufficient.

Until that happens, Azure users are advised to fully update all the tools they use to open CSV files and educate their IT staff on the dangers of malicious payloads in Azure logs and social engineering attacks that may attempt to exploit them.

Engage with us directly regarding this blog post and other topics in the Vectra AI Reddit community.