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

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

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

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

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

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

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

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

Spot the Fed or Spot the Pony - CIA XSS

I can't resist. Giorgio Maone posted this here, having seen it on the Wired blog.
The repros say it all, and mind you, this "opportunity" has been public for days, yet the CIA hasn't fixed or disabled it. As Wired alluded, methinks the Cyber Security 'Manhattan Project' hasn't quite reached fruition yet.
For you fans of the "alqa-ida pony club" go here, but if you'd prefer to read about wunderkind Chertoff's latest spew try this. Both execute in the context of cia.gov. Sad, to say the least. Hopefully, these won't work much longer.
Screenshots if you'd prefer.




del.icio.us | digg

Packet heads and malware hunters rejoice

A couple of projects have recently emerged from development that are well worthy of adding to your feed readers.
Matt Jonkman at Emerging Threats pointed out OpenPacket.org, "a web site whose mission is to provide a centralized repository of network traffic traces for researchers, analysts, and other members of the digital security community." And traces they have...all the yummy pcap goodness you could ever hope for in the Capture Repository. This is a gloden opportunity to correlate attack trends to what you may be seeing on your networks, ro take the time to analyze captures you may not otherwise see, thus tuning your packet analysis skills. It goes without saying that Openpacket.org was conceived by Richard Bejtlich.
The other site of immediate interest to bug hunters is the SRI Malware Threat Center. The press release is here, but the premise is this: "SRI's Malware Threat Center posts daily updates of firewall filters, malware-related domain name system (DNS) names, antivirus statistics, intrusion detection system (IDS) signatures, and malware binary data to help network administrators understand current and emerging computer security threats and provide key network defense information that can be configured into security products to help network administrators fend off the latest malware threats."
The data is drawn from the Cyber-TA Honeynet Project and is extremely useful.
Enjoy!

del.icio.us | digg

Site issues

Just as an FYI, my primary site, holisticinfosec.org, is suffering from server RAID card issues. My ISP is migrating my content to new hardware, so we should be back within 24 hours. Thanks for your patience.
UPDATE 4/5/08: We're back, a painful migration to new hardware, but complete, and fully functional. Thanks again for your patience.

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

Upcoming conference presentations

I'll present The XSS Epidemic: Discovery, Disclosure, and Remediation at the 2008 ISSA NW Regional Security Conference on April 23rd, 2008, in Olympia, WA:
In the same mindset of a "month of browser, Mac OS X, PHP, etc. bugs" I challenged myself to find and report as many XSS (cross site scripting) vulnerabilities as possible in a 30 day period. The result was well more than 100 vulnerabilities in sites ranging from General Motors to George Mason University, 6 Secunia/CVE advisories for weak software, and a raging debate over the value of ScanAlert’s Hacker Safe label.
Our discussion will include a technical dive into this epidemic, including methodology, tools, examples, inherent risks, and the need to aid the Internet community in remediating this issue as well other web application security lapses.

I'll also present Malcode Analysis Techniques for Incident Handlers at the 20th Annual FIRST Conference in Vancouver, B.C. on June 25th, 2008. Details here.

RAPIER featured in SANS Ask The Expert Webcast

I gave an overview of RAPIER during a SANS Ask The Expert Webcast,
Malcode Analysis and Response: Proficiency vs. Complexity on March 20th, 2008.
"The threat landscape changes constantly, driven in part by the "bot economy" and changing malcode techniques. In response, incident handler techniques must keep pace. This presentation will cover the use of RAPIER, a security tool built to facilitate first response procedures for incident handling. It is designed to acquire commonly requested information and samples during an information security event, incident, or investigation. RAPIER automates the entire process of data collection and delivers the results directly to the hands of a skilled security analyst. From detection and discovery, capture and containment, count on a useful discussion meant to further your incident response practices."
You can listen to the stream and/or view the slides here.

Fastest fix in the West - a vendor's excellent response

Rare is the occasion when one who researches and responsibly reports web application vulnerabilities is met with an open, immediate, consumer oriented response from a vendor. But so it was when I let the folks who develop Tendenci, a Schipul offering, know about a few XSS issues. These are people who take great pride in their product; had they simply fixed the issue, and perhaps sent back a quick note many days later, I would have accepted that as the typical norm for most responsible vendors.
Yet, Schipul took the process to a new height, raising the bar entirely.
I literally heard back from Schipul's Jennifer Brooks within an hour of notification. Within 24 hours the issues had been addressed, and even more surprising, Tendenci posted the issue and its resolution to their blog, providing customers with a summary and an FAQ.
This rapid, public response exemplifies a company who seeks to protect their brand, their customers, and the end user, all in the same spirit and with the same intent.
To Schipul I say well done, extremely well done, and thank you.
del.icio.us | digg

An Open Letter to Ken Leonard, CEO, ScanAlert

Dear Mr. Leonard,

As well you are aware; the Hacker Safe brand has long been viewed by those in the information security field with varying levels of skepticism, if not vehement disdain. As there are a plethora of blogs, articles, and exposed vulnerabilities available for you to review, I will not waste your time with excerpts validating our position. Suffice it say, the community at large shares certain doubt about the service offering ScanAlert arrogantly calls Hacker Safe.
It is our view that this is a marketing position only. Nothing, I repeat, nothing, is truly "hacker safe". You claim that websites are free of vulnerabilities when they are clearly not. This is disingenuous and is at the root of what angers information security professionals. If a site is vulnerable while under the auspicious care of ScanAlert's Hacker Safe program should it not lose its Hacker Safe credential until such a time as the vulnerability is remediated? If I take this down to a fundamentally simple premise, saying a site is Hacker Safe while vulnerable to SQL injection, XSS, CSRF, etc. is, in essence, a misrepresentation. If a consumer commits a transaction on a site that is vulnerable, are they not at risk due to vulnerabilities your service claims to scan for? While we understand that you are in the business of growing revenue by indicating websites as “hacker safe”, we believe you are also beholden to the consumers using those sites.
We ask of you this: if a site is found to be vulnerable during your scans, or as reported by third parties, then enforce the findings and suspend their certification. Strive to improve your scan engine where possible. It is your responsibility to NOT label a site “Hacker Safe” when it is not. Then, at least, you are telling the truth, and a consumer can make an informed choice as to how confident they feel about the site's security practices.
There are, at the time of this writing, sites still vulnerable to XSS, yet branded Hacker Safe, that were identified as vulnerable MORE THAN A YEAR AGO. These sites should not be reported as Hacker Safe, period.
Please don't insult us with more of Joseph Pierini’s pearls of wisdom like “XSS vulnerabilities aren't material to a site's certification”. Adopting a view like this is ridiculous and blatantly ignorant given the risks to consumers. You scan for XSS and clearly denote it in your How We Scan section. Therefore, if a site is vulnerable to XSS it is not “Hacker Safe”.
This is far from the first round, credit sla.ckers.org with driving this point home in 2006, only to be shrugged off by Pierini then too. I think there may be a job opening for him over at Zango. Perhaps he could change his mantra from “XSS is not our problem” to “We don’t make spyware.”
What about the PCI argument? If a site is vulnerable to XSS, it’s simply not compliant. See this post for details. It all adds up to consumers at risk. ScanAlert should remember, above all, that safety for the consumer is paramount. Why not live up to your marketing hype and offer a service that truly, honestly, and with integrity, lives up to even a fraction of its namesake.
"What gets us into trouble is not what we don't know. It's what we know for sure that just ain't so. - Mark Twain"

Sincerely,

Russ McRee

Those information security professionals wishing to lend your name to this plea, please add your name as a comment.

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

NSM-Console and HeX update

While researching the HeX System for the pending February toolsmith, I was extremely pleased to discover NSM-Console, from Matthew Lee Hinman. I've not yet seen such an efficient, useful, all encompassing framework for offline packet analysis. NSM-Console includes modules for:
# aimsnarf
# ngrep (gif/jpg/pdf/exe/pe/ne/elf/3pg/torrent)
# tcpxtract
# tcpflow
# chaosreader
# bro-IDS
# snort
# tcpdstat
# capinfos
# tshark
# argus
# ragator
# racount
# rahosts
# hash (md5 & sha256)
# ra
# honeysnap
# p0f
# pads
# fl0p
# iploc
Consider giving both HeX System and the included NSM-Console an immediate look.