On September 16th a Redhat Linux
6.2 honeypot was compromised. This is the 3rd time this system was compromised
by the same intruder. The honeynet is VMware based and uses a modified bash to
log to syslog. Syslog is remotely logging to 0.0.0.0 (remote syslog server IP
has been replaced). The compromised system has an IP of 192.168.1.102. After
successfully breaking into the box, the attacker ended up using 3 modes of
connecting and running commands (some of which is encrypted). The attacker also
tried to hide some of his edits from the MAC times.
After downloading the snort binary
capture, I verified the md5 checksum and performed an analysis of the captured
data, using Ethereal v0.8.14 and common Linux programs.
Which vulnerability did the intruder exploit?
I discovered that an attempt was made to exploit the FTP daemon running on the honeypot machine by following the TCP data stream from the connection made to the target from IP address 207.35.251.172. The vulnerability that was exploited was the SITE EXEC WU-FTPD 2.6 exploit. A brief overview:
By passing character format strings consisting of printf conversion characters (%f, %p, %n, etc) while executing a "site exec" command, the ftp daemon can execute arbitrary code as root. This vulnerability is discussed in greater detail at the following sites:
http://ciac.llnl.gov/ciac/bulletins/k-054.shtml
http://www.kb.cert.org/vuls/id/29823
http://www.redhat.com/support/errata/RHSA-2000-039-02.html
http://www.securityfocus.com/bid/1387
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-0573
http://www.cert.org/advisories/CA-2000-13.html
By reviewing
timestamps, the type of vulnerability exploited, and the tools that were
downloaded, I determined that this process was automated, and is more clearly
described in the cert.org advisory:
http://www.cert.org/incident_notes/IN-2000-10.html
For additional
reference, the saved stream of the SITE EXEC
WU-FTPD exploit as performed on the honeypot machine is listed in the
appendix. The attacker performed this
FTP exploit against the machine on 9/16/01, at 19:55.
What ways, and in what order, did the intruder use to connect and run commands on the system?
How did the intruder try to hide his edits from the MAC times?
Through carefully analyzing
the snort data, I discovered unsuccessful attempts to connect to the honeypot
machine via telnet, and attempts on port 24 and 6666 just prior to the
execution of the SITE EXEC exploit, from IP address 217.156.93.166. Closer
inspection of the telnet connection shows an attempt to connect to the honeypot
machine as the user nobody. The “nobody”
account logging in to a FTP server would be a telltale indication of
unauthorized activity. This suspicious activity by IP address 217.156.93.166 started at 19:52, and ended at 19:54, less than a
minute before the FTPD exploit was initiated from IP address 207.35.251.172. Our attacker is apparently working from both IP
addresses.
Once root access via the
FTP exploit from IP Address 207.35.251.172 was obtained, the attacker then proceeded to use the shell granted by
the exploit to conduct the following:
·
Checked his privilege,
looked for other users on the machine, moved about on the machine traversing
several directories, then settled on abusing the /etc/X11/applnk/Internet
directory to begin his penetration work.
·
created an .etc and an
.etcpasswd file and used the touch command to sync access times from the /etc
directory and the /etc/passwd file accordingly.
·
He then deleted the
password for the nobody account, and created a dns account as root, removed
that password and then re-touched his .etc and .etcpasswd files to hide the
activity
·
Finally he did a “cat”
on the /etc/passwd file to review his handy work. He finished this work at 20:26.
The log file of this activity is included in the appendices.
·
Once the accounts were
setup, at 20:32 our attacker logged into the honeypot machine via telnet, using
the nobody account. Then he “su’ed” to
his dns account with root privileges, and performed the following:
·
Attempted to run
Midnight Commander to navigate directories and/or transfer files, but that
failed.
·
Initiated a FTP session (as listed in the appendix) with
teleport.go.ro. (193.231.236.42; also
resolves to s1.go.ro) and downloaded the following into the sdc0 directory which he created in the /dev/rd directory:
·
The downloading of the
apparent rootkits finished at 20:43.
·
The next step was to unpack
the rootkits and execute.
·
Port scans the machine
to look for open ports that the rootkit should have created.
The intruder downloaded
rootkits, what were they called? Are they new/custom rootkits?
Recover (tell how you did it too) the rootkits from the snort binary capture
What does the rootkit do to hide the presence of the attacker on the system?
I used Ethereal v0.8.14
to analyze the binary snort capture, and in doing so located the data channel
for each file transfer of the above compressed files. I then followed each separate TCP data stream and saved the files
to my system. I unzipped and un-tarred
the Zer0, copy, and ooty
downloads to continue my analysis (files can be found in the appendix).
The Zer0 rootkit, upon
further examination, appears to be the t0rn rootkit, according to references in
the Go install script, and
various directories that are created by un-tarring the various packages. This
rootkit has been modified somewhat, as the names of the processes running are
different than the traditional t0rn rootkit, as evidenced in the adore.h file, and references to the programs in the Go script. By
reviewing the references in the adore header file, ports to look for running on
the system are 24, 666, 443, and 60000.The Zer0/t0rn rootkit is fairly
competent at hiding its presence. All references within the Go script point towards t0rn, and from my review of
the script, sets up a secure shell daemon (moved during the install from
sharsed to nscdx), modifies several system binaries, and installs a log cleaner
called vrssb, and sniffer named vrssnf, along with loading kernel modules to
hide processes. I included the Go script in the appendix. A brief summary of
what the rootkit does to the system:
·
Checks for a previous
rootkit installation, then checks if logging and remote logging are running.
·
Sets up files to hide
timestamps with the touch –acmr command to /bin, /usr/X11R6/bin,
/etc/rc.d/rc3.d
·
Sets up the following
directories: /usr/X11R6/lib/X11/.~/, /usr/X11R6/bin.,/copy/adr/, /dev/rd/sdc0,
/usr/info/.t0rn/
·
Moves and unpackages
the trojans, sets up a secure shell, and defaults to 6666 if no ports are
specified in the installation
·
Modifies rc3.d inet
startup script, then verifies that make and gcc are present; if not will
download them
·
Installs loadable
modules to hide processes
·
Installs a sniffer,
hides various running processes
·
Appends a file called
mail with crucial system data and emails it to hatcheryhatched@hotmail.com
·
Removes the files used
to create the rootkit.
A complete analysis on the t0rn rootkit can
be found at:
http://www.incidents.org/protect/t0rn.php
The ooty file contains files for a local exploits, including
a perl suid exploit. The copy file
contains his WU FTP exploit and some other tools, including the smurf denial of
service exploit, and some others related to automating the exploit process and
enumerating vulnerable targets.
Following the successful
download and execution of the rootkit and associated programs, the attacker
then makes a connection to port 24 at 20:51 from IP address 217.156.93.166. Streaming
this connection reveals that it’s encrypted, and the connection is to SSH-1.5-1.2.27
via an SSH-1.5-PuTTY client. From this
point on, the snort log is encrypted by secure shell. The initial secure shell connection ends at 21:06, and is
immediately re-established at 21:07.
This is the end of the snort packet analysis.
While reviewing the
syslog file, I was able to verify the execution of the Go script, and
identified two separate processes that identify the secure shell
connection. I found this data using
“strings”, “grep”, “cat” and “awk” to weed out the critical information:
What did you learn from this exercise?
How long did this challenge take you?
As the challenge stated, the attacker had become real friendly with this IP from previous attacks, and was counting on this box already being rooted, as I noticed from his initial attempts to connect to port 6666, which according to the rootkit script, is the secure shell default. With the data gathered, I was able to understand his methods and track his movements between two different IP addresses. This attack seems to be part of a mass automated process that has multiple users all using the s1.go.ro FTP server to propagate rootkit attacks from as the many machines they compromise. Further research pointed me to the same references the previous scan of the month challenge submitters researched as the origination point being somewhere in Romania, or at least the attacker having some familiarity with that language. As for lessons learned, I became more accustomed to using Ethereal to parse snort logs, and recreating and analyzing data from TCP streams. I have also learned detailed information about the t0rn rootkit and this Zer0 variant. I spent about 8 hours digging into the binary data, reviewing the rootkits, and reading some web information on the rootkits, and another 4-6 hours or so compiling notes and polishing up the report. I worked on this in my spare time during the week, so I wasn’t counting the minutes spent on this effort.
Attachment 1 ftpexploit.txt – Logfile of the SITE EXEC
exploit attempt and activity
Attachment 2 goscript.txt – The Zer0/t0rn install script
Attachment 3 rootkitftp.txt – FTP session between the honeypot
and the attackers ftp server
Attachment 4 adore.h – Customized Zer0/t0rn header file
Attachment 5 Bonus Letter – Letter to the owner of a
compromised system
Attachment 6 Zer0.tar.gz – Downloaded rootkit
Attachment 7 copy.tar.gz – Downloaded toolkit, WU FTP exploits
Attachment 8 ooty.tar.gz - Downloaded local Linux exploits
Based on this challenge, write an example letter of notification to the source owner that attacked the system. Include any evidence or logs that you feel important.
See attachment 5
http://www.heatscanner.com - shameless plug