DVWA: SQLI in BruteForce Easy

Questo post fa parte della serie DVWA.

In questo post non discuterò della vulnerabilità al brute force della pagina (nessun limite di tentativi, nessun controllo anti-bot, link costante, messaggio di errore deterministico...), ma dell'attacco SQL Injection a cui è vulnerabile.

Provando con il classico tentativo (inserendo ' nei due campi), otteniamo un errore:

[...] for the right syntax to use near '3590cb8af0bbb9e78c343b52b93773c9'' at line 1
Quella stringa di caratteri è un hash (più precisamente è il risultato di md5(') ). Da qui possiamo dedurre che le password siano salvate nel database tramite il loro hash. Dunque un attacco sqli al campo password è impossibile (qualunque stringa inserita è convertita in una stringa esadecimale da 32 caratteri). Tuttavia è possibile un attacco al campo username. Proviamo a dedurre la query:

SELECT * FROM tabella WHERE user = '$user' AND password = $password;

Non si può (come negli altri casi) inserire nel campo user il valore 1' OR '1' = '1, poichè la query risultante sarebbe:

SELECT * FROM tabella WHERE user = '1' OR '1' = '1' AND password = $password;

Se la password non è corretta, la query restituisce false.
Per aggirare questa condizione, possiamo usare il commento SQL: --, in modo da costruire questa query (gli spazi sono importanti!):

SELECT * FROM tabella WHERE user = '1' OR 1 -- AND password = $password;

Se il campo user vale "1' OR 1 -- ", otteniamo il risultato desiderato.

La query è corretta, però se proviamo ad inserire questo valore, non riusciamo a effettuare il login. Perché?

Una pratica molto comune nei casi dove il numero di risultati della query è noto, è quella di effettuare il controllo del numero di risultati.
Nel caso del login il risultato della query deve essere uno solo, poichè deve esistere una sola entry per una coppia (user, password).

A questo punto ci viene in aiuto SQL, con il comando LIMIT, che permette di selezionare indice e numero di risultati forniti dalla query. Mettendo in pratica, scrivendo  "1' OR 1 LIMIT 0,1 -- ", la query sarà:

SELECT * FROM tabella WHERE user = '1' OR 1 LIMIT 0, 1 -- 'AND password = $password;

Siamo riusciti ad effettuare il login!

C'è un'altra cosa interessante. In caso di succesful login, viene aggiunta alla pagina una immagine che ha come nome ciò che sembrerebbe il nome dell'utente con cui ci siamo loggati (es: admin.jpg). Perciò inserendo nel campo user "1' OR 1 LIMIT x,1 -- ", dove x >= 0, possiamo loggarci come ogni utente del sistema e leggerne il nome dall'immagine caricata.

DVWA: File Upload Medium

Questo post fa parte della serie DVWA.

Per cominciare, qual è la vulnerabilità che può comportare un file upload?

Quella più semplice risiede nella possibilità di generare un memory overflow, inserendo file giganteschi, oppure è possibile inserire programmi malevoli, script, effettuare defacing, ecc...

Il form permette di inserire una immagine nel server. Ma è veramente così? Vengono fatti dei controlli sul tipo di file inserito?

Osservando il codice html, si nota l'hidden input MAX_FILE_SIZE che accompagna sempre un file input (php implementa un controllo automatico della dimensione massima del file, basandosi su MAX_FILE_SIZE). Ovviamente questo parametro è decisamente bypassabile (modificando l'html o la request mediante un proxy).

Effettuiamo qualche prova.
Provando ad uploadare un file .php (ad esempio una shell), il form ci avverte che la nostra immagine non è stata uploadata.

Questi controlli sono solitamente fatti in determinati modi:

• Blacklist: lo script mantiene una lista di estensioni da non accettare
• Whitelist: lo script mantiene una lista di estensioni da accettare
• MIME-Type: lo script controlla l'Internet Media Type del file (riportato nel campo Content-Type (eg: Image/jpeg)
• Controllo indiretto di tipo: lo script invoca una funzione (come getimagesize() ), che fallisce se il file caricato non è una immagine.

Ovviamente il metodo più debole è quello che usa il MIME-Type, infatti, utilizzando un proxy locale, è possibile inserire un header "Content-Type: image/jpeg" nella parte relativa al file da uploadare.

Con la Blacklist, solitamente, si ricava l'estensione del file ricercando l'ultimo '.' della stringa e comparandolo con una lista. Se questa estensione compare nella blacklist, il file non viene uploadato. Ci sono vari modi di bypassare il controllo, il più immediato è quello di passare un file che ha come nome (nell'ipotesi che 'php' non sia ammessa) 'shell.php.' . Quando questo nome viene analizzato, l'estensione risulterà vuota e se non compare nella blacklist, sarà permessa. Inoltre durante la memorizzazione nel filesystem, l'ultimo punto viene ignorato dal sistema operativo, di conseguenza di avrà uploadato il file 'shell.php'.

La Whitelist ha una vulnerabilità strettamente legata al webserver e al modo in cui si comporta con le doppie estensioni. Ad esempio Apache se configurato male, può permettere di bypassare la whitelist, interpretando il file "shell.php.jpg" non come una immagine jpg, ma come un file php (molto raro che succeda).

Il controllo indiretto del tipo può essere ingannato a seconda del tipo di controllo: se è solamente limitato all'header del file, è possibile mettere nel file da uploadare le informazioni necessarie per far apparire il file ciò che in realtà non è. Ovviamene un controllo più diretto non è bypassabile.

In ogni caso, tornando a DVWA, provando ad inserire dei file non immagini si nota che questi non vengono uploadati. Provando con un proxy locale a modificare l'HTTP Request, aggiungendo al file uploadato l'header Content-Type: image/jpeg, qualunque file viene caricato.

Ma la vulnerabilità della pagina non si limita solo a questo, infatti la pagina salva tutti i file in un'unica folder, mentre le buone norme di sicurezza imporrebbero l'utilizzo di folder random-generated.

DVWA: Command Execution Easy

Questo post fa parte della serie DVWA.

SecurityLevel: Easy, entriamo in Command Execution.

È richiesto di inserire un indirizzo ip, se lo facciamo otteniamo sullo schermo l'output dell'operazione di ping.

Possiamo supporre che il codice php sia qualcosa tipo:

exec("ping ".$command);

Se siamo fortunati, non viene fatto alcun controllo sul comando inserito. Abbiamo varie soluzioni da provare (dipendono dal sistema operativo in cui è installato il webserver, nel nostro caso il nostro sistema operativo).

1. Linux) La shell permette di separare i comandi da eseguire inserendo ";"
2. Linux) La shell permette di eseguire due comandi concorrentemente separandoli con "&"
3. Linux) La shell permette di eseguire due comandi sequenzialmente separandoli con "&&"
4. Windows) cmd permette di eseguire sequenzialmente due programmi separandoli con "&"
5. Windows) cmd permette di eseguire sequenzialmente due programmi solo se il primo esce con non-error status separandoli con "&&"
6. Windows) cmd permette di eseguire sequenzialmente due programmi solo se il primo esce con error status separandoli con "||"

Il comando in comune che agisce sequenzialmente è && (se non si conosce il sistema operativo occorre avere l'accortezza di inserire un ip raggiungibile e pingabile in modo da non far fallire il comando ping).
Proviamo inserendo:
74.125.232.114 && echo Vuln!
Se alla fine del ping otterrete "Vuln!", significa che il codice è vulnerabile! Ora la fantasia entra in gioco! Possiamo ad esempio ottenere il codice php di qualsiasi pagina, es:
74.125.232.114 && cat path/pagina.php

Oppure, se l'OS è linux, probabilmente possiamo caricare un programma malevolo del server con wget e poi eseguirlo...


Permettere una simile vulnerabilità nel proprio sito web, è veramente da idioti.

DVWA: SQL Injection Easy

Questo post fa parte della serie DVWA.


Impostiamo il Security Level a Easy ed entriamo in "SQL Injection".
La differenza rispetto a "SQL Injection", è che in "SQL Injection (Blind)", non viene riportato l'errore causato da una malformazione del parametro di input.

È meglio cominciare con la versione non blind, per poter osservare eventuali errori.
Cominciamo inserendo un campo intuitivamente conforme a ID (un numero piccolo), come 1.
In ouput viene visualizzato qualcosa.
Proviamo ora ad inserire dei caratteri non alfanumerici.

Provando con ', otteniamo un errore.

Abbiamo scoperto che il form è vulnerabile a SLQ Injection. Cosa possiamo farci?
Se siamo "fortunati" e anche lo script di elaborazione dei risultati è fatto male, possiamo ad esempio pensare di ottenere le informazioni su tutti gli utenti.

Possiamo intuire la struttura della query:

SELECT * FROM tabella WHERE ID = $id;

Oppure

SELECT * FROM tabella WHERE ID = '$id';

Ipotizziamo la prima e proviamo a costruire questa query:

SELECT * FROM tabella WHERE ID = 1 OR 1;

Mettiamo nel form "1 OR 1", ma non otteniamo il risultato voluto, allora probabilmente è la seconda forma. Proviamo a mettere nel form "1' OR '1' = '1", in modo da ottenere:

SELECT * FROM tabella WHERE ID = '1' OR '1' = '1';

L'output è proprio quello desiderato: la lista di tutti gli utenti del database.

Etical Hacking - Damn Vulnerable Web Application

Oggi inizio una serie di post su DVWA, una web-application utile per imparare e testare le proprie abilità di Penetration.


DVWA è una applicazione PHP/MySQL, quindi occorre installare un webserver (come apache), un modulo PHP e il database MySQL. In rete è pieno di istruzioni su come installare un web-server WAMP (Windows-Apache-MySQL-PHP) o LAMP, perciò non mi divulgherò molto.
Per i windows-users consiglio EasyPHP.


Supponiamo di aver installato il web server in ascolto su 127.0.0.1, sulla porta 80.
Ora scarichiamo DVWA, scompattiamolo e mettiamolo nella RootDirectory del nostro sito (supponiamo che la folder di DVWA sia dvwa).
A questo punto possiamo accedere, tramite il nostro browser, a:

http://127.0.0.1/dvwa


Si aprirà una pagina di login, in cui dovremo inserire le credenziali di default (admin, password).

Ora che siamo entrati nella pagina di login, a destra possiamo scegliere fra varie vulnerabilities.
Per ogni vulnerabilities esistono 3 Security Level:

• Easy) il programmatore non ha inserito alcun sistema per prevenire attacchi.
• Medium) il programmatore ha inserito qualche mecchanismo di protezione ma è estremamente inefficace e facilmente bucabile.
• Hard) il programmatore ha inserito degli ottimi strumenti di protezione (serve come confronto rispetto agli altri 2).

I security level sono selezionabili nel menù a lato DVWA Security. Sempre da questo menù è possibile abilitare o meno PHPIDS (PHP-intrusion detection system), che abilità l'utilizzo di PHPIDS nel sito come layer di sicurezza (serve solo per far vedere che abilitandolo quasi tutti gli attacchi portati diventano inutili).In ogni sfida sono riportati dei link in cui è spiegato il tipo di attacco, inoltre in fondo alla pagina è presente un button "View Source", che permette di visualizzare il codice php della vulnerabilità (ovviamente da osservare dopo aver bucato il sistema ;) ).

I post che seguiranno faranno da how-to per varie sfide al livello di difficoltà easy/medium.