StrikePack 12200 Released

StrikePack 12200 is now available to BreakingPoint customers. This release contains 9 new strikes covering 7 different vulnerabilities.

MS07-035: Win32 API Code Execution Vulnerability

One of the strangest bugs patched by Microsoft on June 12th was the "Vulnerability in Win 32 API Could Allow Remote Code Execution" issue addressed in MS07-035 (CVE-2007-2219). The description provided by Microsoft is somewhat vague:

"This critical security update resolves a privately reported vulnerability in a Win32 API. This vulnerability could allow remote code execution or elevation of privilege if the affected API is used locally by a specially crafted application. Therefore applications that use this component of the Win32 API could be used as a vector for this vulnerability. For example, Internet Explorer uses this Win32 API function when parsing specially crafted Web pages."

Fortunately, a friend of mine was working on the same issue, and after reviewing the differences between the patched and unpatched versions, discovered the trigger. The vulnerability occurs when an application tries to locate a resource within an EXE or DLL using a numerical ID. A logic error results in the resource ID being treated as a resource handle if the ID supplied is greater than 65535. An attacker can exploit this flaw through Internet Explorer by redirecting the victim to a res://existing.dll resource URL that contains a hash character (#) followed by a decimal integer value greater than 65535.

This logic error eventually leads to an attempt to free the resource handle. Since the attacker controls the pointer value of the handle, the end result is a call to RtlFreeHeap() with an attacker-supplied parameter. Exploiting this to execute arbitrary code is tricky, since the attacker would need to create a fake heap structure in memory and then pass the decimal value of a pointer to this structure in the URL. In the following stack trace, the value 65536 (0x10000) was supplied as the resource ID to Internet Explorer 7.

eax=0173b8a8 ebx=00000000 ecx=0019f1e8
edx=7cbf4418 esi=00010000 edi=00140000
eip=7c931c6b esp=0173b7fc ebp=0173b8b8 iopl=0 cs=001b
ss=0023  ds=0023  es=0023  fs=003b  gs=0000 efl=00000206

ntdll!RtlFreeHeap+0x44:
cmp     byte ptr [esi-0x1],0xff ds:0023:0000ffff=??

ChildEBP RetAddr 
0173b8b8 7c9109bc ntdll!RtlFreeHeap+0x44
0173b8cc 7c910992 ntdll!RtlpFreeAtom+0x1b
0173b8dc 7c832545 ntdll!RtlFreeUnicodeString+0x17
0173b8f0 7c80bc44 kernel32!BaseDllFreeResourceId+0x2d
0173b938 7e86e4d9 kernel32!FindResourceW+0x96
0173b970 7e942228 mshtml!GetResource+0x1c
0173bc14 7e94209d mshtml!CResProtocol::DoParseAndBind+0x2fc
0173bc30 7e941f71 mshtml!CResProtocol::ParseAndBind+0x26
0173bc54 6142d78a mshtml!CResProtocol::Start+0xa4
0173bc88 61421eab urlmon!COInetProt::StartEx+0xf1

In the crash above, an exception was thrown because the address 0x10000-1 (0xffff) does not map to a valid address. If we pass an argument that contains a valid address, then we reach the following block of code:

ntdll!RtlFreeHeap+0x44
cmp     byte ptr [esi-0x1],0xff ds:0023:0000ffff=??
jb      ntdll!RtlFreeHeap+0xe1 (7c91047d)
mov     edx,esi
call    ntdll!RtlpLowFragHeapFree (7c93212e)

The first thing we notice is that the byte before the address we pass is used to determine what type of free operation to perform. If this byte is not 0xff, then the normal free routines are used. If this byte is 0xff, then the low fragmentation heap code is called instead. This is good news for us, since it lets us hit two different code paths in search of a way to control execution. If we take the first path and point the resource ID at a block of NULL bytes, the free operation completes without an exception being raised. If we point it immediately before a byte set to 0xff, a new exception is raised from inside the low fragmentation heap code. Playing with these values should eventually lead to an exploitable condition, but so far have we not found a clean way to trigger code execution.

StrikePack 11995 included coverage for this vulnerability (ms07_035_windows_api.xml), which can be found in the /strikes/exploits/browser/ directory of the strike tree.

StrikePack 12128 Released

StrikePack 12128 is now available to BreakingPoint customers. This release contains 8 new strikes covering 6 different vulnerabilities.

MS07-033: Navigation Cancel Page Vulnerability

On June 12th, Microsoft released an update to cover the five vulnerabilities addressed in MS07-033. One of the flaws, titled "Navigation Cancel Page Spoofing Vulnerability" (CVE-2007-1499), demonstrated a common problem in how resource URLs are used in Internet Explorer. This vulnerability allowed an attacker to modify the URL used in the Refresh link of the Navigation Cancelled screen of Internet Explorer 7. To exploit this flaw, an attacker would redirect the victim to a res://ieframe.dll/navcancl.htm resource URL that contains a hash character (#) and a crafted XSS string.

The vulnerability occurs in one of the included javascript functions of the navcancel.htm page. You can view the source yourself by entering that res:// URL into the location bar of Internet Explorer 7, right-clicking the page, and selecting the View Source menu item. At the top of the HTML source, we see two script tags that load in external javascript files. These files are errorPageStrings.js and httpErrorPagesScripts.js. If we enter the URL for the httpErrorPagesScripts.js into the location bar, we see a function named navCancelInit() in the javascript source. This function looks at the parameter in the URL and then rewrites the Refresh link to point to this location. The only restriction is that the value after the hash mark must begin with http(s)://, ftp://, or file://. The problem with this code is that an attacker can insert a double-quote and close-parenthesis into the URL and then append arbitrary javascript, which will be executed within the context of the resource domain. For example, the following URL will cause an alert box to pop up when the Refresh link is clicked: res://ieframe.dll/navcancl.htm#http://BOGUS/");alert("Hello");//

After a quick review, it appears that most IPS vendors detect this attack by looking for a link to res://ieframe.dll/navcancl.htm that contains a double-quote in the parameter. What they missed is that this location can also be accessed using a link to about:cancel. For example, the following URL will exploit this vulnerability the exact same way: about:cancel#http://BOGUS/");alert("Hello");//

The list of mappings between about URLs and resource links can be found in the HKLM\SOFTWARE\Microsoft\Internet Explorer\AboutURLs registry key.StrikePack 11995 included two strikes for this vulnerability, ms07_033_navcancel_xss_about.xml and ms07_033_navcancel_xss_res.xml, which can be found in the /strikes/exploits/browser/ directory of the strike tree.

RFC3514: Setting the Evil Bit

Every once in a while, a good joke can turn into a useful feature. On April 1st, 2003, Steven Bellovin published RFC 3514, entitled "The Security Flag in the IPv4 Header". This document suggested that the "unused bit" in the IP Flags field of the IPv4 packet header should be used to convey security information. Specifically, the document stated that the "evil bit" should be set to one for all attack traffic, while benign traffic should leave it set to zero. Network devices, such as firewalls, should drop all traffic with this bit set. The assumption, of course, is that malicious users would always follow the RFC and set the evil bit for any packets used in an attack. While most folks who saw this RFC realized it was a joke, quite a few people contacted Bellovin asking for clarification. You can see an archive of the responses on Mr. Bellovin's web site.

So, how is this useful? The BreakingPoint BPS-1000 product supports multiple concurrent tests. The traffic leaving the four test ports can be a combination of re-created traffic streams, generated application traffic, high-speed TCP sessions, and exploits. If you are developing a security product, such an IPS or IDS, trying to debug attack detection under a heavy traffic load can be problematic. If only there was an easy way to identify the "evil" traffic in the stream...

The evil bit to the rescue! The BreakingPoint BPS-1000 supports setting the evil bit for all attack traffic sent by the Security component. To enable RFC 3514 support:

1. Login to the BPS-1000 interface.
2. Access the Attack Manager and create a new Attack Series.
3. Add the desired exploits to the Strikes group.
4. Click the Parameters button. The system will examine the selected strikes and present you with a list of all available parameters.
5. Select the IP option group from the Parameters Filter drop-down box. The option list will now show IP related parameters.
6. Select the RFC3514 option and change the value to true.
7. Close the Parameters dialog.
8. Select New Test from the Test menu.
9. Add a Security component.
10. Select the Targeted Attack screen.
11. Choose the Attack Series you just created from the list.

At this point, you can add other components, such as the Bit Blaster and Session Sender, or just run the test as is. Once the test is running, you can use the following tcpdump BPS filter to match the evil traffic:

#  tcpdump -vn 'ip[6] & 128 != 0'

StrikePack 12078 Released

StrikePack 12078 is now available to BreakingPoint customers. This release contains 3 new strikes and a significant bug fix for the IP fragmentation engine.

IPS Evasion with the Apache HTTP Server

This post is the first in a series on IPS evasion techniques. The intent is describe the strange behaviors of network applications and demonstrate the evasion capabilities of the BPS-1000 product.

Microsoft's IIS web server gets a bad rap by security vendors, due to the mind-boggling number of ways an attacker can encode a valid HTTP request. IIS's support for Unicode encoding, case-insensitive file names, and interchangeable path separators have created a series of annoying problems for IPS, IDS, and web application proxy developers. As of June 2007, nearly all vendors in this space have some solution for normalizing HTTP requests destined for IIS web servers.

The Apache Foundation's HTTP server, by contrast, is largely standards compliant and is quite picky about what types of requests it will accept. This has made life comparatively easy for developers trying to normalize HTTP requests destined for Apache web servers. Unfortunately, two quirks in the Apache request parsing code can be abused to evade many commercially-available IPS products.

The first issue relates to how Apache handles invalid request methods with CGI and PHP scripts. By default, Apache allows all methods, even invalid methods, to be used in requests to access dynamic content. For example, if we have an Apache web server with mod_php installed, and create a script called test.php in the web root, each of the following requests would be considered valid and result in test.php being accessed:

• GET /test.php HTTP/1.0
• POST /test.php HTTP/1.0
• HELLO /test.php HTTP/1.0
• GET%20/%20HTTP/1.0%0A%0D /test.php HTTP/1.0
• \r\n\r\n\r\n\r\n\r\n\r\n\r\n /test.php HTTP/1.0

As you can imagine, normalizing these requests can be difficult. The fourth example can trick an IPS into believing that the request is actually for the main page, while the web server will see the request for /test.php. The fifth request is particularly evil, since it requires the IPS to look beyond the first line of data in order to locate the URI. Very few (if any) vendors will properly decode this last case.

The second issue has been covered before, but still affects most commercial IPS products. In a normal HTTP request, the first line consists of the request method, followed by a space, followed by the URI, followed by a space, followed by the HTTP version. The HTTP RFC states that instead of an ASCII space character (0x20), the horizontal tab character (0x09) is also valid as a separator. The Apache web server, instead of just looking for either 0x20 or 0x09, will process 0x09, 0x0b, 0x0c, 0x0d, and 0x20 as valid separators. Since many IPS products only recognize 0x20 and 0x09, they are not able to decode HTTP requests containing these alternate whitespace characters.

I raised this issue just over one year ago on the Daily-Dave mailing list and described it again it during my Black Hat 2006 presentation with Brian Caswell. Since that time, the Snort HTTP preprocessor has been updated to properly decode these requests (look for the apache_whitespace and whitespace_chars options). Unfortunately, many commercial IPS vendors have not updated their products to detect this evasion technique. One vendor added support for 0x0d, but forgot to check for 0x0b or 0x0c. The end result is that the following requests may not be properly decoded by many vendors:

• GET\x0c/test.php HTTP/1.0
• GET\x0b/test.php HTTP/1.0
• GET\x0d/test.php HTTP/1.0

In the examples above, we used invalid HTTP methods and non-standard whitespace characters to prevent an IPS product from properly decoding a request for /test.php. In most cases, these techniques will work for real attacks, such as an attempt to exploit a buffer overflow in a CGI or trigger a remote file include vulnerability in a PHP script. The BreakingPoint BPS-1000 supports these evasion techniques through the following parameters in the HTTP option group, accessible from the Parameter view of the Attack Manager:

• MethodRandomInvalid: Use randomly-generated request methods
• URIPrependAltSpaces: Use alternate whitespace characters before the URI
• URIPrependAltSpacesSize: The number of alternate whitespace characters to prepend
• URIAppendAltSpaces: Use alternate whitespace characters after the URI
• URIAppendAltSpacesSize: The number of alternate whitespace characters to append

Alternatively, BPS-1000 users can create a new test, add a Security component, select Targeted Attack, and choose the HTTP: Apache High Evasion preset from the Attack Profile drop-down.

StrikePack 12038 Released

StrikePack 12038 is now available to BreakingPoint customers. This release contains 3 new strikes and a number of small bug fixes. The Advisories section is now sorted by BPS ID instead of name, with the newest entries listed first.

StrikePack 11995 Released

StrikePack 11995 is now available to BreakingPoint customers. This is our first StrikePack update since the 1.0 software update was issued. This release includes coverage for many of the flaws addressed by Microsoft on June 12th (patch Tuesday), as well as a few new unpublished vulnerabilities. It is now possible to obtain a list of all BreakingPoint proprietary strikes by searching for the "0day" keyword in the Attack Manager. Enjoy!

Welcome to the StrikeCenter!

Hello everyone and welcome to the BreakingPoint Systems StrikeCenter. This site will be used to discuss vulnerabilities, exploits, and recent updates to the BPS-1000 product. BreakingPoint customers can access product updates, documentation, and advisories by accessing the links to the right.