…after the death of the admin was more or less the title of a thread I read a while ago in reddit. The thread was about this one guy being the admin of his houses machines and would would happen to the data on them if he suddenly died.
Besides the question of how to recover the password of a local machine this in my community spawned also discussion on how would one distribute for example his email password to someone else if he died. Email in particular would be a resource that would be valuable to have an access to after its primary user is gone, to shut down it and other services linked to it, if for nothing else. (Turns out there are services for distributing your passwords [for example deadmansswitch], if you trust them enough.)
Anyway, this post is about recovering root password in case you forgot it or happen to acquire dead man’s laptop or whatever. I have collected here four different ways to possibly gain root access to the machine without relying on any software exploits, some of them more convenient than others. After you have a root (or in some cases just write) access to the disk, you can go and edit /etc/shadow manually, or change it with passwd.
Note that all these rely on the fact that the media the target system is on is unencrypted. If the disk is encrypted and you don’t have the password, getting the data out is pretty much a lost cause.
Runlevel 1
Probably the easiest way to go about this is booting straight to runlevel one. It is a single user mode for admin tasks. Booting a linux kernel to runlevel one is as easy as appending “1″ (without the quotes) to your kernel parameters in your bootloader.
This method is very easy to do, but in practice it has a couple of “defects”. Defects as in security measures involved. Firstly, on some systems booting the kernel in to runlevel one doesn’t drop you immediately to a root console, but instead prompts you for the root password which makes this approach a dead-end. This is the case in for example my Arch Linux install.
The second problem can be giving the kernel the “1″ -option. If the bootloader is locked for editing you simply can’t hand it to the kernel and the system will boot up as it always does. In this case the only way to edit the boot menu you’d need to log in as root and then edit the menu… which again puts us to a dead-end.
init=/bin/bash
Trying this method out is pretty similar to runlevel one trick above, but circumvents the first problem in it. Adding init=/bin/bash (or init=/bin/sh or whatever) to the kernel options in you bootloader instructs the kernel to run the specified command first, instead of the usual /sbin/init. This drops you straight into a root shell, and you should see your filesystem just fine. One thing to note here is that the filesystem is now mounted as read only, so to change the root password you first need to remount the fs with read/write access:
mount -o remount,rw /
You are now ready to modify /etc/shadow. As you can see, this too relies on being able to edit the kernel options in your boot loader, which can potentially render this method useless.
Booting a live-cd
Pretty trivial, eh? Insert the media containing the live os, boot it, mount the disk in the machine and edit it accordingly. But! For this to work you need to be able to select the first boot device. If the order is set and BIOS is password protected, you have a minor bump on the road. “Fortunately” as this method already assumes physical access you can open the case and remove the BIOS battery. This should reset the BIOS and you are free to edit it again!
Taking the disk out and modifying it on another system
The title says it all. Since we already have access to the machine physically, and don’t want to bother ourselves with downloading live systems and burning CDs, simply:
- take out the disk
- plug it in your own machine
- boot the system normally
- mount the foreign disk
- edit disk accordingly
What can we learn from all this from security’s point of view?
We can turn this whole scene upside down, and take a look at what measures you could take to prevent someone from gaining root access to you box.
The first two methods relied on being able to modify the kernel boot parameters. There’s a simple solution for that: lock it from modifying. There almost certainly is an option for that somewhere in the configs.
The first one also relied on being able to enter runlevel 1 without prompting the root password. In Arch asking for password is achieved by having “su:S:wait:/sbin/sulogin -p” in /etc/inittab, but I don’t dare even try giving a general instructions on how you should do this. Consult your OS manual or so ;) Besides, locking the boot loader prevents also entering to runlevel 1 in the first place so this isn’t an issue, and not locking it still makes it possible to use the init=/bin/bash -parameter instead of this.
Now that the bootloader is secure, let’s move on to BIOS. Set a password for it, and see that the first device the machine looks for something bootable isn’t a removable media like a cd-device or USB port. Some BIOS’ have a function for selecting the bootable device just for that time, by hitting some key before POSTing. Disable this, too.
All in all: physical access is a bitch. If you have a machine you want to keep safe? Don’t let anyone near it. All the tricks above rely on getting physical access to the machine. If your disk is not encrypted and someone gets close enough to touch your machine there’s nothing that will protect your data from being compromised.
So as the last point: encrypt the disks on machines that other people might get to. Laptops are prone to stealing and it would be a child’s play to get your data from there if the disks are unencrypted.