MD5 Considered Harmful Today or Don't Put Too Much Faith in PKI

A group of 7 security researchers from the United States, Switzerland, and the Netherlands has released details of an exploitation ("MD5 considered harmful today") in the now well-known MD5 Hash Collision vulnerability that would allow a rogue web site to issue a rogue SSL certificate... as well as a rogue signing certificate that is trusted by a valid root Certificate Authority.

Putting that all into English (or at least non-geekspeak):

"Secure" web sites can be impersonated by evildoers, even with the cute little lock icon and a completely "valid" certificate as far as your browser is concerned. This web site could be your bank.

The paper discusses countermeasures, mostly aimed at Certificate Authorities (CAs) and browser vendors. One thing you can do is look at your certificate chain for critical sites to see if MD5 is used by the CA's signing certificate.

The Mozilla developers are already working on a patch for Firefox, et al.:
https://bugzilla.mozilla.org/show_bug.cgi?id=471539


--john

We cannot let this man be elected as President

I am appalled. If John McCain has done even one tenth of the things listed in this Rolling Stone article, we cannot let him take the office of the Commander in Chief:

http://tinyurl.com/3oje6n

Update:
Scary. Someone actually went to the trouble of breaking the above URL. Here is the new one:
http://tinyurl.com/mcmaverick

Or, just google for "mccain maverick rolling stone".

strip=1 ftw

I use lots of browser flame-retardant suit layers these days... NoScript, AdBlock, etc. I even tend to NoScript google.com by default. If you only go to "normal" web sites this might seem extreme, but if you are poking around the seedy back streets of the intertubes, you probably know what I mean.

Here is another good pair of tips for safer browsing:

1. Use the cache, Luke, and
2. Always use strip=1

You can use the google cache to search for your topic of interest, and the oracle will return some hits (e.g., "100th monkey"):

1. Hundredth Monkey Effect - Wikipedia, the free encyclopedia

   The “Hundredth Monkey Effect” is a supposed phenomenon in which a learned behaviour spreads instantaneously from one group of monkeys to all related monkeys ...
   en.wikipedia.org/wiki/Hundredth_Monkey - 32k - Cached - Similar pages - Note thisgqqw9kMHZRoFt8OyvG9JlHlDgwW5sgV299RIBg3DVr8DolLpJiLqsJelqosQMCWJe3ghxm2XTUvAtSU1k0AvRYTKu3ZWsO88HHco

2. The 100th Monkey Studio

   An open art studio using art therapy and creativity in Portland Oregon.
   www.the100thmonkeystudio.com/ - 14k - Cached - Similar pages - Note this

Then, click on the "Cached" link to view the page from the Google servers -- and avoid nastiness that might be found and the listed web sites themselves.

However...

That little trick doesn't completely protect you. Don't believe me? Just start up your favorite network sniffer (tcpdump, wireshark, etc.). You will see, if the page has certain types of content -- such as images, they will still come from the original web site. Oops! You have been identified, and hopefully not served.

The way to avoid this is to Right Click on that "Cached" link, past it into a browser's URL bar and add "&strip=1" to the end of it, such as...

http://www.google.com/search?q=cache:en.wikipedia.org\
/wiki/Hundredth_Monkey+100th+monkey&strip=1

Now your sniffer will happily report that all information comes only from Google.

Happy browsing!

SANS Forensics Blog is up!

Okay, you heard it here first!  

SANS has created a new blog on digital forensics, and yours truly is the first poster.

SANS has chosen a team of about 25 contributors to provide the latest news, tips, and techniques on the topic of forensics.  There are some great posts on the way, so enjoy!

PenTest at the Alamo!

Last year I took my kids to San Antonio for some fall heat, killer whales, and our first visit to The Alamo. I eventually had to be dragged away from the Bowie knife collection (note to wives: it's a guy thing).

Now I'm ready to go back. Not because I need more time with whales or knives, but because SANS San Antonio (Nov 8-13), will be featuring the new SEC560 Network Penetration and Ethical Hacking class.

I have heard fantastic things about this new class. The courseware author, Ed Skoudis, apparently pulled out all the stops putting this one together. And, for Ed, that's really saying something.

The class is being taught by Jim Shewmaker. Shew is a great instructor, and it should be a rockin' fun time. Also on site will be Tanya Baccam (Oracle-security-guru-extraordinaire) and Jonathan Ham. I assisted Jonathan with the Google Hacking class in San Diego last year, and it was an excellent class... with attendees from the NSA to keep things extra interesting.

Think about it... when it's cold in November, you could be eating chips and salsa, drinking margaritas, and honing your pen testing skills-- what could be better than that!

Ah... finally an exploit framework I can sink my teeth into

Call me a curmudgeon, but I just cannot make myself learn Ruby. I know I should, and I know this "on rails" stuff is really cool, but days are short and I still haven't invented that cloning machine. So, I was excited when I heard that Francisco Amato at InfoByte Security had released evilgrade -- with support for writing modules in perl. This is perl, I know this!.

Also cool is the IOS-like command line interface. I must admit I prefer bash or tcsh, but IOS is plenty familiar and easy to settle into.

Francisco has a very useful readme file posted as well as an impressive video demonstration.

Check it out. :-)

Teaching SEC401 at SANS Community Albuquerque 2008

I will be teaching the SANS Security Essentials (Security 401) class at the University of New Mexico August 11-16. We'll be doing it bootcamp-style (yeah, baby!), so sign up if you want to work hard, play hard, and meet some other security geeks.

SANS Community Albuquerque 2008

Little Things like Butterfly Wings

Little things count. They count a lot. In fact, attention to the little things... the details... and how they fit together makes it easy to bring the big picture to realization.

There are so many times that I have experienced large system failures because someone was too busy, too tired, too lazy, too rushed, too something to do the job correctly. The funny thing is... it is always more work to go back and fix what wasn't done right the first time than it would have to have done the job right the first time. Intuitively people seem to understand this, but why don't they DO it?

Recently I had a network meltdown because a developer on was building a network application. This happened behind a firewall, which is an interesting story for another time. Even though the network was "isolated" we experienced the meltdown because the developer glossed over some "little things" ... and so did I.

His mistake was deciding that on this isolated little test network, he didn't need to follow the recommendations in the RFC -- required by the test network switch he was using -- to re-send ARP packets to reset the aging table timeout. This had a fascinating effect on the test network that was only illuminated by watch the switch port traffic. For a short, initial period of time, the switch would dutifully forward packets from the port the test generator was plugged into to the port the receiving test system was connected to. Then, after the timeout occurred, and no new ARP packet was seen, the switch happily turned itself into a dumb hub... dutifully forwarding packets to every port with link (including the uplink to the switch where the firewall was located).

My mistake was believing that I had achieved isolation by routing a VLAN though a firewall and then back into the same switch as the production network. I convinced myself that I was concerned with stability, not clever attackers or malware... and therefore became complacent.

The engineer is fixing his problem (surely customers would not appreciate this test bench behavior). And I have learned my lesson as well.

The little things count -- just like butterfly wings.

--john

Helpful software or malware?

One thing I often do when visiting relatives is fix their computers. They normally have various theories on what the problems are, but increasingly the issues are caused by "assistants" and "helpers" and "utilities" installed by hardware and software vendors on the systems of unsuspecting users.

A perfect example is TGCMD (tgshell.exe). This site has more details on this software: http://www.answersthatwork.com/Tasklist_pages/tasklist_t.htm
including this amusing (though sad) comment:
"Absolutely nightmarish software which eats up CPU, drives the hard disk hard, causes boot-up Kernel32 errors, generates illegal operations, invalid page faults and much more."

I will add that it caused my in-laws' PC to hang with a "Cannot find tgshell.exe" error and take a very long time to start up.

Sorry, but this is not only spyware (as mentioned at the link above), but -- since it is launching a continual, insidious DoS on the host computer -- in my opinion it's good, old-fashioned malware.

People who should know better

/soapbox-on

People are worried about the wrong things. This gets my bile up sometimes because they have all kinds of crazy rationalizations for their misunderstanding of risk. For example, they might not want to fly or sky dive, but they get in a car all the time. They neglect to look left and right before crossing the street. They get complacent about all the little, important things their parents taught them when they were a kid. Instead they are wooed by the F.U.D. spread by mass media.

Fast-forward to the digital age. It's the same thing. It's not the little lock icon on the web site that makes you secure. It's your behavior. And, even worse is when the people who should know better, system administrators and system architects, build systems where the windows have bars, but the front door is left wide open.

And complacency is not only for the uninformed. Sometimes it's willful ignorance (or even flat-out stupidity) from people who should know better that creates the problems. If someone says, "Oh, it's SSL encrypted," you had better challenge them by asking, "SSLv2 or SSLv3? What is the cipher used? Are you sure it is sent to encrypt? Better yet, I'll sniff packets and check myself." This happens because the people who should know better don't do their jobs. And then (this is the best part), they defend their position vehemently. As in, "Well, SSLv2 is good enough. Do you think hackers really want this data?" Or, as I heard not long a go (I kid you not), "Who the heck would crack a non-priveleged account?"

Sigh. It's a tough world out there folks. If you should know better, act better.

/soapbox-on (still)