It seems to me that organizations that should know better are still attempting to remove information from the internet.  First we have the following that was removed due to legal threats (thanks C for pointing this one out);

Google Cache: http://209.85.129.132/search?q=cache:3hxOgSPu460J:bountii.com/blog/+%22I%27ve+never+bought+anything+using+Bing+Cashback,+but+the+balance+of+my+account+is+%242080.06%22&cd=2&hl=en&ct=clnk&gl=ch&client=firefox-a

Breaking Bing Cashback

 Posted November 4th, 2009 by Samir

 I’ve never bought anything using Bing Cashback, but the balance of my account is $2080.06. Apparently, I placed two $1 orders on January 24th of this year, and spent another $104,000 on October 24th. Let’s see how these transactions might have “accidentally” got credited to my account.

First, we need to try to figure out how transactions get into Bing Cashback. Microsoft posted some documentation here. The explanation of how a merchant reports transactions to Bing starts on page 20. Merchants have a few options for reporting, but Bing suggests using a tracking pixel. Basically, the merchant adds a tracking pixel to their order confirmation page, which will report the the transaction details back to Bing. The request for the tracking pixel looks something like this: 

‘https://ssl.search.live.com/cashback/pixel/index? jftid=0&jfoid=<orderid>&jfmid=<merchantid> &m[0]=<itemid>&p[0]=<price>&q[0]=<quantity>

 This implementation, while easy for the merchant, has an obvious flaw. Anyone can simulate the tracking pixel requests, and post fake transactions to Bing. I’m not going to explain exactly how to generate the fake requests so that they actually post, but it’s not complicated. Bing doesn’t seem to be able to detect these fake transactions, at least not right away. The six cents I earned in January have “cleared,” and I’m guessing the remaining $2080 will clear on schedule, unless there is some manual intervention.

Even if Bing detects these fake transactions at some point in the future, the current implementation might have another interesting side effect. I haven’t done enough work to say it with confidence, but a malicious user might be able to block another user’s legitimate purchases from being reported correctly by Bing (I only tried this once, but it seemed to work). Posting a transaction to Bing requires sending them an order ID in the request. Bing performs a reasonable sanity check on the order ID, and will not post a transaction that repeats a previously reported order ID. When a store uses predictable order ID’s (e.g. sequential), a malicious user can “use up” all the future order ID’s, and cause legitimate transactions to be ignored. Reporting would be effectively down for days, causing a customer service nightmare for both Bing and the merchant.

Based on what I’ve found, I wouldn’t implement Bing Cashback if I were a merchant. And, as an end user and bargain hunter, it does not seem smart to rely on Bing Cashback for savings. In our next blog post, I’ll demonstrate some other subtle but important reasons to avoid using Bing Cashback.

And now we have this taken down (also thank you to C for pointing this out);

http://securitytube.net/Hacking-NASA-with-SQL-Injection-video.aspx

Hacking NASA with SQL Injection Most of us might think that the top sites in the world such as those belonging to NASA, the FBI etc would be very strong on the security front and would be impregnable with simple attacks. However, this might not be really true. In this video, a Romanian hacker c0de.breaker demonstrates how one of NASA’s subdomains is vulnerable to a SQL injection attack.

<This video has been removed due to terms of use violation>

Organizations need to realize that once information has become posted on the Internet – IT IS PUBLIC.  Having sites remove the content does not make it go away or be forgotten.  I’d be interested in any other recent takedowns that have occurred.

The last couple years of my career have been interesting when it comes to disclosing vulnerabilities.  I have worked on some pretty big ones and a few aren’t even public yet.  Based on this I have been thinking a lot about how the industry as a whole handles vulnerability disclosure.  Yes, I am aware that this debate has raged on for years and will probably never be settled but I thought I would share my random thoughts here.

I have always been a fan of responsible disclosure.  Wait, let me first define what I feel responsible disclosure is.  To me it is very simple, do your best to get the vendor to fix the vulnerability without increasing the risk for the general Internet ecosystem. 

Of course one could easily argue that the existence of the bug is already a huge risk and therefore should be disclosed immediately to the world.  While there is some truth in that statement my personal issue with going that route is that disclosing something without a patch or at least with some very strong mitigation options does not help anyone increase their security and simply shines a spotlight on the flaw.

Over my career I have been involved with some pretty cool and pretty serious vulnerabilities.  My involvement has mostly been around reporting the issue to the vendor and working with them to fix the issue.  Believe it or not this can be a lot of work depending on the vendor.  In some cases you simply toss the crash dump over the fence and the vendor is able to run with it.  In other cases you end up having to supply PoC, which I hate having to do BTW, and in even more extreme cases you actually have to sit down prove the vulnerability on a live system and even offer fix advice.  I have even been involved in cases where a vendor has supplied a beta patch in which the scary smart people I work with quickly prove to also be flawed.

Unfortunately, over the years, the phrase “responsible disclosure” has become rather meaningless and really a one way street.  Vendors, note I work for one, are very quick to remind researchers that they need to do the responsible thing and while most researchers do attempt to show as much good faith as they can.  The vendors themselves seem to forget that responsibility and disclosure is a two-way street that requires both the vendor and the researcher to act in a manner that is best for those whom are vulnerable.

Some vendors do a pretty good job while others are still extremely horrible.  Believe it 0r not, but this is a place where other vendors should look at the Microsoft MSRC model.  The industry went from beating up on Microsoft during the 80s and 90s to seeing some great improvements in handling vulnerabilities and some proven process.  The only real criticism I can toss towards the folks in Redmond is that they are still a bit slow on some issues and yes I am still pissed at Culp for calling researchers Terrorists after 9/11. 

I am really not sure where I am going with all of this but I am finding myself becoming more and more frustrated with various vendors and their ability to invoke “responsibility” of the bug finder while not acting responsible themselves.  While I understand that this has become a business and fixing bugs cost money, the vendors need to understand that the researcher didn’t create the bug.  Their bad development process and lack of anything resembling a SDL process did.

Based on this frustration I have some advice for vendors.  Note that all of this is coming from the perspective of someone reporting a bug and not from the side of a vendor.

1.)  The researcher is not your enemy.  In fact, if you have a researcher contacting you about a vulnerability he/she found in your product, they are the exact opposite of the enemy.  They just provided you wtih some free QA and are handing you a great opportunity to not only improve your product but be seen in the public eye as a company that actually cares about their customer’s security and reacts accordingly.

2.)  If the bug is stupid or not exploitable.  Call it out.  But do so in a constructive manner.  Spend the time to sit down with the researcher and make sure you fully understand what they are telling you and that they understand how you came to the conclusion you have.  Again, you are not adversaries.

3.)  Be honest about patch timelines and potential issues you may have.  I don’t expect a vendor to share sensitive information with a researcher but being genuine about timelines and the process to produce a patch helps.  Most will understand that you can’t produce a safe patch in 30 days or less.  But a reasonable timeline should be offered,

4.)  Over communicate.  Nothing is worse when a researcher feels like they are being ignored or nothing is going on with the bug they reported.  As they sit and look for some sort of communication back from the vendor their mouse also hovers over the send key of a full-disclosure post.  Vendors are one forgotten status update away from having the issue dropped on them.

5.)  Lawyers won’t work – usually.  Enough companies have tried and failed to silence a researcher with lawyers.  If you contact your legal team BEFORE you contact your developers with a vulnerability report expect to have the vulnerability leak to the public.  Again, the researcher is not the enemy.  Your bad coding process is.

6.)  Give the researcher credit.  At the very least you should credit the researcher.  Remember, unless they have sold this bug to one of the clearinghouses, they have done this QA work for you FOR FREE.  They should get recognition for their work.  Hell if you have headcount and good workplace — hire this person to find more bugs for you.  Researchers like money just as much as corporations.

7.)  Applying pressure via other means such as mutual customers or corporate relationships will just build resentment.  Any attempt to silence the researcher will simply turn a positive situation in to an adversarial one.  As a vendor you do not want this.

8.)  Stay honest and back up your promises.  If you make commitments to the researcher.  Follow them.  It’s really that simple. 

9.)  Use  the vulnerability report as a mechanism to improve your internal development and QA process.

10.)  Do not use #9 as a way to stall a patch or prevent disclosure.

I know the above seems very simplistic and obvious to most of us but believe it or not the majority of vendors out there still do not get it.  Vendors need to realize that having a bug found in your product is actually an opportunity and not a set back. 

I encourage all researchers to remind vendors of THEIR responsiblity in the process.  Be open with the vendor with what you feel a reasonable process to fix the vulnerability is.  The more approachable you are, the easier the entire process will be. 

Got a vendor thats not cooperating?  Contact me and I can try and help.

Of course your other option is to simply disclose the issue to the public but that becomes a whole new can of worms.  My next post, when I get around to it, will talk about the issues that a researcher faces when they go this route.

It is a little ironic that I am basing this blog post off of another blog post but I am willing to admit that I rarely come up with a good ideas of my own.

Over the weekend we saw lots of Twitter activity about a blog post over at McGrew Security.  While I applaud the effort in pointing out this complete scam job of a book I do feel that perhaps the “authors” (can we even call them that?) are getting off a bit too easy.  Or at least one of them.

Before I rant and make fun of them let me first state that I too have written books.  I have even written books for Syngress.  While I am biased and honestly have not been paying attention, I have not seen a Syngress book worth purchasing since the Hack Proofing Your Network series — this includes my own material. 

I have worked with other publishers and this is my take on Syngress as a book publisher.  They went from being pretty cool and easy to work with during the Hack Proofing days to simply an outfit that attempts to churn out as many books as possible as quickly and as cheaply as they can.  Apparently, if you can cut and paste from Wikipedia, you are now a Syngress author.  Syngress pays the lowest amount they can negotiate with you and then rushes you through the fastest possible timeline to get your work in and published.  Quality is not the goal here – quantity is.  Flood the market with enough cheaply made books and you eventually make money on a few of them.

Back when I wrote for Syngress they did recommend that we run various tools to insure that we don’t plagiarise anyone’s material and they did do *some* technical editing but my most recent experience resulted in a book being released with next to no oversight.  Hell, I know for a fact that the majority of my last Syngress book was a.) written from the bottom of a bottle and b.) not reviewed very closely by anyone.  I am honestly embarassed about that one.

So do we point a finger at the so called authors?  Or is this a failure in the Syngress editing process and quality management?  I say both.  Jumping back to the blog post over at McGrew we see this explanation from one of the authors:

Edit: Dustin L. Fritz (of The CND Group) has left the following comment regarding plagiarism in this book:

This was an honest mistake and I sincerely apologize for any miscommunication. I hope that the correct and proper citations can be added soon and that all questions regarding copyright and plagiarism issues can be resolved. I hope the book can still be enjoyed as a valuable contribution to the information security community and I hope it will go on to fulfill its objective in reaching anyone who desires to learn more about hacking and security. I want to specifically apologize to Jayson, Kent, Syngress, Rachel, Angelina, all the readers, reviewers, and others who have taken offense. I want to fix this and I sincerely appreciate everyone’s positive support!

Wait, “honest mistake”?  Really?  Let me jump back and steal more of Mcgrew’s content;

If you have a copy of this book that you bought or received for review, I encourage you to take a look at these pages and source URLs to see what I’m talking about:

page	topic	original source	length
135	OSI Model	http://en.wikipedia.org/wiki/OSI_model	2 paragraphs and a table
141	Maltego	Old description from paterva.com	1 sentence
146	DNSPREDICT	Many sources (likely original tool site)	Entire description
149	Kismet	http://en.wikipedia.org/wiki/Kismet_(software)	Entire description
151	Netstumbler	http://en.wikipedia.org/wiki/NetStumbler	Entire description
153	SuperScan	http://en.wikipedia.org/wiki/Superscan	Entire description
154	Nmap	http://en.wikipedia.org/wiki/Nmap	Entire description
155	Paratrace	http://linux.die.net/man/1/paratrace	Entire description
156	Scanrand	http://linux.die.net/man/1/scanrand	Entire description
157	Amap	http://freeworld.thc.org/thc-amap/	Entire description (short)
161	Plug-in	http://en.wikipedia.org/wiki/Plug-in_(computing)	Paragraph description
164	Vulnerability Scanner	http://en.wikipedia.org/wiki/Vulnerability_scanner	Entire description
164	IBM Internet Security Systems	http://en.wikipedia.org/wiki/IBM_Internet_Security_Systems	Entire description & history
165	Nessus	http://en.wikipedia.org/wiki/Nessus_(software)	Entire description
166	Nessus Goes Closed License	http://en.wikipedia.org/wiki/Nessus_(software)#History	quoted
167	Tenable NeWT Pro 2.0	Press release? http://www.highbeam.com/doc/1G1-115844766.html	Entire description
168	Rapid7	http://en.wikipedia.org/w/index.php?title=Rapid7&oldid=301929477	Entire description
169	Microsoft Baseline Security Analyzer	http://en.wikipedia.org/w/index.php?title=Microsoft_Baseline_Security_Analyzer&oldid=225194910	Entire description
170	eEye Retina	http://en.wikipedia.org/wiki/Retina_Vulnerability_Assessment_Scanner	Entire description
177	Exploits	http://en.wikipedia.org/wiki/Exploit_(computer_security)	Entire description (full page of text)
179	Buffer Overflows	http://en.wikipedia.org/wiki/Buffer_overflow	Entire description
180	SubSeven and Stopping SubSeven	http://en.wikipedia.org/w/index.php?title=Sub7&oldid=299155522	Entire description
186	Metasploit	http://en.wikipedia.org/wiki/Metasploit	Entire description
187	Core Impact	http://en.wikipedia.org/w/index.php?title=Core_Impact&oldid=295444915	Entire description
193	Registry Keys	http://en.wikipedia.org/wiki/Windows_registry	Entire description
194	Securing your logs	http://codeidol.com/sql/network-security-hack/Windows-Host-Security/Secure-Your-Event-Logs	Entire how-to
195	Event Viewer and HOW TO: Event Log Types	http://support.microsoft.com/kb/308427	Entire description
197-200	Last User Logged in	http://www.technixupdate.com/change-or-hide-the-last-username-logged-on-username-dialog-box/	Entire how-to copied
201	Last True Login Tool	Many – Likely old description from website	Entire description
202-204	Last logoff script	http://dovestones.com/active-directory/true-last-logon/last-logoff.html	Entire how-to
205-208	Windows Security Log	http://en.wikipedia.org/wiki/Windows_Security_Log	Entire article
223	Description of NIST	http://en.wikipedia.org/wiki/National_Institute_of_Standards_and_Technology	Two paragraphs
233-235	CompTIA	http://en.wikipedia.org/wiki/CompTIA	Entire description
236	EC-Council	http://en.wikipedia.org/wiki/EC-Council	Entire description
236-237	(ISC)2	http://en.wikipedia.org/wiki/ISC2	Entire description
244	One-time Passwords	http://en.wikipedia.org/w/index.php?title=One-time_password&oldid=306538660	Paragraph and list
246	Honey Pot	http://en.wikipedia.org/wiki/Honeypot_(computing)	Paragraph
253	Firewall	http://en.wikipedia.org/wiki/Firewall	Paragraph
255-256	Full-Disk Encryption	http://en.wikipedia.org/wiki/Full_disk_encryption	Three sections
257-258	Snort	http://en.wikipedia.org/w/index.php?title=Snort_(software)&oldid=273431896	Entire description
258-264	IPS	http://en.wikipedia.org/wiki/Intrusion_prevention_system	The entire wikipedia article copied over multiple pages!
278	Wireshark	http://en.wikipedia.org/wiki/Wireshark	Several sentences from the article
279	PGP	http://en.wikipedia.org/w/index.php?title=Pretty_Good_Privacy&oldid=304558754	Two paragraphs of description
281	Personal firewalls	http://en.wikipedia.org/wiki/Personal_firewall	Short description
285	Perl	http://en.wikipedia.org/wiki/Perl	Entire description
292	Bluesnarf	http://en.wikipedia.org/wiki/Bluesnarfing	Entire description
299	Bleeding edge technology	http://en.wikipedia.org/wiki/Bleeding_edge	description and list
303-305	ECHELON	http://en.wikipedia.org/wiki/Echelon_(signals_intelligence)	Entire description + photo
310	Ghost Rat	http://en.wikipedia.org/wiki/Ghost_Rat	Two paragraphs
332	2600 Magazine	http://en.wikipedia.org/wiki/2600:_The_Hacker_Quarterly	Entire description
333-334	Gary McKinnon	http://en.wikipedia.org/wiki/Gary_Mckinnon	Entire description
336	PSP Hack	http://www.dcemu.co.uk/vbulletin/showthread.php?t=33928	Tutorial
396	World of Warcraft	http://en.wikipedia.org/wiki/World_of_warcraft	Large paragraph
399-400	Infragard	http://en.wikipedia.org/wiki/Infragard	Entire description
404	Bump Keys	http://en.wikipedia.org/wiki/Bump_key	Entire description

 

That is no honest mistake.  The mistake here was that this so called “author” thought he could get away with cutting and pasting from online resources.  There is zero honesty in this mistake.  What is even funnier (at least to me) that Syngress didn’t even catch this in their so called edits and reviews. 

Miscommunication?  Really?  What part of cutting and pasting from a website results in a miscommunication? 

To quote someone who will remane nameless because they said this in private:  “honesty and quality are not priorities for Syngress.”

Apparently, honesty and quality was not a priority for at least one of the authors of this book.  Mistake?  Yes.  Honest?  Thats hard to believe.

For my next book I think Iwill just cut and paste directly from Twitter.

What a complete joke.

By now, seeing how it takes me forever to write blog posts, everyone has heard the press about the “Twitter Hack”.

Since when is guessing someones password hacking?  If that is the case someone call the feds on my 11 year old son as he once guessed a siblings Windows password.  Sorry to all the want-to-be 1337 h4×0rs out there but guessing a password is not really a hack.  Sure it is amusing, but not hacking.

The fact that a couple of different email accounts that happened to belong to people associated with twitter has easy to guess passwords has really no bearing on the security or insecurity of twitter.  Yes it demonstrates that those compromised were idiots but no its not a Twitter issue.

Is Twitter insecure?  Probably.  Do these “hacks” demonstrate that — of course not.  What I find even more amusing is that this made the general media, I read about it on CNN and so did a lot of my friends who are not necessarily computer savy but do use Twitter.  Yet the only people who actually cared and made noise about this were security companies looking to get quoted and beat up on web 2.0 and cloud computing.

Don’t get me wrong, I do think cloud computing and Web 2.0 are both bad ideas from a security perspective but they are the inevitable path that the web will take.  Features, performance, price, and functionality will always trump security.

Anyways, random thoughts first thing in the morning for me.  Can we get back to hacking the important targets?

Just wanted to do a quick post to point out a couple good posts on the IIS WebDav bug.  Am I the only one to think its kind of cool to see another IIS bug after spending months upon months of dealing with file format type bugs?

Great and detailed post from Todd Manning over at Breakingpoint (you should follow this blog its great!)

http://www.breakingpointsystems.com/community/blog/slash-and-burn-the-iis-6-0-webdav-bug

and, an amusing post showing yet another consequence of the bug:

http://blog.zoller.lu/2009/05/iis-6-webdav-unicode-bug-that-wont-die.html

I received this email the other day.  I don’t have any real commentary to add to this other than my best Simpsons “ha-ha” and the HTML formatted email was a nice touch.. heh

===================================================================

Dear Valued Prospect,

You recently received an email from PGP Corporation as a follow-up to your evaluation of PGP products.  This email erroneously included some 290 email addresses of other evaluation users. This occurred when an employee inadvertently pasted these addresses into the “To” line of the message.  Even as this really was a basic mistake – it is not acceptable to me or the employees of PGP Corporation.

This error was in violation of our corporate policies regarding customer information and customer communications.  It should not have happened and we apologise for this mistake.  PGP Corporation is first and foremost committed to privacy and information security.  We assure you that we are not only examining the mistake itself, but are actively re-examining our training and processes to prevent an incident of this kind from happening again.  As John Leyden of The Register wrote, “since PGP specialises in email security, it can hardly complain if people hold it to higher standards”.  He is right.

If you have additional comments, questions or concerns and would like to speak with me directly, please contact me via phone in the UK, toll free: 08-08-2341889, or in the US, toll free: 888-515-4922.  If you call and get my voicemail, please do leave a message.  I will call you back.  If you would like to contact me via email, send your concerns to ceo@pgp.com.

As a company and as individuals, we are committed to safeguarding customer information and we again express our apologies for this error.  We will do better in the future and we will use this isolated event as a learning experience upon which we improve and strengthen PGP Corporation and its communication practices.

Sincerely,

Phil Dunkelberger
President and CEO
PGP Corporation

At CanSecWest last week (note to self: write a post about how awesome the conference was) a few well known researchers, Alex Sotirov, Dino Dai Zovi, and Charlie Miller began a movement against “free bugs”.  The basic and over simplified premise is that they feel that security vulnerabilities should not be handed over to vendors for free.  I don’t necessarily agree with this but in reality who cares?  To each their own.  This is really an individual choice.

Of course, this caused a few to scratch their heads and while I am sure there are other really dumb blog posts about this — I thought this one took the cake:

http://www.sophos.com/security/blog/2009/03/3680.html

Not only is the above blog post completely off the mark, but it is clear that the author is very inexperienced in dealing with security vulnerabilities.  Lets look at some of the ridiculous comments made by Ross Thomas of Sophos.

“As one of those users, I have to say I’m not exactly delighted to discover that a so-called security researcher was so breathtakingly cavalier about the safety of my data and the privacy of my personal information. Apparently I’ve been vulnerable to this “idiot-proof” exploit for at least a year, and have only good luck to thank for the fact that no-one used it to drain my bank accounts in the meantime.”

Wow.. talk about raising the level of FUD and so soon in the post.  While we don’t have a heck of a lot of details on the bug (some do have more than others) I can say with a pretty high confidence level that this bug could not be used to “drain” the author’s bank account.  If it could, there would be even less reason to disclose it. 

But wait it gets even worse:

“The point I’m trying to make is that this wasn’t “his exploit” to do with as he saw fit.”

Really?  Didn’t the researcher, in this case Charlie Miller, spend the time to find this bug?  He found the bug and he wrote the exploit.  That does in fact make it his to do with as he pleases.

I guess that is really the entire point that Sophos and Ross Thomas are missing.  While I personally would report any vulnerabilities I find to the vendor, for free, it really is up to the individual researcher to do as he pleases with what he finds.  Afterall, he did put in the work.

“With today’s highly monetized black market for malware authors this kind of bug must not be permitted to exist even for a day, let alone a year”

More FUD!  Security vulnerabilities exist, they always have and they always will.  Get over it.  Bugs exist much longer than days as it takes most vendors months to fix anything and once you have reported the bug to a vendor — it is no longer a secret.  While anyone could have found the same bug and used it for “bad things” no one did.  So what does that tell you?  It suggests to me that the so called “black market” and malware authors aren’t looking as hard or maybe they aren’t as good as looking.

Lets also not forget that users are always slow to patch their machines.  So waiting to report this really has no bearing on anything — especially when this specific bug has not been used in the wild.  Looking at the last few very successful pieces of malware — none of them used a zeroday.  In fact one of the bigger ones (although we all know the shady AV Vendors inflate their numbers) Confiker, used a known and patched vulnerability.  In fact, the trend lately has been, patch released, bad guys reverse patch, bad guys start using vulnerabilities, months later users get around to installing patch.

Perhaps once we start to see more actual zero day being used and lets be honest here, perhaps once AV Vendors start actually offering their users REAL PROTECTION that can’t be easily bypassed then we can cast stones at someone for wanting to be paid for something they do in their spare time.

This is a very amusing blog post that I thought I would toss on here. Great find and I am going to test this later today.

Full post from:  http://david.weebly.com/1/post/2009/03/how-to-open-many-keypad-access-doors.html

How to open many keypad-access doors 03/11/2009

14 Comment(s)

Here’s a fun little tip: You can open most Sentex key pad-access doors by typing in the following code:

***00000099#*

The first *** are to enter into the admin mode, 000000 (six zeroes) is the factory-default password, 99# opens the door, and * exits the admin mode (make sure you press this or the access box will be left in admin mode!)

I’m not sure how prevalent they are, but here in San Francisco, Sentex building access systems seem to be the most popular.

Today I read a Blog post that, in my opinion, was pretty suspect when it comes to the whole debate around ethics in blogging.  While it is a reality that all of us have multiple “gigs” from our daily corporate grinds, to side consulting, to getting paid to Blog (note I don’t get paid to Blog) we should all be smart enough to not let them interfere with each other.  But what happens when you blur those lines of common sense and use one gig to promote another?  Is that not unethical?  Should writing for ZDNet, albeit a Blog, not make you some sort of “reporter” (using the term very loosely) and shouldn’t you resist the urge to pimp your other gigs?

Sure, in this case the author, called out that he works for the company in question but that doesn’t excuse the fact that he basically inserted a mostly ignored press release in to his PAID ZDNet Blog under the guise of following a “twitter user’s request” and “just helping out”.  While I don’t have anything against Adam personally, and I am sure Cloudmark makes a great product — how dumb do they think ZDNet readers are?  Wait don’t answer that….

Sorry but I call bullshit.  This was simply an attempt to gain more attention for the day job’s press release and really no different than the Security Companies we all have made fun of in the past for posting fake mailing list posts talking up their own products.

One less trusted resource I suppose…

Check out this post over at Space Rogue’s blog.  Looks like we will finally see a new version and maybe some updates to L0phtcrack.

Great job Mudge, Dildog and Weld