Penetration test – Testare il network e fare il primo attacco

Testiamo il server web

Prima di concentrarci sulle singole applicazioni web stesse è conveniente verificare le vulnerabilità del server web stesso, rifacendoci al manuale WSTG (Web Security Testing Guide) di OWASP

Possiamo usare nikto per una scansione veloce.

nikto -h http://192.168.0.30

Questo strumento ci restituisce, se presenti, alcune mitigazioni che dovrebbero essere implementate sul server web per ridurre i rischi in futuro.

Ci vengono riportate alcune probabili insicurezze nella configurazione del web server, come gli header X-XSS o i frame-options non settati.

Come abbiamo visto conosciamo anche l’ esatta versione del server web della quale è possibile ricercare eventuali vulnerabilità con searchsploit.

searchsploit apache 2.4

Se la scansione di nikto restituische la possibilità di metodi HTTP arbitrari, possiamo provare a caricare un file sul server con il metodo PUT di HTTP per vedere se fosse abilitato

echo "Ciao sono test" > test.txt
curl --upload-file test.txt http://192.168.0.30

Se il metodo PUT non fosse abilitato, potrebbe essere comunque permesso su alcune cartelle, vedremo più avanti…

Testare la configurazione della piattaforma applicativa

Una buona norma è quella di cercare i log dell’applicazione, questi potrebbero fornire informazioni utili sui componenti utilizzati dal sistema. A volte i log contengono informazioni sensibili e stack trace sarà in grado di leggerne i risultati generando errori casuali manomettendone le richieste, tipo caricamento di pagine di errore 404 o sfruttando vulnerabilità di directory trasversal

Pagine amministrative

Ogni CMS contiene la propria pagina amministrativa, ad esempio WordPress ha la sua pagina di login wp-login.php. Spesso sarà sufficiente guardare il file robots.txt o eseguire un dirbust sul server per enumerarle. una volta identificata l’applicazione in uso, si potrà sempre cercare la relativa documentazione online per verificare il percorso esatto.

Test sui metodi HTTP

Esistono diversi metodi HTTP oltre a GET e POST, come HEAD che restituisce solo gli headers della pagina, PUT per caricare file, DELETE per rimuoverli. Il metodo OPTONS restituisce verbi HTTP supportati dal server.

Modifica delle richieste tra metodi GET e POST

In molti server, seppur configurati correttamente, è possibile eseguire una richiesta POST o GET intercambiabili tra loro. In questo modo fare il brute forcing dei form diventa molto più semplice.

Se intercettiamo la richiesta con burp ( Proxy / Intercept ) compilando un form con dati a caso, noteremo che la richiesta è di tipo POST.

Repeater

Ripetiamo la richiesta del form cambiando il metodo della richiesta a GET, disabilitiamo l’intercept per passare questa volta dal Repeater di burp, in modo da poter intercettare la richiesta più volte senza dover intercettare la pagina di nuovo.

Quindi dalla scheda Proxy nella quale avevamo intercettato la richiesta, scegliamo, col tasto destro, l’opzione Send to Repeater. Noteremo la scheda Repeater illuminarsi di rosso. Cambiamo la modalità in Intercept is off. spostiamoci nella scheda Repeater e clicchiamo su Go. Nella finestra Response del Repeater oltre all’ intstazione, troveremo l’HTML della risposta.

Clicchiamo col destro nella finestra Request e cambiamo il metodo di richiesta scegliendo Change request method e rinviamola con GO.

Come abbiamo appena visto è molto semplice intercambiare i metodi della richieste tra loro, sruttando eventuali insicurezze dello script PHP.

Possiamo anche effettuare la richiesta con un metodo personalizzato, cancellando GET (o POST) all’inizio della Request e sostituendolo anche con un metodo inesistente, a nostro piacere. In questo modo sarebbe più facile effettuare un attacco brute force per scoprire la password di un ipotetico utente admin.

Esistono numerosi strumenti di brute forcing!

Intruder

Possiamo inviare la richiesta all’ intruder di burp passando una serie di wordlist da provare. Col tasto destro inviamo la richiesta all’intruder scegliendo Send to Intruder.

Cercheremo la porzione della pagina con scritto authenticated di autenticato come admin per trovare la password corretta.

Spostiamoci nella scheda Position

Definiamo il segnaposto cambiando user=$test$ (se nel compilare il form avevamo messo test) con admin, poi evidenziamo il valore della stringa del PHPSESSID e cancelliamo i dollari premendo il pulsante clear $.

Nella scheda Payloads carichiamo la wordlist che vogliamo utilizzare, Cliccando su load nella sezione Payloads Options. Una molto nota è reperibile da metasploit. Su Kali linux ne abbiamo già pronta una nel percorso:

/usr/share/wordlist/metasploit/unix_password.txt

Ora definiamo la stringa di nostro interesse nella scheda Options alla sezione Grep – Match. Cancelliamo tutto col tasto Clear e inseriamo Authenticated nell’input field e poi clicchiamo su Add, Aggiungiamo anche authenticated in minuscolo.

Clicchiamo infine su Start attack nella scheda Positions. Se l’attacco è andato a buon fine vedremo il record nella lista della finestra Intruder attack col il check box true. Il relativo dato corrispondente al campo Payload corrisponde alla nostra password.

Test HTTP Strict-Transport-Security (WSTG-CONFIG-007)

Un’altra aspetto da testare riguardante la configurazione del server è la presenza dell’ header di risposta HSTS ovvero la sicurezza rigida per il trasporto HTTP che è una direttiva per il browser che impone un traffico sempre criptato e quindi viaggiare sempre in HTTPS al fine di evitare tecniche di sniffing o dirottamenti.

Facciamo un test su multillidae per verificare il certificato SSL self signed

curl -k -head https://192.168.0.30/multillidae

L’opzione di curl -k permette connessioni insicure del server quando si usa SSL, mentre l’opzione -H (–head) pernette di passare un header personalizzato al server.

Qual’ora l’header HSTS il sistema è insicuro.

Test RIA cross domain policy (WSTG-CONFIG-008)

Il Rich Internet Applications policy files (File di criteri delle applicazioni Internet avanzate) è un file solitamente presente nelle root dei siti, è un file XML che determina le restrizioni di accesso a diversi domini sui siti, qualora queste regole fossero troppo generiche, potrebbero rendere possibile lo sfruttamento di vulnerabilità CSRF tra i diversi domini definiti.

https://www.google.com/crossdomain.xml

Quella di google è una policy ben definita

<?xml version="1.0"?> 
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy>   
  <site-control permitted-cross-domain-policies="by-content-type" /> 
</cross-domain-policy>

se avessi avuto una linea del genere, allora qualsiasi sito sarebbe stato in grado di mandare richieste contro il sito originale.

<allow-access-from doomain="*" secure="false"/>

Test file permission (WSTG-CONFIG-009)

Da un punto di vista blackbox non c’è molto altro da fare per testare il server, a meno che non riuscissimo ad entrare nel server web per poi ottenere maggiori informazioni sulle proprietà dei files.

I files e i programmi configurati in modo insicuro possono essere utilizzati per ottenere privilegi più alti all’interno del sistema compromesso.