Updated 12/24/08 (see end of post)
In this, our second entry in the series Online Finance Flaws, I call to your attention a report from Javelin Strategy & Research, the Banking Identity Safety Scorecard.
According to the MarketWatch writeup on the report, it "measures 25 leading U.S. financial institutions' customer-facing identity fraud capabilities. The Javelin model measures Prevention, Detection and Resolution(TM) features to track performance throughout the fraud cycle."
While I don't have the $1500 handy to purchase rights to read the complete report, it appears to be a comprehensive, well intended, ongoing effort.
Key questions asked by Javelin include:
1) Which financial institutions rank highest against Javelin’s customer-facing Prevention, Detection and Resolution™ criteria?
2) What type of account protection capabilities should banks and credit unions implement now to increase customer safety through Prevention, Detection and Resolution™?
3) Which customer safety features will most differentiate financial institutions in the future?
In answer to #1, the report lists its Top 5 indicating that Bank of America once again earned top overall honors, demonstrating excellence in its efforts to partner with customers against a crime that uniquely targets both the financial institution and the consumer. National City Bank (acquired by PNC) and Wells Fargo shared second position with equivalent scores followed closely by US Bank and Wachovia.
I'll answer #2 & #3 below.
I'll ask some further questions first, however.
Do we agree that web application security should and does play a critical role in what Javelin refers to as Prevention, Detection and Resolution™?
Do we agree that cross-site scripting (XSS), cross-site request forgery (CSRF), information disclosure, and SQL injection (SQLi) are all flaws that should not exist in a bank site on Javelin's Top 5?
Do we agree that XSS issues make for golden phishing opportunities for the inherently malicious, and again, should not exist in bank sites on Javelin's Top 5 with regard to a Banking Identity Safety Scorecard?
Before I discuss the flaws, be aware that I followed my terms of engagement with both of the following banks, and was largely ignored with either no reply or very vague, inconclusive brush-offs.
It is my hope that you, dear reader, will contact the following institutions, as I have, on behalf of the consumers they are obligated to protect, in the hope that they will make timely repairs.
And here, as I am prone to saying, is where the trouble begins.
U.S. Bank is vulnerable to XSS at their logon page.
National City Bank is vulnerable to XSS and information disclosure, as well as potential CSRF and potential SQLi, in a Cold Fusion (gasp!) app that runs a subdomain; specifically insights.nationalcity.com.
While the potential National City Bank vulns don't necessarily give a malicious attacker a ton to work with, given that it's an isolated app running a subdomain, the XSS issue is still useful in obvious ways.
I am particularly saddened by the XSS issue on the U.S. Bank site given the history of exploitation of just opportunities. See what I call the Italian Bank Job, and the article I wrote, Anatomy of an XSS Attack, inspired by the Italian caper.
Note that, as indicated in the Netcraft article on the Italian bank issue, SSL "security" is a moot point. Any script execution in the context of the U.S. Bank site occurs "protected" by SSL. As Netcraft says, "any SSL certificate associated with the site - included Extended Validation certificates - would display a padlock icon and apparently assure the user that the injected login form is genuine."
The National City Bank issues appear as follows.
XSS:
Information disclosure and potential SQLi both appear in the grossly verbose, overly helpful Cold Fusion error:
As a technical evangelist for online consumer well-being, and an information security practitioner, I'm here to tell you: these vulnerablities are indicative of behavior unbecoming of secure online banking; particularly as applied to two of the five "top-ranked banks who partner with customers to protect against identity fraud."
To answer #2 and #3 from above: build secure web applications.
U.S. Bank and National City Bank, I ask you to resolve these issues soon, on behalf of customers in your care.
Update 12/24/08:
U.S. Bank has notified me that they've repaired the vulnerable login code. Additionally, they've asked that I remove the video PoC, a request I choose to honor in deference to their open communication during the remediation period.
I've heard nothing from National City Bank. That said, while the initially reported issues appear to have been resolved, the resulting error message is still sloppy and overly informative (typical of Cold Fusion left unchecked).
del.icio.us | digg | Submit to Slashdot
Subscribe to:
Post Comments (Atom)
Moving blog to HolisticInfoSec.io
toolsmith and HolisticInfoSec have moved. I've decided to consolidate all content on one platform, namely an R markdown blogdown sit...
-
Continuing where we left off in The HELK vs APTSimulator - Part 1 , I will focus our attention on additional, useful HELK features to ...
-
As you weigh how best to improve your organization's digital forensics and incident response (DFIR) capabilities heading into 2017, cons...
-
When, in October and November 's toolsmith posts, I redefined DFIR under the premise of D eeper F unctionality for I nvestigators in R ...
3 comments:
They aren't the only ones around. I'm aware of a mortgage company who, in addition to being riddled with XSS holes, use timestamps as session IDs.
Another bank that I have used with in the past have XSS holes, lack of SSL on the login page, and publicly accessible access logs. When I brought it to their attention they simply told me that since they outsource their online banking, it isn't important. They never did fix the issues.
I have since found a new bank.
Um, as an NCC customer, an InfoSec professional and, more importantly, an IRM professional - I couldn't care less.
These banks know about these issues, they've had to do the risk assessments already, and they figured they have bigger fish to fry. So what?
Of course, I have more informative priors about their IRM practices than you do...
@alex: Are you serious? You're either a troll (trying to get someone to flip out and respond) or you're just ridiculous.
I have a little experience working for a bank (or few) in my past so I can appreciate the "bigger fish to fry" comment but an issue that is (1) relatively trivial to fix and (2) damaging to a huge customer base should be a high-priority, especially given the comment you posted on my blog.
Anyway - this is *exactly* the reason there are so many excessive IT-based risks out there...people just don't care!
... WOW.
Post a Comment