Come si cercano nuove vulnerabilità? [chiuso]

-1

Mi è stata fatta questa domanda, e davvero non so come potrei farlo. La mia risposta era prendere vulnerabilità note e cercare di sfruttarle in un modo diverso, ma questa non è realmente una nuova vulnerabilità, piuttosto un nuovo attacco basato su una vulnerabilità nota.

Quindi la mia domanda è, come è il processo di ricerca delle vulnerabilità? (In un pezzo di software, o su un sistema, o in un protocollo.) Immagino che sarebbe qualcosa di simile:

  1. Ricerca approfondita su dove stai cercando di trovare una vulnerabilità. Ad esempio: una ricerca approfondita su come funziona un PKI.
  2. Una volta che sai tutto, trova se c'è qualche punto debole e capisci perché è un punto debole.
  3. Cerca di sfruttare questi punti deboli.
  4. Rapporto.

È corretto questo processo?

    
posta yzT 31.05.2013 - 10:37
fonte

2 risposte

4

Parafrasando qualcuno che fa questo per vivere: "Sfruttare le vulnerabilità è un mestiere. La ricerca di vulnerabilità è un'arte nera. "

Un modo comune di cercare vulnerabilità nel software (o nell'hardware o in una combinazione) è fuzzing . Guarda un'interfaccia e getta tutti i tipi di spazzatura su di esso. Se continua a funzionare correttamente ("accesso negato", "errore di sintassi", ...), prova alcuni rifiuti inutili. Se fa qualcosa di interessante (nessuna risposta, "errore di segmentazione", ...), hai colpito qualcosa che non funziona come previsto, quindi indagare ulteriormente per vedere se hai trovato un problema reale. Non appena trovi che l'obiettivo non funziona come previsto, e la differenza di comportamento ha un impatto sulla sicurezza, hai trovato una vulnerabilità e il prossimo passo è lo sfruttamento (sfruttando la vulnerabilità per ottenere qualche risultato utile che viola la politica di sicurezza).

Sebbene sia possibile eseguire il fuzz con spazzatura casuale, è più produttivo cercare condizioni al contorno. Prova a inviare alcuni byte nulli o un unicode non valido o un nome contenente una virgoletta singola o una lunghezza appena sopra o appena sotto limite di dimensioni.

Se si dispone del codice sorgente, è possibile eseguire alcune analisi statiche su di esso e cercare problemi comuni (accessi di array non selezionati, stringhe in formato libero concatenate per formare una query di database, ...). Puoi anche eseguire analisi statiche su un binario ma tende ad essere molto più difficile.

Per cercare vulnerabilità nei protocolli, è possibile sfogliare il protocollo in un'implementazione di test. Un altro approccio è tentare di dimostrare alcune proprietà desiderate del protocollo. Se rimani bloccato nella dimostrazione, forse è perché la proprietà di sicurezza desiderata in realtà non regge.

A volte puoi trovare le vulnerabilità per caso, perché ti capita di colpire un caso d'angolo e non si comporta come previsto e scopri che questo ha un impatto sulla sicurezza. Ma è molto più produttivo avere una conoscenza approfondita di ciò che stai attaccando. Hai bisogno di sapere quali componenti guardare, come regolare il tuo fuzzer per ottenere risultati interessanti in questo secolo, che la tua dimostrazione non è solo fallita perché non riesci a trovare gli argomenti giusti ...

    
risposta data 31.05.2013 - 12:05
fonte
2

Uso molti strumenti UNIX di base. grep, awk, cut, head, tail, cat e vim. Questo è quando il codice sorgente è lì. In caso contrario, colpisco IDA =)

Fondamentalmente quello che faccio è cercare le funzioni che si implementano spesso male (memcpy, malloc, aprire quei tipi di funzioni). E scorrere indietro fino a ottenere l'origine delle variabili utilizzate come argomenti. Quando questi sono controllati (filtrati), controllo se i filtri sono decenti. Se sono incontrollati (input dell'utente) avvio il processo di sfruttamento. E prova a risolvere il puzzle su come ottenere il massimo da quella singola funzione.

L'altro metodo che provo è solo quello di hackerarlo. Significa, vedo una casella di ricerca, provo solo il xss più semplice possibile e spero che funzioni. O con questo caso ho avuto un'applicazione client. Non è stato necessario l'autenticazione, quindi ho invertito il tutto e ho dimostrato che non era la strada da percorrere. Ho notato che la vulnerabilità era un tipo di sicurezza, quei ragazzi erano sviluppatori che non si preoccupavano abbastanza della sicurezza per sapere che il software di inversione era possibile.

Questi sono i miei modi, anche Fuzzing è fantastico. Come è mona.py

    
risposta data 31.05.2013 - 12:18
fonte

Leggi altre domande sui tag