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
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...
-
Ladies and gentlemen, for our main attraction, I give you...The HELK vs APTSimulator, in a Death Battle! The late, great Randy "Macho...
1 comment:
@Russ - Well done. Seems your reputation preceeds you these days :)
@VISA - Everyone in security (well, those that get it) understand that there will be bug, it's just the nature of the human condition - to create faulty things - but to have a 24hr turn-around is smashingly-good. Applause and some recognition is due to the Visa folks
Post a Comment