As we clack away on our keyboards, running numerous scripts, sipping Club-Mate and green code flooding the screens, the “1337 h4x0r” vibes kick in. Breaking into firewalls after firewalls, we are finally at our destination, the esteemed terminal and we have donned the disguise of the user Alice. But, wait what? Alice can only play music files on this system!? This is not what we spend endless nights in underground leet hacker forums for. It’s time to transcend user permissions and “escalate”.
You must be thinking what are we blabbering about, so let us take you through the thinking process of a hacker when he decides to make a move. Imagine what was going through the mind of Vasily Kravets when he found a way to become administrator of any computer with Steam (yeah gamers, you guessed it right) installed because of a design flaw in the Steam client or how the most loved Chrome browser can be manipulated to compromise a system. Be it a software developed by a big corporation or getting in school systems to change grades (don’t do this though), the overall process remains the same. In almost every system we have tackled, following the simple methodology of enumerate, exploit and escalate, which we like to call the 3E process, has always proved fruitful to us:
Find as much information/intel about the system as you can.
Figure out the weakest link and break in through that point.
Escalate from a weak user (most exploitable services have only limited privileges) to a more powerful user.
The last step is where the privilege escalation attacks take place. According to Forrester, almost 80% of security breaches involved privilege escalation and privileged credentials abuse in one way or another. where a system misconfiguration or a design/implementation flaw unwittingly lets an attacker interact with the system as a user with more permissions than intended. Privilege escalation is done mostly after you have some sort of access to a system shell. These kinds of attacks are broadly of two types:
Vertical privilege escalation
Horizontal privilege escalation
Vertical Privilege Escalation:
When an attacker gains access to a user with more power than the current user, then the attacker has performed vertical privilege escalation. Say, you worked your head off all day installing Arch Linux in your new laptop and preferably, gave your account all the permissions. Then your best friend comes along and wants to use your laptop to read a book, so you created an account for him just giving him enough freedom to read files. But what do you see when you come back? Your friend has played a prank on you by running the dreaded sudo rm -rf because he was able to read the file you store your password in.
In contrast to vertical privilege escalation, this type of attack takes place when an attacker goes from a user with certain permissions to another user having similar permissions. We all remember the good old days of Windows XP, where our parents had one “Administrator” account and separate accounts for you and your brother/sister. But your sibling is a closet hacker and got access to your account (this was actually possible back in the day: https://dgit.in/xphak).
The categorization we talked about was mainly from a theoretical point of view, but security is most parts technical and hence finer divisions are necessary to understand privilege escalation and mitigation. Technically, escalation attacks can be distinguished based on the operating system of the machine under attack and the two most widespread OS are Unix/Linux and MS Windows, hence we'll focus on these two. (Privilege escalation attacks do exist for Mac systems, we'll talk about them later in a brief manner).
Unix/Linux and MS Windows makes up to about 99.8% of the OS being used in the wild on the world wide web. Who uses Mac OS as backend server OS anyway, right? Pfft. But apparently, some machines have been seen running Apple’s home grown OS. Most websites you see are on Unix/Linux based servers while Windows provides support to Remote Procedure Calls(facility for remote interaction to systems not available for physical access), file sharing services, etc.
Almost 70% of the websites use Unix/Linux based OS, as of 14th November 2019 (https://dgit.in/osoverview), as a result, an array of privilege escalation attacks exist for these systems. Firstly, we'll be broad with the categorisations and then check out the finer details under these categories:
System admins are after all humans, and many a time while managing complex systems some configuration done to minimize efforts/work may prove fatal to the security of the system. While doing machines on the HackTheBox platform (https://dgit.in/htb), the most basic step is to check what commands are allowed by the system to be run as sudo, by running sudo -l. Now, this is an intended feature of sudo but provides crucial information to the attacker. One of our favorite use of this command was in OneTwoSeven machine which revealed that the http_proxy environment variable was being used while running apt-get update using a proxy server as sudo, which allowed us to perform a man-in-the-middle(MITM) attack (https://dgit.in/mitm). Misconfigurations can sometimes be easy to exploit, sometimes extremely hard, all varying from system to system. Another misconfiguration we have encountered many times is giving read/write access rights to files without considering their future consequences. For example, consider a seemingly benign file that anyone can read/edit, this file, in turn, gets used by another file/process during run-time, which gets executed through higher privileges. Editing the base file (with fewer restrictions) with a payload that can lead to privilege escalation.
Many servers/systems use custom binaries to run specific services, which the system owner or service provider has developed in house. These binaries are written in low-languages to improve performance and C/C++ is the language of choice. But the problem is that C/C++ are neither memory-safe nor type-safe or simply put, they are susceptible to buffer-overflow attacks. Buffer-overflow attacks is a huge topic by itself and are out of the scope of this article. Even if the binaries are not custom-built, the Unix/Linux system binaries may pose a threat to the system's security. GTFOBins (https://dgit.in/gtfobins) is a highly curated list of exploits in system binaries that may help in bypassing local restrictions and is one of the best places to get the required payloads for binary exploitations.(These are not necessarily classic attacks like buffer-overflow, ret2libc attack, etc).
These are a special kind of tools which are usually built to exploit programs which work at the kernel level, for example, hardware drivers, etc. These are harder to create since knowledge of machine language is required and hence is one of the areas where we continuously try to improve our skills. We only encountered one machine where we needed a rootkit to gain root privileges where a backdoored kernel object (compiled from a Linux kernel module) was used to gain root access. Here's a great article that helped a lot: https://dgit.in/kernelrootkit.
Sometimes, the applications you put your trust into might not be worthy of it. A lot of applications, over the years, have kept passwords/credentials in easily breakable encryptions or even in plain-text, hoping no one will look there! This sometimes gives the attacker an easy way in. Having guessable passwords for master passwords of password managers can prove harmful too. To this, add the human nature of reusing passwords and you give attackers a one up on your security.
Services, no matter how robust the developer thinks it is, exploits may arise due to a lack of proper coding practices. While doing KryptOS, the privilege escalation was the hardest we have encountered till that point (after all the machine was rated insane), because a custom exploit was required. One of the service's python code was retrievable and it was using a pseudo-random number generator (PRNG) to authenticate itself to another service. Now this PRNG was broken as in no matter how many random numbers you generate, only around 100 were unique in them which allowed a brute force attack. These custom exploits may result in direct privilege access or may provide enough to move ahead.
The second major OS used by the server/websites on the internet is the ever-favorite desktop operating system, MS Windows. Due to less customisability and its closed-sourced nature, Windows privilege escalation is not as popular as Unix/Linux privilege escalation but nonetheless, there are numerous ways to get administrator access (notice how it's 'administrator' for Windows while 'root' for Unix/Linux systems).
After a long day of work, you settle down to enjoy an hour or two of your favorite RPG. But uh oh! What’s that? The infamous “xxxxx.dll not found” error pops up. You wouldn’t have thought in your wildest dreams that these files could be crafted to take down your system. Whenever a Windows application is executed, it looks for dynamic linked libraries (DLLs) which are loaded during runtime. Now if a DLL is missing the application will give an error. This gives the attacker an opportunity to inject malicious and specially crafted DLLs which the application might use thinking it's the real deal. This leads to escalated privileges.
This category is common to both Linux/Unix and Windows, which is understandable because after all developers think alike, sometimes in a bad way. Once we encountered a machine using a version of mRemoteNG, a famous remote connection manager, which stored the master password in a hash form, which was breakable (there is a Metasploit module and numerous scripts available online). Another way to gain credentials is from unsecured backups. For example, the SAM file in Windows is a database file that stores user passwords, is present in C:\Windows\System32\config folder but is not accessible when the OS is running. But if this file is extracted through a backup, that can prove to be hazardous. Some processes may dump clear-text passwords when their process are analyzed. One good tool to do this is procdump.
New zero-day vulnerabilities are being discovered daily and lots of them allow local/remote privilege escalation. The .NET Framework local privilege escalation vulnerability (https://dgit.in/dotnetvuln) which was recently discovered in September 2019 is one of them or the more popular group of vulnerabilities like EternalBlue/EternalRocks/BlueKeep etc, are very harmful unless they are patched.
MacOS is the host OS of very few computers running on the Internet but still widely used as a personal computer. Some of the exploits that exist are mainly for older versions, like the "Windows Server" component (https://dgit.in/macwinserv) which had a high severity or the Kernel-LPE vulnerability present in the <18.7.0 versions (https://dgit.in/1870). Most of these are not useful in the actual environment and real-time pen-testing. In fact, one researcher going by the name of “Siguza” released details of one such attack back in 2018 and here comes the fun part, the vulnerability was present in the OS since 2002! That’s huge! But guess Apple got lucky since a good guy found the exploit before the bad guys.
Usually, to figure out what kind of approach or which attack vector is the most optimal to perform, initial system enumeration performs a crucial role. Knowledge of users, groups, file permissions, and other information is very important. This step is mostly automated using numerous OS enumeration scripts. There are a lot of scripts, here are some of the most famous and most used one:
enum4linux (https://dgit.in/enum4linux)
linux-smart-enumeration (https://dgit.in/smartenum)
LinEnum (https://dgit.in/linenum)
linuxprivchecker (https://dgit.in/privcheck)
Just Another Windows Script (JAWS)(https://dgit.in/jaws)
Watson (https://dgit.in/watson)
WindowsEnum (https://dgit.in/winenum)
Seatbelt (https://dgit.in/seatbelt)
User access controls, permissions, privilege levels, etc play a huge role in a big enterprise where security is the utmost priority. Hence, in case of a breach, the main goal is to minimize the damage as much as possible. One policy to protect the systems is to implement the Principle Of Least Privilege, where only a bare minimum amount of permissions are given to a user which will allow them to do their work. So in case even if a user account is compromised, the damage will be only to the extent the permissions allow them. But privilege escalation attacks thwarts this technique completely and has an adverse effect if the hacker gets permissions not intended for anyone except the admins who manage the servers. Privilege escalation attacks are rarely the endpoints of a cyber-attack (it is different in case of HackTheBox, VulnHub, and other platforms, where root privileges are considered the final step) and after gaining the necessary permissions, the adversary usually has plans for other malicious activities like installing a backdoor, dumping crucial info, etc. Hence, in case of a breach, first responders should see to it that the attacker doesn't get far and trap him while the damage is minimal.
Now after having a look at privilege escalation attacks from the perspective of a hacker and considering the huge impact they have on enterprises, it time to put down the black hat and take up the white hat. Mitigation techniques overlap operating systems and exploit methodologies, so it's better to not do any categorisation as everything applies to everything.
This is one of the crucial steps to prevent privilege escalation attacks. There are only a few cases where hackers use a zero-day vulnerability to leverage accesses because, in most scenarios, a pre-existing unpatched vulnerability is what gets used to gain entry. So keep your systems up-to-date and update them as soon as patches are released by the parent company of the vulnerable software. Especially, keep an eye out for security patches.
Make sure to use functions that are not susceptible to common vulnerabilities like buffer overflow, stack smashing, etc. The safest way to ensure safety in this aspect is to use a memory-safe and type-safe language like java to write applications. Even if you are using C/C++, use the safe variants of vulnerable functions that analyse user-input before parsing them ( for example, using strcpyl() instead of strcpy(), which considers the buffer length before copying data into it).
Wherever and whenever you are taking input from external sources, never trust it. Treat all input data as potentially malicious and perform necessary actions and checks before parsing it. This is true especially in case of attacks that use user input as attack vectors such as SQL injection, local file inclusion, etc which inevitably might lead to privilege escalation attacks.
This is the simplest way of them all, but the most difficult to enforce because human memory comes into play here. Passwords should be hard enough to be not guessed and invulnerable to brute-force attacks but easy enough to remember so that users don't keep Post-its notes of passwords stuck to their desks (this is just one of the ways in which extreme password policies weaken the security instead of strengthening them). Also, make sure to change the default passwords of any hardware/software you use.
As mentioned earlier, use the Principle Of Least Privilege while assigning permissions to ensure minimal damage. Create groups and users for specified tasks and localise them so as they can't access other areas. Same goes for file access permissions.
Close all unused ports and services not actively used. Remove or restrict functionalities which might allow attackers to transfer data to and fro from the system. Remove accounts no more associated with active users and other dormant credentials. Restrict access to hardware devices like routers, printers and remove unused hardware from the network.
Following the above-mentioned practices will prevent/mitigate almost all the privilege escalation attacks. Stay alert and up-to-date with the latest vulnerabilities and hold a monthly or bi-monthly review to ensure all the ideal conditions are being satisfied. Make necessary changes whenever something out of order is discovered.
Privilege escalation attacks, irrespective of operating systems and environment, are still a major issue in the cyber-security spectrum. And the problem can’t be curbed unless the rules are strengthened, but then again compromises in performance and efficiency are unavoidable since humans are involved. A perfect balance, a sweet spot has to be found and the most important part is that system admins need to be aware and ditch the mentality “this cannot happen to my system”. The enforcement will take time, but it is, indeed, possible to render the ever persistence privilege escalation attacks, void.