Determina Security Blog

Determina Personal Edition and SPF

2007-06-29T15:06:00.000-07:00

As some people know, we've been in the process of making our 'lights-out' security solution available for the consumer market over the last couple of months. While we're not ready to release it to the general public, we have been posting new betas at www.determina.com/consumer recently, and the latest rev is significant.

For one thing, we have changed the GUI so that it is catchy and 'consumer-friendly'. Our enterpriese products have a great interface, but they are oriented toward somebody who is a security administrator at a Fortune 1000 company. It's assumed that they know alot about security events, are managing 1000's of machines, etc. You can't and don't want to do that in the consumer marketplace. Hence we've introduced a new GUI that allows a minimum amount of control, and only the essential features.

Second, and the reason for this post is something called SPF or System Protection Factor. One of the biggest problems that normal folks (me included) have is keeping up with patches from multiple ISV's. Microsoft does an okay job with auto-update, but even there if your PC is a year or so old, you may not be getting all of the latest patches and you won't know it. Worse yet, there are a bunch of other ISV's who put out patches, and you may not have them installed either. Lastly, there are always the 0-days to worry about that don't have patches.

SPF computes a single number to indicate how vulnerable you are. First, it tries to figure out which known vulnerabilities are still active on your machine. Second, it shows how much Determina's VPS protection would help if it is installed and activated.

When put together SPF and VPS protection give you extra knowledge and provide you with great protection against vulnerabilites in the software on your desktop that hackers might exploit without your knowledge.

Driveby downloads

2007-05-30T12:57:00.000-07:00

The folks over at Google have posted a paper where they have searched their web cache for drive-by attacks that take advantage of vulnerabilities that transparently allow malware to be downloaded. It's significantly more data walked than others papers that I've seen. The paper also characterizes the mechanisms that hackers use to infect third-party sites dynamically.

Of course, with VPS installed you shouldn't be vulnerable to most of these kinds of attacks :)

Google Talk

2007-05-22T16:30:00.000-07:00

Alex was over at Google yesterday to give a talk about exploiting vulnerabilities and some of the techniques that hackers use. It gives a number of examples of current techniques which show why products like Determina VPS are important for mitigating risk against vulnerabilities.

Here's a pointer to the video .

Heap Feng Shui

2007-04-05T16:35:00.000-07:00

With all of the hubbub over the ANI vulnerability over the last week, we neglected to mention a recent paper and preso that Alex gave at BlackHat Europe last week. There are three parts to any memory-based exploit:

1. the software vulnerability that allows memory to be overwritten
2. setting up the processes memory to contain information that you want it to contain.
3. the structure of the actual shellcode.

For recent browser-based vulnerabilities, it has been known how to use heap-spraying to put the shellcode into the process for awhile. However, it has become more difficult to actually overwrite a location that causes one to branch into that shellcode. Alex's paper describes how to use Javascript to force the heap into a particular configuration that the hacker desires to take advantage of a vulnerability. To get there, you have to take a reverse engineering trip through several layers of abstraction in the software. Very elegant!

Enjoy the read pointer.

Exploiting Vista with ANI

2007-04-02T17:10:00.000-07:00

This is a short flash video of exploiting the ANI vulnerability on Windows Vista. The exploit works against both Internet Explorer 7 and Mozilla Firefox 2.0.

Click on the image to play:

1994 called, it wants its bug back!

2007-02-12T16:36:00.000-08:00

Sometimes I wonder why we bother with all these impossibly hard to exploit heap corruption vulnerabilities when there are still remote code execution bugs that can be exploited with nothing more than a simple command.

This weekend there was a post on the Full-Disclosure mailing list describing a mindblowingly simple remote root vulnerability in Solaris:


telnet -l -fusername hostname

The telnet command above will log you in on any Solaris box with any username, without authentication. All you have to do is put '-f' before the username. On some system the root login is disabled, but you can log in as user bin and easily escalate your privileges to root.

Amusingly, it turns out that this is a ancient bug, first reported in 1994 on AIX. You can read its entry in OSVDB, including a link to the original discussion on Bugtraq.

The cause of the vulnerability is the -f option of /usr/sbin/login. This option tells login that the user is pre-authenticated and should be allowed to log in with the username specified after the option. As a security mechanism, login allows the use of the -f option only when it is invoked with root permissions. The relevant Solaris code in login.c is given below:


1399    case 'f':
1400            /*
1401             * Must be root to bypass authentication
1402             * otherwise we exit() as punishment for trying.
1403             */
1404            if (getuid() != 0 || geteuid() != 0) {
1405                    audit_error = ADT_FAIL_VALUE_AUTH_BYPASS;
1406
1407                    login_exit(1); /* sigh */
1408                    /*NOTREACHED*/
1409            }
1410            /* save fflag user name for future use */
1411            SCPYL(user_name, optarg);
1412            fflag = B_TRUE;
1413            break;

If the fflag variable is set by the code above, the authentication step is skipped:


528    /* we are already authenticated. fill in what we must, then continue */
529    if (fflag) {
530
531            if ((pwd = getpwnam(user_name)) == NULL) {
532                    audit_error = ADT_FAIL_VALUE_USERNAME;
533
534                    log_bad_attempts();
535                    (void) printf("Login failed: unknown user '%s'.\n",
536                        user_name);
537                    login_exit(1);
538            }
539
540    } else {
541            /*
542             * Perform the primary login authentication activity.
543             */
544            login_authenticate();
545    }

As long as untrusted users are not allowed to specify the -f option to login,
this code will be safe. Unfortunately, the in.telnetd daemon does not sanitize
the username before it passes it to /usr/sbin/login. Look at the code in
in.telnetd.c:


3199    } else /* default, no auth. info available, login does it all */ {
3200            (void) execl(LOGIN_PROGRAM, "login",
3201                        "-p", "-h", host, "-d", slavename,
3202                        getenv("USER"), 0);
3203    }

If the username passed by the telnet client starts with '-f', login will interpret it as a command line option and the user will be logged it without any authentication.

If you still have telnetd enabled on your servers, now is a good time to turn it off.

UPDATE: The fix for this bug is available in the OpenSolaris CVS

Fuzzing shouldn't work!

2007-01-27T13:06:00.000-08:00

After the Month of Browser Bugs ended in August 2006, I imagined that browser fuzzing will be over soon. The widespread awareness of this technique and the release of multiple HTML and ActiveX fuzzers were going to help eradicate all easily-found bugs. Vendors were going to incorporate fuzzing in their QA process, and I expected that running a fuzzer in 2007 would be pointless.

It turns out that I was wrong. After the release of Vista, I ran a very simple ActiveX fuzzer against it and only a few minutes later I hit a NULL pointer dereference bug in Internet Explorer. You can read the full advisory at our security research site.

The ActiveX fuzzer I used was extremely simple - it instantiated each available ActiveX control and accessed all its properties. It didn't even have to send any malformed data or long strings, just accessing the ActiveX object was enough to crash the browser. Something this simple isn't supposed to work!

I agree with Microsoft's assessment of the bug as something that's probably not worth fixing in a security update, but the fact stands: this is a bug that should have been found and fixed very early in the development cycle. Maybe next time they'll do better.

Vendor acknowledgement policies

2007-01-24T01:03:00.000-08:00

In a recent post on the Matasano blog, Dave G. asks whether acknowledging MOAB in their latest QuickTime security update was a wise decision on Apple’s part. I believe that it was, and I recommend that other vendors follow this practice as well.

Microsoft has a stated policy against acknowledging the work of researchers that do not follow their "responsible" disclosure guidelines. This policy has been successful in encouraging the security industry to play by Microsoft's rules, but their definition of "responsible disclosure" is still far from universally accepted. A quick look at milw0rm or bugtraq shows there are many independent researchers who disclose vulnerabilities and publish exploits with no regard for any policies other than full disclosure.

What is the best way for a vendor to handle a publicly disclosed vulnerability? Releasing a workaround or a patch should have the highest priority, but the vendor's responsibilities do not end there. Many advisories are needlessly vague in describing the vulnerabilities, even though the vendor admits that the information is already public. This makes it harder for security teams to evaluate both patched and unpatched bugs and to realistically assess their exposure.

If you don't believe me, take the following challenge:

Without installing any security updates or running any PoC code, find out which of the MoBB vulnerabilities have been patched, and list the corresponding Microsoft security bulletins.

The vendors are in the best position to provide this information. It is not as important that they they credit the researchers, but they need to provide links to all publicly available information about all vulnerabilities addressed in each patch. This is exactly what Apple did by acknowledging MOAB in their latest QuickTime security update, and I commend them for it.

What's wrong with WMF?

2007-01-10T17:46:00.000-08:00

As a kid I was fascinated by the Indiana Jones movies and their portrayal of the brave explorer searching for artifacts in ancient tombs and ruins. These days my job as a security researcher involves a certain amount of software archeology. Many software vulnerabilities are a result of old and long forgotten code, often interacting in unexpected ways with new systems.

A great example for this is the WMF file format, a source of multiple vulnerabilities over the last two years. This format was based on a wrong design decision which has come to haunt Microsoft ever since. In this post I will describe the fundamental design flaws in the WMF format and analyze a new attack that was disclosed publicly today.

WMF is different from typical bitmap graphics file formats. It contains a sequence of processing instructions that are interpreted by the display system and used to draw an image. In this the format is similar to PostScript. Unlike PostScript however, the WMF file format is not based on an abstract graphics language, but instead maps directly into Windows API calls. Each record in the file contains the arguments for a single Windows API function. An advantage of this design is the ability to open a WMF file and record a series of Windows API calls into it. When the file is viewed later, the API calls will be replayed and will draw the image. Unfortunately, this design violates one of the main requirements for secure system - a clear separation of trusted and untrusted data.

The Windows API makes the fundamental assumption that the program issuing API calls is trusted. If the program passes invalid arguments to an API function, it will crash, and the programmer will have to fix it. Unlike the syscall interface to the kernel, the Windows API functions are running at the same privilege level as the program that calls them. This makes it possible to omit a lot of parameter validation.

When we introduce WMF files into this system, the basic assumption breaks. WMF files downloaded from the Internet are untrusted, and so are the parameters that they pass to the Windows API functions. If an untrusted parameter is passed without validation, the WMF file will be able to crash or exploit the program that displays it.

An example of this kind of attack was posted on milw0rm earlier today. The WMF file created by the exploit calls the CreateBrushIndirect function and passes it a LOGBRUSH structure from the file without validating any of its contents. According to the MSDN documentation, the lbHatch field in the structure is a constant specifying the hatch style of the brush. However, when the lbStyle field is BS_DIBPATTERNPT, the lbHatch parameter is used as a pointer to a device-independent bitmap structure in memory.

The PoC code on milw0rm sets the lbStyle field to BS_DIBPATTERNPT and passes an invalid pointer value in lbHatch. This value is dereferenced inside GDI32.DLL. Since this address is invalid, the memory access causes an unhandled exception and the program displaying the WMF file crashes. The impact of the vulnerability is limited and does not allow remote code execution, but it is still a good illustration of the fundamental problem with the WMF format.

Solving this problem is not easy, but it can be done. Writing a formal specification for the WMF format and implementing a validating parser would be a good first step. The mapping between each WMF record and Windows API function must be audited for unexpected interactions and issues such as the one described above. Only then can we be reasonably sure that the WMF format is reasonably safe to use for untrusted Internet content.

Vulns in Vista, no way?

2007-01-10T06:58:00.000-08:00

I certainly applaud the efforts that Microsoft has made in improving the security in Windows. I don't know the other vendors well, but they're ahead of most other ISVs.

However, to think that means there won't be vulnerabilities in Vista is sort of silly. Simply stated, new or changed code means that there will be new vulnerabilities given the state of art of application security testing today.

For example, we just started a new initiative on our website today with a zero-day page where we record significant zero-day vulnerabilities that may be of interest to our customer base. We recently reported 5 such vulnerabilities to Microsoft in Vista.

I wonder what 2007 will bring. 2006 saw a significant increase in 0-days with IE being openly vulnerable for 284 days during the year as documented by Brian Krebs, and lots of Office 0-days that seemed timed to come just after 'Patch Tuesdays'.

Vista notices

2007-01-02T14:23:00.000-08:00

Recently, there has been the start of some discussion around vulnerabilities on Vista. The NYT and CNBC were interested in what we've done in that area recently. See our research page for some more details...

Links

2006-03-28T14:51:00.000-08:00

Nice description of our patch from hexblog. Bing!

There are lots of other links off our news page.

Fix for IE

2006-03-28T05:57:00.000-08:00

When there is a 0-day situation because of a vulnerability that hasn't been patched, it's even more trouble than when the vendor has patched the problem and disclosed it. On Friday, we started noticing that there were a number of PoC's that exploited CVE-2006-1359. Even though our Memory Firewall technology protects against this vulnerability out of the box, we're not widely deployed on desktop systems (yet).

Back in December Ilfak decided to do something similar for the WMF vulnerability and we took note because he did a one-off of the thing that we do for a living around here. We thought it was very cool because it solved the problem and a lot of people downloaded his patch as a temporary workaround. Hats off to Ilfak for inspiring us.

So we decided Friday afternoon that it would be a public service to the community if we created a one-off 'fix' that employed elements of our LiveShield technology to have a quick downloadable exe that would repair the problem once and for all. By Saturday afternoon, Alex had produced the fix and Monday was spent packaging and testing the fix . Our fix literally changes only one byte of code in the executable and addresses the root vulnerability.

We released it last evening, complete with the source so that independent parties could decide whether or not it is a fix. Here are some relevant links.

Now, this disclosure was important enough that the guys at eEye also tried to address the issue. Of course, I like our fix better because when the Microsoft patch comes out, you don't have to take any action, you just get the vendor's patch. I haven't done much analysis of their fix, but I think you have to go through an uninstall procedure with theirs.

RSA Conference

2006-02-15T09:23:00.000-08:00

Come by the Determina booth at the RSA conference. Out 'address' there is booth 1942. We're also in the innovation station.

What does Determina do?

2006-01-24T12:06:00.000-08:00

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?

2006-01-17T14:10:00.000-08:00

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

2006-01-13T22:09:00.000-08:00

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

2006-01-13T10:29:00.000-08:00

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?

2006-01-09T17:37:00.000-08:00

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

2006-01-06T07:01:00.000-08:00

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:

We've got a delivery mechanism that gets this out on all of your machines in secure fashion
It's not a one-off event
It doesn't require extra configuration or a reboot of your computer to take effect. This is really important for servers.
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

2006-01-06T06:48:00.000-08:00

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.