TCP DoS Attack

Tra il 30 Settembre ed il 2 Ottobre 2008 ha iniziato a girare la notizia che due ricercatori svedesi, Robert Lee e Jack Louis di Outpost24, avrebbero scoperto una serie di pericolose vulnerabilità nello stack TCP di Internet. Queste vulnerabilità permetterebbero di portare a termine un devastante attacco DoS contro qualunque server di Internet senza che il gestore del server abbia modo di reagire. Vediamo cosa se ne sa e cerchiamo di capire se c’è da preoccuparsi.

Il sibillino annuncio di Outpost24

L’annuncio, in realtà, è del 27 di Agosto ed è stato dato come “aggiornamento” di un talk già previsto alla conferenza T2-08 che si terrà il 16 e 17 Ottobre a Helsinki in Finlandia:

“As you might have noticed the schedule for T2´08 was already published a while ago. However, we’ve received such an unusual submission that we have decided to include it to the schedule. Effectively this means that we have replaced the second part of “Iceberg Incorporated – A Peek Under the Surface of the Criminal Enterprise” with this new talk. And now about this new talk …

Jack C. Louis and Robert E. Lee from Outpost24 will divulge new technical details about TCP state table manipulation vulnerabilities that affect availability.

Specifically this talk will showcase new attacks that will render a remote system unavailable using a very low bandwidth attack stream. Attacks against Windows, BSD, Linux, and embedded systems TCP/IP stack implementations will be discussed and demonstrated.”

[Da “Jack C. Louis and Robert E. Lee to talk about New DoS Attack Vectors”]

Inutile dire che questo modo “sibillino” di annunciare una vulnerabilità così grave, devastante e pervasiva ha irritato più di un osservatore, tra cui l’autore di NMap, Fyodor:

“While I know and respect these researchers, I’ve had enough of the recent spate of people announcing (supposedly) massive security vulnerabilities, then refusing to back up their claims with details until a talk weeks or months away. Obviously Dan Kaminsky ignited this recent trend with his DNS flaw. While many of the researchers are earnest and call this “responsible disclosure”, it often reeks like a PR campaign. When you tell the press that you’ve discovered a core Internet protocol flaw so severe that you can’t even provide any details for fear that the entire network could come crashing down, they just eat that up and it devolves into a media circus.”

[Da “Explaining the “New” TCP Resource Exhaustion Denial of Service (DoS) Attack”]

L’analisi di Fyodor

Il 2 Ottobre Fyodor ha presentato una sua personale analisi di questa vulnerabilità:

“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. Then 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 your own IP address (or one you control) 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 application handle 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.

Every open TCP connection uses significant resources on the target machine (various state in the kernel TCP stack, application memory, a socket descriptor, etc.) Many web servers and other daemons fork (or at least occupy) a whole OS process for each concurrent connection. Yet the steps above consume very few resources on the attacker side. So you can simply repeat the steps hundreds or thousands of times until the target exhausts one of its critical resources and malfunctions. As an attacker, you need a unique source port for each connection you make to a single port on a target system. This limits you to 65,535 connections per source IP address you control. Some major web sites may be so well-tuned that they can handle that many concurrent connections and you need to go after them from multiple IPs.”

[Da “Explaining the “New” TCP Resource Exhaustion Denial of Service (DoS) Attack”]

In buona sostanza, l’attacco consisterebbe nell’aprire migliaia di richieste di connessione TCP sulla macchina bersaglio usando uno strumento semplice ed efficiente come Ndos (“Network Denial of Service”). Ndos consuma poche risorse (cicli macchina, memoria, etc.) sulla macchina dell’attaccante ma, ad ogni richiesta, ne consuma molte sulla macchina bersaglio. Di conseguenza, dopo una serie di richieste, la macchina bersaglio si inchioda irreparabilmente mentre la macchina attaccante continua tranquillamente a inviare richieste.

Si noti che questo attacco produce un stato di “impallamento” talmente grave sulla macchina bersaglio da richiedere il reboot. Non c’è altro modo di rimettere in servizio la macchina colpita.

La risposta di Outpost24

Secondo uno degli scopritori di questa vulnerabilità, tuttavia, non sarebbe questo il meccanismo che hanno scoperto:

“In regards to Fyodor’s article:

There are some really valid points made; While his article does describe some of how sockstress works and why it is efficient, it does not describe our attacks.

Jack would like to stress that turning off server side SYN-Cookie protection will not help and will only make you open to syn flood attacks again (as stated in Fyodor’s article).

Also, scenarios that lead to systems being resource starved to the point of requiring a reboot is very attack and target specific. It is not as universal as causing a specific service to become unavailable. We have made this clear in all public communications, but it is worth saying again.”

[Da Conjecture, speculation… di Robert Lee]

C’è da preoccuparsi?

Forse si e forse no.

Il meccanismo descritto da Fyodor è molto pericoloso. Se lo si mette in pratica usando una botnet come Storm o Kraken, non c’è praticamente modo di fermare l’attacco. Nessun server al mondo potrebbe resistere ad un attacco del genere. In questo caso, bloccare gli IP chiamanti non servirebbe a nulla (sono milioni e cambiano di continuo).

Tuttavia, attacchi di questo genere sono noti da tempo e non vengono usati semplicemente perchè i normali SYN flood sono già più che sufficienti a portare a termine un attacco DDoS.

Fyodor infatti spiega:

Is this really a new discovery?

Perhaps Robert and Jack hadn’t seen previous references to this attack, but it is not new. I didn’t invent it either. In fact, it is somewhat straightforward for people with a strong background in TCP/IP networking. A thorough description of this exact attack, with proof-of-concept source code, was posted to Bugtraq by Stanislav Shalunov in April 2000. Bindview expanded the research with their “Naptha” research in December 2000. What Robert and Jack have done is bring increased attention to this serious and long-running problem. While I don’t consider it a serious threat to the Internet as a whole, I do consider it an important issue which should be fixed.”

ed ancora:

How serious is this problem? If it is well known, why aren’t attackers using it?

In part this is because the sort of attackers who perform DoS attacks are often lazy and unskilled. But the brute force packet flooding preferred by most attackers also has advantages over this admittedly more elegant technique. One is that the brute force packet floods can often be forged, making them harder to track down. For resource exhaustion attacks such as this one which require a full TCP connection, the attackers must use real IP addresses, making the attack sources easier to track down or simply block at the firewall. Note that the sources may be infected zombie hosts rather than the attackers themselves.

Another advantage of brute force packet flooding is that it is harder for an end user to block. With these full-TCP connection attacks, I can just block the attacker IPs. Packet floods, even when not spoofed, can be harder to block since by the time they reach your firewall they may have already caused their damage (wasted bandwidth). So you often have to work with your higher level service providers to block them upstream. This requires more time and coordination.”

Quindi, se l’attacco è quello descritto da Fyodor non è un attacco nuovo e comunque non porta significativi vantaggi rispetto ai metodi tradizionali usati dagli attaccanti.

Se però non è questo l’attacco in questione…allora non è possibile sapere quanto possa essere grave la situazione. Bisogna aspettare il talk dei due scopritori il 16 o 17 Ottobre.

La mia personalissima opinione è che comunque ci sia da preoccuparsi. Anche la tecnica descritta da Fyodor è molto pericolosa e quella, ancora segreta, scoperta dai due ricercatori di Outpost24 può solo essere qualcosa di peggio. Questa tecnica può essere usata per “buttare giù” in modo pressochè definitivo dei servizi che sono essenziali per grandi comunità di persone, come i server delle banche usati per l’home banking ed il trading o come i siti della pubblica amministrazione. Per esempio, questa tecnica potrebbe essere usata da dei criminali per impedire agli utenti delle banche di vendere i propri titoli attraverso il sistema di home banking durante un “rush speculativo” in borsa, in modo da tenere alti i prezzi.

Tuttavia, un attacco DDos, per definizione, serve a “spegnere” un sito web, un server di posta o qualcosa di simile. Di conseguenza, gli utenti finali, come voi e come me, ne risulterebbero colpiti solo in quanto utenti di servizi Internet. Potrebbe essere resa irraggiungibile la posta di Google Mail o il sito web di Wikipedia. Questa tecnica, qualunque sia la sua forma, non può essere usata per “colpire” il PC di un utente collegato via ADSL o UMTS. Semplicemente, i PC degli utenti non espongono su Internet nessun servizio che possa essere spento in questo modo. Meno che mai, questa tecnica può essere usata per colpire l’utente nel suo mondo reale (non permette l’accesso al conto corrente o cose simili). Si tratta quindi di una preoccupazione che riguarda soprattutto i tecnici di rete ed i webmaster, non gli utenti.

Alessandro Bottoni


Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo di

Stai commentando usando il tuo account Chiudi sessione /  Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione /  Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione /  Modifica )

Connessione a %s...

%d blogger hanno fatto clic su Mi Piace per questo: