Chapter 8

Phase3: Gaining Access Using

Network Attacks

Tools used in Network Attacks

Sniffing
Spoofing
Session hijacking
Netcat

Sniffer
Allows attacker to see everything sent across the

network, including userIDs and passwords

NIC placed in promiscuous mode
Tcpdump http://www.tcpdump.org
Windump http://netgroup-serv.polito.it/windump
Snort http://www.snort.org
Ethereal http://www.ethereal.com
Sniffit http://reptile.rug.ac.be/~coder/sniffit/sniffit.html
Dsniff http://www.monkey.org/~dugsong/dsniff

Island Hopping Attack

Attacker initially takes over a machine via

some exploit
Attacker installs a sniffer to capture userIDs
and passwords to take over other machines

Figure 8.1 An island hopping attack

Passive Sniffers
Sniffers that passively wait for traffic to be

sent to them
Well suited for hub environment
Snort
Sniffit

Figure 8.2 A LAN implemented with a hub

Sniffit in Interactive Mode

Useful for monitoring session-oriented

applications such as telnet, rlogin, and ftp

Activated by starting sniffit with -i option
Sorts packets into sessions based on IP addresses
and port numbers
Identifies userIDs and passwords
Allows attacker to watch keystrokes of victim in
real time.
http://reptile.rug.ac.be/~coder/sniffit/sniffit.html

Figure 8.3 Using Sniffit in interactive mode to

sniff a userID and password

Switched Ethernet LANs

Forwards network packets based on the

destination MAC address in the Ethernet

header
Renders passive sniffers ineffective

Figure 8.4 A LAN implemented with a switch

Figure 8.5 A switched LAN prevents an

attacker from passively sniffing traffic

Active Sniffers
Effective in sniffing switched LANs
Injects traffic into the LAN to redirect

victims traffic to attacker

Dsniff
Active sniffer
http://www.monkey.org/~dugsong/dsniff
Runs on Linux, Solaris, OpenBSD
Excels at decoding a large number of

Application level protocols

FTP, telnet, SMTP, HTTP, POP, NTTP, IMAP,
SNMP, LDAP, Rlogin, RIP, OSPF, NFS, NIS,
SOCKS, X11, IRC, ICQ, Napster, MS SMB,
and SQL

Performs active sniffing using MAC

flooding or arpspoof

Dsniffs MAC Flooding

Initiated via Dsniffs Macof program
Foul up switches by sending out a flood of

packets with random MAC addresses

When switchs memory becomes full, the
switch will start forwarding data to all links
on the switch
At this point, Dsniff or any passive sniffer
can capture desired packets

Dsniffs Arpspoof
Used in switched environment where MAC

flooding does not work

defeats switches via spoofed ARP messages
Attackers machine initially configured with
IP forwarding to forward incoming
network traffic to a default router
Dsniffs arpspoof program activated to send
fake ARP replies to the victims machine to
poison its ARP table
Attacker can now sniff all traffic on the
LAN

Figure 8.6 Arpspoof redirects traffic, allowing

the attacker to sniff a switched LAN

Dsniffs DNSspoof
redirects traffic by sending false DNS

information to victim
Attacker initially activates arpspoof and
dnsspoof
When victim tries to browse a web site, a
DNS query is sent but the attacker sends a
poisoned DNS response
Victim unknowingly communicates with
another web server

Figure 8.7 A DNS attack using Dsniff

Sniffing HTTPS and SSH

Security is built on a trust model of underlying

public keys

HTTPS server sends to browser a certificate containing

servers public key signed by a Certificate Authority
SSL connection uses a shared session key generated by
client to encrypt data between server and client
With SSH, an encrypted session key is transmitted by
client using servers public key

Dsniff takes advantage of poor trust decisions made

by a clueless user via man-in-the middle attack

Web browser user may trust a certificate that is not signed

by a trusted party
SSH user can still connect to a server whose public key
has changed

Attacking HTTPS and SSH

via Dsniff
Webmitm
Sshmitm

Figure 8.8 In a person-in-the-middle attack, the attacker

can grab or alter traffic between Alice and Bob

Dsniffs Webmitm
Program used to proxy all HTTP and

HTTPS traffic
acting as an SSL proxy, webmitm can
establish two separate SSL connections
One connection between victim and attacker
One connection between attacker and web
server

Webmitm sends attackers certificate to

victim

Figure 8.9 Sniffing an HTTPS connection using dsniffs

person-in-the-middle attack

Figure 8.10 Netscapes warning messages for SSL

connections using certificates that arent trusted

Figure 8.11 Internet Explorers warning messages are

better, but not by much

Figure 8.12 Webmitms output shows entire content of SSLencrypted session, including the userID and password

Dsniffs sshmitm
Allows attacker to view data sent across an

SSH session
Supports sniffing of SSH protocol version 1

Dsniffs other Tools

Tcpkill
Kills an active TCP connection.
Allows attacker to sniff the UserID and
password on subsequent session
Tcpnice
Slows down traffic by injecting tiny TCP
window advertisements and ICMP source
quench packets so that sniffer can keep up with
the data
Filesnarf
Grabs files transmitted using NFS

Dsniffs other Tools (cont.)

Mailsnarf
Grabs email sent using SMTP and POP
Msgsnarf
Grabs messages sent using AOL Instant
Messenger, ICQ, IRC, and Yahoo Messenger
URLsnarf
Grabs a list of all URLs from HTTP traffic
Webspy
Allows attacker to view all web pages viewed
by victim

Sniffing Defenses
Use HTTPS for encrypted web traffic
Use SSH for encrypted login sessions
Avoid using Telnet
Use S/MIME or PGP for encrypted email
Pay attention to warning messages on your

browser and SSH client

Configuring Ethernet switch with MAC
address of machine using that port to
prevent MAC flooding and arpspoofing
Use static ARP tables on the end systems

IP Address Spoofing
Changing or disguising the source IP

address
used by Nmap in decoy mode
Used by Dsniff in dnsspoof attack
DNS response sent by Dsniff contains source
address of the DNS server

Used in denial-of-service attacks

Used in undermining Unix r-commands
Used with source routing attacks

Simple IP Address Spoofing

Pros
Works well in hiding source of a packet flood
or other denial-of-service attack
Cons
Difficult for attacker to monitor response
packets
Any response packet will be sent to spoofed IP
address
Difficult to IP address spoof against any TCPbased service unless machines are on same
LAN and ARP spoof is used

Figure 8.13 The TCP three-way handshake inhibits

simple spoofing

Undermining Unix r-commands

via IP Address Spoofing
When one Unix system trusts another, a user can log

into the trusted machine and then access the trusting

machine without supplying a password by using
rlogin, rsh, and rcp
hosts.equiv or .rhosts files used to implement trusts
IP address of trusted system used as weak form of
authentication
Attacker spoofing IP address of trusted system can
connect to trusting system without providing
password
Rbone tool http://packetstorm.security.com

Figure 8.14 Bob trusts Alice

Figure 8.15 Everyone trusts Alice, the administrators

main management system

Spoofing Attack against Unix Trust

Relationships

1.
2.

3.
4.
5.

6.

Attacker interacts with targeted trusting server to determine

predictability of initial sequence number
Attacker launches a denial-of-service attack (eg. SYN flood
or smurf attack) against trusted system to force it not to
respond to a spoofed TCP connection
Attacker rsh to targeted trusting server using spoofed IP
address of trusted server
Trusting server sends an SYN-ACK packet to the
unresponsive trusted server
Attacker sends an ACK packet to trusting server with a
guess at the sequence number. If ISN is correct, a
connection is made.
Although attacker cannot initially see reply packets from
trusting server, attacker can issue command to append ++
to hosts.equiv or .rhosts file. Trusting server will now trust
all machines. IP spoofing is no longer needed

Figure 8.16 Spoofing attack against Unix trust

relationships

Spoofing with Source Routing

Works if routers support source routing
Attacker generates TCP SYN packet destined for

trusting server containing spoofed IP address of

trusted machine and fake source route in IP header
Trusting server will reply with a SYN-ACK packet
containing a source route from trusting server to
attacker to trusted machine.
Attacker receives the reply but does not forward it to
the trusted machine.
Attacker can pose as trusted machine and have
interactive sessions with trusting machine

Figure 8.17 Spoofing attack using source routing

IP Spoofing Defenses

Make sure that initial sequence numbers generated

by TCP stacks are difficult to predict

Apply latest set of security patches from OS vendor

Used Nmap to verify predictability of ISN

Use ssh instead of r-commands

Avoid applications that use IP addresses for

authentication

Authentication should use passwords, PKI, or Kerberos

or other methods that tie a session back to a user.

Use anti-spoof packet filters at border routers

and firewalls

ingress (incoming) and egress (outgoing) filters

Block source-routed packets on routers

no ip sourceroute

Figure 8.18 Anti-spoof filters

Network-based Session Hijacking

Attack based on sniffing and spoofing
Occurs when attacker steals user session such as

telent, rlogin, or FTP.

Innocent user thinks that his session was lost, not stolen

Attacker sits on a network segment where traffic

between victim and server can be seen

Attacker injects spoofed packets contain source IP
address of victim with proper TCP sequence
numbers
If hijack is successful, server will obey all
commands sent by attacker.
May cause ACK storm between victim and server
when victim tries to resynchronize its sequence
number

Figure 8.19 A network-based session hijacking

scenario

Figure 8.20 An ACK storm triggered by session

hijacking

Host-based Session Hijacking

Attacker can hijack a session on source or

destination machine if he has super user privileges

on that machine
Highjacking tool allows attacker to interact with
the local terminal devices (tty)
Attacker can read all session information from
victims tty
Attacker can control victims tty by injecting
keystrokes into the tty
Host-based session hijacking preferable to
network-based session hijacking if target machine
is already compromised

Session Hijacking Tools

Network-based
Hunt http://www.cri.cz/kra/index.html
Dsniffs sshmitm tool in I mode
Juggernaut http://packetstorm.securify.com
Host-based
TTYWatcher
http://ftp.cerias.purdue.edu/pub/tools/unix/sysut
ils
TTYSnoop http://packetstorm.securify.com

Session Hijacking with Hunt

Runs on Linux platform
Allows attacker to see many sessions going across the

network and to hijack a particular session

ACK storm may occurs after attacker injects one or two
commands
ACK storm can be prevented running Hunt in a mode
supporting ARP spoofing
Dont want victims packets to be seen by server and visa versa
Attacker sends bogus ARP replies to both victim and server to
poison their ARP tables

Attacker sees traffic sent by victim and server

Hunt can resynchronize the connection so session can be

returned to victim
Message is sent to victim to type certain number of keys to
increment victims sequence number

Figure 8.21 Avoiding the ACK storm by ARP spoofing

Figure 8.22 The attackers view of a session hijacking

attack using Hunt

Figure 8.23 By ARP spoofing two routers between Alice and

Bob, all traffic between the routers (including the traffic
between Alice and Bob) will be directed through Eve

Session Hijacking Defenses

Use SSH or VPN for securing sessions
Attackers will not have the keys to encrypt or
decrypt traffic
Pay attention to warning messages about any
change of public key on server since this may
be a person-in-the-middle attack

Netcat
Network version of cat utility
Allows user to move data across a network using

any TCP or UDP port

Runs on both Unix and Windows NT
http://www.l0pht.com/~weld/netcat/
Netcat executable nc operates in two modes

Client mode allows user to initiate connection to any

TCP or UDP on a remote machine and to take input
data from standard input (eg keyboard or output of
pipe)
Listen mode (-l option) opens any specified TCP or
UDP port on local system and waits for incoming
connection and data through port. Data collected is sent
to standard output (eg. Screen or input of pipe)

Figure 8.24 Netcat in client mode and listen mode

Netcat for File Transfer

Useful for transfering files in/out networks

which block FTP sessions

File can be transferred by having netcat
client either push it or pull it

Figure 8.25 Pushing a file across the network using Netcat

Figure 8.26 Pulling a file across the network using Netcat

Netcat for Port Scanning

Note: verbose option will cause Netcat to display a

list of open ports on target machine

Connecting to Open UDP and TCP Ports

via Netcat

Vulnerability Scanning
using Netcat
Finds RPC vulnerabilities
Finds NFS exports whose file systems can

be viewed by everyone
finds machines with weak trust relationship
Finds machines with very weak passwords
Finds buggy FTP servers
Vulnerability scanning is limited compared
to Nessus

Using Netcat to Create a Passive Backdoor

Command Shell on any UDP/TCP port

Using Netcat to Actively Push a Backdoor

Command Shell to Attacker

Note: useful if firewall blocks inbound connections from

Internet

Relaying Traffic with Netcat

Netcat can be used to bounce an attack

across may machines controlled by an

attacker
One each relay machine, a Netcat listener is
configured to forward network traffic to a
Netcat client on same machine
Netcat client is configured to forward data
to another machine in the relay
Difficult to trace attacker especially if
relays cross language and political borders

Figure 8.27 Setting up relays using Netcat

Figure 8.28 Directing traffic around a packet filter,

using a Netcat relay

Creating a Netcat Relay

Modifying inetd.conf or
Setting up a backpipe

Using Inetd to create a Netcat Relay

Note: /etc/inetd.conf configured to have Netcat listen on port

11111 and forward traffic to port 54321 on host next_hop

Using a Backpipe to create a Netcat Relay

Note: Netcat setup to listen on port 1111, forwarding data to

next_hop on port 54321. The backpipe file is used to direct
response traffic back from destination to the source

Netcat Defenses
Configure firewall to limit

incoming/outgoing traffic to applications

(eg. DNS, email, WWW, FTP) that have a
business need
Systems should be listening only on ports
that have a business need
Systems should have the latest security
patches
Know what process are commonly running
on your systems so that you can rogue
server process