What is Phishing 2.0 and which countermeasures can organisations use against it?

With all due respect to the countless victims it has claimed, Phishing 1.0 was never rocket science. They’re passive attacks – the victim needs to visit the fake site and put their credentials in themselves.

What phishing boils down to is tricking users in order to acquire their login credentials. Phishing 1.0 is all about tricking users into visiting e.g. www.paybal.com rather than www.paypal.com. In order to do that, the attacker simply creates a fake login page and dumps all the username/password combos that phished users enter into a database. There’s no need to interact with the real target site at all, and no deep technical understanding/feats are required.

The war against Phishing 1.0 is fought on four fronts:

1. Do not click on any ‘suspicious’ links
2. Check there’s a padlock icon in your address bar
3. Play ‘spot the difference’ when on your bank’s webpage
4. Multi-factor authentication (MFA, 2FA)

Phishing 2.0

Phishing 2.0 makes all of these mitigations obsolete. Phishing 2.0 is a far more sophisticated, far more evil attack.

Phishing 2.0 uses a transparent reverse proxy to mount a man-in-the-middle (MITM) attack against all users in the same network segment. Its ultimate goal is not to capture usernames and passwords – those are just collateral – but the keys to the kingdom: the user’s session token.

While MITM attacks are nothing new (Citibank was attacked way back in 2006!), lately highly automated ‘script-kiddie level’ tools, such as Evilginx2 and Modlishka, have become publicly available. I must admit that I’m quite impressed by the hard work and the technical accomplishments behind the previous sentence. In order for Phishing 2.0 to work, the tools need to intimately integrate with the target site(s) and therefore utilise deep, complex URL rewriting techniques in HTML content and JavaScript – and all in real time!

In Phishing 2.0, instead of a fake page created by the attacker, the victim sees the real and unaltered PayPal page in their browser – only that the page is served by a transparent proxy decrypting and re-encrypting all data in real time. As the tools will automatically acquire a valid TLS certificate, the URL bar will have the padlock icon, but still needs a fake domain like ‘paybal.com’.

In order to direct traffic to the proxy, the attacker sets up a reverse proxy on the same network, and routes all traffic through it via traditional ARP poisoning etc. While Phishing 2.0 sounds quite hard to mount properly, the current tools hide the technical challenges in a way that most UI designers would be proud of.

To reiterate, using contemporary toolkits, the technically demanding Phishing 2.0 becomes Phishing for Dummies. There is no need to hand craft real-looking sites and e-mails. Script-kiddie level automated tools are freely available and, to top it all, shared, untrusted networks are increasingly common (WLAN).

Once set up, the Phishing 2.0 proxy will transparently intercept passwords, 2FA access tokens and session tokens. The impact is tremendous. The user doesn’t need to click on any links to end up at the fake site. The phishing site is no longer a copy – it is the real site, just accessed through a relay. There is no natural protection from using exotic languages like Finnish, so relying on the ‘spot the sketchy Google-translated sites’ offers no protection. As the site looks absolutely identical and shows the padlock on the address bar, it gives the victim a false sense of security.

SMS OTP, mobile authenticators, everything that the user puts in is intercepted by the attacker and stored for future use.

Pre-emptive attacks

In addition, stealing the session tokens opens up the possibility to mount pre-emptive attacks.

Pre-emptive attacks abuse the trust relationships between Identity Providers (IDPs) and the services that consume identities. By capturing the user’s session token, the attacker can then act as them. The actual attack can therefore be described in four parts:

1. Steal user’s session token from a single service (for example, Office 365)
2. Register to all other services accepting that token
3. Wait for the real user to start using them
4. Profit

Countermeasures

Ineffective countermeasures

The countermeasures deployed against Phishing 1.0 are not effective against its successor.

Educating users to spot website differences can lull the victim into a false sense of security, as the victim is connected to the real website – just through a relay. Any MFA relying on user input will be intercepted by the proxy.

Forced 2FA re-authentication for every transaction only protects against persistence and, speaking from personal experience, is highly annoying from the end user perspective.

Effective countermeasures

In order to raise effective defences against Phishing 2.0, it is important to keep in mind that the ultimate goal of Phishing 2.0 is not stealing the user credentials, but rather stealing the token.

Many contemporary web services will send a warning email if the account password or registered email address is changed, while very few will notify the user if the entire session is cloned. You can try this out yourself by logging in to a service and then copying the session cookie to another browser/computer and trying to access the target site. In the vast majority of cases, you won’t be asked to log in again, and neither would the attacker.

As I briefly touched on before, Phishing 2.0 is technically based on MITM, so the traditional defences against MITM are still effective. These include hard-fail certificate pinning and hard-fail 2-way TLS.

However, the devil is in the ‘hard-fail’ part. Are you willing to make your business-critical app hard-fail? Will you be the one to make sure that your mobile apps are on a hairline trigger? There must not be any way to click through any discrepancies detected during the TLS setup – no stern warnings, no long string of dialogue boxes. Your service must simply be inaccessible if anything appears to be not in order.

It seems logical for browsers to block MITM attacks, or at least strongly warn their users that their private data is being intercepted, and to do their utmost to prevent it in the first place. Although, even if this were easy to do in practice, it’s not going to happen anytime soon.

Why? All of the major browsers – Chrome, Edge, Firefox, IE and Safari are designed to allow transparent MITM attacks against their users, because all the browsers cater to business owners first, and end users’ privacy second. Hardware and software solutions that mount MITM attacks against all users of the network, such as Zscaler and CheckPoint, are commonly used in big markets like the USA. Any browser that would not allow such attacks would simply be banned from the tens of millions of corporate devices.

Interestingly, Mozilla held a trial to detect MITM by comparing the certificate presented to the browser to certificates presented to other users around the Internet. Any discrepancy would cause an alert to be displayed to the user. It worked – but the trial was terminated quickly. This was because in addition to alienating big corporations and breaking local MITM-performing virus scanners (which do more harm than good), the trial by design lets a third party know all the TLS-protected domains visited by the user. As Lord Acton stated in the 19^th century, knowledge is power and power corrupts – absolute power absolutely. On the other hand, people are increasingly accustomed to letting a single third party both record and screen parts of their digital lives – and even pay for the privilege! Witnessing the sustained quarter-to-quarter growth of walled gardens like the iOS App Store indicates that screening by a third party is not only possible, it can be profitable.

A frequently resurfacing idea of utilising WebRTC to double-check browser IP address from the server side is a doomed endeavour, even without the now all-persistent Network Address Translation (NAT). But recall that Phishing 2.0 is nothing new, despite the new name.

Phishing 2.0 is a dangerous foe, but it is not indomitable. There is a simple cure – move to an authentication standard immune to Phishing 2.0.

FIDO (Fast IDentity Online)

FIDO is an acronym for Fast IDentity Online, an alliance formed in 2013 by big players such as PayPal and Lenovo.

FIDO U2F (Universal 2^nd Factor authentication) is an open standard that utilises a hardware authenticator. The remote website accesses this device directly, providing a passwordless experience.

The YubiKey USB devices are examples are U2F-compliant hardware authenticators. The U2F protocol is designed to take the website’s domain as one of the key components, and authentication will simply fail if the domain in the browser’s address bar doesn’t match the domain talking with the U2F device. It’s already in use by Dropbox, GitHub, Facebook and Google. Before 2017, all 85k+ Google employees used their own mobile authenticator for logging in to their internal services. The exact numbers aren’t public information, but successful phishing attacks did still occur.

After moving to U2F, not a single Google employee has been successfully phished.

For a longer introduction to FIDO, check out our other blog here.

To discuss using FIDO for your customers, get in touch!

 

Other useful links:

https://fidoalliance.org/specifications/

https://krebsonsecurity.com/tag/u2f/

https://www.troyhunt.com/beyond-passwords-2fa-u2f-and-google-advanced-protection/