Al termine di tutte queste considerazioni, ho scritto un file (tesi.rules) che contenesse le regole precedentemente elaborate ed ho eseguito alcuni test sui tipi di attacchi previsti dai laboratori di Google-gruyere. Riprendo nell’ordine i diversi esercizi e controllo i segnali di allarme generati da queste regole. Ho provato ad utilizzare normalmente le pagine di Gruyere con le tipiche azioni consentite (registrazione di un utente, upload di un file, inserimento o cancellazione di uno snippet, aggiornamento del profilo...) e non ho ricevuto messaggi di allarme dall’IDS, tranne un segnale di allarme dalla regola 11 quando ho inserito in uno snippet un link ad un’immagine (come era stato previsto nella fase di analisi delle regole).
5.2.1
XSS
Ripercorro qui gli attacchi di tipo XSS studiati, per analizzare il comporta- mento del server Snort in questi contesti.
XSS Reflected
Provo il classico esempio di script inserito direttamente nell’url di una pagina, digitando l’indirizzo:
http://192.168.2.50:8008/12345678/<script>alert(1);</script> L’attacco ha successo e il server Snort genera segnali di allarme di questo genere:
06/03-08:13:43.799777 [**] [1:1:0] WEB XSS reflected con <script nell’url [**] [Priority: 0] {TCP}
192.168.1.101:34120 -> 192.168.2.50:8008 L’attacco cio`e viene rilevato dalla regola 1. Anche per un input come:
http://server_web:8008/12345678/
feed.gtl?uid=<script>alert(1)</script> si ottiene un analogo messaggio di errore.
XSS Stored
I primi test riguardano l’upload di file con stringhe potenzialmente pericolo- se. Ho provato ad inserire nei file da caricare sul server svariati contenuti:
<script> alert(document.cookie); </script>
Viene rilevato sia dalla regola 5 che dalla regola 20, con avvisi come questi: 06/03-08:30:46.790000 [**] [1:20:0] WEB XSS tramite
<script in un campo POST [**] [Priority: 0] {TCP} 192.168.1.101:34132 -> 192.168.2.50:8008
06/03-08:30:46.790000 [**] [1:5:0] WEB upload di un file contenente un tag <script [**] [Priority: 0] {TCP} 192.168.1.101:34132 -> 192.168.2.50:8008
L’attacco ha successo. Viene rilevato da entrambe le regole perch`e il file viene caricato tramite un form che usa il metodo POST. Potrebbe essere quindi sufficiente utilizzare la seconda regola (pi`u generale).
Ho provato anche con qualche altro input (cercando di testare soprattutto gli effetti di file contenenti caratteri codificati). Se nel file ho il contenuto:
%3cscript%3e alert(1); %3c/script%3e
l’azione di upload viene rilevata da Snort come un tentativo di attacco. E’ un attacco che non ha successo. Se il file caricato viene richiamato si ottiene la stampa della stringa inserita, ma non viene eseguito alcuno script. Ha invece successo l’attacco portato con l’upload di un file che contiene la seguente stringa:
<a href="%3cscript%3e alert(1); %3c/script%3e"> Guarda qui! </a> e viene rilevato dalla regola 5, che dalla regola 9 e dalla regola 20, con messaggi di questo tipo:
06/03-08:49:51.707107 [**] [1:20:0] WEB XSS tramite <script in un campo POST [**] [Priority: 0] {TCP} 192.168.1.101:34142 -> 192.168.2.50:8008
06/03-08:49:51.707107 [**] [1:9:0] WEB upload di un file contenente caratteri codificati [**] [Priority: 0] {TCP} 192.168.1.101:34142 -> 192.168.2.50:8008
06/03-08:49:51.707107 [**] [1:5:0] WEB upload di un file contenente un tag <script [**] [Priority: 0] {TCP} 192.168.1.101:34142 -> 192.168.2.50:8008
Un simile risultato si ottiene inserendo un file con questo contenuto:
<a href="<script> alert(1); </script>"> Guarda qui! </a> questo input viene rilevato dalla regola 5 (file contenente un tag <script) e dalla regola 20 (tag <script presente nel campo di un form POST).
Se provo a fare l’upload di un file con il seguente contenuto:
<a href="../%3Cscript%3Ealert(1);%3C/script%3E">Guarda qui!</a> Viene rilevato dalla regola 5 (perch´e contiene il tag <script), ma anche dalla regola 9 (contiene caratteri codificati) e anche dalle regole 30 (tentativo di directory traversal), 31 (tentativo di path traversal in un file caricato) e 32 (tentativo di path traversal nel campo di un form POST).
Ottengo quindi i messaggi:
06/03-10:05:06.081140 [**] [1:30:0] WEB Tentativo di directory traversal [**] [Priority: 0] {TCP}
06/03-10:05:06.081140 [**] [1:20:0] WEB XSS tramite <script in un campo POST [**] [Priority: 0] {TCP} 192.168.1.101:34142 -> 192.168.2.50:8008
06/03-10:05:06.081140 [**] [1:32:0] WEB Tentativo di
directory traversal in un form POST [**] [Priority: 0] {TCP} 06/03-10:05:06.081140 [**] [1:31:0] WEB Tentativo di
path traversal in un file caricato [**] [Priority: 0] {TCP} 06/03-10:05:06.081140 [**] [1:9:0] WEB upload di un
file contenente caratteri codificati [**] [Priority: 0] {TCP} 192.168.1.101:34142 -> 192.168.2.50:8008
06/03-10:05:06.081140 [**] [1:5:0] WEB upload di un file contenente un tag <script [**] [Priority: 0] {TCP} 192.168.1.101:34142 -> 192.168.2.50:8008
Da qui posso osservare che la regola 30 (per il path traversal generico), include anche le 31 e la 32.
Si pu`o anche caricare un file dal seguente contenuto: <a href="../%3C%53%43%52%49%50%54%3E%61%6C%65%72% 74%28%27%43%49%41%4F%21%21%21%27%29
%3C%2F%53%43%52%49%50%54%3E>">Guarda!</a>
ottenuto con il software in [5], dove la sequenza di caratteri codificati riporta la stringa:
<SCRIPT>alert(’CIAO!!!’)</SCRIPT>
Anche in questo caso viene rilevato dalle regole 5, 20, 30, 31, 32. Un altro test `e fatto con il file che contiene:
<img src="panorama.jpg" onerror="alert(1);"/> Guarda qui!
L’attacco ha successo nel momento in cui il file caricato viene richiamato e l’immagine a cui si fa riferimento non esiste.
L’ulpoad del file viene rilevato dalla regola numero 10 (trova l’attributo che supporta codice javascript in un file caricato) e dalla regola 22 (che trova l’attributo javascript tra i valori inviati da un form che usa il metodo POST).
Ho creato un file che contiene questa stringa: <object data="data:text/html;base64,
Si tratta della versione codificata in base64 della stringa: <script>alert(1);</script>
L’attacco ha successo e viene rilevato dalla regola 21 (presenza di parte codifi- cata in base64 in un campo POST) e dalla regola 6 (upload di file contenente url con dati base64).
Provo ora con attacchi inseriti in uno snippet di Gruyere. In generale gli snippet vengono controllati dal server e vengono tolti eventuali tag pericolosi o non ammessi, quale pu`o essere ad esempio il tag <script. Ci sono per`o diversi modi per aggirare questo controllo.
Il primo esempio si ha inserendo questo testo nello snippet: <a href="%3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28 %31%29%3B%3C%2F%73%63%72%69%70%74%3E"> guarda!</a> La parte codificata esprime la stringa:
<script>alert(1);</script>
Quando qualcuno richiama il link riportato nello snippet, l’attacco ha effetto. Questo inserimento di codice viene rilevato dalla regola 1 (il tag <script nel- l’uri), poich´e il form dal quale si pu`o inserire un frammento di codice invia i dati al server con il metodo GET e quindi i dati passano attraverso l’url. L’opzione uricontent lavora sull’uri decodificato e quindi il tag viene rilevato. D`a un messaggio di allarme anche la regola 11, che intercetta l’uso degli apici doppi.
Inoltre se provo ad inserire un frammento di codice di questo tipo: <img src="panorama.jpg" onerror="alert(1);" />
che richiama un file immagine che non esiste. L’attacco ha effetto non appe- na viene mostrata la lista degli snippet.
L’inserimento dei dati viene rilevato dalla regola 2 (che trova un attributo tramite il quale pu`o essere inserito un codice javascript nell’url) e dalla regola 11 (che rileva l’uso degli apici doppi).
Ha effetto anche un attacco che avviene tramite l’inserimento di un fram- mento di codice come questo:
<a href="data:text/html;base64,
L’attacco ha successo non appena si clicca sul link che compare nello snip- pet. Lo script javascript `e codificato in base64 e viene rilevato dalla regola 3, (inserimento di codifiche base64) e dalla regola 11 (uso degli apici).
Un tentativo di inserire codice javascript nella pagina di aggiornamento del profilo utente, consiste nel dare al testo del campo che determina il colore per il profilo il seguente valore:
yellow’ onerror=’alert(1);
Questo tentativo di attacco non ha effetto se non si genera un errore.
Serve per`o per dimostrare che un tentativo di attacco di questo tipo (XSS stored) viene rilevato dalla regola 2 (inserimento di un attributo javascript, presente nell’url) e dalla regola 12 (uso degli apici singoli).
5.2.2
Test sul path traversal
Provo in primo luogo a creare un utente con login “..”, per cercare poi di inserire un file in una posizione non convenzionale (tra i file dell’applicazione Gruyere).
Questo attacco viene rilevato dalla regola 30.
Provo poi a creare un utente con la login “brie/../..” e anche questo tentativo di attacco viene rilevato dalla regola 30.
Anche l’inserimento di un file che abbia la sequenza “../” nel nome viene rilevato.