DLL exploit not a job for secure coding programs

The big "zero-day" exploit this week was the malicious Windows DLL payload brought to the spotlight by Rapid7's HD Moore. Two other researchers appear to have also found this bug as well. Microsoft released a security advisory on this class of vulnerabilities, and stated "This issue is caused by specific insecure programming practices that allow so-called "binary planting" or "DLL preloading attacks". These practices could allow an attacker to remotely execute arbitrary code in the context of the user running the vulnerable application when the user opens a file from an untrusted location."

So which one is it? Is this an issue caused by insecure coding practices, or by insecure desktop administration and security policy execution? The secure coding methodology made famous by Microsoft didn't protect them from having at least 4 major applications affected by this bug. Researchers say that Microsoft has known about this class of vulnerability for anywhere from 6 months to 10 years, depending on who you read. So why didn't they catch this bug? While it might seem to be, this is NOT an admonishment of Microsoft or their secure coding practices. The Microsoft SDL and SDL-Agile are successful, game-changing strategies that I give a lot of credit. The reason the SDL didn't catch this DLL code execution bug is because a bug like this is outside of the scope of a successful secure coding program. In a secure software development lifecycle, the goal is to prevent bugs from the start that are easy and cost-efficient to eliminate. The SDL is great at preventing SQL Injections and catching bugs where code sanitization is the fix, however this bug is in code that is behaving exactly as it was designed. In April 2009, Aviv Raff was told by Microsoft when dealing with a very similar disclosure that this bug was not a simple fix. "They said it would be very problematic to fix the whole thing, and would break a lot of third-party Windows applications."

Microsoft has put out a tool to help administrators mitigate the problem, and has a lengthy description to help guide developers to construct their code differently in the future. This is an appropriate response based on their Security Response Practices. It is possible that it is more cost-efficient to respond to a disclosure such as this than it is to prevent it. Third-party companies such as Rapid7 and Errata Security are adding modules to their auditing tools to check for this attack. Actions such as these may actually cause the DLL Preloading Attacks to become "low-hanging fruit" in the development process in the future, but for now it should not be expected that a secure coding program should have prevented this attack.

Microsoft has good security, but it's not enough

Google(reportedly) says that because of security, it is replacing Windows desktops with Macintoshes and Linux computers. Microsoft replies, claiming that Windows is the most secure operating system. Both are right.

Errata Security releases the results of the survey on secure coding practices

Errata Security released the results of a survey conducted over the week of Security B-Sides and the RSA Conference in San Francisco. The survey found that Microsoft SDL was the most common security development lifecycle chosen of the companies using formal methodologies, but Ad Hoc solutions are still more popular. Small companies are more likely to be using Agile development, and the corresponding SDL-Agile. The most common reason for not choosing to use a formal methodology was resource requirements. Of those that responded they were choosing not to use a secure coding program, a lack of resources was by far the most common answer. No matter what the size of the company, participants said it was too time consuming, too expensive, and too draining on their resources. Another reason was that management had deemed it unnecessary. Management plays a key role in these decisions. The survey showed that developers look to management to set the security agenda, and are generally not self-starters when it comes to including security in their code. Security in the SDLC is still a relatively new methodology. 43% not integrating security is a high number, but it's improving at a steady pace. The adoption of SDL-Agile, which was introduced in November '09, by almost all of the small development shops and several large companies shows us that people are ready to make the shift, they're just waiting for the right style to fit their needs. Here are the press links covering the story, and a link to the actual paper: Download the Survey Results (pdf): "Integrating Security Into the Software Development Lifecycle" Dark Reading: "Survey Says: More Than Half of Software Companies Deploying Secure Coding Methods" CSO Security and Risk: "Code Writers Finally Get Security? Maybe" Microsoft SDL Blog: "Survey Results: Microsoft SDL awareness on the rise" Jeff Jones Blog: "SDL AWARENESS AND ADOPTION HIGH AMONG SECURITY PROFESSIONALS" Help Net Security: "Root issues causing software vulnerabilities"

Random musings...

Have you noticed that Microsoft does not seem to want you to look at application crash data in Windows Vista? This morning I was doing…something…that…involved Flash. A 0xc0000005 error popped up and the application automatically restarted. No big deal I though, when it asks if I want to report the fault I will say no and grab the dump file. It didn’t ask if I wanted to report the error, it just did. To add insult to injury it deleted the dump file. It looks like its time to do Vista research offline from now on.

New RTSP Quicktime flaw affects both OSX and Windows

Apple’s unsafe and cavalier attitude towards security puts not only Macintosh users at risk, but also Windows users. The latest QuickTime flaw demonstrates this. QuickTime is Apple’s multimedia player. It’s the part of iTunes that plays the music/videos, although you can install it separately without iTunes. Windows users who have iPods or attempt to play “.mov” videos will likely have QuickTime installed.

QuickTime is written in an inherently insecure manner. This puts at risk anybody who uses it, Windows or Macintosh. There have been a constant stream of bugs in QuickTime published over the last couple years, such as the famous 0day that won a Hack the Mac contest.

Address Space Layout Randomization

The most interesting bit of these latest QuickTime vulnerabilities is how they react with “Address Space Layout Randomization” or “ASLR”. ASLR is a technique of mixing things up in memory so that hackers cannot find them. This is armor that prevents vulnerabilities from being exploited in practice.

Apple announced ASLR as a feature in their latest version of the operating system, Mac OS X 10.5 (TigerLeopard). However, Apple largely lied. While some insignificant items were indeed randomized, nothing that hackers are interested in where changed. If Apple had fully randomized things like Windows Vista, then this QuickTime vulnerability would (likely) not be exploitable.

Does this mean that this vulnerability is not exploitable on Vista version of QuickTime? Humorously, Apple still has a problem here. Vista ASLR requires a little cooperation from developers. Developers have to link their code with the flag /dynamicbase. This sets a bit in their compiled code that tells Vista it can randomize the layout of memory. Apple developers do not set that all-important flag, telling Vista NOT to randomize their layout.

Even though Apple didn’t set it, you can set that flag yourself. It’s just a single bit within the DLL file. If you flip that bit, then Vista will load QuickTime in a randomized fashion. As far as we can tell, QuickTime runs just fine under Vista with the ASLR bit set.

The original location of QTOControl.dll.

What it look like in PE Explorer.

After its been modified save and copy it back. (note that Vista requires admin privs to copy the file)

The new location of QTOControl.dll.

Watching a video.

QuickTime has multiple executables, all of which must be changed in this manner. We set this bit on all the DLLs, then tried the latest QuickTime exploits. As we expected, setting the flag stops the exploits from working, protecting the system.

Changing a major application like QuickTime is not as easy as snapping your fingers, but Vista has been out almost a year now so it seems like support should have trickled down now. Apple should have enabled randomization in QuickTime.

RTSP handler

The easiest way to exploit QuickTime was URLs that caused it to be executed directly. Both IE7 and Firefox 2.0.0.9 have removed the rtsp:// handler. This makes it harder to reach QuickTime. Users must manually download a QuickTime file and play it, rather than simply following a link. When trying to play QuickTime files, Vista will warn the user that they may be accessing malicious content.

Below is what message I get while trying diffrent attack methods via Firefox.

Unfortunately, Safari still supports the rtsp:// handler, meaning they are at much greater risk than IE/Firefox users.

The Proof of Concept (PoC) Exploit

Below is a screen shot of gdb attach to the QuickTime Player after the exploit was successful. It is crashing because of an attempt to dereference EAX, which is 0x41414141. You can see in the instruction before EIP that EAX is loaded from a deference of EBP+0x10. Looking at EBP the pad the author of the PoC chose, 0x41, can clearly been seen.

Tracking down this bug is easy considering the information given by the PoC author about it being a stack overflow. The problem is a lack of length checking in the _EngineNotificationProc before calling a function called BlockMoveData. BlackMoveData is just a wrapper for bcopy(), a notorious bad function from a security standpoint.

Microsoft has impressed the security community with its dedication to secure coding practice. It bans dangerous functions like bcopy(), and forces its programmers to use safer versions (such as memcpy_s(),the safer version of bcopy()). Apple has not adopted secure coding practices; they still use known dangerous code such as bcopy(), sprintf(), strcpy(), and so on.

Breaking on the _EngineNotificationProc.

(gdb) set disassembly-flavor intel
(gdb) break _EngineNotificationProc
No symbol table is loaded. Use the "file" command.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (_EngineNotificationProc) pending.
(gdb) attach 316
Attaching to process 316.
Reading symbols for shared libraries . done
Reading symbols for shared libraries ..................................................................................................................... done
Breakpoint 1 at 0x174816fd
Pending breakpoint 1 - "_EngineNotificationProc" resolved
0x93442446 in GIF_CDBandDecompress ()
(gdb) c
Continuing.

Tracing the bad data.

0x174329bc in INet_GetFieldBody ()
1: x/i $eip 0x174329bc : mov edx,eax
(gdb) x/20x $ebp
0xbfffc908: 0xbfffcbc8 0x174820d8 0x17bdb811 0x00001447
0xbfffc918: 0x175732d5 0x15af8808 0x00000000 0x69746c32
0xbfffc928: 0x0000bd7e 0x00000000 0x00000012 0x00000010
0xbfffc938: 0xbfffc948 0x92d90000 0x00000012 0x00000006
0xbfffc948: 0xbfffc958 0x00200020 0x00000000 0x0083f69c
(gdb) info registers
eax 0x17bdb837 398309431
ecx 0x0 0
edx 0x15 21
ebx 0x17481708 390600456
esp 0xbfffc8e0 0xbfffc8e0
ebp 0xbfffc908 0xbfffc908
esi 0x17bdb811 398309393
edi 0x15af8808 363825160
eip 0x174329bc 0x174329bc
eflags 0x286 646
cs 0x17 23
ss 0x1f 31
ds 0x1f 31
es 0x1f 31
fs 0x0 0
gs 0x37 55
(gdb) x/20x $eax
0x17bdb837: 0x70737472 0x302f2f3a 0x302e302e 0x312f302e
0x17bdb847: 0x33706d2e 0x430a0d2f 0x65746e6f 0x542d746e
0x17bdb857: 0x3a657079 0x41414120 0x41414141 0x41414141
0x17bdb867: 0x41414141 0x41414141 0x41414141 0x41414141
0x17bdb877: 0x41414141 0x41414141 0x41414141 0x41414141
(gdb) x/20s $eax
0x17bdb837: "rtsp://0.0.0.0/1.mp3/\r\nContent-Type: ", 'A' ...
0x17bdb8ff: 'A' ...
0x17bdb9c7: 'A' ...
0x17bdba8f: 'A' ...
0x17bdbb57: 'A' ...
0x17bdbc1f: 'A' , 'B' ...
0x17bdbce7: 'B' ...
0x17bdbdaf: 'B' ...
0x17bdbe77: 'B' ...
0x17bdbf3f: 'B' ...
0x17bdc007: 'B' ...
0x17bdc0cf: 'B' ...
0x17bdc197: 'B' ...
0x17bdc25f: 'B' ...
0x17bdc327: 'B' ...
0x17bdc3ef: 'B' ...
0x17bdc4b7: 'B' ...
0x17bdc57f: 'B' ...
0x17bdc647: 'B' ...
0x17bdc70f: 'B' ...
(gdb)

The guilty system call.

1: x/i $eip 0x1748216f <_enginenotificationproc+2680>: mov DWORD PTR [esp+0x4],edx
(gdb)
0x17482173 in _EngineNotificationProc ()
1: x/i $eip 0x17482173 <_enginenotificationproc+2684>: mov DWORD PTR [esp],eax
(gdb)
0x17482176 in _EngineNotificationProc ()
1: x/i $eip 0x17482176 <_enginenotificationproc+2687>: call 0x175812ae
(gdb) x/20x $eax
0x17bdb85c: 0x41414141 0x41414141 0x41414141 0x41414141
0x17bdb86c: 0x41414141 0x41414141 0x41414141 0x41414141
0x17bdb87c: 0x41414141 0x41414141 0x41414141 0x41414141
0x17bdb88c: 0x41414141 0x41414141 0x41414141 0x41414141
0x17bdb89c: 0x41414141 0x41414141 0x41414141 0x41414141
(gdb) x/20x $edx
0xbfffca99: 0x1f000016 0x6c000000 0x00000006 0xa8000000
0xbfffcaa9: 0x0f001201 0x6c92dbbc 0x000083f6 0x5800000c
0xbfffcab9: 0x2517bdcc 0x009494bd 0x00000000 0x08000000
0xbfffcac9: 0x7abfffcb 0x009494bd 0xe0001200 0xa815ae1f
0xbfffcad9: 0x04000001 0x00000400 0x9317b7ba 0xa8175712
(gdb) info registers
eax 0x17bdb85c 398309468
ecx 0x0 0
edx 0xbfffca99 -1073755495
ebx 0x17481708 390600456
esp 0xbfffc910 0xbfffc910
ebp 0xbfffcbc8 0xbfffcbc8
esi 0xffffeae6 -5402
edi 0xbfffcd38 -1073754824
eip 0x17482176 0x17482176 <_enginenotificationproc+2687>
eflags 0x286 646
cs 0x17 23
ss 0x1f 31
ds 0x1f 31
es 0x1f 31
fs 0x0 0
gs 0x37 55
(gdb)

Conclusion

Installing Apple code on a Microsoft Vista system will make that system unsafe. Since these QuickTime vulnerabilities are equally exploitable on both Vista and Mac OS X 10.5, the fans might conclude that both operating systems are equally safe. This is not true, Vista is vastly more secure than the Macintosh. Apple’s only advantage over Microsoft is their small market share, which means hackers are less interested in them. However, as hackers are having a harder time cracking Vista, they are getting more interested in the Mac, and we are seeing more exploits and more malware targeting Apple users.

As always there is more information in the Hacker Eye View report concerining these issuses.

Funny Vista Tricks with ASLR

While doing alot of testing around the implementation of ASLR on both OSX and Vista I noticed something odd. 3rd party dlls in the Internet Explorer don’t seem to change addresses. See the screenshot below. Googletoolbar and flash9d stay at the same address through multiple reboots. I thought this was odd.

Flash9d and Googletoolbar stay at the same address.

Doing some reading it turns out that a linker flag, /dynamicbase, is what tells Vista that it is ok to rebase a DLL. This gave me a bright idea that maybe I could manually enable ASLR support in a DLL. The first step to this is to find out exactly what the /dynamicbase flag does to a binary. I did a couple of things to run this down, but mainly I compared a DLL that utilized ASLR versus one that doesn't. Mshtml.dll takes advantage of ASLR so that the target. Googletoolbar is the binary I want to force to use ASLR. After comparing alot of fields in the PE header i narrowed it to an option in the PE header, DLL Characteristics. Setting this field to 0x40 enables rebasing the DLL.

The real difference is the DLL Characteristic field which has to get set to 0x40.

1. The first step in enabling ASLR for this program is to save a copy of the original file so that it can be restored in case of an accident.

2. The next step is to open the Googletoolbar in a hex editor and find the DLL Characteristics field and set it to 0x40.

These are images of modifying the googletoolbar dll. The byte that is changed is on the bottom role on the right.

3. Save the file. B00m, some ASLR action for Googletoolbar.

Every reboot changes the load address of GoogleToolbar now.

I was worried that this would not work because of application signing. I thought that once an application is modified it would no longer run. No problems like that occurred. The toolbar seemed to work just fine.

I am not advocating doing this to your system DLLs, I just thought it was interesting.

An open letter to computer criminals...

Dear Computer Criminals,

I would like to have a word with you about an event this week. As you might know from the commercials, advertising tie-ins, and reviews, Microsoft’s latest entry in the Halo series becomes available at midnight. In fact, many stores will be opening at midnight to support the expected rush for Master Chief goodness.

Now it may seem that, with the flood of people developing the flu or strep throat or other non-diagnosable aliments resulting in Tuesday being a sick day, that it would be a great time to launch a new worm or add a new attack to your botnet. Its almost like Microsoft fan boys will be leaving the doors to the castle open due to the number of cellphones and blackberries that will be ignored in pursuit of unlocking Halo achievements.

I would, on behalf of these dorks, like to ask you to let this day pass. It is like shooting fish in a barrel; where is the glory in that.

Thank you for your time,
David

Super Tuesday!!

Today is the Microsoft drop day and it was pretty light. The most dangerous bug is the Active Directory vulnerability. Its a bit hard to weaponize but its doable but I doubt there will be much of a worm. If someone manages to get it working it will more likely be used in directed attacks. Once again this proves how bad ass Neel Mehta is.

Since Errata finished up early today covering these vulns and we know super Tuesday is all any security blog will discuss today, I know present you with videos of Dillon miniguns!




And...

News from Microsoft: DNS 0day being exploited in the wild

http://blogs.technet.com/msrc/archive/2007/04/12/microsoft-security-advisory-935964-posted.aspx

It seems not long ago I use to observe many an argument about if 0day is ever really used in real world attacks. No one really has those fights anymore; I guess the pundits are weary from all the numerous 0day attacks that have popped up in the last few years. I don’t care to go and dig up links to naysayer’s but I am sure the usual suspects like Lindstrom have pie all over their face on the “0day isn’t really used in attack” predictions.

Back to this new bug, it’s in server code so workstation type installations like Windows XP SP2 and Windows 2000 Pro are not affected. Microsoft, of course, doesn’t give details on the flaw or even what people should look for in a potential attack scenario. The only real clue to this is that it involves RPC and that its not vulnerable over port 53. I can hear the sound of people starting IDA all over the world, I know I am. A bit more of a clue to the problem is given in the “Suggested Action” section: creating a registry key can disable the functionality that allows an anonymous remote attack to trigger a stack based overflow. I personally think Microsoft gave out way to much detail here, but time will tell.

The one thing wish Microsoft would tell you is what sector or client profile is being targeted. No sense for people in a University to get all paranoid if the targets have only been Military installations so far. Of course its never a bad thing if everyone is more cautious.

Errata will have an HEV on this for customers pretty soon.

UPDATE: Running DNS.exe through something like Dave Aitel's UNMIDL or using the Tenable IDA plug-in mIDA (pictured below), there isn't a lot of places a bug could be. The SANs ISC diary initially said it was the DCOM exploit over a new port. The arrived at this conclusion because they claimed that the packets matched a Blaster exploit. One of the byte strings they said matched was this: 05 00 0B 03 10 00 00 00 I found this laughable because if you have spent anytime wrangling packets you know exactly what that is. It’s the beginning of a DCERPC BIND request. The 05 is the major version, the 00 is the minor version, 0B is the request type (in this case it’s a BIND, 03 is the flags, and 0x10000000 is data representation (if its little endian or big endian). If you look at a lot of traffic you will notice that this is pretty standard for the beginning of a DCERPC request, and there are tons of reasons you would see this legitimately.

BTW, since this is a RPC based attack you will see plenty of ways to evade most IPSs when they release signatures for this. Based on the ease of finding this you should see publicly available exploits pretty quickly. The question is will the patch be out quickly enough to make this a non-issue for attackers.

UPDATE 2 PER ROB:

One possible signature for intrusion detection would be to simply trigger on the GUID of {50abc2a4-574d-40b3-9d66-ee4fd5fba076}. In a protocol-analysis system, like Proventia, you could simply add that to the blacklisted GUIDs. In a pattern-match system, you can enter something like:

alert tcp any any -> any 1024: (msg:"DNS DCE-RPC exploit emergency rule"; content:"a4 c2 ab 50 4d 57 b3 40 9d 66 ee 4f d5 fb a0 76"; sid:9999; )

Note that the exploit, and its evasions, are a bit more complicated than just this, so you shouldn't rely upon the above pattern signature catching everything.

Why did the ANI patch take so long?

Microsoft made us all laugh with the comment in their blog about the ANI patch:

I'm sure one question in people's minds is how we're able to release an update for this issue so quickly

Um, no, the question in everybody's mind was why it took so long.

Actually, there is an answer why it took so long. As documented, there was a bug with a RealTek audio control panel. Even if Microsoft makes ZERO code changes, simply rebuilding the product will lead to bugs like this, either within Windows itself, or 3rd party drivers, applications, or control panels. This bug happened because of something wrong in RealTek's code, not Microsoft's code.

Few people realize this but when Microsoft tests a patch prior to shipping, they also test popular third party applications. They find conflicts due to other people's code. When they encounter such an issue, they change their patch until the 3rd party bug no longer appears. In some cases, they have changed the Windows specification just to fix some weirdness in a popular application. Microsoft doesn't like to talk about this because they don't want to insult other people, but this sort of thing happens a lot. What appears to be "Microsoft's fault" is actually Microsoft covering for other vendors.

Everybody complains that Microsoft takes a week to ship a bug fix for an actively exploited bug, but the fact that they can test 30 different versions of Windows (various patch levels, 2k/XP/2003/Vista, Itanium/x86/x64) and thousands of apps on top of that in under a week is simply amazing.

Many in the community don't think such thorough testing is needed. However, there is a good chance that cost to those running RealTek audio because of this bug will be greater than the cost to those getting exploited. The reason others can create pseudo-patches for such bugs is the don't have to suffer the consequences when it causes more problems for a customer than it solves. Since this QA process is so long, Microsoft tries to schedule when it fixes bugs, so that they can test many of them all at once, rather than retesting every time.

On the other hand, I'm not sure if Microsoft's timeline is shrinking The time between when a developer checks in and the patch ships to customers should be a measured part of a "secure development lifecycle" - and it should be continuously shrinking. No matter how big the problem, engineers shouldn't be making excuses for why it takes so long. For example, instead of rebuilding the affected DLL, maybe Microsoft should instead "patch" it: overwrite a 'jmp' instruction in the affected area to some dead padding area in the DLL that contains the fix, then 'jmp' back. Or do something else: there is always a clever way to solve problems. I'm curious whether (a) Microsoft has been tracking this time-to-patch, and (b) whether it's been shrinking or growing, and (c) whether they are doing researching on fixing bugs other than rebuilding the affected files.

ANI 0day vs. intrusion detection providers

Most people do not know how intrusion-detection systems work. The recent Microsoft 0day animated-cursor/ANI vulnerability is a good way to learn what's really going on. Most intrusion-detections systems had 0day detection for this vulnerability, and were therefore detecting the 'unknown' attacks before everyone else knew about them.

The reason a product could detect this is because signatures are usually based on vulnerabilities rather than exploits. This new bug is essentially the same as an earlier bug in 2005, so the old sigs could detect the new variant of 2007.

Understanding vulnerability-based signatures starts with understanding the vulnerability itself. Animated-cursors are generic Microsoft multimedia files like .avi and .wav. The animation information is contained in a subsection starting with the string "anih". That string is followed by a structure
that looks like:

struct tagANIHeader {
DWORD cbSizeOf; // Num bytes in AniHeader (36 bytes)
DWORD cFrames; // Number of unique Icons in this cursor
DWORD cSteps; // Number of Blits before the animation cycles
DWORD cx, cy; // reserved, must be zero.
DWORD cBitCount, cPlanes; // reserved, must be zero.
DWORD JifRate; // Default Jiffies (1/60th of a second) if rate chunk not present.
DWORD flags; // Animation Flag (see AF_ constants)
} ANIHeader;

This structure contains nine 4-byte values, so the length field should always be exactly 36 bytes. The vulnerability is an unchecked stack overflow from code that looks like:
ANIHEADER anihdr;
memcpy(&anihdr, p+4, *(DWORD*)p);

Signatures for this vuln work by looking for the "anih" section then testing the length field to see it is longer than 36 bytes. The follow is an edited signature from the Snort intrusion-detection system that was written for the 2005 bug that also detects the 2007 variant:

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (\
msg:"WEB-CLIENT Microsoft ANI file parsing overflow";\
content:"RIFF"; nocase; \
content:"anih"; nocase; \
byte_test:4,>,36,0,relative,little;\
);

This signature first triggers on the pattern "RIFF" for the Microsoft generic multi-media file format. It then triggers on the pattern "anih" for the vulnerable subsection. It then extracts a 4-byte length field, relative 0 bytes from the end of the "anih" pattern, and triggers when that length is greater than 36.

This is how things are done in the intrusion-detection industry, yet when you take a class on intrusion-detection, they claim it ISN'T done this way. Instead of vuln-analysis and vuln-sigs, they teach you that intrusion-detection is done by analyzing the exploit, looking for patterns unique to that exploit.

Since most intrusion-detection products had 0day detection for this bug it stands to reason that intrusion-detection SERVICE PROVIDERS should also have had detection. YOU SHOULD ASK THEM. I'm sure if you read the marketing literature of product and service providers, everything is wonderful, but if you force them to prove to you that they were detecting this problem, things might not be so rosy. The service provider might have been using a poor intrusion-detection system. The signature might have had too many false-positives so was disabled. Or somebody was stupid and just didn't turn on the signature. I would love to see every managed intrusion-detection provider publish a graph of the detection of this bug over the last 6-months. (Indeed, I'm a bit annoyed right now since I no longer work for Internet Security Systems, and I can't just ask the service-provider folks to execute a database query for me).

The reason I suggest talking to service providers is that while most intrusion-detections systems based their signatures on vulnerabilities, there is still a big difference in the quality of the signatures. For example, the above Snort signature is prone to false positives. Any file containing both "RIFF" and "anih" will likely trigger the bug. While this is rare for any particular sensor, this is a high enough rate of false-positives that a large service-provider might turn off the signature.

The above signature only works on a small number of ports assigned to HTTP. In reality, hostile servers are delivering this attack on virtually any port. Another problem is that Snort is typically configured to only analyze the first few hundred bytes of an HTTP response, which means it will miss the attack unless it's the first filed deliver in a response.

The above signature example only covers HTTP, but it can come across other transports, such as instant messengers or e-mail. As far as I can tell, no Snort signatures have been written for these other transports. Indeed, it was announced that e-mail spam was a major vector for this attack.

I point these flaws out because people treat intrusion-detection like magic. They don't understand the signatures they download and put in their intrusion-detection systems, but instead treat them as magical incantations. After every major event, I see signatures posted to various websites, but they are usually incomplete. That's why you pay more for commercial products: they invest more in detection. For example, Proventia (the product I worked on) solves the above problems because it has a full protocol-stack; indeed, many customers are using it right now to block high rates of ANI exploit spam. However, since most people treat signatures as magic, there is little discussion about what's really going on with the signature. It's not hard creating better signatures, it's just that since so few classes teach how signatures are actually developed, and so few users actually read the signatures, that there is no pressure to create better ones.

More on Apple security Vs. Microsoft Security

Some people feel that my last post means that that Vista is perfect from a security standpoint and will not have any hacker problems. Please re-read the post. I said is that Microsoft has worked hard to eradicate most of the current, popular exploitation methods. This doesn’t mean its hacker proof. Why? Because people will develop new methods. That what security researchers will do. Unfortunately for researchers Microsoft has hired a ton of talented security people that are also trying to come up with new methods so they can plug them before anyone knows about them. To my knowledge not many other vendors, including Apple, are doing anything like this.

What does this mean? In the end not much, every vendor is still locked in the same arms race with hackers they always were.

Bill Gates fights back against an evil corp?!?!

UPDATE: For a response to John Gruber check here. For more discussion on the lack of security features in OSX, check here.

http://apple.slashdot.org/apple/07/02/02/1940232.shtml

The Mac community is up in arms. Bill Gates gave an interview where his fights back against some Apple’s misleading and deceptive marketing.

As a side note those commercials are what lead me to do security research in Apple. Also the quote that is quite often attributed to me about “cigarettes in mac users eyes” is a misquote as I actually said “cigarettes in the eyes of the actors in the commercials”. But I digress.

"Nowadays, security guys break the Mac every single day. Every single day, they come out with a total exploit, your machine can be taken over totally. I dare anybody to do that once a month on the Windows machine."

Oh the Mac fans are upset. *rabble*rabble*.

http://www.limited-exposure.org/2007/02/02/hey-bill-keep-up-will-ya/

http://www.securityfocus.com/archive/142/458920/30/0/threaded

http://daringfireball.net/2007/02/lies_damned_lies_and_bill_gates

The limited exposure guy even went as far as to count the MoBB bugs to prove how insecure Windows is. He forgot to mention how many of the affect Windows Vista and IE7 (HINT: not 25, that’s for sure).

Take a seat, hold your hats because I am about to make a declaration: Windows Vista is more secure than OSX 10.4.8. Anybody that tells you anything different should immediately be treated with the same disdain as finding a parking ticket on your car. This hasn’t been a popular thing to say and it’s not often said, but I am here to stand my ground on this. It sure won’t win me any karma on Slashdot.

Why do I think this? One new exploitation methods have to be developed to take advantage of a Vista vulnerability. Let’s look at why:

Stack overflows are gone. Don’t think this is just because of NX, or Non-eXecutable stacks. NX just means I can’t execute code on the stack but return-to-libc attacks still work. With things like ASLR (which is implemented on Vista and not OSX) breaks return-to-libc attacks because the system libraries are loaded at different, random addresses every time. Count how many of the Month of Apple Bug exploits were stack overflows. The most dangerous one, MoAB #1, was.

Heap Overflows are pretty broken is not eradicated. With heap randomization, metadata elements and function pointers being XORed with random numbers it would be next to impossible to exploit a heap overflow on Vista in the traditional way. OSX doesn’t have any similar protection.

Tom Ptacek even comments on the lack of advanced security features in OSX here.

What does this mean? In order for attacks to continue in the same way there will have to be some MAJOR evolutions in vulnerability and exploit technology as almost all of the widespread flaws you have heard of take advantage of these methods. Blaster, Sasser, Slammer, Zotob, all those big worms have relied on either a stack or heap based overflow.

Don’t believe me? Prove me wrong. Now don’t get me wrong, you can still email executables to people and then trick them into running it…you can do that on OSX as well.

Of course this won’t do anything to calm the swell of zealots or people stuck in the belief that Microsoft hasn’t changed since 1998. Its kinda like when explaining, in-depth, a black Ferrari is a better car than a red Honda civic to a teenage girl. The same logic that would lead the teenage girl to say “but I like this one better because its red and goes with my lipstick” is the same logic a Mac zealot will use when they say “I don’t care about the facts, I KNOW OSX is more secure”. Know I can’t comment on usability or any of that jazz, that’s not my area of expertise. I’ve never had a problem setting up and running either.

The thing that really upsets me about the Mac community going off on Bill Gates is that Apple does the same exact thing. Their "we don't have security problems" commericals are the same thing as what Bill Gates said. If you want to be mad at Bill then hold Steve accountable for the same actions as well. The arrogant commericals Apple runs has done nothing but win them alot of researchers who are breaking their systems that would not have otherwise given them a second look.

I’ll leave you with my favorite Mark Twain quote:

“It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so.”

UPDATE: Please understand that I'm not referring to the average Mac user that just wants a safe, reliable computing experience. I'm taking exception with zealots who place those users at risk by giving them a false sense of security. OS X is pretty safe today for the average user, but the platform is definitely NOT as fundamentally secure as Vista. Microsoft only changed when users demanded better security, and it's only when the Mac community calls for similar protections that Apple will include them in products. I use my macbook on a daily basis. I write code on it, I watch movies on it, I chat with people on it. Just becasue I don't think highly of the security in OSX doesn't mean I am not a Mac user.

2007: the year someone will mention 0day to you in a club

Do you remember where you were the first time a layman said something to you about a “virus” or a “worm” and how those “hackers” can take over your “computer”. I do. I was in club; it was 2000 so I was being assaulted by the sounds of N’sync, Pink, Creed, and Macy Gray. Being that I was 22 or so it’s a safe bet that I was wearing a shiny shirt to impress women, it was a very scary time. I was talking to a cute girl in a short skirt (ah the things you remember) who asked me what I did for a living. After telling her I worked with computers she started in on a long story about how those “hackers” tricked her because she got an email with the subject line “I Love you” and she totally fell for it and got a “virus” then her computer crashed. I suddenly felt like my super secret club just became a subject of mainstream discussion.

With Word flaws, and Apple flaws, and a host of other problems affecting people in ways previously unseen, like Myspace, I predict someone will have a similar experience: “Like, I was totally surfing Myspace and some hackers like used one of those 0days on me and now my credit card information is in like Prague or something”.

I remember when it was a hard thing to find 0day and there were so called 0day brokers who were often regarded like underground cyber arms dealers. Not anymore it seems. This morning I awake to a story about Oracle rootkits and 0day. The story revolves around a company in Argentina, Argeniss, which sells a 0day pack for Canvas. Immunity, the makers of Canvas also have their own vulnerability sharing club. Argeniss isn’t the first service of its kind to build an ecosystem around exploit frameworks. Gleg offers up the vulndisco pack which also works on top of Canvas. Not to be confined to exploit framework ecosystmes some vendors like Digital Armaments also sales 0day information. Yours truly, Errata Security, even includes original 0day information in our Hacker Eye View Service. It won’t be long till Gartner has a magic quadrant for 0day services. It’s hardly a secret anymore.

Back to Oracle rootkits. This is not a new problem. Since vendors are hardening their OSes attackers have two options: go up to the application layer or go deep into the device drive layer. We have seen plenty of device driver problems so to make sure the app layer doesn’t feel lonely, we have database rootkits. The first person I saw talk about this was Alexander Kornbrust, A great presentation on this can be found here. Since security is actually all about diligence you now need to add checking databases for rootkits to the list as there is weaponized code available. I doubt it will be long till we see similar rootkits for DB2 or Microsoft’s SQLServer. Anybody have good suggestions for verifying database integrity?

Words can be dangerous...

http://blogs.zdnet.com/Ou/wp-trackback.php?p=416

I saw this post on dailydave today and laughed to myself. I thought with all the effort MS had put into the security of Vista something this obvious would not work. George Ou actually tried it and surprise, surprise it works. Sometimes you can’t see the trees for the forest (I did change this saying to fit this situation).

The amount of damage that can be done with this is uncertain, but I would wager its not high. It’s a pretty nifty hack though.

UPDATE: I am getting reports from more 3rd parties that this works. There are some things to keep in mind. The speech rec can be disabled and right now the worst affect of this can be pretty much the same effect of malicious javascript: sending web browsers to random pages. There is testing underway to see what other bay things can be done.

UPDATE 2:http://blogs.technet.com/msrc/archive/2007/01/31/issue-regarding-windows-vista-speech-recognition.aspx

You can tell its Vista launch day....

Bill Gates is on the Daily Show and and Slashdot is alive (buzzing?) with Microsoft stories. Two stories are about MS: one about MS retracting a patent, one about how broken Vista is. A researcher *gasp* found a way to circumvent Vista DRM via patchguard (for more information on subverting patchguard see Skywings excellent paper from uninformed). Now please don't get me wrong I am not knocking the researcher. Alex did good work with an interesting result but as someone who knows a thing or two about the media (I begrudgingly extend that designation to blogs) I can't help but notice the difference between what he stated on his blog and what the anonymous reader submitted to slashdot:

"Alex is now quite nervous about what an army of lawyers backed by draconian copyright laws could do to him if he released the details, but he claims to be currently looking into the details of safely releasing his details about this at the moment though."

This is completely different than what I know to be true. I have attended/spoken at several of Microsoft's internal security conferences and want to dispel the myth that MS is sue happy, unlike other companies. Researchers and developers at Microsoft are actually more interested in solving problems than suing people which seems more productive as we all know suing doesn't work. I know for a fact Alex is in contact with Microsoft and has been for a while but little things like facts never seem to stop people from spinning stories to create sensationalism. Alex details how MS can break his method of bypassing the DRM, and how he can get around that, and helpfully details how MS can fix his evasion....

He confirms what we all know: that security is an arms race, which was also left out of slashdot. In the long run the winner of the DRM conflict will be the person who gets tired first.

UPDATE: While writing this another story popped up on slashdot about
MS getting tough on license dodgers. *GASP* the horror of a company
actually wanting people to PAY for their product. The nerve of them,
lets get the pitch forks and torches together and running them out of
cyberspace! Gotta love launch day!

Myspace Hacking and browser technologies

http://seclists.org/fulldisclosure/2007/Jan/0270.html

This is not good. If you have a Myspace account you may wish to start changing passwords.

Update:
This appears to be from some sort of phising scam. Some of the entries are pretty funny:

youmustbecompleteretards@idiot.com:doyouhonestlythinkiwillputmyrealpasswordhere

Update 2:
This is something I have wanted to look at for a long time but have never gotten around to it. I have been curious about the anti-phishing technology in both IE7 and Firefox 2.0. They both work but I have to say it did take Firefox a few moments before popping up the warning so if I was not paying attention and quick I could have attempted to login. The pictures above are a side-by-side comparison of the anti-phishing technology in both browsers (IE7 on the top, Firefox 2.0 on the bottom). Which is better? I would say IE because it wouldn't even display the page if it’s a phishing site but in the end it really is up to the user.

Microsoft Patch Release initial analysis

Microsoft just released their patches; I have to say it’s a pretty lackluster offering. 3 Office bugs and one VML bug.

The break down for critical vulnerabilities is pretty easy: one in excel, one in outlook and one in VML (aka. Internet Explorer).

Excel is not a surprise as the summer and fall saw active targeted 0day exploitation against certain targets. Being that this is a client side vulnerability and malicious attacker wouldn’t have to many opportunities for a retry as unsuccessful exploitation will crash the application. This is important to patch as it will be hard for IPS vendors to guard against this. The Excel file format is so complex the best most vendors can do is add signatures for any proof of concept that arises or their customers will be swimming in false positives. This means all an attacker needs to do is write a new and slightly differing version of the exploit and it should bypass most inline protection tools.

The Outlook bug is exceptionally bad. If you just receive the e-mail, you are owned (even before you open the e-mail or see it in the preview pane). No user interaction is required; this one is also in the category of “patch as soon as possible”. A worm could use this propagate and could result in clogging corporate email servers. Servers who succumb to a spike in email delivery could cause more or a problem than successful exploitation of the end user.

Windows did not escape this month without a fix. This one is in the well worn VML library. This vector is exploitable via a webpage and email. Standard obfuscation methods for web based attacks like a variety of different encoding methods apply. Inline security tools would be hard pressed to detect 100% of VML exploit variants. A similar vulnerability was discovered last year being exploited in the wild.

Active exploitation of all these vulnerabilities will likely include botnet/rootkit malware.

MSRC Advanced Notification & Sales Pitch

http://blogs.technet.com/msrc/archive/2007/01/04/january-2007-advance-notification.aspx

Next week is Microsoft Patch Tuesday and the MSRC released their “Advanced notification” summary. It looks like a total of 8 bugs will be released with some critical issues in the bunch. The patches and advisories are released around 1pm EST.

If you are an Errata Security customer you can expect you initial analysis by 2:30 with full analysis of critical functions following shortly after that. If you don’t know about our service: we tell our customers, and for tier 2 customers provide working exploit code, for what Microsoft told you they patched and even what they didn’t tell you they patched. We also provide expert analysis on the patches: what’s important, what’s not, and what you should drop everything to fix. We do this for almost all major vendor patches and security happenings. Customers also get access to the Errata Security research pipeline, or vulnerabilities we have found in house. Customers are notified at the same time the vendors are.

That’s enough of a sales pitch for now.

Blah Blah Blah

I love having a blog, it means I can rant, and I sure do like ranting. Like earlier in the week I was upset that the media made a huge deal out of a Russian site selling a Vista exploit. These reports made it seem like a much worse problem that it was and few reporters actually mentioned that is was a LOCAL bug and an attacker needs valid credentials to login to the machine to carry out the attack. I suppose headlines like “Russian site selling lame bug that affects almost nobody” would not have been as eye grabbing.

This trend of dumping on Vista has continued but this time its cracks. If you are not familiar with the term there are ways to circumvent legitimate licensing and copyright protection schemes and download and run copies of Microsoft’s latest shiny toy with out *GASP* paying for it. Maybe this story is getting play because outside of the hacker community not many people have heard of “warez” and it’s finally going mainstream, maybe its getting play because it’s a slow news week; I can’t decide which.

Let me disclose something: all the cracks that have been discussed in the media recently I made efforts to go and find. I now have a very extensive collection of Windows Vista cracks. You might be asking yourself why I would do that, why not just buy a copy of ask MS to give me one. Its simple, I am waiting for the first cracks to appear that are massively infected with virii or spyware. I have seen some, but I am more waiting for something that is massively blatant like after 90 days of operation you are prompted for a credit card number or the OS will delete itself and take all of your work/photos/music with it. Surely these free spirited pirates wouldn’t do such a thing you might say…honor among thieves and stuff like that.

I ask you, what’s the best way to build a botnet now that a botnet master can’t count on massive windows remote 0day every three months that can be used in a recruitment drive. Its simple you build yourself a good reliable network of people who can’t patch (security patches require a legit copy of Windows) and you know will take your bait (free copies of Vista!!). It makes for a great plan; you can even add new functionality to your trojaned OS by releasing “cracked” patches. I am going to call this the “addict pirate” because once you get a sap hooked on this he or she has to keep coming to you for his fix or *GASP AGAIN* pony up for a legit copy.

Enough ranting about “addict pirates” and back to the poor reporting and business aspects of these “cracks”. These types of cracks have been around for years and no matter what people say this will not affect the sale of the OS. What makes me the most irate is how the reporting on the Vista cracks make it seem like this is the first time an OS has been pirated. Right now on file sharing networks you can find copies of Windows XP, 2000, ME, 98, and 95. There are even copies of Windows 3.1 floating around! And I don’t mean 3.11 for Workgroups, I am talking about the OLD SCHOOL stuff.

If you take one thing away from this blog post make sure it’s this thought: this is not a new or shiny problem, as long as there has been software there have been people stealing it. Nothing to see here, move along.