Alfonso Maruccia

Slow Read, attacco DoS al rallentatore

Ovvero, buttare giù i sistemi remoti prendendoli per sfiancamento: una lettura troppo lenta della risposta del server consuma risorse e inibisce l'accesso ai visitatori legittimi

Roma - Ideato dal ricercatore Sergey Shekyan di Qualys Security Labs, "Slow Read" è un nuovo tipo di attacco DoS tarato per l'uso di risorse limitate: sfruttando una nota vulnerabilità nel protocollo di rete TCP, Slow Read è virtualmente in grado di mettere fuori gioco i server remoti facendo uso di una normale connessione ADSL e un solo computer come vettore d'attacco.

Slow Read costringe il server preso di mira a mantenere indefinitamente una connessione di rete eseguendo una lettura "lenta" del feedback del protocollo TCP, un meccanismo che costringe il server ad allocare enormi quantità di dati in memoria.

Con pochi sistemi a disposizione, suggerisce Shekyan, un ipotetico hacker black-hat o un cyber-criminale avrebbe gioco facile nell'abbattere i server meno protetti per difendersi da questo genere di attacchi.
Slow Read è un attacco DoS "lento" che rientra nella stessa categoria di "Slowloris", già usato nel 2009 contro i sistemi del governo iraniano per protesta contro l'elezione del presidente Mahmoud Ahmadinejad. In quel caso, però, l'attacco DoS era stato condotto con richieste HTTP parziali.

Alfonso Maruccia
Notizie collegate
  • SicurezzaSSL, DoS a portata di laptopUn gruppo di hacker tedeschi rilascia il suo tool per buttar giù i server di autenticazione. Il software sfrutta una funzionalità poco nota dello standard SSL, ma comunque nefasta
  • SicurezzaIl misterioso crash dei server DNSIl software BIND, tra più popolari, deve fronteggiare una minaccia ignota. Vulnerabilità? Danni collaterali di un DDoS? Ci sono comunque pronte delle patch per arginare il problema
7 Commenti alla Notizia Slow Read, attacco DoS al rallentatore
Ordina
  • Come spesso accade, Mariuccia è convinto di aver scritto un articolo ma in realta' non ha scritto nulla.

    Si tratta, banalissimamente, di un DDoS che richiede risorse troppo grandi per stare nel buffer (altrimenti il server si libererebbe in un attimo) che richiedono una risposta in pacchetti di pochi byte. Come tutti sanno dalla notte dei tempi, questo mette ko il server. Ovviamente la soluzione è impostare un timeout per la connessione sufficientemente basso ed evitare l'invio di pacchetti troppo piccoli.
    non+autenticato
  • - Scritto da: uno nessuno
    > Come spesso accade, Mariuccia è convinto di aver
    > scritto un articolo ma in realta' non ha scritto
    > nulla.

    COme spesso accade, molti non hanno ancora capito che si chiama MARUCCIA e non MARIUCCIA. Ci vuol tanto a togliere quella "I"?
    non+autenticato
  • - Scritto da: uno nessuno
    > Come spesso accade, Mariuccia è convinto di aver
    > scritto un articolo ma in realta' non ha scritto
    > nulla.
    >
    > Si tratta, banalissimamente, di un DDoS che
    > richiede risorse troppo grandi per stare nel
    > buffer (altrimenti il server si libererebbe in un
    > attimo) che richiedono una risposta in pacchetti
    > di pochi byte. Come tutti sanno dalla notte dei
    > tempi, questo mette ko il server. Ovviamente la
    > soluzione è impostare un timeout per la
    > connessione sufficientemente basso ed evitare
    > l'invio di pacchetti troppo
    > piccoli.

    Mi sa che hai capito male.
    Qua si parla di un solo vettore d'attacco quindi non si parla di DDOS... ma di DOS causato da un singolo PC. (sicuramente ce ne saranno stati altri anche prima....quindi fin qui nulla di nuovo)

    A quanto pare si tratta di un nuovo attacco che sfruttando una pecca del TCP permette di creare un disservizio sul server. Tutto qua.

    Il fatto che vengano allocate dal server risorse a tempo indefinito e che l'attaco si possa applicare in maniera lenta, potrebbe evitare che questo venga rilevato dai firewall, perlomeno quelli meno sofisticati.

    Per collegarmi a quello che dici tu, se il timeout non è previsto non "basta settarlo"... salvo modificare il codice del'applicazione credo.
    non+autenticato
  • Che novità
    A corto di notizie eh?
    quanto ai DoS non li definirei un problema di sicurezza in modo "diretto" quanto un problema di "business continuity" che hanno soluzioni differenti da quelli tipici della sicurezza nel 90% dei casi.
    Nel caso specifico il problema evidenziato non sta nel protocollo in senso proprio ma nella/e sue implementazioni.
    non+autenticato
  • > A corto di notizie eh?
    > quanto ai DoS non li definirei un problema di
    > sicurezza in modo "diretto" quanto un problema di
    > "business continuity" che hanno soluzioni
    > differenti da quelli tipici della sicurezza nel
    > 90% dei


    A me risulta che la mancanza di disponibilità sia un problema di sicurezza informatico
    non+autenticato
  • Ci sono molti protocolli che sono nati senza pensare alla sicurezza. Ma in fondo a quei tempi non c'erano problemi di minacce informatiche come ai giorni nostri.

    PS
    Complimenti per i termini, magari usassero "Black Hat" anche ai telegiornali. Nome accattivante ed eticamente corretto allo stesso tempo.
  • - Scritto da: Metal_neo
    > Ci sono molti protocolli che sono nati senza
    > pensare alla sicurezza. Ma in fondo a quei tempi
    > non c'erano problemi di minacce informatiche come
    > ai giorni
    > nostri.

    Non è un problema del protocollo ma eventualmente della sua/e implementazione/i.
    In parole povere... guarda a come scrivi (è scritto) il codice!
    non+autenticato