McAfee has alerted me that the McAfee Secure Standard has been published on the McAfee Secure (formerly ScanAlert Hacker Safe) website.
The McAfee SECURE Standard
Joe Pierini and Kirk Lawrence started this process with me prior to their departure from McAfee, and work continued in their absence, largely at the hands of Will M., who's been communicative and inclusive in their stead.
I applaud McAfee for staying true to their commitment to publish the McAfee Secure Standard.
While I may not agree with everything in it, a standard is better than no standard.
That said, my concerns with the Standard as discussed earlier remain unaddressed.
First, you will find that remediation of what McAfee deftly refers to as Client Side Vulnerabilities is Optional. The Client Side Vulnerabilities category includes the entire family of script insertions.
Clarified, this means that merchants displaying the McAfee Secure trustmark are under no obligation to repair such vulnerabilities; the trustmark will remain displayed unabated by the truth.
My position here is clear.
If a website declaring itself secure via a McAfee Secure trustmark is vulnerable to cross-site scripting (XSS), I believe that declaration to be false and misleading. Further elaborated, the McAfee Secure Standard's Client Side Vulnerability category includes cross-site request forgery (CSRF).
While I choose not to out any site in particular at this time, I can assure you with all professional certainty that there are sites displaying a McAfee Secure trustmark that are vulnerable to CSRF. In the case of sites using one particular application, the CSRF vulnerability is so severe, an attacker can escalate privilege in short order.
This is a vulnerability that I've discovered and disclosed responsibly, so I won't discuss it further at this time.
But I ask you, should a site vulnerable to such an attack be labeled as McAfee Secure, per their freshly published Standard?
I think not.
Also Optional on the McAfee Secure Standard: SSL Encryption.
Should a website that conducts financial transactions, yet does not choose to encrypt transaction traffic, be allowed to display a McAfee Secure trustmark?
I think not.
Ironically, the McAfee Secure Standard directly compares itself to PCI DSS. None of the vulnerabilities listed as Optional, per the McAfee Secure Standard, are acceptable for PCI certification.
While the McAfee Secure Standard careful delineates the difference between the Secure trustmark program and their PCI Compliance program, it's not as black and white as they may think. McAfee is a PCI approved scanning vendor (ASV), and a provider of a popular PCI compliance service.
Should they really hold one set of customers to a different standard than the other?
I think not.
Again, I applaud McAfee for publishing the McAfee Secure Standard.
I never imagined we'd get this far, so I humbly ask McAfee to consider the following.
1) Don't bury the Standard. Announce it. Publicize it. Embrace discussion about it. Provide a link to it from the McAfee Secure website. While we may have differences over some of its content, the McAfee Secure Standard is a bold step. Let people know.
2) Disguising script insertions (XSS and CSRF) in the Client Side Vulnerabilities category is a disservice to your customers, and their customers. The "clients" in Client Side Vulnerabilities are consumers using these sites. I believe you are beholden to these consumers as much as you are your own.
Extend the timetable for merchant repair of these vulnerabilities if you must, but said repair should not be Optional.
3) A McAfee Secure site, with a McAfee Secure trustmark, without an SSL certificate is unfathomable. While many a vulnerability can be exploited under the umbrella of SSL protection, SSL encryption is nonetheless an industry standard that should not be Optional.
These things I ask of McAfee in the name of common sense and consumer well-being.
To quote the McAfee Secure website:
"When you display the McAfee Secure certification mark, you not only increase sales by increasing shopper confidence, you build your brand with the security seal seen on more top sites than any other."
Is "increasing confidence" at the expense of industry standards, and real web security a violation of good faith and the very trust you seek to build?
I think so.
As always, I welcome constructive and thoughtful comments and feedback.
del.icio.us | digg | Submit to Slashdot
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.
Showing posts sorted by relevance for query mcafee. Sort by date Show all posts
Showing posts sorted by relevance for query mcafee. Sort by date Show all posts
Tuesday, January 13, 2009
Tuesday, May 05, 2009
The McAfee Secure Double Standard
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)
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)
Tuesday, October 07, 2008
The McAfee Secure Standard: Sort Of
I need your help.
I am in receipt of the McAfee Secure Standard, drafted to transparently describe the McAfee Secure service, as promised during my meeting with Joe Pierini and Kirk Lawrence of McAfee some weeks ago. I admit my attitude has soured since last I discussed it here, as the Standard is not yet ready for public release (I last said 2-3 weeks and that was five weeks ago), but bear with me. I can't publish exact quotes from the Standard, as I've promised not to, but let me give you insight on the upside, then the downside.
The upside includes all the transparency we'd hoped for. You'll read the McAfee Secure Standard and know exactly where they stand with regard as to what can be expected of the McAfee Secure Service. My discussions with Joe Pierini have been productive and respectful; he means well, and I believe he will try to drive the greater McAfee leadership to officially incorporate suggestions made in this blog.
I have even had the pleasure of reading a Researcher/Finder Policy that very succinctly describes what researchers can expect when they submit vulnerabilities found in McAfee Secure sites. That's all good stuff and to be applauded.
Now for the downside.
The McAfee Secure Standard will draw a clear distinction between "enterprise" customers and all the Ma & Pa websites who have so loved McAfee Secure / ScanAlert Hacker Safe for conversions.
The most glaring and painful distinction for me is this. While enterprise customers will have a clearly defined time line in which to remediate script injection vulnerabilities like XSS and open redirects, before losing their McAfee Secure badge, the Ma & Pa sites will have absolutely no requirement to fix their XSS issues. XSS vulnerabilities and the McAfee Secure badge will remain consistent on all those sites that care more about "convincing" their customers that they're secure with a McAfee Secure badge; a badge that, by its own pending standard, will contradict what we know to be truly secure.
My views are clear. I have made every effort to convince McAfee that this stance is counter intuitive to good web application security standards. I believe that, in their own way, they are listening. So here's your chance.
1) Is transparency enough?
2) Is holding only enterprise customers accountable acceptable?
3) Should ALL McAfee Secure customers be expected to fix their vulnerabilities, even if on different timelines?
4) What else do you want McAfee to hear, in the form of constructive feedback only?
I will publish all well written, thoughtful comments here. Let's keep it positive and see if we can help convince McAfee that script injection vulnerabilities and McAfee Secure can't exist in the same physical space. Like matter and anti-matter. ;-)
The floor is yours...
del.icio.us | digg | Submit to Slashdot
I am in receipt of the McAfee Secure Standard, drafted to transparently describe the McAfee Secure service, as promised during my meeting with Joe Pierini and Kirk Lawrence of McAfee some weeks ago. I admit my attitude has soured since last I discussed it here, as the Standard is not yet ready for public release (I last said 2-3 weeks and that was five weeks ago), but bear with me. I can't publish exact quotes from the Standard, as I've promised not to, but let me give you insight on the upside, then the downside.
The upside includes all the transparency we'd hoped for. You'll read the McAfee Secure Standard and know exactly where they stand with regard as to what can be expected of the McAfee Secure Service. My discussions with Joe Pierini have been productive and respectful; he means well, and I believe he will try to drive the greater McAfee leadership to officially incorporate suggestions made in this blog.
I have even had the pleasure of reading a Researcher/Finder Policy that very succinctly describes what researchers can expect when they submit vulnerabilities found in McAfee Secure sites. That's all good stuff and to be applauded.
Now for the downside.
The McAfee Secure Standard will draw a clear distinction between "enterprise" customers and all the Ma & Pa websites who have so loved McAfee Secure / ScanAlert Hacker Safe for conversions.
The most glaring and painful distinction for me is this. While enterprise customers will have a clearly defined time line in which to remediate script injection vulnerabilities like XSS and open redirects, before losing their McAfee Secure badge, the Ma & Pa sites will have absolutely no requirement to fix their XSS issues. XSS vulnerabilities and the McAfee Secure badge will remain consistent on all those sites that care more about "convincing" their customers that they're secure with a McAfee Secure badge; a badge that, by its own pending standard, will contradict what we know to be truly secure.
My views are clear. I have made every effort to convince McAfee that this stance is counter intuitive to good web application security standards. I believe that, in their own way, they are listening. So here's your chance.
1) Is transparency enough?
2) Is holding only enterprise customers accountable acceptable?
3) Should ALL McAfee Secure customers be expected to fix their vulnerabilities, even if on different timelines?
4) What else do you want McAfee to hear, in the form of constructive feedback only?
I will publish all well written, thoughtful comments here. Let's keep it positive and see if we can help convince McAfee that script injection vulnerabilities and McAfee Secure can't exist in the same physical space. Like matter and anti-matter. ;-)
The floor is yours...
del.icio.us | digg | Submit to Slashdot
Saturday, August 30, 2008
McIrony: An unexpected response from McAfee
Irony: incongruity between what might be expected and what actually occurs.
Right before Black Hat, I put together what I believed was a pretty strong arguement against McAfee Secure - Hacker Safe, at a level heretofore unexplored. I believe it was more damaging than anything I've said to date, and as such, presented potential risk for me. So I ran it by some friends before publishing it. Then a most extraordinary thing happened. I had a long chat with Nate McFeters, who described an awakening he'd recently experienced. He shared with me the belief that a better approach to potentially negative security research might be to try to create a positive outcome, and worry less about press cycles or exposure, the 15 minutes of fame if you will. He pointed to people like Mark Dowd as an example of people who conduct crushingly good research, and steer clear of the petty, ego driven bulls**t.
There I sat, repose like the thinking man, frozen for minutes. "Nate", I said, "I think you're right."
What do I aspire to as an information security professional; more readership or street cred than the next guy, or the respect of my peers for contributing to the greater good? Attention, press cycles, 15 minutes...it all has its allure, trust me on this.
But at the end of the day, I really do want to contribute to the greater good.
So I did something different. I sent my findings to McAfee and offered them an opportunity to respond, rather than publish first, ask questions later.
Here's the real kicker.
They responded.
I had a three hour lunch this past Thursday with two gentlemen from McAfee, who flew up from the Bay Area to Seattle to have a face to face with me. This, all by itself, speaks volumes to me. In addition to meeting with Kirk Lawrence, the new Director of Product Management for McAfee Secure, there I sat with, of all people, Joe Pierini, the very guy who has suffered more than his share of abuse, up to and including the Pwnie. As I have been a direct contributor and participant in heckling Joe, you can imagine our meeting could have been uncomfortable. It was not.
I have had expectations of McAfee and Scan Alert that to date have not been met, or my (your) perception has been that they have not been met.
This meeting was designed as an opportunity to voice some of these expectations, and see if McAfee, in turn, believed there was any merit to them.
Surprisingly, at least as spoken, we weren't all that far apart.
While, as a naive idealist, I believe that security should come before conversions, I am also grounded enough of a realize that the most attainable goal can be a marriage of both. This premise frames my expectations of McAfee.
Can they not be more of a "thought leader" for all the Ma & Pa websites who rely on McAfee Secure, first for a higher conversion rate, then security?
Can they not hold merchants to a higher standard, without alienating them and losing business?
Can they not embrace the security research community in a fashion that McAfee, the security community, the merchants, and consumers can all benefit from?
Can they not be more transparent in their approach, providing more details and feedback about their methods, their findings, and their vision?
I know McAfee Secure - Hacker Safe scans can find vulnerabilities.
I know they report the vulnerabilities to merchants.
What happens thereafter is where things begin to break down.
Can the scan engine be improved to find more vulns? Sure. That's really not that big a deal; technology can always be improved.
But, regarding holding merchants to a higher standard; therein is the whole point of this debate.
Anyone can throw a badge on a site.
But what happens when the site proves vulnerable is the key. I'll be candid here: I don't give a damn about the merchant at that point; it's the consumer who is at risk and needs something better from McAfee and their peers.
So, here begins a different approach. I know that making changes at a company the size of McAfee can be likened to the three miles it takes to turn around an aircraft carrier. I'm willing to work with them, and allow for a positive outcome.
I have been told that, in two or three weeks, we can expect a published standard, that clearly defines exactly what the McAfee Secure product offering adheres to, inclusive of their expectations for merchant remediation timelines, potential badge downgrades for unresolved vulnerabilities, and hopefully even a more clear stance on XSS.
I have been told that I will have the opportunity to discuss this standard, and invite feedback. Any standard is better than no standard.
I have also been told that this is just the beginning of changes that will lead to more of what I have hoped for in my expectations, over the next 6 months or so.
I am hopeful that we can take McAfee at their word, and even if slowly, see a positive outcome.
del.icio.us | digg
Right before Black Hat, I put together what I believed was a pretty strong arguement against McAfee Secure - Hacker Safe, at a level heretofore unexplored. I believe it was more damaging than anything I've said to date, and as such, presented potential risk for me. So I ran it by some friends before publishing it. Then a most extraordinary thing happened. I had a long chat with Nate McFeters, who described an awakening he'd recently experienced. He shared with me the belief that a better approach to potentially negative security research might be to try to create a positive outcome, and worry less about press cycles or exposure, the 15 minutes of fame if you will. He pointed to people like Mark Dowd as an example of people who conduct crushingly good research, and steer clear of the petty, ego driven bulls**t.
There I sat, repose like the thinking man, frozen for minutes. "Nate", I said, "I think you're right."
What do I aspire to as an information security professional; more readership or street cred than the next guy, or the respect of my peers for contributing to the greater good? Attention, press cycles, 15 minutes...it all has its allure, trust me on this.
But at the end of the day, I really do want to contribute to the greater good.
So I did something different. I sent my findings to McAfee and offered them an opportunity to respond, rather than publish first, ask questions later.
Here's the real kicker.
They responded.
I had a three hour lunch this past Thursday with two gentlemen from McAfee, who flew up from the Bay Area to Seattle to have a face to face with me. This, all by itself, speaks volumes to me. In addition to meeting with Kirk Lawrence, the new Director of Product Management for McAfee Secure, there I sat with, of all people, Joe Pierini, the very guy who has suffered more than his share of abuse, up to and including the Pwnie. As I have been a direct contributor and participant in heckling Joe, you can imagine our meeting could have been uncomfortable. It was not.
I have had expectations of McAfee and Scan Alert that to date have not been met, or my (your) perception has been that they have not been met.
This meeting was designed as an opportunity to voice some of these expectations, and see if McAfee, in turn, believed there was any merit to them.
Surprisingly, at least as spoken, we weren't all that far apart.
While, as a naive idealist, I believe that security should come before conversions, I am also grounded enough of a realize that the most attainable goal can be a marriage of both. This premise frames my expectations of McAfee.
Can they not be more of a "thought leader" for all the Ma & Pa websites who rely on McAfee Secure, first for a higher conversion rate, then security?
Can they not hold merchants to a higher standard, without alienating them and losing business?
Can they not embrace the security research community in a fashion that McAfee, the security community, the merchants, and consumers can all benefit from?
Can they not be more transparent in their approach, providing more details and feedback about their methods, their findings, and their vision?
I know McAfee Secure - Hacker Safe scans can find vulnerabilities.
I know they report the vulnerabilities to merchants.
What happens thereafter is where things begin to break down.
Can the scan engine be improved to find more vulns? Sure. That's really not that big a deal; technology can always be improved.
But, regarding holding merchants to a higher standard; therein is the whole point of this debate.
Anyone can throw a badge on a site.
But what happens when the site proves vulnerable is the key. I'll be candid here: I don't give a damn about the merchant at that point; it's the consumer who is at risk and needs something better from McAfee and their peers.
So, here begins a different approach. I know that making changes at a company the size of McAfee can be likened to the three miles it takes to turn around an aircraft carrier. I'm willing to work with them, and allow for a positive outcome.
I have been told that, in two or three weeks, we can expect a published standard, that clearly defines exactly what the McAfee Secure product offering adheres to, inclusive of their expectations for merchant remediation timelines, potential badge downgrades for unresolved vulnerabilities, and hopefully even a more clear stance on XSS.
I have been told that I will have the opportunity to discuss this standard, and invite feedback. Any standard is better than no standard.
I have also been told that this is just the beginning of changes that will lead to more of what I have hoped for in my expectations, over the next 6 months or so.
I am hopeful that we can take McAfee at their word, and even if slowly, see a positive outcome.
del.icio.us | digg
Tuesday, May 20, 2008
McAfee Partner isn't McAfee Secure either
Winferno.com is an authorized distributor of McAfee Software. OK.
They use Verisign 128-bit SSL to secure your transaction. Can't take issue with that.
All good so far...but wait!
Shouldn't a McAfee Partner be McAfee Secure?
Apparently not, and being one wouldn't have cured the XSS blues anyway.
Next in our video series, a supposedly secure shopping cart that is far from.
Here's an IFRAME.
Here's the cookie.
As well we know, coughing up the cookie counts as a really bad thing for any shopping cart, let alone an SSL protected shopping cart that happens to be a McAfee Partner and authorized distributor of McAfee Software. But lest we forget, McAfee doesn't count XSS as concerning.
Here's the video.
Huge props to Ronald van den Heetkamp for starting this whole debate years ago, and for exposing Brett Oliphant for the fraud that he is.
Fraud is the key word here. Hacker Safe was fraudulent, McAfee Secure is fraudulent, and buying from Winferno puts consumers at risk for being defrauded, not only due to horrendous site code, but perhaps bad business practices as well.
I won't even ask if McAfee has any standards, we already know the answer.
Their standards have left the building.
del.icio.us | digg
They use Verisign 128-bit SSL to secure your transaction. Can't take issue with that.
All good so far...but wait!
Shouldn't a McAfee Partner be McAfee Secure?
Apparently not, and being one wouldn't have cured the XSS blues anyway.
Next in our video series, a supposedly secure shopping cart that is far from.
Here's an IFRAME.
Here's the cookie.
As well we know, coughing up the cookie counts as a really bad thing for any shopping cart, let alone an SSL protected shopping cart that happens to be a McAfee Partner and authorized distributor of McAfee Software. But lest we forget, McAfee doesn't count XSS as concerning.
Here's the video.
Huge props to Ronald van den Heetkamp for starting this whole debate years ago, and for exposing Brett Oliphant for the fraud that he is.
Fraud is the key word here. Hacker Safe was fraudulent, McAfee Secure is fraudulent, and buying from Winferno puts consumers at risk for being defrauded, not only due to horrendous site code, but perhaps bad business practices as well.
I won't even ask if McAfee has any standards, we already know the answer.
Their standards have left the building.
del.icio.us | digg
Tuesday, December 16, 2008
So...you can hack a server with XSS?
It's been awhile since I've updated you, dear reader, regarding matters concerning McAfee Secure.
You may recall I met with Joe Pierini and Kirk Lawrence of McAfee Secure in August, and received an update regarding the still pending "McAfee Secure Standard" in October.
Sadly, both Joe and Kirk have left McAfee, in pursuit of better opportunities, leaving our McAfee Secure crusade in lurch. I'll be updating you on the Standard (allegedly, now being released in January), and other proposed improvements to the McAfee Secure offering in days to come. I have been informed that there are people at McAfee willing to carry on the work that Joe and Kirk started.
Now, that said, an update from Joe Pierini. You may recall the numerous times I, and many others, have heckled Joe for his Pwnie award winning statement "Cross-site scripting can't be used to hack a server."
Joe has surprised me at more than one interval; first, attending the Pwnie Awards ceremony at BlackHat 2008, and later, agreeing to fly to Seattle to meet with me and discuss considering significant changes and improvements in the McAfee Secure program.
What I've learned of Joe is that he is technically capable, a worthy web application security assessor and pen tester in his own right, and someone who prefers "breaking things" in the trenches, as opposed to promoting brands as an SE.
Having had numerous conversations with Joe since August, I believe this: the debate sparked by his now infamous "can't hack a server with XSS" statement came down to semantics and context. To be fair, the act of dropping javascript strings behind a vulnerable GET parameter is not a server hack per se, particularly if not utilized in a hybrid attack.
But enough from me; Joe explains just such a hybrid approach quite elegantly in a letter I recently received from him. It is reprinted here with his permission, and I appreciate the opportunity to share it.
Russ,
As you know, I left McAfee Secure in early December to join a security firm in San Jose as a Security Consultant. We provide PCI assurance services related to Merchants, Financial Institutions, Processors and Service Providers. As soon as I complete the PCI Security Standards Council's Qualified Security Assessor (QSA) training course, I will be assuming the responsibilities as a QSA but in the mean time I am performing penetration tests for clients needing to meet the PCI 11.3 requirements.
In one of my first engagements, I came upon a situation where there were no critical vulnerabilities and a few minor issues including XSS and a couple of Exchange mail servers with an open relay misconfiguration. These findings are sufficient with which to take a merchant out of PCI compliance but they lack the drama and urgency of more serious vulnerabilities like SQL Injection. My infamous, award winning catch phrase, “You can’t hack a server with it”, came back to haunt me. While you and I have agreed this is technically true, the the 11.3 penetration tests I was conducting are intended to exploit vulnerabilities. What I needed was an attack scenario that would get their attention and demonstrate the risk of having XSS in the web site.
The mail servers would only allow mail relaying to email addresses within the domain. They would provide the perfect delivery mechanism for the attack. A remote web server could be configured to host the attack pages for XSS Shell. This application ( http://labs.portcullis.co.uk/application/xssshell/) makes use of concepts first presented by XSS Proxy over 3 years ago: persistent, bi-directional communication with a client machine using XSS. The XSS Shell makes it possible to log keystrokes, steal the clipboard, execute arbitrary javascript and more. I don't need to hack the server with it, I could attack the entire company.
First, I could craft an email pretending to be from the web development team asking for help in testing a new piece of functionality in the website. I could then embed an HTML link in the page directing them to their own website, albeit with an attack exploiting the XSS weakness in their web site appended to it. Because the company users would receive an email with all the right headers from their own mail server and directing them to a site they own and inherently trusted, the click through rate would be extremely high and I could collect the session and clip board content from dozens of users. If my instinct was correct, I wouldn't need to upload arbitrary javascript because I would have enough to prove my point: XSS is dangerous and poses an immediate risk.
It’s not just about the servers or the clients, XSS can leave the entire company vulnerable to attack.
Best Regards,
--
Joseph Pierini | CISSP, CISM
Best regards indeed. Thank you, Joe.
del.icio.us | digg | Submit to Slashdot
You may recall I met with Joe Pierini and Kirk Lawrence of McAfee Secure in August, and received an update regarding the still pending "McAfee Secure Standard" in October.
Sadly, both Joe and Kirk have left McAfee, in pursuit of better opportunities, leaving our McAfee Secure crusade in lurch. I'll be updating you on the Standard (allegedly, now being released in January), and other proposed improvements to the McAfee Secure offering in days to come. I have been informed that there are people at McAfee willing to carry on the work that Joe and Kirk started.
Now, that said, an update from Joe Pierini. You may recall the numerous times I, and many others, have heckled Joe for his Pwnie award winning statement "Cross-site scripting can't be used to hack a server."
Joe has surprised me at more than one interval; first, attending the Pwnie Awards ceremony at BlackHat 2008, and later, agreeing to fly to Seattle to meet with me and discuss considering significant changes and improvements in the McAfee Secure program.
What I've learned of Joe is that he is technically capable, a worthy web application security assessor and pen tester in his own right, and someone who prefers "breaking things" in the trenches, as opposed to promoting brands as an SE.
Having had numerous conversations with Joe since August, I believe this: the debate sparked by his now infamous "can't hack a server with XSS" statement came down to semantics and context. To be fair, the act of dropping javascript strings behind a vulnerable GET parameter is not a server hack per se, particularly if not utilized in a hybrid attack.
But enough from me; Joe explains just such a hybrid approach quite elegantly in a letter I recently received from him. It is reprinted here with his permission, and I appreciate the opportunity to share it.
Russ,
As you know, I left McAfee Secure in early December to join a security firm in San Jose as a Security Consultant. We provide PCI assurance services related to Merchants, Financial Institutions, Processors and Service Providers. As soon as I complete the PCI Security Standards Council's Qualified Security Assessor (QSA) training course, I will be assuming the responsibilities as a QSA but in the mean time I am performing penetration tests for clients needing to meet the PCI 11.3 requirements.
In one of my first engagements, I came upon a situation where there were no critical vulnerabilities and a few minor issues including XSS and a couple of Exchange mail servers with an open relay misconfiguration. These findings are sufficient with which to take a merchant out of PCI compliance but they lack the drama and urgency of more serious vulnerabilities like SQL Injection. My infamous, award winning catch phrase, “You can’t hack a server with it”, came back to haunt me. While you and I have agreed this is technically true, the the 11.3 penetration tests I was conducting are intended to exploit vulnerabilities. What I needed was an attack scenario that would get their attention and demonstrate the risk of having XSS in the web site.
The mail servers would only allow mail relaying to email addresses within the domain. They would provide the perfect delivery mechanism for the attack. A remote web server could be configured to host the attack pages for XSS Shell. This application ( http://labs.portcullis.co.uk/application/xssshell/) makes use of concepts first presented by XSS Proxy over 3 years ago: persistent, bi-directional communication with a client machine using XSS. The XSS Shell makes it possible to log keystrokes, steal the clipboard, execute arbitrary javascript and more. I don't need to hack the server with it, I could attack the entire company.
First, I could craft an email pretending to be from the web development team asking for help in testing a new piece of functionality in the website. I could then embed an HTML link in the page directing them to their own website, albeit with an attack exploiting the XSS weakness in their web site appended to it. Because the company users would receive an email with all the right headers from their own mail server and directing them to a site they own and inherently trusted, the click through rate would be extremely high and I could collect the session and clip board content from dozens of users. If my instinct was correct, I wouldn't need to upload arbitrary javascript because I would have enough to prove my point: XSS is dangerous and poses an immediate risk.
It’s not just about the servers or the clients, XSS can leave the entire company vulnerable to attack.
Best Regards,
--
Joseph Pierini | CISSP, CISM
Best regards indeed. Thank you, Joe.
del.icio.us | digg | Submit to Slashdot
Friday, June 27, 2008
PC Universe is shrinking thanks to McAfee Secure's cluelessness
My web app sec friends know exactly how to push my red buttons. "Heh-heh, send it to Russ, he'll go off." Yep. ;-) Thanks, Rafal. Now I'm all spun up. I was sent two moronic gems this morning; one on the merits of McAfee Secure / Hacker Safe and the 109% sales increase it resulted in for PC Universe, the other an interview with the Internet's single biggest dillweed, Cresta Pillsbury. These articles are both a bit dated, but they equally embrace the premise of "trust" logos as a predominant sales driver, rather than any actual motivation to secure a site and protect consumers.
An example:
"If you’re doing conversion marketing and statistical testing on your website and you haven’t explored trust logos yet, then you’re missing out."
I must be the most naive person in the world; this enrages me. When will the idiots who write this crap get a clue? They've bought right into the hype the snake oil salesmen hoped they would and are now complicit in their failures.
Case in point, as seen in the Internet Retailer piece. By the way, I realize that Internet Retailer and basic web application security practices are completely at odds (as proven here), but this one deserves direct abuse.
"PC Universe first tested Hacker Safe on its own site in an A/B split test in which half the visitors saw the Hacker Safe seal and half did not. During that test, 7.3% more orders came from Hacker Safe shoppers than from the control group. PC Universe, which operates on the web at PCUniverse.com, is No. 360 in the Internet Retailer Top 500 Guide."
Really? Let's see what McAfee Secure / Hacker Safe has done to actually provide any measurable security benefit.
How about absolutely nothing.
Here's PC Universe's very current, verified McAfee Hacker Safe cert.
Now, here are a few ridiculous examples of reality from the this universe as opposed to the McAfee-twisted alternate universe. Please note, this is the "accountid" variable, and the fact that the marquee is rendered no less than eight times.
1)Marquee Remediated 6/30/08
2)XSS Deface Remediated 6/30/08
3)Cookie Remediated 6/30/08
Kudos for the quick fix PC Universe.
If you rather just see a video of these vulns, it's here.
PC Universe, rather than lauding your sales increases thanks to some POS logo, try securing your site code. I guarantee you have other issues.
McAfee Secure, once more, you are simply fraudulent to the core.
del.icio.us | digg
An example:
"If you’re doing conversion marketing and statistical testing on your website and you haven’t explored trust logos yet, then you’re missing out."
I must be the most naive person in the world; this enrages me. When will the idiots who write this crap get a clue? They've bought right into the hype the snake oil salesmen hoped they would and are now complicit in their failures.
Case in point, as seen in the Internet Retailer piece. By the way, I realize that Internet Retailer and basic web application security practices are completely at odds (as proven here), but this one deserves direct abuse.
"PC Universe first tested Hacker Safe on its own site in an A/B split test in which half the visitors saw the Hacker Safe seal and half did not. During that test, 7.3% more orders came from Hacker Safe shoppers than from the control group. PC Universe, which operates on the web at PCUniverse.com, is No. 360 in the Internet Retailer Top 500 Guide."
Really? Let's see what McAfee Secure / Hacker Safe has done to actually provide any measurable security benefit.
How about absolutely nothing.
Here's PC Universe's very current, verified McAfee Hacker Safe cert.
Now, here are a few ridiculous examples of reality from the this universe as opposed to the McAfee-twisted alternate universe. Please note, this is the "accountid" variable, and the fact that the marquee is rendered no less than eight times.
1)
2)
3)
Kudos for the quick fix PC Universe.
If you rather just see a video of these vulns, it's here.
PC Universe, rather than lauding your sales increases thanks to some POS logo, try securing your site code. I guarantee you have other issues.
McAfee Secure, once more, you are simply fraudulent to the core.
del.icio.us | digg
Monday, July 21, 2008
McAfee's Hacker Safe nominated for a Pwnie
Updated 7/22/08: The Pwnies have added Cresta Pillsbury's gem: "We go in like a super hacker." Bless McAfee | Scan Alert for lameness like this, it'd be hard to make this stuff up.
Mondays don't usually include such glorious highlights but I'll gladly pass on this exception. The Pwnie Awards 2008 nominations are out, and under Lamest Vendor Response we find McAfee's Hacker Safe, specifically Joesph Pierini's response to the findings XSSed.com and I gave to Thomas Claburn for publication in Information Week this past January.
Joseph Pierini, director of enterprise services for the "Hacker Safe" program, stepped in it when he said that XSS vulnerabilities can't be used to hack a server:
Cross-site scripting can't be used to hack a server. You may be able to do other things with it. You may be able to do things that affect the end-user or the client. But the customer data protected with the server, in the database, isn't going to be compromised by a cross-site scripting attack, not directly.
As you can imagine, this one gets my vote.
Winners will be announced at the BlackHat USA reception at Caesar's Palace, Las Vegas on Wednesday, August 6th, 2008.
Should you wish further reading on the McAfee Secure / Hacker Safe fiasco, you need only utilize this query or refer to all of Nate's coverage on Zero Day.
I must admit, I'm curious who McAfee will have at Black Hat to receive this prestigious award should they win. I'm torn between suggesting Brett Oliphant or Pierini himself. ;-)
Cheers.
del.icio.us | digg
Mondays don't usually include such glorious highlights but I'll gladly pass on this exception. The Pwnie Awards 2008 nominations are out, and under Lamest Vendor Response we find McAfee's Hacker Safe, specifically Joesph Pierini's response to the findings XSSed.com and I gave to Thomas Claburn for publication in Information Week this past January.
Joseph Pierini, director of enterprise services for the "Hacker Safe" program, stepped in it when he said that XSS vulnerabilities can't be used to hack a server:
Cross-site scripting can't be used to hack a server. You may be able to do other things with it. You may be able to do things that affect the end-user or the client. But the customer data protected with the server, in the database, isn't going to be compromised by a cross-site scripting attack, not directly.
As you can imagine, this one gets my vote.
Winners will be announced at the BlackHat USA reception at Caesar's Palace, Las Vegas on Wednesday, August 6th, 2008.
Should you wish further reading on the McAfee Secure / Hacker Safe fiasco, you need only utilize this query or refer to all of Nate's coverage on Zero Day.
I must admit, I'm curious who McAfee will have at Black Hat to receive this prestigious award should they win. I'm torn between suggesting Brett Oliphant or Pierini himself. ;-)
Cheers.
del.icio.us | digg
Friday, April 25, 2008
Still not Hacker Safe, roll the video
Accuse me of beating a dead horse, but this really ticks me off. While preparing content for my monthly column, as well as presentation content for the ISSA NW Regional Security Conference, I found yet another bunch of McAfee Hacker Safe branded sites that are completely vulnerable to cross-site scripting (XSS), as well as other issues. The video I took points out only reflected, non-persistent vulnerabilities...no sites were harmed in the making of the video, and all sites have been advised. Nonetheless, let me make my point yet one more time.
1) Sites that are vulnerable to XSS are not PCI compliant. All of the sites in this video take CC payments and store customer information.
2) The sites in this video have been vulnerable for months. Additionally, some have been advised multiple times and have simply ignored my notices. Their McAfee Hacker Safe branding is active and has not been removed at any time.
3) The McAfee Hacker Safe service claims XSS as part of its vulnerability checks; sites that are vulnerable to it should not be showing the McAfee Hacker Safe label in perpetuity.
THEY ARE NOT HACKER SAFE AND CONSUMERS ARE AT RISK.
Please join me in protest by adding a comment to my open letter to Ken Leonard, CEO of Scan Alert. Send them email, ask the sites to fix the issues.
Unknowing consumers deserve far more than false claims of security and empty assurances designed to grow McAfee/ScanAlert revenues.
As I am not the only person greatly concerned over this issue, please visit Rafal Los' fine blog for additional findings.
Enjoy the video.
del.icio.us | digg
1) Sites that are vulnerable to XSS are not PCI compliant. All of the sites in this video take CC payments and store customer information.
2) The sites in this video have been vulnerable for months. Additionally, some have been advised multiple times and have simply ignored my notices. Their McAfee Hacker Safe branding is active and has not been removed at any time.
3) The McAfee Hacker Safe service claims XSS as part of its vulnerability checks; sites that are vulnerable to it should not be showing the McAfee Hacker Safe label in perpetuity.
THEY ARE NOT HACKER SAFE AND CONSUMERS ARE AT RISK.
Please join me in protest by adding a comment to my open letter to Ken Leonard, CEO of Scan Alert. Send them email, ask the sites to fix the issues.
Unknowing consumers deserve far more than false claims of security and empty assurances designed to grow McAfee/ScanAlert revenues.
As I am not the only person greatly concerned over this issue, please visit Rafal Los' fine blog for additional findings.
Enjoy the video.
del.icio.us | digg
Monday, June 30, 2008
XSS Comedy at McAfee Secure's Expense
In celebration of the deadline for PCI Requirement 6.6 compliance as of June 30, 2008, I thought I'd share a little web app sec comedy at McAfee Secure's expense.
As well you should know by know, the existence of XSS vulnerabilities in a site that is required to meet PCI DSS standards means that the site IS NOT PCI COMPLIANT. Very simple, right?
Let's consider the McAfee Secure/Hacker Safe-branded site for Organize-It.
A seemingly handy site, perfect for your HGTV types, likely with healthy credit card limits. Uh-oh, here it comes. Oh yes, Organize-It handles credit cards and is thus beholden to PCI DSS.
Organize-It is also proudly displaying a current McAfee Secure badge, indicating that it's tested daily.
Given the focus of many a recent discussion it shouldn't shock you that Organize-It is vulnerable to XSS.
What's funny is what Organize-It does with regard to "handling" malformed requests.
Where a typical test string for XSS might be " script payload /script (characters removed or Blogger will let me XSS myself), you won't get much use from such a string via either direct form submittal or URL encoding. But when the site barfed up '; // LEAVE THIS VALUE var sli_cId = 90;, while under investigation, my ruh-roh meter went off.
I decided to play with my trusty marquee test and found interesting results. The actual search form field is limited to 41 characters (er?). So my complete string of " marquee message /marquee didn't fit for direct submittal BUT THE MARQUEE RENDERED ANYWAY! Basically, half the test string worked: " marquee h1 This_site_is_NOT_McAfee_S
Forget the marquee tag on the blacklist, did we?
But here's the real icing on the cake. The uber-intuitive search index reinterpreted my message with what I can only imagine are index keywords. Thus "This site is NOT McAfee Secure" scrolls across the Organize-It site as "this sit is not coffee secure".
OMG! My daily quad shot Americano has been pwn3d to the core!
Here's the URL if you don't believe me, or the video if you prefer.
Forget PCI compliance, bring on the Gong Show hook, Chuck!
Cheers.
del.icio.us | digg
As well you should know by know, the existence of XSS vulnerabilities in a site that is required to meet PCI DSS standards means that the site IS NOT PCI COMPLIANT. Very simple, right?
Let's consider the McAfee Secure/Hacker Safe-branded site for Organize-It.
A seemingly handy site, perfect for your HGTV types, likely with healthy credit card limits. Uh-oh, here it comes. Oh yes, Organize-It handles credit cards and is thus beholden to PCI DSS.
Organize-It is also proudly displaying a current McAfee Secure badge, indicating that it's tested daily.
Given the focus of many a recent discussion it shouldn't shock you that Organize-It is vulnerable to XSS.
What's funny is what Organize-It does with regard to "handling" malformed requests.
Where a typical test string for XSS might be " script payload /script (characters removed or Blogger will let me XSS myself), you won't get much use from such a string via either direct form submittal or URL encoding. But when the site barfed up '; // LEAVE THIS VALUE var sli_cId = 90;, while under investigation, my ruh-roh meter went off.
I decided to play with my trusty marquee test and found interesting results. The actual search form field is limited to 41 characters (er?). So my complete string of " marquee message /marquee didn't fit for direct submittal BUT THE MARQUEE RENDERED ANYWAY! Basically, half the test string worked: " marquee h1 This_site_is_NOT_McAfee_S
Forget the marquee tag on the blacklist, did we?
But here's the real icing on the cake. The uber-intuitive search index reinterpreted my message with what I can only imagine are index keywords. Thus "This site is NOT McAfee Secure" scrolls across the Organize-It site as "this sit is not coffee secure".
OMG! My daily quad shot Americano has been pwn3d to the core!
Here's the URL if you don't believe me, or the video if you prefer.
Forget PCI compliance, bring on the Gong Show hook, Chuck!
Cheers.
del.icio.us | digg
Tuesday, May 13, 2008
McAfee is NOT McAfee Secure
A challenge was put forth on Zero Day, and it has been answered.
Apparently, McAfee doesn't care about XSS on their own sites either.
I'll let the video speak for itself.
For the love of all thing good and proper, McAfee, please address this issue...for yourselves and the consumers who look to you to do the right thing.
Sincerely,
Russ McRee
del.icio.us | digg
Apparently, McAfee doesn't care about XSS on their own sites either.
I'll let the video speak for itself.
For the love of all thing good and proper, McAfee, please address this issue...for yourselves and the consumers who look to you to do the right thing.
Sincerely,
Russ McRee
del.icio.us | digg
Monday, May 12, 2008
Why PCI DSS is doomed.
Too much fun in the news to pass up on today.
First, the press release from McAfee indicating the obvious re-branding of McAfee Hacker Safe to McAfee Secure for Web Sites. Oh yes, dear friends, McAfee delivers the secure internet. The profound and deeply flawed arrogance continues, with a new name.
Rafal Los has already torn into this one, so I'll let you get the goods there, but after reading further I saw this gem:
Yep, full steam ahead. Now your credit cards are really going to be safe.
As you may know the previously vague PCI DSS 6.6 language has been made even more elusive with such useful language as:
"Keeping in mind that the objective of Requirement 6.6 is to prevent exploitation of common vulnerabilities (such as those listed in Requirement 6.5), several possible solutions may be considered. They are dynamic and pro-active, requiring the specific initiation of a manual or automated process. Properly implemented, one or more of these four alternatives could meet the intent of Option 1 and provide the minimum level of protection against common web application threats."
Such strong assertions: possible, may, could. We wouldn't want to actually commit, would we?
As if all of this wasn't enough, along comes the PCI mastery of the PCI Blog - Compliance Demystified, from pcianswers.com.
You'll get a 404 now, but here's the cached page.
Yep, a QSA actually debating the merits of ScanlessPCI.
"From what we can ascertain, ScanlessPCI.com is just a scam."
Really? We weren't sure.
"The larger concern is the fact that they require you to insert code into your Web site to get a copy of their certificate. Since you are inserting code into your Web page for a GIF, it is anyone’s guess as to whether or not they are hacking your site at the same time they are supposedly protecting it."
Oh, scary. Common, guys. I think you should insert this picture on your website. Then your customers can feel truly confident in your services. Man, my ribs still hurt from laughing.
del.icio.us | digg
First, the press release from McAfee indicating the obvious re-branding of McAfee Hacker Safe to McAfee Secure for Web Sites. Oh yes, dear friends, McAfee delivers the secure internet. The profound and deeply flawed arrogance continues, with a new name.
Rafal Los has already torn into this one, so I'll let you get the goods there, but after reading further I saw this gem:
Yep, full steam ahead. Now your credit cards are really going to be safe.
As you may know the previously vague PCI DSS 6.6 language has been made even more elusive with such useful language as:
"Keeping in mind that the objective of Requirement 6.6 is to prevent exploitation of common vulnerabilities (such as those listed in Requirement 6.5), several possible solutions may be considered. They are dynamic and pro-active, requiring the specific initiation of a manual or automated process. Properly implemented, one or more of these four alternatives could meet the intent of Option 1 and provide the minimum level of protection against common web application threats."
Such strong assertions: possible, may, could. We wouldn't want to actually commit, would we?
As if all of this wasn't enough, along comes the PCI mastery of the PCI Blog - Compliance Demystified, from pcianswers.com.
You'll get a 404 now, but here's the cached page.
Yep, a QSA actually debating the merits of ScanlessPCI.
"From what we can ascertain, ScanlessPCI.com is just a scam."
Really? We weren't sure.
"The larger concern is the fact that they require you to insert code into your Web site to get a copy of their certificate. Since you are inserting code into your Web page for a GIF, it is anyone’s guess as to whether or not they are hacking your site at the same time they are supposedly protecting it."
Oh, scary. Common, guys. I think you should insert this picture on your website. Then your customers can feel truly confident in your services. Man, my ribs still hurt from laughing.
del.icio.us | digg
Tuesday, January 15, 2008
Hacker Safe? Not so much.
Likely you've all read about Hacker Safe certified Geeks.com being hacked. ScanAlert, recently bought by McAfee, says that "research indicates sites remotely scanned for known vulnerabilities on a daily basis, such as those earning 'Hacker Safe' certification, can prevent over 99% of hacker crime."
I agree...but here comes strike two.
I was happily bouncing about the internet looking for things that should be fixed, when what did I see at Toastmasters International but a McAfee Hacker Safe certificate. Ever the skeptic, I said to myself "Prove it." But, of course, because my white hat and professional values require it, I remembered that first, do no harm are words to live by. But a wee script test in a form field can't hurt, right?
There's video of this here if you prefer.
Let's begin.
Here's the Advanced Search page, note the McAfee Hacker Safe tag in the lower right:
Then, said little test script about to be submitted to the Advanced Search page:
Ruh roh, Rastro. Can you say XSS?
Man, that's not good, so let's try a bit more trickery.
XSSed indeed.
Something tells me the McAfee Hacker Safe service offering would do well to dig a little deeper before certifying a site.
Meanwhile, sanitizing input might not be a bad idea for our Toastmasters friends.
Play nice until Toastmasters gets a chance to fix it, please. I've already let them know.
Cheers.
del.icio.us | digg
I agree...but here comes strike two.
I was happily bouncing about the internet looking for things that should be fixed, when what did I see at Toastmasters International but a McAfee Hacker Safe certificate. Ever the skeptic, I said to myself "Prove it." But, of course, because my white hat and professional values require it, I remembered that first, do no harm are words to live by. But a wee script test in a form field can't hurt, right?
There's video of this here if you prefer.
Let's begin.
Here's the Advanced Search page, note the McAfee Hacker Safe tag in the lower right:
Then, said little test script about to be submitted to the Advanced Search page:
Ruh roh, Rastro. Can you say XSS?
Man, that's not good, so let's try a bit more trickery.
XSSed indeed.
Something tells me the McAfee Hacker Safe service offering would do well to dig a little deeper before certifying a site.
Meanwhile, sanitizing input might not be a bad idea for our Toastmasters friends.
Play nice until Toastmasters gets a chance to fix it, please. I've already let them know.
Cheers.
del.icio.us | digg
Tuesday, August 05, 2008
Cross-site scripting CAN be used to hack a server
UPDATE: They won the Pwnie for this at Black Hat! More surprising is the fact that allegedly someone from McAfee showed up to accept. At least they have a sense of humor. More details soon.
Likely you remember when Joseph Pierini at McAfee Secure / Hacker Safe said XSS wasn't important because "cross-site scripting can't be used to hack a server. You may be able to do other things with it. You may be able to do things that affect the end-user or the client. But the customer data protected with the server, in the database, isn't going to be compromised by a cross-site scripting attack, not directly."
That gem has made McAfee Pwnie worthy (winners announced tomorrow!); may the Lamest Vendor win.
That said, anyone with a clue knows that XSS attacks are ideal for credential theft, and if you can steal credentials, you can hack a server.
Looking for a textbook example? Check out mckt's new blog, skeptikal.org.
Here's a highlight:
"Every cPanel user's account contains a file titled .contactemail in its home directory. This is used to tell the server and administrators who to email when things go south, and can be changed by the user through the cPanel interface, the file manager tool, FTP, or through local scripts. It's only a text file, after all. Assuming we set our email address to:
"onmouseover="alert(1337)
When the friendly system administrator tries to reset our email address (because we forgot our password, obviously), he will receive an alert box in his browser.
But an alert box doesn't really demonstrate anything. Fortunately the WHM (Web Hosting Manager) interface has enough functionality that we can perform just about any system-level task we want. This one will reset the root password to 'owned':
"onmouseover="f=document.forms[0];f.action='/scripts/passwd';f.user.value='root';
f.removeChild(f.domain);d=document.createElement('input');f.appendChild(d);
d.name='password';d.value='owned';d=document.createElement('input');f.appendChild(d);
d.name='password2';d.value='owned';f.submit()
Of course, the only limit is your imagination- WHM can set up cron jobs, add and delete users, send full backups to a server of your choice, and reformat hard drives."
Hmm...I'd say that would be a server hack. ;-)
Welcome, Mike...keep up the good work.
del.icio.us | digg
Likely you remember when Joseph Pierini at McAfee Secure / Hacker Safe said XSS wasn't important because "cross-site scripting can't be used to hack a server. You may be able to do other things with it. You may be able to do things that affect the end-user or the client. But the customer data protected with the server, in the database, isn't going to be compromised by a cross-site scripting attack, not directly."
That gem has made McAfee Pwnie worthy (winners announced tomorrow!); may the Lamest Vendor win.
That said, anyone with a clue knows that XSS attacks are ideal for credential theft, and if you can steal credentials, you can hack a server.
Looking for a textbook example? Check out mckt's new blog, skeptikal.org.
Here's a highlight:
"Every cPanel user's account contains a file titled .contactemail in its home directory. This is used to tell the server and administrators who to email when things go south, and can be changed by the user through the cPanel interface, the file manager tool, FTP, or through local scripts. It's only a text file, after all. Assuming we set our email address to:
"onmouseover="alert(1337)
When the friendly system administrator tries to reset our email address (because we forgot our password, obviously), he will receive an alert box in his browser.
But an alert box doesn't really demonstrate anything. Fortunately the WHM (Web Hosting Manager) interface has enough functionality that we can perform just about any system-level task we want. This one will reset the root password to 'owned':
"onmouseover="f=document.forms[0];f.action='/scripts/passwd';f.user.value='root';
f.removeChild(f.domain);d=document.createElement('input');f.appendChild(d);
d.name='password';d.value='owned';d=document.createElement('input');f.appendChild(d);
d.name='password2';d.value='owned';f.submit()
Of course, the only limit is your imagination- WHM can set up cron jobs, add and delete users, send full backups to a server of your choice, and reformat hard drives."
Hmm...I'd say that would be a server hack. ;-)
Welcome, Mike...keep up the good work.
del.icio.us | digg
Wednesday, April 29, 2009
Recommendations for trustmark providers
I've been slow in responding to Pete Lindstrom's (Spire Security) prompt for recommendations and solutions for trustmark (security badge) providers, beyond my typical griping about same.
I appreciate Pete's candor and perspective, and shall endeavor to make amends.
Having repetitively taken issue with trustmarks, with McAfee Secure\Hackersafe facing the brunt of it, I propose the following to ALL trustmark providers, as I did during the creation of the McAfee Secure Standard.
1) Check the arrogance and sales hype at the door.
We have no doubt that you're in business to drive conversions first and security second, so just be honest about it.
We also have no doubt that there will be vulnerabilities in your customer's sites, so cut out the "we guarantee their security" angle and opt for the "we do the best we can to contribute to the security and well being of our customers, and their customers" approach.
2) Practice transparency.
How do you scan (very specifically)? If you simply run Nessus, say so. If you make use of custom algorithms and signatures, say so.
3) Publish your standard, most importantly inclusive of your intentions on how to enforce it.
If a customer's site is not compliant, how and when, if at all, will you pull down the trustmark badge?
I can't believe I'm about to say this but McAfee Secure really has set the standard for establishing a standard. While I believe it to be lacking in areas, at least they have one.
4) Actually enforce.
So often I've found websites in flagrant violation of any feasible security standards, and yet they display a trustmark. This simply should not be. It is misleading, dishonest, and deceptive.
5) Offer resources.
As an alleged security provider, offer your customers resources. Not just the "use SSL and all is well" bunk. Real resources: OWASP, SANS Top 25, SDL, how-to, the list goes on.
6) Provide an immediately evident point of contact for your trustmark program; an abuse@, security@, and/or info@ alias to which we can report sites we determine to be vulnerable.
I have found it difficult in the past to disclose vulnerabilities; it shouldn't be.
7) Offer incentives.
People often do well with incentive. A reward system for strong security practices demonstrated by your customers will reap benefits, and adversely, so too will a punishment system for non-performers.
Note: Keep a close eye on Skeptikal.org. Mike's of the same mindset, and has applied this spirit of thinking to PCI ASVs who themselves have missed the mark on security, while holding others to the embattled PCI DSS. Look for some interesting content next week.
Finally, dear trustmark provider, think integrity. Operating from that position should lead you down the right path.
del.icio.us | digg | Submit to Slashdot
I appreciate Pete's candor and perspective, and shall endeavor to make amends.
Having repetitively taken issue with trustmarks, with McAfee Secure\Hackersafe facing the brunt of it, I propose the following to ALL trustmark providers, as I did during the creation of the McAfee Secure Standard.
1) Check the arrogance and sales hype at the door.
We have no doubt that you're in business to drive conversions first and security second, so just be honest about it.
We also have no doubt that there will be vulnerabilities in your customer's sites, so cut out the "we guarantee their security" angle and opt for the "we do the best we can to contribute to the security and well being of our customers, and their customers" approach.
2) Practice transparency.
How do you scan (very specifically)? If you simply run Nessus, say so. If you make use of custom algorithms and signatures, say so.
3) Publish your standard, most importantly inclusive of your intentions on how to enforce it.
If a customer's site is not compliant, how and when, if at all, will you pull down the trustmark badge?
I can't believe I'm about to say this but McAfee Secure really has set the standard for establishing a standard. While I believe it to be lacking in areas, at least they have one.
4) Actually enforce.
So often I've found websites in flagrant violation of any feasible security standards, and yet they display a trustmark. This simply should not be. It is misleading, dishonest, and deceptive.
5) Offer resources.
As an alleged security provider, offer your customers resources. Not just the "use SSL and all is well" bunk. Real resources: OWASP, SANS Top 25, SDL, how-to, the list goes on.
6) Provide an immediately evident point of contact for your trustmark program; an abuse@, security@, and/or info@ alias to which we can report sites we determine to be vulnerable.
I have found it difficult in the past to disclose vulnerabilities; it shouldn't be.
7) Offer incentives.
People often do well with incentive. A reward system for strong security practices demonstrated by your customers will reap benefits, and adversely, so too will a punishment system for non-performers.
Note: Keep a close eye on Skeptikal.org. Mike's of the same mindset, and has applied this spirit of thinking to PCI ASVs who themselves have missed the mark on security, while holding others to the embattled PCI DSS. Look for some interesting content next week.
Finally, dear trustmark provider, think integrity. Operating from that position should lead you down the right path.
del.icio.us | digg | Submit to Slashdot
Friday, January 18, 2008
XSS and PCI: Not compliant, or Hacker Safe
As a follow up to the last post on sites vulnerable to XSS that are certified McAfee Hacker Safe, there is more to this story.
Of the additional sites listed in Thomas Claburn's recent Information Week article, many take credit cards online and are thus required to comply with PCI DSS 1.1.
If a website is vulnerable to XSS, THE COMPANY IS NOT PCI COMPLIANT.
Supporting language from the Payment Card Industry Data Security Standard:
6.5 Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project guidelines. Review custom application code to identify coding vulnerabilities. Cover prevention of common coding vulnerabilities in software development processes, to include the following:
6.5.1 Unvalidated input
6.5.2 Broken access control (for example, malicious use of user IDs)
6.5.3 Broken authentication and session management (use of account credentials and session
cookies)
6.5.4 Cross-site scripting (XSS) attacks
So not only can we call into question the validity of the Hacker Safe label, we can question how these businesses can be considered PCI compliant. Again, see the Information Week article for the list of sites.
For further consideration, what if these businesses, as McAfee Hacker Safe customers, are signed up for their Scan Alert PCI service?
"To validate compliance with the PCI DSS, a merchant, service provider, and/or financial institution may be required to undergo a PCI Security Scan conducted by an Approved Scanning Vendor (ASV)."
Are there potential gaps here as well?
del.icio.us | digg
Of the additional sites listed in Thomas Claburn's recent Information Week article, many take credit cards online and are thus required to comply with PCI DSS 1.1.
If a website is vulnerable to XSS, THE COMPANY IS NOT PCI COMPLIANT.
Supporting language from the Payment Card Industry Data Security Standard:
6.5 Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project guidelines. Review custom application code to identify coding vulnerabilities. Cover prevention of common coding vulnerabilities in software development processes, to include the following:
6.5.1 Unvalidated input
6.5.2 Broken access control (for example, malicious use of user IDs)
6.5.3 Broken authentication and session management (use of account credentials and session
cookies)
6.5.4 Cross-site scripting (XSS) attacks
So not only can we call into question the validity of the Hacker Safe label, we can question how these businesses can be considered PCI compliant. Again, see the Information Week article for the list of sites.
For further consideration, what if these businesses, as McAfee Hacker Safe customers, are signed up for their Scan Alert PCI service?
"To validate compliance with the PCI DSS, a merchant, service provider, and/or financial institution may be required to undergo a PCI Security Scan conducted by an Approved Scanning Vendor (ASV)."
Are there potential gaps here as well?
del.icio.us | digg
Tuesday, March 24, 2009
Why trust marks can't be trusted
Trustmarks & security badges don't provide security, just false confidence.
Hopefully,a month or so ago, you noticed the headlines and have read that Geeks.com, via its parent company Genica Corp, has settled with the FTC and will allow "allow federal regulators to monitor its website security for 10 years to settle charges it violated federal laws requiring it to adequately safeguard sensitive customer data."
I'd be remiss in my duties if I didn't remind you, dear reader, that Geeks.com was a Hacker Safe (now McAfee Secure) site.
I'm certain that if you've ever read my blog before you know I've taken McAfee Secure to task numerous times, and consider my point well established.
It's all really part of a larger discussion that should come as no surprise.
The only value of a trust mark/security badge is to the merchant wielding it, often under false pretenses. I've not met a trust mark yet amongst whose customers I couldn't find web application security flaws.
Forget what this means for PCI compliance. Every one of the examples I'm about to present is likely beholden to PCI in some form or fashion.
The reality is, they all display a trust mark, and aren't worthy of that trust. Consumers are at risk, plain and simple.
Let's explore, shall we?
There's WebSafe Shield's Hacker Free Site, or Comodo's HackerProof, perhaps Security Metrics Credit Card Safe(more on them in the near future), and my new favorite in security hilarity, Control Scan.
Remember former Hacker Safe fangirl, Cresta Pillsbury, she of "we go in like a super hacker" fame? When she jumped ship with jaded judiciousness, she placed herself squarely in Control Scan's camp carte blanche. Talk about the blind leading the blind.
In the interest of protecting customers and merchants (who've ignored disclosure notices), I'm going to provide screen shots a variety of vulnerabilities, without indicating who sufferers from it specifically. Rather, we'll focus only the trust marks displayed handsomely next to the realized vulnerability.
We'll begin with WebSafe Shield's Hacker Free Site. Here's an example IFRAMEd with a real trust mark innovator, Scanless PCI:
Here's a ControlScan customer, IFRAMEd with XSSed.com:
Finally, this one's my favorite. This is a Comodo Hacker Proof site (you'll have to trust me on this (pun intended)), helpfully barfing database schema for the world to read:
Need I remind you that any merchant receiving customer PII and credit card data that is vulnerable to XSS, CSRF, or SQLi is not Hacker Proof, or Hacker Free, or Hacker Safe?
They should simply be labeled Hacker Ready.
*sigh*...now I'm depressed.
Thanks to Joe Pierini for participating with me in this conversation for some time now.
del.icio.us | digg | Submit to Slashdot
Hopefully,a month or so ago, you noticed the headlines and have read that Geeks.com, via its parent company Genica Corp, has settled with the FTC and will allow "allow federal regulators to monitor its website security for 10 years to settle charges it violated federal laws requiring it to adequately safeguard sensitive customer data."
I'd be remiss in my duties if I didn't remind you, dear reader, that Geeks.com was a Hacker Safe (now McAfee Secure) site.
I'm certain that if you've ever read my blog before you know I've taken McAfee Secure to task numerous times, and consider my point well established.
It's all really part of a larger discussion that should come as no surprise.
The only value of a trust mark/security badge is to the merchant wielding it, often under false pretenses. I've not met a trust mark yet amongst whose customers I couldn't find web application security flaws.
Forget what this means for PCI compliance. Every one of the examples I'm about to present is likely beholden to PCI in some form or fashion.
The reality is, they all display a trust mark, and aren't worthy of that trust. Consumers are at risk, plain and simple.
Let's explore, shall we?
There's WebSafe Shield's Hacker Free Site, or Comodo's HackerProof, perhaps Security Metrics Credit Card Safe(more on them in the near future), and my new favorite in security hilarity, Control Scan.
Remember former Hacker Safe fangirl, Cresta Pillsbury, she of "we go in like a super hacker" fame? When she jumped ship with jaded judiciousness, she placed herself squarely in Control Scan's camp carte blanche. Talk about the blind leading the blind.
In the interest of protecting customers and merchants (who've ignored disclosure notices), I'm going to provide screen shots a variety of vulnerabilities, without indicating who sufferers from it specifically. Rather, we'll focus only the trust marks displayed handsomely next to the realized vulnerability.
We'll begin with WebSafe Shield's Hacker Free Site. Here's an example IFRAMEd with a real trust mark innovator, Scanless PCI:
Here's a ControlScan customer, IFRAMEd with XSSed.com:
Finally, this one's my favorite. This is a Comodo Hacker Proof site (you'll have to trust me on this (pun intended)), helpfully barfing database schema for the world to read:
Need I remind you that any merchant receiving customer PII and credit card data that is vulnerable to XSS, CSRF, or SQLi is not Hacker Proof, or Hacker Free, or Hacker Safe?
They should simply be labeled Hacker Ready.
*sigh*...now I'm depressed.
Thanks to Joe Pierini for participating with me in this conversation for some time now.
del.icio.us | digg | Submit to Slashdot
Friday, May 09, 2008
Hacker Free Site?...Yeah, right.
So as not to seemingly pick only on McAfee Hacker Safe, I thought it appropriate to show just how ridiculous the entire premise of calling anything Hacker Safe, Hacker Proof, and now WebSafe Shield Hacker Free Site really is. For you, dear reader, a new video for your streaming pleasure, courtesy of the WebSafe Shield Hacker Free Site.
My brother in arms in the battle against BS, Rafal Los, has already called out Comodo for their Hacker Proof fluff on the Digital Soapbox.
I simply couldn't let this one pass without a little extra scrutiny. I Googled hacker safe to see what else popped up and bam, there's WebSafe Shield in the sponsored links for "70% less than Hacker Safe" to boot!
I had literally about ten minutes to kill, and in less than two minutes, more XSS silliness courtesy of the sites with starring roles in the latest installation in our growing video series. The home page for WebSafe Shield lists frictionent.com and shoppingvale.com with such inanities as "My customers feel more safe and more likely to sign up knowing I operate a secure website." and "If you're interested in increasing your conversions, I'd suggest you sign up for WebSafe Shield." Doesn't that sum it up? Forget protecting the consumer. Let's just blindly lead the sheep to the wolves with some Hacker Free Site logo that means nothing in order to "increase conversions."
WebSafe Shield vaguely discuss their methodology here; I just love:
#6 - How do you conduct your security scans?
"We use industry-standard software and methodologies to scan, test and identify security vulnerabilities. We first scan for open ports, and for each open port, we identify the service and software for that port, and report any security vulnerabilities."
Wow, open ports. Let me guess...you're using Nessus?
The only discussion of web application security is on their rather vague Security Tips page. It's a perfectly generic read and they make no mention of actually scanning for those vulns, only open ports, and that they "report any security vulnerabilities." Maybe they keep it vague intentionally so they can more easily duck the criticism. I can imagine the answer to this question. Why are both the sites proudly listed front and center on your home page vulnerable to XSS and yet showing their WebSafe Shield Hacker Free Site logos? Likely because they only mention XSS, but don't actually scan for it. Probably not SQLi either. Just open ports. Please. Maybe that 70% discount over Hacker Safe means you're not making enough to build a service that can find XSS, the most prevalent of all web application vulnerabilities.
I'll say the same thing to WebSafe Shield that I've said to McAfee. Stop misleading people with some crappy little logo that you wouldn't take down for anything in the world (you wouldn't want to tick off your customer base, right?).
What about the consumers using those sites who actually fall for your misleading false premises? What's your answer to them? XSS doesn't count because you can't hack the server with it? Who is the victim of a well executed XSS attack?
The consumer, not your ill-coding customers.
In case you missed it earlier, here's the video.
The last little gem, and I quote: "Our security professionals are CISSP (Certified Information Systems Security Professional) certified." Oh goody. Maybe you can charge a wee bit more than "70% less than Hacker Safe" and help your customers build secure web apps on behalf of consumers, rather than driving conversions on behalf of your customers, and ultimately your investors.
WebSafe Shield, you're welcome to comment.
del.icio.us | digg
My brother in arms in the battle against BS, Rafal Los, has already called out Comodo for their Hacker Proof fluff on the Digital Soapbox.
I simply couldn't let this one pass without a little extra scrutiny. I Googled hacker safe to see what else popped up and bam, there's WebSafe Shield in the sponsored links for "70% less than Hacker Safe" to boot!
I had literally about ten minutes to kill, and in less than two minutes, more XSS silliness courtesy of the sites with starring roles in the latest installation in our growing video series. The home page for WebSafe Shield lists frictionent.com and shoppingvale.com with such inanities as "My customers feel more safe and more likely to sign up knowing I operate a secure website." and "If you're interested in increasing your conversions, I'd suggest you sign up for WebSafe Shield." Doesn't that sum it up? Forget protecting the consumer. Let's just blindly lead the sheep to the wolves with some Hacker Free Site logo that means nothing in order to "increase conversions."
WebSafe Shield vaguely discuss their methodology here; I just love:
#6 - How do you conduct your security scans?
"We use industry-standard software and methodologies to scan, test and identify security vulnerabilities. We first scan for open ports, and for each open port, we identify the service and software for that port, and report any security vulnerabilities."
Wow, open ports. Let me guess...you're using Nessus?
The only discussion of web application security is on their rather vague Security Tips page. It's a perfectly generic read and they make no mention of actually scanning for those vulns, only open ports, and that they "report any security vulnerabilities." Maybe they keep it vague intentionally so they can more easily duck the criticism. I can imagine the answer to this question. Why are both the sites proudly listed front and center on your home page vulnerable to XSS and yet showing their WebSafe Shield Hacker Free Site logos? Likely because they only mention XSS, but don't actually scan for it. Probably not SQLi either. Just open ports. Please. Maybe that 70% discount over Hacker Safe means you're not making enough to build a service that can find XSS, the most prevalent of all web application vulnerabilities.
I'll say the same thing to WebSafe Shield that I've said to McAfee. Stop misleading people with some crappy little logo that you wouldn't take down for anything in the world (you wouldn't want to tick off your customer base, right?).
What about the consumers using those sites who actually fall for your misleading false premises? What's your answer to them? XSS doesn't count because you can't hack the server with it? Who is the victim of a well executed XSS attack?
The consumer, not your ill-coding customers.
In case you missed it earlier, here's the video.
The last little gem, and I quote: "Our security professionals are CISSP (Certified Information Systems Security Professional) certified." Oh goody. Maybe you can charge a wee bit more than "70% less than Hacker Safe" and help your customers build secure web apps on behalf of consumers, rather than driving conversions on behalf of your customers, and ultimately your investors.
WebSafe Shield, you're welcome to comment.
del.icio.us | digg
Wednesday, May 28, 2008
SaaS Snake Oil Top Ten, with video
As I was happily sniffing about for more annoying vendor fodder a few nights ago, I found a true gem. I was actually investigating ControlScan's practices and came across some poor hapless site owner that had been manipulated into buying both the ControlScan service and McAfee Secure / Hacker Safe by not one, but two snake oil salesmen.
This site was bound to be secure, right? Wrong!
Here's a new video to detail the inadequacies of both these services, at the same time.
But, as my disdain for these con artists grew yet stronger, it occurred to me (with the suggestion of an unnamed accomplice) that we needed a Letterman-like Top Ten list.
In this case SaaS will denote scanning as a service, rather than software or security, as security is the last thing these daft gits offer. These are all real statements, claims or quotes from these so called services.
Top Ten 10 signs the SaaS sales guy in front of you if offering up snake oil.
10. We first scan for open ports.
9. If you're interested in increasing your conversions, I'd suggest you sign up for WebSafe Shield.
8. Al Gore is on our board.
7. We held a hacker contest to break our security, and no one did.
6. We want to be the trusted partner who’s at your side, day by day, year to year,to help your business grow.
5. Increase your conversion rate or double your money back!
4. Our Web-based PCI Compliance 1-2-3 solution includes everything you need.
3. The "Verified Secure" mark appears only when a web site's security meets the highest security scanning standards of the U.S. government.
2. Unfortunately, the automated scanning technology we use doesn’t have this XSS scanning.
1. We go in like a super hacker.
There will be no rest for their souls in the afterlife; the web app security gods have a special in hell for salesmen and companies like this. ;-)
del.icio.us | digg
This site was bound to be secure, right? Wrong!
Here's a new video to detail the inadequacies of both these services, at the same time.
But, as my disdain for these con artists grew yet stronger, it occurred to me (with the suggestion of an unnamed accomplice) that we needed a Letterman-like Top Ten list.
In this case SaaS will denote scanning as a service, rather than software or security, as security is the last thing these daft gits offer. These are all real statements, claims or quotes from these so called services.
Top Ten 10 signs the SaaS sales guy in front of you if offering up snake oil.
10. We first scan for open ports.
9. If you're interested in increasing your conversions, I'd suggest you sign up for WebSafe Shield.
8. Al Gore is on our board.
7. We held a hacker contest to break our security, and no one did.
6. We want to be the trusted partner who’s at your side, day by day, year to year,to help your business grow.
5. Increase your conversion rate or double your money back!
4. Our Web-based PCI Compliance 1-2-3 solution includes everything you need.
3. The "Verified Secure" mark appears only when a web site's security meets the highest security scanning standards of the U.S. government.
2. Unfortunately, the automated scanning technology we use doesn’t have this XSS scanning.
1. We go in like a super hacker.
There will be no rest for their souls in the afterlife; the web app security gods have a special in hell for salesmen and companies like this. ;-)
del.icio.us | digg
Wednesday, November 25, 2009
Fun with fake Flash: an Abode update you don't want
Jericho of Attrition.org (support the Open Security Foundation!) recently asked the VIM mailing list a question: Adobe Flash - vuln or just "design"?
The question, inspired by Mike Bailey's work for Foreground Security, leads to healthy debate, including press and vendor response. But, ironically the same day I received the VIM mail, I was led to explore a slightly different perspective on Adobe Flash issues. Thus, your author doesn't intend to get in the middle of above proposed curmudgeonly discussion.
I am however inspired to be curmudgeonly; grumpy even.
The crux of this conversation is the fact that the oft updated Adobe Flash Player continuously proves to be social engineering attack vector fodder. This is by no means news, or likely a surprise to the 19 of you who read this blog, but I recently stumbled on a real gem in the wild and I thought I'd share.
Whilst defending the Intarwebs from evildoers, I spotted
hxxp://www.abodeplugin.com/flashpayer/thankyou/flashplayer.htm
Explore this site at your peril, the binary sure isn't Adobe's; nor is it any update you want to install.
First, the use of letter juxtaposition (Adobe to Abode) is a pretty smooth endeavor likely to be missed by happily unaware clickers.
Second, the faux page layout is built largely right from the source Abod...er, Adobe site.
This irony is not lost on me: this "update" page is so pure it includes JSON formatted addon offers from Adobe, including a free McAfee Security Scan. Woot! You're going to likely need one if you install plugin.exe.
Speaking of, plugin.exe is a Trojan-Downloader.Win32.Genome sample that would normally go grab additional ill-intended binaries. Runtime analysis showed some common behaviors, though this sample seemed rather neutered.
1) Spawned a process and created C:\WINDOWS\system32\services.exe
2) Made a call to 212.180.97.163 (hxxp://www.sofec.21s.fr/k70.htm), now resulting in a 404.
3) Strings output was amusing (highlights parsed):
Buffer overrun detected!
unable to initialize heap
unexpected heap error
HeapDestroy
HeapCreate
HeapReAlloc
HeapSize
show me the money!
Nice. Really?
Who knows what additional evilware once lurked at 212.180.97.163, but it wasn't likely removed by anyone thinking clearly. The site hosted there is in miserable shape, suffering from numerous issues including SQL injection, horribly managed Frontpage extensions, cross-site scripting, and more. Which is to say, "give any one species too much rope and they'll f**k it up" (Roger Waters from Amused to Death).
So what's the lesson?
Negligence begets opportunity.
Opportunity begets maliciousness.
Maliciousness begets victimization.
Simple, yet entirely preventable.
The above mentioned combination of bad web application security and common malware practices likely means that someone may not have a nice Thanksgiving and that makes me sad. I don't like to be sad.
So beware fake Flash updates and button up your crappy websites so jerkwater ne'er-do-well's have less opportunity, damn it!
I am thankful for my dear family and all 19 of you readers.
Pass the Tofurkey!
Cheers.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
The question, inspired by Mike Bailey's work for Foreground Security, leads to healthy debate, including press and vendor response. But, ironically the same day I received the VIM mail, I was led to explore a slightly different perspective on Adobe Flash issues. Thus, your author doesn't intend to get in the middle of above proposed curmudgeonly discussion.
I am however inspired to be curmudgeonly; grumpy even.
The crux of this conversation is the fact that the oft updated Adobe Flash Player continuously proves to be social engineering attack vector fodder. This is by no means news, or likely a surprise to the 19 of you who read this blog, but I recently stumbled on a real gem in the wild and I thought I'd share.
Whilst defending the Intarwebs from evildoers, I spotted
hxxp://www.abodeplugin.com/flashpayer/thankyou/flashplayer.htm
Explore this site at your peril, the binary sure isn't Adobe's; nor is it any update you want to install.
First, the use of letter juxtaposition (Adobe to Abode) is a pretty smooth endeavor likely to be missed by happily unaware clickers.
Second, the faux page layout is built largely right from the source Abod...er, Adobe site.
This irony is not lost on me: this "update" page is so pure it includes JSON formatted addon offers from Adobe, including a free McAfee Security Scan. Woot! You're going to likely need one if you install plugin.exe.
Speaking of, plugin.exe is a Trojan-Downloader.Win32.Genome sample that would normally go grab additional ill-intended binaries. Runtime analysis showed some common behaviors, though this sample seemed rather neutered.
1) Spawned a process and created C:\WINDOWS\system32\services.exe
2) Made a call to 212.180.97.163 (hxxp://www.sofec.21s.fr/k70.htm), now resulting in a 404.
3) Strings output was amusing (highlights parsed):
Buffer overrun detected!
unable to initialize heap
unexpected heap error
HeapDestroy
HeapCreate
HeapReAlloc
HeapSize
show me the money!
Nice. Really?
Who knows what additional evilware once lurked at 212.180.97.163, but it wasn't likely removed by anyone thinking clearly. The site hosted there is in miserable shape, suffering from numerous issues including SQL injection, horribly managed Frontpage extensions, cross-site scripting, and more. Which is to say, "give any one species too much rope and they'll f**k it up" (Roger Waters from Amused to Death).
So what's the lesson?
Negligence begets opportunity.
Opportunity begets maliciousness.
Maliciousness begets victimization.
Simple, yet entirely preventable.
The above mentioned combination of bad web application security and common malware practices likely means that someone may not have a nice Thanksgiving and that makes me sad. I don't like to be sad.
So beware fake Flash updates and button up your crappy websites so jerkwater ne'er-do-well's have less opportunity, damn it!
I am thankful for my dear family and all 19 of you readers.
Pass the Tofurkey!
Cheers.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Subscribe to:
Posts (Atom)
-
Continuing where we left off in The HELK vs APTSimulator - Part 1 , I will focus our attention on additional, useful HELK features to ... -
Ladies and gentlemen, for our main attraction, I give you...The HELK vs APTSimulator, in a Death Battle! The late, great Randy "Macho... -
First off, Happy New Year! I hope you have a productive and successful 2018. I thought I'd kick off the new year with another explorat...