Costo della ricerca di vulnerabilità rispetto allo sviluppo di exploit

Question

Costo della ricerca di vulnerabilità rispetto allo sviluppo di exploit

#1 da (3 voti)
#2 da (-3 voti)

6

Dal punto di vista di qualcuno che vuole sviluppare un exploit zero-day contro qualche applicazione o destinazione software, ci sono in generale due compiti che l'hacker deve fare: (1) trovare una nuova vulnerabilità sfruttabile nel software; (2) sviluppare un exploit affidabile e armato per quella vulnerabilità.

Ad esempio, fuzzing, reverse e analisi statica potrebbero aiutare a trovare la vulnerabilità; ma poi richiede un'analisi separata e lavora per costruire un exploit affidabile.

Quale di queste due attività tende a costare di più, in media? Mi chiedo che aspetto abbia l'aspetto economico di questo e per avere un'idea del rapporto tra i costi di queste due attività. So che se si considera una singola vulnerabilità, i costi dipenderanno dalla vulnerabilità, ma sto chiedendo il caso medio. Ad esempio, se guardassimo a una società che sviluppa exploit, nel complesso, ci aspettiamo che più del suo budget vada verso 1 o verso 2?

Supponiamo di dover attaccare un'applicazione software per utenti finali ampiamente utilizzata e relativamente matura.

exploit zero-day exploit-development

posta D.W. 23.03.2016 - 23:23

fonte

2 risposte

Leggi altre domande sui tag exploit zero-day exploit-development

Porte sconosciute mostrate su Nmap scan ... e altri strani comportamenti IPSec Host-to-Host VPN (RedHat) ha bisogno dell'inoltro IP?

score 3 · Answer 1

I costi relativi dipendono molto da quale sia la vulnerabilità. Per dimostrarlo, farò riferimento a due vulnerabilità semi-recenti: il bug di Bash "Shellshock" e il bug "Ghost" gethostbyname() di glibc.

Shellshock

Il bug di Shellshock è stato causato da una falla complessa nell'analisi di Bash che potrebbe essere usata per far eseguire Bash codice direttamente dalle variabili di ambiente. Il bug esisteva per circa 22 anni prima che fosse trovato pubblicamente.

Un controllo per verificare se il bug esiste è il seguente:

$ env X="() { :;} ; echo vulnerable" /bin/sh -c ":"

Ora, scoprire che l'errore richiede un accurato controllo del codice sorgente o una buona sessione con un codice fuzzer. Ma non appena si riduce a un caso di test come questo, gli exploit arrivano facilmente. Ad esempio, se sai che un server di destinazione sta eseguendo uno script di shell CGI:

$ nc vulnerable.example.com 80 <<__END
GET /path/to/cgi.sh HTTP/1.1
Host: localhost
User-Agent: () { x; }; printf "%s\n\n" "Content-type: text/plain"; /usr/bin/id
Accept: */*

__END

Quindi Shellshock era difficile da trovare, ma una volta trovato, era banale da sfruttare.

Ghost

La vulnerabilità di glibc gethostbyname() , d'altra parte, è una vulnerabilità di overflow del buffer che può verificarsi soltanto in determinate condizioni molto specifiche. Un utente malintenzionato può sovrascrivere al massimo 8 byte di memoria su macchine a 64 bit o 4 su macchine a 32 bit. L'autore dell'attacco deve impostare una voce DNS appositamente predisposta, quindi ingannare il bersaglio per richiederlo.

Questo bug è stato rimosso per circa 13 anni e, una volta risolto, non è stato riconosciuto come una vulnerabilità di sicurezza. I ricercatori di sicurezza Qualys che lo hanno segnalato come vulnerabilità hanno dedicato molto tempo a testare i singoli programmi per sfruttarli. Una grande maggioranza non lo era, a causa della limitazione di 8 byte e dei dettagli di come viene tipicamente utilizzato gethostbyname() . Nota anche che il semplice innesco del bug causa generalmente il crash del programma: più denial of service che exploit.

Il loro colpo di grazia, un completo exploit remoto del mailserver di Exim, è una catena Rube Goldberg meticolosamente progettata che è riuscita a aggirare le limitazioni usando proprietà specifiche di come Exim succede ad organizzare la sua memoria in situazioni specifiche. È descritto dettagliatamente nel advisory sulla sicurezza di Qualys ed è troppo complicato per andare qui dentro.

Confronto

Devo ammettere che non sono sicuro di quale bug fosse più difficile da trovare. Entrambi sono rimasti latenti nel codice per molto tempo. Qualys ha trovato il bug di Ghost "durante un controllo del codice"; Stéphane Chazelas ha trovato il bug di Shellshock estrapolando da cose che sapeva già sul comportamento di Bash e un'intera serie di i bug correlati sono stati trovati molto rapidamente una volta che le persone sapevano dove cercare, alcuni con l'aiuto degli strumenti fuzzing.

Tuttavia, la questione di quale era più difficile da sfruttare è molto più facile da rispondere. Penso che sia chiaro che un livello molto alto di ingegneria è andato alla ricerca di un modo per trasformare il bug Ghost in un exploit Exim funzionante. È stato richiesto molto più lavoro rispetto all'utilizzo di Shellshock precedente, che ha richiesto circa 10 minuti per scrivere e testare.

score -3 · Answer 2

La scrittura di un'utility di exploit non è nulla per un programmatore esperto. E non è un software per gli utenti finali, quindi non hai bisogno di un'interfaccia user-friendly, non c'è bisogno di cose stravaganti. È solo una veloce utility sporca per sfruttare la vulnerabilità, quindi questo non è un grande software costoso, è un piccolo software economico. E puoi parlare di un ETA. Sai quando riprendi il tuo investimento.

Scoprire una nuova vulnerabilità è molto più difficile in un software maturo, rispetto allo sviluppo dell'exploit. E non sai se puoi trovare presto, o mai, nessun ETA, non sai quando riavrai il tuo investimento, o mai. Stai cercando qualcosa che gli sviluppatori non vogliono essere presenti. C'è anche una competizione, altri possono scoprire prima di te.

Se il software è importante (OpenSSL ad esempio), diventa incredibilmente difficile a causa della concorrenza. Perché scoprire una vulnerabilità critica equivale a inventare un'arma eccellente per le guerre informatiche, come HeartBleed . L'NSA probabilmente spende tonnellate di denaro ogni anno per questo tipo di ricerche e probabilmente ha già qualche serio 0 giorni.

Quindi, il costo di scrittura di un exploit è trascurabile rispetto alla ricerca di una nuova vulnerabilità.

Qualche dato? Si prega di vedere alcuni exploit nel link Ci sono vulnerabilità che sono rimaste nascoste per diversi anni, tuttavia il loro sfruttamento è abbastanza semplice e facile con 100- 200 linee di Python.

3-4 settimane fa, una nuova vulnerabilità scoperta pubblicamente in OpenSSH prima di 7.2p2 ( tutte le versioni; risalente a ~ 20 anni ), che consente agli utenti autenticati remoti di ignorare le restrizioni previste per il comando shell tramite elaborato i dati di inoltro X11.

Ed ecco l'exploit: link 150 linee di Python .

BTW, non dimenticare di controllare il tuo pacchetto openssh-server. Ho installato Ubuntu 14.04 e, dopo aver aggiornato i pacchetti, ho ancora la versione 6.9p1.