Online finance flaw: Ameriprise FAIL...again

Here we go again.
The cross-site scripting (XSS) issues on the Ameriprise advisor locator site were fixed, even if temporarily, back when Dan Goodin reported on the issue in August.
A little bird whispered in my ear the other day and told me a sad tale:
they're baaaaack.
Regression testing anyone?
Regression testing (from the Wikipedia entry recommends that:
"in most software development situations it is considered good practice that when a bug is located and fixed, a test that exposes the bug is recorded and regularly retested after subsequent changes to the program.
What a grand idea! Ensure that you don't reintroduce old flaws when you roll old code.
Really? I have to say it?
Apparently.



Dan & El Reg have covered the issue again given that, in order to have it fixed again, I had to ask him to ping the Ameriprise PR department.

*sigh*

BTW...the issue is fixed, for now. ;-)

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Amex II: Ameriprise mishandles disclosure too

Yet another online finance flaw for your consideration.
Remember the American Express issue?
Apparently the negligence and ignorance of the parent has been inherited by the child.
It took me pinging Dan Goodin at The Register and asking him to shake Ameriprise out of their slumber to address the most commonplace, simple, web application bug of all: XSS. Really? Still?
Dan did a bang up job of the task at hand; it was fixed within hours. Ameriprise had ignored my multiple attempts to disclose over five months. Power of the press, eh?
The story is here.
I also owe Laura Wilson at Information Security Resources for alerting me to likely issues with Ameriprise.
I'm tired of having to say it. It's even gotten to the place where readers get pissed at me because I keep stressing the point. But I shouldn't have to.
Major financial providers should not be ignoring reports of common web application vulnerabilities sent in via all their available channels.
Major financial providers should be reviewing their web sites and their code at regular intervals, proactively preventing these issues.
Blah, blah, blah...you can't hack a server with XSS.
If you attended BlackHat or Defcon a few weeks ago, you may realize how much less relevant that argument is.
Check out the XAB, Firefox extensions, and evasion discussions.
You can be pwned through XSS.
Do I need to stress compliance again? Amex touts itself as a founding PCI partner, yet here we go again.
Vendors and developers need to get smarter, faster, and more responsive to security related notifications, particularly with regard to their websites.
To that end, keep an eye on the Data Security Podcast. Ira Victor and I have hatched a scheme to promote the use of proper disclosure handling by website operators such as major financial services providers. He'll also be posting podcasted discussions we've had regarding the disclosure issues, as well as the forensic challenges presented by CSRF attacks (another easily avoided, common web application vulnerability).
I'll also be talking about a pending ISO standard for disclosure that I hope will begin to drive enterprise adoption of improved disclosure handling.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

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

Online finance flaw: Merrill Lynch not bullish on XSS & CSRF vulnerabilies

Updated: 1/16/09 See update below.

Perhaps, now that they're a Bank of America property, better web site security is in store for Merrill Lynch. In the meantime...here's where the trouble begins.
Prompted by headlines from December 21st stating that $1.6B Of Bank Bailout Went To Execs, I thought I'd take a look at the most egregious amongst those receiving a bailout courtesy of taxpayers.
I'd also like to explore what web app vulns mean to Sarbanes-Oxley (SOX) compliance; I've posed some questions below.

Here's all you really need to know:
John A. Thain, chief executive officer of Merrill Lynch, topped all corporate bank bosses with $83 million in earnings last year. Thain, a former chief operating officer for Goldman Sachs, took the reins of the company in December 2007, avoiding the blame for a year in which Merrill lost $7.8 billion. Since he began work late in the year, he earned $57,692 in salary, a $15 million signing bonus and an additional $68 million in stock options.
Like Goldman, Merrill Lynch received $10 billion from taxpayers on Oct. 28.

Too bad Merrill Lynch didn't spend just a wee small percentage of excessive salaries focusing on improving web application security on behalf of the customers paying for the extravagant lifestyles of their top execs.
But, that said, enough frustrated social commentary.

The Merrill Lynch OnLine Login page is vulnerable to cross-site scripting (XSS) and cross-site request forgery (CSRF), leaving customers at risk for financial compromise via phishing or credential theft.

As always, I followed my terms of engagement, sending no less than three emails over a period of no less than two weeks, even allowing a couple of extra days for the holidays.
To date I have not received a single response, automated or otherwise.

The point is best driven home via video, but the details are simple enough.
A properly formed IFRAME fits neatly, front and center, on Merrill Lynch's OnLine login, embedding Morgan Stanley's ClientServ login page, just to prove the point.

Merrill Lynch OnLine before:



Merrill Lynch OnLine after:



Web application vulnerabilities and SOX compliance

It's obvious that vulnerabilities such as that described above indicate a clear break from PCI compliance.
But what about SOX? HP (formerly SPI Dynamics) offers an interesting perspective in an effort to promote product:
Sarbanes-Oxley Act compliance can be difficult because it was not written specifically with information technology or information security in mind; however, there are various sections within the act that directly affect these functions in today’s corporations. This includes how information is accessed, what leaves the corporate network and what information needs to be protected and retained over time. You should conduct web application security assessments for an initial SOX compliance risk assessment to understand your various internal controls.
Such a web application security assessment would certainly require that a company like Merrill Lynch "validate that web application inputs are properly validated and not vulnerable to command injection or cross-site scripting attacks."
If SOX Section 404: Assessment of internal control indicates that an enterprise must "evaluate controls designed to prevent or detect fraud", shouldn't web application vulnerabilities that lend greatly to phishing or credential theft (fraud to be sure) fall under established controls?
So, my compliance an auditor friends, who wants to take this one on?
Comments welcome.

Can a failed enterprise like Merrill Lynch, who received $10 billion in bailout funds, and compensated a top exec in extraordinary fashion, be called in to question with regard to SOX compliance for issues as described above?
I'm not certain, but it seems worthy of consideration and debate.
I look forward to your feedback.

Update 1/16/09
The Merrill Lynch security team has responded in force and has conveyed that they "take security very seriously and now that we know about this are acting quickly."
As of 1/16/09 Merrill Lynch has indicated that the necessary fixes have been applied to their production environment.
They've also asked that, should anyone discover issues in the future, that they report them to abuse at ml.com.

del.icio.us | digg | Submit to Slashdot

Online finance flaw: Visa responds quickly to reported vulnerabilities

The American Express online flaw I discussed last week led to two interesting sidebars.
First, a rather strong media response resulted with coverage in The Register, BetaNews, and Dark Reading, amongst others.
Second, aside from all the variant hunters, I received a number of interesting finds from friend-of-the-cause Mike Bailey over at skeptikal.org.
He'd been inspired by the fact that the PoC I issued for the AmEx bug included an IFRAME insertion pointing to Visa.com. Inspiration led to discovery (and whole lot less work for me) and immediate issues were noted in a few Visa sites.
To be fair, http://usa.visa.com itself appears to be sound; both Mike and I gave it a cursory glance and nothing popped up (XSS pun).
The same could not be said for http://empresarial.visa.com.
No need to rehash all the problems XSS issues in major credit card company sites might cause (PCI compliance, phishing, customer abuse, etc.); earlier posts speak for themselves.
As always, I reported the vulns per my terms of engagement.
Here's where the rather unexpected occurred.
I first reported the issues on December 17th at 1322 hours PST.
They were fixed no later than December 18th at 1916 hours PST.
In essence, Visa executed a 24 hour turn around for mitigation and repair.
Now, I have no doubt variant hunters will likely go digging about for other vulnerabilities, and if Visa hasn't issued global repairs, they might find some.
But, what's key here is how quickly Visa responded. I must admit, after the debacle born of the AmEx issue, I wondered if I'd be asked to report the vulns through Visa's PR department, a method recommended by AmEx to report vulns to them. ;-)
Not only was my disclosure responded to in a very timely fashion, I received the following feedback:
"We appreciate you bringing this situation to our attention. Visa takes security matters very seriously. All impacted pages have been taken down while we remediate the XSS coding. As always, feel free to report any future abuses to: abuse@visa.com."
Hard to argue with that.
My impression (unsubstantiated) is that the vulnerable sites were the product of a 3rd party development team, serving Spanish speaking customers, given the fact that the vulnerable code was PHP, not typical of English language Visa properties.
For posterity's sake one of the vulns appeared as follows. There were other similar issues with different variables, different sub-domains, and partner sites, but you get the point.

XSS in empresarial.visa.com/por/glossario.php:



I'd like to issue a "well done" to Visa and those who responded so quickly.
I can only hope that pending disclosures to all the other credit card vendors, banks, and brokerages in the Online Finance Flaws pipeline are handled as quickly and openly.
Thanks again to Mike Bailey (mckt) for his contributions to the cause. You'll see more of his work in future posts.

del.icio.us | digg | Submit to Slashdot

Online finance flaw: American Express XSS

Updated again 12/19/08 (see end of post)

Our third entrant in the Online Finance Flaws series is one that truly perturbs me.
American Express came to my attention when setting up an online access account I was prompted to REDUCE the amount of characters in my password to eight or less. What?!
Luckily, my partner in alerting you to the absurd, Rafal Los, covered this issue nicely in May.
Of course, prompted by my irritation, I challenged myself to see what other truly inane security "features" American Express might be offering.
Here's where the trouble begins.
I kid you not, thirty seconds later, I found a new cross-site scripting (XSS) vulnerability right off the American Express primary search script (not one of three already posted on XSSed.com).
Three minutes later , in the TMI department, I discovered a most informative 500 error page exception indicating that American Express uses the Vignette CMS product via Apache and IBM's WebSphere.
Before I validate these findings please allow me to point you to the American Express data security page.
Key language includes:
"American Express is proud to be a founding member of the PCI Security Standards Council. The Council is designed to manage the ongoing evolution of the PCI Data Security Standard and to foster its broad adoption industry-wide. Through our participation with the Council, American Express continues our commitment to diligently pursue all aspects of data security."
Let me spell this out for you.
A founding member of the PCI Security Standards Council is itself in violation of PCI DSS 6.5.4.
This does little for my faith in American Express "data security", or the PCI Security Standards Council for that matter.
Finally, as always, I followed my terms of engagement in reporting these findings to American Express and was ignored by everyone including a director in their information security organization.

A video of both issues is here.

Should you prefer screen shots...an American Express XSS cookie grab:



Or the phishing warning:



Finally, my favorite, an IFRAME insertion of the VISA web site. Oops!



Oh yes, the 500 error, if you're still with me:



Is it wrong of me to expect more of credit card companies with claims to founding the PCI Security Standards Council? I think not.

Please contact American Express and register your own complaint. This is simply unacceptable.

Update 1100 hours 12/17/08:
American Express has made repairs regarding the XSS vulnerability, and has replied to Dan at The Register.
Additionally, this Computerworld article is just too silly and timely to not share in the context of our discussion. May the irony amuse you as much as it did me.

Update 2015 hours 12/19/08:
Repairs as indicated 12/17 now proven to be "repair" as variants galore arise.
Dan G. at The Register exposes research from at least two sources proving once again that one-off repairs are worthless when compared to a global approach.
Makes me wonder what this means for AmEx's stock.
Well done, fellow researchers. Well done.

del.icio.us | digg | Submit to Slashdot

Online finance flaw: U.S. Bank & National City Bank XSS and more

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