McAfee Secure claims to be McAfee Secure while not McAfee Secure
It's been a rough week for our McAfee Secure friends.
First, an XSS, Iframe injections, and XMLHTTP outing provided by XSSed.com, followed quickly by a CSRF browbeating from The Skeptikal One, Mike Bailey.
While these findings should not come as a surprise, I have no doubt McAfee moved as quickly as possible to resolve the issues.
What sadly should also not come as a surprise is that the entire time these numerous vulnerabilities were live, so too was the McAfee Secure trustmark.
I realize the odds of McAfee Secure removing the McAfee Secure trustmark when they are not McAfee Secure is highly unlikely, it nonetheless exemplifies a double standard.
The key question is this.
If the McAfee Secure customer portal is vulnerable to CSRF for 4-5 weeks while the portal code is under repair, should it declare itself McAfee Secure?
To further my point, language from the McAfee Secure Standard:
In the event that McAfee discovers a vulnerability that prevents a merchant’s website from complying with the McAfee SECURE standard, the merchant will have a 72-hour remediation window. In instances where McAfee believes confidential customer data is at immediate risk, or in those cases where McAfee has evidence of prior compromise, the McAfee SECURE trustmark may be removed before expiration of this 72-hour window.
While the McAfee Secure Standard does not indicate that CSRF by itself is worthy of pulling a trustmark, the fact remains that because Mike had demonstrated what could be done with this paricular vulnerability, such as a live weaponized attack script, McAfee was treating it like a high-priority critical issue.
I can therefore only hope that a McAfee Secure customer under the same circumstances would NOT have been displaying a McAfee Secure trustmark.
So there it, plain and simple, for your consideration.
A double standard?
You decide...comments welcome.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Russ McRee's HolisticInfoSec™ includes articles and research, as well as feedback and an occasional rant. HolisticInfoSec™ promotes standards, simplicity, tooling and efficiency in achieving holistic information security.
Subscribe to:
Post Comments (Atom)
-
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 ...
2 comments:
Of course it's a double standard. Will they pull their little badge? No. Why? Because that would confuse the 98% of their customers that have no idea of what happened this week. The sad thing is, being a consultant, even if I tell this story most of those listening won't get it. 1/10 will and the remainder will need it drawn out in a Visio diagram before they can start to wrap their head around it.
I recently found multiple CSRF and XSS bugs in the SecureComputing (now McAfee) IronMail SWD (secure web deliver) interface. I showed them to, someone I thought was, a relatively knowledgable SE. His response: "Nobody else has reported an issue with this". Way to go SecureComputing / CipherTrust / McAfee -- they haven't updated the product since 2005, why start now? :)
Hey Russ, nice post by the way. I think windexh8er hits it square on the head; McAfee has been buying up companies and crapping no them for years - and they still have customers so why would they change anything they're doing?
If you're selling crap and people are still buying, what's your incentive to change?
Post a Comment