Phishing++ – Chapter II

Stay tuned on FogMarks

Hi! Long-time-no-case-studied.
I know, I know, this chapter was supposed to be released two weeks ago, but we waited for PayPal‘s official permission to disclose this two vulnerabilities before even starting to write the case-study (why? Read our about page).

So, finally – PayPal kindly allowed us to disclose two HTMLi/XSS vulnerabilities they had in the last summer, and that’s perfect because now we can show you a real life scenario that actually happened.
Before reading this, please make sure you fully read and understand the previous chapter. This is vital for this final chapter – its like you cannot start watching Breaking Bad from the second season (Although I know a guy who did it, because he was lazy downloading the first season. Weirdo.)

In the last chapter we talked about what companies can do to prevent 3rd party malicious phishing websites from using their HTML entities such as images, JS scripts and CSS style-sheets.
Today we are going to talk about the most dangerous & complicated Phishing attacks – phishing attacks that occur on the official website.

In the past, Phishing was super-easy. New internet users didn’t understand the importance or even the existence of an official domain. They were used to access their desired websites by a bookmark, by a mail someone sent them and later on – by Google.
Later on, Phishing became less easy. Companies started to warn their users from accessing their site from wrong sources like email messages or forum links. They made their users aware of the domain part of the browser’s window. And indeed, most users have adapted to these security precautions and now double-check the domain their viewing before making any action.

But no one prepared the companies for this new stage of Phishing attacks: Phishing on the official companies websites!Imagine that a malicious deceptive page is being inserted to the website under the official company domain.
A malicious file doesn’t have to be even uploaded – existing pages by the company can be altered by attackers – using XSSes, HTML Injections, Headers Injections or Parameter injections – and malicious content will be displayed.

Actually, there only one TV series about “Cyber” security I appreciate: CSI:Cyber. They presented this exact case of HTML Injection in their 10th episode of the first season.

Ok, now that we learned how to swim – let’s jump to the middle of the ocean.
PayPal suffered from two XSS/HTML Injection vulnerabilities which allowed 3rd-party malicious content to be added to official PayPal pages under the official ‘’ domain.

This allowed us to create some very nice Phishing templates, such as:

In addition, we were able to actually create a <form> inside a page, which allowed us to send the credit card data of victims to a 3rd party websites. Unfortunately, this demo was not allowed to be published.

I even created an online ‘Web Gun’ Content Spoofer which can inject HTML entities directly to a vulnerable page:

The fix
Actually, there is no easy fix. Haunting down vulnerabilities and paying attention to payloads that are being injected to the website pages – via GET/POST requests or via SQL queries (in case of a permanent XSS) is pretty much the best way to handle this threat.
XSS Auditors – like presented in PayPal’s case – simply don’t work.

Writing this 2-chapters sequel was very fun. Expect similar case-studies in the near future.
But till then,