The BECU vulnerability that might: External JavaScript from Typekit

BECU is the largest credit union in Washington State and the fourth largest in the United States with 971,328 members as of June 2016. Every day, nearly a million customers trust BECU to keep their confidential information and money safe. One of my professional interests is whether high-profile websites and applications follow the obvious security measures, and avoid taking unnecessary risk. Being in the security space, I’m very aware of the different attack approaches and can reasonably evaluate whether a website or application I’m using is secure at the fundamental level. However, most people aren’t obsessed with technology and security, and are left with no option other to trust the companies who create it. Though over the years, I’ve found that websites and applications that any reasonable person would assume is as secure as possible, simply isn’t.

Often, I find that companies focus on the minutia in code and leave the big, highly exploitable issues open. The page handling password changes forces TLS and loads unique CSRF tokens, but that level of detail wasn’t implemented consistently, and they left the door wide open.

Banks and credit unions fall within the category of “they must have secured it as much as possible, and no unnecessary risks are being taken, right?” For that reason, I decided to take a look at BECU.

At first glance, BECU does a great job.There’s a painfully obvious EV SSL with strong encryption and key exchange. Cookies have the Secure flag and TLS is consistently forced across the entire website. The sessions are heavily restricted and expire within minutes of inactivity. Passwords are at least hashed and salted, password recovery is made as difficult as possible, and brute-force is made impossible due to limited failed attempts. Headers give no useful information and ports are properly restricted. CSRF and XSS are handled in textbook fashion. Behind the scenes, I assume there’s also a strong WAF and IDS/IPS.

But it’s not all perfect. Looking at the homepage source, I found this:

Screen Shot 2016-10-31 at 3.23.13 PM.png

That’s a Typekit embed code. Typekit is a subscription font service by Adobe. In short, it’s used to make the website look nice. It serves no functional purpose and is purely aesthetic.

What’s dangerous here is that BECU is using a third-party JavaScript file, and doing so is always risky because if compromised, malicious code can be delivered to BECU’s customers. Risk can be mitigated by using services with security that most companies couldn’t begin to match even if they self-hosted, such as Google Hosted Libraries, and the confidence that no breach would occur is very high. If BECU was using Google Hosted Libraries, I likely wouldn’t be writing this post, but instead Typekit is being used. Even in the case of Google, whose security is industry-leading in many ways, DNS attack and modification is a potential attack vector, though for all practical purposes incredibly unlikely. However, as Google Hosted Libraries becomes ubiquitous, more attention will directed toward it, and I would expect breaches in the future, especially with its centralized and wide-reaching nature.

What’s significant about Typekit is that it’s owned and operated by Adobe. Recall that in 2013, Adobe was targeted and in addition to the encrypted credit card information and login credentials of about 3 million users being released publicly, the source code for a number of Adobe products was made public. It was later discovered that sensitive information of 152 million users was released.

I do believe that Adobe has made significant and even over-the-top security improvements from the 2013 breach. However, BECU is one of the largest credit union’s in the country and they service almost 1 million customers. They have over $12 billion in assets. Much of their online user traffic lands on their homepage, which loads external JavaScript from Typekit. There is no reason that the Typekit file couldn’t be hosted on BECU’s own servers, which they do for most other JavaScript files. And again, this external file is for aesthetic reasons only.

The likelihood of BECU’s Typekit file being compromised and malicious code being inserted to attack BECU customers seems fairly low, but it’s still possible (a small-scale example is the PageFair hack). In this case, the likelihood is increased because there is reason to exploit this. Adobe employees could be compromised, giving access to attackers. There could also be an Adobe employee cooperating with malicious entities. The origin of the file could be found beyond Akamai CDN, which we know is possible with today’s technology, and it could be compromised from the outside.

There’s just no way for BECU to control the file, and the security measures aren’t theirs. There are many extraordinarily talented engineers working for profit and governments, trying to collect data or do harm. This is low hanging fruit, and fonts aren’t worth it.

I’d also like to note that BECU does not use subresource integrity, which increases risk.

Curious whether other major credit unions and banks also use third party JavaScript such as TypeKit, I quickly viewed the source of the largest institutions:

  • Navy Federal Credit Union: No
  • Bank of America: No
  • Chase: No
  • Alliant Credit Union: No
  • Wells Fargo: No
  • Capital One: Yes (Ensighten, for analytics)
  • USAA: No
  • Key Bank: No
  • Goldman Sachs: Yes (Gigya, for customer identity management)
  • US Bank: No

Capital One and Goldman Sachs both use external JavaScript, for analytics and customer identity management, respectively. Those being the exception, the trend is that external JavaScript is never used.

BECU was notified on October 17th, 2016. Typekit is externally called on their homepage as of the post date.







Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s