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
Wednesday, May 28, 2008
Friday, May 23, 2008
Blue River's stance on Sava security stands out
It's been awhile since I've had something nice to say, and the golden opportunity to rectify that issue has presented itself in the discovery of some vulnerabilities in Sava CMS from the Blue River Interactive Group.
At 9:29pm May 19th, I sent a note to Blue River pointing out an XSS vulnerability. I received a reply from Malcolm at 9:46pm (yes, 17 minutes later), stating that the issue would be addressed immediately and asking if I had questions or suggestions.
Wow! Really?
The lonely life of security dork/vuln researcher sometimes has its rewards. I offered to take a deeper look at Sava, with their permission, which Malcolm immediately granted. After further inspection, I noted a SQLi issue as well, but the update they'd already released had fixed the issue on other sites where the update had been applied. So, in what really amounts to 48 hours, the Blue River team went after the issues with a vengeance, and addressed them appropriately (and obviously quickly).
It's no secret that I am giant open source proponent, and Sava fits that definition in every way, not just their application but their open communication, pride in their product, and concern for their users.
This is what we in the security community hope for...those rare occasions to feel good about well intended efforts being met by further well intended efforts, all to the benefit of the user and the consumer.
Well done, Blue River...go Sava!
Any Sava users who may be reading this, ensure that you are running Sava CMS 5.0.122 or later.
Advisory here: HIO-2008-0523 Sava CMS SQLi & XSS
del.icio.us | digg
At 9:29pm May 19th, I sent a note to Blue River pointing out an XSS vulnerability. I received a reply from Malcolm at 9:46pm (yes, 17 minutes later), stating that the issue would be addressed immediately and asking if I had questions or suggestions.
Wow! Really?
The lonely life of security dork/vuln researcher sometimes has its rewards. I offered to take a deeper look at Sava, with their permission, which Malcolm immediately granted. After further inspection, I noted a SQLi issue as well, but the update they'd already released had fixed the issue on other sites where the update had been applied. So, in what really amounts to 48 hours, the Blue River team went after the issues with a vengeance, and addressed them appropriately (and obviously quickly).
It's no secret that I am giant open source proponent, and Sava fits that definition in every way, not just their application but their open communication, pride in their product, and concern for their users.
This is what we in the security community hope for...those rare occasions to feel good about well intended efforts being met by further well intended efforts, all to the benefit of the user and the consumer.
Well done, Blue River...go Sava!
Any Sava users who may be reading this, ensure that you are running Sava CMS 5.0.122 or later.
Advisory here: HIO-2008-0523 Sava CMS SQLi & XSS
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
Sunday, May 18, 2008
Redmondmag...I told you so!
There is no more egregious an act of negligence committed by online vendors and businesses than ignoring notifications of vulnerabilities found in their applications.
So when Dancho Danchev pointed out that Redmond Magazine had been SQL injected by Chinese Hacktivists, I was both appalled, yet not surprised.
On January 29th, 2008 I informed 1105 Media, the parent company of the Redmond Media Group, of multiple XSS vulnerabilities in various properties they maintain, including EntMag.com and AdtMag.com, as well as Redmondmag.com.
From my email:
"I’d like to advise you of XSS vulnerabilities in the search code used by all Redmond Media Group websites.
This is most easily validated by pasting a simple script alert generator in the search form.
These vulnerabilities were disclosed by XSSed.com in February and July of 2007.
http://www.xssed.com/mirror/20073/
http://www.xssed.com/mirror/13305/
These vulnerabilities could be exploited by malicious people to conduct XSS attacks and it could further lead to reputation and PR issues for the Redmond Media Group."
Not only did they flatly ignore me, and they guys from XSSed.com who'd notified then in FEBRUARY and JULY 2007!, but all these vulnerabilities still exist, including Redmondmag.com. You could definitely say that these issues have led to "reputation and PR issues for the Redmond Media Group."
Doh! I told you so!
It goes without saying that if you are vulnerable to XSS, you have a significantly higher likelihood of being vulnerable to SQLi.
Redmondmag.com was also victimized by the 2nd wave of mass SQL injection attacks that dropped in nihaorr1.com/1.js.
Regarding current vulnerabilities, observe the following:
http://www.whiteacid.org/misc/xss_post_forwarder.php?xss_target=http://search.redmondmag.com/search.asp&cmd=search&SearchForm=%%SearchForm%%&index=C:\dtSearch\rmg\red_all&sort=Date&srcrequest=%22%3E%3CSCRIPT%3Ealert('XSS_Alert')%3C/SCRIPT%3E&submit1=Search">http://www.whiteacid.org/misc/xss_post_forwarder.php?xss_target=
http://search.redmondmag.com/search.asp&cmd=search&SearchForm=%%SearchForm%%&
index=C:\dtSearch\rmg\red_all&sort=Date&
srcrequest=(Insert JavaScript here)&submit1=Search
Props, as always, to Whiteacid's XSS Assistant and POST forwarder.
But behold, what do we see, but index=C:\dtSearch\rmg\red_all.
Well, now we know you use dtSearch on the C: of your Windows server (no surprise there ;-)).
Come on people, fix your sites!
You have been found guilty of the following charges:
1) Vulnerable to SQLi
2) Vulnerable to XSS
3) Internal file disclosure
4) Flagrant negligence with regard to secure coding best practices
50 Flagrant disregard fo information submitted to you by the information security community.
1105 Media and the Redmond Media Group, you have failed your readers, your visitors, your customers, and yourselves, and you should be ashamed.
del.icio.us | digg
So when Dancho Danchev pointed out that Redmond Magazine had been SQL injected by Chinese Hacktivists, I was both appalled, yet not surprised.
On January 29th, 2008 I informed 1105 Media, the parent company of the Redmond Media Group, of multiple XSS vulnerabilities in various properties they maintain, including EntMag.com and AdtMag.com, as well as Redmondmag.com.
From my email:
"I’d like to advise you of XSS vulnerabilities in the search code used by all Redmond Media Group websites.
This is most easily validated by pasting a simple script alert generator in the search form.
These vulnerabilities were disclosed by XSSed.com in February and July of 2007.
http://www.xssed.com/mirror/20073/
http://www.xssed.com/mirror/13305/
These vulnerabilities could be exploited by malicious people to conduct XSS attacks and it could further lead to reputation and PR issues for the Redmond Media Group."
Not only did they flatly ignore me, and they guys from XSSed.com who'd notified then in FEBRUARY and JULY 2007!, but all these vulnerabilities still exist, including Redmondmag.com. You could definitely say that these issues have led to "reputation and PR issues for the Redmond Media Group."
Doh! I told you so!
It goes without saying that if you are vulnerable to XSS, you have a significantly higher likelihood of being vulnerable to SQLi.
Redmondmag.com was also victimized by the 2nd wave of mass SQL injection attacks that dropped in nihaorr1.com/1.js.
Regarding current vulnerabilities, observe the following:
http://www.whiteacid.org/misc/xss_post_forwarder.php?xss_target=http://search.redmondmag.com/search.asp&cmd=search&SearchForm=%%SearchForm%%&index=C:\dtSearch\rmg\red_all&sort=Date&srcrequest=%22%3E%3CSCRIPT%3Ealert('XSS_Alert')%3C/SCRIPT%3E&submit1=Search">http://www.whiteacid.org/misc/xss_post_forwarder.php?xss_target=
http://search.redmondmag.com/search.asp&cmd=search&SearchForm=%%SearchForm%%&
index=C:\dtSearch\rmg\red_all&sort=Date&
srcrequest=(Insert JavaScript here)&submit1=Search
Props, as always, to Whiteacid's XSS Assistant and POST forwarder.
But behold, what do we see, but index=C:\dtSearch\rmg\red_all.
Well, now we know you use dtSearch on the C: of your Windows server (no surprise there ;-)).
Come on people, fix your sites!
You have been found guilty of the following charges:
1) Vulnerable to SQLi
2) Vulnerable to XSS
3) Internal file disclosure
4) Flagrant negligence with regard to secure coding best practices
50 Flagrant disregard fo information submitted to you by the information security community.
1105 Media and the Redmond Media Group, you have failed your readers, your visitors, your customers, and yourselves, and you should be ashamed.
del.icio.us | digg
Friday, May 16, 2008
Beware the Zangobot!
While this news is likely speculative and unfounded, it has ramifications I couldn't resist. My good friend Steve and I have, for the last couple of years, jokingly inferred that Zango must have some form of bot, be it a crawler or IRC/P2P. Now this was stated entirely in jest, mind you, but I have to throw the phrase open now that to a story from Trendmicro claiming Zango and Storm: Possibly in Cahoots.
How could I pass? This is indeed the prospect of a Zangobot!
From Trend's post: "The presence of these clues means either of two possibilities. One, that Storm is now targeting computers that have Zango adware installed in them, or two, that Storm has now been commissioned to deploy Zango adware. Zango (also ePIPO, 180solutions, HotBar) is an adware company notorious for planting software that runs on startup, displays advertisements, and comes bundled with other software."
Alex Eckelberry rightfully puts a cautionary spin on the story in his post on the Sunbelt blog:
"After years of tracking Zango/180, etc., we have a really hard time believing that Zango would knowingly work with distributors of Storm. While there’s no love between us, they're not complete idiots, and they know that if they got caught they'd be in serious trouble with the FTC."
Nonetheless, let the speculation and research begin.
BEWARE THE ZANGOBOT!
I hereby declare a contest! We need a Zangobot graphic. Get your creative juices flowing and send your Zangobot character/avatar/image to me at holisticinfosec at gmail dot com.
The winner receives mention here, an information security book of my choosing, and a Daily WTF sticker.
del.icio.us | digg
How could I pass? This is indeed the prospect of a Zangobot!
From Trend's post: "The presence of these clues means either of two possibilities. One, that Storm is now targeting computers that have Zango adware installed in them, or two, that Storm has now been commissioned to deploy Zango adware. Zango (also ePIPO, 180solutions, HotBar) is an adware company notorious for planting software that runs on startup, displays advertisements, and comes bundled with other software."
Alex Eckelberry rightfully puts a cautionary spin on the story in his post on the Sunbelt blog:
"After years of tracking Zango/180, etc., we have a really hard time believing that Zango would knowingly work with distributors of Storm. While there’s no love between us, they're not complete idiots, and they know that if they got caught they'd be in serious trouble with the FTC."
Nonetheless, let the speculation and research begin.
BEWARE THE ZANGOBOT!
I hereby declare a contest! We need a Zangobot graphic. Get your creative juices flowing and send your Zangobot character/avatar/image to me at holisticinfosec at gmail dot com.
The winner receives mention here, an information security book of my choosing, and a Daily WTF sticker.
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
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
Subscribe to:
Posts (Atom)
Moving blog to HolisticInfoSec.io
toolsmith and HolisticInfoSec have moved. I've decided to consolidate all content on one platform, namely an R markdown blogdown sit...
-
Continuing where we left off in The HELK vs APTSimulator - Part 1 , I will focus our attention on additional, useful HELK features to ...
-
As you weigh how best to improve your organization's digital forensics and incident response (DFIR) capabilities heading into 2017, cons...
-
When, in October and November 's toolsmith posts, I redefined DFIR under the premise of D eeper F unctionality for I nvestigators in R ...