MISC-45: Barclays Bank gives 3rd parties access to login page

I took a screencast of the behaviour to better explain it - https://videos.bentasker.co.uk/Player.html?url=2021/20210305_barclays_login_page/video_for_barclays.mp4.m3u8

Barclay's (very helpful) customer service agents passed my DM queries onto the web team, who unfortunately gave a less than stellar reply

They have said that the ad blocker could be causing the issues. Can you turn off all analytics using your cookie preferences, and then change your ad blocker to allow our online banking website and all other sites.

We use some additional sites such as (the http://we-stats.com that could be getting blocked) to help us protect and monitor your account.

That's very much the cause, but kind of misses the point. The request was that they adjust so that their page handles things sanely when those domains are blocked, rather than locking the tab up for 10-15s.

So, I've replied highlighting the issue, but also dug into this a bit more.

we-stats.com has a negligible discoverable presence - they don't have a site announcing who they are at www.we-stats.com for example. Already a shady look.

A bit of digging around suggests they're owned by Biocatch (https://www.biocatch.com/) - a US based company.

BioCatch delivers advanced behavioral insights to provide global organizations with actionable intelligence so you can create a secure customer journey.

Essentially they profile the hell out of your usage to try and build a profile and discovered when someone else logs in as you.

However,

- I can't find reference to Biocatch or we-stats in Barclays GDPR statements (I'm willing to accept I've missed it somewhere)
- Biocatch don't have a GDPR statement, they've simply published a contact (https://www.biocatch.com/data-protection-contacts)

Which in terms of GDPR compliance, all seems a little bit suspect.

Barclays confirmed this

Thanks for getting back to us again Ben. The team have advised the tool that we use (the http://we-stats.com that you're blocking) builds up a behavioural biometric of your use of online banking, and so if anyone else ever tries to access his login, that tool will help to spot and block them. ItÂ's all there for your protection.

Whilst the tool is (obviously) well-intentioned, the way it has been deployed is still extremely problematic.

It's used on login pages - pages where users enter shared secrets (in Barclays case, passcode and parts of the memorable word - also the userid, but that's not a secret). A compromise of we-stats would mean that that information becomes compromised.

History has shown that these compromises can, and do happen.

Barclays as a bank, are presumably fairly familiar with magecart - https://www.techrepublic.com/article/magecart-attack-what-it-is-how-it-works-and-how-to-prevent-it/ - where attackers managed to compromise "legitimate" sources to inject arbitrary JS and steal credit card details. It's exactly that sort of attack that's problematic here, the credentials being entered potentially give direct access to a user's bank account.

Supply chain attacks aren't new either, in fact, there's even one in the news at the moment - the Solarwinds compromise: https://www.politico.eu/article/solarwinds-largest-cyberattack-ever-microsoft-president-brad-smith/ - a compromise of an important point in the supply chain has yielded access to Government and business systems alike.

According to their website, Biocatch's core customer base consists of

- Banking
- Insurance
- Payments

Which likely makes them ripe targets for attack. It's reasonably easy to find on the net that Natwest and Halifax have both used we-stats in the past, so a successful compromise of Biocatch's systems could affect a sizeable portion of the UK userbase.

A simple route to mitigation, of course, would be to only use we-stats once a user has passed the initial login stage.

Whilst that'd still be problematic if compromised, it would at least prevent an attacker from quietly collecting credentials for later use/re-sale.

Essentially, there's the thing I want fixed, and there's the stuff that really they should fix in the name of security/compliance

The thing I'd like to see fixed is:

- Gracefully handle we-stats not working rather than locking the tab up

The bits that Barclays really should fix though is

- Remove we-stats from the login pages and only use once authentication has passed (but, again, be graceful)
- Update the GDPR statement (or make it more easily discoverable)

Unfortunately support haven't been able to arrange direct comms with the web team to explain this properly, so I've asked them to ping a link to this ticket across instead.

Oh, and just for avoidance of doubt, I did check - the ip the domain resolves to is in MS Azure Amsterdam, so they're not shipping data out of the EU (or at least, not directly).

Looks like Biocatch is actually Israeli rather than American, not that it makes much difference, it's still an undisclosed 3rd party.

A quick deobfuscation of the calling JS (embedded into the anchor page itself) shows there's quite a complex implementation in there. They even seem to have included Pako (a javascript zlib implementation).

Looking in the ublock log, the filter list blocking this domain is EasyPrivacy (https://easylist.to/index.html)

||we-stats.com^$3p

If we look at a blame of the source - https://github.com/easylist/easylist/blame/master/easyprivacy/easyprivacy_trackingservers.txt#L2780 we can see it's been there for about 2 years having been added in https://github.com/easylist/easylist/commit/5ddc7f37e277f39b31a1c8b9969dd94a5acdc7cb

I wonder if they've been screwing up the login flow for 2 years then...

Not unsurprisingly, the Barclay's banking team bounced the issue again

So, we've heard back from the team Ben -- so, the team have reiterated that the tool that we use (the http://we-stats.com that you're blocking) builds up a behavioural biometric of your use of online banking, and so if anyone else ever tries to access his login, that tool will help to spot and block them.

Which, again, ignores the points that

- I don't want that
- I haven't consented to that (it's not in their GDPR statement, at least in an easily findable form)
- The benefits of that are quite clearly outweighed by providing a means for a third party to collect login credentials
- Arguably, any good programmer/PM should be concerned that they're locking up a tab because of an easily predictable circumstance (if we-stats.com has an outage, are they just going to hang all their customer's tabs rather than fix this?)

This has become a bit of a dog-with-a-bone thing now, so I've fired a complaint in

Hi,

I'm logging this complaint following an attempt to resolve/highlight it via your Social media team. The SM team were very helpful, but the online banking team were being fairly obstinate and wouldn't engage directly.

Barclays are actively putting user login credentials at risk by requiring third party resources on the login page. Barclays is using a service provided by Biocatch (with the endpoints hosted on we-stats.com) in order to perform biometric profiling of users for fraud prevention purposes. The codebase is able to access/collect any interaction with the page, up to and including credentials.

Barclays also do not appear to have made allowances for this in the GDPR statement, and so do not appear to have established a legal basis for this processing.

For security (and privacy) reasons, my browser blocks known trackers/profilers including we-stat.com. Because the profiler integration is badly implemented on Barclay's pages, this leads to the browser tab locking up for around 10s. My original request was that Barclay's fix their codebase so that it handles exceptions gracefully rather than hanging the worker, but the backend team unfortunately chose to insist that I'd need to unblock the resource instead.

Biocatch's service goes out of it's way to hide it's true origins - the domain we-stats.com is used for profiling only, there's no informational page disclosing who/what they are. That hardly engenders trust.

There's a fuller writeup here - https://projects.bentasker.co.uk/jira_projects/browse/MISC-45.html - of the security concerns around using 3rd party resources on login pages.

In terms of resolution, the preferable route would be for Barclays to not use the profiler on pages where credentials are entered. However, I'd also find it acceptable if Barclays were to fix their implementation so that the page/tab does not hang when the endpoint is blocked by an ad-blocker.

There's a char limit on the complaint form, so had to try and keep it fairly brief.

As a hit of final irony, they locked up the complaint form with the we-stats.com shenanigans

Closing as Won't Fix - Barclays aren't interested in sorting this out.

I've now done a writeup on this: https://www.bentasker.co.uk/blog/security/732-uk-banking-protecting-you-by-exposing-you-to-risk