Theory
Another method system administrators can use to increase the privilege level of a process or binary is “Capabilities” Capabilities help manage privileges at a more granular level (low-level/Micro-level) thus increasing the security.
Capabilities in a Nutshell: Before capabilities, we only had the binary system of privileged and non-privileged processes; either your process could do everything — make admin-level kernel calls — or it was restricted to the subset of a standard user. Certain executables, which needed to be run by standard users but also make privileged kernel calls, would have the suid bit set, effectively granting them privileged access.
These executables are prime targets for hackers — if they can exploit a bug in them, they can escalate their privilege levels on the system. This wasn’t a great situation, so the kernel developers came up with a more nuanced solution: capabilities.
The idea is simple: Instead of giving process full privileges of making any kernel calls we split them & assign processes only to the subset (necessary kernel calls they needed). for example ping, it can be given only the single CAP_NET_RAW capability as ping doesn’t actually need any capabilities instead of setting SUID bit which not only gives it CAP_NET_RAW privileges but also allow making other kernel level calls.
Want to learn more about this topic? Check these HERE & HERE.
Yes, they’re better compared to SUID, SUDO But that doesn’t mean that they are unexploitable, if configured badly then the malicious attacker can easily exploit them.
Practical
We can use the “getcap” tool to list enabled capabilities.
We’ve a lot of binaries with capabilities but let’s exploit the CAP_SETUID.
So what this capability does is allow us to manipulate the UID. we can forge the User ID to any ID & then run any program (0 = root or any user).
This capability same as SUID’s but keep in mind that neither vim or view has the SUID bit set. This privilege escalation vector is therefore not discoverable when enumerating files looking for SUID.
No SUID “s” bit set But works same as SUID because of capability (CAP_SETUID).
Here just forge the UID & run a bash shell.
Theory
Cron (daemon/service) use to schedule binary/script to execute automatically at a specific time or action (same as task scheduler in windows). By default, they run with the privilege of their owners. (Means who set up that particular jobs). Cron job configurations are stored as crontabs (cron tables) to see the next time and date the task will run. Each user on the system has their crontab file and can run specific tasks whether they are logged in or not
The Cron Jobs methodology is simple;
Identify the active jobs. Check if there’s a scheduled task that runs with root privileges or any other user. Change the script that will be run & gain that jobs owner privileges. (we can change if that script has write,execute perm or not full path defined loopholes etc).
Practical
Any user can read the file keeping system-wide cron jobs under /etc/crontab so check it.
Let’s enumerate this automated scripts. (As many times sysadmin delete the script but that script’s cron job remains active)
Scripts is deleted from the system which was automated at some point but it’s cron job is still running every minute so, what we can do is create a file named same as our deleted script file’s name & it’ll cause the cron job to executed our new created file with ROOT privileges.
After a minute, we’ll get the reverse shell of target with ROOT priv.
Theory
PATH in Linux is an environmental variable that tells the operating system where to search for executables. For any command that is not built into the shell or that is not defined with an absolute path, Linux will start searching in folders defined under PATH. (PATH is the environmental variable were are talking about here, path is the location of a file).
This techniques works best if you have answers of these questions
What folders are located under $PATHDoes your current user have write privileges for any of these folders?Can you modify $PATH?Is there a script/application you can start that will be affected by this vulnerability?
Practical
First, Check all the folders that have write permission.
We found one home dir of user & It look like perfect place to write.
Check what dir/folder are under path & can we modify path. (Answer of Q 1,2,3). Yes current user can modify PATH.
So, add the home dir of Murdoch to path var.
export PATH=/home/murdoch/:$PATH
In thm.py Look like it’s executing a os command “thm” (Answer of Q4)
Created a file named as “thm” & run the script so what happens is it’ll go to PATH var to search for “thm” & What makes a privilege escalation possible within this context is that the path script runs with root privileges. So when “thm” will get found in /home/murdoch it’ll ran as ROOT privileges.
That’s it for 2 part. More parts will be released soon.
Check these automated tools to enumerated these vulnerability easily.
github.com/carlospolop/PEASS-ng/tree/master/linPEAS
github.com/diego-treitos/linux-smart-enumeration
github.com/rebootuser/LinEnum
github.com/sleventyeleven/linuxprivchecker
L O A D I N G
. . . comments & more!
Understanding Privilege Escalation Techniques in Linux: Part2
Source: Trends Pinoy
0 Comments