Privilege Escalation
One aim of the exploit process is privilege escalation (privesc). Normally when we get our initial shell its for a low privileged user, and tends to be restricted in what we can do. Therefore we want to see if can upgrade this low priv shell to something with administrative access. Having admin rights on a system is the ultimate "Win", as it means that we should have access to the full functionality.
Note
This is reflected in may CTF challenges and war games. Flags and points tend to be given for both "User" (unprivileged) and "Root" (superuser) accounts.
In the next couple of topics we will look at Linux based Privilege escalation. This is where we attempt to misuse the configuration of a piece of software, or kernel level functionality to assume the privileges of a user other than ourselves.
As with a lot of the things we cover, the methods we use for privesc will differ based on the situation we are in, and it would be impossible to cover all potential topics. However, we will look at a few of the "classic" methods of getting an elevated shell, and examine the mistakes that lead to these problems.
Note
We are going to do this all "by hand", rather than use pre made scripts or metasploit. While these tools have a very important place, in real world pentesting, I feel they can hide some of the nuances behind the problem.
Also, its a lot more fun to understand why the issues occur by breaking them yourself.
The need for elevated privilege.
One of the problems with a multi user system is access control and permissions. Giving every user administrative rights is an incredibly bad idea, so we tend to segregate users into "Standard" accounts and "Superusers" (root in Linux terminology). The standard user will be limited in what they can do, to prevent malicious (or accidental) damage to the system.
We could take this to one extreme and have seperate Admin and User accounts for individuals. You login as admin if you need admin stuff doing, and a normal user the rest of the time. However, this causes a problem. If everyone has low priv access by default how do we get anything done. Even simple things like bringing a network interface up or down, require systems level access, which wont be available. This would mean that you would have to logout, log back in as admin, do your change, then log back out again1
A much more usable approach would be to allow users to temporarily become root. This means they could use the standard level account by default, but be able to assume the higher level powers when needed.
This is an even better approach in terms of security is to apply the "principle of least privilege", here users will have the lowest privilege levels by default, meaning that for the majority of the time even admin2 users will only have standard permissions.
As well as People, processes may also require elevated privileges. There are some common commands that all users should be able to access, but we might not want to have to grant them any form of superuser rights. This is often the case with programs that need to access low level system resources, or privileged information.
Example
Lets examine the common task of changing passwords. Evidently the file containing the hashed passwords should be secure, and only accessible by privileged users. However, if a user wants to change their own password we have a problem:
- Either the unprivileged user needs to be able to access the password list (which makes securing it pointless)
- Everybody who may change their password needs SUDO rights. (Which defeats the point of them in the first place)
- The user would have to give their password to the systems admin to get it changed (Letting others know your password is also a bad thing)
Using Misconfigured services to elevate permissions
Ironically, it is this need to temporarily elevate privileges for a "good reason" that provides the opportunity for many privesc attacks.
Many of these problems come through the administrator not configuring the system correctly. This is easier that it appears, many commands have extra functionality that changes the way it behaves, or allow us to start secondary processes.
In the next part of this weeks materials we will discuss some of these common configuration mistakes in detail.
CTF Tasks and Docker.
Info
From now on we are getting a lot more practical, with more tasks to try.
Each task will give you one or more flags. Make sure you keep track of the flags you have.
The lab tasks this week will involve a set of privesc based challenges. There will be an worked "example"
For each privesc example there will be a walk through, and one or more
challenges. For each challenge you will need to login as the cueh
user (password cueh). Inside the root users home directory
(/root/root.txt), there will be a flag. Keep a note of the flag,
as we will want them later.
Summary
In this article we have introduced the concept of privilege escalation. In the next few articles, we will have a recap of Permissions settings, then see how we can make use of them for privesc.
Links
- Linux.com article on Permissions: https://www.linux.com/learn/understanding-linux-file-permissions