JavaScript Analytics Code Can Be Used to Compromise US Banks

[Inga Goddijn <inga () riskbasedsecurity com>]

http://news.softpedia.com/news/javascript-analytics-code-can-be-used-to-compromise-us-banks-500477.shtml
9 out of 21 major US banks load third-party JavaScript analytics code on
their login pages, exposing users to attacks

*Hungarian security expert Gabor Szathmari has analyzed the login pages of
21 major US banks and found that 9 load third-party JavasCript assets,
exposing users to unnecessary dangers.*

Theoretically, bank login pages should be the safest places on the
Internet. In practice, they are far from being so, and there are multiple
reasons this happens.

As Mr. Szathmari has discovered in his research
<https://blog.gaborszathmari.me/2016/02/11/compromising-us-banks-third-party-code/>,
some US banks fail to protect this page and unwittingly load JavaScript
resources from third-party sites.

But loading JavaScript files is not a problem, since websites need
JavaScript files to work properly these days. The danger relies in the fact
that some of these files are stored on another company's server.
Hackers should focus on compromising third-party analytics services

If that company gets compromised, attackers could very well alter these
third-party scripts and deliver malicious code, which is executed right on
the bank's login page.

And the danger is real because something like this has already happened in
the past. SilverPop, one of the companies whose scripts are loaded on the
login page of BT&T, a US bank, was hacked in 2010
<http://krebsonsecurity.com/tag/silverpop-systems/>.

In that incident, hackers only compromised its email automation software.
Imagine if this incident repeated today. Do you think the hackers would go
after their email software, or would try to compromise the JavaScript code
loaded on bank login pages?
* Analytics services and where they're deployed*
[image: Analytics services and where they're deployed]
<http://i1-news.softpedia-static.com/images/news2/javascript-analytics-code-can-be-used-to-compromise-us-banks-500477-3.png>

The answer is simple because Web-based exploits have become more prevalent
in recent years. Thanks to many new HTML5 APIs, malicious JavaScript code
now allows you to log keystrokes, steal data entered in forms, take
screengrabs, steal browser cookies, and even communicate with Flash to
exploit many of its security loopholes.
Third-party analytics services are a backdoor left wide open

A simple analytics script can break down a bank's complex security policy.
No matter how many multi-million dollar deals banks sign with
cyber-security vendors, by continuing to allow third-party analytics code
to load on login pages, or even the user's banking dashboard, banks are
leaving a backdoor wide open to attacks, thanks to their analytics provider.

As Mr. Szathmari explains, the solution is quite simple. Removing analytics
code from these pages is the quickest way to neutralize the threat.
Additionally, implementing *Subresource Integrity (SRI)* is also another
way to allow these scripts to load but remain safe in case the third-party
service gets compromised.

Despite not being supported in all browsers, W3C's new SRI specification is
already the darling of many security experts. GitHub has even gone forward
and *implemented it on its website*
<http://news.softpedia.com/news/github-implements-subresource-integrity-to-better-protect-itself-from-xss-attacks-492142.shtml>
.

A browser that interprets a page's code where SRI has been implemented will
be able to tell if the third-party asset was compromised or altered. SRI
does this by using cryptographic digests to analyze the JS or CSS it
received from a third-party to an expected content payload. In case the
third-party was compromised, SRI will block rogue resources from executing
in the browser.

Mr. Szathmari is also the man behind SRItest.io <https://sritest.io/>, a
website where users can scan websites for Subresource Integrity (SRI)
cryptographic hashes.

_______________________________________________
Dataloss Mailing List (dataloss () datalossdb org)
Archived at http://seclists.org/dataloss/
Unsubscribe at http://lists.osvdb.org/mailman/listinfo/dataloss
For inquiries regarding use or licensing of data, e-mail
        sales () riskbasedsecurity com 

Supporters:

Risk Based Security (http://www.riskbasedsecurity.com/)
Need access to data breach details or alerts when new breaches happen? Risk Based Security's Cyber Risk Analytics 
portal, fueled by the RBS breach research team, provides detailed information on how data breaches occur and which 
vendors to trust. Contact us today for a demo.