2013

Gerben Kleijn

NTS 415

11/5/2013

Incident Response Using Wireshark

Contents Incident 1 ...................................................................................................................................................... 3

Incident Analysis ....................................................................................................................................... 4

Prevention Report ..................................................................................................................................... 7

Activity Timeline........................................................................................................................................ 9

Incident 2 .................................................................................................................................................... 11

Answers ................................................................................................................................................... 12

Incident Analysis ..................................................................................................................................... 15

Appendix A – Screenshots for Incident 2 ................................................................................................ 18

Incident 1 On September 16th a Redhat Linux 6.2 system was compromised. This is the 3rd time this system was

compromised by the same intruder. The system 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.

1. Which vulnerability did the intruder exploit?

2. What ways, and in what order, did the intruder use to connect and run commands on the

system?

3. How did the intruder try to hide his edits from the MAC times?

4. The intruder downloaded rootkits, what were they called? Are they new/custom rootkits?

5. Recover (tell how you did it too) the rootkits from the snort binary capture

6. What does the rootkit do to hide the presence of the attacker on the system?

7. What did you learn from this exercise?

8. How long did this challenge take you?

Based on your results, write an report of mitigation/prevention to the owner of attacked the system.

Include any evidence or logs that you feel important along with your prevention/mitigation plan.

Incident Analysis 1. The attacker was able to exploit vulnerability CVE-2000-0573 in Wu-FTP for version 2.6.0 and

earlier. The lreply function in these versions of the FTP server does not properly cleanse an

untrusted format string, which allows remote attackers to execute arbitrary commands via the

SITE EXEC command (cve.mitre.org, 2013).

2. The intruder connected and ran commands on the system in the following ways, given in order:

a. FTP - After exploiting the FTP service the intruder obtained root privileges and used

basic Linux commands to navigate around the filesystem.

b. Telnet - The intruder connects to the victim over telnet using the username ‘nobody’.

No commands are executed - the connection attempt is probably made just to verify

that telnet can be used to log in after the password for ‘nobody’ is deleted.

c. FTP - Adds a user, creates new files, deletes certain passwords, and modifies file access

and modification timestamps.

d. Telnet - Downloads three files from teleport.go.ro. Executes the rootkit located in the

zer0.tar.gz file.

e. SSH - Connected back to 217. 156.93.166 over ssh, probably to copy away data.

3. By using the command ‘touch -acmr’. Touch is a command used to change a file’s access and/ or

modification times, and the flags that the intruder specified ensure that both the access and

modification times are changed (-a and -m), that the access and modification times of another

specified file are used (-r), and that the specified file is not created if it does not exist (-c). The

way in which the intruder uses this command is by first creating a hidden file in a folder with an

inconspicuous name, transferring the access and modification dates of a files that the intruder is

planning to modify, and after the modification is done the access and modification dates are

transferred back again. This makes it seem like the modified file was never accessed or

modified.

4. The first downloaded file was zer0.tar.gz. The second downloaded file was copy.tar.gz. and the

third downloaded file was ooty.tar.gz. The files located in zer0.tar.gz definitely comprised a

rootkit, demonstrated by the actions it takes on the victim machine after being executed. This

seems to be a version of the t0rn rootkit for Linux systems, as demonstrated by the files it drops

on the victim system. All these files are dropped into a directory named ‘t0rn’. Whether the

other files are rootkits and whether they are new or not is difficult to say. Copy.tar.gz was

unpacked on the victim system, as demonstrated by entries in the ‘slog2.log’ file, but the logs

don’t show if it was executed. No further mention of ‘ooty.tar.gz’ is found anywhere in the log

files after this package was downloaded.

5. The rootkits were recovered as follows:

a. Select the first packet where data for the rootkit is transferred (packet 1183) and in

Wireshark select ‘follow tcp stream’. The transferred data from the ftp server to the

victim can be filtered out, leaving only the data belonging to zer0.tar.gz. This data can

be copied to a file, and that file then contains the rootkit. The MD5 hash of zer0.tar.gz is

47865f518d2eb264dfc29320f2146252.

b. The same process was repeated for copy.tar.gz. The MD5 hash of copy.tar.gz is

0806d11d4bfaaddb3d2e4c9a517696a5

c. The same process was repeated for ooty.tar.gz. The MD5 hash of ooty.tar.gz is

3d3fab56fe50d75303c83352e4b9f284

6. The rootkit zer0.tar.gz performs various actions on the victim system. It checks to see if the

system is logging remotely, it creates a backdoor, it installs Trojans, it emails system information

to a remote system, it opens up an ssh port, it displays system information, and more. The

actions it performs specifically for hiding user activity on the victim seem to be related to the

program ‘adore’, which hides certain system services and redirects file access. After the rootkit

finishes performing its main actions, it also goes through various log files to remove lines from it.

7. The biggest thing I learned from this exercise was the CVE-2000-0573 vulnerability and how to

recognize it by the ‘SITE EXEC’ command. I spent a lot of time trying to figure out how the

system was initially compromised. The way I see it, network traffic analysis - particularly

identifying malicious traffic or malware - comes from experience. The more exploit signatures

one encounters, the easier they become to identify if they are encountered again. Prior to this

exercise the only other exploit signature I have come across was for MS10_061; a vulnerability

in the Print spooler service on Microsoft systems. Now I have seen two signatures that I will be

able to identify if I see them again. Other than that, this type of analysis seems to come down to

manually scrolling through many packets and looking at the payload.

8. This challenge took me about 6 hours. The first two hours were spent trying to find the point of

entry, the next three hours were spent scrolling through traffic and generating a timeline of

events, and the last hour was spent writing this document.

Prevention Report Preventing this incident from reoccurring in the future basically comes down to two actions:

1. Updating the FTP server to a version of 2.6.0 or higher.

2. Restricting anonymous access to the FTP server.

The intruder used vulnerability CVE-2000-0573 to gain root access to the FTP server. This vulnerability in

Wu FTP was fixed after version 2.6.0. Therefore, updating the FTP server to a more secure version would

limit any intruder to exploit this vulnerability in order to gain access to the system. Secondly,

anonymous FTP access should be restricted. Allowing anonymous FTP access provides potential

intruders with a way to gain access to a system. By default, anonymous FTP users have very limited

privileges on a server but that does not stop them from exploiting vulnerabilities that increase their

privileges, as was done in this scenario. Even if the FTP server gets updated to a version that does not

have the CVE-2000-0573 vulnerability that does not mean it’s not vulnerable to another exploit that

grants root access to the server. A better idea is to disable anonymous access altogether so that access

to the server can be strictly controlled.

There are other actions that can be taken to harden the server, but any local defenses can be turned off

easily once an intruder gains root access. For instance, the fact that the intruder was able to download

three rootkits to the server suggests that no anti-virus software was running. Although it is good

practice to install anti-virus on any device, once the intruder gains root access he or she would simply be

able to turn it off or remove it from the system before downloading any files.

On the contrary, actions taken remotely to defend a machine cannot be stopped once local root access

is obtained. For instance, a firewall with specific rules as to what network access a device has could have

stopped some of the actions that the intruder performed on the victim system. For instance, the

intruder connected to a remote FTP server and a remote mail server from the victim machine. The

intruder also connected from a remote system to the victim system on port 24 to establish an SSH

session. Port 24 is a non-standard port for SSH traffic so this should have thrown up a red flag. An IDS or

IPS system on the network could have identified this traffic as malicious and potentially stopped. A

firewall could have been configured to block all incoming traffic except on the FTP ports, and to similarly

block outgoing traffic. Northcutt, Zeltser, Winters, Kent, and Ritchey (2005, p.45) point out issues that

can be encountered when trying to control FTP traffic through a firewall, but they also provide solutions

so these issues should not be seen as a reason not to control traffic to an FTP server with a firewall.

Stringent firewall rules might not have prevented the exploitation of this server, but they might have

prevented the exfiltration of data.

Activity Timeline 217.156.93.166 > attempt to telnet into victim: User: nobody, pass: ultravirus - incorrect User: nobody, pass: virus - incorrect User: nobody, pass: no entry - connection timeout 207.35.251.172 > anonymous ftp connection to victim. Uses CVE-2000-0573 to exploit box and gain root access Browses around the filesystem for a bit. Deletes the password for user nobody 217.156.93.166 > attempt to telnet into victim: User: nobody - entry gained 207.35.251.172 > continue through FTP connection Creates directory /etc/X11/applnk/Internet/.etc Creates directory /etc/X11/applnk/Internet/.etcpasswd Updates the access and modification timestamps for the .etcpasswd file to that of /etc/passwd Adds user dns and adds user to root group Deletes password for dns Updates the access and modification timestamps for the /etc file to that of /etc/X11/applnk/Internet/.etc Verifies through several ls commands that the other commands were successful 217.156.93.166 > attempt to telnet into victim: User: nobody - entry gained Gives a ‘su dns’ command but afterwards he still seems to be user nobody Opens an ftp connection to teleport.go.ro Creates a new directory: /dev/rd/sdc0 FTP connection establishes. Logs in with usename teleport and password gunoierul. Downloads zer0.tar.gz (139711 bytes) Downloads zopy.tar.gz (265189 bytes) Downloads ooty.tar.gz (14847 bytes) Disconnects from the FTP server Unpacks zer0.tar.gz 207.35.251.172 > port scans the target 217.156.93.166 > Executes the rootkit through telnet The rootkit performs various actions on the system 192.168.1.102 > 64.4.49.71 - victim opens up an SMTP connection to the server Emails system information to hatcheryhatched@hotmail.com 217.156.93.166 > Rootkit continues its actions and status messages are relayed through telnet Rootkit finishes its actions and cleans log files to hide activity 217.156.93.166 > Opens ssh connection to victim on non-standard port 24

Transmission is encrypted. However, the victim did remote log the commands given through the shell so the slog2.log file provides some of the actions taken through the encrypted ssh session. The intruder does a ‘whoami’ command, probably to verify that he or she still has root privileges. The intruder then navigates to the folder where the zer0 rootkit was downloaded to and run from and deletes the file zer0.tar.gz. He or she verifies it was deleted by running ‘ls --color’, which he or she aliases as ‘ls’. The password for user ‘nobody’ is also changed.

217.156.93.166 > Telnets into the victim again User: uucp, no pass. Not sure if the connection was ever established, since no password was asked for or given, but even if it was, all the user did was send a Ctrl-D sequence (\004) which closes the telnet connection. 217.156.93.166 > continues ssh session

The intruder pings yahoo.com and accesses (possibly edits) the /etc/rc.d/rc3.d/s50inet file. This file seems to be related to the inetd startup script (Blum, 2002, p.171). The intruder then moves the file copy.tar.gz to a different directory and unpacks it. He or she changes the file permissions of every file in the working directory through the command ‘chmod 7777 *’, which grants read, write, and execute to everyone and also changes the setuid, setgid, and sticky flags of the file. The first two of those set the effective user and group ids of the user opening or executing the files. As for the sticky bit, when this is set only the item’s owner, the directory’s owner, or the superuser can rename or delete files. The intruder then deleted the file copy.tar.gz and enters the directory ‘copy’, presumably where all the files were unpacked to. The intruder again issues the command ‘chmod 7777 *’. The intruder’s last logged actions are the ‘ls’ command to view all the files in the directory, the ‘’uname -r’ command which prints the system’s kernel release, and finally ‘pstree’, which displays a tree of processes. This is where the log file ends. It’s possible that the next command executed the ‘copy’ rootkit and remote logging of system commands was immediately disabled, or the remainder of the log files were simply removed for this challenge.

Incident 2

An attacker accessed a Linux system using the WU-FTPD vulnerability, then installed a backdoor binary

and proceeded to use the system for malicious activity. Determine what the activity was and how it was

accomplished. All the necessary evidence is contained in the snort binary capture file. The IP address of

the system is 172.16.183.2. Using the snort file, answer the following questions:

9. What is the attacker's IP address?

10. What does the attacker do first?

11. What do you think the motivation is for the attack?

12. Why there is readable text in some packets such as 17-25, but not in other packets such as

15&16? What differentiates these packets from each other?

13. What is the purpose of 'foo'? Please provide more insight about the internal workings of 'foo'?

14. What is the skill level of the coder of 'foo'? Do you think the coder was experienced or an

amateur?

15. What is the purpose of './ttserve ; rm -rf /tmp/ttserve' as done by the attacker?

16. How do you think the attacker will use the results of his activity involving 'foo'?

17. As a network administrator, would you have caught this type of backdoor communication? If

yes, how?

18. What do you think is the best way to prevent such communication from happening and/or

detect it?

19. How long did this assessment take you?

20. What did you learn?

Answers

1. I found it difficult to determine with certainty what the attacker’s IP was, as described in more

detail in the ‘incident analysis’ section. However, my best guess would be 80.14.184.201, which

is the IP address that attempts to log into the server’s FTP service.

2. The first activity that seems to be related to the malicious activity is when ‘foo’ gets downloaded

to the server. This is approximately 3.5 hours after 80.14.184.201 tries to log into the FTP

service.

3. I think the motivation for the attack is denial of service (DoS) of the ICQ website. The ICQ servers

start to become less responsive within 2 minutes of 172.16.183.2 making its first connection to

them. One client by itself wouldn’t be able to DoS ICQ by continuously requesting resources, but

hundreds of clients simultaneously doing the same thing would. Therefore, I think that

172.16.183.2 was one machine used in a larger DDos (distributed DoS) attack.

4. I am confused by this question; I don’t see readable text in any of these packets, as

demonstrated by figures 1 and 2 in appendix A. These figures only show packet 15 and 17, but

no readable text was found in packets 16, or 18-25 either.

5. Foo’s purpose seems to be simply to occupy resources from a server at web.icq.com. It causes

the server on which it is executed to contact a server at web.icq.com and request a webpage.

Shortly after the download has started, the connection is reset and then initiated again on a port

one up from the previous port, and requesting a resource one up from the previously requested

resource.

6. It’s hard for me to say whether the coder was experienced or an amateur because I don’t know

much about coding myself, or DoS attacks. The program seems to function as it is supposed to. I

imagine the program keeps running in a simple loop, as it does the same thing over and over

again. At the end of each session with an ICQ server, the client sends out a duplicate resource

request with an incorrect checksum header, followed by several RST packets to close the

connection. This might be bad coding, or it might be part of the function of the program. Maybe

sending a duplicate request with an incorrect header checksum and closing the connection

through RST rather than FIN packets take up more server resources, in which case it would fall in

line with the motivation of executing a DoS attack.

7. I cannot find any frame that contains the string “ttserve” in the packet capture file, as

demonstrated by figure 3. My guess is that this is part of the text that is supposed to be

readable in packets 17-25. My only guess as to why this text is not readable on my system is that

my Wireshark might not be updated to the latest version. I am running version 1.8.5, and

according to Wireshark.org the newest version is 1.10.3. However, running “apt-get install

Wireshark” on my system informs me that I have the newest version available through the

repositories, and to be honest - I didn’t feel up to the task of compiling the program from

source.

8. This question makes me think that I am incorrect about the activity being a DDoS attack,

because a DDoS attack doesn’t really have useable results. It’s usually an activity that is done

out of spite, out of political motivation, or just ‘for fun’. However, if I am right about the activity

being a DDoS attack then I imagine the attacker would interpret the results as a successful

attack and continue to use the program, possibly against other targets. I imagine the program is

easy to adapt against other targets by simply replacing ‘web.icq.com’ with another domain

name.

9. I really hope I would, because the network traffic originating from 172.16.183.2 appears very

suspicious. Regardless of what the purpose of this server is (besides being an FTP server), I

imagine it is not supposed to continuously make ICQ webpage requests. A properly configured

IDS would pick up on this traffic and alert the system or network administrator. Alternatively,

without an IDS an alert administrator could still pick up on the suspicious traffic just by looking

at Wireshark on live traffic. Of course, this would require the admin to be looking at network

traffic while the attack is in progress, but since the activity went on for more than five hours it

would seem likely that it would be detected.

10. A good network security policy that outlines acceptable traffic, and an IDS that is configured to

pick up on non-compliant traffic would be the best way to detect this type of communication.

Additionally, making sure that servers and services are patched and up-to-date plays an

important role too. In this case, that might have prevented 172.16.183.2 from being part of the

malicious activity in the first place since it might have had a non-vulnerable version of Wu-FTP

running.

11. This assessment took me about three to four hours.

12. Assuming that I am correct in my assessment of this traffic being part of a DDoS attack, I learned

to look at network traffic from a different perspective. At the start of the analysis I assumed that

the network traffic was part of 172.16.183.2 being compromised, or otherwise being the target

of malicious activity. However, the captured network traffic didn’t match up with this

assumption, which forced me to consider that the server was not the target of malicious activity,

but rather the origin and that web.icq.com was the target. That’s what made me consider that I

was looking at a DDoS attack.

Incident Analysis The first thing I did was inspect that traffic metadata. Inspecting the traffic using ‘statistics – protocol’

hierarchy reveals that most of the communication is done over TCP, and only a small amount is done

over FTP, HTTP, and UDP. Looking at ‘statistics – endpoints’ shows that there are 37 unique IP addresses

contained in the packet capture. ‘Statistics – summary’ shows that the first packet was captured on April

12th 2002 at 06:45:02 and the last packet was captured 10:38:02 hours later at 17:23:05. Finally ,

‘statistics – conversations’ show that the most packets were sent between the server and the following

hosts: 205.188.248.25, 205.188.248.89, and 205.188.248.57. These hosts also sent the most information

in terms of bytes, although 11.11.11.11 also sent a high amount of bytes to the server. All other

communication session contained a relatively low amount of packets and bytes. It is likely that the

attacker’s IP address is one of the ones identified (edit: turns out that it wasn’t).

The start of the packet capture is confusing. First there is some ICMP traffic, followed by network voice

traffic with various hosts 1.5 hours later. Another 1.5 hours later, 80.14.184.201 establishes a

connection with the compromised server over FTP. Upon completion of the three-way-handshake the

server sends out a DNS request asking for the FQDN of 80.14.184.201. The response is ‘AOrleans-102-1-

2-201.abo.wanadoo.fr’. The server then sends out another DNS request asking for the IP address

associated with this name, and gets the response 80.14.184.201. The server then sends out another

DNS request asking again for the FQDN of the client, and receives the same response as before. Finally,

the server sends out a DNS request asking for the FQDN of itself – 172.16.183.2. This is strange DNS

traffic. After the DNS traffic is over, the client attempts to login to the server using “anonymous” as a

username, and “Pguser@home.com” as a password. The login is unsuccessful but the connection is

actually terminated from the client side, not the server side. Additionally, the process of trying to log in

happens in less than a second – too fast for a human to enter a username and password which suggests

the connection is established through a script or program.

2.5 Hours later, there is some NETBIOS Name Service traffic between a client and 172.16.183.8. A half

hour after that there is some more network voice traffic between two different clients and

172.16.183.2. 5 minutes after that 61.114.247.229 tries to connect to port 111 (sunrpc) on both

172.16.183.2 and 172.16.183.8 but as soon as both servers send their SYN, ACK packets, the client resets

the connection. Finally, 20 minutes later there is one more network voice packet sent from 58.248.76.90

to 172.16.183.2, and within two seconds the server establishes a connection from port 1025 with

11.11.11.11 (which in reality seems to be 216.242.103.2) on port 8882 and downloads the file “foo”.

Foo is a program of 215,578 bytes.

Immediately after the transfer of ‘foo’ is completed, the server sends out a DNS request over port 1025

for ‘web.icq.com’, and establishes an HTTP connection over port 1026 with the address contained in the

answer. After the connection is established, the server sends out the following request: “GET

/wwp?Uin=9207100 HTTP/1.0”, which seems to be an ICQ webpage. The page’s HTML code is then

downloaded to the server, but before it’s finished the server sends out another GET request for the

same resource. The header checksum for this request is incorrect. The ICQ server continues to send

several HTTP data packets to the server, but the server responds to each one with a RST packet,

indicating that the connection should be closed.

Immediately after the ICQ server stops sending packets, the server sends out another DNS request over

port 1025 asking for an IP address for web.icq.com. Just like before, it establishes an HTTP connection to

the address provided in the response but it does so over port 1027, one up from before. It makes a GET

request for /wwp?Uin=9207101, also one up from before.

This pattern continues for a while – the port number on which the connection is established increases

by one and the resource requested increases by one. However, after a while (packet 1230, port number

1045, and resource request 9207119) the server starts sending out 7 SYN packets instead on just one,

possibly because the ICQ server doesn’t respond to the first six – there are approximately 3 minutes

before the ICQ server sends back a SYN,ACK packet. For the rest of the packet capture, that doesn’t

change.

Appendix A – Screenshots for Incident 2

Figure 1. Packet 15 contains no readable text.

Figure 2. Packet 17 contains no readable text.

Figure 3. The string "ttserve" is not found in the packet capture.

References

Blum, R. (2002). Open Source E-Mail Security. Retrieved from http://books.google.com/books?id=9mFLB1NH8iUC&pg=PA171&lpg=PA171&dq=what+is+s50inet+file&source=bl&ots=K1irP2cACA&sig=GmXDrwBKCHx3mXNtx-f6M7HdcQs&hl=en&sa=X&ei=yBN5Up_ROcijiQKT7oCYDA&ved=0CCwQ6AEwAA#v=onepage&q=what%20is%20s50inet%20file&f=false.

CVE.mitre.org. (2013). Common Vulnerabilities and Exposures: CVE 2000-0573. Retrieved from http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-0573.

Northcutt, S., Zeltser, L., Winters, S., Karen, K., & Ritchey, R.W. (2005). Inside Network Perimeter Security. 2nd Ed. Sams Publishing, Indianapolis, IA.