CSV Excel Macro Injection, also known as Formula Injection or CSV Injection, is an attack technique that we use in the day-to-day penetration testing of the application.
CSV injection is a vulnerability that affects applications having the export spreadsheets functionality. These spreadsheets generate dynamically from invalidated or unfiltered user inputs. Modern web applications offer spreadsheet export functions these days. This allows the user to download data in a .csv file format or .xls file format. This is suitable for handling spreadsheet applications like MS-Excel and OpenOffice Calc as a result of which the cells in the spreadsheets can contain inputs from untrusted sources. As a result, the end-user who is accessing the exported spreadsheet can be affected.
This vulnerability can be used by an attacker to execute attacks such as client-side command injection or code injection. Basically, the attack scenario for this is purely targeting the user(s) who download the Excel file naturally. We usually disregard this attack as a non-issue. However, websites should still be aware that the information they are exporting can potentially affect the users.
CSV excel macro injection can be exploited when the application supports export to excel functionality.
This happens on spreadsheet files which dynamically generate from invalidated input data.
CSV Injection Payloads used to test and exploit:
We can use formulae which we use in excel for carrying out operations to test for formula injection on websites.
As you can see, once we click on the export excel option, the records automatically export to an excel file with the .xls format. Thus, this allows us to download the .xls file
This vulnerability occurs due to the concept of dynamic data exchange(DDE). DDE is a protocol for interprocess communication under windows supported by MS-Excel, LibreOffice, and Apache OpenOffice.
The DDE function is in the following format:
=DDE(server; file; item; mode)
So by using some malicious arguments, it is possible to remotely execute applications or commands on the victim’s computer of whoever opens the document.
So, the most common CSV Injection payload used is:
=cmd|’ /C calc’!A0
cmd is the name the server can respond to whenever a client is trying to access the server
/C calc is the file name which in our case is the calc(i.e the calc.exe)
!A0 is the item name that specifies the unit of data that a server can respond when the client is requesting the data
So our final DDE call becomes:
DDE (“cmd”;”/C calc”;”!A0″)
As you can see in the above screenshots, our payload adds to the input fields. Now, once we export this record to an excel file, our payload informs the program to run an application called cmd.exe with the command /C calc which executes calc.exe from the command line.
Once the excel file is open calc.exe will be executed as shown in the screenshot below.
Mostly these payloads are all fine and well. But, sometimes the
= character filters out. However, we can use some different combinations such as @, + or -. So, the current payload of choice for exploiting this as a proof of concept is.
@SUM(1+1)*cmd|' /C calc'!A0
We can use any formula starting with:
Updated on Sunday, 6:30 AM
In conclusion, I recommend that it is always a good practice not to trust user inputs and always encode the output. Also, for the successful execution of the formula, an attacker will have to use the ‘-‘, ‘=’, and the pipe (|) is used to execute the binary in the excel software. Hence, it is strongly recommended to filter the ‘- ‘, ‘|’, ‘+’, and ‘=’ to mitigate this vulnerability.
 Download Vulnerable Code here
 CSV Injection : https://blog.zsec.uk/csv-dangers-mitigations/
This vulnerability seems to b affected by excel and not web applications although we can sanitize and validate user inputs
Thank you arif
It is clearly mentioned this vulnerability is not in the Excel software, this leading due to improper user sanitation and malicious formula getting executed to run binary.
When discussing formula injection, please don’t omit the hyperlink attack mentioned in the original post at http://www.contextis.com/resources/blog/comma-separated-vulnerabilities/, and claim DDE is the only exploit mechanism. Doing so means that your mitigation advice will utterly fail to prevent the most plausible attack (using formulas to silently exfiltrate the contents of the document).
Thank you for the suggestion. Will update the post accordingly.
What are the ways to mitigate this? Lets say I got such file via mail… Moreover I will be using xls files as input to generate pdf from that file…. So how to keep my application safe from such inbuilt code exploits….?
i didnt get your question bro can you please make it more clear?
I mean what are the ways to stop this exploit? If I get a file with vulnerable code and if I open it, my system is compromised…. So how to stop that code from executing?
This exploit doesnt work in updated microsoft excel i tested this on 2007 so its suggested t keep you microsoft office updated
The very first thing if you running under the domain controller, you can disable the micro using Group Policy and the malicious file will not get executed. In other case whenever you will open the malicious document, it will popup the warning and there you will have to close the malicious file. I hope this clarify your question’s answer.
Ishaq thank you so much for your effort. I hope this will help others in many ways. ???????? keep it up brother.
Thanks nitin. 🙂
Its pretty impressive explanation! great work 🙂
Clear all about CSV injection.
Nice work bro
Nice explanation brother! Keep it up.