Investigating Privilege Elevation on Linux
We’re talking about ways in order to elevate privileges on the Linux platform and the discussion today will also be of use for anybody who’s worried about privilege elevation on other UNIX platforms. Basically, whenever you’re worried with privilege elevation on UNIX, there are basically two paths that you should be looking at or for elevating privileges.
The first such path is a kernel exploit. Innocence, your attacker will attempt gain execution in the kernel by hacking some user mode interface to a kernel service. Once that hacker has gained execution in the kernel, his goal will be to grant root privileges to a running shell or backdoor process through poking in the kernel’s data structures. That’s fortunately very easy to detect. Once this has happened we just have to have a scanner of all running processes and to take a look at their user IDs. Whenever the user ID of a running process changes by decreasing thereby suggesting that the process is increasing its own privileges it goes against a golden rule of the UNIX security model, which is that privileges for a given process can be reduced but can never be augmented. That’s pretty easy to detect that flashes is a big red light on our dashboards and there is little that a hacker can do in this space that will go beyond our surveillance.
The alternative from exploiting the kernel is to hack a highly privileged user mode application. In this case you want to gain execution in some daemon. Either through a good old memory exploit or more generally by exploiting a fault in the way this daemon handles it in books or a fault in the protocol for handling inputs either from the design or the implementation. An alternative on UNIX, you can hack the input parameters to a setuid program.
A setuid program is basically the tool of the devil. It’s on the other hand the only way for a user mode program to go from an unprivileged program to a high privilege program. In a sense, setuid programs, when they are started, get the privileges of the owner of the program rather than inherit the privileges of the parent process. This means that if a setuid program belongs to root when you run it, this program runs as root. Even if it was run by good old me who is not root. These things are evil, it’s the only way to properly implement the normal privileged elevation programs such as su or pseudo but many systems administrators are hell-bent on having a non delegating certain systems management tasks using setuid program and this is a very very bad idea and most privileged elevations go through these setuid programs.
What you do when you are hacking a frivolous user mode application? Essentially, you coax it into forking a shell or a backdoor for you. This is hard to detect, surprisingly. Why? It’s not so much that it is difficult to detect whenever a certain program for child process that suddenly has a higher level of privileges, it’s just that this pattern of events is frequent. Many high privilege applications will forge into high privilege child processes on a regular basis thereby granting many false positives to any test checking that. What do you do in this case? All the alleged stuff you try to whitelist, you will inspect, you will audit your typical privilege elevation pathways on a system but you will only whitelist them at your own peril as the upcoming examples are about to show.
Two examples here. One is about a situation where we get the sense of a privilege elevation but there is none and the other is an actual good old privilege elevation problem.
Let’s take a look first at this investigation here. What we have here is this process called polkit-agent-helper-1 which is now running as root but has a parent that was polkit-gnome-authentication-agent-1 that was running as user Victor. User Victor was able to fork a new process called polkit-agent-helper-1 from the polkit-gnome-authentication-agent-1.
What’s at stake here? When you’re in the know as to how that gnome interface systems work, you quickly learn that gnome has its own the wrapper around the pseudo process. This wrapper basically handles the authentication checking and then once the identity of the user has been checked and been known to match the set of users who can run pseudo, then it has its own setuid helper process, in this case it’s called polkit-agent-helper-1 in order to get it to elevate privileges on a running gnome process.
When you go and look at what is happening here right so this is the raw data stream sent by the machine on which this elevated process was found to run.
When you go into the the past for this, you see that the user was running aptd likely through the systems update tools enabled by his Ubuntu machine.
When you’re running aptd and you call for a system update, then of course you need to elevate your privileges in order to get this updated system. This is what happens here and after that the system the starts downloading new packages and if we keep digging down and exclude everything that’s concerned with Chrome we see that stuff starts deleting an old version of libc and then it starts decompressing and unarchiving new packages, in this case, apparently, go1.8.linux-amd64.gar.gz and we see other traces through new processes that talk about the update of the system.
In this investigation, it is clear that the process elevation from the gnome identification agent when the high privilege process created is polkit-agent-helper-1 this is clearly a legitimate setuid process granting legitimate privileged elevation.
All right, onwards to our next example. Here we have an investigation where the essential label is that privilege process ifstat with unprivileged parent bash. okay Let’s take a look at this guy.
Here we have a process in path /usr/local/bin/ifstat that’s been started by the good old shell from user hamelin, that was me yeah and that I did prepare for this it doesn’t look like it. This process is running as root.
What can we expect from this? What is the smell that I get? Well, clearly this program ifstat has been put into /usr/local/bin. Typically, people deploy programs in that directory when its programs that are not managed through the system’s packaging system. This means that likely this ifstat program is a homegrown piece of software or something built and put there through a hand managed package.
I go through to the systems administrator and ask, “What is ifstat?”. As the systems administrator I say, “It is a wrapper around ifconfig”. The ifconfig program for context is one by which you can query and modify the network configuration for a machine. So me again as the systems administrator tell you it’s because I wanted ifconfig to only be runnable by root and so I have written this wrapper around ifconfig called ifstat to enable users to use ifconfig only to query the status of network interfaces. “Ah” says I, “That is interesting. So how do you manage to get it to run ifconfig if your wrapper is meant to be run by lowly unprivileged users?” Me as a systems administrator say, “I have configured it as a setuid program. ” Then me as a hunter say to me a systems administrator, “You are a fool because look what this user have has done to you.”
It has called your ifstat tool in order to get to query the status of the eth0 interface up to now that’s fine, but then what do you see? You see the typical signature of somebody hacking the inputs of a setuid program. In this case, the user has managed to introduce the possible and invocation of a shell. Basically, the inputs to this program is probably fed into the system libc function which starts a shell in order to run a child program and when you do so and do not properly sanitize the inputs that you set up to be run by system, then you run the risk of your users putting in inputs that do way more than you intended to do with your wrapper.
Let’s dig down the little from there in order to figure out whether the user actually managed to elevate his privileges in this instance. The same way I did with the first instance, I go to the raw data stream for this machine around the instance of the detected privileged elevation. Clearly this has happened soon after starting the system, so I go down I am looking for an invocation of the ifstat program. Here it is, ifstat.
This code identity piece of telemetry was about hashing this program and then here I see it, oh I see a new process here where a process which was the parent the parent was ifstat which we saw run from a shell initially and now this program ifstat is launching a shell in order to run ifconfig eth0 followed by bin/dash.
This does not smell good because what happens after that. It runs this shell through ifconfig who then runs ifconfig after that starts a dash process. Dash is a shell on the system and this dash process is indeed running as root.
There is indeed in this instance the actual elevation of a process through an illegitimate mechanism. This privilege elevation event requires immediate incident response because once this dash shell was launched, it had root privileges so it was able to do everything on the system including deploying a backdoor, including deploying a rootkit.
I thank you very much for your attention and we’ll get to make another show like this in about a month thank you very much cheers and goodbye.
