I server web sono da sempre uno dei principali veicoli di intrusione.
È sufficiente rilevare la versione del server, trovare un exploit adatto
ed eseguirlo, magari con il solo aiuto del browser che utilizziamo normalmente
per navigare. Non si tratta di una semplificazione eccessiva: se non
prestiamo attenzione alla sicurezza del nostro server web, bastano davvero
questi pochi passaggi per consegnarlo nelle mani di un hacker!
La diffusione dei servizi web integrati nei sistemi operativi più
comuni, come Windows 2000/XP e Linux, è di grande utilità
per gli sviluppatori che testano i propri siti in locale, ma al tempo
stesso è una manna per i malintenzionati.
Se avete subìto un attacco e volete capire come
rimediare, o se volete semplicemente saperne di più su come si
conduce una indagine su un server web, questo articolo
fa per voi. Vedremo come si rileva un attacco in corso, quali indizi
cercare e quali contromisure adottare per mettere in sicurezza il sistema
colpito.
Tipologie di attacco
Non tutti i tentativi di intrusione sono uguali. I motivi che spingono
l'aggressore a penetrare nel nostro server web possono trovare posto in
varie categorie:
- Defacement: si tratta della tipologia più
diffusa e protagonista delle cronache, consiste nel modificare la
home page di un sito o sostituirla con un messaggio di protesta, solitamente
l'azione è firmata dal gruppo che l'ha effettuata. - Attacco alla rete: è l'attacco classico,
dove l'hacker utilizza il server compromesso per arrivare alla rete
interna e intrufolarsi in più sistemi possibili. - Informazioni: esiste una tipologia di attacco più
rara ma molto pericolosa, perché mira a ottenere informazioni
riservate che risiedono sul server (ad esempio i database utilizzati
dalle applicazioni web) - Base appoggio: nella maggior parte dei casi gli
hacker colpiscono sistemi aziendali o istituzionali, ma anche i computer
privati possono essere sfruttati come base di appoggio per lanciare
attacchi DoS, per mascherare l'indirizzo IP dell'hacker o come archivio
per diffondere programmi pirata.
In base a queste considerazioni dovremo adottare la risposta più
efficace al tipo di attacco rilevato. Per farlo, è indispensabile
raccogliere tutti gli indizi che ci possono aiutare a farci un quadro
della situazione: le tracce lasciate dall'intruso, i file di log delle
applicazioni coinvolte e dei dispositivi di sicurezza, se presenti.
Come un medico che durante l'anamnesi raccoglie dal paziente i dati
sull'insorgere di una malattia, anche noi dovremo imparare a prestare
attenzione ai sintomi tipici di un server web sottoposto
a un attacco, per prescrivere la "cura" migliore. Quali sono
questi sintomi?
In presenza di un firewall con Intrusion Detection System,
la fase di rilevazione è molto semplificata: l'IDS è un
vigile osservatore che ci riferisce tutti i comportamenti scorretti
che è in grado di riconoscere. I sistemi domestici però
sono raramente dotati di protezioni raffinate, quindi dovremo cavarcela
da soli. Ecco una lista di validi indici di pericolo:
- Instabilità del sistema: molte tecniche
di hacking, in particolare se sfruttano gli exploit basati sul Tecniche: Buffer Overflow, possono comportare evidenti problemi di stabilità
delle applicazioni e del sistema operativo. Controlliamo, ove possibile,
i registri degli eventi del sistema (in Windows 2000/XP li troviamo
sotto Strumenti di amministrazione). - Traffico e risorse: l'aumento improvviso del traffico
di rete rispetto alla media è da considerarsi sospetto, così
come l'utilizzo spropositato delle risorse del sistema, rilevabili
tramite il Task Manager. - Dimensioni LOG: nei file di log del server web
sono salvate tutte le richieste effettuate dai client degli utenti,
con diversi gradi di dettaglio a seconda della configurazione. Quando
un aggressore utilizza tools automatizzati per la ricerca delle falle,
come Retina,
le dimensioni dei file di log aumentano inevitabilmente, fino a raddoppiare
o a triplicare rispetto alla norma.
La lettura periodica dei log è il metodo più sicuro per
rilevare tempestivamente gli attacchi al server web. Quando siamo sicuri
di essere stati attaccati, se il server è già stato compromesso
e vogliamo conservare le prove per eventuali azioni legali, dotiamoci
di programmi per la duplicazione forense come SafeBack
o l'utility dd
per sistemi Unix.
Leggere i log
A seconda del server che utilizziamo i dati contenuti nei log saranno
organizzati secondo una forma differente, ma generalmente le informazioni
archiviate sono le stesse. Per vedere i log di IIS, salvati con il formato
exAAMMGG.log, andiamo nella cartella C:WINDOWSSystem32LogFilesW3SVC1.
La directory di default per Apache invece è /usr/local/apache/logs.
Proviamo a collegarci alla home page del nostro sito, quindi apriamo il
file di log di IIS relativo al giorno corrente. La riga relativa alla nostra
richiesta si presenterà così:
06:59:25 192.168.1.3 GET
/index.htm 200
In ordine troviamo: l'ora, l'indirizzo IP del client, il metodo utilizzato
(get, post, head ecc), la risorsa richiesta (in questo caso la pagina
index.htm) e il codice di stato.
I codici di stato HTTP sono molto importanti per interpretare le singole
richieste. In questo caso il codice è il 200 e
indica il successo dell'operazione. Gli altri
codici che incontreremo più spesso sono il 403
(accesso alla risorsa proibito), 404 (risorsa non presente
sul server) e 500 (errore interno del server).
Le informazioni registrate nei file di log ci saranno molto utili per
scoprire se siamo stati attaccati. Controllando data e ora
di ogni richiesta, ad esempio, possiamo stabilire se c'è stata
una scansione automatizzata: in questo caso riscontreremo moltissime
richieste condensate in poche manciate di secondi.
Anche i codici di stato offrono, all'occhio allenato, diverse indicazioni.
L'intensa attività legata ai codici 403, 404 e 500 rivela con
certezza la presenza di una scansione eseguita dall'hacker per raccogliere
informazioni sul server. Iniziamo a preoccuparci se le richieste corrispondenti
a exploit conosciuti sono marcate con codici 200 o
500: è probabile che il sistema non sia protetto contro la tecnica
utilizzata.
Facciamo anche attenzione a tutte le richieste che sembrano sospette:
chiamate a eseguibili (.exe, .com, .vbs), presenza
di cartelle di sistema o simili nell'URI (scripts, windows,
system32, cgi-bin), presenza massiccia di caratteri strani,
punti, slash, percentuali. Se non riconosciamo la stringa richiesta,
proviamo a utilizzare un motore di ricerca come google: sicuramente
troveremo tutte le informazioni necessarie sull'exploit e sulle patch
da installare.
Scena del crimine
Proviamo ora a mettere in pratica le nozioni viste finora, investigando
su un caso reale. Lo scenario è il seguente: appena arrivati
in ufficio, notate uno strano aumento del traffico notturno verso il server web
IIS. Vi collegate alla pagina principale e i vostri
sospetti prendono forma: la home page è stata sostituita con
un messaggio di un gruppo di hackers sudamericani, si tratta di un defacement
in piena regola.
Per salvaguardare l'immagine dell'azienda la priorità, in questo
caso, è ripristinare il sito da una copia di backup. Dopo averlo
fatto, dobbiamo assicurarci di scoprire le modalità con cui si
è svolta l'azione di hacking e tappare le falle sfruttate. A
tal proposito controlliamo attentamente il file di log del server: ex040716.log.
Dopo aver analizzato il log, alla luce delle informazioni contenute,
provate a fare delle ipotesi e confrontatele con la
soluzione fornita di seguito.
Ecco come si sono svolti i fatti, seguendo l'ordine cronologico del
log:
4:49:06 / 4:49:23 - Dalla quantità
di richieste eseguite in soli 17 secondi, possiamo riconoscere l'azione
di un security scanner. L'hacker sta sondando il terreno per trovare
un punto vulnerabile. I codici 404 sono rassicuranti, ma le due richieste
marcate con codice 500 destano preoccupazione: riguardano l'exploit
IIS Unicode, utilizzato anche dal worm Nimda, che permette
di eseguire comandi sul server e ricevere i risultati a schermo.
5:15:00 / 5:16:09 - Da questo punto in poi
notiamo che le richieste si concentrano tutte sull'exploit Unicode e
che passano alcuni minuti fra una richiesta e l'altra. Questo significa
che l'hacker sta operando manualmente, probabilmente
con l'aiuto del browser. I comandi inviati servono per ottenere un listato
della directory principale del server web.
5:18:02 / 5:20:17 - I due comandi eseguiti
in questo lasso di tempo sono il fulcro del defacement: prima l'hacker
fa una copia della home page "index.asp", poi lancia il programma
TFTP sul server e lo fa collegare al proprio computer
per poter trasferire la pagina sostitutiva "index.htm".
5:22:00 / 5:23:05 - È il momento di coprire
le tracce. Con il primo comando l'intruso visualizza il contenuto del
file di log di IIS, con il secondo tenta di eliminarlo.
Qualcosa però va storto: essendo in uso il file non può
essere eliminato. Questo intoppo ci ha permesso di capire come è
andata l'intrusione.
Ora che ci siamo accertati che l'intruso non ha installato programmi
nascosti sul server e abbiamo trovato la falla da chiudere, anche se
in un caso ipotetico, possiamo renderci conto dell'importanza di salvaguardare
l'integrità dei file di log.
Se un hacker ottiene l'accesso completo al sistema, cercherà
di eliminare con cura tutte le tracce che rivelano la sua intrusione.
Per evitarlo, predisponiamo i nostri sistemi per il logging remoto:
i file di log, normalmente salvati sul server locale, devono essere
inviati a un computer remoto, di modo che nessuno possa alterarli o
distruggerli. Sui sistemi Unix possiamo utilizzare le funzionalità
di Syslog. Per Windows esistono delle utility reperibili
separatamente dal sistema operativo, come NTSyslog.
