58
1 CSCD 434 Lecture 3 Network Protocol Vulnerabilities Spring 2012

1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

Embed Size (px)

Citation preview

Page 1: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

1

CSCD 434

Lecture 3Network Protocol VulnerabilitiesSpring 2012

Page 2: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

Outline

• Today– Define General Attacks on Network

Protocols– Define Why protocols are vulnerable– Look at attacks on network protocols

• TCP, UDP, IP, ICMP, ARP

– Next time• Other protocols BGP/DNS• Discussion of Papers

Page 3: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

History of Network Protocols

• Infrastructure protocols were designed when security concerns were almost non-existing

• Trust was assumed

• Recall early history of Internet• Connected major universities with government

labs ... in fact, commercial use was at first prohibited

• Main goal for DARPA Internet Program– Share large service machines on ARPANET

• Many protocol specifications focused only on operational aspects protocols

• Overlooked security implications ... Hey, we're all friends!!

Page 4: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

Vulnerabilities in Protocols

• During last twenty years, many vulnerabilities have been identified in the TCP/IP stacks of a number of systems

• Protocol weaknesses due to:

– Design of a given Protocol and– Daily operation and configuration

Page 5: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

Protocol Attack Techniques

• Sniffing Traffic– Eavesdropping on a network– “Wiretap” programs ... name one program– Wireless networks

• Easy to see all the traffic, put NIC into Monitor mode

– Wired networks• NIC needs to be in promiscuous mode• Must do ARP spoofing or other attack to get all

packets forwarded to you

– Can only see traffic from subnet you are tapped into

Page 6: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

Protocol Attack Techniques

• Flooding or Denial of Service– Preventing legitimate clients from

receiving service– Sending too many bogus requests to a

server– Tying up server with malformed packets

or packets out of sequence

Page 7: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

Protocol Attack Techniques

• Spoofing– Spoofing is faking parts of a packet– Usually, the address of the source– Can do spoofing for many different protocols

• Illegal Packets– Unexpected values in some of the fields– Cause machine to hang or crash

• Example: src address and port = dest address and port

• Illegal combination of flags in TCP protocol• Huge Ping packet - “Ping of Death”

Page 8: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

Which Protocols

• TCP/IP Protocol Suite– Application Layer - DNS– Transport Layer - UDP/TCP– Network Layer - IP/ICMP/BGP– Data Link Layer - ARP

Page 9: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

9

TCP/IP Problems

• Steve Bellovin – AT&T Bell labs researcher– One of the first to publicize problems in

the TCP/IP protocols– Wrote his original paper in 1989– Documented many problems– Some problems no longer relevant

Page 10: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

10

Problems Summary• Steve Bellovin

– TCP Sequence numbers not random• Can be predicted, leads to IP Spoofing attacks

– Trusted Hosts • Used remote Linux utilities to violate trust• Hardly ever used these days .. we won't cover

it

– ICMP Messages• Used them to perform DoS, routing re-direction

– Routing Protocols• RIP, BGP have authentication problems

– Domain Name Servers• Not secure

Page 11: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

11

TCP/IP Problems

• Look at a few of problems – IP Spoofing/TCP Protocol problems– ICMP Attacks– Arp Cache Poisoning

Page 12: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

TCP/IP Suite Problems• Problems

– Can you think of some problems with design of TCP/IP suite?

– IP addresses are not validated– Hosts can not be authenticated– Trivial to spoof packets as coming from a

trusted host– Remote utilities assumes trust between

hosts– Encryption not typically used, and not for

headers

Page 13: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

First .... TCP Review• SYN - First packet in a connection, indicates

host wants a connection• ACK - Used throughout entire connection to

ACKnowledge previously received packets• FIN - Used to indicate they are FINished

sending data, connection can be ended• RST- RST packet sent whenever host receives

an unexpected packet, such as an ACK with out ever receiving a SYN.

• Resets the connection

Page 14: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

TCP Handshake

C S

SYNC

SYNS, ACKC+1

ACKS+1

Listening

Store data

Wait

Connected

Page 15: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

TCP Syn Flooding

• How does it work?

Page 16: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

TCP Layer Attacks• TCP SYN Flooding

– Exploit state allocated at server after initial SYN packet

– Send SYN and don’t reply with ACK– Server will wait for 75 seconds for ACK– Finite queue size for incomplete

connections (1024)– Once queue is full doesn’t accept

requests

Page 17: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

SYN Flooding

C S

SYNC1 Listening

Store dataSYNC2

SYNC3

SYNC4

SYNC5

Page 18: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

SYN Flooding

• Attacker sends many connection requests– Spoofed source addresses of

machines that are not on-line

• Victim allocates resources for each request– Connection request exists until

timeout– Fixed bound on half-open connections

• DoS future requests rejected

Page 19: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

Syn Flood Solution

• TCP SYN cookies• General idea

– Client sends SYN w/ ACK number

– Server responds to Client with SYN-ACK cookie

sqn = f(src addr, src port, dest addr, dest port,

random seed)

• Server does not save state

– Honest client responds with ACK(sqn+1)

– Server checks response

– If matches SYN-ACK, establishes connection

Page 20: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

20

More TCP •TCP Uses Flags for State Coordination

Gets Sends Gets CommentSyn Syn-Ack Ack – Normal

connectionSyn/Ack RST – Out of sequence Fin/Ack RST – Out of sequence

Page 21: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

21

Steps in a TCP/IP Spoof Attack• Steps in general

– Eve – Evil machine, Alice and Bob – Innocent machines, Eve will violate trust of Alice and Bob

• Alice and Bob have a trusted relationship– Eve must figure out how ISN of Bob’s

machine changes– She is going to spoof Alice’s IP address

and pretend she is Alice– Eve also needs to prevent Alice from

sending a TCP Reset which will drop the connection to Bob

– Eve will then establish a real connection with Bob

Page 22: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

22

Steps in a TCP/IP Spoof AttackSteps in detail

– Eve – Evil machine, Alice and Bob – Innocent machines1. Eve sends many Syn packets to Bob

without spoofing. Uses her real IP addressTry to determine rate at which ISN’s from Bob’s machine are changing with time

2. Eve launches DoS attack against Alice. Syn flood Alice is overwhelmed for a time with trafficThis prevents Alice from sending a Reset to Bob which would result in Bob dropping spoofed connectionWhy would Alice send a Reset to Bob?

Page 23: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

23

Steps in an TCP/IP Spoof Attack

Alice

Eve

Bob

1. Many TCP connections, get ISN sequence

2. DoS against Alice, Syn flood

Page 24: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

24

Steps in a TCP/IP Spoof Attack

Steps in detail3. Eve initiates a connection to Bob using

Alice’s IP address4. Bob responds with Syn-Ack and his ISN This gets routed to Alice which normally

would have responded with a RST, But, she is busy with syn-attack

5. Using info from Step 1., Eve sends Ack to Bob with ISNB + 1 using Alice’s IP Address

Eve won’t see Bob’s response and ISNB to AliceIf guess is correct, she begins TCP connection pretending to be Alice

Page 25: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

25

Steps in an TCP/IP Spoof Attack

Alice

Eve

Bob

1. Many TCP connections, ISN sequence

2. DoS against Alice, Syn flood 3. Sends Syn (A,ISN

A)

4. Sends Ack (A,ISNA+1),

Syn (B, ISNB)

5. Sends Ack (B,ISNB+1)

Page 26: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

TCP Sequence Numbers

Need high degree of unpredictability If attacker knows initial seq number and

amount of traffic sent, can estimate likely current values

Send a flood of packets with likely seq numbers

Attacker can inject packets into existing connection

Most systems allow for a large window of acceptable sequence numbers Much higher success probability

Page 27: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

TCP ISN Prediction Tools• Nice paper on TCP attacks

http://osvdb.org/ref/04/04030-SlippingInTheWindow_v1.0.doc

• Good Sequence Number prediction tools include:– Mendax – Go to

http://www.packetstormsecurity.nl• Search for Mendax

– Dsniffhttp://monkey.org/~dugsong/dsniff/

Spoofit.h

http://www.isk.kth.se/~waseem/DK/lab/spoofit.h

Page 28: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

TCP/IP Spoofing Attacks

• Question is– Are these attacks still feasible today, 14

or 15 years later? See question in Assignment 2

Page 29: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

More TCP Attacks• Illegal Packets

– Send segment with both the SYN and FIN bit set Victim host processes SYN flag first,

– Generates a reply segment with the corresponding

– ACK flag set, and perform a state-transition to the state SYN-RCVD

– Then processes FIN flag, performs a transition to the state CLOSE-WAIT, and sends the ACK segment back to attacker ... no more packets sent from attacker

– Victim connection gets stuck in this state until keep-alive timer expires

Page 30: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

More TCP Attacks• Illegal Packets

– Attackers inject an RST segment into an existing TCP connection, causing it to be closed.

– The TCP Reset attack possible because– TCP endpoint must accept out of order packets

that are within range of a window size, and fact that Reset flags should be processed immediately

– How would this work?

Page 31: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

TCP Reset Attack• Established TCP connection from host A to host

B– Now, third host, C, spoofs packet that

matches source port and IP address of host A,– Destination port and IP address of host B, and

current sequence number of active TCP connection between host A and host B

• Host C sets RST bit on spoofed packet, so when received by host B, host B immediately terminates the connection

• This results in a denial of service, until connection can be reestablishedhttp://kerneltrap.org/node/3072

Page 32: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

32

IP Source Routing Abuse

• Routing Information Protocol (RIP)– Used to propagate routing information

on local networks– Routers need to exchange information

using routing protocols– Typically will exchange information

every so many seconds– IP Source routing feature

• Allows source machine to specify path packet will take through network

Page 33: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

Internet Protocol

• Connectionless– Unreliable– Best effort

• Datagram is – Header– Data

• Specify Options– Source Route

Version Header LengthType of Service

Total LengthIdentification

Flags

Time to LiveProtocol

Header Checksum

Source Address of Originating Host

Destination Address of Target Host

Options

Padding

IP Data

Fragment Offset

Page 34: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

34

IP Source Routing Abuse

• Attack in general - Example of MITM (Man-In-The-Middle) Attacks• Send bogus routing information trying to impersonate a particular host • Want packets to be sent to the attacker

machine • Attacker can intercept packets and gain

passwords, credit card numbers or other sensitive information

Page 35: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

35

Steps in Source Route Attack

Attack Steps (Same players, Eve, Alice and Bob)

1. Eve generates packets with fake source route

2. Packets claim to come from Alice3. Source route includes Eve’s IP

Eve looks like a router between Alice and Bob

4. Bob is the destination5. Routers between Eve and Bob read

source route and deliver packets to Bob via Eve

Page 36: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

36

Steps in Source Route Attack

Alice

Eve

Bob

Packet with Route

1. Alice

2. Eve

3. Bob

Packet with Route

1. Bob

2. Eve

3. Alice

Page 37: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

37

Steps in Source Routing Abuse

Attack Steps1. Bob responds by sending packets through

Eve to Alice2. Eve never forwards packets to Alice, doesn’t

need to even do a DoS on Alice

CommentThis attack doesn’t work across the InternetMost gateways block Source Routed packetsYet, not blocked on internal networksInsiders can get away with this type of attack

Page 38: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

38

Other Routing Vulnerabilities

Page 39: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

ICMP

• What is the ICMP protocol used for?– Internet Control Message Protocol (ICMP)– Mostly ... Used to send error messages– Requested service is not available, or that

host or router could not be reached

http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol

Page 40: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

ICMP Messages

• 0 Echo Reply• 3 Destination Unreachable• 4 Source Quench• 5 Redirect• 8 Echo Request• 11 Time Exceeded• 12 Parameter Problem• 13 Timestamp• 14 Timestamp Reply• 15 Information Request• 16 Information Reply

Page 41: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

ICMP Messages

• Destination Unreachable message– ICMP message generated by host or its

inbound gateway to inform client– Destination is unreachable for some reason– Destination Unreachable message may be

generated as a result of a TCP, UDP or another ICMP transmission

Page 42: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

ICMP Messages

• The Source Quench,– Message requests sender to decrease traffic

rate of messages to a router or host– Message may be generated if router or host

does not have sufficient buffer space to process the request, or

– May occur if router or host's buffer is approaching its limit

Page 43: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

43

ICMP Attacks

• Attacks Reported in Bellovin Paper

– ICMP Redirect message • Used by gateways to advise hosts of

better routes• Abused in same way as RIP• However more constraints on its use

– Tied to existing connection – Must only be sent from first gateway to

originating host

Page 44: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

44

ICMP Attacks

• Attacks Reported in Bellovin Paper– ICMP Redirect message

1. Host C sends a Syn packet to S via A, a router

2. Before packet can get there, Host X, our attacker sends an ICMP redirect for Host X to C spoofing the address A

3. C now redirects packets to X 4. X forwards packets to S to avoid

suspicion

Page 45: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012
Page 46: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

46

ICMP Attacks• ICMP Current Attacks

– ICMP Redirect • Still a threat if not ignored• Current recommendation is to turn off

redirects on CISCO routers• Routing protocol takes care of best

paths, hosts should ignore ICMP redirect messages

Page 47: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

47

ICMP Attacks• More Current Attacks• Other ways ICMP is used to

compromise• ICMP Source Quench

– Slows down transmission of traffic essentially performing a partial DoS on itself

• ICMP DoS Attacker could use either ICMP Time

exceeded or Destination unreachable messages. Both messages can cause host to drop a connection

Attacker can simply forge one of these ICMP messages, and send it to one or both communicating hosts ... their connection will then be broken

Page 48: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

48

ICMP AttacksMore Attacks• SMURF Attack• Generate ping stream (ICMP echo request)

• Network broadcast address• Spoofed source IP set to victim host

• Every host on ping target network will generate ping reply (ICMP echo reply)

• Amplified ping reply stream can easily overwhelm victim’s network connection

Page 49: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

Smurf Attack

Page 50: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

ARP Cache Poisoning• What's the problem?

– No authentication !!!!!– Ethernet, designed without ANY authentication

technology whatsoever– So it is trivial for ANY computer with access to

an Ethernet LAN,• Re-route any other computer's traffic through

itself simply by impersonating one or more other computers

• One computer can re-route ALL of the LAN's traffic through itself

• Monitor and edit or alter anything sent to or received from any other machine on the local network.

Page 51: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

ARP Cache Poisoning

• How Does ARP Work Normally?– Packet comes in through router, has IP Address– If no known MAC address in ARP table– Sends broadcast to all of the computers on the LAN

• Asks which computer has IP address of packet gateway is trying to forward

• Broadcasts ARP Request received by every computer on the Ethernet LAN

• Each computer checks to see whether IP is its own

• Computer finding a match will send an ARP Reply back to the requesting device

Page 52: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

ARP Cache Poisoning

• How is the Cache Poisoned?– Receipt of an ARP reply,

• Causes receiving computer to add newly received information to its ARP cache

– If gateway computer receives SPOOFED ARP REPLY from attacking computer claiming it was assigned IP belonged to some other computer

• Gateway would trustingly and blindly REPLACE its current correct entry with misleading replacement!

• And, sending ARP reply to computer being hijacked, would replace ARP entry for gateway computer

– Subsequent traffic bound for gateway would instead be sent to the attacking computer

Page 53: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

ARP Cache Poisoning

Replace both ARP entries with Attacker MAC address and gain access to all Green's traffic

Page 54: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

Solutions for ARP Cache Poisoning

No Universal defense.

• Use static ARP entries

– Cannot be updated

– Spoofed ARP replies are ignored.

– ARP table needs a static entry for each machine on

the network.

– Large overhead

• Deploying these tables

• Keep the table up-to-date

Page 55: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

Solutions for ARP Cache Poisoning

• Arpwatch– A free UNIX program listens for ARP replies on a network– Build a table of IP/MAC associations and store it in a file– When a MAC/IP pair changes, an email is sent to

an administrator• RARP (Reverse ARP)

– Requests the IP of a known MAC.– Detect MAC cloning.– Cloning can be detected, if multiple replies are received for a single RARP

Page 56: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

ARP Cache Poisoning

• Tools ettercap http://ettercap.sf.net

Poisoning Sniffing Hijacking Filtering SSH v.1 sniffing (transparent attack)

dsniff http://www.monkey.org/~dugsong/dsniff Poisoning Sniffing SSH v.1 sniffing (proxy attack)

Page 57: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

57

Conclusion

• TCP/IP was never designed to be a secure protocol– Architecture flaw sequence numbers have

no security properties– IP addresses - no authentication– Supporting protocols can be subverted

• ICMP, DNS, BGP•

Some problems have been fixed

– Less address authentication being used– More crypto protocols for remote login, e-

mail, web browsers

Page 58: 1 CSCD 434 Lecture 3 NetworkProtocol Vulnerabilities Spring 2012

58

End

• Next time– There will be a lab next week– Finish network protocol vulnerabilities– Read papers, do the questions