Attacco di troncamento SQL

La vulnerabilità del troncamento SQL si verifica quando un database tronca l'input dell'utente a causa di una restrizione sulla lunghezza. Gli aggressori possono raccogliere informazioni sulla durata di un campo critico (come un nome utente) e sfruttare queste informazioni per ottenere un accesso non autorizzato. Gli aggressori possono accedere come un altro utente, come un amministratore, con la propria password registrata.

La vulnerabilità del troncamento SQL di solito esiste nei database MySQL. Questa vulnerabilità è stata descritta per la prima volta nel CVE-2008-4106, che era correlato al CMS WordPress.

Come funzionano gli attacchi di troncamento SQL

Questo attacco funziona a causa del troncamento dell'input dell'utente nei database utilizzando le funzioni "Selezione" e "Insertion".

• Quando viene fornito l'input nel campo del modulo, la funzione "Seleziona" controlla la ridondanza corrispondente agli ingressi nel database.
• Dopo aver verificato la ridondanza, la funzione "inserimento" controlla la lunghezza dell'input e l'input dell'utente troncerà se la lunghezza supera.

Supponiamo che uno sviluppatore crei la tabella "utenti" tramite la seguente query:

Crea utenti di tabelle (
user_id int non null automatico,
user_name varchar (20) non null,
password varchar (40) non null,
Chiave primaria (user_id)
);

Utilizzando questo schema, se lo sviluppatore crea un account amministratore con quanto segue:

user_name = 'admin'
Password = "Secret_P4SSW0ord"

Ovviamente, queste credenziali non sono pubbliche. C'è solo un account amministratore nel database e se un utente malintenzionato cerca di registrare un altro account con il nome utente "amministratore", l'attaccante fallirà a causa dei controlli di ridondanza del database. L'attaccante può ancora bypassare quel controllo di ridondanza per aggiungere un altro account amministratore sfruttando la vulnerabilità del troncamento SQL. Supponiamo che l'attaccante registri un altro account con il seguente input:

User_name = 'AdminxxxxxxxxxxxxxRandom'
(x sono gli spazi)
E
Password = "RandomUser"

Il database prenderà il 'user_name' (26 caratteri) e verificherà se questo esiste già. Quindi, l'input User_Name verrà troncato e 'Admin' ('Admin' con spazio) verrà inserito nel database, risultando in due utenti di amministrazione duplicati.

L'attaccante è quindi in grado di creare un utente "amministratore" con la propria password. Ora, il database ha due voci di amministrazione 'user_name', ma con password diverse. L'attaccante può accedere con le credenziali appena create per ottenere un pannello di amministrazione perché sia ​​User_Names "Admin" che "Admin" sono uguali per il livello del database. Ora guarderemo un campione di attacco pratico.

Attacco campione

In questo esempio, prenderemo uno scenario dal sito Web overthewire.org. La comunità di Overthewire fornisce CTF Wargame su cui possiamo praticare i nostri concetti di sicurezza. Lo scenario della troncamento SQL si verifica nel livello di gioco di Natas 26-> 27. Possiamo accedere al livello utilizzando quanto segue:

URL: http: // natas27.natas.Labs.Overhewire.org
Nome utente: Natas27
Password: 55tbjppzuuujgvp5b3bnbg6on9udpvzcj

Questo livello è disponibile su: https: // overthewire.org/wargames/natas/natas27.html. Ti verrà mostrata una pagina di accesso che è vulnerabile a un attacco di troncamento SQL.

Dopo aver ispezionato il codice sorgente, vedrai che la lunghezza del nome utente è 64, come mostrato di seguito.

Un utente di nome 'Natas28' esiste già. Il nostro obiettivo è quello di creare un altro utente chiamato "Natas28" usando l'attacco SQL_Truncation. Quindi, inseriremo Natas28, seguito da 57 spazi e un alfabeto casuale (nel nostro caso, a), nome utente e qualsiasi password. La lettera "A" non è visibile nello screenshot a causa del nome utente di lunghezza di 65 caratteri. Dopo la creazione dell'account utente, sarai in grado di vedere il 'UN.'

Se il database contiene la vulnerabilità SQL_Truncation, il database dovrebbe ora avere nomi utente "Natas28". Un nome utente conterrà la nostra password. Proviamo a inserire le credenziali nella pagina di accesso.

Ora abbiamo effettuato l'accesso come utente "Natas28".

Mitigazione

Per mitigare questo attacco, dovremo considerare più fattori.

• Non dovremmo consentire la duplicazione di identità critiche come il nome utente. Dovremmo fare queste identità di chiavi primarie.
• La funzione Truncate dovrebbe essere implementata per tutti i campi dei moduli di frontend, nonché il codice backend, in modo che i database ricevano input troncati.
• La modalità rigorosa dovrebbe essere abilitata a livello di database. Senza una modalità rigorosa abilitata, i database forniscono solo avvisi nel backend, ma salvano comunque i dati duplicati. Con una modalità rigorosa, i database forniscono errori in caso di duplicazione ed evita di salvare i dati.

Ad esempio, verifichiamo la modalità rigorosa utilizzando la seguente query:

mysql> Seleziona @@ sql_mode

Creeremo un database e gli utenti della tabella.'

mysql> crea test del database
Query ok, 1 riga interessata (0.02 sec)
mysql> usa test
Database modificato
mysql> crea utenti tabella (nome utente varchar (10), password varchar (10));
Query ok, 0 righe interessate (0.05 sec)

Successivamente, creeremo un utente di amministrazione con credenziali utilizzando la query sugli insert.

mysql> inserisci nei valori degli utenti ('admin', 'password1');
Query ok, 1 riga interessata (0.01 sec)

Possiamo vedere le informazioni sulla tabella "utenti" utilizzando l'opzione "Seleziona * dagli utenti".

La lunghezza del nome utente è di 10 caratteri. Ora proveremo l'attacco di troncamento SQL.

Quando proviamo a inserire quanto segue:

Nome utente = 'adminxxxxxa'
(x sono gli spazi)
E
Password = 'pass2'

Riceveremo un errore, il che significa che la modalità rigorosa è totalmente efficace.

mysql> inserisci nei valori degli utenti ('admin a', 'pass2')
Errore 1406 (22001): dati troppo lunghi per la colonna "nome utente" alla riga 1

Senza una modalità rigorosa abilitata, il database emetterà avvertimenti, ma inserirà comunque i dati nella tabella.

Conclusione

Gli aggressori possono ottenere l'accesso a account ad alto privilegio se esiste la vulnerabilità SQL_Trunction nell'applicazione. L'attaccante può facilmente ottenere informazioni su un nome utente e la sua lunghezza del database utilizzando i campi critici, quindi creare lo stesso nome utente, seguito da spazi e alfabeto casuale dopo la lunghezza minima, con conseguente creazione di più account ad alto privilegio. Questa vulnerabilità è fondamentale, ma può essere evitata se si prendono alcune precauzioni di sicurezza, come l'attivazione di una modalità rigorosa per gli input dell'utente e rendere il campo sensibile la chiave primaria nel database.