Monday, December 18, 2017

CSV injection mitigations

It's a common feature for servers to allow exporting data in CSV formats that users read in their own machine using some spreadsheet software. The sources of data for the CSV export may be spread across many places in the server where any malicious user can put data. Malicious users can put specially crafted spreadsheet formulas in the server, that might end up in the CSV export file. When the victim opens the CSV file, the formulas end up executing in his machine (victim has to ignore multiple warnings from the spreadsheet software), executing arbitrary commands that the malicious user injected in the server.



I won't describe the payloads and impacts in this blog, as there is already some well written blogs for those information -
The purpose of the blog is to describe proper mitigation.

Example of bad mitigation

One product in my organization fixed a similar issue with 2 layers of defense. For any CSV cell value that starts with +, -, @, = (as suggested in http://georgemauer.net/2017/10/07/csv-injection.html or OWASP) the fix added (1) a preceding TAB char, (2) single quotes around the cell value. But later the we found that adding a single / pair of double quote(s) before the attacker's payload can simply evade the filter to check for the chars +, -, @, =. e.g. if the payload attacker injects is =2+5+cmd|' /C calc'!A0 filter will catch it and mitigate the risks. But if attacker puts the payload ""=2+5+cmd|' /C calc'!A0 filter won't be able to catch it as it was checking for only values starting with +, -, @, =. The end result will be same because MS excel, while rendering the value, simply skips the leading double quotes in CSV values.

Suggested mitigation

So, the mitigation should be, while creating the CSV export in the server -
  1. Create a white-list of allowed characters for the stored data fields in the server and block requests for storing other values. This is a best practice that reduces the chance of any injection attack. While creating CSV export, explicitly disallow any of the following chars in CSV export values +, -, @, =, |, ". If disallowing some chars is not possible in the context of the application, prepend those with a back slash (\).
  2. Additionally, prepend a SPACE or TAB or SINGLE QUOTE to ALL CSV values before exporting them to file. This mitigation leaves the CSV file human readable but not executable. DO NOT check for leading +, -, @, =, " and prepend to only those values.
  3. If the CSV files are created SOLELY for the purpose of information exchange among machines, do not tamper any data as that may break the functionality. Instead you can take the following measures - save the exported file with .txt extension, Create a warning for GUI users while they are exporting a CSV, Update the documentation/SCG to make customers aware of the risk
Note:
  •  NOTE: In theory, escaping special characters should work, but if the CSV file is saved/exported again using Excel the escaping characters might be removed so the saved file will have the vulnerability again.
  • The above mitigation works with known spreadsheet software (MS Excel, Google sheets etc) in present. But other applications might use some other characters to denote a formula in a CSV cell. Also, how the known spreadsheet softwares interpret the values might change in future making the above defense mechanisms weak.
Safe browsing!

Proxychain tool in a nutshell

In order to do penetration testing anonymously and decrease the possibility of identity detection, hackers need to use an intermediary mach...