Un sito di clienti ha avuto un grande attacco di iniezione mysql su di esso, voglio solo imparare da esso

Il semplice fatto che il DB abbia eseguito le query tra virgolette (gettandoti i rapporti di errore) significa che fa ha una vulnerabilità di iniezione nel codice PHP. Si noti che alcuni metodi di controllo della struttura delle tabelle DB implicano l'esecuzione di più query con parametri diversi finché DB non genera un errore e la pagina HTML si interrompe. Ciò significa che le query non riuscite sono solo la punta dell'iceberg di tutte le query eseguite.

Ci sono 5 query:

1) Invalida tutte le precedenti istruzioni WHERE restrittive aggiungendo effettivamente l'istruzione "o 1 = 1".

2) Verifica l'attacco DOS contro il DB del server SQL aggiungendo un'altra richiesta di ritardo.

3) Ispezione del numero di colonne nella tabella DB. Il numero di null-s sulla modifica tra le query passate e quelle non riuscite è l'unico ricercatore che cerca.

4) Lo stesso vale per le tabelle di autorizzazione degli utenti: termina la ricerca con un ID inesistente, quindi controlla il numero di colonne. null-s sono sostituiti da valori HEX.

5) errare il controllo dell'autore iniettando $ utente predisposto nella stringa PHP di query come

"SELEZIONA ... DOVE ... AND name = '" + $ user + "'"

(annota l'esatta sequenza di virgolette singole e doppie) È probabile che l'utente "leachiancs" sia stato effettivamente acquisito da precedenti indagini.

Queries (1) - (4) portano il commento SQL alla fine per invalidare il resto della query originariamente intesa e sconfiggere LIMIT o altri costrutti WHERE di validazione.

La lezione principale qui è usare solo le query parametrizzate e non provare a riprodurre tutto il lavoro sporco dell'appropriazione corretta di DB + PHP per tutte le possibili versioni e stranezze nella sintassi.

Mi sono divertito a "decodificare" due query, quindi ecco come l'ho fatto in PHP: p

1) or 1=convert(int,(select cast(Char(114)+Char(51)+Char(100)+Char(109)+Char(48)+Char(118)+Char(51)+Char(95)+Char(104)+Char(118)+Char(106)+Char(95)+Char(105)+Char(110)+Char(106)+Char(101)+Char(99)+Char(116)+Char(105)+Char(111)+Char(110) as nvarchar(4000))))--

Quindi iniziamo con la copia di questo pezzo di codice in una variabile:

$str = 'Char(114)+Char(51)+Char(100)+Char(109)+Char(48)+Char(118)+Char(51)+Char(95)+Char(104)+Char(118)+Char(106)+Char(95)+Char(105)+Char(110)+Char(106)+Char(101)+Char(99)+Char(116)+Char(105)+Char(111)+Char(110)';
preg_match_all('/\d+/', $str, $m); // Some regex Fu to get the numbers
$sql = implode('', array_map(function($v){return chr($v);}, $m[0])); // converting the numbers to letters
echo $sql; // output

Questo mi ha dato r3dm0v3_hvj_injection e dopo verificando la conversione di mysql e la sintassi del cast sembra che sia incasinato qui, ma non ne sono sicuro, ma fondamentalmente questo è un metodo di offuscamento e l'intento era di finire con or 1=1 .

2) ; if (1=1) waitfor delay \'00:00:07\'--

Bene ; dichiara la fine dell'istruzione e il resto sembra un attacco basato sul tempo . Anche se questo sembra inutile dato che mysql api in php non può eseguire 2 query contemporaneamente. -- commentando il resto della query.

3) union all select null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null--

Sembra inutile per me, ma può determinare quante colonne hai da quando questo genererà un errore se il numero di null non corrisponde al numero di colonne che hai.

4) 999999.9 union all select 0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536--

Bene, copiamo quei vram esadici in una variabile e facciamo del php-fu su di esso:

$str = '0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536';

$result = implode(',', array_map('hex2str', explode(',', str_replace('0x', '', $str)))); // PHP-Fu
echo $result;// output

// function hex to ascii
function hex2str($v){
    $r = '';$l = strlen($v)-1;
    for($i=0;$i <= $l;$i+=2){
        $r .= chr(hexdec($v[$i].$v[$i+1]));
    }
    return $r;
}

Questo mi ha dato: 1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056,1025480056

Anche se è strano perché è lo stesso, ricontroliamolo da esadecimale a stringa:

echo hex2str('1025480056');

L'output è %HV , con un normale editor esadecimale ci sono altri 2 caratteri oscuri .

Bene, penso che lo scopo potrebbe essere lo stesso che in attacco # 3 è solo offuscato.

5) leachiancs\' and \'x\'=\'x

Quota where a=b and x=x semplice.

Conclusione:

Le wild r3dm0v3_hvj_injection e % HV vengono visualizzate, con 120 e-mail entro 5 minuti sospetto strongmente che questa sia una prova che questo attacco è stato eseguito con un automated SQLi tool Havij .

Prevenzione:

Utilizza DOP o MySQLi con istruzioni preparate .

Which makes me glad to know that I'm knowledgeable enough in my php to know how to prevent these things.

Questa è una mentalità straordinariamente pericolosa da sottrarre a questo incidente.

Il fatto che l'autore dell'attacco non sembri avere dati cancellati non significa che non ha letto dati che non dovrebbero avere. E il fatto che fossero in grado di inserire input che hanno causato errori di database è una prova schiacciante che non in realtà sa come impedire queste cose, come le istruzioni preparate e le query parametrizzate avrebbero impedito anche questo.

Come per le stesse query fornite, in primo luogo sembrano essere i tentativi di trovare una vulnerabilità di SQL injection in primo luogo.

Sembra che l'aggressore stia cercando di indagare sul tipo di attacchi possibili con la vulnerabilità che ha trovato.

A prescindere; la lezione è sempre la stessa: usa query parametrizzate. Se devi ricordare di citare e sfuggire i tuoi dati, allora stai sbagliando.

Se vuoi saperne di più su come funzionano gli attacchi tipici dell'iniezione SQL, guarda gli strumenti automatici come la suite di burp che sono tipicamente usati per questo tipo di attacco.