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
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 ...
10 comments:
@Russ - but, but... when I used to work for a startup financial company in Chicago in 1999/2000 AmEx claimed (and to this day claims) they have the "tightest and most stringent security practices anywhere"... they pen-test their partners, vendors, and everyone they can find. Luckily, their pen-testers must never actually pen-test (or security-check) anything of their OWN... otherwise they'd be in serious trouble.
You know, I guess they're lucky they're PCI compliant, otherwise this would be a problem.
@Russ/all...
"Hi, we're AmEx, keepers of the American Express brand which we value above all else, and we're second to none. And we care about your security... and we're pushing PCI and *fining* non-conformists"...
... DO AS I SAY, NOT AS I DO. Right AmEx?
I spent more time than I care to admit at AmEx and their CISO team. The delay was likely do to trying to figure out exactly WHICH 3rd party to contact to correct it. And no, the 'tightest and most stringent' is PR-marketing fluff.
We had an employee data breach where somebody decided to take unencrypted data to Towers-Perrin. They gave us 2 years of monitoring. Then there was the eBay hard drive recently where cards were compromised.
You'd think they'd run the company on a platform other than Lotus Notes, right?
It's still not fixed I hope you know :-)
@Anonymous
If it's still not fixed, please feel free to submit any variant you may have discovered, and we can turn it into to their PR department. ;-)
Further indication they have no clue comes from this quote, from their PR flak as it appears in the Register article: "Security researchers who discover vulnerabilities on Amex's site may report them by contacting a member of the company's PR team".
@Anonymous
Indeed, I chuckled profusely when I read that. What?! Some PR wonk is going to have a clue what any web application vuln might be, and then delegate the issue to the proper development team? I think not.
Try creating an abuse@ or security@ alias, and ensure security-minded people with a clue monitor it.
I wonder if they have ever heard of a little thing called a "Web Application Firewall" which is required by PCI funny enough...
Web Application Firewalls are NOT required by the PCI DSS. They are an option and by no means a panacea. Misconfigurations, lack of logging, or lack of change control on a WAF can all expose a webiste to just as much risk without having one at all.
Post a Comment