| From: [EMAIL PROTECTED] | Sent: Wednesday, November 12, 2003 10:47 AM | To: [EMAIL PROTECTED] <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
