My last blog about User Activation Controls suggested that they were of little help, even when they work. After all, user data (your documents, spreadsheets and such) are the most valuable things you have. Now, we’ll just trash UAC by bypassing it. We’ll do this by relying on a flaw: Microsoft loves itself.
Remember, UAC is the annoying prompt you get when attempting to install or modify a program. It also appears when attackers are attempting to escalate privileges, so they can pillage and plunder by installing system-level code, like rootkits or password sniffers.
To gain initial access to a PC, we’ll attack the Java vulnerability, CVE-2012-0507, written about in previous posts. Having older and vulnerable versions of Java is fairly commonplace and is plausible.
OK. Here’s the setup. There is a victim PC and a malicious server. The victim is running Windows 7 and a vulnerable version of Java. The server is Metasploit, setup to offer a rogue applet to any connecting browser.
In Metasploit, it works like this.
The operator of Metasploit connects to a session and finds out a user named Fred is logged on at the victim PC. But notice: the getsystem command failed. Getsystem is a Metasploit script that will attempt to move your privileges to the SYSTEM account, the all-powerful deity of Microsoft machines. Becoming that account will be our real goal. But, that pesky UAC prevented it. Let’s exploit a flaw in Windows to bypass UAC and gain SYSTEM-level access.
The flaw allows an application to run another application that does not require UAC.
For exploits to work, they need a vulnerability. All vulnerabilities require a flaw. To bypass UAC, we’ll attack the flaw that Microsoft trusts Microsoft. An article in OSnews outlined this rather nicely back in 2009. In a nutshell, the flaw allows an application to run another application that does not require UAC. Microsoft created some functions to bypass UAC – they are called auto-elevation. They did it so that UAC would not be constantly be nagging you to death. Microsoft tried to constrain this by creating a whitelist of applications that could to this. Lo and behold, all of them were built into Windows.
Here’s the tricky part. Windows applications can interact a fair amount. In fact, one process can inject itself into another. OK, analogy time. In scary ghost movies, a good guy is battling some evil demon-posessed bad guy. And right at the end, just when the good guy it about to vanquish the demon-guy, the evil spirit leaps out and takes over someone else to avoid destruction. The demon lives on in someone else’s body. This lets the producer make a sequel. In Windows, this is called process injection.
Fact 1: Many Windows application can auto-elevate.
Fact 2: Metasploit can selectively choose to move its own rogue payloads into almost any other application, like Notepad. Notepad is a signed Windows application.
Let’s watch this play out. Back in Metasploit, we had taken over a PC and a user named Fred. Now, we’re going to load a routine, called bypassuac, and instruct it as follows:
Fred’s PC is now owned by the attacker, who has unlimited privileges. No UAC prompts showed up and the user would be blissfully unaware of the attack. Just so you can see there was no slight of hand. Here are the UAC settings of the Windows 7 victim.
Microsoft considers this auto-elevation a non-issue, or perhaps even a feature. They were tired of all the complaints from users about UAC. So, do not look to them for a fix any time soon.
If this stuff intrigues you, there is a Learning Tree course on penetration testing that helps you learn to work with Metasploit and do things like escalating privileges.