Date: Mon, 4 Apr 2016 10:08:06 +0200
From: Hack Ex <hackexfan@...il.com>
To: bugtraq@...urityfocus.com
Subject: Bugcrowd CSV injection vulnerability

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@...crowd.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@...crowd.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

Powered by blists - more mailing lists