Database compromesso (SQL-injection): come gestire la situazione, dopo il fatto?

Question

Database compromesso (SQL-injection): come gestire la situazione, dopo il fatto?

#1 da (1 voti)
#2 da (-2 voti)

2

Situazione

Abbiamo scoperto che uno dei nostri database (MySQL) è stato compromesso tramite l'iniezione SQL. Il vettore di iniezione era una query vulnerabile a SQL-injection a causa della concatenazione di stringhe nella sua clausola WHERE .

L'utente MySQL per l'applicazione Web in questione ha eseguito privilegi piuttosto limitati ( SELECT , DELETE , UPDATE , INSERT ) su un singolo database insieme al database information_schema . Il server di database è accessibile solo da macchine autorizzate (accesso illimitato a Internet).

Per quanto possiamo vedere, l'utente malintenzionato ha eseguito tutte le interazioni con il nostro database tramite le richieste di HTTP GET all'applicazione Web vulnerabile. Abbiamo protetto i log degli accessi e degli errori del server web che mostrano chiaramente tutte le query tentate. La cosa sfortunata è che l'hacker ha avuto accesso al nostro database per circa 3 giorni. Pertanto, penso che dobbiamo presupporre che il nostro intero database sia stato mappato e che la maggior parte dei dati di interesse siano stati scaricati dall'attaccante.

Al momento della scoperta, l'attacco era ancora in corso; è stato interrotto e la clausola WHERE vulnerabile è stata sostituita da un segnaposto di istruzioni preparato (come avrebbe dovuto essere sempre stato). Dato che l'attacco era ancora in corso, penso che posso presumere che non siano ancora riusciti a ottenere tutti dati. Dopo che la vulnerabilità è stata corretta, abbiamo ruotato le 'password' ¹ per tutti gli utenti che avevano accesso a questo server di database.

I dati

Il database in questione è il datastore per un negozio online. Non ci sono informazioni di pagamento nel database (tutte le transazioni di pagamento sono gestite da un fornitore di servizi di pagamento (terzo)) e le password utente sono state sottoposte a hash con BCrypt con un fattore di lavoro abbastanza dignitoso.
Il database contiene gli ordini dei clienti (insieme alle informazioni sugli indirizzi), i prodotti, le scorte, ecc.

Domande

Il buco è stato tappato, quali passi tecnici ² dovrebbero essere fatti ora (oltre a ruotare le credenziali dell'utente MySQL, cosa che abbiamo già fatto)?
Poiché disponiamo dei file di registro con tutti i tentativi di query, dovrebbe essere possibile capire esattamente quali tabelle sono state scaricate.
Che cosa è uno strumento valido per estrarre queste informazioni da 1 GB combinato di accesso al server Web e file di log degli errori?
Quali sono gli usi dannosi comuni di dati rubati come questo? Attacchi di phishing rivolti ai clienti del webshop?

_{¹: ASCII lungo 32 caratteri, stampabile, stringhe casuali.
²: C'è sicuramente una parte giudiziaria, di comunicazione e di pubbliche relazioni su questo problema , ma questa domanda si concentra esclusivamente sulla parte tecnica dell'incidente.}

sql-injection forensics

posta Monika 12.09.2017 - 22:08

fonte

2 risposte

Leggi altre domande sui tag sql-injection forensics

Memorizza le chiavi PGP in HSM C ++ binary offuscamento: come aggirare i controlli delle licenze come semplici rami if / then?

score 1 · Answer 1

1. Il buco è stato tappato, quali passi tecnici dovrebbero essere presi ora (oltre a ruotare le credenziali dell'utente MySQL, che abbiamo già fatto)?

Controlla il sito web. Preferibilmente da qualcuno al di fuori dell'azienda se hai il budget. Il termine di ricerca che stai cercando è "pentest". Inoltre, se l'applicazione visualizza tutti i dati memorizzati nel database direttamente sul sito Web, verificare se l'autore dell'attacco ha inserito opportunisticamente un XSS memorizzato. (Javascript per rubare credenziali di testo in chiaro, per esempio)

2. Poiché disponiamo dei file di log con tutti i tentativi di query, dovrebbe essere possibile capire esattamente quali tabelle sono state scaricate. Che cosa è uno strumento valido per estrarre queste informazioni da un combinato 1 GB di accesso al server Web e file di log degli errori?

Non sono a conoscenza di tale strumento, mi dispiace. Puoi sempre provare e farlo manualmente. Prova a utilizzare qualsiasi tipo di linguaggio di scripting (bash e prompt dei comandi lo faranno) per ricreare le query eseguite dai file di log. Da lì puoi facilmente capire quali tabelle sono state consultate, ma sarebbe stato molto impegnativo ottenere maggiori dettagli in questa materia.

Se lo fai, cerca le istruzioni di inserimento e aggiornamento, per vedere se ha modificato o aggiunto anche i dati.

3. Quali sono gli usi dannosi comuni di dati rubati come questo? Attacchi di phishing rivolti ai clienti del webshop?

Può essere usato per alcune cose. Suppongo che la lista contenga anche indirizzi email? (i webshop lo fanno spesso)

L'utente malintenzionato potrebbe provare a utilizzare i dati per compromettere altri account su altri servizi. potrebbe:

prova a decifrare le password e usale su altri siti web. Le password sono state salate? Altrimenti, può provare a usare i tavoli arcobaleno.
Utilizza le informazioni del tuo sito web per provare a recuperare account su altri siti web senza infrangere la password. Utilizzando le domande di recupero.
Utilizza gli indirizzi email (se li hai archiviati) per scopi di spam. Può anche solo vendere l'elenco email.
phishing come hai detto tu stesso

score -2 · Answer 2

L'unica cosa che posso dire in merito è come evitarlo di nuovo. Cambiare le informazioni utente del database SQL sarebbe un piccolo passo, ma è essenziale sfuggire i dati prima di inserirli nel database o anche solo la query è essenziale. Questo può essere fatto in circa 5 righe tramite una funzione che è possibile riutilizzare per ogni input.

Ad esempio, in PHP, sarebbe simile a questo:

$con = In this example, I'm saying this is the connection.

function escape($string) {
  global $con;
  return mysqli_real_escape_string($con, $string);
}

Quindi, prima ancora di inserirlo nel database, ad esempio, afferrando una variabile da un URL tramite un metodo get, dovresti fare qualcosa di simile:

$data = escape($_GET['data']);

Quindi se inserissi "$ data" nel database, saresti sicuro che è sicuro dall'iniezione SQL con il metodo di escape.

Capisco che potresti non usare PHP, ma volevo solo capire quanto sia facile proteggersi dalle iniezioni in poche righe.

È davvero così semplice stare al sicuro dalle iniezioni SQL.

Saluti.