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à con un semplice click tutto in uno.

Il programma proverà a simulare attacchi come per es. SQL Injection e di raccogliere informazioni sulle possibili vulnerabilità.

Per prima cosa configurare Acunetix per effettuare l’analisi tramite un Proxy Server. Consiglio di usare sempre dei proxy quando si usano questi “tools”, anche se si sta testando il proprio Server o se 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 il proprio Proxy.

Acunetix Web Vulnerability Scanner

Una volta fatto avviare lo scanner premendo su New scann. Apparirà una finestra in cui inserire l’host da analizzare. Inserire l’host e premere su next.

Acunetix Web Vulnerability Scanner

Poi appare la finestra options in cui si possono scegliere alcune opzioni, in questo esempio si lascia Default. Poi premere su Next.

Acunetix Web Vulnerability Scanner

Dopo la parte Options appare la finestra di configurazione nominata Target in cui scegliere le varie tecnologie da testare, in questo esempio si sceglie PHP, mod_ssl e OpenSSL. Se non si conosce niente sul Server selezionarle tutte.

Acunetix Web Vulnerability Scanner

Una volta scelto premere su next. La prossima schermata, Login, serve nel caso si volessero testare zone protette da password durante lo “scann”. In questo esempio non vi sono cartelle protette da analizzare e quindi lasciare com’è ( no login sequence ) e premere su avanti.

Acunetix Web Vulnerability Scanner

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 premere su finish.

Acunetix Web Vulnerability Scanner

Una volta premuto 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.

Acunetix Web Vulnerability Scanner

Come si può vedere dal risultato, il tool ha rivelato 6 “allerts” di cui 3 di livello medio. In questo esempio non vi sono rischi gravi per la sicurezza, come si può vedere in alto a destra il livello di “allerta” è “LEVEL 2”. Vi 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 supporta il metodo HTTP TRACE, che potrebbe esporre il proprio server ad alcuni tipi di attacchi, tra cui i “Cross-Site Scripting attacks“.

Ecco un ottima descrizione tratta da “Hacking Web – Sicurezza nel groviglio della Rete“: “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.”

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 TRACE in Apache2 editare il file di configurazione del Web Server, in SUSE, /etc/apache2/httpd.conf. Se non si ha accesso al file di configurazione del Server, usare .htaccess.
Alla fine del file aggiungere la seguente riga:

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 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à trovate “scannando” altri hosts.

Blind SQL Injection

Acunetix Web Vulnerability Scanner
In questo caso lo scanner ha rilevato una vulnerabilità ad attacchi tramite SQL INJECTION. Per risolvere il problema si potrebbero usere delle regole rewrite o impedire l’aggiungere di segni particolari nei formulari controllando meglio l’input da inserire (sanitize the data) che è la soluzione migliore.

Ecco un esempio con delle regole rewrite che prevengono diversi attacchi 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

Acunetix Web Vulnerability Scanner
In questo caso acunetix ha rilevato possibili rischi dovuti al fatto che la “PHPSESSID non è secure”.

Aggiungere la seguente riga nel file di configurazione di Apache (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’altra analisi per assicurarsi che tutte le modifiche apportate abbiano avuto l’effetto desiderato. Non sono andato di proposito troppo nel dettaglio per quanto riguarda il descrivere le varie lacune alla sicurezza e relative soluzioni al problema, per non deviare troppo dal tema principale di questo tutorial e per il fatto che comunque, ognuno avrà risultati diversi.