4

It is a production server - CentOS 6.1

Some user having root access in the past had logged on to the server and removed the SUID bit from the /bin/su file and then exited root. Now we are not able to switch back to root. Also ssh access for root is disabled on the server, so root directly cannot login to the machine. Since we are nor able to su to root nor able to ssh as root we can't set the suid bit for the /bin/su file back.(Also we are not able to switch between users using su)

How it should had been:

$ ll /bin/su
-rwsr-xr-x. 1 root root 30092 Mar 10  2011 /bin/su

How it is right now:

$ ll /bin/su
-rwxr-xr-x. 1 root root 30092 Mar 10  2011 /bin/su

Is there any way we can switch back to root or set the SUID bit in any way?

Note: We want to avoid a reboot no networking usermode because the server is in use 24x7 and getting downtime is a bit difficult. If reboot was possible then we could simply login using single user mode as root and reset that bit.

Feel free to give creative answers. I can test your answers on our test environment.

|improve this question
  • Do you have root's password? Is ssh enabled? ssh root@localhost then chmod. – Robert Jacobs Mar 9 '15 at 20:28
  • yes i have root password .. but ssh login is disabled for root. we can only su to root .. my now su is decfected... – Aditya Pednekar Mar 9 '15 at 20:31
  • 1
    Can you log in from the console? Doesn't require su. – Robert Jacobs Mar 9 '15 at 20:35
  • 2
    Does the machine mount any shares on from another machine. If so, you can copy su from your machine to a share that it is mounting, go the the file server and chmod the new su. Then run it. – Robert Jacobs Mar 9 '15 at 20:38
  • 1
    Is there a serial port on the machine? If you can attach a terminal or equivalent to it. If /etc/securetty has not been modified to disallow root access, you are in. – Robert Jacobs Mar 9 '15 at 20:44
1

Some options:

  • sudo -i, that's the most obvious alternative.
  • sudo -l then look for a command that you are allowed to use that you could use to solve the problem, like : editing a file executed by root, like crontab, logrotate, executon yum/rpm...
  • go to the console, and connect as root (only ssh is restricted if I understood)
  • open a graphical session, some distribution have tools to become root that don't rely on sudo. Also, many of them have some update manager .. Maybe you can reinstall the package which provides su
  • if you have a configuration management tool like puppet/chef/ansible/fai... Push the configuration!
  • investigate your crontab to see if you can edit a file to escalade.
  • if your server is connected to a central authentication system (especially LDAP/nis), create an account with high permission (group wheel, or user uid=0).
  • if it's a virtual server, shut it down, then mount and edit the filesystem.

Some silver bullets:

  • reboot your server in single user mode (red hat) or specify init=/bin/sh (Debian and rhel/CentOS 7), then fix the permission.
  • reboot the server in a CD/DVD/USB/NetBoot and use the recovery (or just mount and edit)

And some really ugly:

  • find a vulnerability in you system to compromise it!

If your sysadmin did a good job, a regular user can't do any of those things (but you are the sys admin)

|improve this answer
  • Found a backdoor.. fixed the SUID and then fixed the backdoor .. :D – Aditya Pednekar Mar 15 '15 at 6:47
1

Assuming you're in a group that allows you to sudo, then:

sudo -i

will give you root access and allow you to repair /bin/su. Remember that you use your user's password with sudo - not root's password.

|improve this answer
  • i tried sudo without the -i option n it didnt work. i think sudo uses su in background(not sure though) haven't tried it with the -i option. this will be the first thing i'll try when i reach office tomorrow. wasted my entire day today with this issue... o'll get back to u on this one .. :) – Aditya Pednekar Mar 9 '15 at 20:03
  • sudo doesn't use su to do it's work for it. However, on most distros the user must be in a specific group. Of course, if the users isn't in that group then you're stuck as you need root permissions to add a user to any group. Good luck. – garethTheRed Mar 9 '15 at 20:06
  • "user must be in specific group" ? wht did u mean by tht ? Can u elobarate a sentence on this line. May b this was the reason sudo wasnt working today .. the user with whom i was trying was in the sudoers list. But did not had any secondary groups .. – Aditya Pednekar Mar 9 '15 at 20:12
  • Of course, this presupposes that the … erm … helpful person didn't remove the set-UID bit from /usr/bin/sudo as well. ☺ – JdeBP Mar 9 '15 at 20:39
  • 1
    On Debian based systems you need to be in the sudo group to use sudo. On RedHat based systems you need to be in the wheel group. Of course, an individual user can be added to the sudoers file, but it's usual practice to add a group to this file (this is normally already done by the distro) and then add users to the group. – garethTheRed Mar 9 '15 at 21:39
1

The question implies SSH (or equivalent) as the only access. The only way generally to get from a user privileged process to a root privileged is via su, sudo, or another site local alternative. If you don't have one then you are hopefully out of luck as the presence of an alternative suggests a security hole of some sort.

That said, the suggestion of rebooting to gain access suggests console access is available in some form. Generally root can login directly on the console and would be the first thing to try (perhaps remotely with IPMI or an IP KVM?). Both the graphical console and the serial ports are worth trying.

An alternative is to look for an external file system which either is mounted or can be mounted and allows a static setuid su binary to be presented for your user to run.

If there is a config-management system in place (puppet, chef, etc.) then it may be still running and be usable to fix or update the binaries.

If the running system is a virtual machine you may have access to it in some form from the host environment. (Conversely if it's a host machine you may be able to exploit root access on a virtual machine to gain control)

After that, first evaluate how much time it's worth spending on re-gaining access to the system without doing the re-boot. Then if the time is justified it's a matter of looking at what you do have access to. Look at each of these and evaluate them for the ability to either fix the set-uid bit or otherwise run a relatively arbitrary command:

  • Every set-uid binary on the system accessible to your user
  • Every process running as the root user (looking at intended uses)
  • The underlying storage system and alternate access to it
  • Every process running as the root user (looking for unpatched local code execution vulnerabilities)
  • The kernel version (looking for unpatched code execution vulnerabilities)

At some point in there it actually becomes a security audit.

|improve this answer
0

Also you can use this command :

sudo -s

It will give you root access

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.