cancel
Showing results for 
Search instead for 
Did you mean: 
Trevor
Commander Commander
Commander
  • 420 Views

Privilege Escalation Techniques

Some typical techniques used for privilege escalaton in Linux are:

  • Kernel exploits
  • sudo abuse
  • Special file permission abuse - setuid and setgid
  • weak file permissions - possibly due to misconfiguration
  • cron jobs
  • poor passwords   (why are passwords still being used, only to be abused)


If you know of other techniques, I certainly would welcome you adding to
my list.  After all, I did specify that the items in my list are "typical"!

Thanks in advance!

 

Trevor "Red Hat Evangelist" Chandler
Labels (3)
4 Replies
Travis
Moderator
Moderator
  • 382 Views

@Trevor -

So this one I'm not quite sure about, but from the way it is phrased and your examples, it is showing ways to "abuse" access, not just methods of elevation.

You are correct in the many ways things are being abused, but you left out "su" of switching of users. Again, this requires a password and the easiest thing to do is hack passwords and we all know the root is on all systems. You also left out things such as rogue SystemD services and proceses. If something breaks out there, you could potentially have issues with processes running at a root-level that shouldn't.

So I'm guessing you might also be wondering how do we mitigate issues from abuse with privilege elevation ...

  • Disable root account login with password completely (can't abuse password that doesn't exist)
  • Leverage SELinux users
    • Use SELinux users that restrict the users that have ability to SUDO. If you don't know what this does, it requires users to have a special SELinux user flag attached to their account so they need to have SELinux user set properly (because if it isn't even if they have full SUDO privileges they can't run SUDO).
  • For passwords, we can use 2FA and tokens for additional elveated security along with PAM settings to help and assist more 
  • Use SELinux "jails" around processes to ensure that network ports, and filesystem have labels that are required preventing rogue services from having full system-level access.
Travis Michette, RHCA XIII
https://rhtapps.redhat.com/verify?certId=111-134-086
SENIOR TECHNICAL INSTRUCTOR / CERTIFIED INSTRUCTOR AND EXAMINER
Red Hat Certification + Training
Trevor
Commander Commander
Commander
  • 165 Views

Travis, you hit the nail on the head, even when my query
is fuzzy!!!

Thank you good sir!!!

Trevor "Red Hat Evangelist" Chandler
Chetan_Tiwary_
Community Manager
Community Manager
  • 343 Views

@Trevor quite a comprehensive list of typical privilege "exploitiation". 

Another ones could be ( but not limited to

1. world writable /tmp or insecure NFS mounts

2. srvices running as root with vulnerabilities.

3. PATH or env variable hijacking.

4. Container escape ( container related misconfigurations ).

5. Forgotten credentials, hard-coded passwords or exposed config files/keys.

6. Bugs in app/software.

7. Orphaned user accounts or obsolete service accounts. 

Ad_astra
Flight Engineer Flight Engineer
Flight Engineer
  • 116 Views

@Trevor Just to add a few more areas for consideration...

1) Web Shells

Linux servers often run Apache, Nginx or other web servers. If a script on a web server does not sanitize or check the inputs, an attacker could use an exploit or bug in the software to execute commands on the server. This could include gaining access to a web shell and attempting privilege escalation.

2) Database command injection

Running a database service on a Linux server can leave it open to attack via command injection. If a database service allows user input to run without validation, an attacker may be able to run commands on the server. SQL injection attacks are a known method of attacking databases and web based database services. 

3) Linux kernel modules

Allowing untested or unverified kernel modules to run on a server is another area to consider when audting a system. As with all modular software (kernel modules, webserver plugins, etc), only trusted or proven software should be used to minimise a potential exploit or attack on a system.

4) The atd daemon

In addition to the cron daemon, the atd daemon could be used to schedule commands by an attacker. Whilst atd is usually set to run jobs just once, at jobs can be set to reschedule themselves to run repeatedly.

Join the discussion
You must log in to join this conversation.