From China with Love? (Part 1)

After a long hiatus from blogging, I have finally returned. To be honest, I just haven't had the time for it, but I've recently had some fun stuff going on that I wanted to write about.

As you may know, I am quite interested in both malware and honeypots. I've run Linux SSH honeypots in the past and recently started one up again. Within a few days, I started seeing a repeat visitor who tried to change the settings of the system as well as downloading one file per visit.

Based on viewing the logs "replayed", it looks like the attacks on my honeypot are automated. There are no typos or other signs of actual human interaction. In all cases, the attacking IP address and the IP address from which files were downloaded were based in China (shock!). All the downloaded files were of the Executable and Linkable Format (ELF) type.

The IP address I have seen these attacks coming from is 60.169.77.233. The whois data for this IP is:

inetnum:        60.166.0.0 - 60.175.255.255
netname:        CHINANET-AH
descr:          CHINANET anhui province network
descr:          China Telecom
descr:          A12,Xin-Jie-Kou-Wai Street
descr:          Beijing 100088
country:        CN
admin-c:        CH93-AP
tech-c:         JW89-AP
mnt-by:         APNIC-HM
mnt-routes:     MAINT-CHINANET-AH
mnt-lower:      MAINT-CHINANET-AH
status:         ALLOCATED PORTABLE
changed:        hm-changed@apnic.net 20040721
source:         APNIC

There is one other IP that has conducted an almost identical attack and it too was of Chinese origin.

I am including a video recording below of one of the log replays. Below that, I'll talk about what the attacker was trying to accomplish with each command. One note: I am not even close to being an expert on Linux or on attacks. If you see that I am wrong about something I post here, please let me know. I love to learn and will be happy to be corrected.

 

 First, we see the intruder is logged into the "sales" computer. The first act is the intruder updating the /tmp/resolv.conf file to include the free Google DNS server at IP address 8.8.8.8. I'm not familiar with all the various flavors of Linux out there, but I believe resolv.conf in most systems I've been around has been in /etc, not /tmp. I would welcome information on why/when it would be in /tmp.

Next, our visitor starts issuing various commands to shut down iptables and/SuSEfirewall.  In all  cases, the honeypot doesn't know anything about firewalls, so it simply replies "command not found".

The next act of our visitor is to download a file called ".bash_root.tmp3" to the /tmp directory. Notice the dot (or period if you prefer) at the beginning of the file name. The dot makes the file a "hidden file" that you won't see simply by running the ls command to list the directory contents. Running ls -a, however, will show it. I must assume this our visitor's way of trying to make finding his file just a little harder, though it isn't especially hard to find if performing a forensic examination of the victim computer. In the actual honeypot, the file didn't download. The system returned an "unsupported scheme" error when the intruder tried to download the file. I suspect, but haven't confirmed that this is because they were trying to download and save it as a hidden file.

Notice the IP address the file is downloaded from: 112.117.223.10. This IP is also based in China. The whois data for this IP is: 

 

inetnum:        112.116.0.0 - 112.117.255.255
netname:        CHINANET-YN
descr:          CHINANET YUNNAN PROVINCE NETWORK
descr:          China Telecom
descr:          No.31,jingrong street
descr:          Beijing 100032
country:        CN
admin-c:        CH93-AP
tech-c:         ZL48-AP
remarks:        service provider
status:         ALLOCATED PORTABLE
mnt-by:         APNIC-HM
mnt-lower:      MAINT-CHINANET-YN
mnt-routes:     MAINT-CHINANET-YN
remarks:        -+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+
remarks:        This object can only be updated by APNIC hostmasters.
remarks:        To update this object, please contact APNIC
remarks:        hostmasters and include your organisation's account
remarks:        name in the subject line.
remarks:        -+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+
changed:         20090121
source:         APNIC

The attacker continues by trying to change the file's permissions on disk with the chmod 0755 command. The Wikipedia entry for the chmod command describes the command our visitor used as this: equivalent to u=rwx (4+2+1),go=rx (4+1 & 4+1). The 0 specifies no special modes .

Our visitor also tries to run the downloaded file with this entry:

nohup /tmp/.bash_root.tmp3 > /dev/null 2>&1 &

I have to admit, I had to look this one up. The nohup command is used to keep a program running in the background, even after the user logs out. So, in this case, the intruder wants the file he downloaded, /tmp/.bash_root.tmp3, to start running and continue running after he logs out.

The next part of the command line, > /dev/null 2>&1 & tells the system to redirect all output from .bash_root.tmp3 to /dev/null or, in simpler terms, send all output into the bitbucket. Normally, using nohup would redirect all the output into a file called nohup.out, but adding that last part of the command line prevents nohup.out from being created, helping hide things just a little better. As it turns out, the honeypot doesn't recognize the nohup command and responds with "command not found", so this command line failed to actually run anything.

Next, it appears the attacker started setting up a persistence mechanism. The command  echo "cd /tmp">>/tmp/rc.local creates an rc.local file in /tmp and tells the system to change to /tmp for commands as it starts up. The system is supposed to read through the rc.local file as it boots up to find commands.

The next command, echo "./.bash_root.tmp3&">>/tmp/rc.local tells the system to append the text ./.bash_root.tmp3& to the existing rc.local file. For unknown reasons, the attacker sends this one twice. This command tells the system to run the .bash_root.tmp3 program on start up and, adding the & to the end of the file name tells the system to run the program in the background.

The next command our visitor enters is echo "/tmp/init.d/iptables stop">>/tmp/rc.local. This appends /tmp/init.d/iptables stop to the rc.local file and is intended to turn off the iptables firewall on boot.

Finally, the attacker tries twice to protect the .bash_root.tmp3 from accidental or intentional deletion. According to the chattr man page, a file with the -i attribute (in this case, the .bash_root.tmp3 file) such that it cannot be modified, deleted or renamed, nor can a link be created to it and no data can be written to it. Only a superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute. After entering the chattr command once without including the full path to the file, the intruder tries again using the full path. Like other commands, the honeypot doesn't know the chattr command and simply replies that the command is not found. Shortly after this, the attacker apparently disconnects and the log comes to an end.

As I said before, if I got something wrong in all of this or you have something to add, by all means add a comment to this post and let me know.

In part two of this series, I will be conducting my own attack against a test system. I will attack a "real" system (my own, don't call the cops ;-) ) in a virtual machine, download the .bash_root.tmp3 file and execute it. I will then pause the virtual machine and save the .vmem file for analysis with Volatility. I will also create a timeline of the .vmdk file to see what other files perhaps are created when I execute the file. In part three, I hope to be able to describe what this file's purpose is. I'm not even close to being a reverse engineer, but with a little help from my friends at Malware Must Die and others, perhaps I'll have some general idea of what it is.

Stay tuned!