Come sfruttare la vulnerabilità "PHP_MAGIC_QUOTES ON" per causare il massimo danno?

22

Ho trovato un sacco di exploit di SQL injection in alcuni sistemi che mantengo. So come prevenire l'iniezione, ma vorrei dimostrare al mio CEO e CTO quanto sia pericoloso se non ci concentriamo abbastanza sul mantenimento delle nostre applicazioni.

Molte volte dobbiamo reagire invece di agire in modo proattivo quando si tratta di sicurezza, soprattutto perché quando viene rilevata una vulnerabilità non è necessario stabilire una priorità perché è improbabile che venga sfruttata.

La seguente query è uno di questi esempi. Il server è in esecuzione con PHP_MAGIC_QUOTES ON (sì, so che è davvero pessimo) e quindi previene gli exploit in diversi posti perché i programmatori hanno aggiunto esplicitamente "attorno a tutti i valori di input utilizzati nelle query (quindi non riesci a uscirne). La query che ho trovato vulnerabile ora è tuttavia trattata come un numero intero invece di una stringa e non contiene "attorno".

Ecco l'esempio:

$sql = "select * from vulnerable_table where id = " . $_GET['id'] . " limit 1"; 
$result= mysql_query($sql); 

Come faresti il danno massimo al sistema considerando di controllare la variabile id.

Alcuni esempi che ho trovato da soli:

id = 1;drop table mysql.user 
Only if semi colon is accepted

id = 1;SELECT '<?php exec($_get['cmd'])?>' INTO OUT_FILE('/var/www/backdoor.php')
Only if I could bypass the magic_quotes somehow
    
posta Chris Dale 21.12.2010 - 14:10
fonte

7 risposte

18

In PHP non puoi impilare le query con un punto e virgola. Tuttavia puoi annidare una query in un'altra con parentesi (comunemente chiamate sottoquery), ad esempio:

SELECT * FROM vulnerable_table WHERE id = (SELECT number from other_table)

Usando questa tecnica (ignorando se si restituisce o meno il risultato SQL) un attaccante acuto può estrarre tutti i dati dal proprio database.

Esempio (con output sulla pagina Web)

SELECT * FROM vulnerable_table WHERE id = (SELECT group_concat(table_name) from information_schema.tables WHERE version = 10)

Questa query genererà un elenco (come stringa) di tutte le tabelle definite dall'utente nel database. Ulteriori query riveleranno le colonne e permetteranno all'avversario di acquisire una conoscenza completa della struttura della tabella (ad esempio: "tbl_accounts, tbl_passwords, tbl_guestbook").

Se non si fornisce alcun output sulla pagina Web, un utente malintenzionato potrebbe ancora iniettare un'istruzione condizionale (think: case-when) con la sottoquery SQL, che si tradurrà in un errore SQL in un caso e nessun errore nel altro caso. Derivato da "nessun output" e dalla tua normale pagina web puoi raccogliere 1 bit di informazioni ed effettuare una ricerca binaria attraverso il tuo database.

Generare stringhe in una query SQL come quella che hai suggerito di caricare una PHP-Backdoor (a seconda che l'utente corrente di MySQL abbia il privilegio FILE, che non dovrebbe;)) non è poi così difficile da ottenere: Le funzioni ascii () e ord () puoi semplicemente creare le stringhe con input interi. Anche un valore come 0x414141 verrà automaticamente convertito in "AAA" in MySQL.

Per quanto riguarda le tecniche di attacco e di evasione dei filtri molto avanzate, ti consiglio anche di leggere il blog di Reiners sulla sicurezza SQL: link

Per completezza: per correggere questa vulnerabilità, puoi semplicemente eseguire un typecast e trasformare $ _GET ['id'] in un intero.

    
risposta data 22.12.2010 - 12:11
fonte
11

Se la tua azienda è in qualche modo una parte delle normative che richiedono sicurezza (come SOX o HIPPA negli Stati Uniti) o standard commerciali (come PCI o vari standard ISO), tutto quello che devi fare è dire loro che:

  • hai trovato buchi che potrebbero consentire a chiunque di scaricare l'intero database e la rete (allunga un po 'la verità se devi venderlo e ricorda loro l'ACS: perdita di legge).
  • dai loro numeri difficili su quanto tempo e denaro costa ad altre aziende che hanno perso dati o sono stati violati.
  • che se sei mai sottoposto a revisione, la società può essere multata o abbattuta per non aver rispettato gli standard.
  • che se sei mai stato citato in giudizio o perseguito, e c'è qualche prova che hai ignorato un potenziale problema noto o maggiore, i danni punitivi potrebbero essere sufficienti per portare la compagnia alla bancarotta. (Vedi la causa Ford Pinto.)

Questo funzionerà meglio se puoi parlare con l'avvocato della compagnia per fornire le cattive notizie. Se ciò non funziona, non c'è nulla che possa salvare la tua azienda.

Qualunque cosa tu faccia, dimentica di sfruttare te stesso. Ti apri alle cause legali e al carcere se lo fai senza il permesso scritto, anche se una piccola prova che mostra che funziona su un account di prova appositamente impostato per lo scopo potrebbe funzionare.

    
risposta data 22.12.2010 - 02:55
fonte
4

Qui è possibile l'estrazione di informazioni (come la lettura di file o l'estrazione di informazioni sull'utente del database) e il consumo delle risorse del server. Il primo è ottenibile utilizzando l'istruzione UNION nella query. Il secondo è fatto usando la funzione BENCHMARK (). L'estrazione dei dati è possibile anche tramite l'uso della funzione menzionata.

Non voglio mostrare esempi qui - sono su Internet. E suppongo che, come manutentore del sistema, siate in grado di riprodurre i casi. Se ne hai veramente bisogno, commenta.

A proposito, non è necessario supportare il punto e virgola per poter scrivere su file (tuttavia è necessario accedere a scrivere su file).

    
risposta data 21.12.2010 - 15:02
fonte
3

Penso che questo cartone dice tutto. Little Bobby Tables

    
risposta data 21.12.2010 - 18:38
fonte
2

id =

0 OR id <> 0

ignorerebbe completamente l'uso dell'ID e l'hacker potrebbe quindi scaricare l'intera tabella.

    
risposta data 21.12.2010 - 20:15
fonte
2

Il danno massimo è relativo. Inserire discrezionalmente piccoli dati difficili da rilevare su base continuativa può potenzialmente essere molto più devastante che distruggere grandi quantità di dati in un solo colpo.

Una situazione ancora potenzialmente peggiore potrebbe essere semplicemente la lettura dei dati su mesi / anni. Quanti numeri di carta di credito memorizzi in quel database? Le password?

Nessuno può mostrarti il proiettile d'argento dell'iniezione SQL. Dipende dai dati che stai mantenendo, dall'abilità dell'attaccante, dal fatto che abbiano una conoscenza approfondita, l'architettura dello schema, ecc.

    
risposta data 26.12.2010 - 10:02
fonte
0

Se il sito è Drupal, potrebbero modificare la password per l'utente 1 nella tabella utente per fornire loro l'accesso amministrativo e fare un danno più mirato in seguito poiché ora hanno la possibilità di esplorare il sito con i privilegi di amministratore.

    
risposta data 21.12.2010 - 20:57
fonte

Leggi altre domande sui tag