Un attacco DDoS fornirà sicuramente a un utente malintenzionato informazioni sui tempi di risposta, capacità di carico e instradamento.

Può anche fornire informazioni su come gli incidenti vengono gestiti internamente ed esternamente, nonché su come vengono segnalati al pubblico.

Ma non sono questi gli usi principali.

Generalmente i due motivi principali per DDoS sono:

• prendere un servizio o sito web offline
• distrarre da un attacco, un exploit o un'intrusione più ampio

Il primo è ben noto, molto popolare ed è relativamente semplice da eseguire, con l'unica difesa contro un attacco di grandi dimensioni essendo un servizio di mitigazione DDoS ad alto volume.

Il secondo è utilizzato più raramente, ma viene visto come parte del set di strumenti di un utente malintenzionato. Il caricamento del team di risposta agli incidenti può rendere più difficile per loro rilevare un'intrusione, può nascondere il vero motivo dell'attacco e può nascondere le prove di un'intrusione tra un gran numero di voci di registro dal DDoS.

Una risposta completa dipenderà dall'attacco e da cosa verrebbe attaccato, quindi la manterrò generale.

Un DoS può far trapelare informazioni come effetto collaterale. In passato nelle reti venivano utilizzati degli interruttori per impedire alle macchine di ascoltare la comunicazione tra altre 2 macchine. A causa di un problema di progettazione potresti trasformarlo nuovamente in un grande dominio di collisione lanciando un attacco DoS contro lo switch e potrai riascoltare qualsiasi comunicazione Spiegazione dell'attacco: gli switch apprendono quale macchina è connessa a quale porta. Quando una macchina invia un pacchetto a un'altra macchina, lo switch cerca nella sua memoria su quale porta si trova questa macchina e inoltra il traffico solo a questa porta. Una macchina su un'altra porta non vedrebbe il traffico. Quando ci sono più macchine sulla rete, si verifica un problema rispetto a quello che potrebbe essere contenuto nella memoria dello switch. I comportamenti comuni sono:

• Invia tutto il traffico a tutte le porte
• Lo switch smette di apprendere nuove macchine
• Lo switch dimentica le macchine più vecchie

Particolarmente comuni erano il primo tipo: un utente malintenzionato lasciava che la sua macchina fingesse di avere una quantità enorme di macchine su questa porta eseguendola con trasmissioni di annunci.

Un altro attacco correlato a DoS è un attacco di downgrade della sicurezza. Hai un sistema composto da 2 sottosistemi, A e B. B viene utilizzato da A per eseguire ulteriori controlli di sicurezza. Se B non risponde in tempo, A salta questo controllo e lo considera riuscito. Se l'attaccante può DoS sistema B ha un gioco più semplice perché deve solo superare i controlli di sicurezza sul sistema A. Alcuni sistemi sono progettati in questo modo perché la disponibilità del sistema A è importante e nessuno pensava che qualche attaccante potesse DoS sistema B o accetterebbe il rischio. Non posso fornirti i dettagli di un attacco effettivo, ma alcune liste nere anti-spam funzionano in questo modo.

È anche noto che alcuni gruppi / organizzazioni avanzati lanciano attacchi (D) DoS per distrarre dal loro attacco reale attirando l'attenzione del personale di sicurezza sul bersaglio del DDoS o nascondendo il traffico di attacco tra il traffico DDoS.

Un'altra opzione è che hai bisogno di quella quantità di traffico ma non hai bisogno di (D) Fallo. Ad esempio, alcuni attacchi a SSL richiedono pacchetti sufficienti per recuperare / manipolare le informazioni. Qui il DoS sarebbe un effetto collaterale della quantità di traffico.

Identifica le risorse condivise

Un attacco Denial of Service , distribuito o meno, può essere utilizzato per identificare con successo le macchine che condividono le risorse. Se vuoi hackerare un servizio, puoi lanciare un attacco contro di esso, monitorando altri servizi. Se anche quelli scompaiono, è probabile che siano ospitati sulla stessa macchina. Questi altri servizi possono essere più inclini alla pirateria informatica e possono essere utilizzati come "piede di porco" per ottenere l'accesso al servizio desiderato.

Servizi nascosti

Questo può essere devastante se utilizzato contro servizi nascosti nella rete Tor. Se hai motivo di credere che un determinato individuo stia ospitando un servizio nascosto, puoi testarlo lanciando un attacco contro un servizio aperto sullo stesso hardware o nello stesso data center. Se il servizio nascosto non funziona, potresti aver confermato che la tua ipotesi è corretta e che l'identità dietro il servizio nascosto è stata compromessa.

Ogni volta che lo provi, otterrai un campione, che potrebbe essere un falso positivo. Facendolo abbastanza volte a intervalli casuali, puoi aumentare la probabilità di avere ragione.

È possibile utilizzare un attacco DDOS per ottenere informazioni. Oltre alle risposte di Rory Alsop e H. Idden che si concentrano sull'acquisizione di informazioni sull'infrastruttura o sul sovraccarico del team di risposta agli incidenti in modo che altri attacchi rimangano inosservati più a lungo, ci sono alcune altre possibilità.

Applicazioni con ridimensionamento automatico : quando si lavora con una piattaforma applicativa che esegue il ridimensionamento automatico, un attacco DDOS può sfruttare il fatto che si ridimensionano automaticamente per fare qualcosa. Questo dovrebbe essere di concerto con qualche altro tipo di attacco o informazione, ma l'idea generale è che se ne sai abbastanza per sfruttare il processo di "riavvio" potresti usare DDOS per forzare un nuovo server online, la strega passerebbe attraverso il processo di riavvio , consentendo il tuo exploit. È importante notare che questo si aggiunge a un problema di sicurezza già esistente. È solo lo strumento attraverso il quale l'exploit completamente diverso viene portato online (o forse testato). Un esempio a cui riesco a pensare è un server di produzione che ospita la sua base di codice in un repository GitHub pubblico, quando scales inserisce nuovo codice nel server, quindi si avvia. Potresti aggiungere un codice errato a quel repository GitHub (se non gestito correttamente), forzare un riavvio e avere il tuo exploit.

Primo arrivato, primo servito - Ci sono alcune applicazioni che sono "primo arrivato, primo servito" in qualche parte del loro processo. IRC (dai commenti) è un esempio ma ce ne sono altri. Qualsiasi servizio che riserva qualcosa a un utente con un approccio primo arrivato, primo servito, può essere sfruttato tramite DDOS. O occupando tutti gli slot fino a quando una persona specifica non ottiene il loro, o forzando un riavvio e ottenendo un'altra possibilità di "slot" dopo il riavvio. Questi sono abbastanza comuni e, sebbene un servizio che lo utilizza per l'autenticazione sia un po 'strano, non è inaudito. In effetti, i servizi di licenza lo fanno sempre. Il primo utente con una licenza di "ABC" è l'utente qualificato di ABC. Se quei dati vengono persi dopo un riavvio, DDOS potrebbe causare il riavvio e mettere piede nella porta.

Vulnerabilità all'avvio - Ho visto, un bel po 'di volte in cui un avvio del server ha portato i servizi a essere "lasciati attivi" per ogni evenienza. Ad esempio, lasciamo le password SSH attive dopo il riavvio e poi disattivale dopo un paio d'ore, nel caso avessimo bisogno di un accesso di emergenza. Oppure, FTP è attivo per 30 minuti dopo il riavvio. Questo è più comune sulle apparecchiature di rete. Cose come "accesso Wi-Fi non sicuro per i primi 2 minuti" o "qualsiasi cosa può caricare qualsiasi cosa per 2 minuti". Di solito questo fa parte di un meccanismo di aggiornamento / aggiornamento. Ad esempio, un router Cisco può accettare tutti i dati TFTP che trova dopo il riavvio. Alcuni computer ascolteranno QUALSIASI server di avvio di rete al riavvio. DDOS può avviare il riavvio e consentire al tuo "codice errato" di entrare.

In sostanza, un DDOS da solo può dirti alcune cose, ma di solito solo cose che sono inutili di per sé. Un DDOS in combinazione con altri vettori di attacco può essere estremamente efficace.

Nota I metodi usati qui funzionerebbero in un laboratorio, ma ci sono pochi frutti sospesi per un team di sicurezza (o anche solo regolare IT). Sebbene esistano in natura, un utente malintenzionato dovrebbe aver ottenuto l'accesso / la conoscenza degli interni ben oltre quella di qualcuno che sta semplicemente facendo un DDOS.

Un esempio reale di questo fenomeno è con Steam. Hanno subito un attacco DoS il giorno di Natale. In risposta a ciò, hanno modificato le regole di memorizzazione nella cache del servizio Steam, in modo che i clienti potessero ancora accedere alla pagina del negozio. Sfortunatamente, hanno finito per commettere un errore di configurazione, che a volte faceva sì che gli utenti vedessero le informazioni personali di altri utenti.

I sistemi a volte hanno un comportamento imprevisto sotto un carico di sistema pesante, che può portare a vulnerabilità di sicurezza. È una possibilità per gli hacker di sfruttarlo, ma è improbabile che siano in grado di pianificarlo e l'exploit è probabilmente imprevedibile. Devono anche fare i conti con il fatto che il server è probabilmente lento a rispondere a causa del carico pesante.

Un attacco DDOS potrebbe sfruttare una vulnerabilità

In teoria un attacco DDOS potrebbe non solo distrarre da un exploit come menzionato in un'altra risposta, ma potrebbe anche essere combinato con uno.

Considera il bug Heartbleed, che restituiva informazioni quando un server veniva contattato in un modo particolare.

Si potrebbe aumentare le informazioni ottenute dal server contattando il server in un attacco DDOS e raccogliendo le informazioni che sono state rilasciate in questo modo.

Forzare il tempo di avvio del server

Una cosa che è stata menzionata tangenzialmente nei commenti, ma non affrontata in nessuna delle altre risposte abbastanza eccellenti, è che occasionalmente può essere utile per sapere quando un'applicazione / un server è stato avviato. Ad esempio, alcuni generatori di numeri casuali orribilmente insicuri (che non dovrebbero mai essere usati per attività legate alla sicurezza, ma lo sono sempre di tanto in tanto) usano l'ora di sistema come seme "casuale".

Con questo caso, se puoi dedurre quando l'RNG è stato seminato (preferibilmente entro un paio di minuti di precisione) e hai alcuni campioni di output del generatore, è ragionevolmente banale trovare il seme e ricostruire lo stato RNG per prevedere i token futuri. Ora, normalmente un server non dovrebbe esporre la sua ora di inizio (anche se di nuovo, alcuni lo fanno invariabilmente), tuttavia se un attacco DDoS può essere utilizzato per forzare un riavvio del server, allora hai acquisito conoscenza dell'ora di inizio del server.

Questo può portare a una varietà di attacchi basati su token come il dirottamento della sessione.

Potrebbe essere risolto, ma so che nei primi giorni di Criteri di gruppo un exploit era sovraccaricare il server Criteri di gruppo e in alcune configurazioni veniva applicato il criterio locale. Quindi configureremmo la politica locale come minima. È possibile utilizzare la negazione solo come exploit dell'autorizzazione ridotta della politica del server. So di non avere tutti i termini corretti: è passato un po 'di tempo da quando ho fatto l'amministratore di Criteri di gruppo.

Supponiamo che tu abbia compromesso un router ma quel router non riceveva il traffico che volevi. Potresti fare un DoS su un buon router per ottenere, si spera, traffico sul router hack.

Presumo che l'attacco DoS possa essere utilizzato insieme a un tipo di exploit race-condition. Quando il server è pesantemente caricato, l'exploit sarà più facile da usare.

Tuttavia, l'attacco DoS da solo può fornire alcune informazioni, come mostrato nelle risposte precedenti, sull'instradamento, i tempi di risposta e la gestione degli incidenti interni.

Che ne dici di un attacco a tempo? Questo è stato discusso come una possibile vulnerabilità di sicurezza in Java, Python, probabilmente molti altri, e in realtà potrebbe sembrare un attacco DOS.

Quando varie librerie controllano l'uguaglianza, generalmente sono pronte byte per byte e confrontano, restituendo false se non corrispondenti - se qualcosa del genere viene utilizzato nel controllo di password / cookie, in teoria possono cronometrare la richiesta più lunga e presumere che sia andata oltre il confronto.

Di solito non è incredibilmente invadente. Dipende dalle porte aperte e dai pacchetti inviati. Gli attacchi DDoS possono provenire da persone che forzano brutemente i dettagli e i database del tuo server, specialmente sulla LAN, e in alcuni casi può implicare un attacco di forza bruta discreto. Un tipico server web è difficile da hackerare, hosting web e videogiochi. Chiedi a un professionista o presumo che si tratti di una vulnerabilità inevitabile.