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:
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 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.
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.
- 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
BECU was notified on October 17th, 2016. Typekit is externally called on their homepage as of the post date.