Archive for the ‘Security’ Category

Security Thought Leadership

Sunday, February 27th, 2011

Hat tip to Brian Krebs for this one.  Also congratulations to Brian for winning a security blogger award at the RSA Conference.  One of his fellow winners, Chris Eng, won an award for the best single blog post for this wonderful piece. (Thanks to xtranormal.com for providing the embedding code on their website.  The original post may be found at http://www.xtranormal.com/watch/7897173.)

Attachment or Link?

Monday, July 27th, 2009

Steve Bellovin has an interesting analysis of the question “which is a better way to send a file, as an attachment or as a link?” The discussion centers around the process of opening a file in either a mail user agent or a web browser, and how vulnerabilities in each get tickled. There is no clear hands down winner, although since sending links is also more courteous he gives that a slight nod.

Password Security

Friday, July 24th, 2009

From our friends at XKCD:

Cybersecurity Bill of 2009

Monday, April 27th, 2009

Steve Bellovin has an excellent analysis of the CyberSecurity Bill of 2009 on his blog. It is a long and thoughtful piece that you should read for yourself rather than having me try to summarize it.

Devolution

Wednesday, April 22nd, 2009

A hat tip to Bruce Schneir for spotting this one.  The BBC is reporting that the NHS Central Lancashire backed up health data on 6,360 prisoners and ex-prisoners by copying it on to a USB stick. They even encrypted the data.

Then they lost the stick.

With a yellow sticky attached to it with the password.

We really can’t make this stuff up.

Captcha? Gotcha

Monday, April 6th, 2009

Beware of security questions that you didn’t create!  From XKCD (http://xkcd.com/565/)

Not out of the Conficker woods yet

Sunday, April 5th, 2009

Dan Kaminsky has a very good call for continued vigilance against Conficker. Entitled “A Marathon, Not a Sprint” he writes:

Of course, you may be thinking:  The world didn’t come to an end.  Clearly, this whole thing was just a Y2K hypefest.  I’m sorry the bad guys aren’t quite the eschatologists some people would like them to be, but somebody’s been investing extraordinary amounts of resources making a worm very difficult to kill.  It’s not like there was a contingent of rogue coders, sitting around figuring out where they could put two-character date fields after January 1st, 2001.  There’s a bad guy out there, and while we shouldn’t panic, we shouldn’t quite ignore the situation either.

I agree with his advice.  Don’t panic, but don’t drop your guard either.  Now that network based scanners can spot this, the owners of enterprise networks should be scanning and cleaning up.

Conficker “doomsday” passes without incident

Thursday, April 2nd, 2009

Security Wire Daily (among many other sources) reports that the April 1st detonation date for the Conficker / Downadup worm passed without incident. For those who have not been paying attention, Conficker is a worm that exploits a vulnerability in the Microsoft Windows RPC code to install itself.  The payload is aimed at forming a large (between 9 and 15 million hosts so far) botnet.  The command and control channel is an outbound connection to a host selected from a pool of domain names generated by algorithm.  Largely due to the efforts of the Conficker Working Group the domain generation algorithm was cracked and registrars cooperated to prevent (or revoke) registration of those domains.  Thanks to that effort, very few of those millions of computers were actually able to reach an update server, which has kept these machines from getting instructions to do anything nastier than spreading.

The Conficker Working Group is a (rare) collaboration among a broad spectrum of technology companies and organizations including Microsoft, Afilias, ICANN, Neustar, Verisign, CNNIC, Public Internet Registry, Global Domains International, Inc., M1D Global, AOL, Symantec, F-Secure, ISC, researchers from Georgia Tech, The Shadowserver Foundation, Arbor Networks and Support Intelligence. Their work was aimed at both detection (hence the AV companies) and keeping the worm from phoning home (the registrars and ICANN).

Reports are that some small percentage of infected machines did manage to connect to an update server, but did not immediately change their behavior.  This has led some to speculate that the April 1 date was a blind and the worst may be yet to come.  Certainly, it is no time for complacency, and organizations should remain vigilant in detecting and cleaning up Conficker-infected machines.

The most interesting work actually came over the weekend on the detection front.  Dan Kaminsky reports on work he did jointly with Tillman Werner and Felix Leder of The Honeynet Project to detect infected machines from the network rather than the host. The authors of Conficker want to protect their botnet from poaching, so after they own a host they patch the buffer overflow that let them in.  Werner and Leder exploited the differences between the Conficker patch and the official Microsoft patch to develop a malformed RPC request that will elicit different responses from healthy and infected machines, allowing detection.  This is vital to remediating infections because the worm disables Windows update and any security software it finds on the machine to avoid detection.

In an amazing piece of coordination, the group figured this out last Friday and working code was in the major vulnerability scanners by Monday.  I don’t impress easily, but I’m impressed.

Teaser: SQL Injection — Not just for kids anymore

Monday, March 23rd, 2009

While I’m still preparing new material, amuse yourselves with my favorite XKCD cartoon (at http://xkcd.com/327/):

 

\

This is, of course, SQL injection as we fondly remember it — one person mano y mano against the database.  More on how the world has changed in a future post.

Don’t blame the user

Monday, June 16th, 2008

There was an interesting post on the Security Bytes blog, reminding us that while many attacks are based on user susceptibility, it’s short sighted to just blame the users. While many of us have favorite nasty acronyms to describe our users, in fact, the fact that their behavior enables many cyber attacks is as much our fault as theirs. In many cases, the users have had insufficient training and awareness to know that their behavior is unwise. It is up to us as technologists and security professionals to educate our users.

It is also a big problem that the most prevalent operating system on the corporate desktop (Windows XP) is usually configured so that users have local administrative rights to their workstation. Again, it would be easy to blame the victim, in this case the systems staff, for leaving their users with local admin or power user rights, but the fact is that a lot of Windows applications break if the user does not have elevated rights. I know of at least one company that made a good faith effort to secure their desktop. The number of exceptions that had to be granted, and not just to software developers, was disheartening