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 support@bugcrowd.com 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 support@bugcrowd.com 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