14 DAY TRIAL // LinkedIn has fixed a security bug on its platform that would have allowed attackers to redirect the site's visitors to malicious Web pages.
On the technical side of things, the clickjacking bug is quite easy to reproduce for any low-skilled developer, but LinkedIn's security team was surprised to find how it was used on their platform.
Clickjacking via CSS, old technique, new method of employing it
The person that discovered the bug is Ruben van Vreeland from BitSensor, who informed LinkedIn's team of the bug earlier this year, providing instructions on how the attacker could take advantage of CSS code already hosted on the platform to exploit the bug.
As LinkedIn explains, their platform allows users to publish articles in the form of blog posts. These blog posts, in particular, can be generated via a JSON request sent to their servers, which contains the article's HTML content.
To allow an author's creativity to roam free, LinkedIn also lets users style the content inside those blog posts by inserting links and other HTML formatting tags.
As you'd expect, the HTML tags that make up each blog post are heavily filtered and sanitized for unwanted content that may be abused to launch various types of attacks, from XSS to CSRF.
Mr. van Vreeland's attack is based on the fact that LinkedIn allows the HTML tags used inside blog post to load CSS classes. These CSS classes do not load the attacker's CSS code of choice but load CSS classes from LinkedIn's own stylesheets. Since LinkedIn is a massive platform, its CSS files contain hundreds of classes that can be indirectly loaded via this method.
The clickjacking code was actually hosted in LinkedIn's CSS files
Van Vreeland discovered that, by loading a specific class on anchor links (< a >, URLs, links), he would be able to expand the link area to cover the entire page. The particular class was included with one of LinkedIn's stylesheets to allow clickable content to automatically adapt to the page's width and height.
While that particular class (.li_style) was applied by LinkedIn's staff to links under their control, using Mr. van Vreeland's method, attackers that created blog posts via JSON requests would have been able to use it as well. The result was a blog post page that contained malicious links that expanded their target, clickable area, to the entire page.
If the user loaded that particular blog post and then wanted to navigate away from the page, they would have no way of escaping without clicking the malicious link first (technically, they could close the tab from their browser, but users aren't generally aware when pages contain malicious code).
This way, LinkedIn users could have been redirected to malicious pages, where other attacks could have been carried out (e.g. phishing, exploit kits, etc.).
Even if Mr. van Vreeland did not disclose this issue via LinkedIn's bug bounty program, the company invited him to join the program so that he could be rewarded for his work.