Domanda:
Ha senso considerare un arresto anomalo del software del server attivabile un attacco DOS?
Matías
2019-01-30 04:28:54 UTC
view on stackexchange narkive permalink

Ho trovato una piccola vulnerabilità in un'applicazione web in esecuzione sul server Node.js.

Funziona inviando un payload predisposto al server delle applicazioni, il che fa sì che il codice del server delle applicazioni generi un errore ea causa della mancanza di gestione degli errori - Si arresta in modo anomalo (finché qualcuno non lo esegue di nuovo).

Non sono sicuro di quale sia il nome appropriato per questo tipo di attacco. Presumo che sia un DOS ( Denial Of Service ) perché rende il server Deny Serving i suoi client. D'altra parte, fino ad ora, ho solo sentito parlare di attacchi DOS che funzionano per flooding il server in qualche modo (che non è il caso qui).

Quindi, è corretto considerarlo come un attacco DOS? Se la risposta è no, allora come dovrebbe essere chiamato ?

Se un'applicazione è ben scritta, non avrà bug DOS di tipo crash e un utente malintenzionato dovrà ricorrere a un DDOS completo (che funzionerà sempre se l'attaccante ha una manichetta più grande del bersaglio).Tuttavia, se l'app di destinazione ha un arresto anomalo facile da attivare, sono sicuro che qualsiasi utente malintenzionato preferirebbe inviare il singolo pacchetto creato e risparmiare il $$ di eseguire una rete DDOS.
Finché impedisce agli utenti di utilizzare il servizio, è un DOS.Ho lavorato su un sito Web che è stato attaccato da DOS da Google e Bing semplicemente perché Drupal non è in grado di gestire il carico (volevo dire ** non poteva ** ma credo che ancora non possa).
Questo sarebbe un attacco DoS, in particolare ho già visto tali attacchi chiamati attacchi "veleno" prima ... ma non sono in grado di trovare un riferimento per questo in questo momento
Modificherei il tuo titolo in un arresto anomalo del software "attivato".L'arresto anomalo casuale non è realmente DoS, ma il fatto che tu possa provocarlo a comando è la parte fondamentale.
@zero298 Sono leggermente in disaccordo: il titolo non ha bisogno di contenere l'intero contesto e le sfumature della domanda, ecco a cosa serve il corpo della domanda.Andrei bene con un titolo ancora più breve, come "Un crash del software è un attacco DoS?"La risposta al * titolo * sarebbe "a volte", ma se qualcuno lo postasse, sarebbe chiaro che erano troppo pigri per leggere la domanda vera e propria.
Penso che un po 'più di dettaglio su questo punto sia importante: "Si arresta in modo anomalo (finché qualcuno non lo esegue di nuovo)." Cosa succede alle richieste future, esattamente?Se il server si blocca per te, ma continua a funzionare normalmente per tutti gli altri utenti, allora direi che hai più un bug che un attacco DOS, perché il servizio è ancora disponibile per altre persone.Tecnicamente hai fatto il DOS da solo, quindi c'è un bug da correggere, ma se l'unico utente interessato sei tu stesso, allora non hai molti attacchi (in genere).
Si sente parlare di attacchi DoS basati sulle inondazioni perché sono molto semplici da eseguire: l'attaccante ha solo bisogno di più larghezza di banda rispetto al bersaglio.Questo li rende di gran lunga la forma di attacco più comune.
@ConorManconeI ha letto che quando il servizio si arresta in modo anomalo fino al riavvio, ad es."esegui di nuovo (sul server)" per esempio, avviando un processo `node` in una sessione` screen`: se c'è un'eccezione non rilevata, il processo del server NodeJS muore fino al riavvio.Ovviamente una mitigazione qui è che i servizi critici verrebbero riavviati automaticamente in caso di guasto da qualcosa come systemd o software di monitoraggio, ma ciò non mitiga contro una marea di attacchi di pillole velenose
@Josh Grazie Josh.Ho finito per aggiungere una risposta per parlare di quella distinzione comunque, poiché la tecnologia è importante.Non ho mai fatto l'hosting di nodi (solo PHP e Python) e dalla sua terminologia non era chiaro cosa stesse descrivendo esattamente.Mi sembra un po 'folle, però, che è probabilmente il motivo per cui ero confuso in primo luogo.Sono abituato al fatto che l'applicazione e il server siano separati, nel qual caso nessuna quantità di eccezioni non gestite può causare problemi al servizio stesso, solo per l'unica richiesta che ha generato l'errore dell'applicazione.
Questo non è molto diverso da un Ping of Death e quelli sono considerati attacchi DoS.
Sette risposte:
DarkMatter
2019-01-30 04:32:48 UTC
view on stackexchange narkive permalink

Sì. Qualsiasi attacco che abbia l'obiettivo di negare il normale utilizzo di un servizio da parte di utenti legittimi è per definizione un DoS (Denial of Service).

schroeder
2019-01-30 04:58:46 UTC
view on stackexchange narkive permalink

DDoS (Distributed DoS) è caratterizzato da inondazioni che creano un DoS (in tutte le definizioni disponibili). Un singolo nodo che causa con successo un flood è piuttosto raro.

Ma DoS può essere causato da una vasta gamma di trigger.

CVSS ha anche un esempio di arresto anomalo del software classificato come DoS per te:

A causa di un difetto nella funzione di gestione dei comandi RPC , è possibile manipolare i puntatori ai dati all'interno del processo Virtual Machine Executable (VMX). Questa vulnerabilità può consentire a un utente in una macchina virtuale guest di arrestare in modo anomalo il processo VMX con conseguente Denial of Service (DoS) sull'host o potenzialmente eseguire codice sull'host. [empasis mine]

E da Wiki:

Gli attacchi denial-of-service sono caratterizzati da un tentativo esplicito da parte di aggressori per impedire l'uso legittimo di un servizio. Esistono due forme generali di attacchi DoS: quelli che bloccano i servizi e quelli che inondano i servizi. Gli attacchi più seri vengono distribuiti.

Quindi, sì, un semplice arresto anomalo è un DoS.

DDoS è caratterizzato dall'essere un attacco * distribuito *, ma non necessariamente dall'essere un diluvio.Quando invii un singolo carico di arresto anomalo ogni volta che il server torna online e utilizzi sempre uno zombi botnet diverso per farlo al fine di evitare la blacklist IP, anche questa sarebbe una forma di attacco DDoS.
@Philipp non ne sono sicuro.Sembra un DoS seriale.Ogni riferimento che posso trovare per descrivere DDoS è stato quello di caratterizzare l'evento come un'alluvione da più fonti creando un DoS, non un DoS da più fonti.Potete fornire qualcosa per supportare il vostro esempio?
@schroeder Io _sospetto_ questo perché molti (o, almeno, i più facili da ottenere) attacchi DoS comportano inondazioni e le inondazioni da più fonti hanno maggiori probabilità di sopraffare un bersaglio.Pertanto, la maggior parte degli attacchi DDoS comporta il coinvolgimento di più sorgenti, ma, direi, "inondazioni" non è la _definizione_ degli attacchi DDoS, mentre "più sorgenti" lo è.Un attacco accuratamente predisposto, come richiesto dall'OP, proveniente da più fonti (per ostacolare la blacklist IP) sarebbe legittimamente un DDoS.
@TripeHound certo, ho la supposizione, e potrei essere d'accordo, se avessi qualcosa a sostegno dell'ipotesi.Non riesco a trovare alcun supporto.
Solo parlando da una prospettiva logica, per me ha senso che la caratteristica distintiva di un DDOS sia che la distribuzione dell'attacco impedisce al difensore di mitigare l'attacco.Il difensore ha davvero bisogno di essere specificato perché abbia senso.Non prenderei in considerazione l'invio di singoli payload di arresto anomalo a un'applicazione server ogni volta che arriva online un DDoS contro l'applicazione server, ma potrebbe essere visto come un DDoS dal punto di vista di un difensore di livello inferiore (forse un firewall) che potrebbe non essere in gradoper bloccare questo attacco perché ogni volta continua a provenire da IP diversi.
Sì, tutti, sono pienamente d'accordo sul fatto che DDoS *** potrebbe, logicamente, significare un attacco distribuito di qualsiasi tipo.Ma non riesco a trovare *** nessun riferimento *** a questo significato utilizzato nella pratica e anche l'esempio proposto mi sembra una serie di attacchi, e non un singolo attacco (sebbene distribuito).Se *** qualcuno *** può aiutare con un esempio concreto, gliene sarei grato.[Effettivamente esci e conta i denti del cavallo] (https://bedejournal.blogspot.com/2008/02/francis-bacon-and-horses-teeth.html).
DDoS può assolutamente includere attacchi che utilizzano un meccanismo diverso oltre al semplice flooding.Lo dico come qualcuno che recentemente è stato uno sviluppatore di software in un team anti-DDoS per una nota azienda mondiale.
https://www.paloaltonetworks.com/cyberpedia/what-is-a-denial-of-service-attack-dos - ma sei bravo a resistere fino a quando qualcuno non ha effettivamente fornito una citazione!Troppe discussioni su Internet finiscono per fiat della mafia.
sarnold
2019-01-30 10:17:35 UTC
view on stackexchange narkive permalink

Molto spesso si ritiene che la sicurezza fornisca tre proprietà:

  • Disponibilità
  • Integrità
  • Riservatezza

Nel tuo caso, hai trovato qualcosa che consente a un utente di influenzare la disponibilità del servizio. A seconda di ciò che fornisce il servizio, ciò potrebbe essere fastidioso o potrebbe essere catastrofico.

Molto spesso i servizi non riusciti vengono riavviati automaticamente. Questi possono mitigare arresti anomali occasionali, ma il riavvio di un servizio è solitamente molto più costoso del normale costo per gestire una connessione. In questo caso, eseguire la tua richiesta di "arresto anomalo del server" cinque o sei volte al secondo potrebbe non richiedere molta larghezza di banda, ma probabilmente è ancora piuttosto approssimativa sul server medio.

Inoltre, buoni gestori di servizi non riavviano i servizi senza limiti.È probabile che qualcosa che renda il servizio in crash possa essere sfruttato anche in altri modi e riavviare ciecamente il servizio offre all'attaccante un'altra possibilità.
Conor Mancone
2019-01-30 20:00:10 UTC
view on stackexchange narkive permalink

Volevo aggiungere un altro dettaglio importante non esplicitamente dichiarato nelle altre risposte. Hai detto questo:

Funziona inviando al server un payload predisposto, il che fa sì che il codice del server generi un errore e, a causa della mancanza di gestione degli errori, si arresta in modo anomalo ( finché qualcuno non esegue di nuovo ).

(enfasi mia). Questo avvertimento è importante perché il modo in cui tali servizi rispondono a un arresto anomalo può variare notevolmente tra i set tecnologici.

Non è un DoS

Ad esempio in PHP o nella maggior parte cgi, una singola richiesta arrestata non ha assolutamente alcun impatto su altre richieste. Il server non riesce a inviare una risposta adeguata per la richiesta bloccata, ma altre richieste provenienti da utenti legittimi continuano a essere gestite correttamente dal server. In questo caso l'incidente colpisce solo te stesso, non gli altri, quindi sarebbe difficile qualificarlo come un attacco DoS. Certo, c'è un bug e stai negando il servizio a te stesso, ma se il server continua a funzionare normalmente per tutti gli altri, allora non c'è davvero alcuna negazione del servizio in corso.

A DoS

Se, tuttavia, il tuo payload causa l'interruzione del servizio effettivo e il server non può più ricevere richieste fino a quando non viene intrapresa un'azione per ripristinare i servizi (da un amministratore o ripristino automatico dopo un breve periodo di tempo) allora hai sicuramente un Denial of Service perché il crash che hai causato ha impedito al servizio di rispondere agli utenti legittimi (come discusso in altre risposte).

In alcune circostanze l'attacco "Non è un DoS" che non disattiva il server potrebbe essere promosso a un vero e proprio attacco DoS se puoi "ingannare" un utente legittimo affinché visiti un URL con il tuo payload dannoso. Il più delle volte, tuttavia, tali attacchi non hanno un grande impatto pratico poiché il servizio continuerà a funzionare normalmente quando in seguito utilizzeranno normalmente il servizio. Tuttavia, potrebbero esserci rare circostanze in cui il payload viene mantenuto nella sessione e quindi blocca permanentemente l'utente (ho già visto persone attivare accidentalmente tali circostanze nella vita reale prima).

Dalla tua descrizione, è difficile per sapere in quale di queste categorie rientra il tuo particolare carico utile, ma è necessario fare una distinzione importante.

DoS può essere applicato anche se induci un utente valido a eseguire il payload.Il DoS è localizzato, ma conta ancora come DoS.
@schroeder Sì, vero, anche se è difficile fare in modo che tali attacchi abbiano un impatto sostanziale, motivo per cui l'ho lasciato fuori (aggiungerò un commento a riguardo).In genere questo tipo di attacco può far sì che l'utente interessato abbia un caricamento della pagina non riuscito, ma se torna alla pagina durante il normale utilizzo tutto funziona normalmente.È possibile che si verifichi un caso in cui il payload errato viene persistito nella sessione in qualche modo, il che può finire per eseguire efficacemente DoS su un singolo utente - questo può essere un attacco DoS molto efficace.
In node hai un piccolo numero di server a thread singolo.quindi un arresto anomalo del server colpisce tutti gli utenti attivi (ovviamente il riavvio automatico è una buona idea, ma un arresto anomalo continuo del processo danneggerà gravemente il servizio).Tuttavia ciò che dovrebbe essere più preoccupante è il tipo di crash che è ... potrebbe essere sfruttabile (le interruzioni dell'elaborazione logica non porterebbero a termine il binario del nodo).
PHP FastCGI o FPM utilizza un processo di lavoro PHP per richiesta e un errore irreversibile ucciderebbe solo il processo di lavoro e il demone FastCGI ne estenderebbe un altro.Ma cosa succede se il tuo errore è così grave da uccidere _apache_ (o qualunque server web tu stia utilizzando) - _allora_ è un attacco DOS.L'ho già visto prima (dove il bug era in un modulo Apache) e il risultato non era più niente in ascolto sulla porta 80 e una perdita totale del servizio
Grazie @eckes, Non sono un tipo di nodo quindi non so molto su come gestisce le eccezioni non gestite.
@Josh Sì e no.In effetti, se sei riuscito a far uccidere Apache, sei tornato a un DoS.Tuttavia, ciò richiede in genere un bug in apache.Tuttavia, l'attivazione di un errore irreversibile in un'applicazione PHP non causa la morte del processo di lavoro sottostante.Per causare la morte del lavoratore è necessario trovare un bug in PHP * stesso *, che è molto più difficile che trovare un bug nell'applicazione PHP.Lo stesso con apache: per uccidere apache è necessario attivare un bug in apache (si noti che la risposta dei trognanders include un esempio di tale incidente).Quelli creano attacchi DoS, ma sono molto più difficili.
@ConorMancone, ... trovare un attacco di esecuzione di codice arbitrario su un'applicazione PHP, al contrario, tende ad essere un evento frequente e sfruttare * quello * in una negazione del servizio che ha un impatto su Apache nel suo insieme è semplice.
@CharlesDuffy A meno che non ti abbia frainteso, mi sembra che sia un po 'una frettolosa generalizzazione.Un attacco con esecuzione di codice remoto è il tipo di attacco più pericoloso.Ci sono certamente siti vulnerabili là fuori (si presentano qui chiedendo di file casuali trovati sul loro server), ma ciò non significa che sia frequente o che sia facile trovare una tale vulnerabilità su un sito casuale.Inoltre, se avessi ottenuto i privilegi di esecuzione su un server, non vedo perché dovresti quindi andare a eseguire il DoS del sito: probabilmente ci sono attacchi più succosi e un DoS è rumoroso.
trognanders
2019-01-30 23:25:18 UTC
view on stackexchange narkive permalink

Il tuo attacco è fondamentalmente la definizione di DOS, nega letteralmente il servizio e stai usando il termine correttamente.

Il consumo di larghezza di banda è un approccio ingenuo che non richiede che il server abbia una vulnerabilità specifica, ma non è certamente l'unico.

Ecco un vero CVE su Apache che descrive un attacco DOS simile (si blocca con segfault) usando quella terminologia:

http: // cve .mitre.org / cgi-bin / cvename.cgi? name = CVE-2018-8011

Anche attacchi più complicati sono a volte banalmente attacchi DOS e ricevono anche quell'etichetta. Un bug di esecuzione del codice remoto che distrugge lo stack senza uno shellkit distrugge ancora lo stack con valori errati causando un segfault.

DarcyThomas
2019-02-01 04:45:16 UTC
view on stackexchange narkive permalink

Sì, questa potrebbe essere definita una vulnerabilità DOS. L'ho sentito chiamare "attacco DOS dell'applicazione".

Un altro esempio: un sito che esegue uno scanner antivirus sui file caricati, in cui qualcuno carica un file zip di 100.000 file zip contenenti 100.000 file da 2 GB di zero bit . Un file zip super piccolo che utilizza tutta la memoria disponibile per aprirsi e scansionare.

Se stai negando a un utente legittimo di utilizzare una risorsa [CPU, Ram, Disco, larghezza di banda di rete (reimpostazioni della password?] potresti chiamarlo un attacco DOS.

Se tuttavia l'attacco danneggia solo lo stato dell'applicazione (ad esempio, consente a un utente non autorizzato di impostare l'app in modalità di sola lettura), allora potrei essere incline a chiamarla semplicemente un'applicazione (o di sicurezza) vulnerabilità.

virolino
2019-01-30 18:38:05 UTC
view on stackexchange narkive permalink

Ha senso considerare un crash del software del server come un attacco DOS?

Qualsiasi attore agirà in almeno due dimensioni rispetto a qualsiasi attività: abilità e permission.

L'abilità ha 2 possibilità: abile e incapace .

L'autorizzazione ha anche 2 possibilità: allowed o denied.

Pertanto, un bravo attore eseguirà un'azione solo se può e allowed.

Dal mio punto di vista, crash del software = cannot e DOS = negato . Poiché i due sono "valori" su dimensioni diverse, non possono essere considerati simili, anche se gli effetti per l'utente finale possono essere simili. Tuttavia, gli effetti visti dall'amministratore di rete possono essere completamente diversi: le soluzioni per loro sono generalmente diverse.

Inoltre, un attacco DOS può portare a un crash del software, ma non sono ancora simili: lo sono solo correlato - causa ed effetto.

Esempio: qualsiasi software potrebbe bloccarsi per un numero incalcolabile di motivi anche in assenza di qualsiasi attacco.

Nota: il crash del software di solito significa che il processo è interrotto dal sistema operativo a causa di un'operazione difettosa. I DOS sono possibili di solito perché il software si comporta male, ma non si blocca.

DoS non è un problema di autorizzazioni.Le definizioni di base dei termini contraddicono la tua premessa.
Anche così, i termini non sono simili.Quindi presumo che la mia risposta sia corretta, anche se la "metafora" non è perfetta.Quindi il voto negativo non dovrebbe riferirsi all'intera risposta.Inoltre, D in DOS è "Denial" (esattamente come ho scritto) - quindi ancora una volta non capisco veramente il voto negativo.
Di fatto, linguisticamente e logicamente sei sbagliato.Stai cercando di applicare definizioni di parti di termini fuori contesto per escogitare un significato e il risultato non ha senso.Potrei esaminare gli errori nella logica, ma il fatto è che il termine "DoS" è * definito * dalla perdita intenzionale del servizio per gli utenti legittimi e un arresto anomalo è un esempio fondamentale di questa classificazione di attacco.
Se uso i tuoi termini, il malintenzionato è "in grado" e "autorizzato" (cioè, non negato, date le tue definizioni) di inviare un pacchetto predisposto per interrompere il servizio.Quindi la tua conclusione è sbagliata dall'inizio.Il tuo punto successivo non ha alcun senso dato il contesto che hai fornito ai termini che stai usando, quindi il tuo argomento si basa su un cambiamento nelle definizioni.Il risultato è che la tua logica non ha flusso.
Solo curioso: chi `permette` qualcosa di dannoso?Come sono ammessi gli attori malintenzionati?Sì, possono, sì, agiscono, no, non sono ammessi.Agiscono e basta.Penso che anche le tue definizioni non siano molto valide.E la mia risposta è l'unica che affronta la domanda nel titolo, anche se altre risposte sono più tecnicamente corrette.Puoi per favore spiegare - magari in una risposta - "in che modo un crash del software è simile a un attacco DoS"?Per favore.
La domanda è l '* intero * post, non solo il titolo.L'intero post fornisce il contesto.Sto usando le tue *** definizioni quando dico che gli attori malintenzionati sono "consentiti", perché non sono "negati".questa è la tua dannata dicotomia.E, se cercherete voi stessi, scoprirete che * ho * fornito una risposta.Cioè, ho fornito una risposta alla domanda, non la tua reinterpretazione.
Un arresto anomalo del software conta come una negazione del servizio perché impedisce a utenti altrimenti legittimi di utilizzare il servizio (ovvero nega loro il servizio), perché il servizio non può essere utilizzato quando il processo non è in esecuzione.Ci si potrebbe chiedere, come fa un DDoS a ridurre i privilegi degli utenti legittimi?


ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...