La notizia è nata da questo curioso e sibillino annuncio degli organizzatori della conferenza T2’08, che si terrà il 16 ed il 17 Ottobre 2008 a Helsinki, in Finlandia:
“As you might have noticed the schedule for T2´08 was already published a while ago. However, wè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 ”
Non sto ad annoiarvi con la traduzione e riporto subito i fatti salienti: sembra che questi due ricercatori abbiamo scoperto una o più vulnerabilità di tipo strutturale nello stack TCP (“Sockstress”). Queste vulnerabilità renderebbero possibile un attacco di tipo DoS (Distributed Denial of Service) verso qualunque server di Internet. Si tratterebbe di un attacco verso il quale, al momento, non è possibile immaginare nessun tipo di difesa.
Sfruttando queste vulnerabilità, un malintenzionato potrebbe rendere inaccessibile uno o più server (server web, server di posta etc.) facendo uso di un semplice laptop e di una normale connessione ADSL (o forse persino di un modem a 56Kb/sec). Questo vuol dire che i risultati che un tempo potevano essere ottenuti solo effettuando un attacco DDoS (Distributed Denial of Service) a cui partecipavano migliaia di computer “raccolti” in una botnet comune, adesso sarebbero alla portata di qualunque quindicenne dotato di un laptop e di una connessione WiFi “scroccata” a qualche utente poco accorto.
Questa vulnerabilità viene ritenuta talmente grave che i due autori si rifiutano di divulgare i dettagli fino al momento del loro Talk a T2’08, previsto per le 15 di Venerdì 17 Ottobre 2008. Questo intenzionale ritardo è dovuto alla necessità di permettere alle aziende coinvolte di sviluppare e distribuire le patch necessarie per difendere i sistemi esistenti da questo tipo di attacchi.
Warning o Marketing?
Questo annuncio ha sollevato una grande quantità di proteste, tra cui quelle di Fyodor , l’autore di NMap . Fyodor ha espresso le sue perplessità in modo molto chiaro:
“While I know and respect these researchers, Ì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 yoù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 ”
Per gli allergici all’inglese, il discorso di Fyodor suona più o meno così: “Anche se rispetto questi ricercatori, sono francamente stanco di gente che annuncia vulnerabilità catastrofiche e poi si rifiuta di divulgare i dettagli. Questa cosa puzza troppo da operazione di marketing.”
L’analisi di Fyodor
Fyodor è andato molto oltre: in un articolo pubblicato il 2 ottobre scorso, ha cercato di capire come sia fatta questa vulnerabilità e quanto possa essere pericolosa. Ecco la parte saliente del suo articolo:
“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.
Roba vecchia…
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 già 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.”
Che suona più o meno così: “Nella mia analisi non ho né scoperto né inventato nulla di nuovo. Questo genere di attacchi è già stato descritto da Stanislav Shalunov nell’Aprile del 2000 ed è stato ripreso da Bindview nel Dicembre successivo. Non si tratta di una seria minaccia per Internet nel suo complesso ma è comunque un serio problema di sicurezza e và risolto al più presto.”
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.”
Che si potrebbe tradurre concisamente così: “Un attacco di questo tipo è tecnicamente più complesso di un normale DDoS basato su un SYN flood ma porta ben pochi vantaggi. Richiede l’uso di IP statici, che sono più facili da identificare e da bloccare, e richiede strumenti e competenze superiori. L’unico vero vantaggio è che permette di raggiungere gli stessi risultati senza dover ricorrere ad una botnet.”
La risposta di Outpost24
Secondo uno degli scopritori di questa vulnerabilità, tuttavia, non sarebbe questo il meccanismo incriminato:
“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
Se quello che dice Robert Lee è vero, allora il tipo di attacco descritto da Fyodor non sarebbe quello che loro hanno scoperto. Pur pericolosissmo, l’attacco ipotizzato da Fyodor sarebbe comunque meno insidioso di quello scoperto dai due ricercatori di Outpost24.
C’è da preoccuparsi?
Sì e no.
Questo tipo di attacco NON può essere usato per “entrare” nel computer di un utente, per rubargli le password, per entrare nel suo conto corrente e per rubargli i soldi. NON può essere usato nemmeno per entrare nei server delle banche. Di conseguenza, i rischi per gli utenti nel cosiddetto “mondo reale” sono nulli o molto limitati.
Tuttavia, Internet è molto più “mondo reale” di quanto comunemente si creda. Ammettiamo per un attimo che ci sia un crollo della borsa e che voi, in prima persona, vi troviate nella necessità di vendere al più presto le azioni di qualche azienda in difficoltà. Ogni minuto che passa, le vostre azioni si svalutano e voi perdete centinaia o persino migliaia di euro. Ebbene, questo tipo di attacco può essere usato per attaccare e rendere irraggiungibili i server delle banche usati per il Trading Online. In questo modo, una persona che detiene una parte di azioni di quell’azienda in difficoltà potrebbe impedire a voi, ed a altre migliaia di persone, di vendere le vostre azioni, con il risultato di mantenere più alto il prezzo delle sue azioni e di mandare voi sul lastrico.
Come è facile capire, vulnerabilità di questo genere rappresentano sempre un rischio per l’utente, direttamente o indirettamente, e vanno quindi risolte. Ovviamente, non deve essere l’utente finale a risolverle. Il normale utente non può farci nulla. Devono essere gli amministratori dei server e, ancora di più, i produttori del software usato da questi server ad occuparsene.
Per il momento, tutto quello che possiamo fare consiste nell’aspettare le 15 del 17 di Ottobre e sentire cosa hanno da dire i due ricercatori di Outpost24.
I precedenti articoli ed interventi di A.B. su Punto Informatico sono disponibili a questo indirizzo
Ti potrebbe interessare
6 ott 2008