BugCrowd CSV Injection

`Description:  
  
A vulnerability in the file upload feature allows attackers to send  
malicious csv files. By using the Microsoft Excel DDE function an  
attacker can launch arbritary commands on the victims system.  
  
Many companies don't allow xslx or docx files to be uploaded by  
security testers, because they can contain malicious macros. What they  
don't realize, however, is that csv files can contain malicious macros  
as well.  
  
The csv contains a field like this:  
=cmd|' /C calc'!A0  
  
Which in this case launches the calc application as a proof of  
concept. While excel does give a warning before a user opens the file  
saying it should only be used if it comes from trusted sources,  
bugcrowd could be seen as a trusted source and the file could be  
executed.  
  
This is just as bad or even worse than an XSS vulnerability. Imagine  
if a security researcher made a submission. This submission got  
rejected and the researcher is very angry. To have his revenge, he  
sends a malicious csv file containing a payload to launch an  
application and steal the credentials of the analysts account. Now the  
researcher has access to all the vulnerabilities that have been  
reported in the application. He can now publish them or cause havoc.  
  
Extra info:  
  
Description of the vulnerability  
http://www.contextis.com/resources/blog/comma-separated-vulnerabilities/  
The same vulnerability has been discovered in HackerOne.  
https://hackerone.com/reports/72785  
  
The researcher recommends BugCrowd to always stay on the lookout for  
new kinds of vulnerabilities. Most of my submissions were  
vulnerabilities in the Bug/Other categories, because they weren't the  
most obvious vulnerabilities. This vulnerability was found in just a  
few minutes after reading through some public HackerOne articles and  
discovering an article about CSV formula injection.  
  
Solutions  
Do not allow formulas in csv files.  
  
Comments  
  
Researcher  
  
Certain 'risky' file types like EXE files are also accepted on upload.  
A better approach would probably be to limit the allowed file types to  
a certain degree.  
  
Analyst  
  
We agree with Google, who made an announcement about this issue:  
https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection.  
As such, this is a P5 or Won't Fix issue based on Bugcrowd's  
Vulnerability Rating Taxonomy. Please do read our VRT in order to know  
what bugs are eligible for rewards.  
  
changed state to wont fix  
This submission was reproducible but will not be fixed. This may be a  
best practice recommendation, an issue with low risk, an issue that  
has existing mitigations in place, or is an accepted business risk for  
the customer.  
  
Researcher  
  
Thank you for bringing this to the researchers attention. He will  
refrain from reporting these kind of vulnerabilities from now on. The  
researcher did read the VRT, but didn't realize that CSV injection  
vulnerabilities were a part of it. He will make sure to always test  
that document before writing his reports.  
  
Researcher (again)  
  
The researcher doesn't want to be stubborn, but just to make sure you  
understand the full impact of the vulnerability consider the fact that  
Bugcrowd has 54 different companies that have their own bug bounty  
programs. If an attacker send a malicious file like this to all these  
companies the chanches of at least one analyst making a mistake and  
opening the file are definitely high.  
This could be an attractive vector for an attacker to take into  
account. Excel already displays several warnings upon opening a csv  
file, but these warnings imply that if the file is from a 'trusted  
location' it should be ok to continue. If an attacker submits a  
legitimate low level issue the analysts might place more trust in  
them, because they already reported a vulnerability in their products.  
Of course, Bugcrowd cannot account for every single malicious file. If  
an analyst decides to open an EXE file and it contains malware then  
that is something Bugcrowd doesn't have any responsibility for.  
However while many people know about the risks of XLSX files and  
malicious macros, not everybody knows about the fact that CSV files  
can be malicious as well.  
The researcher agrees with the stance of Nikhit Kumar  
(http://www.tothenew.com/blog/csv-injection/).  
This issue is not essentially a vulnerability in Excel, but in every  
website that places active content from untrusted sources into  
spreadsheets. A website must validate its user input properly.  
There is not a lot Microsoft can do to 'fix' this issue in Excel,  
since it is partly an intended functionality of their product. This  
isn't just limited to Excel, but it also affects products like  
Openoffice and others. Older versions don't even show a warning at all  
(although at this point, there are so many prerequisites that this can  
hardly be seen as a valid argument).  
While the researcher understands the opinion of a high profile  
organisation like Google is quite convincing the researcher doesn't  
believe it to be a business accepted risk. Please take a moment to  
reconsider my arguments. The researcher accepts the decisions made by  
Bugcrowd. If this submission will not be fixed, however, the  
researcher would like permission to publish a video demonstrating this  
issue so that company analysts are aware of this issue. This is not  
meant as a threat towards Bugcrowd, since it is more of a way to teach  
the users of Bugcrowd about the risks involved with opening these  
kinds of CSV files.  
Thank you for your response and the researcher awaits your response.  
Greetings,  
HackEx  
  
Analyst  
  
Hey HackEx,  
You can email [email protected] for the request of your report to  
be made public. Make sure to include the Reference Number of this  
report.  
  
Researcher  
  
The researcher has sent an email to [email protected] asking for  
full disclosure.  
The researcher doesn't really like the idea of going full disclosure,  
since it would increase the chances of attackers actually exploiting  
this vulnerability and it could damage the reputation of Bugcrowd.  
The researcher highly values the Bugcrowd community and everything it  
stands for and doesn't want to create a public discussion about this  
submission.  
Could the analyst please explain in his/her own words why this  
vulnerability will not be fixed? Relying on the opinion of another  
company isn't really applicable in all cases.  
An employee of Mozilla describes it nicely in response to  
https://bugzilla.mozilla.org/show_bug.cgi?id=1054702  
a bug in bugzilla.  
Why is this bug tagged as a security bug? It's an issue in Excel/LibO/OO  
IMO, not a Bugzilla bug.  
It doesn't matter whose bug it is, bugzilla is used by folks in  
environments with those very common programs and the combination can  
result in harm. That makes it a security bug  
Bugcrowd is also used in environments with these programs.  
Now, you could also make an exception for this submission and fix it  
while not rewarding the researcher. Because this is not about being  
rewarded for this vulnerability, the researcher simply wants this  
issue fixed and be absolutely sure it isn't abused to attack the very  
companies he has fought to protect during the last 11 months since he  
joined Bugcrowd.  
Besides Google has actually fixed the same kind of vulnerability in Google docs.  
Just look at https://erpscan.com/press-center/excel-formula-injection-in-google-docs/.  
This means that the argument "Google doesn't think it is an issue and  
neither do we." doesn't hold up anymore, since Google actually does  
think this is an issue.  
Please give it some thought. The researcher send a very long comment  
the last time and none of the points he made were adressed other than  
the researcher potentially wanting to go full disclosure.  
With all due respect, it would probably be a lot easier to fix the  
vulnerability now and get it over with than it would be to go full  
disclosure and fixing it after public embarrassment (which is quite  
likely to happen considering that the people who care about this issue  
are probably both the security researchers and the companies who  
joined Bugcrowd).  
The researcher reads mailing lists like Bugtraq and other resources  
like security researcher blogs daily and so do many other people.  
So please, again, reconsider this issue. The researcher will probably  
not be able to come up with much more than he has done so far to  
convince you to fix it except for public disclosure, but this is  
against the researchers philosophy of responsible disclosure and the  
researcher would hate to do that.  
  
Analyst  
  
Hi HackEx,  
This has been given okay for full disclosure.  
  
Video:  
  
https://www.youtube.com/watch?v=vhR5olzu3_E  
`