Another year, another batch of security issues at Santander.
TL;DR - Don't bank online with Santander. Don't send payments to any company which uses Santander as a payment gateway.
Today, we'll be looking at three areas of concern.
1. BillPay; the website allowing business and personal customers to make online payments.
2. Mobile Banking; both personal & business accounts at risk.
3. Security audits, or lack thereof.
Let's dive in.
Now, I've blogged about Santander before... so I set my expectations pretty low from the outset. Headland have appeared on the radar a few times too; associated with other sites which do not handle data safely. Think MachineMart, SnowDome (Tamworth) and Alton Towers.
Before entering any card details, I ran the site through a Qualys test.
Hmm. That's a good start!
What's insecure renegotiation?
If a server is vulnerable to insecure renegotiation, it's possible to carry out a MiTM or Man-In-The-Middle attack; allowing a hacker to inject arbitrary content into encrypted data.
How about the certificates... they're installed correctly, right?
Now I'm worried! If you can't install an SSL certificate correctly, you really shouldn't be looking after a payment gateway.
Hang on... surely that means a mobile device will throw a warning?
Yep! It's a good job the native Android browser checks certificates properly.
Where do we start with this lot?
We've already ascertained it supports insecure renegotiation, but here we can see it doesn't support secure renegotiation. To add insult to injury, it doesn't support forward secrecy or session resumption and is intolerant to long handshakes, risky when it's only visible to browsers with SNI support.
Choosing a secure password is absolutely vital to ensure your account remains secure. Santander give the following advice...
Superb! However, it's equally important to store the chosen password securely too.
Why is there a maximum length of 50 chars? If Santander were hashing passwords correctly, there's absolutely no reason to restrict the amount of characters here. In light of recent mega-hacks... 152 million accounts stolen from Adobe, 850,000 from Stratfor, 453,000 from Yahoo and over 37,000 from Sony... surely Santander store passwords securely?
I tried to run a password reset. Please note: "reset" - widely regarded as the safest method of account recovery today. Instead, Santander offered to "remind" me. If they email my password to me, I may cry.
For this alone, I'd run a mile from any Santander / Headland product.
Catch 22 - BEAST vs RC4.
On the TLSv1 protocol, developers face a tricky problem which cannot be entirely resolved. You see, both BEAST and RC4 present a risk... and until recently, developers considered RC4 to be the lesser of two evils. Things have changed significantly however. New exploits have proven RC4 to be considerably weaker than we first thought... and updates to modern browsers render the risk from BEAST almost irrelevant.
As such, BEAST is now the lesser of two evils. Santander/Headland however, haven't moved with the times.
PCI Compliance - Who needs it?
As a corporate bank, you'd be forgiven for thinking the site would be payment card industry compliant... wouldn't you? Nope.
Cross Site Scripting - The thorn in Santander's side.
No, that's not the wrong image...
It's the HMRC payment gateway, hosted under Santander's BillPay website. As you can see, it's possible to inject arbitrary content here too. I've added the OWASP image purely to prove it's possible... but there's nothing stopping an attacker inserting a fake payment form, or indeed modifying the official one.
Secure? Pull the other one.
So, I raised it with Santander straight away.
The call which followed was bizarre to say the least. The responses ranged from the perfunctory "we use SSL" to "Call Halifax, it's their problem" and "That site is owned by HMRC, call them". I lost count how often I said I hadn't actually entered my Halifax card details yet, but still she continued to blame them.
Turns out, Santander gave me the wrong number! After much searching and many phone calls, I finally end up in the hands of Craig McDougall; a technical analyst at GeoBan UK, part of the Santander Group. He forwarded my comments to Headland and after a couple of weeks, I receive an email.
Great! I've checked the site since and although the XSS exploits have been patched, the SSL issues have not.
Check it yourself here: http://ssllabs.com/ssltest/analyze.html?d=santanderbillpayment.co.uk
By this point, I'm ready to chalk it up as another sorry Santander episode... but something appeared in my Twitter timeline which got me wondering...
Sounds great! A mobile app for both personal and business customers offering...
If "it's as secure as online banking", we're in trouble. Let's take a closer look.
I've installed both the personal and business banking apps... so let's fire up the personal version first.
Before I enter a fake User ID, I started Fiddler and routed HTTPS (ya know, that secure traffic that nobody can intercept!) through the proxy; essentially performing a MiTM attack on myself.
Wonderful. My User ID (and subsequently the password, if I went further) have just been intercepted.
How is that possible?
When you route traffic through Fiddler, it creates a fake SSL certificate which a secure browser/application should easily detect. Remember the warning we had earlier when trying to load the other site? We should see something similar here. After all, the fake SSL certificate means someone could be watching everything we type. A "secure" application would throw a warning or simply refuse to connect. Santander's "secure" mobile app however... assumes everything is safe and carries on regardless.
How does that apply in a real-world environment?
The common misconception here is an attacker would need access to your internal network for this exploit to work, but that simply isn't true.
A secure SSL implementation requires minimally two things... strong encryption and crucially, authentication. The encryption ensures the data cannot easily be decrypted without the key... but authentication ensures you're sharing the data with the correct party to begin with.
You'd never dream of giving your bank details to a random caller, purporting to be Santander... but that's exactly how this application operates! So if anyone in your network, internal or external (ISP, proxy, DNS et al) tells the app "hey, I'm Santander... send me the data instead", you're screwed.
What about the business banking app, is that safe?
Long story short, no.
As you can see, now we're talking to bb.santander.co.uk instead of m.santander.co.uk.
Unfortunately, it still doesn't check the certificate's validity and similarly, any data entered into the app can be intercepted & read by anyone.
Santander first appeared on my radar back in 2010 - with both XSS and SQLi issues which they eventually fixed. Since then, they've appeared at least once a year with a variety of dodgy security practices; all of which beg the question...
How useful/frequent are their security audits?
OK. Cards on the table... I've probably spent a good hour on this and I've barely scraped the surface. No automated tools, just basic manual checks which it failed miserably. If Santander have missed the basics, what else have they missed? Let's not forget, they provide a payment gateway for several high-profile web sites.
HMRC, Tiscali, E.ON, nPower, several council offices, Severn Trent Water... that's just a few. A full list is here: https://www.santanderbillpayment.co.uk/scripts/who.asp
Presumably the task of processing payments went out to tender for many of these firms... was an audit carried out to make sure it was safe, and if so, by whom?
What really concerns me is both Headland & Santander consider this to be "resolved".
If you can, avoid Santander like the plague. It's poorly designed, insufficiently tested and vulnerable to a wide variety of exploits. If you come across a site connected with Headland in any way, tread very carefully.
Remember to +1, Like or Tweet. Thanks!