How privileges work in operating systems?
By definition privileges are defined as the delegation of authority over a computer system. When the user wants, for example, to create a file, write some data to the memory, run some device or get access permission to a socket for communicating over the Internet then Then Operating System have to decide if requesting user has proper privileges to perform the specified action.
Users who have been delegated extra levels of control are called privileged and the user who lacks most privileges is defined as unprivileged, regular or normal user.
In modern computer systems we have two special modes that allow users execute an application on operating system level:
- Kernel Mode – In this mode, executed code has complete and unrestricted access to the hardware layer. It can execute any instruction and reference any memory address. Generally, kernel mode is reserved for the low-level and most trusted functions of the operating systems.
- User mode – In this mode, executed code has no ability to directly access hardware or reference memory. Code running in user mode must delegate to the system APIs to access hardware or reference memory.
Other types of software handle access rights in different ways, for example databases have security roles which define how different users access different types of records. Each user can have multiple security roles. Also, web applications can have security roles defined that allow users to log in, get access to the specified part of an application, create, edit, or moderate contents.
What is privilege escalation?
Privilege escalation is the act of exploiting a bug, design flaw, configuration oversight in operating system, software application or web application which allows the user to access information, features or functionality that they are not entitled to in their role.
Computer systems, software application and web application are designed to be accessed by multiple users, with different level of permissions. Privilege escalation vulnerability allows malicious user to obtain privileges of another user they are not entitled to. Privilege escalation occurs in two forms:
- Vertical privilege escalation – Occurs when user can access resources, features or functionalities related to more privileged accounts. For example, if we have a normal user account in operating system and we can find a bug that allows us to gain access to the root account which have full permissions, or have normal user account in web application, and we have the ability to log in to the higher privileged user account like as an administrator.
- Horizontal privilege escalation – Occurs when user have the ability to access the resources, features or functionalities of the accounts having similar privileges. For example, we have a bank account and we are able to log in to another bank account with similar level of privileges.
During a penetration test, rarely will the tester get access to a system with administrator privileges on the first attempt. You are almost always required to use privilege escalation techniques to achieve the penetration test goals.
Few examples of privileges escalation:
- Kernel exploitation – By exploiting vulnerabilities in the operating system kernel we can escalate our privileges.
- Vulnerable applications – When application is running with administrator privileges, then by exploiting vulnerability we could get administrator privileges.
- Bypass of authorization – Occurs when we can log in as a higher privileged account without using password.
- Misconfiguration – Occurs when application installed on operating system has wrong configuration.
- Jailbreak – It’s an act or a tool used to break out of a chroot or jail in UNIX-like operating systems or to bypass DRM (Digital Rights Management). For example, iOS jailbreak allows to install applications outside the AppStore.
Privilege escalation examples
One of the most important things during a penetration test is to gain access to administrator account. If the application (for example webserver) is well configured, it is most often run with limited user rights, only able to run a specific application. When we can get low privileges access to the server using some vulnerability, the next step is to get higher permissions to read important files, continue network exploration etc. To do this, we must use the privilege escalation technique.
Now we will see some examples of privilege escalation. We will use virtual machines hosted on Vulnhub (https://www.vulnhub.com/). These are machines that contain common misconfiguration that will be used to achieve our goal, that is, get administrator privileges.
To successfully carry out a privilege escalation attack, we have to learn as much as possible about the system that we want to attack. For this purpose, we must conduct a decent reconnaissance.
The most important information is:
- what is the operating system?
- kernel version (for Unix/Linux system)
- what applications have been installed?
- are there any files with suid/guid bit set?
- what services are running?
- which services work under the administrator’s account?
- are other users logged in?
- are there any entries in bash history that contain passwords or other sensitive data?
These are just a few examples. It should be remembered that the more we know about a system, the higher the possibility of elevating the privileges in it.
This article will not describe how to download, prepare and install the system on our local machine. It just shows the steps strictly related to privilege escalation part.
- Operating system privilege escalation
After we manage to exploit the vulnerability and gain a shell we should see something like this:
As we can see, we are logged in as user webmin, who has uid=1001 and gid=1001. We don’t have access to the /home/vulnosadmin/ which is probably administrator’s directory. So, now our goal is to get access to this directory.
Now, we must check what system we are dealing with. To do that, we need to:
- Check OS Version
- Check kernel version
- Check available users and the current user privileges
- Find suid/guid files
- Check what software is installed on the machine
Let’s check the version of Operating System running on server:
As we can see that server is running Ubuntu 14.04.4
Now let’s check kernel version:
Victim have 3.13.0-24 kernel version. Now, let’s check if any public exploits exist for this system version.
We can go to the https://www.exploit-db.com/ and search for ubuntu exploits. We can find exploit called ofs.c – overlayfs local root in ubuntu and we will try to use this exploit to privilege escalation.
As we can see, our exploit worked properly and, thanks to that, we gained access to administrator’s account. We have successfully elevated permission from a regular user to the root account.
- Web application privilege escalation
In web applications, privilege escalation can rely not only on taking over administrator account or a user with higher privileges, but also on running commands or queries that require higher rights than ours, without direct access to the privileged account. In OWASP Top 10 project, these types of errors are listed under the name Broken Access Control and Broken Authentication and they are located in the 2nd and 5th place of the list.Firstly, we will discuss a Broken Authentication issue which results from logging into a different account than ours, often with higher permissions. In penetration tests, the main purpose is to log in to the administrator’s account, therefore our goal will also be to attempt to log in to administrator’s account.At the beginning, we will start a special application WebGoat which was created to test your skills and learn about web security. The installation and configuration process of this package is not described in the article. For details, please consult the main page of the project https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project.Our task is to log in to the user with administrator privileges. We can see the login panel.
Without knowing the password to this account we must try to bypass password protection. The most popular and the most effective way is to find SQL Injection vulnerability and exploit it.Let’s try to use this technique now. Instead of a password, we will try to enter ‘or’ 1 ‘= 1. This is a typical way to use an SQL Injection type error which allows to bypass the authentication without knowing the correct password.
As we can see, the application has allowed us to log in to the user Neville, who is the administrator, so we have obtained the rights of administrator and our goal has been achieved.
The next threat we will discuss is Broken Access Control. This error occurs when the system incorrectly implements access controls. An example of this vulnerability may be e.g. command execution or access to data that should not be accessible for a given user role.
We will use the WebGoat software again. Our task is to look at the user’s profile. The problem is that, theoretically, we do not have the right to do so. Let’s try to bypass this. After logging in to our account, we see that we can see the profile of the user we just logged into.
When we click on the ViewProfile button, information about the user will be displayed.
Now let’s examine the data sent to the application by the browser. For this purpose, we will use the Burp Suite tool which will allow us to see HTTP traffic and requests to our application. Again, click on ViewProfile and check what Burp shows us.
As you can see in the attached image, the application sends 2 parameters to the server. One of them, named employee_id, looks interesting. As you can guess, this parameter determines data of which user will be rendered in response. Let’s try to change the employee_id parameter value to e.g. 101.
Our goal has been achieved. We could see the data to which we shouldn’t have access. This type of attack is horizontal privilege escalation which means that we have access to data we are not permitted to.
How to prevent privilege escalation?
It’s impossible to completely secure against privilege escalation attacks. However, we can make it difficult to exploit.
To minimize the risks related to privilege escalation, you must follow the process called Principle of Least privilege which relies on granting access to users, processes, or programs, only and exclusively to the resources they need. For example, a user who is delegated to create backups should not have the right to install the software, because he does not need it to perform backups.
To be better protected against such attacks, we should install a well-tested system for monitoring the network and user activity, so that it can detect unusual actions and blocks them immediately. This is not an easy task, but the correct configuration of such system will allow to protect the network against privilege escalation attacks.
You should also remember about a good antivirus program that will protect you from most software that can elevate user or process right, as well as ensure regular updates of the systems and services installed.
Of course, there are more methods and techniques to protect yourself against privilege escalation attacks, but remembering the most basic principles we can effectively prevent an attacker from penetrating our system or network.
In the case of web applications one of the methods is the Checking Permission By Role method.
The roles assigned to specific users of the application should be defined during the design stage. This will create a mapping between users and commands, queries or actions available to them. It can be created using the so-called “role matrix”. All actions should be “deny by default” and only those permissions that are necessary for given users or groups should be granted. To put it briefly, if the permission is not explicitly stated, then it is not in the system.
Example of the „role matrix”:
|Permission 1||Permission 2||…||Permission N|
The above “role matrix” would be accompanied by mapping user accounts to roles (i.e. a users/roles matrix):
|Role 1||Role 2||…||Role N|
Even with properly implemented permissions checking, it is still possible to “drop the ball” in other ways. Clearly, the role/permissions matrix and user/roles matrix should be configurable outside the application and stored in a secure manner with role-based access control. The insecure storage of the role, permission, or user information used by the application can render permissions checking a moot point. Also, any misconfiguration of that same information can lead to Privilege Escalation, even if the application itself is properly checking permissions.