How To Break Into Linux
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.
The following simple exploit works against most Linux systems, but not Ubuntu as explained in the following defensive section:
<Escape>key as soon as you see the GRUB splash screen.
Akey to modify (add to) the kernel parameters.
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
Sto the end!
<Enter>to boot with that added parameter, asking for a boot to single-user mode.
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 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 (Red Hat and CentOS)
or even missing (Ubuntu), and you have a
/etc/init, then you have the newer
Upstart replacement for
In this case:
/etc/sysconfig/initexists (Red Hat / CentOS)
/etc/sysconfig/initto change the line currently looking like this:
/etc/init/rcS.confalready prevents the trivial exploit of booting to single-user mode:
start on runlevel S
stop on runlevel [!S]
if [ -x /usr/share/recovery-mode/recovery-menu ]; then
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!
kernel=/vmlinuz-<version> [...parameters...] init=/bin/bash
/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
/etc/mtababout the situation immediately before the previous shutdown.
# mount -o remount,rw /
mountwith a pair of options —
remountmeans "Keep it mounted, just change the way that it's mounted", and
# cat /etc/fstab
/usris another file system, you will probably need to mount it.
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.
<Ctrl><Alt><Del>or the power switch.
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.
/boot/gruband named either
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 ...
mumble. So change the permission on that file:
# chmod 600 /boot/grub/menu.lst
# chmod 600 /boot/grub/grub.conf
Pto GRUB to enter the password, and only then will it let you edit the boot parameters.
suto become root, and mount the file systems as needed.
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.
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.
That alarm needs to get its electrical power from 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.