In this part of this series, I’m going to cover 3 more techniques.
Check the previous parts of this series HERE
Note: This is the final part of the Linux Privileges Escalation series as I covered almost all the important Attack vectors (A/C to OSCP) but will surely update this series if I find any new vectors/techniques also feel free to ping me on Twitter (LE0_Hak) if you know any.
13. Privilege Escalation: Local User Accounts Brute-Forcing
A user is an entity, in a Linux operating system, that can manipulate files and perform several other operations. Each user is assigned a Unique ID & other attributes. The password of each user in Linux is stored in /etc/shadow in a hashed format.
Theory
The User Account BF methodology is simple; (use this only when no other attack vectors are feasible because this technique takes time/resources, creates a lot of logs & luck-based)
- Check all the current users in the system.
- Collect all possible information regarding the password policy of target (this part is Optional but useful as we can narrow down the search of the dictionary/wordlist in part 3)
- Launch an attack on a specific user on the system.
Practical
Found one user “luke” in the system
Also, there’s a file on the target file server which gives us a hint of the password policy in the target network.
Now let’s try to brute force the user “luke” password. The tool which is used to brute force local user “luke” account here is sucrack
Now we can switch to Luke user to further escalate our privileges to root or other users.
14. Privilege Escalation: Binaries
Theory
A binary package is an application package that contains (pre-built) executables, build from source code, and is not reversible.
The Binary methodology is simple;
- Search for all the installed binaries in the system
- Check the version of binary that’s more prone to vulnerabilities e.g exim, pkexec, su, etc.
- Find or write the exploit code to get that binary owner privileges.
Practical
Here I found a pkexec that has by default suid bit of root but here we don’t want to abuse the suid instead let’s check this pkexec binary as this binary had a lot bad reputation in the past (a lot of CVEs were found in this binary).
I use this tool that automatically checks if this current pkexec binary has any vulnerabilities or if it’s vulnerable to CVE-2021–4034. (Most popular CVE is known as “Pwnkit” which affected nearly all Linux machines. This vulnerability occurred in polkit or more specially polkit utility pkexec installed by default on all Linux systems).
I use this exploit code to exploit this vulnerability.
And we got the Root access. similarly, we can exploit other vulnerable binary installed in Linux such as su,adduser, sudo, mount, etc.
15. Privilege Escalation: Shared Object Injection
Shared libraries are the most common way to manage dependencies on Linux systems. These shared resources are loaded into memory before the application starts, and when several processes require the same library, it will be loaded only once on the system. This feature saves on memory usage by the application.
Theory
The Shared Object Injection methodology is simple;
- Check for a program or service that uses any shared object (.so) library using ltrace or strace (both programs allow us to monitor/trace all the system calls or shared object library called by that executed program).
- If find any shared object library then create your payload with that same library name.
- Execute that program again this time it’ll call your payload (one) shared object instead of the original.
Practical
Here we found a binary that has root suid (but again don’t need to abuse suid here as we going to hunt for shared objects).
So we run this binary & trace behind the scene of this process.
We found one shared object (libcalc.so) which is being accessed by binary (suid-so) & another good thing is this .so is not opening as it’s not there in the system.
So let’s create a payload with the name libcalc.so.
Payload created, after that just compile it & execute the binary (suid-so) again.
This time binary (suid-so) will call our payload (which spawns a shell) but this shell will be Root since binary (suid-so) has root suid bit set so it’s running with root privileges.
