Lucene search

K
securityvulnsSecurityvulnsSECURITYVULNS:DOC:22998
HistoryDec 29, 2009 - 12:00 a.m.

Code to mitigate IIS semicolon zero-day

2009-12-2900:00:00
vulners.com
20

This mitigation should help block attempts to exploit the IIS
semicolon zero-day (BID 37460), but no warranties and no
guarantees.
It didn't crash my web servers during testing, but I make no
representations as to how it will or won't perform on anyone else's
web servers. This mitigation is only intended for IIS 4.0, 5.x,
and
6.0; IIS 7.0 does not appear to be vulnerable (although in my
testing,
IIS 4.0, 5.0, and 5.1 didn't appear to be vulnerable, either), and
7.5
is also reportedly not vulnerable.

If an attack is blocked, it should show up in the IIS logs with
HTTP
status 403 and the made-up substatus 59; for example, on IIS 6.0:

2009-12-27 12:34:56 W3SVC1 169.254.123.200 GET /evil.asp;x.jpg -
80

  • 169.254.123.100 Mozilla/4.0+(compatible;+MSIE+…) 403 59 0

When passed a malformed file name by IIS due to the vulnerability,
most (non-.NET) ISAPI extensions will process the file, including:

asp.dll / asp51.dll: .asa, .asp, .cdx, .cer, .htr
httpodbc.dll: .idc
ssinc.dll: .shtm, .shtml, .stm

So to get the most protection, you'll need to remap the file
extensions for each different ISAPI extension to a different copy
of
the mitigation DLL – it uses the file name with which it loads to
figure out which ISAPI extension it's wrapping. You'll also need
to
set up the registry to tell it where to find the ISAPI extension
it's
replacing. For example:

[HKEY_LOCAL_MACHINE\SOFTWARE\iissemi1]
"iissemi1_asp.dll" = "C:\WINDOWS\system32\inetsrv\asp.dll"
"iissemi1_ssinc.dll" = "C:\WINDOWS\system32\inetsrv\ssinc.dll"

Try out a malformed file name after deploying to make sure you have
everything set up properly.

Sorry I can't host an installer right now to automate all of this.
Hopefully most people won't need to use this mitigation, but if the
other options for reducing exposure aren't viable in your
situation, I
hope this one will be.

– Derek

P.S. The vulnerability can also be exploited if a subdirectory
containing ".xxx;" can be created; for instance, accessing
"/~y.asp;y/z.jpg" would cause "z.jpg" to be executed by the ASP
ISAPI
extension as though it were an ASP script.