SearchFinancialSecurity: The need for financial Web application security

The current lead story on SearchFinancialSecurity.com is my contribution Why financials must implement Web application security best practices.
This is a follow up piece, a summary if you will, on my Online Finance Flaws campaign, kindly solicited by TechTarget to drive home the point: Is there any one sector more than financial services who must take a stronger stance with regard to Web application security?
Answer: Not that I can think of.
Security hits to financial-services firms have far reaching impacts beyond individual victims, including economic implications that can contribute to global economic malaise.
This article offers examples of flaws noted in major financial-services websites, data from OWASP's Security Spending Benchmarks Project Report as well as best practices guidance derived from security development lifecycle (SDL) methodology.
I invite you to read the article at your earliest convenience.
As always, feedback is welcome.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Online finance flaw: Recession humor at Citibank's expense

It should come as no surprise that Citibank would turn up in the Online Finance Flaws series.
Given their active role as root cause participant in our current economic downturn, Citibank has managed to invoke the ire of more than one critic.
The lesson I'll offer here is a simple one, unrelated to economics.
If you outsource development, and fail to manage the process, including the security development lifecycle (SDL), or lack thereof, you put your enterprise at risk.
I admit I am assuming outsourcing in this scenario, but I believe given that the vulnerability was found in a Citibank Hungary offering, I don't think I'm off the mark.
Citibank ignored me entirely so I decided to pass the findings off to the Microsoft Vulnerability Research (MSVR) program and see if the team could make contact with the right folks. The MSVR program is both very young, and in a current state of transition, but they obviously had success as the following vulnerability has been repaired. Hopefully I'll be able to provide more detail on this program in the future.
Citibank Hungary suffered from a cross-site scripting (XSS) vulnerability at the from variable as submitted to the form.jsp script.

It afforded me ample opportunity to inject a little humor (pun intended).
Here's the video if you'd like the long version; please note all the "security" references I capture prior to finding the site to be in complete contradiction to those references.

The following screen shot captures the essence of the message.



Here's the string resulting in the above screen shot, to give you injection context.



All security implications apply here: phishing, PCI, damage to brand and reputation, risk to consumers, etc.
That said, it appear that just a few of the kabillions of bailout dollars bestowed upon Citibank might have gone to a web application protection mechanism applied globally to all Citibank sites.
I'd love to say it came on the heels of this vulnerability being disclosed to them, but alas, I'll likely never know.
As I poked about to see what sort of results the old vulnerabilities generated, as well as poking for any other lapses, I universally received this URL.
It shows a 404, but the implications are something WAF-like is nailing common Javascript strings, given that the URL declares /domain/spoof/intercept.
Makes me feel good to see my tax dollars hard at work. ;-)

Cheers.

del.icio.us | digg | Submit to Slashdot

Online finance flaw: At least AIG got this one right

As our economic conditions worsen, and the gloom and doom chatter intensifies, much attention has been paid to AIG. The crux of the AIG dilemma, to hear Ben Bernanke say it, is that they're too big to let go under, but most observations indicate they deserve to.
"I share your concern, I share your anger," Bernanke told the Senate Budget Committee. "It's a terrible situation, but we're not doing this to bail out AIG or their shareholders. We're doing this to protect our financial system and to avoid a much more severe crisis in our global economy."
Add to that this past week's disclosure that AIG will pay out $170 million in tax payer dollars as bonuses, and today's news that the $170 billion at large is basically already all gone.
Thus, the list of big finance companies becoming fodder for verbal abuse and regulatory oversight just keeps growing.
That said, I am neither an economist or even remotely intelligent enough to speak on these issues with authority, but there's one issue I know relatively well.

As part of the ongoing Online Finance Flaws series, AIG suffered from a cross-site scripting vulnerability in their search script.

I apologize in advance, I couldn't resist a little political, current events humor at AIG's expense as I chose to drop in an IFRAME with a relevant news story.

AIG before:



AIG after:



I initially took note of this vulnerability on sla.ckers.org. It occurred to me that, in all likelihood, no one had bothered to tell AIG. After pinging my circle of industry folks with good contact lists, to no avail, I decided to try winging my disclosure and advisory effort to see what might come of it.
I sent email to abuse@, as well as two other aliases I found on the AIG site security page; specifically, corporatelegalcompliance@ and aig.iaig@.
I received an almost immediate automated response with a ticket number (a good thing), a call from an AIG information security resource the next day (a really good thing), and a week later the issue was fixed (a great thing).

So, as I sit here watching my 401k and investment portfolio fall in value by 75%. due in large part to one group at AIG, I can rest comfortable that another group at AIG (information security) is doing its job well. ;-)

del.icio.us | digg | Submit to Slashdot

Online finance flaw: one flaw to rule them all

Flaws in SAAS offerings and the inherent risks

What if dozens (even hundreds) of banks all used one vendor's solution to provide online banking services?
What if that solution had a security flaw thus affecting all users of said solution? A finding of considerable concern, yes?

I must preface this discussion with the fact that the vendor in question has proven to be trustworthy, capable, reputable, responsible, and responsive.
Precision Computer Systems, a FISERV company, provides outsourced online banking solutions to a plethora of banks.
My desire to discuss the vulnerability with Precision Computer Systems (PCS) was forwarded to FISERV for consideration, and the reply came directly from the Vice President | Head of Security.
"As you might imagine, no higher priority exists for our organization than the protection of our client’s information, and that of their customers. To that end, we’ll always welcome constructive feedback such as yours with enthusiasm."
As responses to reported vulnerabilities go, PCS/FISERV handled the process in ideal fashion and are to be applauded for doing so.
While flaws in web applications are a dime a dozen, and nearly every web app yields a vulnerability at some point, the more important piece is how the vendor responds when said vulnerability is disclosed to them.
For this software as as service (SAAS) offering, while each bank's web site is unique, when the user decides to login to the Online Banking service, they're redirected to https://ibank.pcs-sd.net/onlinebanking8/login.r?t-bank=bank id.
Thus, all banks utilizing PCS for this particular feature all take advantage of this specific application to handle logins, amongst other things.
The login form, in particular, suffered from a cross-site scripting (XSS) vulnerability; as discussed in earlier posts, the potential risks to consumers are obvious.


This graphic has specific bank information redacted, and the specifics of the vulnerability are unnecessary. My preference is to treat this discussion as a learning opportunity, rather than nitpick needlessly.

At the risk of overstating the point, the one flawed variable affected all PCS customers utilizing the service.
Again, PCS/FISERV, as indicated above, handled this vulnerability quickly and admirably; they immediately assigned a PM and development resources to repair and release a fix to production.

The lessons here are many.
1) Other online finance vendors, particularly those falling in the SAAS category, take note: this is how to respond to reported vulnerabilities.
2) SAAS customers, take note: ensure that the vendor you contract with for service is very clear about their secure development practices. Don't be afraid to ask very pointed questions such as:
"How quickly will you respond if a vulnerability is disclosed to you?"
"Do you employ a Secure Development Lifecycle standard?"
"How often, and by whom, is the security posture of your product reviewed, preferably with the appropriate compliance frameworks (PCI, SOX) in mind as well as the given web application security standards (input validation, sanitize output, etc.)?"
3) Customers and vendors alike: trust no trustmark (security badge) provider to actually provide you any actual security value...conversions yes, security not so much. At least one bank on the PCS customer list utilize the likes of Control Scan. You'd think Control Scan might have found or reported this vulnerability to the bank or PCS, yes? I think not. SSL-related trustmarks are also nice but no encryption in the world will help you under these circumstances.

The responsibility bestowed upon SAAS providers is of a magnitude at least similar to that of typical application product providers, if not more.
Where a single "boxed" product falls under the scrutiny of vulnerability managers such as CVE and OSVDB, no such scrutiny exists for SAAS offerings.
As more enterprises take advantage of SAAS and cloud-based offerings, they do so for obvious cost and efficiency reasons, but may not have assessed the changing dynamic of their risk posture.

As we consider the premise of one flaw to rule them all, vendor response will be paramount. May the PCS/FISERV standard become commonplace.

del.icio.us | digg | Submit to Slashdot