Network Attacks I

Network and System Security

Dr. Padmalochan Bera

Associate Professor (CSE)
School of Electrical Sciences
IIT Bhubaneswar
 Outline

• Various forms of Network Attacks

– Sniffing
– Spoofing and Hijacking
– DoS/DDoS
Sniffing
 Attacker is inside  Grab and file away:
firewall  userids and passwords
 Requirements  credit card numbers
 Attacker’s host  secret e-mail
connected to shared conversations
medium  Island hopping attack:
 NIC should be in  Take over single
“promiscuous mode” machine (eg virus)
• processes all frames
 Install sniffer, observe
that come to NIC
passwords, take over
 Sniffer has two more machines, install
components sniffers
 Capture
 Packet analysis
Passive sniffing
 Easy to sniff:
 802.11 traffic
 Ethernet traffic passing through a hub
• Any packets sent to hub is broadcast to all interfaces
• Not true for a switch
 Cable modem traffic
 Popular sniffers
 Wireshark
 tcpdump (for unix)
 Snort (sniffing and intrusion detection)
Active Sniffing through a switch

How does attacker sniff packets sent to/from the victim?

attacker

switch

victim

Have to get victim’s packets to attacker!

Sniffing through a switch: flooding
switch memory approach

Host sends flood of frames with random

source MAC addresses
 Switch’s forwarding table gets filled with bogus
MAC addresses
 When “good packet arrives,” dest MAC address
not in switch memory
 Switch broadcasts real packets to all links

 Sniff all the broadcast packets

Defenses
 Tie MAC addresses to switch ports
 Available on high-end switches
 Sophisticated configuration

 Give priority to existing mappings

 Only replace them when timeout expires
Sniffing through LAN: poison
victim’s ARP table approach
Idea: have client’s traffic (0) Sniff all frames that arrive.
Configure so that IP packets
diverted to attacker arriving from victim are
attacker
forwarded to default router

(1) Send fake ARP response,

mapping router IP address (3) Packets are
to attacker’s MAC address forwarded from
attacker’s host to
default router

victim (2) Victim sends traffic switch outside

destined to outside world.
default
world
Poisoned ARP table causes
traffic to be sent to attacker router
for LAN
Powerful sniffing tools
 Dsniff and ettercap
 Flooding switch memory
 ARP poisoning
Sniffing defenses
 Encrypt data: IPsec, SSL, PGP, SSH
 Get rid of hubs: complete migration to switched
network
 Use encryption for wireless and cable channels
 Configure switches with MAC addresses
 Turn off self learning (knowing mappings between ports
and MAC addresses)
 Eliminates flooding problem
 Intrusion detection systems:
 Lookout for large numbers of ARP replies

 Honeypot
 Create fake account and send password over network
 Identify attacker when it uses the password
IP address spoofing (1)
SA: [Link]
DA: [Link]

[Link] [Link]

 Attacker doesn’t want actions traced back

 Simply re-configure IP address in Windows
or Unix.
 Or enter spoofed address in an application
 e.g., decoy packets with Nmap
IP address spoofing (2)
[Link] SA: [Link] [Link]
DA: [Link]

attacker [Link]
victim
SA: [Link]
DA: [Link]

 But attacker cannot interact with victim.

 Unless attacker is on path between victim and
spoofed address.
IP spoofing with TCP?
 Can an attacker make a TCP connection to
server with a spoofed IP address?
 Not easy: SYNACK and any subsequent
packets sent to spoofed address.
 If attacker can guess initial sequence
number, can attempt to send commands
 Send ACK with spoofed IP and correct seq #,
say, one second after SYN
 But TCP uses random initial sequence
numbers.
Session hijacking
 Take control of one side of a TCP connection
 Marriage of sniffing and spoofing

Alice telnet

Bob
Alice

Attacker
Session hijacking: The details

 Attacker is on segment where traffic passes from

Alice to Bob
 Attacker sniffs packets
 Sees TCP packets between Bob and Alice and their
sequence numbers
 Attacker jumps in, sending TCP packets to Bob;
source IP address = Alice’s IP address
 Bob now obeys commands sent by attacker, thinking they
were sent by Alice
 Principal defense: encyrption
 Attacker does not have keys to encrypt and insert
meaningful traffic
Session hijacking: limitation
2. to resync, Alice
sends segment with
correct seq #

1. weird ACK # for

data never sent
Bob
Alice

Bob is getting segments Attacker’s solution:

from attacker and Alice. • Send unsolicited ARP replies
to Alice and Bob with non-existent
Source IP address same, Attacker MAC addresses
but seq #’s different. • Overwrite IP-to-MAC ARP tables
Bob likely drops • Alice’s segments will not reach Bob
connection. and vice-versa
• But attacker continues to hear Bob’s
segments, communicates with Bob
 Denial-of-Service
Prevent access by legitimate users or stop
critical system processes
 Connection flooding attack
 Implementation  Overwhelming connection
Vulnerability attack: queue with SYN flood
 Send a few crafted  Bandwidth flooding attack:
messages to target app  Overwhelming
that has vulnerability communications link with
 Malicious messages packets
called the “exploit”  Strength in flooding attack
 Remotely stopping or lies in volume rather than
crashing services content
DoS and DDoS
 DoS:
 source of attack small # of nodes
 source IP typically spoofed

 DDoS
 From thousands of nodes
 IP addresses often not spoofed

 Good book:
 Internet Denial of Service by J. Merkovic, D.
Dittrich, P. Reiher, 2005
Interlude: IP datagram format
32 bits total datagram
header length length (bytes)
ver head. type of length
(bytes) len service for
“type” of data fragment
16-bit identifier flgs fragmentation/
offset
max number time to upper reassembly
Internet
remaining hops live layer checksum
(decremented at
32 bit source IP address
each router)
32 bit destination IP address
upper layer protocol
to deliver payload to Options (if any)
data
(variable length,
typically a TCP
or UDP segment)
 IP Fragmentation and Reassembly
length ID fragflag offset
Example =4000 =x =0 =0
 4000 byte
One large datagram becomes
datagram several smaller datagrams
 MTU = 1500 bytes
length ID fragflag offset
=1500 =x =1 =0
1480 bytes in
data field length ID fragflag offset
=1500 =x =1 =185
offset =
1480/8 length ID fragflag offset
=1040 =x =0 =370
DoS: examples of vulnerability
attacks see [Link]
 Land: sends spoofed  Teardrop, Newtear,
packet with source and Bonk, Syndrop: tools
dest address/port the send overlapping
same segments, that is,
 Ping of death: sends fragment offsets
oversized ping packet incorrect.
 Jolt2: sends a stream
of fragments, none of Patches fix the problem,
which have offset of but malformed packet
0. Rebuilding consumes attacks continue to be
all processor capacity. discovered.
LAND
 Local Area Network Denial
 Spoofed SYN packet with source and
destination both being the victim
 On receipt, victim’s machine keep on
responding to itself in a loop
 Causes the victim to crash
 Many OSs are vulnerable, e.g.,
 Windows 95, NT, XP SP2
 Mac OS MacTCP
Ping of Death
 ICMP Echo Request (Ping) is 56 bytes
 If a ping message is more than 65536 bytes
(max for IP packet), this can cause some
machines to crash
 Older windows systems

Solution: patch OS, filter out ICMP packets

“Teardrop”, “Bonk” and kins
 TCP/IP fragments contain Offset field
 Attacker sets Offset field to:
 overlapping values
• Bad/old implementation of TCP/IP stack crashes when
attempting to re-assemble the fragments
… or to very large values
• Target system crashes

Solution: use up-to-date TCP/IP implementation

Connection flooding: Overwhelming
connection queue w/ SYN flood
 Recall client sends SYN  Attack: Send many SYN
packet with initial seq. packets, filling connection
number when initiating a queue with half-open
connection. connections.
 TCP on server machine  Can spoof source IP
allocates memory on its address!
connection queue, to track  When connection queue is
the status of the new half- exhausted, no new
open connection. connections can be
 For each half-open initiated by legit users.
connection, server waits
for ACK segment, using a Need to know of open port
timeout that is often > 1 on victim’s machine: Port
minute scanning.
SYN Flooding Attack
S
SYNC1 Listening…
SYNC2 Spawn a new thread,
store connection data
SYNC3 … and more
SYNC4 … and more

SYNC5 … and more

… and more

… and more
 SYN Flooding Explained
 Attacker sends many connection requests (SYNs) with
spoofed source addresses
 Victim allocates resources for each request
 New thread, connection state maintained until timeout
 Fixed bound on half-open connections
 Once resources exhausted, requests from legitimate
clients are denied
 This is a classic denial of service attack
 Common pattern: it costs nothing to TCP client to send a
connection request, but TCP server must spawn a thread for
each request - asymmetry!
 What’s another example of this behavior?
SYN flood Issue
amateur attack:

attacker
Connection queue
freed up with
RST segment
victim

Alice Expert attack: Use multiple source IP

addresses, each from unresponsive
addresses.
Preventing Denial of Service
(SYN Flood)
 DoS is caused by asymmetric state allocation
 If server opens new state for each connection
attempt, attacker can initiate many connections
from bogus or forged IP addresses
 Cookies allow server to remain stateless until
client produces:
 Server state (IP addresses and ports) stored in a
cookie and originally sent to client

 When client responds, cookie is verified

SYN flood defense: SYN cookies (1)
SYN with ISNA

SYN-ACK with ISNB= cookie

Host A Host B

 When SYN segment arrives, host B calculates

function (hash) based on:
 Source and destination IP addresses and port numbers,
and a secret number
 Host B uses resulting “cookie” for its initial seq #
(ISN) in SYNACK
 Host B does not allocate anything to half-open
connection:
 Does not remember A’s ISN
 Does not remember cookie
 SYN Cookies (2)
[Bernstein and Schenk]
C S
SYNC
Listening…

Compatible with standard TCP; Does not store state

simply a “weird” sequence number scheme
SYNS, ACKC
sequence # = cookie

Cookie must be unforgeable

F(source addr, source port, and tamper-proof (why?)
dest addr, dest port, Client should not be able
F=Rijndael or crypto hash coarse time, server secret) to invert a cookie (why?)

ACKS(cookie) Recompute cookie,

compare with with the one
received, only establish
connection if they match

More info: [Link]

SYN cookies (3)

If SYN is legitimate If SYN-flood attack

 Host A returns ACK with spoofed IP
 Host B computes same
address
function, verifies  No ACK comes back to
function = ACK # in B for connection.
ACK segment  No problem: B is not
 Host B creates socket waiting for an ACK
for connection What if Host A sends
 Legit connection only ACK (no SYN)?
established without  Will host B establish a
the need for half-open connection?
connections
Overwhelming link bandwidth with
packets
 Attack traffic can be made similar to
legitimate traffic, hindering detection.
 Flow of traffic must consume target’s
bandwidth resources.
 Attacker needs to engage more than one
machine => DDoS
 May be easier to get target to fill-up its
upstream bandwidth: async access
 Example: attacking BitTorrent seeds
 Distributed DoS: DDos
Attacker takes over many machines,
called “bots”. Potential bots are
machines with vulnerabilities.
bot

bot

attacker Internet

bot victim

bot processes wait

for command from
attacker to flood a target

bot
 DDoS: Reflection attack

DNS server

request reply
request
DNS server reply

request
attacker

reply
DNS server victim
request
reply
Source IP =
victim’s IP
DNS server
 “Smurf” Attack
Looks like a legitimate
“Are you alive?” ping
request from the victim
Stream of ping replies
1 ICMP Echo Req overwhelms victim
Src: victim’s address
Dest: broadcast address

Every host on the network router victim

generates a ping reply (ICMP
Echo Reply) to victim

Solution: reject external packets to broadcast addresses

DDoS: Reflection attack
 Spoof source IP address = victim’s IP
 Goal: generate lengthy or numerous replies
for short requests: amplification
 Without amplification: would it make sense?
 January 2001 attack:
 requests for large DNS record
 generated 60-90 Mbps of traffic

 Reflection attack can be also be done with

Web and other services
DDoS Defenses
 Don’t let your systems  Over-provisioning of
become bots resources
 Keep systems patched  Abundant bandwidth
up  Large pool of servers
 Employ egress anti-  ISP needs abundant
spoof filtering on bandwidth too.
external router.  Multiple ISPs
 Filter dangerous  Signature and anomaly
packets detection and filtering
 Vulnerability attacks  Upstream hopefully
 Intrusion prevention  Rate limiting
systems
 Limit # of packets sent
from source to dest