Gaining Root Access on Linux by Abusing SUID Binaries (Privilege Escalation)

[Music] hey there i'm andy and in this video we'll be exploring how to attack detect and defend against the abuse of set uid and set gid permissions on unix-like systems are commonly articulated as read write and execute for each of the owner user owner group and everyone else although other permission bits can also be set one of these is the set uid bit which instructs the operating system to always execute this file in the context of the file's owner so in the case of this file here which is owned by root and has the set uid bit anytime any user runs it it will always execute with full root privileges set gid acts in a similar way but triggers apps to run in the group context of the file's owner group rather than the user set uid and set gid are used for several genuine cases to allow normal users to perform a very restricted set of desirable actions which would otherwise not be possible for example changing password requires writing to the etc shadow file now granting normal users direct access to edit this file would be completely disastrous as it'd then be trivial for any user to change any other user's password so instead the write access is limited to only the root user and the password change app is granted permission to run as root via set uid it is then responsible for undertaking all the necessary checks and balances to ensure that only the requesting user's password is changed to help it perform these checks whenever a process is launched with set uid the kernel records the effective user permissions in a separate variable we can see this most clearly in the id command which prints these data values screen when run normally note the uid and gid values indicate it's running in a standard user context now if we take a copy of the id program and add the setuid permission to this copy and then run it we see that the uid and gid remain the same but the effective uid is that of root so this process has root privileges but it also has knowledge of the uid that spawned it so that its internal logic can sensibly limit actions to avoid abuse any set uid program with flaws in its logic could potentially be used for nefarious purposes thankfully such bugs are rare in the programs which are typically granted set uid in a default system install however system administrators occasionally end up granting other apps set uid permissions which either contain flaws or little known features which can lead to abuse [Music] the first step in abusing set uid binaries to elevate privileges is to find which apps on a system have that permission bit set one of the easiest ways is via the ubiquitous find command specifying the perm option to search for any file with the set uid bit represented in numeric form as the number 4000 or 2000 to find set gid files some apps have very obvious features to launch another app for example the whole purpose of bash or any other shell is to launch other apps or script interpreters such as perl php or python come with functions to launch other commands identifying setuid on any of these would grant an attacker the ability to run any code with full super user privileges similarly granting set uid to a text editor like nano would also be a major mistake on the part of the system administrator as it would allow easy access to edit critical security configuration files such as password and shadow to create a new privileged user or edit the sudoes file to allow a low privileged user to elevate any command to root any other app that allows file reading and writing can also be abused in the same way albeit through some more roundabout routes a full list of common apps that can be abused in this way can be found on the gtfo bins repository filtering by file read and file right also listed on this site are apps which can be used to run code and spawn a new interactive shell avoiding the need to modify system files which might trigger an alert for example bless one of the apps used to scroll through large text files it has a feature whereby you can type an exclamation mark followed by the name of any command and it'll run it here i've launched the id command to print details about the current user but this could just as easily be any other command such as spawning a new shell if a careless admin were to grant set your d permissions on less like so an attacker could easily use it to launch a new shell with root privileges right well sadly it's not quite that easy the set uid mechanism has been abused so badly over many years that modern systems come with some decent defenses by default all shells will check for a difference between the user id and effective user id and drop the additional effective permissions unless explicitly requested not to do so for the bash shell this involves using the dash p flag but despite re-running this attack with the relevant flag our attacker is again foiled and left with a low privileged shell examining the process listing explains why less les isn't directly running the command specified by the attacker but is instead encapsulating it in its own call to the s8 shell and as mentioned before most shells will drop privileges if not explicitly instructed so whilst less is running with its full root privileges it forces any commands that it spawns to return to lower privilege with no way of explicitly altering this behavior but not all binaries are quite so cautious the file searching tool find has a feature whereby it'll run a command whenever a matching file is found by specifying the exact parameter so if a system administrator has made the mistake of granting set uid permissions to find it can be abused to launch a new interactive shell and at the time of recording find does not drop its privileges nor encapsulate calls leaving an attacker with a fully privileged interactive shell it's not just ignorance admins who may set uid on dangerous files if an attacker has achieved root access via some other method they may use set uid on an otherwise innocent looking system binary as an easy back door for re-elevating their permissions at a later date here the attacker is granting set uid to python so far we've discussed set uid in the context of achieving root permissions but remember it always impersonates the owner of the program and that might not always be root these cases are not as powerful as full super user access but may still allow for a lot of other mischief such as accessing restricted data [Music] detecting the abuse of set uid is a little challenging given it's used in several genuine cases the linux audit in daemon audit d can lend a hand here although it must be configured ahead of time once installed it can be configured to record any instance of the exe cve system call which occurs when a new process is launched we want to specify that the audit event should occur every time this call finishes and that an event is only generated on the condition that the user id is a different value to the effective user id signifying impersonation of another user via set uid on 64-bit systems it's also necessary to specify two separate rules one first 64-bit and another for 32-bit system calls finally the dash k parameter sets a tag for these rules to make it easier to search for them in the logs set uid programs can still run although audit events are now generated these can be reviewed with ausearch specifying the name of the tag that we assigned to the rules note that the rules here will include occurrences which are desirable and part of normal system operation such as password and sudo so some filtering may be required you'll probably also want to ship these logs off to a seam for alerting and to protect against an attacker deleting locally stored logs once they achieve root privileges [Music] flagging up cases where set urd binaries have been run is good but it'd be even better to identify potentially dangerous configurations and eliminate them before they can be exploited by an attacker one method is to manually scan for set uid binaries using the same find command from earlier and investigate any item which is not part of the system's default and safe installation but the find command doesn't scale very well when you have lots of machines to assess a better option for larger environments is a tool such as os query which can pull back system configuration information from a large state quickly and easily a query named suidbin is included in the macpack which returns details of every set uid or set gid file contained within common binary locations note though it doesn't search the entire file system so as not to be too resource intensive the results table lists the machine name location of the binary whether the permissions are set uid or set gid and the user angry poners running os query on a periodic basis and manually assessing the results is good for hunting but ideally we'd like near instant notification of new set uid files again audit d has us covered this time we just need to trigger on one of the three flavors of chmod syscall to generate alerts whenever a file permission is changed adding the set uid bit to a binary now triggers an audit event note that the audit events include the original permissions in the familiar octal format in the mode field of the path message and the new permissions are in hex format in the a2 field of the syscall message we can further refine the audit configuration to only trigger on the addition of set uid and set gid permissions rather than any and all permission changes by applying the following bitmask filter on the a2 field but that about wraps up this video if you found it useful please do give it a like and consider subscribing if you want more of this sort of content drop a note in the comments if there's anything you think i missed around attacking detecting and defending against the abuse of set uid and set gid or if you have a good idea of what topic i should cover next i'll see you next time

Channel: Attack Detect Defend

Views: 12,016

Keywords:

Id: nj-dYB3D2dA

Length: 11min 43sec (703 seconds)

Published: Tue May 11 2021