Archive for December, 2008


Exploiting the Internets

Dec 21, 2008 in Security

2 months ago I discussed a new flaw at the protocol level of the TCP stack (read it again  Outpost24 was supposed to release details of this exploit during the T2 Security conference in Finland on Oct 17th, but limited details have been released so far.  The best paper I could find describing this attack is at insecure’s website:

The basic idea is to first firewall your source address(es) using a command such as iptables (on Linux) to prevent your own OS from interfering with your attack. Next you create hundreds or thousands of connections to the TCP port you are targeting (such as port 80 of a web server) as follows:

1. Attacker sends a TCP SYN packet to the target port from his own IP address (or one he controls) to request a connection.
2. The target port is open, so it will respond with a SYN/ACK packet—the 2nd step of the TCP 3-way handshake. Remember that Attacker sent the SYN as a raw packet from userland rather than using his operating system’s connect() API to establish the connections. So when Attacker’s operating system’s TCP stack sees the unexpected SYN/ACK come back, it would normally destroy the nascent connection by sending a reset (RST) packet. This is why the special firewall rule was mentioned—to prevent such interference by Attacker’s OS. Instead Attacker’s DoS client handles all these packets by sniffing them from userland (generally using libpcap) and building/sending the raw reply packets.
3. Using the initial sequence number and other information from the SYN/ACK, Attacker sends an acknowledgment packet (the final step of the 3-way handshake) to complete the connection.

Acri Emanuele, had released a tool called Complemento ( that at a small scales accomplishes this.  Complemento includes a tool called LetDown that in essence is a tcp flooder that is based off of the Outpost24 finding (although doesn’t include the complete vulnerabilities listed from them.

During testing this tool, I did find it to be successful in small environments, but had limited success in large environments.  The attack relies on the completion of a successful 3 way handshake and the fact that you deplete the target’s resources.

For example, here I am attacking a simple webserver over port 80.  [image]  Although I don’t have images of the attackers box, it spawns over 10 apache processes on our attacker’s box and really doesn’t increase the process resources.  From the tcpdump logs, we can see that the 3 way handshake completes and then makes a get request.

The way this attack is successful is that it uses a lower level layer than the application layer (in this case using libnet) to build and send the raw packet replies.  So from the source device, we send the web server 1000+ syn requests.  At each syn request being sent, the webserver sends an syn-ack back.  This is a basic syn-flood, but this goes a bit further.  When the source device receives the syn-ack back from the server, the network device doesn’t understand why it received an syn-ack as it was a lower layer that had sent the request.  That is why LetDown, with the -f iptables switch, drops all resets being sent back to the webserver, keeping all connections open.  Now when LetDown sees the returned syn-ack, it sends an ack and a get request to the server.  This is going to keep thousands connections open.

Now what happens when this attack is successful and what does this mean?  Whether this attacks port 80 or 22 or whatever, it seems to take down that service.  Now that’s not the shocking part… we were able to take down a webserver from one attacking box and with very limited time.  If this protocol level flaw becomes exploited, it could lead to the 90’s all over again with the syn DoS attacks.  The end is near…

In addition with this tool:
“Once you have those thousands of open connections, you can get even nastier by sending malicious data payloads customized for the service you’re attacking.  For example, you can request a large file from web servers using each of your open connections. The server will then load the first part of that file into the OS TCP stack for sending, using precious kernel memory buffers. ”