This page shows you how to break in as
root on a
Linux console, and then how to defend against this.
As you will see below, it's an arms race — back and
forth between exploit and defense.
It's up to you to decide how far to take this.
But without physical security,
you cannot have information security.
The following assumes that the target system has the standard
GRUB boot loader configuration.
EXPLOIT LEVEL 1:
The following simple exploit works against most Linux systems,
but not Ubuntu as explained in the following defensive section:
-
Reboot the system.
-
If are looking at a graphical login screen,
use any shutdown/reboot menu to start this
cleanly.
-
If that is not available, switch to a text
console with
<Ctrl><Alt><Del>.
-
If all else fails, press the Reset button
or turn the power off and back on.
-
Press the
<Escape> key as soon as
you see the GRUB splash screen.
-
Press the
A key to modify (add to) the
kernel parameters.
-
Add a space and the letter
S, either
lower-case or upper-case, to the end of the line
of kernel parameters.
The line will look something like the following,
with your addition highlighted:
kernel=/vmlinuz-version
ro root=LABEL=/
other-parameters
S
-
If you have recent Red Hat (CentOS, etc),
the list of parameters will be very
long. Just add
S to the end!
-
Also, if you are not able to do everything
you want when you get it, that may be because
of Security-Enhanced Linux policy enforcement.
In that case (e.g., Red Hat Enterprise Linux 6),
add another boot parameter:
enforcing=0
-
Press
<Enter> to boot with that
added parameter, asking for a boot to single-user mode.
DEFENCE LEVEL 1:
First, find where your system has its program
sulogin
with this command:
# which sulogin
I would expect the answer to be
/sbin/sulogin, but
if that is not the case then change the path as needed
in the below.
Our goal is to force someone to type the
root password
before getting a shell when they try the above exploit of
booting to single-user mode.
This is done by requiring
sulogin to get into
single-user mode.
They will be asked for the
root password before
getting a shell.
They will be asked repeatedly until either they type the
correct
root password or they lose patience and
type
<Ctrl-D> and the system comes up to
its default run state with its login prompt.
However, the fix depends on whether you are running
traditional
init or its Upstart replacement.
Look at your file
/etc/inittab and see if it contains
a line specifying the
sysinit action.
If that file contains a line similar to this:
si::sysinit:/etc/rc.d/rc.sysinit
then you have traditional System 5
init.
In this case,
leave that line alone and add a new line.
That will probably result in a new block looking like the
following.
Don't worry if the sysinit line does not look
precisely as it does below, leave that line alone.
The important thing is to add the
highlighted
new line:
# System initialization
si::sysinit:/etc/rc.d/rc.sysinit
ss:S:respawn:/sbin/sulogin
If, instead, that file is mostly comments with just one
line specifying initdefault (Red Hat and CentOS)
or even missing (Ubuntu), and you have a
directory /etc/init, then you have the newer
Upstart replacement for init.
In this case:
EXPLOIT LEVEL 2:
/sbin/init
once it has found and mounted the root file system.
The above defense works by telling init to impose
a special rule before entering run level 1.
So simply tell the kernel to run something else instead
of init, something that won't impose that rule
and will still be useful to the attack.
Something like a shell!
-
Start this exploit as above, rebooting and getting
into the boot loader.
Add something different and slightly more complicated
to the kernel line:
kernel=/vmlinuz-<version> [...parameters...] init=/bin/bash
The kernel will detect the hardware and immediately
drop you into a shell.
You are in a strange state because the system
initialization script /etc/rc.d/rc.sysinit
has not been run.
You probably cannot run it cleanly on its own as
it expects to be run from init, so you
will need to continue with some manual steps to
get the system somewhat more useful.
-
Mount the
/proc file system:
# mount /proc
You will see an error message complaining that it
was already mounted.
Ignore this, it is incorrect.
It is based on stale information in /etc/mtab
about the situation immediately before the previous
shutdown.
-
Remount the root file system in read-write mode.
You cannot unmount it and then mount it back up again.
Well, you certainly can unmount it.
But now that you have kicked the ladder out from under
your own feet, you may not be able to remount it!
Do it this way:
# mount -o remount,rw /
That calls mount with a pair of options —
remount means "Keep it mounted, just change
the way that it's mounted", and rw means
"read-write".
-
Depending on what you want to accomplish and how the
target's file system is laid out, you may need to
mount some other file systems.
Investigate:
# cat /etc/fstab
Mount other needed file systems.
If /usr is another file system, you will
probably need to mount it.
-
Do whatever nefarious things you want.
-
You will not be able to shut the system down in the
normal way.
You well need to also do this manually.
So, run the
sync command a few times to both
ask the kernel to flush any disk I/O out to the
hardware and to salute UNIX tradition, and then
umount the mounted file systems in reverse
order.
-
Once the file systems are all unmounted, you can
reboot with either
<Ctrl><Alt><Del>
or the power switch.
DEFENCE LEVEL 2:
The problem so far is that the attacker is typing things to
the boot loader.
So, we need to tell the boot loader to not allow that
unless they know a boot loader password.
-
In one terminal emulator, run this command:
# grub-md5-crypt
Follow the directions.
-
In another terminal emulator, start to edit the GRUB
configuration file.
This will be in the directory
/boot/grub and
named either menu.lst or grub.conf.
-
Add a new line, directly below the
timeout
line, resulting in something like the following,
with your addition highlighted.
Of course, you need to use the hash value resulting
from your password.
Since this must be correct, copy and paste
from that other terminal emulator makes sense:
# ... comments above ...
default=0
timeout=5
password --md5 5f3782baec534bae412c27fc0850fc6d
spashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
... and so on ...
-
Now an attacker with an unprivileged foothold on your
system could see that hash, go run an automated attack
using a bunch of guesses, and discover that your GRUB
password is the dictionary word
mumble.
So change the permission on that file:
# chmod 600 /boot/grub/menu.lst
— or —
# chmod 600 /boot/grub/grub.conf
-
Now, to legitimately break into your own machine,
you must first press
P to GRUB to enter
the password, and only then will it let you
edit the boot parameters.
EXPLOIT LEVEL 3:
- Boot the system from a
Knoppix live CD.
- Once it boots, get a terminal emulator,
type
su to become root,
and mount the file systems as needed.
DEFENCE LEVEL 3:
-
Reboot the system and go into the BIOS.
Disable booting from anything other than the main disk.
-
Set a BIOS password, so you cannot change the BIOS
settings without first typing that BIOS password.
EXPLOIT LEVEL 4:
Open the case, remove the battery from the motherboard,
and wait a few minutes for the BIOS to forget its settings.
Reassemble, set the BIOS to suit your needs, and boot
from your media.
DEFENCE LEVEL 4:
Install alarms in the cases of all systems storing sensitive
information or serving sensitive roles.
Anyone opening the case without the proper key will set off
an alarm that sounds like the fire alarm.
EXPLOIT LEVEL 5:
That alarm needs to get its electrical power from somewhere....
OK THE SECURITY IS JUST LIKE
"EVERY QUESTION HAS AN ANSWER OR EVERY PROBLEM HAS A SOLUTION"
Hopefully you have gotten the point —
Security is not one simple thing,
it tends to be some form of an arms race.
It certainly isn't perfect, and you need to understand the
implications of any assumptions you make, even the unspoken
or even unknown ones caused by saying "This is far enough."
And hopefully you got the other point —
Without physical security,
you cannot have information security.
The thing is, it seems that you can always come up with
some way to work around any defense.
