Why Clickjacking is bad and some pentest firms are wrong

I work with a far few ladies and gents who do bug bounties and while sitting on the beach during one of our hack on the beach sessions, I posed the question “How friggin evil is clickjacking, PoC or GTFO.” The challenge was set, and here is what we decided.

What we really need is a credit card company in 2019 that has a clickjacking vulnerability on their web portal. Thankfully, I actually have a card issued by S*************. I know they have a clickjacking vulnerability, despite informing them of it. For the ultimate challenge, I would open a link sent by each tester and if it passed the sniff test I would perform a £10 transfer transaction. Could they intercept it?

Apparently there is no risk, according to one big pentesting and bug bounty firm.

Clickjacking = get riCH quick scheme.

A bold statement. 5 seasoned penetration testers. 1 attack vector. 4 attacks that passed the sniff test and all £500 of stolen money. How?

Step 1 - The Web Server

To start with, what we needed was a visually similar domain name. A few were located and webservers sets up on them with valid SSL certificates. To make the journey really convincing, an email server was also set up to send and receive emails. This section is really important as it will carry the attack.

Step 2 - The Illusion

This is where the attackers html, css and javascript skills really come into play. Loading a website into a full width iFrame is easy. A 4 year old can do it. Now we add in two critical elements:

  1. Javascript glass pane

  2. Keylogger

It is possible to just use the second and keylog the entire session, but points were added for evilness. Of course, we are not going to put in here the actual code used but it took less than two hours to get the snippets from google, so enjoy that.

2.1 - Javascript Glass Pane

The purpose of the glass pane is to separate the victim from the end site. This is very literally a man-in-the-middle attack against the user. By tracking the mouse positions and clicks, it was possible to build a database of possible positions and inclinations essentially mapping the user journey.

Now came the evil part. When ever the user entered what looked like an account transfer, the end account number and sort code was entered as the attackers, not what the victim actually thought. Anything returned on the screen was masked by a <div> that showed what the victim would have expected to see. The amount remained the same.

2.2 Keylogger

With a transaction identified, they keylogger could now replay the same transaction a few times before the user logged out. Even if you user closed the browser window, it would still run until the session times out. The keylogger in this case reran the same transaction minus £1.50. If it succeeded, it would re-run it again, minus £1.50 and loop until the site logged out or returned an error.

3. The Delivery

Delivering the attack is really easy. Using URL shortening delivery via twitter, facebook and linkedin all works really nicely. We even managed to set up a PPC campaign on Google by copying the actual banks PPC campaign and using our urls.

4. Viable Targets

Who is at risk with this attack? Well, anyone who runs a transactional site that does not implement the header security, but good targets are:

  • Gambling sites

  • Cryptocurrency exchanges

  • Banks and credit card companies

  • All retailers (takes more work but still worth it)

Considering the remediation for this takes seconds, it is shocking that still we find sites who are vulnerable.