Scanner per utenti vulnerabili rispetto alla vulnerabilità [chiuso]

5

Quando un essere umano potrebbe sovraperformare uno strumento di scripting durante la verifica delle vulnerabilità? Ad esempio, un essere umano potrebbe mai trovare qualcosa che non sarebbe SQLmap? In quali casi sarebbe preferibile / ci sono degli esempi?

Ad esempio, considera l'url:

"fakeurl.com/vuln.php?id=4"

Un umano potrebbe provare:

"fakeurl.com/vuln.php?id='"

e vedere se viene visualizzato un messaggio di errore, ma in quel momento potrebbe semplicemente eseguire

sqlmap -u fakeurl.com/vuln.php?id=4 --batch --dump-all

e trova tutto molto più velocemente.

So che molte persone amano guardare in basso i kiddies, ma per scopi pratici e professionali è meglio fare le cose velocemente e correttamente. Mi sembra che lavorare a mano sia meno efficiente e più soggetto a errori. Qualcuno può darmi un caso (tecnico o un esempio storico) in cui un essere umano ha trovato qualcosa che uno strumento non avrebbe avuto?

    
posta user3364161 31.10.2016 - 01:32
fonte

2 risposte

9

La maggior parte dei difetti di controllo / autorizzazione di accesso non verrebbe mai trovata da uno strumento (generico), perché non ha la comprensione di cosa dovrebbe essere accessibile e cosa no. (Detto questo, i pentesters esperti probabilmente sanno che un bel po 'di applicazioni non hanno questo documentato ...) Quindi questo è un esempio di un'intera classe di problemi.

Qualsiasi difetto logico (ad esempio un utente che è in grado di creare un altro utente con più privilegi in base alla progettazione) non verrebbe rilevato da uno strumento automatico.

Qualsiasi catena di vulnerabilità non sarebbe correlata, come ad esempio come utilizzare una perdita di informazioni a basso rischio, insieme a un DOM XSS a medio rischio insieme ad un'altra vulnerabilità a basso rischio per cambiare la password di un utente a qualsiasi cosa l'hacker voglia (questo è un esempio reale che ho visto).

Testare DOM XSS con uno scanner normale (come al solito) come la maggior parte di questi strumenti commerciali è abbastanza difficile in quanto non hanno un runtime Javascript, quindi perderanno la maggior parte di esso.

Anche per le cose testabili, uno strumento può avere diversi pattern da provare, ma probabilmente mancheranno casi più complessi. Ad esempio, cosa succede se un'applicazione ha un filtro della lista nera per XSS che blocca esplicitamente l'avviso (1) e tutti i vettori di attacco dello strumento lo hanno come payload? Passare attraverso un filtro della lista nera è quasi sempre possibile, ma è molto difficile per uno strumento automatico.

O considera il DoS. Come lo troverà uno strumento automatico?

Per un esempio finale, per quanto riguarda l'overflow del buffer in un file caricato ed elaborato, ad esempio un utente carica un'immagine che viene ridimensionata da una libreria lato server, vulnerabile a bof. Come potrebbe lo strumento automatizzato sapere che è il caso e in che modo creerebbe un exploit per questo?

Questi sono solo alcuni esempi, sono sicuro che altri citeranno molto di più.

In breve,

  • ci sono intere classi di vulnerabilità che non possono essere testate nel caso generico

  • anche per le vulnerabilità che sono automaticamente testabili, è praticamente impossibile scrivere test completi (una serie di test che trova tutte le istanze della vulnerabilità).

Naturalmente, considerando tutto questo, penso che non ci sia niente di sbagliato nell'usare strumenti per rendere più veloci molte cose. Tuttavia, qualsiasi risultato di uno strumento deve essere riprodotto dal tester e inoltre deve essere consapevole dei limiti dello strumento per poter aumentare i risultati con attacchi più creativi.

    
risposta data 31.10.2016 - 02:12
fonte
2

Voglio solo completare la risposta di cui sopra, vulnerabilità come SQL Injection e XSS possono essere rilevate da processi sistematici (non sempre), uno strumento sarebbe sufficiente per questo lavoro, ma come @lengyelg ha detto, ci sono casi complessi che possono 'essere rilevato da una facilità di strumento, ad esempio: un'iniezione SQL cieco in cui l'iniezione potrebbe essere dopo order by o limit , l'applicazione è dietro un WAF e la risposta dall'applicazione è una struttura di dati JSON; questo tipo di vulnerabilità ha bisogno di tempo per essere analizzato, se si esegue uno strumento, potrebbe non essere in grado di rilevare la vulnerabilità, non voglio dire che gli strumenti non sono in grado di rilevarli, ma uno strumento ha bisogno di conoscenza per essere configurato correttamente. Il modo migliore per ottenere questa conoscenza è farlo da soli, conoscendo l'applicazione, una risposta corretta, una risposta errata, un errore dall'applicazione, ecc; quando puoi capire molto bene il comportamento dell'applicazione e ciascuno dei suoi componenti, puoi costruire un buon exploit e configurare uno strumento per fare il lavoro più velocemente ed efficacemente. Uno strumento ci aiuta a fare il nostro lavoro, ma a mio parere, non dovrebbe mai fare completamente il nostro lavoro. Quindi penso che uno strumento abbia bisogno della conoscenza umana, un martello ha bisogno della giusta forza e della giusta direzione per fare un buon lavoro.

    
risposta data 01.11.2016 - 15:57
fonte

Leggi altre domande sui tag