EE579T_GD/5 #1 Summer 2003 © 2000-2003, Richard A. Stanley EE579T Network Security 5: An...

63
Summer 2003 © 2000-2003, Richard A. Stanley EE579T_GD/5 #1 EE579T Network Security 5: An Introduction to Network- Based Attacks Prof. Richard A. Stanley
  • date post

    19-Dec-2015
  • Category

    Documents

  • view

    215
  • download

    0

Transcript of EE579T_GD/5 #1 Summer 2003 © 2000-2003, Richard A. Stanley EE579T Network Security 5: An...

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #1

EE579TNetwork Security

5: An Introduction to Network-Based Attacks

Prof. Richard A. Stanley

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #2

Thought for the Day

“Everything should be made as simpleas possible. But not simpler.”

Albert Einstein

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #3

Overview of Today’s Class

• Review last two week’s lessons

• Network attacks

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #4

Last two times...

• Attacking a network is no different from robbing a bank; you have to plan if you expect to be successful

• There are three basic steps to planning, which is called vulnerability assessment:– Acquire the target (case the joint)

– Scan for vulnerabilities (find the entry points)

– Identify poorly protected data (enumeration)

• This applies if you are inside or outside the protected perimeter!

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #5

SSL Handshake OverviewClient Server

1. Supported ciphers, random number

2. Cipher choice, certificate, random number

3. PreMasterSecret (encrypted in server’s public key)

Verify certificate,Generate

PreMasterSecret

4. Generate keys4. Generate

keys

6. HMAC over handshake messages received

5. HMAC over handshake messages sent

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #6

Network Based Attacks

Oldies and Goodies--It Isn’t Magic

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #7

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 condemnedto repeat it.”

George Santayana

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #8

Target Acquisition

?

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #9

TCP Review

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #10

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #11

TCP Assumptions

• Assumes IP addresses are valid and correct

• If sequence number received sequence number expected, packet is refused (discarded); system waits for correctly numbered packet– If correct packet doesn’t arrive before the timer

winds down, then a retransmission occurs

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #12

TCP Handshake OverviewClient Server

1. SYN

2. SYN, ACK

3. ACK

What if Step 3 never happens?

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #13

Getting Fingered

Aimee Girard (agirard)Home: /usr3/agirardShell: /sh/tcshBuilding: Unknown Work phone: Unknown Home phone: UnknownDirectory: /usr3/agirardShell: /sh/tcshNo unread mail.Aimee Girard has never logged on.No plan.

Andrew George Marut (agmarut)Home: /usr2/agmarutShell: /sh/tcshBuilding: Unknown Work phone: Unknown Home phone: UnknownDirectory: /usr2/agmarutShell: /sh/tcshMail forwarded to: [email protected] George Marut (agmarut) is not presently logged in.Last seen on ece.wpi.edu at Tue Mar 27 03:06:03 2001

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #14

Do You Know Who?

ece(ttyp9):~> whocrcalvo ttyp0 Mar 14 17:52rcl ttyp1 Mar 20 07:53renato ttyp2 Mar 20 08:38anshul ttyp4 Mar 20 09:18pavan ttyp5 Mar 19 04:08lavanya ttyp6 Mar 20 08:53clements ttyp7 Mar 20 09:45aelliott ttyp8 Mar 20 10:46rstanley ttyp9 Mar 20 12:18bram ttypa Mar 20 10:42gaubatz ttypb Mar 20 10:42

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #15

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #16

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #17

Enumeration

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #18

Finding out What’s There

• Scans– Stealthy– Not so stealthy

• Fingerprinting

• Tools– Nmap– Retina (eeye.com)– ...etc.

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #19

Attacks

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #20

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #21

SYN FloodClient Server

1. SYN

2. SYN, ACK

Repeat quickly, over and over.After awhile, the server is able to donothing except wait for the pending

connections. Thus, DoS.

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #22

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #23

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #24

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #25

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #26

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #27

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #28

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #29

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #30

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #31

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #32

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #33

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #34

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 ...

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #35

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #36

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #37

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #38

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #39

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #40

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #41

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #42

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #43

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”

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #44

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #45

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #46

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #47

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #48

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 timeis usually good enough!

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #49

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?

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #50

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #51

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #52

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?

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #53

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #54

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #55

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #56

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?

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #57

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 NGUserIDcc98a714-14298-900987956-4

.doubleclick.net TRUE / FALSE 1920499140 id3aa44cd0

.netscape.com TRUE / FALSE 1293840000 UIDC24.128.181.249:0921530518:183152

www.netscape.com FALSE / FALSE 942189161 NGUserIDcfc84b26-10757-921530518-1

.imgis.com TRUE / FALSE 1078108157 JEB2A80C29F3DBB5C25F1880B5F93004CF94

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #58

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #59

How to Keep Up?

• Common Vulnerabilities and Exposures – http://www.cve.mitre.org/

• CVE is– A dictionary, NOT a database– A community effort– Freely available

• In short, this is not a “how to hack” list

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #60

What About Hacker Sites?

• Can provide an idea of the current state of affairs, and also toolkits

• BE CAREFUL!– What you download may come with little

“surprises”• If you download, quarantine and test

– These sites don’t just exist to serve hackers; some also exist to hack

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #61

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

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #62

Homework - 1

1. How would you prevent post-desynchronization 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!!

Summer 2003© 2000-2003, Richard A. Stanley

EE579T_GD/5 #63

Homework - 2

3. Describe how a SMURF attack works (don’t just parrot the description you find). Describe how to stop it.