What does Determina do?

If you want to know what we do, see the post of one of our investors, David Cowan. I couldn't have said it better myself. It's cool when the people that you work with really get it...

"If It Ain’t Broke Don’t Fix It, but worms and other hacks have raised the dreadful prospect that every important computer system in the world needs to be fixed on a weekly basis. That’s why Determina has developed a memory firewall to protect software on computer servers and clients alike so that they no longer need security patches. Unlike other Intrusion Prevention Systems, Determina never generates a false-positive alert, and stops even new attacks without requiring data streams of new signatures, so Determina can scale to the largest networks without human supervision."

What do you do with a vulnerability?

This indictment got a lot of press a few days ago. It goes into gory detail about how vulnerabilities might be used to establish and control 'botnets'. There are lots of stories out there, but this actually gets closer to the real truth of it.

MS06-001 vs MS05-053

As part of my work on LiveShield, I get to analyze a lot of vulnerabilities, both new and old. The purpose is not only to make sure that our product protects against them, but also to get more experience with the kinds of code and bugs that we are likely to see again in the future. Most vulnerabilities follow identifiable patterns, and recognizing those is very valuable when you have to analyze a 0-day that is actively exploited in the wild.

In the best case scenario, the new vulnerability will be in a piece of code that you are already familiar with. When the first WMF vulnerability was announced in November of last year, Jim and I spent a significant amount of time analyzing the vulnerable code. In the end, we had a pretty good understanding of the WMF file format, the functions responsible for processing those files, and their general weaknesses. When the WMF 0-day hit on December 27-th, it took me less than 15 minutes to trace through the code and figure out what was going on. I was disappointed that I had missed this vulnerability back in November, even though I had been looking at the same function in GDI32.DLL. My only excuse is that I was looking for bugs in the code, not for features that shouldn't have been there in first place.

Our response time on this bug would have been much longer if we had to start analyzing the WMF parser from scratch on the 27-th. I hope that as we gain more experience, we will be able to react this quickly to a wide range of vulnerabilities.

Good vs. Bad: Hook behavior

This entry notes that there are a bunch of products that use 'rootkit' behavior.

Sony DRM was an egregious example of a software provider changing the behavior of the system in unusual ways. The dirty little secret of Windows programming is that lots of vendors change the behavior of other programs on a Windows system in ways that make it difficult to distinguish between good and malicious activity.

Back in the good old days of Windows 3.1, it was easy for other programs to modify another program. Of course, you aren't supposed to do that in modern operating systems such as NT, 2000, or 2003. Processes are supposed to be separate entities so that incorrect behavior by one program doesn't crash or hang the whole system.

The only problem with that is that folks like Jeff Richter and others have documented all of the ways for a program to violate this normal constraint, and IT HAPPENS ALL THE TIME.

I was reminded of this a couple of times in the last few weeks. First, Google Toolbar hooks a number of functions in Internet Explorer. There are a number of reasons why they might do it, but they do it in a way that is similar to what a hacker might do: namely they allocate some memory to perform the hook and then sometime later they change the permissions on the memory to be executable. At least they mark it as executable at some point. BUT the problem is that suppose that a hacker is trying to get some injected code to run, they may do exactly the same time: namely they find some memory that has been allocated before and they mark the area as being executable.

Stuff like this makes it more difficult to tell good from bad behavior in-memory. It would be nice if the platform vendor established a protocol for making inserting these kinds of hooks that was difficult for hackers to emulate.

Is WMF a trend?

Microsoft was indicating that the wmf vulnerability from last week was something new because it took advantage of a particular 'feature' of the format and wasn't a bug per se.

That's true, but it isn't the end of the story. Although the particular vulnerability in this case was unusual, Internet Explorer and other applications, such IM, iTunes, or anything that accesses the Internet can become an easy vector for this kind of attack. The defect may be unusual, but the mechanism for attacking could be replicated. There are a couple of trends going on here that make this easier than before. First of all, adware and spyware makers have set up fake websites, etc. to distribution their wares. Normally, they might use phishing attacks or email to convince unsuspecting users to download their spyware. With these kinds of code vulnerabilities, they can bypass the need for user interaction. Given this infrastructure exists, all they are waiting for is the next vulnerability and resulting exploit to surface in IE or other Internet facing applications to take control of thousands of systems or distribute bots and/or spyware.

Microsoft may fix up IE (and all its plug-ins???), but there are lots of other inet applications for an enterprising hacker to compromise for profit.

WMF patches and Liveshield

One of the most interesting aspects of the recent wmf drive-by attacks is that an 'unofficial' patch was created for the vulnerability as well as some workarounds by Microsoft. The unoffical patch is a one-off example of a capability that we have in Deteremina's VPS, called 'LiveShield'. For some vulnerabilities (didn't need it in this case), we generate a similar out of band patch that goes after the root cause of the vulnerability.

There are several critical differences in what was done by Ilfak and what LiveShield does on a regular basis:

1. We've got a delivery mechanism that gets this out on all of your machines in secure fashion
2. It's not a one-off event
3. It doesn't require extra configuration or a reboot of your computer to take effect. This is really important for servers.
4. It doesn't have to be undone when you get the patch from the vendor. Here's an example of a message sent out by a patch management vendor last night:

"If you have un-registered the shimgvw.dll files as a temporary workaround for this vulnerability, or you’ve installed a third-party patch to address the WMF vulnerability, xxx recommends deploying the Microsoft MS06-001 patch, reboot, then re-register the .dll files and/or uninstall the third-party patch."

With our LiveShields, you wouldn't have to do any of this to deploy the patch. It just happens automatically based upon our core matching technology.

HD Moore and WMF disclosure

The WMF defect that has been all over the news media recently had one component that was just foolish. Once 'hacker' exploits had been discovered by the community, H.D. Moore very quickly created an exploit that demonstrated how the vulnerability works. Some people are claiming that this kind of public disclosure is irresponsible and there are even polls denouncing HD.

Nothing could be further from the truth. The bad guys already had exploits and were set up to succeed. He saved a lot time for the security community. For example, using his exploit, we could very quickly verify that our Memory Firewall technology just protected against any of the exploits out there with no loss of functionality. It would have taken us extra time to verify that without the existence of an exploit. We were able to build on that to find other indepth facts about the various bugs in the wmf parser.