[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Full-Disclosure] Frontpage Extensions Remote Command Execution



| From: mattmurphy@kc.rr.com
| Sent: Wednesday, November 12, 2003 10:47 AM
| To: full-disclosure@lists.netsys.com
<snip>
| Well, for one, it's not root level.  It allows ANONYMOUS 
| (Guest) access to
| a site using FPSE for anyone who can POST to a vulnerable 
| ISAPI extension. 
| FPSE is not enabled by default on any OS other than Windows 
| 2000 Server
| series OSes (according to MS), and is usually a security risk anyway. 

Indeed this flaw does not directly result in "root", SYSTEM, or administrator 
level code execution. However, it does result in executing code in the context 
of a shared process/privilege (dllhost) that is used for other critical web 
components. Its always interesting to me when people down play the severity of 
a vulnerability by saying "Its only remote code execution as an unprivileged 
user." That stupid statement should leave any knowledgeable person laughing. 
But since some people seem confused about this type of flaws severity...

What is an unprivileged user? It seems to me that if your attacking a service, 
and can now execute code as you wish within that service, then you are actually 
VERY privileged. As in the case of CodeRed and the .ida overflow you could 
perform in-line API hooking within the affected application. For example since 
a lot of eCommerce related scripts and ISAPI's are running in dllhost (same 
privilege/execution as this FrontPage overflow) you can now, with this 
"unprivileged" attack, intercept critical data and launch further attacks. For 
example hooking the dllhost outbound data sends, in an effort to attack 
visitors to the now owned website. Maybe using something like the recent "zero 
day" (well not anymore) [1]IE Object Bug. Or steal form inputs, and god knows 
what else. In the end an attacker is still becoming "privileged" to do things 
that they should not be. While maybe they cant interact with other 
data/processes on the system, they still can do anything they want to the pr!
 ocess they are executing code within, and also any data that process has 
access to. 

Now you might not agree with the above statements and be ignorant to still 
think "its just 'unprivileged' code execution, who cares" So then lets move on 
to the real-world examples of where you combine two attacks. One attack being 
remote code execution as an "unprivileged" user and the second being a local 
privilege escalation vulnerability.

Take your pick there is a constant stream of local privilege escalation 
vulnerabilities. I'll actually use a really old example, just to illustrate 
this style of combined attack is not new.

Three years ago, almost to this date, eEye released an [2]advisory on how to 
gain remote SYSTEM on a Microsoft IIS web server. The vulnerability we 
discovered was not actually a remote SYSTEM level vulnerability. In fact it was 
a "local" vulnerability within .ASP file parsing, that would lead to a buffer 
overflow and code execution as SYSTEM. Combine this "local" SYSTEM privilege 
elevation with any unprivileged IIS attack (At the time we used Unicode), and 
b00m, now you have remote SYSTEM. So for example, if this local buffer overflow 
still existed, you could combine Brett Moores FrontPage attack with this local 
overflow and now you easily have remote SYSTEM, whereas if you didn't have 
Brett's flaw, you wouldn't have remote SYSTEM. Anyways again this is a 3 year 
old example illustrating why these "unprivileged" remote code execution bugs 
are in fact still VERY relevant and important. Hopefully no one responds saying 
"yah but that was 3 years ago"... go do some homework, ther!
 e are plenty of very recent privilege escalation flaws that have been 
released. In fact Brett Moore himself has released some recently. So I wouldn't 
put it past him to have an exploit that combines one of those priv flaws with 
his FrontPage flaw to allow remote SYSTEM shells on vulnerable systems. vegas 
again soon? :-)

As for your comment about Windows 2000... I am not sure what that was about 
other than to further illustrate how critical this flaw is since your basically 
saying this flaw affects default installations of the operating system most 
prevalent and depended on by the majority of the business world.

[1] eEye IE Object Bug Advisory - 
http://www.eeye.com/html/Research/Advisories/AD20030820.html
[2] eEye $19.95 "dual-bug" privilege hack 
http://www.eeye.com/html/Research/Advisories/AD20001003.html

<snip>
| You know, I can't believe that people criticize MS for sitting on the
| details of root-level holes when they don't even bother to read the
| bulletin.  A decent admin would configure FPSE such that this 
| flaw is a
| non-issue.  This is because no ordinary user has a reason to 
| be accessing
| FPSE's files.  If FPSE is secured, this means that an 
| attacker is getting
| their own privileges back.

Its not worth really discussing your comment about how this is a mute issue if 
administrators would configure their software correctly. Obviously we cannot 
depend on administrators to know, or have the time (that's more often the 
case), to correctly configure their systems. If that were true then we wouldn't 
have had CodeRed and and all the other worms, because proper security policy 
would have stopped them (Ala, hardening the .ida ISAPI, and hardening RPC 
etc..). In the end basing the criticality of a vulnerability on what 
administrators should or shouldn't have done, blame shifting away from vendors, 
is a rather wasted endeavor because the technical facts simply speak for 
themselves.

This flaw shouldn't have been left to be fixed for almost a year. Microsoft 
should not have knowingly left customers vulnerable for almost a year. 
Microsoft fucked up.

Signed,
Marc Maiffret
Chief Hacking Officer
eEye Digital Security
T.949.349.9062
F.949.349.9538
http://eEye.com/Retina - Network Security Scanner
http://eEye.com/Iris - Network Traffic Analyzer
http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities 
"You think they're selling you truth, but truth is they're selling you out, and 
if we keep buying in, the line between lies and truth, will wear paper thin."

Important Notice: This email is confidential, may be legally privileged, and is 
for the intended recipient only. Access, disclosure, copying, distribution, or 
reliance on any of it by anyone else is prohibited and may be a criminal 
offense.  Please delete if obtained in error and email confirmation to the 
sender.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html