This page shows you how to break in as
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:
First, find where your system has its program
I would expect the answer to be
Our goal is to force someone to type the
However, the fix depends on whether you are running traditional
Look at your file
then you have traditional System 5
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.
EXPLOIT LEVEL 3:
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.
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....
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.
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
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
-
If you have recent Red Hat (CentOS, etc),
the list of parameters will be very
long. Just add
Sto 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
-
If you have recent Red Hat (CentOS, etc),
the list of parameters will be very
long. Just add
-
Press
<Enter>to boot with that added parameter, asking for a boot to single-user mode.
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: -
/etc/sysconfig/initexists (Red Hat / CentOS)
Modify the file/etc/sysconfig/initto change the line currently looking like this:
to instead look like this:SINGLE=/sbin/sushellSINGLE=/sbin/sulogin -
There is no
/etc/sysconfig/init(Ubuntu)
The Ubuntu solution in/etc/init/rcS.confalready 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: /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.sysinithas not been run. You probably cannot run it cleanly on its own as it expects to be run frominit, so you will need to continue with some manual steps to get the system somewhat more useful. -
Mount the
/procfile 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/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 /
That callsmountwith a pair of options —remountmeans "Keep it mounted, just change the way that it's mounted", andrwmeans "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/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
normal way.
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 thenumountthe 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.
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/gruband named eithermenu.lstorgrub.conf. -
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 ...
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
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,
type
suto become root, and mount the file systems as needed.
- 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.
