May 2, 2016 · banking security breach xss csrf security headers mobile network 2fa 2sv two factor authentication two step verification theft sms halifax freedompop lloyds banking group

Bank & Mobile Network Security: For want of a nail...

Ever since publishing a "two factor authentication vs two step verification" article in 2014, I've been waiting for an opportunity to irrefutably demonstrate the difference.

Note: This article is very much a "work in progress" as until both exploits are patched, I can't provide any technical information.

A quick recap...

If you haven't yet read the above article, let's quickly recap on the differences between two-factor authentication & two-step verification.

A "factor" falls into one of the following categories.

1) Knowledge
2) Possession
3) Inherence

The lines between them however, become blurry when companies refer to SMS one-time passwords (OTPs) or calls as "two-factor" authentication.

Although you technically "possess" the phone, the OTP isn't generated by, nor dependent on the phone itself... but rather the code sent to it via the mobile network. I've long argued that despite NIST's statement to the contrary, SMS OTPs do not constitute 2FA.

So, let's dive right in.

Who are FreedomPop?

FreedomPop are the UK's first completely free mobile network provider; launching in September 2015.

Unsurprisingly, FreedomPop has grown rapidly to in excess of a million users, many of whom opt for the free 200 minutes, 200 texts & 200MB data plan.

FreedomPop's security... or lack thereof

At this point, I'd usually explain the exploit in detail but, mindful of not wanting to exacerbate the problem, stop short of providing a step-by-step guide. On this occasion however, the risk is such that any further information is likely to immediately place 1+ million users at considerable risk.

It is currently possible to remotely hijack any FreedomPop account, allowing both calls & messages to be made/intercepted by an attacker. No usernames, no passwords and no SIM swapping... just unfettered access to a user's communications.

Monetizing the exploit...

OK. We now have access to every call & SMS message to a user's device... how can we convert that into actual money?

Well, the user's contact list is probably a good place to start; a few quick texts to friends & family is likely to yield a few quid. Keep in mind, the messages are coming from the victim's own number.

That's all well & good, but what if we're not interested in a few hundred quid?

Hitting the bank

At first glance, this seems like a particularly crazy idea.

To successfully gain access to a Halifax account, an attacker would need the username, password & security pass phrase. Even armed with all this, they're unable to add a new payee without triggering further anti-fraud checks... in the form of an automated call to your registered mobile number.

The UK banking sector isn't particularly hot on security either, but that's still a tall order without tripping sophisticated anti-fraud systems.

Can we bypass the username, password & security pass phrase entirely?

As of the date of this article, it's possible to do just that.

Halifax don't offer a "Premier +" account, but would you have spotted the fake/malicious section of the page?

No security warnings, no outward signs at all that we're looking at a page controlled entirely by an attacker.

A serious (yet remarkably simple) vulnerability in the Halifax site allows an attacker to execute arbitrary & external scripts. This gives the attacker complete control over the victim's environment; changing links, buttons, text and crucially... perform actions as if they're the genuine user.

Thankfully, Halifax/Lloyds Banking Group have since verified this exploit, even bringing in external consultants to re-test & confirm their results.

Whilst we agree there's an issue, Halifax/Lloyds have (unsurprisingly) played down the risk, suggesting that other safeguards prevent unauthorised access to a user's bank account. One of those safeguards, of course, is the requirement to verify a new payee by contacting the victim's mobile number.

I've demonstrated one method of payload delivery and although it works, it's by no means quick or easily scaled. There's at least one other route too, but proving this theory means breaching the Computer Misuse Act and, given their propensity for threatening legal action, it's a step too far for an exploit I've proven by other means.

Let's not forget though, even a single, well-executed attack can yield a sizeable return. Remember Vivian Gabb?

Killing two birds with one stone.

Let's recap...

We control the user's mobile number.
We control the user's banking environment.

But, we still need to deliver & execute the payload in a manner which doesn't alert the user.


The fix for this exploit is due in 3/4 weeks, so until then, I obviously can't give any further details.

However, their failure to adopt even the most basic of safeguards means it's possible to fire both exploits simultaneously and directly on Halifax's own site. To make matters worse, the exploit takes place on the user's device; effectively shielding the attacker from the vast majority of anti-fraud checks.

Wider issues...

Let's be clear. An attacker is unlikely to hit your bank account first... the risk is just too high.

There are other low/no risk targets which could yield an equally high return. Your email address, as an example, provides access to virtually every account you own.

If you're sensible, you've enabled 2FA or 2SV on your email account; effectively preventing unauthorized access to anyone armed with just your password. It's also sensible to add a fallback number, if you ever lose access to your second factor... or is it?

Every fallback/revocation option provides a wider threat surface, each attracting their own set of security concerns. An immensely strong password is rendered useless by anyone with access to my email account. A Yubikey/Google Authenticator is rendered useless by the ability to bypass it via SMS. Instead, the crypto seeds which form the basis of my OTPs are backed up locally; encrypted and isolated from the outside world.

Thankfully, I've never lost my keys... but it'll happen one day. If you must use backups/fallback options, just bear in mind they're another door into your digital life.

If the attacker now has knowledge of your OTP, he has access to your supposedly "2FA" protected accounts. Keep in mind, 2 knowledge factors does not constitute 2FA either... but 2SV or two-step verification.

The attacker hasn't stolen something you "possess", thus it couldn't possibly be 2FA. It's undoubtedly stronger than just a password, but it's by no means comparable to true 2FA.


These exploits really are the lowest of the low-hanging fruit; detected by even the most rudimentary of security scans... but overlooking even the simplest of exploits can lead to much bigger problems.

In isolation, the issues at the Halifax do not appear to be particularly serious... though I'd question how such a basic flaw went unnoticed. When combined with other, equally simple exploits elsewhere, an attacker has a much wider window of opportunity to gain access to your communications & bank account.


Halifax/Lloyds Banking Group responded immediately, escalating the issue to the appropriate team for review. They later called to confirm the exploit, the steps they're taking to resolve it and their assessment of the risk. As our assessments differ, a partial publication seems appropriate.

FreedomPop however, are yet to reply.

24/03/16 - Tweeted FreedomPop. They replied asking for details to be emailed to [email protected] - Email sent.
24/04/16 - Identical email to [email protected] requesting a response.
25/04/16 - Email to CTO. No response.
27/04/16 - DM to FreedomPop asking for an update.
28/04/16 - Response to DM. "We've relayed your message, have a wonderful day"
01/05/16 - Publication. Further information to follow if they fail to respond.