Cosa sta facendo questa iniezione SQL?

Question

Per farla breve, attraverso un vecchio sito di aspro, eseguo qualcuno che ha trovato un parametro URL non filtrato ed è stato in grado di eseguire questa query. Sto cercando di capire cosa fa se ...

La query dovrebbe leggere:

select * from reserve where id = 345 

quello che è stato eseguito era:

select * from reserve where id = 345 and ascii(substring((select concat(user,0x3a,password,0x3a,host) from mysql.user limit 0,1),17,1))=53 

Io non sono davvero sicuro cosa ottiene. Qualsiasi input?

Answer 1

Potrebbe essere necessario verificare se l'applicazione Web accede al database come root. La rimozione delle porzioni ascii(substring()) restituisce il seguente quando eseguito come root:

mysql> select concat(user,0x3a,password,0x3a,host) from mysql.user limit 0,1; 
+--------------------------------------+ 
| concat(user,0x3a,password,0x3a,host) | 
+--------------------------------------+ 
| root:<rootpw-hash>:localhost   | 
+--------------------------------------+ 

A seguito di una sonda di successo, essi possono quindi tentare di recuperare il contenuto di mysql.user da cui si può iniziare a craccare le password sulle tabelle arcobaleno.

Answer 2

L'SQL sta tentando di leggere i dati utente dalla tabella utente My-Sql che in genere contiene un elenco di utenti e host a cui è consentito l'accesso a un determinato server my-sql.

Mi sembra che il responsabile stia tentando di ingannare mysql per scaricare il contenuto della tabella utente in modo che possano quindi registrare gli hash delle password offline e dcrittarli per trovare accessi validi.

Se l'applicazione Web utilizza un accesso che consentirà l'accesso alla tabella degli utenti mysql, si tratta di un grave errore di sicurezza, se si utilizza un accesso a cui è stata concessa l'autorizzazione solo alle tabelle richieste per l'app, quindi nessuna informazione sarà ottenibile.

punta Sicurezza: Quando si imposta qualsiasi tipo di banca dati è di vitale importanza che l'applicazione utilizzando lo fa con un ruolo di login/di accesso che concede solo ciò di cui ha bisogno.

Se la tua applicazione ha solo bisogno di leggere i dati e non modificarli mai, non dovrebbe mai avere permessi diversi da leggere. È sempre necessario ricontrollare questo perché la maggior parte dei sistemi di database creerà per default i ruoli utente per un determinato database con piena lettura, creazione, modifica dei privilegi.

Creare sempre un utente specifico, solo per quel db eo collezione di tabelle, e dare sempre a quell'utente il minimo necessario, se la tua app viene hackerata con un attacco di cross site scripting, il più possibile anche l'accesso è un database specifico.

Answer 3

La seconda parte in cui condizione è davvero strano: sembra per un credenziali di MySQL ed elaborare nel modo seguente:

• concat (user, 0x3a, la password, 0x3a, host) sarà qualcosa di simile a 'someuser : hisPass: localhost'
• la stringa di cui sopra sarà divisa in una più piccola
• la stringa di cui sopra viene convertito in codice ASCII (si potrebbe sapere da lingue legacy come ord())
• il risultato della conversione è confrontato con 53 numero intero

suppongo che la prima parte di istruzione WHERE (id = 345) sarà sempre tornare true, mentre la seconda è troppo specifico, quindi l'intera query sarà probabilmente restituire un risultato vuoto tutto il tempo.

Answer 4

la query è apparentemente uno dal un insieme di essi:

• modificando la posizione charcode e sottostringa inizio e si può scoprire tutti i nomi utente e le corrispondenti hash delle password (quando la pagina esegue il rendering come previsto avere una corrispondenza di caratteri)
• consente di scoprire che l'utente corrente ha accesso allo schema mysql.

Answer 5

Un exploit sql injection non genera necessariamente immediatamente il risultato della query sulla schermata degli attacker, spesso il risultato è solo un errore, o nessun errore, o forse l'iniezione causa un ritardo misurabile (per l'attaccante). in questo modo l'attaccante può ottenere 1 bit di informazioni per richiesta.

Inviando un sacco di richieste, iterando su posizioni di stringa, facendo una ricerca binaria sui personaggi - o come in questo caso una ricerca lineare (che potrebbe indicare che l'attaccante non capisce veramente cosa sta facendo, ma lo farà ci arriveremo alla fine), sarà in grado di trovare tutti i caratteri nell'utente root mysql passwordhash. (Che può essere bruteforce offline).