Devo davvero trattare le perdite di memoria come il classico bandwith dos?

2

Recentemente ho scoperto che una grande azienda utilizza un prodotto obsoleto nei propri server di archiviazione file (ho il nome e la versione nascosti) . Il bug è stato corretto nella versione recente, ma non erano né cve né exploit fino a quando non li ho creati. (non sono ancora disponibili e molte distribuzioni sono ancora pecore pacchetti git interessati nelle filiali correnti

Stabiliscono limiti sull'utilizzo della ram sui loro back-end http ma non sui loro server di storage virtuali (un singolo processo può arrestare il server su swap)
Esse eseguono il bilanciamento del carico per account, il che significa che ogni server di archiviazione contiene l'intero dato degli account http (hanno centinaia di account) . Non sono riuscito a trovare quanti ne hanno, ma considerando che il loro sito è un sito web top (in termini di traffico mondiale) immagino che questo dovrebbe essere molto.

Ho provato il problema e alla fine ho bloccato uno dei loro server di archiviazione per diverse ore con una singola richiesta (il server http inviava 500 pagine agli utenti che tentavano di accedere agli account memorizzati su di esso)
Mi sono scusato e ho inviato loro mail sul comportamento. Ho sollevato la preoccupazione di un attacco su larga scala che avrebbe spento tutti i file server guidati da un gruppo di 5 ~ 10 persone senza richiedere botnet.

Hello again,

In these cases we feel that our compensating controls can make this significantly harder to exploit. You are probably correct that all of these things are possible and ideally would be fixed, but we consider this to be very low risk. I'm very impressed with the investigations you have done !

Sembra davvero trattarli come attacchi classici da botnet che influenzano la larghezza di banda.

Ho imparato ad aggiornare sempre il software che soffre di perdite di memoria sfruttabili. Tuttavia, sono solo uno studente, non ho esperienza nella gestione di un sito web così grande (~ 47 richieste valide al minuto) . Ma qui ci sono alcuni punti:

  • Secondo la loro pagina di stato, nessuno dei classici attacchi dos che hanno affrontato ha colpito gli utenti (che non è il caso qui)
  • Anche se i loro "controlli" potrebbero impedire la messa offline dell'intero sito, sicuramente non impediranno un grande downtime di molti dei loro server di storage (che interessano migliaia di utenti) .
  • Lo scopo del sito è quello di ospitare software, è perfettamente possibile scegliere quelli più scaricati.
  • Poiché i server di archiviazione hanno 50 GB di RAM, non credo che ne abbiano così tanti (non so se grandi esigenze come questa possano richiedere un & 20Tb di ram)
  • Può essere utilizzato solo per dos . Non c'è più possibilità per cose come l'esecuzione di codice remoto.
  • Una volta ripristinato un server di archiviazione, è possibile riporlo immediatamente poiché nulla impedisce che una richiesta elaborata venga creata da un'altra macchina con un IP diverso e non richiede l'accesso (quindi la il repository non è disponibile la maggior parte del tempo per diversi giorni)
  • Nel frattempo, fanno molte cose per impedire a una richiesta push di riempire ram, come limitare la dimensione massima dell'oggetto, o disabilitare oggetti ad albero nidificati profondi. Hanno anche intrapreso azioni su un problema precedente che consentiva l'esaurimento del ram da uno dei miei report .

Qualcosa che non riesco a capire è che si preoccupano dell'esecuzione di codice remoto non root su uno di quei server mentre il software che li alimenta è pubblico (non si preoccupano del fatto che gran parte di loro la configurazione è accessibile dall'esterno) .

Quindi ci sono situazioni in cui mantenere perdite di memoria utilizzabili è ok? (sono necessari solo 1,2 Gb di dati di rete per lo stallo di un server da 50 Gb) O più in generale, dovrebbe ram essere limitato su ɢɪᴛ server?

    
posta user2284570 25.11.2015 - 22:34
fonte

2 risposte

7

La risposta a questo dipende da una decisione di gestione del rischio che l'organizzazione fa. Esistono best practice, ma anche le migliori pratiche possono essere compromesse dalle decisioni di gestione del rischio. Non ci sono assoluti, anche patch broken stuff non è un assoluto.

Hai avuto un indizio nella loro risposta:

compensating controls

Questa frase viene utilizzata per giustificare l'attivazione di codice potenzialmente pericoloso. Il risarcimento potrebbe essere qualsiasi cosa, ma qualunque sia il limite dello scopo dell'exploit in modo tale da non costituire un problema che minaccia la SLA. Forse la perdita sfruttabile causa una breve interruzione in una piccola percentuale di utenti complessivi, che nel grande schema del loro monitoraggio SLA si perde nel rumore statistico.

È anche del tutto possibile che abbiano frainteso l'entità di ciò che hai trovato. Sfortunatamente, solo loro possono giudicare se i loro controlli compensativi sono sufficienti o meno.

Come giornalista, il tuo ruolo qui è di fornire loro una valutazione chiara dei rischi che presenta. Sarai più efficace nel cambiare la loro percezione dei rischi se riesci a fornire uno scenario realistico in cui questa debolezza può essere sfruttata per un'interruzione generalizzata. Sii specifico, cerca di non invocare botnet su scala mega e una ragionevole valutazione di quanto sarebbe facile sfruttare il problema una volta che la debolezza è nota. Utilizza la terminologia del Sistema di valutazione delle vulnerabilità comuni ; o meglio ancora, citare eventuali numeri CVE per il problema.

    
risposta data 25.11.2015 - 22:53
fonte
2

Puoi portare un cavallo all'acqua, ma non puoi farlo bere.

Se sei stato assunto per un controllo di sicurezza, hai già fatto ciò che potevi fare segnalando il problema. Se non sei stato pagato per questo, hai già fatto più di quanto eri obbligato a fare, e tutto ciò che puoi fare è evitare di usare quel servizio in futuro.

Se la direzione decide che il rischio non è abbastanza grande da giustificare l'azione, questa è la loro decisione.

    
risposta data 06.12.2015 - 23:50
fonte

Leggi altre domande sui tag