Privilege escalation, why should I care?

Published: 2013-05-22
Last Updated: 2013-05-22 16:10:59 UTC
by Adrien de Beaupre (Version: 1)
17 comment(s)

In my day job I spend about 90% of my time on the red team, performing vulnerability assessment and penetration testing. The rest is spent on threat research, incident response, and digital forensics. Interacting with clients as a consultant I often hear what I term 'interesting' responses. When a penetration tester calls something interesting you should probably pay attention :)

The IDS only listens external to the firewall? SharePoint is directly exposed to the Internet? The WAF protects against attacks therefore we don't have to fix the application? The VMs are all physically on the same host? The DMZ and the internal VLAN are physically on the same switch? You don't bother with privilege escalation patches? All quite interesting.

One of the responses I have heard multiple times is that privilege escalation vulnerabilities are a low priority because they require the attacker have local access. Meaning that that would be very difficult to pull off, therefore we don't have to worry about it. This also assumes that every single account holder is 100% gruntled all of the time, and that nobody ever makes a mistake. Meaning that we can trust everyone who accesses our networks and applications. Which I also find to be 'interesting' :)

There are multiple types of privilege attacks. The first is privilege escalation, where someone who has valid credentials or means to access a network or application can raise their level of access to a more privileged level. Like getting root on a Unix system for example, or becoming Domain admin before lunch on day 1, or assuming a higher role within an application. Impersonation attacks are similar however they entail becoming a different user, often with the same level of privilege, but with way more money in their account :) which soon finds its way to a non-extradition treaty country.

If the major difference between a remote exploit and a local one is that a network connection is required for the former, and not for the latter, does this mean that local priv escalation attacks cannot be performed across the network? Actually no. If an attacker can gain access to a system through a client side exploit, they may then effectively become the local user, and escalate to local system. Local system priv on a Windows computer is just a hop, skip, and jump away from being Domain administrator.

In a recent discussion about the priority to be assigned to patch one comment was "It's only a privilege escalation!". Yes, you are correct, and that is an interesting statement was my response.

Adrien de Beaupré Inc.
My SANS Teaching Schedule

17 comment(s)


Adrien, could you provide us with some links discussing these other problems you mention in the second paragraph? I know of at least one reader (who could that be?) that currently has some of those issues. It would be useful to see some discussion that would help justify fixing those problems.
Hi Jim C, they are all interesting in that in my experience each has led to more than one significant breach. Either with me as a pentester, or as incident management lead. In all cases the client had a bad day. Each one is deserving of a diary article and lengthy discussion pro and con. Cheers, Adrien
The theme these days is hard exterior soft interior. Not applying priv escalation patches helps ensure you have a soft interior. With a hard exterior what makes a remote XP/Vista/7/8 vulnerability different than a local privilege escalation? No one from the internet can remotely hit the workstations to exploit them. The main attack vectors seem to be client side exploit or via email whether it exploits software or is just a malicious attachment. This leaves the attacker with the same access the user has, if the user is administrator then patching privilege escalation vulnerabilities probably isn't a priority. If the user is restricted then the next step is local priv escalation or exploit other hosts on the network which usually results in priv escalation.
Great posting. I think you address something that is at the heart of our challenge as InfoSec professionals: admins and other "IT Professionals" do not think past one dimensional, and single event/step issues. They often fail to see the 'domino effect' of single weaknesses, nor do they see the multiple vectors from which an vulnerability can be exploited. More than half our job is to educate data and system owners of these. InfoSec truly is a collaborative discipline.
I think what's not being taken into account is patching and the other risks that are being considered. While it's easy enough to say that it's "interesting" someone would choose to prioritize a PE vulnerability as low, it might be in favour of re-mediating a critical vulnerability on an exposed host. The risk and likelihood of an exposed host being exploited would generally seems to be much higher. If it came down to a choice between fixing a PE vuln or a vuln which may allow something like SQLi. I think I would choose the latter and then follow-up with the PE vuln afterwards. Risk versus reward. All vulnerabilities should be addressed but unfortunately they have to be weighed you have to do what you can to get the most bang for you buck in the enterprise.

If they choose not to flat out not patch or mitigate the vuln at that I would find interesting.
As a production server sysadmin my response to OS level privilege escalation is why bother. If they can get to the place where they can run code, by attacking the OS or the single application, they have the valuable data within their grasp without using it.

The production servers are isolated and even interior is hard to get at because I went way out of my way to make it so. Compromising the domain controller (which is not under my control) will not easily breach the production servers, and unless the attacker has been here for awhile he won't find out how. I worry more about certain engineers' workstations who haven't learned what it means to pick a strong password and have access to production.
@joshua: precisely. I gather the credentials/hashes/tokens/data by pillaging workstations. I don't hack the production servers. I just log in.
@Noot. Yes, there should be a conversation about risk, mitigation, cost, and level of effort. However in quite a few enterprises the decisions don't always follow a rational pattern when layer 8 gets in the way. Often leading to interesting decisions.
@ Ferret. Yes, attackers understand island hopping, good pentesters can demonstrate real risk using creativity. A sysadmin might only understand their little piece of the pie.
@Adrien +1 to circumventing all that fancy production security with a legitimate login.

Diary Archives