IT Security Blog

There has been quite a bit of press over the last day or two with respect to a design flaw with SSL that could allow an attacker to forge a security certificate such that it circumvents the built-in authentication methods within your browser.  This means that your browser could believe that a malicious, look-alike web site for your bank could authenticate to your browser as your real bank web site if this attack is carried out correctly.  See this story from CNET that has a graphical proof of concept example using Bank of America.

If you are not familiar with MD5, essentially it is a 128-bit hashing algorithm that is used by many security applications.  For example, an MD5 hash is commonly used as a checksum by system integrity validators (SIV) to ensure that key binaries on your system have not changed their default composition (if they have, this could indicate a trojan or rootkit has been installed on your system). 

MD5 checksums have been known for some time to not be completely secure as it is typically expressed as a 32-bit hexadecimal number.  This means that there are only a finite number (2^128) of potential hash possibilities.  This has been considered to be good enough for many applications, but with the power of today's clustered computing environments (also including botnets), it has been found that the time it takes to generate a targeted MD5 collision has been greatly reduced.  According to the CNET article, performing the initial forgery proof of concept took about 2 weeks on a cluster of 200 Playstation PS3s.  This kind of computing power is infinitesimal compared to most botnets.  Quite a few articles on the web (do a Google search for "md5 collision example" and some will yield source code) already discuss how easy it is to create an MD5 collision. 

Web site forgeries are only one example of how MD5 collisions can be used to circumvent security technologies.  My friend Adam O'Donnell from Cloudmark points out in a Twitter update that an MD5 collision could also be utilized to make malicious software look legitimate.  Take our SIV example from earlier.  If a malicious version of a binary was created with the same md5 checksum as its legitimate counterpart, your security checks may never identify that the original executable was modified if your PC were to get infected with some type of trojan or rootkit.  This could also cause AV companies to have to rethink how they do some of their own scanning methods also.

What all of this really highlights is the fact that MD5 is no longer a "good enough" (and in reality hasn't been, but that hasn't stopped people from using it) hashing algorithm if your intention is to create a hash that will be used as part of any kind of security/authentication system.  I agree with Paul Kocher's statements from the CNet article in that although this is certainly not one of the biggest security issues facing us right now.  Between all of the other application based attacks that exist, this one could be potentially very dangerous as it is another one of those that we have discussed that do not require elaborate social engineering to be carried out effectively (at least for web site forgeries) as the redirection to a malicious site can be carried out at the network level. 

This is not one of those types of attacks that is likely to occur on a large scale against many widely used web sites (like the Bank of America proof of concept) as it would likely get sniffed out very quickly, but if used for smaller, more localized attacks could prove to be effective. 

According to this story posted on Wired yesterday, a keylogger has been found on laptops being used in the space station.  The reported malware, W32.Gammima.AG (see here for description on Symantec's web site), has been around since August 2007 and steals passwords from a few (rather obscure here in the United States) online games.

You are thinking "So what?  What risk does an online game keylogger pose to a laptop on the space station?  Why should I care?"

As you know, we like to think bigger picture here.

Let's start with the obvious question of why the anti-virus software running on the laptop didn't immediately identify and stop a one year old virus?  I don't know about you, but that sends up lots of red flags to me!  This obviously begs the question of how long this keylogger has actually been resident on the laptop and if there are other, yet undetected, rootkits and keyloggers on those machines?  Also, what other computers were potentially exposed to these infected machines that this virus could have propagated to?  What information has been exposed to theft or compromise either from the laptops or from other exposed machines on the NASA network?  What was done with these laptops once the virus was detected?  Were they merely cleaned to the virus scanners standards (which clearly aren't that high!) or was the computer completely taken out of commission so that it could be wiped to Department of Defense specifications and re-imaged before it was redeployed? 
Obviously there are a lot of unanswered questions in relation to this story, and of course NASA will never make the answers to those questions public, but this certainly calls into question the validity of the security measures employed by one of the most important programs of the 20th and 21st centuries.  Where else within the federal government does the potential for similar security breaches exist?   Are potential data leakages like this something that the Department of Homeland Security is focused on preventing?  If not, they should be!  Let's be sure we aren't aiding and abetting the bad guys by giving them the exact information we are looking to protect!

According to this article posted on CSO Online, a security researcher named Sebastian Muniz has created a rootkit that will work on "several different versions of IOS." 

One of the concepts that I have been throwing out there since we originally started talking about drive-by pharming (aka DNS Rebinding attack) is the potential of similar vulnerabilities being exploited in an effort to move malware infections out closer to the network edge and create a "router bot" whereby a compromised router could potentially be used for the distribution of spam, viruses, and malware similar to how PCs are used today.  This would be even more difficult to detect than a PC based malware infection, however as I do not believe that there are any network device based rootkit/malware detection engines that even exist right now (please do correct me if I am wrong here) although this may certainly create a market for them.  Would you be able to easily detect if your router was being used to distribute spam if it wasn't affecting your web browsing or normal internet usage?  Not likely.

One of the things that concerned me from the article was the quote from EuSecWest conference organizer Dragos Ruiu where he said that "nobody thought you could actually build exploits for Cisco."  This is a dangerous attitude to have for any software application.  I like to say "Where there is software, there are vulnerabilities."  This is often followed by "Where there are vulnerabilities, there are exploits" although far more vulnerabilities exist than there are exploits written for them. 

One should never assume that software is hacker-proof.  It very well may be (however unlikely), but even making the assumption or suggestion is when you've conceded that your guard has been let down.  Always remain diligent in your pursuit of security!

Ok, I'll step off my soapbox now.  Have a great weekend!

Nice to be back!

Between our webmaster working on a new blogging tool for me to use and the first of three Messaging Anti Abuse Working Group (MAAWG) meetings for the year in San Francisco last week (I am now Chairing the Botnet/Zombie Subcommittee), I've not had nearly the time that I normally have for blogging over the past couple of weeks.  I've been queuing up topics in the meantime though so we should be back on our regular posting cadence now. 

In comparison to most previous years, 2008 is off to a pretty fast start as it relates to spam and malware.  Save for last year when the Storm Worm started January off with a bang, the months of January to April are typically a bit slow from the perspective of new worms, malware, and spam volume. The primary reason for this "slow season" is that a good number of your malware writers are of high school/college age.  Those folks are in school or otherwise occupied during the early months of the year.  Come May or thereabouts, schools start letting out for the summer, kids find themselves with more idle time, and the flood of malware and spam begins.  Infections rise, spam levels rise, and things quickly start hopping around our TOC.

2008 has somewhat bucked the trend in that regard as we have seen a number of developments just in the first two months of the year alone: MBR Rootkits, Drive-By Pharming, and continually high spam volumes which normally drop off by as much as 30% after the first of the year.  In fact, the spam volumes that we have been observing this week are UP about 20%  from any other week so far this year!

We've also seen social engineering tactics like Fake Microsoft updates with links to malware and IRS phishing scams claiming that you are due a refund from the IRS that will be gladly credited to your credit card if you provide them with your card number (not new tactics, but worth noting nonetheless) as well as Google spam (email with links to Google search results which forward you to sites that have abused Google's PageRank system).

Google spam is currently accounting for around 100,000 messages per hour that we are seeing in our Threat Operations Center.  Although this doesn't represent a significant percentage of volume, it is the most prevalent spam tactic that we are currently observing.   Compare that to IRS phishing which we are currently seeing at a rate of less than 100 per hour.

If the first two months of 2008 are any indication of what the rest of the year will be like, perhaps it is appropriate that it is the year of the rat according to the Chinese calendar :)

Just as we have reported that there has been a large movement back towards old school type spam tactics like text obfuscations (in lieu of PDF and image based spam) it looks like malware is doing the same and going after the Master Boot Record.

Master Boot Record (MBR) viruses start when your computer's BIOS activates its master boot code (and here comes the key part) BEFORE the operating system loads.

So, why is this important?

Most of your Windows malware that contains a rootkit component will attach itself to one of your Windows device drivers. This means that these rootkits run after the operating system loads (or while it is loading, depending on the device driver). Rootkits that attach to your MBR do so BEFORE the operating system loads. This means that these rootkits are a lot stealthier and as such more difficult to detect, but also much more difficult to remove. Even if you uninstall your operating system, MBR rootkits will still remain on your system, even if the malware which installed the rootkit is removed.

We have hereby crossed the threshold into the next wave of malware as cyber criminals continue to make malware and rootkits less detectable more difficult to remediate.