Guida in italiano sul come testare la sicurezza del proprio server e delle proprie applicazioni con Acunetix Web Vulnerability Scanner.
Acunetix è un tool per Win usato per testare la sicurezza. Con questo programma è possibile testare le varie vulnerabilità. Il programma esegue degli attacchi per testare la sicurezza per poi creare una lista di vulnerabilità.
Per prima cosa configurare Acunetix per effettuare l’analisi tramite un Proxy Server. Consiglio di usare sempre dei proxy quando si effettuano dei penetration test, anche se si sta testando il proprio sito o server e non si hanno cattive intenzioni. Per le impostazioni proxy di Acunetix andare in configuration, scann settings e in fine lan settings. Apparirà la finestra in cui inserire un indirizzo Proxy.
Una volta fatto avviare Acunetix Web Vulnerability Scanner cliccando su New Scan. Apparirà una finestra in cui inserire la URL del sito o blog da analizzare. Inserire l’host e cliccare su next.
Poi appare la finestra options in cui si possono scegliere alcune opzioni, in questo esempio si lascia Default. Poi premere su Next.
Dopo la parte Options appare la finestra di configurazione nominata Target in cui scegliere le varie tecnologie da testare, in questo esempio scelgo PHP, mod_ssl e OpenSSL. Se non si conosce niente sul Server selezionarle tutte. Una volta scelto cliccare su next.
La prossima schermata, Login, serve nel caso si volessero testare cartelle protette da password. In questo esempio non ci sono cartelle protette da analizzare e quindi lascio com’è ( no login sequence ) e clicco su next.
Nella prossima e ultima finestra, FINISH, viene chiesto se si vuole fare uso di AcuSensor e se si desidera includere pagine simili. Lasciare tutto com’è e cliccare su finish.
Una volta cliccato su finish il programma inizierà a scannare il Web Server in cerca di vulnerabilità. La scansione potrebbe durare diversi minuti.
Finito il processo di scansione i risultati riguardo ai diversi rischi per la sicurezza rilevati, vengono mostrati dal programma.
Come si può vedere dal risultato, Acunetix Web Vulnerability Scanner ha rivelato 6 “allerts” di cui 3 di livello medio. In questo esempio non ci sono rischi gravi per la sicurezza visto che come si può vedere in alto a destra il livello di “allerta” è “LEVEL 2”. Ci sono tre livelli, low, medium e high rispettivamente 1, 2 e 3.
L’alert di importanza media, HTML form without CSRF protection, si riferisce al fatto che i form ( formulari in cui inserire informazioni ) potrebbero essere vulnerabili ad attacchi di tipo “cross-site request forgery“.
Per rimediare alla falla nella sicurezza scoperta installare un qualche plugin – nel mio caso si tratta di WordPress – come per es Anti CSRF o apportare le modifiche manualmente.
Uno degli “alerts” di minore importanza è “Trace method enabled“. Per default Apache2 Web Server supporta il metodo HTTP TRACE cosa che potrebbe esporre il proprio server ad alcuni tipi di attacchi come per esempio gli “Cross-Site Scripting attacks“.
“TRACE è una sorta di richiesta ping che restituisce informazioni su tutti i proxy attraversati nell’elaborazione di una richiesta. Riporta anche l’eco della richiesta originale. I browser non fanno richieste TRACE. Tali richieste vengono utilizzate molto di rado per scopi legittimi, il primo dei quali è la verifica della sicurezza: possono rivelare interessanti dettagli sull’architettura interna dei server HTTP di una rete remota. Proprio per questa ragione viene quasi sempre disabilitato dagli amministratori dei server.” – Hacking Web: Sicurezza nel groviglio della Rete
Testare metodo HTTP TRACE con curl
Per testare se il metodo HTTP TRACE sia attivo con Linux si potrebbe eseguire il seguente comando:
:~> curl -i -X TRACE https://christeninformatica.ch HTTP/1.1 200 OK Date: Thu, 05 Dec 2013 23:44:58 GMT Server: Apache Transfer-Encoding: chunked Content-Type: message/http TRACE / HTTP/1.1 User-Agent: curl/7.32.0 Host: christeninformatica.ch Accept: */* :~>
Come si può notare osservando l’output del comando appena eseguito, il Server supporta il metodo “HTTP TRACE“.
Ora vediamo come disabilitarlo. Per disabilitare il supporto per il metodo TRACE in Apache2 Web Server editare il file di configurazione httpd.conf e aggiungere la seguente riga alla fine:
TraceEnable off
Una volta apportate le modifiche rinviare il server:
rcapache2 restart
A questo punto per controllare se il server è stato configurato correttamente eseguire nuovamente il comando di prima.
:~>curl -i -X TRACE https://christeninformatica.ch
HTTP/1.1 405 Method Not Allowed
Date: Thu, 05 Dec 2013 23:52:19 GMT
Server: Apache
Vary: accept-language,accept-charset
Accept-Ranges: bytes
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
Content-Language: en
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<title>Method not allowed!</title>
<link rev="made" href="mailto:%5bno%20address%20given%5d" />
<style type="text/css"><!--/*--><![CDATA[/*><!--*/
body { color: #000000; background-color: #FFFFFF; }
a:link { color: #0000CC; }
p, address {margin-left: 3em;}
span {font-size: smaller;}
/*]]>*/--></style>
</head>
<body>
<h1>Method not allowed!</h1>
<p>
The TRACE
method is not allowed for the requested URL.
</p>
<p>
If you think this is a server error, please contact the <a href="mailto:%5bno%20address%20given%5d">webmaster</a>.
</p>
<h2>Error 405</h2>
<address>
<a href="/">christeninformatica.ch</a><br />
<span>Fri Dec 6 00:52:19 2013<br />
Apache</span>
</address>
</body>
</html>
Come si può notare dall’output del comando il metodo TRACE non viene più supportato dal server ( 405 Method Not Allowed ).
Testare metodo HTTP TRACE con telnet
Se si usa Windows si potrebbe usare telnet per verificare se il metodo HTTP TRACE venga supportato oppure no.
Con il seguente comando aprire una connessione sulla porta 80 con telnet e una volta connessi digitare: TRACE / HTTP1.1
C:\Users\chit>telnet christeninformatica.ch 80 Digitare "TRACE / HTTP1.1" e poi premere due volte su enter per confermare HTTP/1.1 200 OK Date: Sat, 07 Dec 2013 00:17:41 GMT Server: Apache Connection: close Content-Type: message/http TRACE / HTTP1.1 Verbindung zu Host verloren. C:\Users\chit>
Ed ecco la risposta nel caso il metodo HTTP TRACE non venga supportato:
C:\Users\chit>telnet christeninformatica.ch 80
TRACE / HTTP1.1
HTTP/1.1 405 Method Not Allowed
Date: Sat, 07 Dec 2013 00:01:38 GMT
Server: Apache
Vary: accept-language,accept-charset
Accept-Ranges: bytes
Connection: close
Content-Type: text/html; charset=iso-8859-1
Content-Language: en
Expires: Sat, 07 Dec 2013 00:01:38 GMT
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<title>Method not allowed!</title>
<link rev="made" href="mailto:%5bno%20address%20given%5d" />
<style type="text/css"><!--/*--><![CDATA[/*><!--*/
body { color: #000000; background-color: #FFFFFF;}
a:link { color: #0000CC; }
p, address {margin-left: 3em;}
span {font-size: smaller;/*]]>*/--></style>
</head>
<body>
<h1>Method not allowed!</h1>
<p>
The TRACE method is not allowed for the requested URL.
</p>
<p>
If you think this is a server error, please contact the <a href="mailto:%5bno%20address%20given%5d">webmaster</a>.
</p>
<h2>Error 405</h2>
<address>
<a href="/">christeninformatica.ch</a><br />
<span>Sat Dec 7 01:01:38 2013<br />
Apache</span>
</address>
</body>
</html>
Alcuni esempi
Quelli che seguono sono esempi di possibili vulnerabilità trovati con Acunetix Web Vulnerability Scanner.
Blind SQL Injection
In questo caso lo scanner ha rilevato una vulnerabilità ad attacchi di tipo Blind SQL Injection. Per risolvere il problema si potrebbero usere delle regole rewrite. Ancora meglio sarebbe scrivere un applicazione che impedisce l’aggiungere di segni particolari nei formulari controllando meglio l’input da inserire ( sanitize the data ) che è la soluzione migliore.
Ecco un esempio di regole rewrite che impediscono alcuni attacchi di tipo SQL Injection per WordPress:
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC]
RewriteCond %{QUERY_STRING} \.\.\/ [NC,OR]
RewriteCond %{QUERY_STRING} ^.*\.(bash|git|hg|log|svn|swp|cvs) [NC,OR]
RewriteCond %{QUERY_STRING} etc/passwd [NC,OR]
RewriteCond %{QUERY_STRING} boot\.ini [NC,OR]
RewriteCond %{QUERY_STRING} ftp\: [NC,OR]
RewriteCond %{QUERY_STRING} http\: [NC,OR]
RewriteCond %{QUERY_STRING} https\: [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|%3D) [NC,OR]
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)|<|>|ê|"|;|\?|\*|=$).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*("|'|<|>|\|{||).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%24&x).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%0|%A|%B|%C|%D|%E|%F|127\.0).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(globals|encode|localhost|loopback).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(request|select|concat|insert|union|declare).* [NC]
RewriteCond %{QUERY_STRING} !^loggedout=true
RewriteCond %{QUERY_STRING} !^action=rp
RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in_.*$
RewriteCond %{HTTP_REFERER} !^http://maps\.googleapis\.com(.*)$
RewriteRule ^(.*)$ - [F,L]
PHPSESSID secure and httponly
In questo caso Acunetix ha rilevato possibili rischi dovuti al fatto che la “PHPSESSID non è secure”. Per risolver questo problema aggiungere la seguente riga nel file di configurazione di Apache Web Server (httpd.conf):
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
Colmare se possibile tutte le lacune della sicurezza trovate. Chiaramente in altre situazioni si troverebbero altri problemi da risolvere quindi consiglio di fare ricerche sulle vulnerabilità trovate come anche le possibili soluzioni e di apportare in fine le modifiche necessarie.
Una volta finito fare un altro penetration test per assicurarsi che tutte le modifiche apportate abbiano avuto l’effetto desiderato.