Mis-understandings about Privilege escalation exploits

Here's a new thread to discuss Privilege escalation exploits. I feel there is a significant mis-understanding (or at least a contrast of "facts") on this issue.

To start off, here's an article from Wikipedia about what exactly Privilege escalation is:
http://en.wikipedia.org/wiki/Privilege_escalation
It's a rather heavy article, but I think all we need to know (for discussion's sake) is the first part of it:

Privilege escalation is the act of exploiting a bug or design flaw in a software application to gain access to resources which normally would have been protected from an application or user. The result is that the application performs actions with more privileges than intended by the application developer or system administrator.

From my further readings, here is what I've discovered:
1. Privilege escalation exploits are real.
2. Privilege escalation exploits are discovered fairly regularly.
3. Privilege escalation exploits occur on many computing platforms including Windows, Linux, and Mac.
4. Privilege escalation exploits aren't just discovered in primary Windows programs/services; they are also discovered in many third party applications including ZoneAlarm and Panda. Some of these exploits (but not all) relate directly to escalating privilege from a LUA thereby potentially allowing the user to take complete control of the system.

The exploits I'm interested in discussing (although feel free to discuss anything related really) are the ones which apply to Windows platforms and that directly relate to escalating privilege from a LUA thereby potentially allowing the user to take complete (or even some) control of the system. These are the exploits that can potentially bypass SRP/AppLocker (depending on your definition of "bypass").

My standpoint (from a layman's point of view) is that there exists very few (if any...I can't seem to find any real-world examples) privilege escalation exploits of this nature that can occur remotely or via anonymous users. Why is this important? Well, this is a security forum which mainly discusses home computer security solutions. Therefore, home users would not be affected by such exploits if none of them could occur remotely.

Now, where is this mis-understanding of Privilege escalation exploits? I've managed to find one example so far (seemingly on a professional/formal level too):

1. A privilege escalation exploit was discovered in late 2006/2007 and a POC was released. This web-site describes the exploit as follows:
http://itsvista.com/2007/01/windows-messagebox-is-first-vista-exploit/

The exploit, a vulnerability with the Client/Server Runtime Server Subsystem (CSRSS), allows a logged in user to have their privileges elevated to SYSTEM, and does not require user interaction (ie can be executed remotely).

2. However, this appears to be mis-information, which seems rather embarassing, given they reference a source which states:
http://www.eeye.com/Resources/Security-Center/Research/Zero-Day-Alerts/20061215

...this vulnerability requires an attacker to already be logged in or executing other code on a host...

3. Microsoft themselves later (indirectly) confirm this mis-information:
http://www.microsoft.com/technet/security/bulletin/ms07-021.mspx

An attacker must have valid logon credentials and be able to log on locally to exploit this vulnerability. The vulnerability could not be exploited remotely or by anonymous users.

I'll finish by giving a few more examples of privilege escalation exploits that were discovered in the past:
http://www.microsoft.com/technet/security/bulletin/MS07-017.mspx

GDI Local Elevation of Privilege Vulnerability:
An attacker must be able to log on locally to exploit this vulnerability. The vulnerability could not be exploited remotely or by anonymous users.

EMF Elevation of Privilege Vulnerability:
An attacker must be able to log on to the specific system that is targeted for attack. An attacker cannot load and run a program remotely by using this vulnerability.

GDI Invalid Window Size Elevation of Privilege Vulnerability:
An attacker must be able to log on locally to exploit this vulnerability. The vulnerability could not be exploited remotely or by anonymous users.

GDI Incorrect Parameter Local Elevation of Privilege Vulnerability:
An attacker must have valid logon credentials and be able to log on locally to exploit this vulnerability. The vulnerability could not be exploited remotely or by anonymous users.

Font Rasterizer Local Elevation of Privilege Vulnerability:
To try to exploit the vulnerability, an attacker must be able to log on locally to a system and run a program.

As you can see, none of them were able to be executed remotely. Therefore, LUA + SRP would hold strong in the home environment. Only paranoid freaks like me would add in Sandboxie to sandbox all malware threat-gates and to open all newly introduced files sandboxed haha.

Where you seem to be getting confused is that the following statement "this vulnerability requires an attacker to already be logged in or executing other code on a host" does not necessarily mean a person other than yourself needs to be sitting at your computer running code to take advantage of the exploit. As your own Microsoft link informs under MsgBox (CSRSS) Remote Code Execution Vulnerability - CVE-2006-6696 @ http://www.microsoft.com/technet/security/bulletin/ms07-021.mspx

A remote code execution vulnerability exists in the Windows Client/Server Run-time Subsystem (CSRSS) process because of the way that it handles error messages. An attacker could exploit the vulnerability by constructing a specially crafted application that could potentially allow remote code execution.

Additionally, if a user viewed a specially crafted Web site, an attacker who successfully exploited this vulnerability could take complete control of an affected system.

ItsVista was not mistaken at all.

More importantly, When you are sitting at your computer in a LUA running flash, macros, .net, java, silverlight, activex, etc you are logged in AND executing code on a host, code already allowed by SRP. You are the person "executing other code on a host." You are the person running the "specially crafted application that could potentially allow remote code execution." You are running the "specially crafted application" needed whenever you read it "can not be exploited remotely."

As you wrote:

1. Privilege escalation exploits are real.
2. Privilege escalation exploits are discovered fairly regularly.

When the right one is discovered by the right person, like in the case of the Blaster worm from years past, it not only runs rampant, it runs with impunity until the exploit is patched.

^ I guess the only way to mitigate this is to keep Windows and all softwares updated?

Tranquility wrote:Where you seem to be getting confused is that the following statement "this vulnerability requires an attacker to already be logged in or executing other code on a host" does not necessarily mean a person other than yourself needs to be sitting at your computer running code to take advantage of the exploit. As your own Microsoft link informs under MsgBox (CSRSS) Remote Code Execution Vulnerability - CVE-2006-6696 @ http://www.microsoft.com/technet/security/bulletin/ms07-021.mspx

A remote code execution vulnerability exists in the Windows Client/Server Run-time Subsystem (CSRSS) process because of the way that it handles error messages. An attacker could exploit the vulnerability by constructing a specially crafted application that could potentially allow remote code execution.

Additionally, if a user viewed a specially crafted Web site, an attacker who successfully exploited this vulnerability could take complete control of an affected system.

ItsVista was not mistaken at all.

More importantly, When you are sitting at your computer in a LUA running flash, macros, .net, java, silverlight, activex, etc you are logged in AND executing code on a host, code already allowed by SRP. You are the person "executing other code on a host." You are the person running the "specially crafted application that could potentially allow remote code execution." You are running the "specially crafted application" needed whenever you read it "can not be exploited remotely."

Yes, I did read about this one:

FAQ for MsgBox (CSRSS) Remote Code Execution Vulnerability:
This vulnerability requires that either a user either be logged on locally and run a specially crafted application or that a user is logged on and visits a Web site for malicious action to occur.

Therefore, any systems where Internet Explorer is used frequently or where multiple users have permissions to log on locally and run untrusted applications, such as workstations or terminal servers, are at the most risk from this vulnerability.

The reason I didn't mention this specific one was because I didn't think it was a privilege escalation exploit - it's a remote code execution vulnerability (in the bulletin, Microsoft doesn't mention anything about privilege escalation under this heading). It sounded like some sort of PE execution still needed to take place following this Remote Code Execution - that is, a further process was still required to cause privilege escalation (or whatever) in order to bypass SRP (or perform malicious actions). That's how I understood it anyway.

From what I understand, remote code execution vulnerabilities occur even more frequently than privilege escalation vulnerabilities. However, SRP will still block this type of execution as long as it calls a PE executable (apart from Didier Stevens' demonstrations which themselves required specific settings, I've not read or come across real-world malware or even a POC that doesn't). Or am I missing something here?

Tranquility wrote:When the right one is discovered by the right person, like in the case of the Blaster worm from years past, it not only runs rampant, it runs with impunity until the exploit is patched.

I don't quite understand why you're using the Blaster worm example again - wasn't that a buffer overflow exploit, and not a privilege escalation exploit?

Sadeghi85 wrote:^ I guess the only way to mitigate this is to keep Windows and all softwares updated?

Well, the only way to mitigate many/most exploits/vulnerabilities is to keep as many programs as possible up to date. Tranquility and I are having a rather interesting discussion on exploits that occur and are taken advantage of very rarely in the real world (particularly in the home environment). You just need to ask yourself how many people (or facilities) running LUA + SRP get infected, compared to the number of people (or facilities) who don't use LUA/SRP (and just use an Antivirus etc).

In the case of how important it is to keep all sofware up to date, take the example of a buffer overflow exploit. These exploits occur incredibly frequently. Why is this? Simply because there are so many programs out there that aren't coded "perfectly", and because there are professional (and/or very bored) malware writers out there. However, keep in mind that not only would you need to have the specific unpatched program on your system, you would also need to be unlucky enough to obtain code on your computer and run it. Like Tranquility implied, you need to be at the right place at the right time (or more aptly put, at the wrong place at the wrong time).

In the case of privilege escalation exploits and bypassing LUA + tightly configured SRP as described in my security setup/appoach post (not just LUA alone), you'd probably have a higher chance of getting struck by lightning (being at the wrong place at the wrong time haha) than this occurring. And in fact, as I described in my previous post, I'm still unclear/skeptical that this has ever been proven to be possible. From all my "googling", I'm still struggling to find an article about a POC/malware that can bypass LUA + tightly configured SRP (not just LUA alone). I hope Tranquility can give me some clear examples (not the Blaster worm), because I'm tired of googling for now haha. The closest I've come across is some vague description of bypasses that have been discovered in malware research - unfortunately no proof was provided. Keep in mind that many web sites will be trying to write fancy articles about the latest and greatest exploits/bypasses of Windows, but they never actually specify exactly what is bypassed or provide proof that their theories are possible. Didier Stevens is the only exception (that I'm aware of), and yet even his described bypasses required very specific settings (eg. having Macros enabled in Excel).

Also note the underlined text above. In my security setup/approach post, I emphasise the importance of sandboxing threat-gates as well as the intelligent handling of newly introduced files (especially those that you recover outside of these sandboxed threat-gates). Note that even if you were unlucky enough to get struck by lightning (get infected at the wrong time at the wrong place via a buffer overflow exploit/privilege escalation etc), you would still be protected by your lightning-proof suit (the sandbox). Of course, as tzuk mentioned/implied, a targeted attack at kernel level that bypasses even this sandbox (or any other kernel level protective mechanism like a Classical HIPS) can still get through your defenses. But then you're more likely to get a Royal Flush in Poker than this occurring haha.

The Blaster worm was an overflow exploit to a system service - hence the privilege escalation. Once you have DCOM, RPC, or any other service with system privileges, doing your bidding SRP isn't going to interfere with anything they do, like download and run an exe.

There are many means of acheiving privilege escalation. There was a time that you could gain system privileges from the command prompt just by calling cmd.exe one minute ahead using the at command (task scheduler), even from the least privileged guest account. You can still do it today from an admin account. The recent DOS virtual machine vulnerability is another example.

While not privilege escalation, the runas trustlevel function is another means of bypassing SRP, available from even the guest account and built right into Windows. It can be crafted into a shortcut, a program call, or typed into a command prompt to run any program, anywhere that SRP would otherwise prevent.

ssj100 wrote:You just need to ask yourself how many people (or facilities) running LUA + SRP get infected, compared to the number of people (or facilities) who don't use LUA/SRP (and just use an Antivirus etc).

A take on this is why the Blaster example is so important. It nailed millions of computers and by nature of the exploit took every user of LUA and SRP it touched right along with everyone else. LUA and SPR were of no consequence.

Tranquility wrote:The Blaster worm was an overflow exploit to a system service - hence the privilege escalation. Once you have DCOM, RPC, or any other service with system privileges, doing your bidding SRP isn't going to interfere with anything they do, like download and run an exe.

I see, that does make good sense. The Wiki article does mention the following:

The worm also creates the following registry entry so that it is launched every time Windows starts:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\windows auto update = msblast.exe

So I suppose in theory, any executable could be written anywhere?

Tranquility wrote:There are many means of acheiving privilege escalation. There was a time that you could gain system privileges from the command prompt just by calling cmd.exe one minute ahead using the at command (task scheduler), even from the least privileged guest account. You can still do it today from an admin account. The recent DOS virtual machine vulnerability is another example.

Hence the reason why to block "cmd.exe" from being run in a LUA. The majority of people out there should have no use of this anyway. And those that do can simply rename "cmd.exe" to something else (I had to do that to allow Sandboxie's delete function to work).

Tranquility wrote:While not privilege escalation, the runas trustlevel function is another means of bypassing SRP, available from even the guest account and built right into Windows. It can be crafted into a shortcut, a program call, or typed into a command prompt to run any program, anywhere that SRP would otherwise prevent.

Yes, I wasn't aware of that until you mentioned it in the other thread. Presumably most corporate facilities have the runas function disabled/blocked though?

Tranquility wrote:

ssj100 wrote:You just need to ask yourself how many people (or facilities) running LUA + SRP get infected, compared to the number of people (or facilities) who don't use LUA/SRP (and just use an Antivirus etc).

A take on this is why the Blaster example is so important. It nailed millions of computers and by nature of the exploit took every user of LUA and SRP it touched right along with everyone else. LUA and SPR were of no consequence.

I don't quite understand the point you're trying to make here. Surely a home user who is running LUA + SRP is more secure than one who isn't?

Keep in mind that running LUA + SRP is like changing your desktop wallpaper - it's not going to cause potential BSODs etc with other security applications, it's not going to slow-down your system and take up valuable resources, it's not going to ask you endless questions about this and that. If you are so paranoid as to want to add a third party security application to it, then by all means go ahead (I personally chose Sandboxie).

Can I just pick your brains again regarding the Blaster worm? According to Sophos, this is how it attacked users:
http://www.sophos.com/support/disinfection/blastera.html#5

W32/Blaster-A scans the internet and local networks looking for computers vulnerable to Microsoft's DCOM RPC security exploit. When it finds one it causes the remote computer to use TFTP to download a copy of the worm.

For the home user, wouldn't a NAT Router or even Windows Firewall be able to block this? The worm would scan the internet looking for open Ports right? But wouldn't these Ports be stealthed behind a NAT Router and/or Windows Firewall, thereby not responding to the worm's call?

In this topic I'm just trying to expand on privilege escalation, its consequences, the multitude of different ways it can be acheived, and as you have discovered in your googling, just how frequently escalation vulnerabilites are found. Often by the good guys, occasionally by the bad guys and we're hit wth a zero day. Even less occasionaly, one that nails just about everyone on the net.

I'm not paranoid. I don't use any third party security software.

ssj100 wrote:For the home user, wouldn't a NAT Router or even Windows Firewall be able to block this? The worm would scan the internet looking for open Ports right? But wouldn't these Ports be stealthed behind a NAT Router and/or Windows Firewall, thereby not responding to the worm's call?

Oh, absolutely. It occured in the days before Microsoft had XP's firewall on by default. And before DEP. In fact, Blaster was surely the motivator for Microsoft to have the firewall on by default. SP1 or 2, I forget.

It was a mean old worm. You had hundreds of thousands, even millions of compromised computers all running it, scanning random IP's looking for another victim. You couldn't hook up your newly installed XP machine to the internet, unless behind an NAT router, and get to Microsoft Update before getting hosed by the worm. There was that much scanning traffic - you were almost certian to get nailed before you could get updated.

Tranquility wrote:In this topic I'm just trying to expand on privilege escalation, its consequences, the multitude of different ways it can be acheived, and as you have discovered in your googling, just how frequently escalation vulnerabilites are found. Often by the good guys, occasionally by the bad guys and we're hit wth a zero day. Even less occasionaly, one that nails just about everyone on the net.

I'm not paranoid. I don't use any third party security software.

Sure thing mate, and I appreciate your input. I'm always keen to learn and discuss.

What's galling is that most people on this forum (and other security forums) probably don't need to run any security at all (apart from maybe Windows Firewall and/or a NAT Router) - good common sense and computer experience seems to be enough. Those that say they got infected by browsing apparently legitimate web-sites (while searching for something genuine via Google) are either wrong (that is, their antivirus software issued a "false positive"), or they really need to gain more common sense/computer experience haha. That, or simply using a secured browser (Firefox with NoScript) would mitigate this attack vector with ease (even the latest Internet Explorer browser in default mode is very robust).

And keep in mind that even if your system does get destroyed or whatever (never happened to me in my life...and yes, I didn't get infected with that Blaster worm...in fact, I wasn't even specifically aware of it until now...7 years later), it's not the end of the world, particularly if you have a good back-up/imaging strategy.

The Blaster worm is an interesting one. You mention/imply that millions (or even "just about everyone") got infected by it. However, I didn't (as a home user), nor did anyone I knew (hence why I never heard of it). But I do understand your point.

Tranquility wrote:Oh, absolutely. It occured in the days before Microsoft had XP's firewall on by default. And before DEP. In fact, Blaster was surely the motivator for Microsoft to have the firewall on by default. SP1 or 2, I forget.

It was a mean old worm. You had hundreds of thousands, even millions of compromised computers all running it, scanning random IP's looking for another victim. You couldn't hook up your newly installed XP machine to the internet, unless behind an NAT router, and get to Microsoft Update before getting hosed by the worm. There was that much scanning traffic - you were almost certian to get nailed before you could get updated.

Wow, I did not realise that XP's firewall was once not enabled by default (although now that you mention it, it does seem to ring a bell). I also suppose back in 2003, there was still a fair proportion of people using dial-up (and therefore not behind a NAT Router). When I got my first computer running Windows XP (January 2002), I wasn't as knowledgeable about computers as I am now, but I was aware of the importance of having a Firewall enabled, as well as an Antivirus (that's what was heavily promoted back in the day). Then when Windows SP2 was released (around 2004 I think), the Security Center service further emphasised the importance of having both a Firewall and an Antivirus. Now that I'm more knowledgeable, I've disabled the Security Center service haha.

One great,informative,educational thread.

thanks guys,this is (one of the the things) that makes this forum superior.

noor

[quote=ssj100]
Also note the underlined text above. In my security setup/approach post, I emphasise the importance of sandboxing threat-gates as well as the intelligent handling of newly introduced files (especially those that you recover outside of these sandboxed threat-gates). Note that even if you were unlucky enough to get struck by lightning (get infected at the wrong time at the wrong place via a buffer overflow exploit/privilege escalation etc), you would still be protected by your lightning-proof suit (the sandbox). Of course, as tzuk mentioned/implied, a targeted attack at kernel level that bypasses even this sandbox (or any other kernel level protective mechanism like a Classical HIPS) can still get through your defenses. But then you're more likely to get a Royal Flush in Poker than this occurring haha.
[/quote]

Do kernel lvl exploits penetrate LV software?

MrBrian wrote:http://www.scmagazineus.com/hot-or-not-local-privilege-escalation-vulnerabilities/article/34794/

Old article (3 years old) and one that I've read about three times before haha. But thanks for the link anyway. What would be more useful to me, however, is to give me actual POC's and/or live malware to test out whether they can actually harm a system with LUA + tightly configured SRP. Fact is, if these exploits are so scary and increasingly common (as the article heavily implies), how come I can't purposefully find a single POC/live malware of them? The latest significant exploit was the LNK one, and a POC was released (thank goodness!). As we all know, SRP easily blocked it from doing any harm.

Rico wrote:Do kernel lvl exploits penetrate LV software?

I don't know. But based on tzuk's implications, no security software can do much about it, particularly if it's targeted. The only way to be completely safe from these sorts of exploits would be patching. Therefore, those who don't believe in keeping Windows up-to-date are most at risk from these exploits.

As we all know, SRP easily blocked it from doing any harm.

Suppose a malicious pdf exploit a vulnerability in Adobe Reader, SRP is bypassed in this case, right?

Sadeghi85 wrote:

As we all know, SRP easily blocked it from doing any harm.

Suppose a malicious pdf exploit a vulnerability in Adobe Reader, SRP is bypassed in this case, right?

Well, what do we actually mean by "bypassed"? For instance, I don't think SRP will block the exploit from being carried out. What SRP will do is to block the exploit from doing any harm (especially in the real-world). All exploits such as these always seem to require a further PE executable to run - SRP will easily block this.

Another example is in the case of Buffer overflow exploits - SRP will not block these exploits, but it will most likely block any consequence of that buffer overflow exploit (like downloading a PE executable and running it).

In the real-world, the anti-executable mechanism is extremely effective at preventing any harm to your computer. Realistically, this is all one would need. It's only paranoid freaks like myself (or perhaps people who don't really understand security) that feel the need to add in another layer of protection - containment (eg. Sandboxie, Shadow Defender).

Another example is in the case of Buffer overflow exploits - SRP will not block these exploits, but it will most likely block any consequence of that buffer overflow exploit (like downloading a PE executable and running it).

Yeah, that's most likely true, unless probably if the program that is going to be exploited runs with admin privileges?

Sadeghi85 wrote:

Another example is in the case of Buffer overflow exploits - SRP will not block these exploits, but it will most likely block any consequence of that buffer overflow exploit (like downloading a PE executable and running it).

Yeah, that's most likely true, unless probably if the program that is going to be exploited runs with admin privileges?

Yes, I suppose a separate privilege escalation exploit combined with a buffer overflow exploit could potentially bypass SRP. As I said before - being at the wrong place at the wrong time haha.

Again, the probability of this occurring in the real-world must be very very low.

ssj100 wrote:
Old article (3 years old) and one that I've read about three times before haha. But thanks for the link anyway. What would be more useful to me, however, is to give me actual POC's and/or live malware to test out whether they can actually harm a system with LUA + tightly configured SRP. Fact is, if these exploits are so scary and increasingly common (as the article heavily implies), how come I can't purposefully find a single POC/live malware of them? The latest significant exploit was the LNK one, and a POC was released (thank goodness!). As we all know, SRP easily blocked it from doing any harm.

I think it's been suggested by another person in a different thread: install XP retail (no service packs) without an Internet connection, configure LUA+SRP, don't use the firewall on a router, don't use any software firewall, then connect to Internet and wait "awhile" - I think you'd get infected by Blaster (if it's still infecting machines) even with LUA+SRP.

MrBrian wrote:

ssj100 wrote:
Old article (3 years old) and one that I've read about three times before haha. But thanks for the link anyway. What would be more useful to me, however, is to give me actual POC's and/or live malware to test out whether they can actually harm a system with LUA + tightly configured SRP. Fact is, if these exploits are so scary and increasingly common (as the article heavily implies), how come I can't purposefully find a single POC/live malware of them? The latest significant exploit was the LNK one, and a POC was released (thank goodness!). As we all know, SRP easily blocked it from doing any harm.

I think it's been suggested by another person in a different thread: install XP retail (no service packs) without an Internet connection, configure LUA+SRP, don't use the firewall on a router, don't use any software firewall, then connect to Internet and wait "awhile" - I think you'd get infected by Blaster (if it's still infecting machines) even with LUA+SRP.

I guess it's not the job of LUA + SRP to protect you from a port attack via the internet etc. As also previously mentioned, simply having Windows XP's firewall enabled (free security already built into the OS!) would have easily stopped the Blaster worm. Regardless, the Blaster worm was more of an exception right? I don't think we've seen anything quite like it again (and it's been 7 years or so).

Anyway, still waiting on some POC's or live malware to test out. I posted on another forum asking (KernlMode.info), and no one's replied yet:

Hi, does anyone have any live malware files of remote code execution? I am most interested in scripts and macros. For example, malware hiding in a Microsoft Word macro or that executes via cmd.exe, cscript.exe, java.exe etc. Thanks!