The Arms Race: Attacks and Defense
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
- If all else fails, press the Reset button or turn the power off and back on.
<Escape>key as soon as you see the GRUB splash screen.
Akey 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
The list of parameters may be very
long. Just add
Sto the end!
Also, you may still have some mysterious
failures in single-user mode, because
of Security-Enhanced Linux policy enforcement.
In that case, add another boot parameter:
- The list of parameters may be very long. Just add
<Enter>to boot with that added parameter, asking for a boot to single-user mode.
Defense — Level 1
First, find where your system has its program
with this command:
# which sulogin
I would expect the answer to be
if that is not the case then change the path as needed
in the below.
Our goal is to force someone to type the
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
They will be asked for the
root password before
getting a shell.
They will be asked repeatedly until either they type the
root password or they lose patience and
<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
init or its Upstart or
the even newer SystemD replacement.
Look at your file
/etc/inittab and see if it contains
a line specifying the
If that file contains a line similar to this:
then you have traditional System 5
In this case,
leave that line alone and add a new line.
That will probably result in a new block looking like the
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
# System initialization si::sysinit:/etc/rc.d/rc.sysinit
If, instead, that file is mostly comments with just one
initdefault or even missing,
and you have a
/etc/init, then you have the newer
Upstart replacement for
In this case:
Modify the file
to change the line currently looking like this:
to instead look like this:
If there is no
This solution in
prevents the trivial exploit of booting
to single-user mode:
start on runlevel S stop on runlevel [!S] console owner script if [ -x /usr/share/recovery-mode/recovery-menu ]; then exec /usr/share/recovery-mode/recovery-menu else exec /sbin/sulogin fi end script [...]
Exploit — Level 2
The Linux kernel includes code to run
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
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.sysinithas 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 /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/mtababout 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 /
mountwith a pair of options —
remountmeans "Keep it mounted, just change the way that it's mounted", and
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.
# cat /etc/fstab
Mount other needed file systems. If
/usris 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
You well need to also do this manually.
So, run the
synccommand 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
umountthe 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.
Defense — 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:
Follow the directions.
In another terminal emulator, start to edit the GRUB
This will be in the directory
/boot/gruband named either
Add a new line, directly below the
timeoutline, 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 ...
password --md5 5f3782baec534bae412c27fc0850fc6d
... 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
Pto 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,
suto become root, and mount the file systems as needed.
Defense — Level 3
- Reboot the system and go into the firmware. Disable booting from anything other than the main disk.
- Set a firmware password, so you cannot change the firmware settings without first typing that password.
Exploit — Level 4
Open the case, remove the battery from the motherboard, and wait a few minutes for the firmware to forget its settings. Reassemble, set the firmware to suit your needs, and boot from your media.
Defense — 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, I have to stop this somewhere!
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.