Hi all.
Recently the researcher discovered a CSV injection vulnerability in the Bugcrowd file upload form.
According to the Bugcrowd VRT this is a P5 issue.
This vulnerability could be used to attack Analysts by sending them malicious CSV files with injected DDE macros.
(https://www.owasp.org/index.php/CSV_Excel_Macro_Injection).
Now most versions of Openoffice and Excel already show several warnings before allowing you to open such a CSV file, however since a researcher might report a valid issue and because not every analyst might know about the risks involved with CSV files, an analyst might decide to continue which results in RCE on the analyst system.
The researcher understands that the Bugcrowd analysts follow the VRT and their reasons for not accepting his submission. The researcher also doesn’t like publicly complaining about low priority issues, but he would like to hear the opinions of the researchers on this matter.
Bugcrowd doesn’t have the responsibility to secure their analysts from ALL malicious files. For example, if an EXE file is uploaded it should be pretty obvious that it is better not to open it. However, this issue is quite trivial to exploit and there are over 54 different companies registered on Bugcrowd.
The researcher has posted all details here: https://www.reddit.com/r/fulldisclosure/comments/4da7um/bugcrowd_csv_injection_vulnerability/.
Hopefully the other researchers can share their opinions on it and we can have a public discussion on whether or not this vulnerability should be fixed.
A video demo can be found here:
For the time being remember that CSV files can be malicious and do not open any CSV files using your office programs.
The first few opinions have been shared by other researchers.
Daniel Martínez
Bugcrowd CSV injection vulnerability
http://seclists.org/bugtraq/2016/Apr/13 … /* a bad place for an injection */
cxsecurity
https://cxsecurity.com/issue/WLB-2016040019
Severity: Medium
Christian Frichot
IMHO if someone opens something in Excel and clicks through all warnings they deserve the result.
Again, Bugcrowd can easily defend against this vulnerability and it would prevent further risks from CSV files. If a new vulnerability is found affecting Excel or other office programs that allows you to bypass the warnings, Bugcrowd would be good to go.
A few other ‘opinions’ have been shared:
Requested CVE
justinsteven:
Hahahahahaha
jstnkndy
such a garbage account and vuln
Let’s stay professional here. What are your arguments? Just because a vulnerability requires user interaction does not mean that it is not our responsibility to protect our users against it. Vulnerabilities do not have to be sexy or complicated, they can be very simple and still have some impact.
A few years ago, the risks of reflected XSS were not taken seriously. In 2005 Samy Kamkar released a cross-site scripting worm onto MySpace.
Reflected XSS requires some kind of user interaction (a click on a malicious link, for example), but can still have a lot of impact.
Should we really blame our users for irresponsible behavior? As web developers we have the responsibility to sanitise user input. In the case of this vulnerability, we could fix it by simply adding a ’ to the fields with equal signs.
We can either assume that the analysts, many of whom are security experts, will not make the mistake of trusting the file or we can prevent the risk alltogether by fixing the issue.
This vulnerability was found in a very short time. The researcher did not spend a lot of time to try to discover it. It probably wouldn’t take a lot of time to fix it either.
“The researcher” is spending more time making a fuss about it because they were not rewarded than they spent looking for it, which is why my opinion is what it is. Bugcrowd has reviewed the submission, given it their consideration, and responded with their decision.
This really isn’t about the reward, the researcher has actually told Bugcrowd that he would be fine with them fixing this without getting a reward at all. He just wants to make sure that the analysts are protected against this issue which is why he decided to publish it. He understands that it is annoying when researchers make a fuss about vulnerabilities, but this was his last option in trying to fix the vulnerability.
The researcher respects Bugcrowd and loves the platform, this is just an attempt to make it more secure.
Thank you for your response.
This discussion has been going on for too long.
The researcher understands the decision that Bugcrowd made and will now refrain from his efforts to get this vulnerability fixed.
This was not meant to offend anyone and the researcher understands that Bugcrowd receives many submissions every day and cannot possibly protect against every single type of malicious file.
Please do not take this personally.
Greetings,
HackEx