Hacking from a network: SYN flood and TCP Sequence number prediction attacks

The SYN flood attack exploits the limit of the number of connections that are waiting to be established... Resources are finite • Either the system would continue to allocate memory eac

Hacking from a network

SYN flood and TCP Sequence number prediction attacks

Greetings This is the oldie, but goody section of the course This next section is important for a number of reasons

If you think about it, attacks occur in stages In general the attacker has to perform reconnaissance to hone in on the target, to find the weaknesses Then there will be an initial attack, this is often minimal, in the book Network Intrusion Detection we referred to this as the “grappling hook” Finally, the attacker completes the kill This attack shows each of these stages

This attack took 16 seconds to complete When we were discussing automated response, we used 16 seconds as a measuring rod How fast can you run? How fast can you type?

Finally, you really can’t run around in intrusion detection circles if you are not familiar with the called Mitnick attack

What we will cover

– Tsutomu Shimomura example

The information on the Mitnick attack is drawn primarily from Shimomura’s post on the subject The initial header of the news posting is shown below

Source: tsutomu@ariel.sdsc.edu (Tsutomu Shimomura), comp.security.misc Date: 25 Jan 1995

**************************************************************************There seems to be a lot of confusion about the IP address spoofing and connection hijacking attacks described by John Markoff's 1/23/95 NYT article, and CERT advisory CA-95:01 Here are some technical details from my presentation on 1/11/95 at CMAD 3 in Sonoma, California

4500 0030 dddf 0000 3406 b94c a63e 5cd7 C0A8 0101 12e8 0438 0387 1f33 0000 0000 7002 2000 3d45 0000 0204 0218 0101 0402

As you know the IP header is 20 bytes, the second digit as a 5 tell us there are no options set for this header The IP header:

4500 0030 dddf 0000 3406 b94c a63e 5cd7 C0A8 0101

Has no idea how to interpret the higher layer, the TCP header It doesn’t know the DEST port is

1080 (socks or wingate) as shown by the 0x0438 If something goes wrong at this layer, at most, the

IP layer will encapsulate part of the message in an ICMP packet and return it

TCP Header - SYN Flag

Data Frame Header

Data TCP Header

Source

Port

Sequence No.

Destination

Port

ACK No.

HDR Length Flags A C K

Window Size Check- sum Urgent Offset Options

U R G

P S H

S Y N

R S T

F I N

20 Bytes

We may also refer to a SYN packet as an active open

As you know, the SYN is located on byte 13 of the TCP Header, the pattern we see for byte 13 in our sample trace is 0x02 in the block 0x7002

4500 0030 dddf 0000 3406 b94c a63e 5cd7 C0A8 0101 12e8 0438 0387 1f33 0000 0000 7002 2000 3d45 0000 0204 0218 0101 0402

Again as we move forward in this section, it will be important to establish that the IP header will never care that a higher level protocol is sending a SYN

TCP cares though in a big way and as you know would respond with a SYN/ACK if it was an open port and it was willing to talk on that port Once the server sends the SYN/ACK, the server is committed to the connection, and the connection is considered established

Server Memory

• TCP is stateful, so the server must

keep track of all these various

condition states and sequence

numbers, in BSD:

– Socket stuff (program interface to

networking) – IP stuff

"The Internet is an outgrowth of a project from the 1970's by the US Department of Defense

Advanced Research Projects Agency (ARPA) The ARPANET, as it was then called, was designed

to be a non-reliable network service for computer communications on over wide area In 1973 and

1974, a standard networking protocol, a communications protocol for exchanging data between computers on a network, emerged from the various research and educational efforts involved in this project This became known as TCP/IP or the IP suite of protocols The TCP/IP protocols enabled ARPANET computers to communicate irrespective of their computer operating system or their computer hardware */

u_char ip_v:4, /* version */

#endif

u_char ip_tos; /* type of service */

u_short ip_id; /* identification */

short ip_off; /* fragment offset field */

#define IP_DF 0x3000 /* dont fragment flag */

#define IP_MF 0x4000 /* more fragments flag */

u_char ip_ttl; /* time to live */

u_char ip_p; /* protocol */

u_short ip_sum; /* checksum */

struct in_addr ip_src, ip_dst; /* source and dest address */

};

All it takes is memory (and plenty of it)

If you aren’t a C programmer, don’t worry A struct, in this case struct ip, can be thought of as a database record and the items inside as fields for that record Every time a new connection is processed, these structs have to be created for socket, ip, and other protocol information That takes memory Since memory is finite and was particularly limited during the early days of IP network implementation, limits had to be set The SYN flood attack exploits the limit of the number of connections that are waiting to be established

Resources are finite

• Either the system would continue to

allocate memory each time a TCP

connection is established, (SYN packet is

received), OR

• Establish a finite number of concurrent

connections with a waiting queue of

stuff still in the 3 way handshake phase,

(not yet established connections) This

queue is fairly small (5 - 10).

The designers of TCP protocol stacks had a decision to make and they chose to make a small number

of connections waiting to happen I wanted to remind you of the three-way hand shake in hopes of getting you to think about all the things that have to happen If you consider the struct on the previous slide, think about the resources required, there are 12 fields in an IP header alone The TCP header has options set so it has more than a minimum number of 15 This is one reason a server is never committed to a connection simply because it receives a SYN!

Back then, believe it or not the Internet was not 100% reliable as it is today ☺ and they decided to prioritize established connections over connections waiting to be established That was perfectly reasonable

More on state

Active Internet connections (including servers)

Proto Recv-Q Send-Q Local Address Foreign Address (state)

NOTE: queues, state, think memory

As we continue to set the stage we see a system with connections in a variety of states See the CLOSE_WAIT? That is waiting for an acknowledgement of a FIN The LISTENS are active ports

or services waiting for an incoming packet

This is the output of netstat -a on a Unix system though you can type the same command on Windows and we recommend you try it from time to time, it can be very educational This is to demonstrate that a connected system may have multiple active connections at one time, each requiring memory

NOTE: some security professionals do not fully trust the output from Windows netstat There is a replacement netstat on securify.packetstorm.com that you might want to evaluate

Until timeout

When an attacker sets up a SYN flood, he has no intention of completing the three-way handshake and actually establishing the connection Rather, the goal is to exceed the limits that are set for the number of connections waiting to be established This can cause the system under attack to be unable to establish any additional connections until the number of waiting connections drops below the threshold Until the threshold limit is met, each SYN packet generates a SYN/ACK that stays in the queue, which is generally between five and ten total connections waiting to be established

There is a timer for each connection, a limit to how long the system will wait for the connection to be established The hourglass in your slide represents the timer that is usually set for about a minute When the time limit is exceeded, the memory that holds the state for that connection is released and the queue is decremented by one Once the limit has been reached, the queue can be kept full, preventing the system from establishing new connections with about ten packets per minute

Basics of the SYN attack

• SYN, but do not complete 3 Way

handshake

• Make server believe a non existent host

is the client (host unreachable) by IP

Spoofing, so the SYN/ACKs go nowhere.

• Only takes a few (5 - 10) SYNs to seal

off a service for the period of the timer,

60 - 100 seconds

Now we are down to the close, the attacker is taking advantage of the engineering tradeoff of limiting the number of active queues Older operating systems react very poorly to this condition and are rendered unable to communicate Yup, that is right, if their queue filled up because of incoming packets they were unable to process outgoing packets on that service This particular problem is fixed on most modern operating systems

Duration of attack

6 - 10 SYNs every minute or so will disable

a service until the attacker decides to:

go away and SYN no more.

This was an elegant attack, for a small number of packets an attacker could freeze a particular service on a host computer

IP Spoof Handwaving

• How do we spoof the target so that the

sender appears to be an unreachable

host?

– We need a real routable to, unreachable

host, such as a PC that gets turned off at night and so forth.

– We need to assemble the packet ourselves

or else the OS would put in the correct SRC Address.

If the spoofed computer was reachable it would send a packet with the RESET flag set That, in essence says: what are you talking about with a SYN/ACK ? I never asked for a connection That pattern is shown below

06:44:09 srn.com.113 > 192.168.162.67.2226: S 761:761(0) ack 674win 8192 06:44:09 192.168.162.67.2226 > srn.com.113: R 674:674(0)win 0

When the target computer received the reset packet, it would simply release its connection and recycle the memory So what we must do now is create a forged packet We must lie about our source address as the sender, and claim we are some other IP address This is often called spoofing The characteristics of this IP address are that it is valid, routable to, and not active or reachable Many sites have a large number of unused IP addresses and do not employ network address

translation They tend to be the stars of this particular show

Build the packet

/* Packet assembly begins here */

/* Fill in all the TCP header information */

packet.tcp.source=sport; /* 16-bit Source port number */

packet.tcp.dest=htons(dport); /* 16-bit Destination port */

packet.tcp.seq=49358353+getpid(); /* 32-bit Sequence Number */

packet.tcp.ack_seq=0; /* 32-bit Acknowledgement Number */

packet.tcp.doff=5; /* Data offset */

packet.tcp.res1=0; /* reserved */

packet.tcp.res2=0; /* reserved */

packet.tcp.urg=0; /* Urgent offset valid flag */

packet.tcp.ack=0; /* Acknowledgement field valid flag */

packet.tcp.psh=0; /* Push flag */

packet.tcp.rst=0; /* Reset flag */

packet.tcp.syn=1; /* Synchronize sequence numbers flag */

packet.tcp.fin=0; /* Finish sending flag */

packet.tcp.window=htons(242); /* 16-bit Window size */

packet.tcp.check=0; /* 16-bit checksum (to be filled in below) */ packet.tcp.urg_ptr=0; /* 16-bit urgent offset */

The code fragment on your slide is taken from the actual exploit code

We can see we are assembling a packet, building all the fields we discussed If we may draw your attention to the third line down, packet.tcp.seq=49358353+getpid(); check that out, for a sequence number they take the processID and add a constant to it As we study packets for evidence of crafting, it is coding techniques like this that help us know the packet was probably crafted That sequence number will have a particular signature, in fact, you could even say it might be somewhat predictable!

Put the wrong src in the

packet

/* Fill in all the IP header information */

packet.ip.version=4; /* 4-bit Version */

packet.ip.ihl=5; /* 4-bit Header Length */

packet.ip.tos=0; /* 8-bit Type of service */

packet.ip.tot_len=htons(40); /* 16-bit Total length */

packet.ip.id=getpid(); /* 16-bit ID field */

packet.ip.frag_off=0; /* 13-bit Fragment offset */

packet.ip.ttl=255; /* 8-bit Time To Live */

packet.ip.protocol=IPPROTO_TCP; /* 8-bit Protocol */

packet.ip.check=0; /* 16-bit Header checksum (filled in below) */ packet.ip.saddr=sadd; /* 32-bit Source Address */

packet.ip.daddr=dadd; /* 32-bit Destination Address */

In this slide we continue to build our fake packet Note the IPID and the Sequence number will have

a relation since the IPID is based on the getpid() call The most important thing to focus on though is the spoofed address

In intrusion detection it is critical to be aware that a large number of the detects that one gets have an incorrect source address Because of proxy servers and ftp bounce this is as true for TCP as it is for UDP and ICMP We had an entire class of over 200 hundred students in intrusion detection evaluate

a series of network traces and calculate the probability that the source address was spoofed None of them mentioned checking the source address to see if it was from a well known proxy! That means

we need to teach harder from now on

And so we see this packet craft code includes supplying the spoofed source address

Most intrusion detection systems and network analysis tools are not configured to find the relation between the IPID and the Sequence number, but the good news is many of them display both so a good analyst can find this In fact, there are times when we can point back to the precise exploit or DoS code the attacker used by the signature of the packet

Error Checking is Good

- Write documentation

- Build in error checking

Here we have free attacker software with error checking, such a shame! When the attacker enters an address, the attack code pings the address to ensure it meets these requirements If the address was active it would send a RESET when it received the SYN/ACK for the system that is under attack When the target system received the RESET it would release the memory and decrement the service queue counter rendering the attack ineffective From an intrusion detection standpoint, these bogus packets that are assembled for the purpose of attacking and probing can be called crafted packets Quite often, the authors of software to craft packets make a small error at some point, or take a shortcut, and this gives the packet a unique signature We have shown two of them in this code, the sequence number and the IPID We can use these signatures in intrusion detection so that if such a crafted packet is used, we know that something is up

More About IP Spoof

• Faking the source host address to

be an unreachable host is a trivial

example with limited application

• Appearing to be a trusted host

opens a myriad of possibilities

OK, it is great that we have this denial of service Now we will build on the denial of service and actually compromise the target computer And keep in mind that while this technique is no longer state of the art, there are other denial of service techniques that can be used

Also, the key points of this section are quite valid today and probably tomorrow as well

- Engineering tradeoffs and designing for fixed values can create a vulnerability

- When attackers exploit these vulnerabilities, it can have catastrophic consequences never

considered by the designers

- IP addresses are commonly spoofed, this often requires crafted packets

- When attackers craft packets there are often tale tell signs that serve as signatures It is sometimes possible to tie a packet back to particular exploit code by its signature