EE579T
Network Security
9: An Introduction to Network-Based Attacks
Prof. Richard A. Stanley
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #1
Thought for the Day
“Everything should be made as simple
as possible. But not simpler.”
Albert Einstein
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #2
Overview of Tonight’s Class
• Review last week’s lesson
• Course project outlines
• Network attacks
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #3
Projects to
Present on April 17
• Team 1: 802.11?
– Xiangping Xu, Yang, Gao, Yingchun Xu
• Team 2: Mobile IP Security
– Phadnis, Misra, Shetty, Subramaniam
• Team 3: Secure Border Gateway Protocol
– Aytek, Baktir, Yadlon
• Team 4: Exploiting Firewall Rule Sets
– Kurtz, Barrett
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #4
Projects to
Present on April 17
• Team 5: deleted
• Team 6: Fibre Channel Security
– Elkind, Maki, Deshpande, Nat, Rongfred
• Team 7: Bluetooth Security
– Mason, Bouchard
• Team 8: Flawed WEP & Fixes
– Doraisami, Shirali, Shukla, Thurston
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #5
Projects to
Present on April 24
• Team 9: SNMP Vulnerability
– Staake, Peterson, Schweinsberg, Toczek
• Team 10: TCP Security Flaws
– Kavita, Anuj, Nikhil
• Team 11: Intrusion Detection
– Madhavi, Shankar, Rohan, Swathi
• Team 12: Network Worms
– Yuefeng, Wei, Xin
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #6
Projects to
Present on April 24
• Team 13:Web Services Security
– Geldmacher, Johnston,
• Team 14: DDoS
– Hill, Voduc, Huynh
• Team 15: S/W Firewalls
– Page, Poon, Ibrahim, Meawad, Leclerc
• Team 16: Honeypots
– Hartling, Lawson, Posluszny, Chung
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #7
Network Based Attacks
Oldies and Goodies--It Isn’t Magic
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #8
Word of Warning
• Some of the attacks about to be described
are as old as network attacks themselves
– This doesn’t make studying them a waste of
time
– There is nothing new under the sun -- old
attacks keep popping up in new clothes
“Those who do not study history are condemned
to repeat it.”
George Santayana
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #9
Getting Fingered
Aimee Girard (agirard)
Home: /usr3/agirard
Shell: /sh/tcsh
Building: Unknown
Work phone: Unknown
Directory: /usr3/agirard
Shell: /sh/tcsh
No unread mail.
Aimee Girard has never logged on.
No plan.
Home phone: Unknown
Andrew George Marut (agmarut)
Home: /usr2/agmarut
Shell: /sh/tcsh
Building: Unknown
Work phone: Unknown
Home phone: Unknown
Directory: /usr2/agmarut
Shell: /sh/tcsh
Mail forwarded to:
agmarut@wpi.edu
Andrew George Marut (agmarut) is not presently logged in.
Last seen on ece.wpi.edu at Tue Mar 27 03:06:03 2001
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #10
Do You Know Who?
ece(ttyp9):~> who
crcalvo
ttyp0
rcl
ttyp1
renato
ttyp2
anshul
ttyp4
pavan
ttyp5
lavanya
ttyp6
clements
ttyp7
aelliott
ttyp8
rstanley
ttyp9
bram
ttypa
gaubatz
ttypb
Spring 2002
© 2000-2002, Richard A. Stanley
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
WPI
14
20
20
20
19
20
20
20
20
20
20
17:52
07:53
08:38
09:18
04:08
08:53
09:45
10:46
12:18
10:42
10:42
EE579T/9 #11
TCP Review
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #12
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #13
TCP Actions
• Assumes IP addresses are valid and correct
• If sequence number received  sequence
number expected, packet is refused
(discarded), system waits for correctly
numbered packet
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #14
Sequence Number Prediction
• Determine server’s IP address
– Sniffing packets
– Trying host numbers in order
– Connect w/browser, observe address in status
• Try addresses in the server’s address space
• Monitor packet sequence numbers
• Predict and spoof the next sequence number
– Hacker now appears to be a legitimate user
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #15
Purpose, Detection & Defense
• Once on net as an internal user, hacker can
use net as a base for other attacks, or to
access information on the net just spoofed
• Detection: look for sequential “Access
denied” entries in the audit log
• Prevention: if available, enable real-time
notification of large number of sequential
access denial entries
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #16
SYN Flood
• Send a normal SYN packet to a server, as if
to open a TCP connection
• When the server returns a SYN/ACK
packet, ignore it
• Send another SYN packet to the server
• Repeat as necessary
• ...until server cannot handle any more
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #17
FINish, But Don’t Start
• Attacker sends FIN packet to server, but has
not previously established a TCP connection
• Server replies with RST packet
• Attacker now knows that port on that server
is alive and functioning
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #18
Passive Sniffing
• Hacker obtains access to network segment;
observes and analyzes traffic
– Unauthorized access to legitimate computer
(packet monitors standard NT/2000 fixture)
– Unauthorized added NIC on segment
• Purpose: gather intelligence, read traffic
• Defense:
– Secure authentication schemes (Kerberos)
– Data encryption
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #19
Desynchronization Attacks
• Hacker forces both ends of TCP session into
a desynchronized state
• Hacker then uses a third-party host (a
computer connected to the physical segment
under attack) to intercept original packets
and create acceptable replacement packets
that mimic the real ones that would have
been exchanged
• NB: desynchronized  disconnected
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #20
Post-Desynchronization
Hijacking - 1
• Assume:
– hacker can listen to any packet exchanged on a
TCP session
– hacker can forge any kind of IP packet desired
and replace the original with it
– session has been desynchronized
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #21
Post-Desynchronization
Hijacking - 2
• Client sends packet header with
– SEG_SEQ = CLT_SEQ
– SEG_ACK = CLT_ACK
• Because session has been desynchronized,
client packet sequence number (CLT_SEQ)
will never equal server’s expected sequence
number (SVR_ACK)
• Server therefore discards packet
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #22
Post-Desynchronization
Hijacking - 3
• Hacker copies server-discarded packet
• Hacker waits to give server time to discard
the packet
• Sends server same packet the client did, but
changes SEG_ACK, SEG_SEQ, &
checksum to:
– SEG_SEQ = SVR_ACK
– SEG_ACK = SVR_SEQ
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #23
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #24
Post-Desynchronization
Hijacking - 4
• The sequence numbers are now correct, so
the server accepts the packet the hacker sent
• Hacker must produce sequence data so that
– SEG_SEQ = (SEG_SEQ + CLT_TO_SVR_OFFSET)
– SEG_ACK = (SEG_ACK - SVR_TO_CLT_OFFSET)
• Where
– CLT_TO_SVR_OFFSET = SVR_ACK - CLT_SEQ
– SVR_TO_CLT_OFFSET = CLT_ACK - SVR_SEQ
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #25
Post-Desynchronization
Hijacking - 5
• Hacker now interposed between true client
and server
• All packets now routed through hacker
machine, so any desired commands can be
added to / removed from the payload
• Server responds to both client & hacker
requests; hacker filters his requests and
sends client requests to true client
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #26
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #27
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #28
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #29
ACK Storm
• Primary flaw of desynchronization attack
• Receipt of unacceptable packet generates
ACK packet to source with expected
sequence number
– First ACK packet from server contains server’s
own sequence number
– Client refuses packet, because it did not initially
send the modified-request packet
– Client now sends its own ACK packet, and ...
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #30
The End of the Storm
• In theory, the ACK storm is an infinite loop
• BUT…
– If ACK packet lost, no further ACK is sent,
because the packet contains no data payload
– TCP communicates over a lossy network (i.e.
packets will get lost)
– With non-zero packet loss, storm quickly ends
– Self-regulating
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #31
Early Desynchronization Attack -1
• Breaks client-server connection during the
setup stage
– Breaks on server side
– After break, hacker creates new connection
with a different sequence number
• Hacker listens for SYN/ACK exchange
• Hacker then sends server a RST, then
SYN/ACK with same parameters as client
packet, but with different sequence number
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #32
Early Desynchronization Attack -2
• On receipt of hacker’s RST packet, server
closes first connection, and opens new
connection on same port, but with a new
sequence number when it receives hacker
SYN. Sends SYN/ACK to original client.
• Hacker intercepts server SYN/ACK and
sends server its own ACK packet
• Server switches to synchronized connection
ESTABLISHED state
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #33
Early Desynchronization Attack -3
• Client had already switched to
ESTABLISHED state on receipt of first
SYN/ACK from server
• Attack success depends on hacker choosing
correct value of CLT_TO_SVR_OFFSET
– Wrong value makes both client and hacker
packets unacceptable
– Produces unwanted effects, including
disconnect
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #34
Early Desynchronization Attack -4
• The hacker now has an established
connection with the server, and looks just
like the real client
• Real client cannot establish a connection on
this port until the hacker disconnects,
because the server believes that the client is
already connected
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #35
Null Data Desynchronization
• TCP connection can be desynchronized by
sending large amount of null data to both
server and client
• Data not visible to client
• Sheer volume of data interferes with ability
to maintain the TCP session, and ultimately
desynchronizes connection
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #36
Telnet Session Attack - 1
• Hacker passively monitors session
• When appropriate, hacker sends large
volume of null data to server
• Hacker sends ATK_SVR_OFFSET bytes
containing sequence IAC NOP
– Server interprets these as null due to NOP
– Telnet daemon removes each byte pair from
data stream
– Reception of null data interrupts Telnet session
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #37
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #38
Telnet Session Attack - 2
• Server has now received commands
– SVR_ACK = CLTSEQ + ATK_SVR_OFFSET
– Telnet session now desynchronized
• Same procedure carried out with client to
desynchronize
• Early desynchronization attack carried out
• Hacker now establishes Telnet session with
server and client, becomes “man in middle”
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #39
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #40
Some Caveats
• Telnet session has to be able to carry null
data
• Timing is everything -- if null data sent at
wrong time, session may simply break
• If your Telnet session appears
unpredictable, you might be experiencing
an attack
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #41
More ACK Info
• All networks lose packets, so retransmission
occurs
• When an active attack such as described
before occurs, even more retransmission
occurs than in the normal course of events
• Extra packets due to the ACK storms
• One data packet can generate 10-300 empty
ACK packets
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #42
Detecting Attacks
• Detect desynchronized states
– Use packet reader (i.e., a sniffer) to view
sequence numbers at both ends of a connection
– Sequence numbers show if desynchronized
• Packet percentage counting
– Collect statistics on normal network operations
– Use statistics to detect packet storms resulting
from attacks
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #43
Spoofing
“You can fool all of the people some
of the time. You can fool some of the
people all of the time. But you can’t
fool all of the people all of the time.”
Abraham Lincoln
Fooling most of the people most of the time
is usually good enough!
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #44
IP Spoofing-1
• Hacker changes masquerade host IP address
to the trusted client’s address
• Hacker builds source route to server with
direct path packets should take to/from
server and back to hacker’s host, with
trusted client as last hop in route to server
• Hacker uses source route to send client
request to server
• What’s wrong with this picture?
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #45
IP Spoofing -2
• Simpler approach: wait until client system
shuts down and impersonate the system
– Example: Unix NFS uses IP only addresses to
authenticate clients
– Hacker sets up PC with name and IP address of
legitimate client, then initiates connection to
Unix host
– Typical “insider” attack, as needs knowledge of
which computers are not active
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #46
Spoofing E-mail
•
•
•
•
•
•
Open your email client
Change the “Name” field to something else
Change the “Email address” to something else
Delete the Incoming Mail Server address
Delete the value of Mail Server User Name
If you were really bad, you would find an
outgoing mail server that allowed anonymous
login for outgoing mail, and put its name here
• The approach above is good enough to fool most
people most of the time
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #47
Automated Spoofing
• C2MYAZZ
– Who knows to what this filename refers?
– Hijacks session without disrupting connectivity
– This clever utility exploits what was intended
as a feature for convenience and backwards
compatibility
– So, since this is well-known, the tool must be
hard to get or overtaken by events, yes?
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #48
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #49
Preventing Spoofing
• Firewall packet filtering
– Audit incoming traffic. You should never find
packets with source and destination addresses
in the local domain coming in from outside.
BUT…this takes lots of effort
– Don’t allow packets that appear to have
originated locally to come in from outside
• Hard, especially when hacker is inside
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #50
Buffer Overflows
• Sending oversize ICMP packets
• Sending IIS 3.0 a 4048 byte URL request
• Sending email with 256-character file name
attachments to Netscape/MS email clients
• SMB logon to NT with incorrect data size
• Sending Pine user an email with “from”
address > 256 characters
• Connect to WinGate POP3 port with user
name of 256 characters
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #51
What Do You Intend?
• Take over a session
– Why?
– What information do you want to get/put?
• Associate with a network more or less
permanently
• Deny service to selected servers / networks
/ clients?
• Anything else?
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #52
The Dreaded Cookie
# Netscape HTTP Cookie File
# http://www.netscape.com/newsref/std/cookie_spec.html
# This is a generated file! Do not edit.
home.netscape.com FALSE /
FALSE 942189161
cc98a714-14298-900987956-4
.doubleclick.net TRUE /
FALSE 1920499140
.netscape.com
TRUE /
FALSE 1293840000
24.128.181.249:0921530518:183152
www.netscape.com FALSE /
FALSE 942189161
cfc84b26-10757-921530518-1
.imgis.com TRUE /
FALSE 1078108157 JEB2
A80C29F3DBB5C25F1880B5F93004CF94
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
NGUserID
id3aa44cd0
UIDC
NGUserID
EE579T/9 #53
If You Don’t Like Cookies?
• Use a utility or your browser tools to
remove them (IE and Netscape 6 and later)
– Find them using the FIND function; they’re all
over the place (especially in Windows)
– But they keep coming back!
• In Windows, accept those you want, set the
C:/Windows/Cookies folder as Read Only
• In Unix, make cookies.txt zero-length R/O
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #54
Summary
• TCP/IP was not intended as a secure
protocol; as a result, it has vulnerabilities
that can be exploited
• There are many ways to get access to info
• There are many types of attacks that can be
mounted over network connections in order
to gain unauthorized access to resources
• Never forget, the best access is hands-on
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #55
Homework - 1
1. How would you prevent postdesynchronization hijacking attacks?
2. Research attack scenarios and tools that
you find in literature or on the Internet.
Describe two attack scenarios and the tools
required (if any) that would enable you to
break into the WPI network from outside.
Don’t actually break in, or try to!!
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #56
Homework - 2
3. Describe how a SMURF attack works
(don’t just parrot the description you find).
Describe how to stop it.
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #57
Assignment for Next Week
• Read course text, Chapter 14
• Next week’s topic: More Network-Based Attacks
Spring 2002
© 2000-2002, Richard A. Stanley
WPI
EE579T/9 #58