On Sat, 3 Mar 2001 20:41:29 +0000, Gossi The Dog <gossiOWNED.LAB6.COM>
wrote:
[Originally in INCIDENTS but continued here in FOCUS-MS]

>Yeah, I think it might be worth making it known that the IIS Unicode bug
>allows priviledge escalution to SYSTEM without much effort (as demostrated
>by BackGate) - as far as I know, not many admins realise this (certainly
>in RFP's original bugtraq post he said it wasn't possible).

Shame on him! Actually RFP wrote, "program execution happens under
IUSR_machine context."
http://www.wiretrip.net/rfp/p/doc.asp?id=57

I agree that this issue could be more widely understood. That's why I chose to
continue in FOCUS-MS. I hope you don't mind. We're dealing with what's become
a convenient wrap-up phrase for these incidents: "the IIS Unicode bug."

Events have transpired over time. Fresh vulnerabilities leveraged against weak
administration and design vagaries produce unexpected and unwanted behavior.
If you were to make IUSR_Computername a member of the Administrators
Group...well the Unicode Bug would execute with Administrator Group rights and
permissions.

The crux of the issue, the first obstacle if you will, is finding a way to pop
out of the (virtual) web directory constraints in the context of IUSR. That
vulnerability was patched on IIS4, according to what will forever remain
unconfirmed rumor amidst the swirling, muddled pool of advisories each
pointing to the other, by Microsoft's MS00-057, April 2000, and later
officially referenced and patched by MS00-078 in October 2000, as the Web
Server Folder Traversal vulnerability.

"The Unicode Bug" allowed viewing files remotely (read access) that the web
site builder or server admin did not intend.

GET
/scripts/..%c1%pc../winnt/system32/cmd.exe?/c+dir+c:\

Then along comes Web Server File Request Parsing as MS00-086 in November,
2000. This looks like "the Unicode bug" since it involves /../ but allows
running "code" (execute permissions) and other interesting things.

Once an attacker has read and execute permissions remotely on the web server,
still in the context of IIS4's IUSR, what she needs next, if only for
defacement, is write access

GET
/scripts/..%c1%pc../winnt/system32/cmd.exe?/c+copy+c:\winnt\system32\cmd.exe+cmd1.exe

Ultimately the attacker wants write access to an executable directory

GET
/msadc/..%c0%af../..%c0%af../..%c0%af../..%c0%af../winnt/system32/cmd.exe?/c+copy+c:\winnt\system32\cmd.exe+cmd1.exe

Then the attacker wants to write Very Bad Things™ to that directory
GET
/msadc/cmd1.exe?/c+echo+"<%"+>Evil.CMD

GET
/msadc/cmd1.exe?/c+echo+"Evil_Hacker_Script"+>>Evil.CMD

Proper assignment of rights and permissions especially to IUSR, applying
patches, and cleaning up after non-secure default installation routines would
have prevented the BackGate Kit from installing. A light attempt at some
combination of those three would have prevented the attack. The Wingate
executable is identified by McAfee as "BackGate."
http://vil.nai.com/vil/virusSummary.asp?virus_k=98693
Anti-virus should have prevented the attack.

But barring the above, the attacker has exploited the friendly sounding and
all encompassing "Unicode Bug" to remotely write or bring down an Active
Server Page containing Evil_Hacker_Script to an executable directory on an
administratively challenged default install of IIS4 web server on NT4 SP6a.

E.ASP was a WSH file within the BackGate Kit that installed FTP, Telnet, and
HTTP Proxies, and an FTP Daemon.

By default IIS4 gives ASPs to Local System for execution.

When retrieved remotely by a web browser, E.ASP complete with
Evil_Hacker_Script ran in the context of Local System.

On IIS4, this is by design.

Matt 2001-02-28

-- 
Instead of developing fault-tolerant software, we've cultivated a generation
of fault-tolerant users.
____________________________________________________________________
Get free email and a permanent address at http://www.amexmail.com/?A=1

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]