Most of the work of the VEL involves dealing with the same two vulnerabilities: sql injection and cross-site scripting. They are so common that there are standard methods for preventing them by escaping untrusted input.

Recently we received a more unusual report, from a security researcher, concerning a CSV injection vulnerability in AcyMailing (see https://www.owasp.org/index.php/CSV_Injection). It quickly became apparent that this was a wider issue of insecurities in csv export files rather than one specific to AcyMailing. The problem arises because, when imported into a spreadsheet, some special characters can be interpreted as formulae. In Excel in particular, it is possible for an attacker to run commands on a user's computer, for example opening up other programs such as Windows PowerShell. However Excel is not alone in having vulnerabilities, it may (for example) also be possible to exploit Google Sheets to steal user data through crafted data. The more we looked into it, the more it looked like one big fat can of worms.

Is this an extension vulnerability at all? While we think that Excel is very much at fault here for too easily executing any macros that it finds in CSV import data, we do think that this is something that extension developers should be aware of, and should take reasonable steps to mitigate. An attacker may be able to exploit the fact that a csv file comes from a site admin's own website to persuade them that the data should be trusted, and that any security warnings can be safely ignored, so there is some responsibility.

Having said that, it is easier to say than do. Part of the issue is that you don't know what the data will be used for (it may not be loaded into a spreadsheet at all), so it is difficult to devise a system of escaping that will always be safe without sometimes also breaking the data.

In theory, escaping special characters with a single quote (') should work, but if the CSV file is saved/exported again using Excel the quote will be removed so the saved file will have the vulnerability again.

In their tests, Acyba reported that

The only solution that seems to work with all Excel versions is to prefix the value with a tab.

The thing is that only a fraction of our users open the exported files with Excel, the majority directly imports it in another system (that won't necessarily remove the quote/tab so phone systems and accounting systems won't work anymore for example).

Some users also set up an automatic export in AcyMailing using the cron task, and an automatic import in their other system. So if we modify AcyMailing to prefix with a tab/quote, even if Excel is secured it could break the other systems people are using and thus could potentially have an enormous impact.

Acyba have dealt with this by offering the user a choice, and have issued a patch which by default escapes the data for Excel, but allows the user to turn that option off. We think that is a reasonable approach.

To their credit, Acyba reacted quickly when we contacted them about the issue. We ask all extension developers who export csv files to look into this issue and to take appropriate measures.

And if you are opening a CSV file in a spreadsheet application, unless you are 100% certain that the data are trustworthy, remember that you can open it first in a text editor and check what is actually in there.

 

Links

https://www.owasp.org/index.php/CSV_Injection

http://georgemauer.net/2017/10/07/csv-injection.html

https://www.contextis.com/blog/comma-separated-vulnerabilities

 

 

Credit

Thanks to Sureshbabu Narvaneni for responsible reporting