BREAK INTO LINUX AND HOW TO PREVENT IT

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:

1. 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.
2. Press the <Escape> key as soon as you see the GRUB splash screen.
3. Press the A key to modify (add to) the kernel parameters.
4. 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
5. 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: 

• /etc/sysconfig/init exists (Red Hat / CentOS)
  Modify the file /etc/sysconfig/init to change the line currently looking like this:
  

  SINGLE=/sbin/sushell

  to instead look like this: SINGLE=/sbin/sulogin
• There is no /etc/sysconfig/init (Ubuntu)
  The Ubuntu solution in /etc/init/rcS.conf already 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 /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!

1. 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.
2. 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.
3. 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".
4. 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.
5. Do whatever nefarious things you want.
6. 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.
7. 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.

1. In one terminal emulator, run this command:
   # grub-md5-crypt
   Follow the directions.
2. 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.
3. 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 ...
4. 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
   
5. 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:

1.  Boot the system from a Knoppix live CD.
2.  Once it boots, get a terminal emulator, type su to become root, and mount the file systems as needed. 

DEFENCE LEVEL 3:

1. Reboot the system and go into the BIOS. Disable booting from anything other than the main disk.
2. 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.