17.3 TCPIP Related Digital Evidence


17.3 TCP/IP Related Digital Evidence

Given the central role that TCP/IP plays in networks, it should come as no surprise that IP addresses, port numbers, TCP flags, and other TCP/IP related data accumulate in many places. Understanding how to find and exploit these sources of digital evidence is central to investigating crime on networks. As noted in the previous chapter, sniffer logs contain TCP/IP related information.

CASE EXAMPLE

start example

While investigating a UNIX computer intrusion, investigators found a program called router that they did not recognize. Examining the contents of this binary file revealed that it was a Portuguese sniffer, specially designed to capture usernames and passwords, that saved captured data in a file named "/etc/.X0" as shown here:

    Erro abrindo socket Erro setando flags da placa Erro setando modo promiscuo    -------+ [%d bytes]+ -------+[%d segs]+ ------- [RST]    [Fim de coneccao]    %s %s => %s [%d]    %c eth0 w+ /etc/.X0    Erro abrindo %s macunaim@hotmail.com joao@localhost localhost    ------- [Sniffer Terminado] 

In addition to usernames and passwords to other systems on the network, the "/etc/.X0" file contained evidence of several unauthorized Telnet connections from Brazil using a stolen account. Ironically, the intruder had recorded his crime and IP address with his own sniffer:

    Tue Mar 18 18:54:52 2003    mx1.corpZ.com.br  server1.corpX.com [23]    #'vt100!stolenaccount    password    w    dnsmai1 43876537    id    cd /    ------+ [60 segs]+    Fri Mar 21 05:18:45 2003    dialup34.corpX.com  server1.corpX.com [23]    !#' 38400,38400username    password    pine    term=vt100    pine    ------ + [60 segs] +    ------ [Fim de coneccao] 

Searching unallocated space for class characteristics of this sniffer log, the digital evidence examiner was able to find similar incriminating fragments of an older sniffer log that the intruder had deleted.

end example

Although TCP/IP data can be captured using a sniffer, it is not feasible to capture all network traffic in all situations, making it necessary to rely on other sources of evidence such as log files that show past connections and in state tables that show recent and current connections between hosts. Several examples of log files and state tables containing this type of information have been mentioned in passing. The following sections discuss these and other useful sources of TCP/IP related information in more detail, demonstrating how they can be useful in an investigation.

17.3.1 Authentication Logs

Authentication logs are very useful because they show which account was associated with an activity and often contain an associated IP address or telephone number, substantially narrowing the suspect pool.

CASE EXAMPLE (SHINKLE 2002):

start example

An unusual lead developed during a serial homicide investigation in St Louis when a reporter received a letter from the killer. The letter contained a map of a specific area with a handwritten X to indicate where another body could be found. After investigators found a skeleton in that area, they inspected the letter more closely for ways to link it to the killer. The FBI determined that the map in the letter was from Expedia.com and immediately contacted the site to determine if there was any useful digital evidence.

The Web server logs on Expedia.com showed only one IP address (65.227.106.78) had accessed the map around May 21, the date the letter was postmarked. The ISP responsible for this IP address was able to provide the account information and telephone number that had been used to make the connection in question similar to the information shown here:

    Username: MSN/maurytravis    UUNET Resllerer: MSN    IP address assigned: 65.227.106.78    Time of connection: 19:53:34 May 20    Time of disconnect: 22:24:19 May 20    ANI information: (212) 555-1234 

Both the dial-up account and telephone number belonged to Maury Travis. Investigators arrested Travis and found incriminating evidence in his home, including a torture chamber and a videotape of himself torturing and raping a number of women, and apparently strangling one victim. Travis committed suicide while in custody and the full extent of his crimes may never be known.

end example

Internet dial-up logs such as those used in the Travis case are generally created by RADIUS or TACACS authentication servers. Other network devices such as Virtual Private Network (VPN) concentrators also use RADIUS or TACACS to authenticate users. Organizations use these centralized authentication servers to make account administration easier rather than having different user accounts on each system. Network administrators can search the associated authentication logs to obtain the type of information mentioned in the Travis case; that is, which user account was assigned an IP address at a given time. For instance, the following RADIUS logs were generated by Microsoft Internet Authentication Server (IAS) running on a machine named IAS-SERVER (172.16.1.45) when the "ianjones" account in the CORPX domain was used to connect through a VPN concentrator (172.16.1.219) from 64.252.248.133:

    172.16.1.219,CORPX\ianjones,03/08/2003,17:46:04,IAS,IAS-SERVER,    5,7029,6,2,7,1,66,64.252.248.133,61,5,4108,172.16.1.219 4116,0,4128,CORPX    VPN,4129,CORPX\ianjones,25,311 1 172.16.1.4510/08/2002 14:38:34    22348,4127,3,4130,corpx.com/Users/ianjones,4136,1,4142,0    172.16.1.219,CORPX\ianjones,03/08/2003,17:46:04,IAS,IAS-SERVER,25,311 1    172.16.1.4510/08/2002 14:38:34    22348,4130,corpx.com/Users/ianjones,6,2,7,1,4108,172.16.1.219,    4116,0,4128,CORPX    VPN,4129,CORPX\ianjones,4120,0   0259414C45,4127,3,4149,Allow access if    dial-in permission is enabled,4136,2,4142,0    172.16.1.219,CORPX\ianjones,03/08/2003,17:46:07,IAS,IAS-SERVER,    5,7029,6,2,7,1,8,    172.16.19.53,25,311 1 172.16.1.45 10/08/2002 14:38:34    22348,40,1,44,E0D03B6B,66,64.252.248.133,45,1,41,0,61,5,4108,172,16.1.219,    4116,0,4128,CORPX VPN,4136,4,4142,0 

These log entries contain the IP address assigned to the connecting host by VPN concentrator (172.16.19.53) along with other connection details (Microsoft 2000). The corresponding logout was recorded as shown here:

    172,16.1.219,CORPX\ianjones,03/08/2003,17:55:12,IAS,IAS-SERVER,    5,7029,6,2,7,1,8,    172.16.19.53,25,311 1 172.16.1.45 10/08/2002 14:38:34 22348,40, 2,42,    36793575,43,    6837793,44,E0D03B6B,46,35619,47,417258,48,59388,49,1,66,64.252.248.133,    45,1,41,0,61,5,4108,172.16.1.219,4116,0,4128,CORPX VPN,4136,4,4142,0 

This VPN connection and IP address assignment is depicted in Figure 17.8.

click to expand
Figure 17.8: VPN concentrator (172.16.1.219), IAS server (172.16.1.45), and connecting host (64.252.248.133; 172.16.19.53).

Some organizations use a centrally administrated mechanism like Kerberos to handle authentication for all of their hosts and applications, logging all authentication requests in a log file on the Kerberos server. These logs include the date and time of the authentication request as well as the IP address and user name making the request:

    May 12 10:23:52 kerberos1 krb5kdc[2324](info):    AS_REQ 192.168.19.4(88): ISSUE: authtime 1052829558,    user/ianjones@CORPX.COM for krbtgt/CORPX.COM@CORPX.COM 

These types of centralized authentication systems can be a very useful and reliable source of digital evidence because they correlate events from multiple sources on the network and store the log files on a system that is generally more secure than other hosts on the network. Windows Security Event Logs can also be configured to record which accounts logged in when, and Windows 2000 Active Directory facilitates centralized authentication mechanisms like Kerberos.[15]

E-mail, Web, and other Internet servers may also have authentication logs useful for connecting online activities with an individual. For instance, the following logs from an e-mail server show the account "eco" being used to check e-mail from IP address 10.10.2.10, once at 11:01 on February 6 and a second time at 15:02:[16]

    Feb 6 11:01:26 mailsrv ipop3d[26535]: Login user=eco    host =dialup.domain.net [10.10.2.10]    Feb 6 11:01:28 mailsrv ipop3d[26535]: Logout user=eco    host=dialup.domain.net [10.10.2.10]    Feb 6 15:02:48 mailsrv ipop3d[244]: Login user=eco    host=dialup.domain.net [10.10.2.10]    Feb 6 15:02:49 mailsrv ipop3d[244]: Logout user=eco    host=dialup.domain.net [10.10.2.10] 

Multiuser systems often have records of which accounts logged in when. The following segment shows that an intruder used an account named "toor" to log into a UNIX system from a Pacbell dial-up account:

    % last toor    toor pts/0 Wed Mar 31  18:27  ppp-90.scrm01.pacbell.net - 18:30  (00:12)    toor ftp   Wed Mar 31  18:28  ppp-90.scrm01.pacbell.net - 18:27   (00:11) 

Windows NT/2000/XP systems maintain similar authentication logs but they usually only contain the NetBIOS name of the connecting system, not the IP address.

Many other servers have their own authentication mechanisms and associated logs. In some instances, particularly when dealing with customized applications, it is necessary to obtain the assistance of someone familiar with the system to locate and comprehend these logs.

17.3.2 Application Logs

Many applications have log files, other than authentication logs, containing information about peoples' activities on a network. For instance, the following FTP transfer logs ("xferlog") show the user account and IP address used to delete files on the server:

    Nov 14 00:17:23 fileserver1 ftpd[2536]: user32 of 202.180.75.79 [202.180.75.79]    deleted /d2/project13/data1.xls    Nov 14 00:17:24 fileserver1 ftpd[2536]: user32 of 202.180.75.79 [202.180.75.79]    deleted /d2/project13/data2.xls    Nov 14 00:17:24 fileserver1 ftpd[2536]: user32 of 202.180.75.79 [202.180.75.79]    deleted /d2/project13/report1.doc    Nov 14 00:17:25 fileserver1 ftpd[2536]: user32 of 202.180.75.79 [202.180.75.79]    deleted /d2/project13/report2-final.doc    Nov 14 00:17:25 fileserver1 ftpd[2536]: user32 of 202.180.75.79 [202.180.75.79]    deleted /d2/project13/report2-rev2.doc    Nov 14 00:17:26 fileserver1 ftpd[2536]: user32 of 202.180.75.79 [202.180.75.79]    deleted /d2/project13/report2-rev1.doc 

Similarly, each time a Web server receives a request from a client, it records the client's IP address in its access log along with the date, time, and what the client requested. In addition to showing the request from an IP address used by a suspect, Web access logs can be used to determine which IP address accessed a specific page during a certain time, as in the Maury Travis case. A few other common examples are provided here to demonstrate how they can be used in an investigation.

CASE EXAMPLE

start example

When an individual defaces a Web page, he/she usually views it shortly before and after the defacement to check his/her work as can be seen in the following Web server log entries:

    04:17:33 216.67.71.92 HEAD /msadc/msadcs.dll 200    04:19:20 216,67.71.92 GET /default.html 404    04:19:32 216.67.71.92 GET /default.htm 200    04:19:36 216.67.71.92 GET /images/spacer.gif 200    04:19:40 216.67.71.92 GET /line.gif 200    04:19:50 216.67.71.92 GET /images/image1.gif 200    04:19:59 216.67.71.92 GET /msadc/msadcs.dll 200    04:20:33 216.67.71.92 POST /msadc/msadcs.dll 200    04:20:37 216.67.71.92 GET /default.htm 200    04:20:39 216.67.71.92 GET /Default.htm 200 

The first entry shows a scan for known vulnerabilities locating a vulnerable DLL (msadcs.dll) on a Web server. Two minutes later the intruder attempts to view the default page, misspelling it the first time. The intruder breaks in and replaces the default page, the actual page replacement is not logged by the Web server because it is not uploaded through the Web server. The last two entries show the intruder checking the default page again to view the defacement. In cases where an intruder launches an attack through another compromised machine, he/she may still view the page using the Web browser on his own machine.

end example

Many marketing companies make their money by examining the Web pages that a particular individual views and using this information to learn about his/her interests. This same approach can be useful in an investigation for determining who was using a specific computer at a certain time. Web server logs, like their corresponding Web browser history and cached files on a personal computer, can provide strong circumstantial evidence that a particular individual was responsible for the activity in question.

To better understand how to extract behavioral information in log files it is useful to compare routine behavior with more anomalous behavior. When an individual sends an e-mail message, this action is recorded in the e-mail server log file as shown here:

    Feb 7 15:05:30 mailsrv sendmail[1257]: PAA01257: from=(eco@    corpus-delicti.com), size=793, class=0, pri=30793, nrcpts=1,    msgid=(4.2.0.58.19991013150621.0099fa90@mailsrv.corpus-delicti.com),    proto=ESMTP, relay=dialup.domain.net [10.10.2.101]    Feb 7 15:05:31 mailsrv sendmail[1259]: PAA01257: to=bturvey@    corpus-delicti.com, delay=00:00:03, xdelay=00:00:00, mailer=relay,    relay=mail.domain.net. [10.10.2.11], stat=Sent (PAA00253 Message accepted    for delivery) 

Note that a single message creates two entries in an e-mail server log, containing source and destination details, and both containing the same message ID (e.g. PAA01257). In this instance, the IP address of the sender was 10.10.2.101. Compare this normal activity with the following log entries that show someone forging an e-mail message using the SMTP forgery method detailed in Chapter 18:

    Oct 15 01:20:09 mailserver sendmail[27941]: BAA27941:    from=forged.from@home.net, size=114, class=0, pri=30114, nrcpts=1,    msgid=<199910150518.BAA27941@mailserver>, proto=SMTP,    relay=host1.domain.net [20.134.161.6]    Oct 15 01:20:10 mailserver sendmail[28214]: BAA27941:    to=target@ayyahoo.com, delay=00:01:14, xdelay=00:00:01, mailer=esmtp,    relay=192.168.1.50, stat =Sent (BAA08487 Message accepted for delivery) 

The forger evidently made a typo in the target e-mail address and the resulting e-mail header will contain associated backspaces and other characters (e.g. target\bl@ayyahoo.com) when viewed in hexadecimal format.

There are many different commercial network applications and some organizations make their own in-house applications with unique logging mechanisms. Therefore, it is sometimes necessary to perform research and even a functional reconstruction to understand what actions relate to specific log entries.

CASE EXAMPLE

start example

An organization's primary server was targeted by a denial of service attack that lasted for several days. The log files indicated that dozens of machines had been involved in the attack. However, when investigators examined some of the attacking machines, it became clear that some of the machines seized had not been involved in the attack and the date-time stamps in the application server logs were misleading. Using a similar server to perform a functional reconstruction, it was determined that log entries were not made when a request was initially received. Instead, each request was held in a queue that was processed sequentially and a log entry was only made when the request was processed. Because the denial of service attack had created a large queue on the server, it had taken several hours for requests to be processed and associated log entries to be generated. Therefore, the log entries did not accurately reflect when each portion of the attack had occurred.

end example

17.3.3 Operating System Logs

Most operating systems can maintain logs of noteworthy events such as system reboots, errors, modem usage, and network interface cards being put into promiscuous mode by a sniffer. Because they were initially designed with networks in mind, log files on UNIX systems generally retain more TCP/IP related information than Windows NT Event Logs. Table 17.2 describes the most common system logs on UNIX machines. Newer versions of UNIX usually store their log files in "/var/adm" or "/var/log" whereas older versions store them in "/usr/adm." However, the location of these logs is configurable in "/etc/syslog.conf" and can be on a remote syslog server.

Table 17.2: Log files on various types of UNIX.

FILE

DESCRIPTION

Aculog

If modems are attached to the computer, this log contains a record of when the modems were used to dial out

Authlog or secure

On some systems these files contain security related logs including information relating to authentication on the system such as logon attempts

Lastlog

This log file contains a record of each user's most recent login (or failed login)

loginlog

Records failed logins

Syslog

The syslog file (sometimes called "messages" or "system" depending on the type of UNIX and its configuration) is the main system log file. Some servers, such as Sendmail and SSH on UNIX, can be configured to log into the syslog file and these main log files often contain information that is also found in other log files, e.g. failed logins. Additionally, routers and firewalls are usually configured to add their logs to the syslog file on a remote logging server

utmp and utmpx

These files contain a record of all users currently logged into a computer. The "who" command accesses this file

wtmp and wtmpx

These files contain a record of all of the past and current logins and records system startups and shutdowns. The "last" command accesses this file

xferlog

This file contains a record of all files that were transferred from a computer using the File Transfer Protocol (FTP)

The following entries in the syslog file relate to the Brazilian intruder encountered earlier, showing several unauthorized connections, one corresponding to the entry in his sniffer log on March 18. The intruder attempted to login again on March 25 and entered the stolen password twice before realizing it had been changed and that his crime had been discovered:

    % grep "corpZ\ |promiscuous" syslog    Mar 1 23:50:29 server1 login: LOGIN ON 0 BY stolenaccount FROM    mx1.corpZ.com.br    Mar 7 19:08:49 server1 login: LOGIN ON 1 BY stolenaccount FROM    mx1.corpZ.com.br    Mar 7 19:13:37 server1 kernel: device eth0 left promiscuous mode    Mar 7 19:14:21 server1 kernel: device eth0 entered promiscuous mode    Mar 18 18:55:27 server1 login: LOGIN ON 1 BY stolenaccount FROM    mx1.corpZ.com.br    Mar 25 21:09:53 server1 login[29708]: FAILED LOGIN 1 FROM mx1.corpZ.com.br    FOR stolenaccount, Authentication failure    Mar 25 21:10:11 server1 login[29708]: FAILED LOGIN 2 FROM mx1.corpZ.com.br    FOR stolenaccount, Authentication failure 

Most UNIX system log files contain information about incoming traffic, but not outgoing traffic. This makes it relatively easy to determine what an individual was doing to a computer but makes it difficult to determine what an individual was doing from the computer. To overcome this limitation some system administrators install host-based firewalls (e.g. IPFilter, IPChains, ZoneAlarm) on their computers that logs details about noteworthy incoming and outgoing network connections.

17.3.4 Network Device Logs

Because of their central role, network devices often generate logs that provide an overview of activities on a network. Such an overview can help investigators gain an initial understanding of what occurred and which hosts were involved. The overview of network activity that these logs provide can be very detailed, showing activities that were not recorded in other logs. Even when the activities were recorded by other systems, logs from network devices can be used for corroboration, providing independent sources of digital evidence relating to the same events.

CASE EXAMPLE

start example

An organization found a host on their network was apparently compromised using a new exploit that was not detected by the intrusion detection system. NetFlow logs were examined to gain a clearer understanding of how the host had been compromised. The NetFlow logs showed that, at approximately 12:25 A.M. on October 21, adsl-61-105-217.msy.bellsouth.net (208.61.105.217) targeted the SSH daemon on the compromised machine. This reconnaissance activity corresponded with the following system log entries from one of the computers:

    Oct 21 00:29:25 hostA sshd[18967]: connect from 208.61.105.217    Oct 21 00:29:25 hostA sshd[18967]: log: Connection from 208.61.105.217    port 4584    Oct 21 00:29:34 hostA sshd[18967]: fatal: Did not receive ident string. 

At about 02:15 A.M. on October 21, NetFlow logs showed that 66.28.12.53 accessed the SSH server. This corresponded with the following buffer overflow recorded in the syslog file of the compromised host:

    Oct 21 02:16:24 hostA sshd[18997]: connect from 66.28.12.53    Oct 21 02:16:24 hostA sshd[18997]: log: Connection from 66.28.12.53 port 2974    Oct 21 02:16:24 hostA sshd[18997]: log: Could not reverse map address    66.28.12.53.    Oct 21 02:16:25 hostA sshd[18998]: connect from 66.28.12.53    Oct 21 02:16:25 hostA sshd[18998]: log: Connection from 66.28.12.53 port 2975    Oct 21 02:16:25 hostA sshd[18998]: log: Could not reverse map address    66.28.12.53.    <cut or brevity>    Oct 21 02:18:29 hostA sshd[19119]: fatal; Local: crc32 compensation attack:    network attack detected 

At this stage, the intruder installed an IRC bot and French ident daemon to reply to IRC servers with a name other than root. Many IRC servers will not accept connections from the root account on a machine because, recognizing it as a sign of compromise:

    Oct 21 02:46:37 hostA in.ident2[28529]: error: setuid(-2): Param re invalide    Oct 21 02:46:37 hostA in.ident2[28529]: error; cannot reduce self's rights 

The intruder also replaced SSH with a Trojaned version that captured passwords in a file named "/usr/lib/libfl.so.3." The Trojaned SSH daemon also had a backdoor associated with the user name "smiley":

    # strings sshd    Rhosts with RSA authentication disabled.    RSA_new failed    BN_new failed    Warning: keysize mismatch for client_host_key: actual %d, announced %d    RSA authentication disabled.    Password authentication disabled.    smiley    /usr/lib/libfl.so.3    user: %s    password: %s    rcvd SSH_CMSG_AUTH_TIS 

Additionally, the intruder replaced "/bin/login" with a Trojaned version that appeared to allow access to a machine if the client's DISPLAY variable is set to "smiley." Scanning the network for other systems with the same backdoors uncovered two more compromised machines. The intruder had attacked these systems from a different IP address, which is why they did not show up in the original examination of the NetFlow logs. Unfortunately, the original NetFlow logs had not been preserved, only the results from the initial examination. By the time the extent of the attacker's penetration was realized, the original NetFlow logs had been overwritten. Without the original NetFlow log files it was not possible to obtain an overview of what the attacker had done with the other compromised systems or if the intruder had gained access to other systems on the network. Also, log files from the IRC bot were encrypted, preventing investigators from obtaining additional information about the intruder.

end example

Because, network devices like routers and firewalls have a limited amount of memory to store logs, they are usually configured to send a copy of their logs to a remote log server for permanent storage. For instance, a router might send system logs to one remote log server and NetFlow logs to a collector on a different host. In most situations, router logs contain limited information about the operation of the router, whereas NetFlow logs generally contain information about every flow through the router.

Consider a situation in which Corporations X's primary router suddenly stops routing all traffic and the "enable" password used to configure the system has been changed, suggesting a serious system failure or sabotage. The following logging details from the router indicate that logs are stored permanently on a remote log server with IP address 172.16.3.2 and show some recent logs are still stored temporarily in memory:

    oisin% date    19:48:05 UTC Fri Apr 11 2003    oisin% telnet route-server.backbone.net    ...    route-server> show clock    *00:16:05.378 UTC Sat Apr 12 2003    route-server >show logging    Syslog logging; enabled (0 messages dropped, 5 messages rate-limited,    0 flushes, 0 overruns)      Console logging: level debugging, 1577 messages logged      Monitor logging; level debugging, 22 messages logged      Buffer fogging: level debugging, 175 messages logged      Logging Exception size (8192 bytes)      Trap logging; level informational, 1586 message lines logged        Logging to 172.16.3.2, 429 message lines logged    Log Buffer (50000 bytes);    *Apr 7 18:47:02: %SYS-5-CONFIG_I: Configured from console by vty0    (172.16.21.4)    *Apr 7 18:51:01: %SEC-6-IPACCESSLOGP: list telnet-log permitted tcp    172.16.21.4(64628) -> 172.16,24.66(23), 300 packets    *Apr 8 00:13:18: %SEC-6-IPACCESSLOGP: list telnet-log permitted tcp    172.16.19.53 (36182) -> 172.16.24.66 (23), 126 packets    *Apr 9 02:18:41: %SEC-6-IPACCESSLOGP: list telnet-log permitted tcp    172.16.19.53 (64805) ->    172.16.24,66 (23), 118 packets    *Apr 9 02:19:01: %SYS-5-CONFIG_I: Configured from console by vty0    172.16.19.53 

Each log entry begins with the date and time, followed by classification codes detailed in Cisco IOS (2000). The first entry in this router log indicates that someone (the network administrator in this case) connected to the router from 172.16.21.4 using Telnet and reconfigured it on April 7 at 18:47 hours. The next two log entries show the administrator connecting using Telnet from the same IP address to check the router. The last connection and reconfiguration on April 9 from 172.16.19.53 was not authorized and was cause for concern. This IP address was associated with the organization's VPN server mentioned in the Authentication Logs section. Recall that the RADIUS logs (Section 17.3.1) indicated that the "ianjones" account was used to commit this offense.

Note that the router clock is inaccurate and the date-time stamps must be adjusted to correct the error.[17] Fortunately, when these logs are sent to the remote server for permanent storage, the server adds a date-time stamp using its own clock as a reference. This can result in unusual looking log entries on the server such as this one, where the server time zone is GMT:

    Apr 8 21:51:41 [route-server] 1435: *Apr 9 02:19:01: %SYS-5-CONFIG_I:    Configured from console by vty0 172.16.19.53 

Some organizations also configure their routers to block certain traffic and maintain a log of denied connections, essentially functioning as a firewall. A sample log entry generated by a Cisco Private Internet eXchange (PIX) firewall when it blocks an unauthorized connection is shown here:

    Jun 14 10:00:07 firewall.secure.net %PIX-2-106001: Inbound TCP connection    denied from 10.14.21.57/41371 to 10.14.42.6/22 flags SYN    Jun 14 10:00:47 firewall.secure.net %PIX-2-106001: Outbound TCP connection    denied from 10.14.42.5/41371 to 10.10.4.16/22 flags SYN 

The format of these log entries is similar to those of a router, starting with the date and time, followed by the name of the firewall, the PIX alert information (Cisco PIX 2000), the action, source, and destination. Different firewalls have slightly different formats that are described in the product documentation.

17.3.5 State Tables

State tables contain information about the current or very recent state of connections between computers. Data in state tables are quite transient -inactive entries are usually cleared in less than an hour. As noted in the previous chapter, the ARP table on every host contains IP addresses relating to recent communications. Also, firewalls, routers, and many other pieces of network equipment maintain a state table of active and recent connections. For instance, on a Cisco PIX firewall these connections can be listed using the show conn detail command. This information can be used to corroborate other evidence and establish the continuity of offense. As mentioned earlier in this chapter, current and recently terminated TCP/IP connections on a server of personal computers can be viewed using the netstat command.

CASE EXAMPLE

start example

A man who was using ICQ to harass a woman believed that he could not be caught because he had configured his ICQ client to hide his IP address. However, the woman consulted with a computer expert and learned that if she could initiate a TCP/IP connection with the man's computer, she could view his IP address using the netstat command. So, the next time the woman was harassed by this man, she sent an ICQ instant message to him, and used netstat to obtain his IP address. The woman contacted his Internet Service Provider and the harassment stopped. This method of finding an individual's IP address is not limited to ICQ. If the harasser had used IRC, AOL IM, or any other application that uses TCP/IP to transfer data the same method could have been used to track him down.

end example

Another example of state tables; for recent outgoing NetBIOS connections, Windows maintains a list of NetBIOS names and their resolved IP addresses in the NetBIOS name table. For instance, in the earlier example involving VNC (Section 17.1.5), the name table on the Windows XP machine running the VNC server (192.168.0.4) had one NetBIOS connection to 192.168.0.2 as shown here:

    C:\> nbtstat -c                  NetBIOS Remote Cache Name Table    Name                  Type      Host Address      Life [sec]    ------------------------------------------------------------    WORKSTN2         <20> UNIQUE    192.168.0.2       567 

Incoming NetBIOS connections can be viewed using the net session command but the associated IP address is not displayed. For instance, executing this command on WORKSTN2 (192.168.0.2) in the aforementioned VNC example shows which user account was used to establish the NetBIOS session but only provides the NetBIOS name of the Windows XP machine (WORKSTN1). Recall that the associated IP address may be obtainable using netstat:

    C:\>net session    Computer        User name         Client Type          Opens Idle time    ----------------------------------------------------------------------    \\WORKSTN1      USER1             Windows 2002 2600    0 00:00:23    The command completed successfully. 

Similarly, UNIX maintains a list of remote machines that are connected to Network File System shares that can be displayed using the showmount - a command as shown here:

    [nfs-server]# showmount -a .    All mount points on case:    192.168.0.101;/Shared-drive 

On the client, the mount command shows all remote shares that are being accessed, which generally corresponds to the information in /etc/fstab mentioned in Chapter 11:

    [nfs-client]# [mount    <entries relating to local drives cut for brevity>    /mnt on 192.168.0.7:/ remote/read/write/nosetuid/dev=2f80002 on Thu Apr    10 08:31:19 2003 

These commands are used in computer intrusion investigations to determine which machines have made connections to a given system. These commands are also useful for locating potential sources of digital evidence on networks as discussed in Chapters 10 and 11.

CASE EXAMPLE

start example

In the process of executing a search warrant to seize a suspect's home computer in a child pornography investigation, the digital evidence examiner notices that the system has an Ethernet connection to a small router. The router had several other Ethernet cables, suggesting that there are other computers in the vicinity. Before shutting the suspect's system down, the examiner uses the netstat -an, nbtstat -c and net session commands to document NetBIOS connections to and from the suspect's system. In addition to listing several connections to other systems on the suspect's home network, these commands showed a computer on the Internet connecting to the suspect's system using an account called "GERY." The digital evidence examiner used the net file command and found that a file containing child pornography was being accessed by the user "GERY":

    C:\>net file    ID         Path                      User name          #Locks    --------------------------------------------------------------    2          D:\pictures\joey01.zip    GERY               0    The command completed successfully. 

This information provided probable cause to obtain a warrant for the remote computer that belonged to one of the suspect's online cohort who manufactured and traded child pornography.

end example

17.3.6 Random Access Memory Contents

TCP/IP related data may be found in RAM on any host, including servers, routers, firewalls, and dial-up terminal servers. By extracting the contents of RAM it may be possible to obtain IP addresses and other useful data relating to network activity. For instance, in one case a computer intruder used a stolen account to install an IRC bounce (BNC) bots that enables individuals to connect to IRC via a compromised host, thus concealing their actual IP address from other people on IRC. Although the traffic between the clients and IRC bot was encrypted, it was possible to obtain some information by examining the contents of memory:

    % /mnt/cdrom/static-binaries/solaris/last stolenaccount    stolenaccount pts/18 Apr 18 12:34 mail.almustaqbal.com.lb - 12:58 (00:24)    % /mnt/cdrom/static-binaries/solaris/ps -ef | grep stolenaccount    root  3485   2432  0  18:05:03  pts/17  0:00   grep    stolenaccount    root  3430   2387  0  18:04:37  pts/10  0:00   script  stolenaccount.04182003    stolenaccount  9455     1        0         Apr 17 ?    0:01    ./tcsh unf    stolenaccount  13961    1        0         Apr 17 ?    0:01    ./bnc    % /mnt/cdrom/static-binaries/solaris/gcore -o /mnt/evidence/core 9455    gcore: /mnt/evidence/core.9455 dumped    % /mnt/cdrom/static-binaries/solaris/gcore -o /mnt/evidence/core 13961    gcore:/mnt/evidence/core.13961 dumped    % cd /mnt/evidence    % strings - core.9455 | more    <cut for brevity>    PART #cavite    a QUIT :sTiLL dA oNe i wAnT...sTiLL dA oNe i LoVeCAVITE's WebSite    (www.cavitechannel.com)    8.244 PRIVMSG #cavite:    0, 0**********    4, 4***    8, 8***    1, 12********* GoodByE all *********    8, 8***    4, 4***    :CuCuMbEr-!v2000@210.23.248.244 PRIVMSG #cavite :    <cut for brevity>    DjCuRe 210.23.248.165 graz.at.Eu.UnderNet.org djcure H :4G    :McLean.VA.us.undernet.org 352 boseman #cavite SMuRF 210.23.248.163    Amsterdam.NL    .Eu.UnderNet.org explorer2H :4    2, 15    :McLean.VA.us.undernet.org 352 boseman #cavite ofm_cap nova4117.    i-next.net Manha    ttan.KS.US.Undernet.Org Jhayr H :3 FERNANDO JOSE    :McLean.VA.us.undernet.org 352 boseman #cavite ~clarice web.cyworld.net    :Arlingto    n.VA.US.Undernet.Org Clarimace H :3 Pls join #Li    Ipid.bnc    fuckj00    <cut for brevity> 

Network devices may also contain some TCP/IP related information in RAM that is not available from the command line. It may be possible to recover such data but the process of dumping the contents of memory varies with each device. For instance, the procedure for obtaining a memory dump of a Cisco router is detailed in (Cisco 2002). It is also possible to extract the contents of RAM by physically connecting special equipment to it but this is expensive and rarely feasible for network devices.

[15]Depending on the configuration, the Windows Security Event Log may not contain IP addresses of remote systems. Unless Kerberos related logging is enabled, the Event log only records the NetBIOS name of remote systems. Notably, Kerberos authentication does not have to be in use for the advanced logging feature to work.

[16]Post Office Protocol (POP) and Internet Message Access Protocol (IMAP) servers both enable clients to read their e-mail remotely and both have similar authentication logs.

[17]Router clocks are notoriously unreliable and it is not uncommon to find that a router clock is off by several days. To address this problem, many routers are configured to automatically correct the dock on a regular basis using the Network Time Protocol (NTP).




Digital Evidence and Computer Crime
Digital Evidence and Computer Crime, Second Edition
ISBN: 0121631044
EAN: 2147483647
Year: 2003
Pages: 279

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net