Finally a use for my iPhone and Blackberry

“Recycling” my iPhone and Blackberry now that I have a real smartphone – Google Nexus-1.

 

Quick Note – Twitter

No the person using twitter.com/hellnbak is not me. I deleted my twitter account and someone else has jumped on the name.

Taking Responsible Disclosure for Granted – Part Duh

In a previous post I talked about responsible disclosure and how I feel Vendors who are receiving vulnerability reports should be acting.  Unfortunately, even today vendors who act in a responsible manner are in the minority.  As promised in that post, this is the follow-up.

Over the years and over different jobs at various places I have been very lucky to work with some very smart researchers.  I will resist the urge to name drop them all here but I will say that all of them are much smarter than I am and I have manged to learn as much as I can from each of them — even though I have probably killed all those brain cells in recent years and forgotten everything. 

One thing I have noticed, and hopefully this doesn’t come across as an insult, is that finding a researcher who is both very good at finding bugs but also able to deal with the “business” side of disclosing that bug is a rare find.  Don’t get me wrong, there are a few out there that I can think of, but more often than not the disconnect between the technical brilliance and the ability to deal with the, for lack of a better word, politics around disclosure is typically a big one.

This alone makes dealing with vulnerability information a huge challenge for most on both sides of the coin.  You end up with a highly technical person talking to a less technical business focused person and frustration builds quickly on both sides.  Of course when a bug is mishandled you end up with even a bigger problem to deal with.

As I did in my last post I wanted to share some advice based on my experience of what a researcher can expect.  Hopefully this will help shed some light on just what goes through a vendors mind when you send them that bug report. 

Before I get in to that however, let me state this.  When you find a vulnerability it is YOURS.  You own it.  The vendor who wrote the software or created the hardware that you have poked holes in does not own your work.  You are free to do what you want with it, sell it, drop it on the internet for free, or use it to impress girls (has that ever worked?). 

Obviously, if you have followed my blog or if you know me you know that I support reporting the issue to the vendor and working with them to get it fixed.  But in all honesty, you can ignore everything I say and do what you want.

As I am writing this, I realized that the entire notion of asking someone who just found a bug in your product to act responsibly is a bit hypocritical, I mean, if you had tested your product properly would the bug not exist in the first place?  So who is really responsible?  That said, here is my advice for researchers:

1.)  If you are not willing to put up with various annoyances including but not limited to stupidity, denial and perceived laziness do not bother reporting your bug to the vendor.  Go and sell it to one of the various companies that purchases vulnerabilities and move on with your life.

2.)  While what you have done is probably very cool remember – THE VENDOR IS SCARED OF YOU.  Upon first contact they have no idea what your true intentions are and they are in immediate fire drill mode.  Try to be as straight forward and honest with the vendor as possible.  Do not go in with a hidden agenda, it never works.

3.)  Most vendors will put their foots in their mouths.  Remember, the vendor is now scrambling and you are typically talking to someone who really does not understand what you are telling him and that person is now trying to relay your message to the developers who are probably replying with “thats impossible”.  A bit of patience can go a long way.  But obviously, only so much, if the vendor never gets out of the denial stage, they have bigger problems than your bug.

4.)  When you approach a vendor asking for money or for a business relationship in exchange for the vulnerability you will always, despite your true intentions, appear shady and potentially get yourself in a lot of trouble.  If you want to make money off of your find, sell it to a third-party.

5.)  Most vendors will not sue you or use other legal means to keep the bug quiet.  That said, it never hurts to seek legal advice.  I highly recommend the smart folks over at the EFF.

 6.)  Demanding a Non-Disclosure agreement will be typically met with resistence.  This is not because the vendor wants to play games but because the amount of effort required to have legal review and approve a NDA for this type of thing far outweighs the benefit of having one.  In addition, as a researcher you should avoid signing a contract of any type with the vendor.  Remember it is not in the best interest of the vendor to disclose a bug early or even at all.  Based on this alone, a Non-Disclsoure Agreement is problematic.

7.)  Be up front with your intentions.  If this bug is going to be a topic of a conference presentation, a blog post, or a mailing list post — say so.  Tell the vendor up front what your plans are so they can respond accordingly.

8.)  Understand that your timeline will almost never be consistent with a vendor’s timeline.  The notion that a bug can be fixed, tested and released in 30 days is not all that realistic.  That said, communicate your expectations and be prepared to at least hear the vendors side of the story.  You do not have to agree or even understand but you should at least be informed.

9.)  If the vendor’s timeline is not acceptable to you, be up front and say so.  It won’t change the vendor’s mind but at least they won’t be surprised when you move forward with your release plans.

10.)  Try to remain professional while interacting with the vendor no matter what their response.  While drama and fights make for great press stories it does nothing to help get the bug fixed and nothing to help build your reputation as a researcher.

11.)  Assume that the more people you tell about the vulnerability the higher chance of that issue becoming public before you are ready.  Use encryption and keep your list of those you tell to a very limited need to know basis.

Source Boston Speaker Arrested

In the past I have been known to cross swords with this guy. In fact, I have maintained for quote some time that he is nothing more than a charlatan. Of course this is only my opinion.

http://www.sourceconference.com/blog/?tag=source-boston-james-atkinson

One thing I will give him credit for — ROCKET LAUNCHER. That is totally badass, although not sure how having a rocket launcher at home is going to help you in prison.

http://www1.whdh.com/news/articles/local/BO131400/

Wonder what kind of yarn will be spun out of this one? While I am quick to point and laugh, I do have a heart and I hope you pull through this James, while I love getting under your skin and proving you to be nothing more than a charlatan, I wouldn’t wish this on anyone.

Nice touch with the “hearing voices” part as with the thousands of pills.

ROCKPORT (WBZ) ― Rockport police displayed some of the items they seized from Atkinson’s home.

A part-time EMT is now free on bail after Rockport police say they found a huge stash of weapons in his home.

47-year-old James Atkinson was arrested last week on larceny and obstruction of justice charges.

Police noticed that he had turned over ammunition after his arrest, but that he did not hand over all of the dozens of weapons that went with it.

So they went to his home on Broadway early Sunday morning with a search warrant.

This is what officers say they found:

US Army issued M190 rocket launcher
Surveillance equipment worth millions of dollars
More than 1,000 rounds of rounds of ammunition
Military-grade smoke bombs
Tear gas launcher
Glock handgun
.357 magnum and rifle
Mace
More than 1,000 pills
Computers

All were seized by police.

Atkinson was arrested again.

16 charges were filed against him, 3 were felonies.

He was arraigned in Gloucester District Court Monday morning and released on $3,500 bail.

Police say “many handguns and rifles are still not accounted for

Of course no post would be complete without pics:

What is with all the Internet Takedowns?

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.

Taking Responsible Disclosure for Granted

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.

Writing original material is hard…

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.

The Twitter Hack That Wasn’t

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?

IIS Webdav Bug

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

PGP Fail!

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

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

From: PGP Corporation [mailto:ceo@pgp.com]
Sent: 25 March 2009 02:07
To: XXXXXXXXXXXXX
Subject: Email communication earlier today from PGP Corporation

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