Esiste un attacco di forza bruta simile a quello che dimostrano nei film [duplicato]

Quello che vedi nei film è un dispositivo di trama per aumentare la tensione, ogni volta che un personaggio è determinato, dà al pubblico un calcio. La realtà è un po 'diversa.

Esistono attacchi di forza bruta, tuttavia è tutto o niente: o si ottiene l'intero codice di accesso corretto o sbagliato. Non c'è modo di sapere se hai indovinato un personaggio corretto. I passcode sono in genere hash , in cui la modifica di una singola cifra restituisce un risultato crittografico completamente diverso. Potresti ottenere tutto tranne un singolo personaggio e non avresti alcuna indicazione che ti sia venuto vicino.

Quindi il vero cracking delle password potrebbe essere un po 'noioso dal punto di vista del film, in cui è necessario mostrare la progressione per mantenere l'interesse del pubblico. Quello che potevano fare è mostrare una barra di progressione per il calcolo di tutte le possibili permutazioni di un hash, ma non avrebbe un tempo di fine prevedibile - potresti essere fortunato e colpirlo subito, o farlo arrivare verso la fine del tuo bruto intervallo di forza. Non necessariamente buono per un film, ma un buon regista potrebbe farcela.

Blind SQL Injection è uno di questi esempi. Supponiamo che tu abbia la possibilità di eseguire l'iniezione SQL ma sei limitato a ciò che puoi iniettare. Qualcosa in righe di:

SELECT id FROM users WHERE username = <foo>;

Puoi inserire in foo ma non puoi ottenere altro output se non la pagina che restituisce 404 (se non esiste tale utente) o qualcos'altro (se c'è un risultato) . Non è possibile ottenere alcun risultato da questa query oltre allo stato della pagina ("funziona / non funziona").

In questa situazione potresti provare a indovinare alcuni dati sull'utente (come la sua password con hash o il suo numero di carta di credito) in questo modo:

SELECT id FROM users WHERE username = "kos" AND secret = "mellon";
SELECT id FROM users WHERE username = "kos" AND secret = "rosebud";

Una volta caricata una pagina, sai di aver indovinato la password correttamente.

Ora per la parte divertente: per indovinare in un tempo ragionevole, è possibile passare alla ricerca lessicografica binario:

SELECT id FROM users WHERE username = "kos" AND secret >= "a" AND secret <= "z" -- 1
SELECT id FROM users WHERE username = "kos" AND secret >= "a" AND secret <= "n" -- 0
SELECT id FROM users WHERE username = "kos" AND secret >= "o" AND secret <= "u" -- 0
SELECT id FROM users WHERE username = "kos" AND secret >= "v" AND secret <= "x" -- 1
SELECT id FROM users WHERE username = "kos" AND secret >= "w" AND secret <= "x" -- 1
SELECT id FROM users WHERE username = "kos" AND secret >= "x" AND secret <= "x" -- 1

Hai la prima lettera! Continua:

SELECT id FROM users WHERE username = "kos" AND secret >= "xa" AND secret <= "xz" -- 1
SELECT id FROM users WHERE username = "kos" AND secret >= "xa" AND secret <= "xn" -- 1
SELECT id FROM users WHERE username = "kos" AND secret >= "xa" AND secret <= "xg" -- 0
SELECT id FROM users WHERE username = "kos" AND secret >= "xh" AND secret <= "xk" -- 1
SELECT id FROM users WHERE username = "kos" AND secret >= "xj" AND secret <= "xk" -- 1
SELECT id FROM users WHERE username = "kos" AND secret >= "xk" AND secret <= "xk" -- 1

... e così via, fino a quando non conosci tutte le lettere.

Gli hash di Windows LM avevano questo meccanismo in cui la password era divisa in 7 stringhe di caratteri e hash separatamente. In tal caso la password viene rivelata in 2 metà. Ma gli hash LM si sono conclusi con Windows XP.

Estendere lo stesso meccanismo, solo per teorizzare, se ogni carattere della password fosse hash separato e l'hash finale fosse una concatenazione dei singoli hash, allora potrebbe esserci uno scenario vicino a quello che vedi nei film in cui la password è ha rivelato carattere per carattere. Ma questo è troppo lontano dalla praticità.

Sì, è possibile se utilizzi ad esempio attacchi temporali . Se la password non è con hash e confrontata con una stringa vulnerabile confronta, puoi misurare se inserisci i caratteri corretti uno per uno. Nella maggior parte delle lingue la stringa compare si ferma quando viene trovata una differenza, o le stringhe hanno lunghezze diverse. Questa è normalmente una buona cosa, perché si traduce in una velocità molto migliore. Se vuoi farlo senza la possibilità di un attacco di temporizzazione, di solito confronti fino alla fine delle stringhe, e imposta solo un valore booleano se riscontri una differenza, che alla fine ritorni. Inoltre devi stare attento con le ottimizzazioni del tuo programma, in modo che non venga modificato nella versione di collegamento.

C'è anche un padding oracle attack , dove puoi indovinare ogni byte della chiave confrontando le diverse risposte del server, come "Chiave non valida" e "Messaggio non valido".

È possibile utilizzare questo metodo nelle iniezioni SQL utilizzando la query UNION. Il metodo consiste nel char bruteforcing per char il server e farlo dormire se il carattere è corretto. Quindi, quando il server è lungo per rispondere, sai che il personaggio è corretto. Il metodo di cui stai parlando mi ha fatto pensare a questo.

In passato, e con sistemi di password primitivi, ci sono stati casi in cui qualcosa del genere avrebbe potuto funzionare.

Immagina un sistema in cui inserisci una password e alcuni codici controllano la password carattere per carattere finché non trova che tutti i caratteri corrispondono e restituisce con successo. O restituisce rifiutando la password non appena il primo carattere fallisce. Potresti quindi provare un attacco a tempo: se indovini il primo carattere a destra, verranno controllati due caratteri, il che richiede un po 'più di tempo rispetto al solo primo carattere. Un sistema intelligente controlla sempre tutti i caratteri, quindi il rifiuto di una password non valida richiede sempre esattamente la stessa ora.

C'era una variante, in cui un utente malintenzionato ha memorizzato una password poco prima della fine della memoria valida. Quindi il primo carattere era in memoria valida, ma si sarebbe verificato un arresto anomalo se il verificatore della password avesse tentato di leggere il secondo carattere. Quindi l'attaccante cerca solo 256 possibilità per il primo personaggio fino a quando non si arresta. Quindi spostano la password di una posizione dalla fine della memoria e attendono un arresto anomalo quando viene selezionato il secondo carattere corretto e così via.

Spero sinceramente che nessuno usi più quel tipo di controllo della password.

Se ricordo bene, i DVD usano uno schema in cui le cose sono protette da una chiave da 40 bit, ma questo può essere cambiato in cracking una prima chiave da 25 bit, e poi una chiave da 16 bit (o 24 e 17). Le chiavi da 25 bit sono ovviamente molto più facili da decifrare con la forza bruta rispetto alle chiavi da 40 bit.