Sunday, 28 June 2015

Linkedin - security issue - Unvalidated Redirects and Forwards

This is a Linkedin shortened URL that seems to be pointing to Linkedin (when you try to reverse it) but in reality, it redirects to this blog post! https://lnkd.in/eSQcwhD

Below we are going to prove that this unvalidated redirect method (OWASP A10) can be used to deceive users and redirect them to malicious websites and malicious executable files by letting them think they are being redirected to Linkedin.

>> Responsible Disclosure: Before I start describing the issue I would like to mention that I followed LinkedIn's policy on reporting vulnerabilities process to the letter (responsible disclosure) and reported the issue exactly as it is described in this page:

After sending a detailed description of the issue (on 27/May/2015), I received the following reply from Linkedin.

Thank you for contacting us and sending us your writeup.

We do perform validation for third-party links that users submit to LinkedIn, checking the destination for inclusion on malware and safe browsing blacklists. The hash you observed is used for that purpose. 


Regarding unwinding of our short links or obfuscation, URL encoding is working as expected and the depth of third-party inspectors is not something under our control. Note that some of our redirects use JavaScript, so they may not be capable of analyzing the content. Those redirects also clearly show an interstitial that a redirect is occurring.

If you believe we have misinterpreted your report, please let us know.
Thanks!

[name of responder not being disclosed]

LinkedIn House Security

From my point of view, Linkedin did not understand the extend of the issue I described. So, I replied to that person giving him a couple of examples why I believe this unvalidated redirect "feature" doesn't seem to be working as "expected". Simply because, it can redirect/trick/deceive users into downloading malware and/or visit a malicious website, while under the impression they are being redirected to Linkedin instead. So, my reply to Linkedin response was the following:

Thank you for your prompt reply. 

I understand that you do perform validation for third-party links with various ways but this doesn't stop a 

malicious person from using/abusing this redirect feature/method. It will still allow him/her to propagate a Linkedin URL which can point to a malicious website / malicious file. 

Please consider this example: If I upload unknown malware to the site I used in my example in the report (a zero day 

issue for a browser which hasn't been picked up by the A/V community or hasn't been blacklisted just yet), I am pretty sure that the link will keep working until that particular website or malware file is actually flagged by an A/V. If a website or a malware file is capable of evading AV detection and hasn't blacklisted yet, why would you deny access to it??? Thus, the redirect feature will work like a charm in favour of the fraudster who is trying to propagate his malware file. Despite my above assumption, I actually tested it using known malware, and the redirect feature worked fine.

Consider the NitlovePOS malware that was discovered just a couple of days ago, which used phishing emails to spread pretending to be job inquires with attached CVs. Now imagine using this redirect feature through Linkedin along with that. In that case it would be ideal for the fraudsters purpose. 


I pointed the link I described in the report to an executable file and it worked fine! (downloaded directly) 

I also, pointed it to the actual nitlovepos executable and downloaded it without a problem, even thought VirusTotal is reporting the exact same file with: Detection ratio: 21 / 57
https://www.virustotal.com/en/file/792915c911e89c74df06ff04cdb8b3572693b535dea7156a997f245d9d10d79a/analysis/1432745058/

According to OWASP this is the whole point of the A10 security risk. To address these unvalidated redirect issues which can trick/deceive a user about the origins of a URL


Consequently, a URL which points to Linkedin but it actually redirects to a different website or to an executable file, is actually considered a security risk highlighted by OWASP. 


If you still believe that this is the intended behaviour of the redirect feature on the Linkedin website and this is not a security issue I will not pursue this with you any-more and I respect your opinion, and I would like to thank you for your time looking into this. 


However, if this is not a security issue from your side (Linkedin) I would like to be allowed to publish this on my blog and twitter.


Kind Regards, 
Greg 

Long story short, the above email says that it is possible for anyone to abuse Linkedin's redirect "feature" in order to spread a URL which even though it seems to be pointing to Linkedin, it can actually download any malicious executable or take the user to a malicious site. Also, as you will read below it is not possible to know in advance where the link (URL) is really pointing to, unless we actually visit the URL. 

Without any further due, I will introduce you to the issue I raised with Linkedin and allow you to come to your own conclusions. I have also included proof that it is not possible to dig/preview the redirected URL before actually visiting it. I also tried to use online services that supposedly are able to find where a shortened link is pointing to, but as you will see the end result seems to be pointing to Linkedin instead of the actual malicious file/web site the URL is redirecting the user. As you probably already realised is about an unvalidated redirect found on Linkedin (OWASP A10). Yes, the test URL you see in the examples (unhackable.eu) is a test domain I own for testing web stuff. 

>> For your consideration: 
Due to the fact Linkedin in their response did not consider this to be a security issue, I mentioned in my email to them that I will publish this on my blog. 
So today, (28/June/2015), a month after I disclosed the issue to Linkedin, I am making this public. I believe that Linkedin should have taken a closer look at this, as it can be easily abused and used to spread malware, e.g. the same way NitLovePOS was spread through attached URLs in fake resumes. 
Some people may say that an unvalidated redirect might not be a such a serious issue. However, when you do no checks at the back-end which allow the redirect to point to malware (known malicious executables), then I believe this should be treated more seriously. It is up to you to decide and share your thoughts if this should have been treated more seriously. 


1. Introduction to the issue. 
According to the Open Web Application Security Project (OWASP) Top 10 list, “Unvalidated Redirects and Forwards” is number ten in the security risks list. While I was updating my profile and more specifically my list of projects, I noticed that a redirect link is being generated for the Project URL. (Figure 1.1)
Figure 1.1 – Adding a new project to my Linkedin profile 

As you can see in Figure 1.1, I then added a new project as test and in the Project URL text box I entered the web address http://www.unhackable.eu in order to be able to demonstrate the issue. 
Once the project is saved a redirect URL is generated, for this particular Project URL. In this case the URL that was generated was the following:

http://www.linkedin.com/redir/redirect?&url=http%3A%2F%2Fwww%2Eunhackable%2Eeu&urlhash=gqk5&trk=prof-project-name-link


Before continuing, let me point out at this stage, that I did notice the four characters validation hash  added to this particular URL I entered (highlighted in yellow above). Obviously, the four character hash does not allow the use of the redirect link to work for any other URL entered, if the relevant valid hash is not given. Consequently, in order to generate redirects on demand for any custom URL, we would have to crack the salt key being used for generating the four character hash codes. 

However, the use of the four character hash is only a small restriction. Using the “Add a Project” section on Linkedin, we can get (generate) the four character hash for any URL that we want Linkedin to redirect a user to. Once we know the four character hash by adding a new test project, we can then delete the newly added project. The generated hash works fine even after the project is deleted, allowing the Linkedin redirect functionality to be used (abused) as anyone pleases. Assuming that a malicious user wants to spread malware with an unvalidated redirect pretending that the link is pointing to Linkedin, the following steps can be used.


2. How to create an unvalidated redirect link that seems to be pointing to Linkedin.
Following to the alluded, let’s assume that a malicious user wants to redirect users to the following URL (http://www.unhackable.eu) using Linkedin’s redirect functionality. 

The malicious user will have to add a new project on any Linkedin profile they have access to. Once a new project is added that includes a “Project URL”, the relevant redirect URL is generated containing the four character validation hash as well. As it is illustrated in Figure 2.1, the project is added to the list, it is called test, it has a description text containing the word test and the heading is a link that points (redirects the user) to http://www.unhackable.eu through the generated URL:

http://www.linkedin.com/redir/redirect?&url=http%3A%2F%2Fwww%2Eunhackable%2Eeu&urlhash=gqk5&trk=prof-project-name-link


Figure 2.1 - A newly added project that redirects the user to a custom hypothetically malicious URL

In order for a malicious user to hide where the URL is actually points to, they can URL encode the visible characters of the URL (highlighted in green). Consequently, the URL will look like the following URL and it will still work:

http://www.linkedin.com/redir/redirect?&url=%68%74%74%70%3A%2F%2F%77%77%77%2E%75%6E%68%61%63%6B%61%62%6C%65%2E%65%75&urlhash=gqk5&trk=prof-project-name-link 

Keep in mind that this step proves that URL encoding works with the existing four characters hash that we generated for the http://www.unhackable.eu URL in the first place (highlighted in yellow). 

When this URL is posted on Social Media, the engine behind them often tries to resolve the URL in order to provide a preview. Consequently, further steps in hiding the redirect need to be taken. In order to do that we can use at first the google shortened URL service, goog.gl

Effectively, the original link http://www.unhackable.eu becomes http://goo.gl/pT2pbf and now it can be used as a project URL in order to be converted to a redirect link with the relevant valid four character hash.

http://www.linkedin.com/redir/redirect?url=http%3A%2F%2Fgoo%2Egl%2FpT2pbf&urlhash=114z&trk=prof-project-name-link


The next step is to use Linkedin’s URL shortening feature by posting the above link as a status update only for a second. Effectively, the above URL will be shortened and become:
https://lnkd.in/eHZK3i9

Once again, we use the project’s page and we create a new test project using the shortened URL we just generated. The project page will provide us with the new redirect URL as shown below, along with its valid four character validation hash. The shortened link is highlighted in green and the new validation hash is highlighted in yellow.

http://www.linkedin.com/redir/redirect?url=https%3A%2F%2Flnkd%2Ein%2FeHZK3i9&urlhash=-s5q&trk=prof-project-name-link

At this stage, we can post the link wherever we want without worrying about a preview relating to where the URL is pointing, being shown. In the following figure (Figure 2.3) it is illustrated that sharing an update on a user’s profile on Linkedin will generate no preview for the link that was shared. Also, a new shortened Linkedin URL (https://lnkd.in/ePiWHeT) will be generated and it can be now shared on other social media as well. 

Figure 2.2 - Sharing a malicious link on a user’s profile on Linkedin or other Social Media

The interesting fact is that everything shows that the URL is pointing to Linkedin. This is true even for those users who will try to reverse the shortened link using online services that can do this for them (see below). 


3. Further proof
As you can see in the following figures, it is not possible for several online services that do reverse shortened URLs (at least the ones I know of and tried), to identify where our redirect is actually pointing to (it should find the original URL given: http://www.unhackable.eu). 

Using http://longurl.org:
Figure 3.1 – longurl.org

Using http://www.getlinkinfo.com:
Figure 3.2 – getlinkinfo.com

Using http://www.knowurl.com:

Figure 3.3 – knownurl.com



You may try more online services that can reverse shortened URL but I couldn’t find any that would actually tell me where this link is actually pointing to. I only got them showing me that the URL points to Linkedin, and for that reason it is highly possible for this URL to be trusted and fool experienced users as well



Last but not least, as proven earlier on, URL encoding can also be used in order to make sure the URLs being generated are less easily read. 



I hope you find the information in this document useful and Linkedin decides to address this issue. Please, do not hesitate to contact me for any further clarifications or with questions you may have. 


If you would like to share your thoughts with me on this or ask me any questions, follow me on Twitter (@drgfragkos) and I will be happy to respond to any comments and suggestions you might have. Please, do share your opinion on the matter and of course if you believe that this is something Linkedin should treat as a security issue or not. 

1 comment:

  1. Thank you for this explaination. I’ve been reading the past week trying to figure out how invalidated redirects work, in general. I now have some understanding. I might be able to write my report which is due in 11 hours.

    ReplyDelete