Skip to main content
compromising-us-banks-with-third-party-code-cover

Compromising US Banks with Third-party Code

Online banking services of major banks in the US can potentially be compromised through third-party services. Banks are including JavaScript code from external sources controlled by someone else. This practice opens up the possibility of stealing online banking passwords, diverting payments or draining bank accounts.

The Weak Link is Third-party Scripts

Large US banks allow their customers to log into their online banking services straight from the main page. This improves customer experience because they are not required to click and navigate to a separate login screen hosted elsewhere.

Login screen on the main page of Capital One

Modern websites tend to integrate third-party services like Google Analytics for measuring user behaviour, tracking users, or pushing ads. To integrate these services, website admins are typically required to include JavaScript from a third-party domain using <script src=””> tags.

Banks are no exception, as they also want to understand their customers better, so they also integrate services. For instance, Capital One includes a JavaScript snippet from Ensighten (an analytics and marketing tool) on their main site.

Third-party asset at Capital One

Unfortunately, third-parties, in general are granted full control over the customers’ online banking sessions. As banks include third-party controlled code on the login screens, it undermines the security of the online banking service.

Hacking Customers with JavaScript

As a consequence, malicious code from a third-party service can remain persistent throughout the session, and manipulate the full interaction between the bank and the customer.

Malicious JavaScript payloads can log keystrokes, take screenshots, steal data from HTML forms, steal cookies. Browsers can be hooked up as zombies with BeeF. Injected code can also be used for delivering exploit kits for delivering banking Trojans like Dridex.

Standard bank security solutions do not remediate the situation. Two-factor authentication, text message confirmation and other techniques are ineffective because third-parties are granted access to the DOM of the visitors’ browser.

To make this worse, this type of attack cannot be detected on the server side, as everything happens on the client side.

Third-party Trust Issues

But why would any third-party compromise a bank through JavaScript, you may ask?

Normally, they would not, of course. But what happens when a third-party gets compromised? A potential attacker may find infiltrating a third-party much easier, than the bank itself. In other words, the bank may have maximum security while the third-party leaves a backdoor open.

For instance, BB&T Bank utilises a service from Silverpop for marketing automation on their website. This particular third-party was hacked a few years back, which could have allowed the attackers to get to the bank as well.

Major US Banks are Affected

Rainbow and Unicorn has assessed websites of major banks in the US. Reports from sritest.io reveal that 9 out of 21 major US banks are including third-party controlled JavaScript snippets.

The following image shows the number of external assets included on online banking login screens of popular banks in the States.

number-of-third-party-assets

As the diagram shows, third-party scripts are hosted by third-parties such as Maritz, Webtrends, AdWords and Adobe DTM.

Now let’s group the banks by third-parties:

third-party-assets-and-banks

As the table shows, the marketing tool from Ensighten alone powers four big financial institutions. In other words, a hacker can compromise four banks by hacking just one third-party service.

Protect Online Banking

There are two possible solutions to remediate the problem:

One is moving online banking login screen onto dedicated web pages. These pages shall not include scripts or other assets from any third-party.

The other is adding subresource integrity (SRI) protection to third-party assets. In this case, the bank assumes the third-party is trusted. However, SRI protects the site’s visitors from unexpected asset changes in case the third-party gets compromised in the future.

As an online banking user, your can protect yourself by installing NoScript, ScriptSafe or a similar plugin. Just keep any third-party JavaScript code disabled that is unrelated to the bank.

Summary

Online banking services of some of the major banks in the US include third-party JavaScript assets. Unfortunately, third-parties are granted full control over online banking sessions because of this practice.

In case a third-party gets compromised, it allows the potential attacker to modify transaction details or drain bank accounts by changing the third-party JavaScript code.

The solution is either moving online banking login screens to dedicated web pages without any third-party asset included. The second option is using subresource integrity (SRI), which can protect the integrity of third-party assets.

The detailed reports used for the assessment are available here; a summarised report is found here. Image courtesy of bngould291.

Update (18/02/2016): Coverage on Softpedia

Update (20/02/2016): Coverage on Liquidmatrix Security Digest Podcast

Share on LinkedInShare on FacebookTweet about this on TwitterPin on PinterestShare on Google+Share on RedditFlattr the authorEmail this to someone
Share This Post!

Gabor

Creator of privacyforjournalists.org.au and sritest.io, organiser of @CryptoPartySyd, privacy and infosecurity enthusiast | Threema: PRN7228A | PGP: https://keybase.io/gszathmari