Un computer in rete può erogare servizi per gli utenti, come Web, Mail, FTP, gestire sessioni interattive con gli utenti, immagazzinare e smistare informazioni, facendo utilizzo anche di filesystem distribuiti e database. Inoltre, può erogare servizi per la rete come nameserver, mail transfer, proxy, etc…
L’accesso al sistema è consentito solo se si utilizzano gli opportuni protocolli di comunicazione e se si è autorizzati mediante richieste provenienti da macchine “conosciute” o mediante procedure di riconoscimento quali password, smartcard e certificati digitali.
In questo scenario, un sistema sicuro garantisce riservatezza e integrità dei dati, funzionalità e affidabilità del servizio e della macchina. Tuttavia, le password ed altri strumenti di riconoscimento possono essere scoperti o falsificati da malintenzionati e molti software per la gestione dei servizi di rete possono presentare comportamenti anomali (bug) che possono essere utilizzati per accedere illegalmente alla macchina. In particolare, un malintenzionato potrebbe utilizzare un servizio per ottenere accesso alla macchina, o persino il controllo, potrebbe bloccare il servizio o la macchina per impedirne l’utilizzo, potrebbe utilizzarlo illecitamente, fingendosi un utente autorizzato, o ancora, potrebbe accedere a dati riservati.
Di seguito è riportata una breve panoramica sui principali attacchi che ci interessano più da vicino.

Denial of Service (DoS)

Nonostante i firewall siano uno dei migliori metodi per proteggere una rete locale da attacchi provenienti da Internet, ed in generale da utenti esterni a tale LAN, esistono alcuni possibili attacchi che possono riuscire a mandare in crash il sistema rendendo così necessario un reboot delle macchine. Questi attacchi sono detti di tipo Denial of Service o brevemente DoS. Tale termine indica una vasta tipologia di attacchi che sfrutta alcune lacune del TCP/IP.
Nei primi mesi del 2000 si è spesso sentito parlare di sabotaggi effettuati contro alcuni dei principali siti Internet. Molti di questi, infatti, sono stati messi in ginocchio da quello che sembra essere stato il più massiccio attacco mai lanciato in rete.
Yahoo! è stato il primo a subirlo, avendo riportato un blackout di tre ore domenica 6 febbraio 2000.
Buy.Com non era raggiungibile la mattina del lunedì successivo, CNN ed eBay non lo erano nel pomeriggio dello stesso giorno, mentre Amazon e Zdnet sono rimasti isolati parecchie ore durante la notte del lunedì stesso.
Articoli tecnici hanno spiegato il fenomeno come un Distributed Denial of Services attack (DDoS): un genere di attacco nel quale i pirati (crackers) attivano un numero elevatissimo di false richieste da più macchine allo stesso server, consumando le risorse di sistema e di rete del fornitore del servizio. In questo modo, il provider “affoga” letteralmente sotto le richieste e non è più in grado di erogare i propri servizi, risultando quindi irraggiungibile. Alcuni dei network provider coinvolti hanno dichiarato di essere stati sommersi da oltre 1 Gb al secondo di traffico.
Anche se questo genere di attacco non è affatto nuovo sulla rete, non ne erano mai stati rilevati su così vasta scala e su così tanti obiettivi importanti quasi in contemporanea.
Spingendo all’eccesso l’idea dei DoS, il DDoS ripete lo stesso approccio utilizzando però diversi punti d’ingresso contemporanei: in questo modo un cracker è in grado di mettere in ginocchio sistemi più grandi, che sarebbero indifferenti ad un singolo flood. Per effettuare questo genere di operazione, si deve poter installare un proprio agente sui sistemi da cui si vuole scatenare l’attacco stesso.
È, quindi, una tecnica che viene premeditata, attrezzandosi con un pool di macchine compromesse, da poter scagliare contro il sistema vittima.
In realtà, questi attacchi sono resi possibili dall’attuale implementazione del protocollo TCP/IP. Per una scelta di realizzazione, infatti, non è stata posta particolare attenzione sull’identificazione del mittente di ogni pacchetto e se questo da una parte consente garanzie di anonimato, dall’altra può essere sfruttato con apposite tecniche per far credere che il pacchetto provenga da sistemi differenti da quello effettivo.

Scansione dei servizi di rete e Buffer overflow

Nelle reti TCP/IP i servizi (ed i corrispondenti server) sono associati ad un numero di porta.
L’associazione è stabilita dagli standard dei protocolli dei servizi, ad esempio, il server di posta elettronica è di norma associato alla porta numero 25.
Un client che si connette alla macchina server, indica il numero di porta del servizio a cui è interessato e dialoga con il server attraverso il protocollo stabilito.
Un client malintenzionato, però, può connettersi come un normale client e inviare particolari messaggi che potrebbero indurre il server a bloccarsi o a eseguire codice “pericoloso”.
Una delle tecniche più utilizzate per questo scopo è il cosiddetto Buffer overflow.
Il Buffer overflow è una tecnica usata per “iniettare” codice estraneo nella memoria del computer vittima, sfruttando bug noti nella gestione della memoria dati dei programmi, come ad esempio un mancato controllo sui limiti delle dimensioni dell’input. Per difendersi da questo tipo di attacco, bisognerebbe consultare periodicamente la documentazione del produttore del software, per avere segnalazione di nuovi bug, controllare periodicamente i file di log dei server per scoprire eventuali attività sospette, verificare periodicamente lo stato di efficienza dei servizi attivi e la robustezza delle macchine attraverso appositi software di probing, cioè effettuando attacchi con le tecniche più diffuse e documentate. Una diffusa tecnica di probing è il Port-Scanning.
Un port-scanner è un programma che simula connessioni ai servizi di rete, scandendo esaustivamente le porte per appurare quali servizi sono attivi, richiedendo a ciascun servizio informazioni di tipo diagnostico o di aiuto, per identificare il tipo di server e determinarne il grado di vulnerabilità.
Alcuni port-scanner effettuano solo un controllo esaustivo di tutti i numeri di porta, ma ve ne sono alcuni, più sofisticati in grado di gestire sessioni di probing anche periodiche, su singole macchine o su intere reti e sono anche estendibili e modulari.

Sniffing

Negli ambienti distribuiti le risorse sono dislocate in punti diversi di una rete. Spesso più macchine condividono delle risorse e i dati transitano ripetutamente attraverso la rete ed alcuni suoi nodi.
In uno scenario di questo tipo, un malintenzionato potrebbe accedere a dati riservati semplicemente mettendosi in ascolto sulla rete (sniffing).
Per difendersi da questo tipo di attacco esistono diversi tool e tecniche che possono aiutare a rilevare la presenza di uno sniffer nella rete, e inoltre si può rendere incomprensibile il risultato dello sniffing mediante la cifratura dei dati (utilizzando protocolli di comunicazioni basati su crittografia).

Man-In-The-Middle

La tipologia di attacco che va sotto il nome di Man-In-The-Middle consiste nel dirottare il traffico generato durante la comunicazione tra due host verso un terzo host (attaccante). Durante l’attacco, è necessario far credere ad entrambi gli end-point della comunicazione che l’host attaccante è in realtà il loro interlocutore legittimo.
L’attaccante, essendo in mezzo alla comunicazione delle due (o più) vittime, riceve tutto il traffico prodotto dai due host e si preoccupa di inoltrare correttamente il traffico verso l’effettiva destinazione dei pacchetti ricevuti, in modo che risulti trasparente ai due end-point della comunicazione. Chiaramente, prima di rispedire le informazioni verso la corretta destinazione, l’attaccante potrebbe comodamente consultarle, modificarle e farne ciò che vuole.

Cross Site Scripting (XSS)

La grande diffusione dei siti a contenuto dinamico che utilizzano linguaggi lato server (come ASP e PHP) ha favorito lo sviluppo di particolari tecniche di hacking, ideate per colpire gli utilizzatori delle applicazioni web. Una delle più conosciute è sicuramente il Cross Site Scripting (XSS), che permette ad un malintenzionato di inserire codice arbitrario come input di un’applicazione web, così da modificarne il comportamento per perseguire i propri fini illeciti. Se uno script consente questo tipo di attacco, è facile costruire un’URL ad hoc e inviarla all’utente che sarà vittima del sotterfugio. All’utente, ignaro di questa modifica, sembrerà di utilizzare il normale servizio offerto dal sito web vulnerabile. Pagine web o email sono i mezzi ideali per portare a termine l’attacco.
Consideriamo un esempio. Sappiamo che quando si utilizza un servizio che richiede l’inserimento di username e password, spesso questi dati vengono registrati sulla macchina dell’utente sottoforma di cookie. Per ovvi motivi di sicurezza, i dati contenuti nel cookie sono accessibili solo dal sito web che li ha creati, ma supponiamo che il sito in questione utilizzi un’applicazione vulnerabile al XSS: l’aggressore potrà iniettare un semplice JavaScript che legge il cookie dell’utente e lo riferisce. Il browser dell’utente permetterà la lettura, perchè in effetti il JavaScript viene eseguito da un sito autorizzato a leggere il cookie! Il risultato immediato è che l’aggressore avrà accesso al cookie e, a seconda delle informazioni contenute, sarà in grado, ad esempio, di leggere la posta dell’utente, oppure di utilizzare il suo nickname nel forum che frequenta, e così via.
Da notare, inoltre, che il Cross Site Scripting solitamente richiede un intervento attivo da parte della vittima per poter funzionare: anche il click su un link in una pagina web o in un messaggio di posta elettronica può nascondere insidie di questo tipo. E, ancora, ricordiamo che le connessioni cifrate tramite SSL non offrono una protezione adeguata per queste falle.
In generale, qualsiasi tipo di applicazione web può essere a rischio, se non implementa opportuni controlli sull’input degli utenti. Tuttavia, i bug riscontrati nelle applicazioni web solitamente vengono risolti in breve tempo e le patch sono integrate nelle versioni successive degli script. Molti dei bug relativi al Cross Site Scripting possono essere risolti implementando una procedura di validazione dell’input negli script, ma, in ogni caso, gli sviluppatori dovrebbero cercare di essere sensibili ai temi della sicurezza, anche se non indispensabili al fine dell’applicazione.

SQL injection

La creazione di contenuti dinamici che consentono all’utente di interagire con i siti sono spesso alla base del successo o dell’insuccesso dei servizi che vengono offerti tramite il web. Maggiore è l’importanza dei dati che bisogna gestire, maggiore è il bisogno di sicurezza che ruota attorno agli stessi. La sicurezza di un sito web non viene garantita soltanto da un web server ben configurato, o da un tunnel SSL, ma deve essere implementata in maniera coscienziosa, anche da chi sviluppa l’applicazione web. Una delle più classiche tipologie di attacco legate al web, molto diffusa ma spesso sottovalutata, va a colpire il cuore dell’applicazione web, ossia il database: si tratta dell’attacco di tipo SQL injection. E’ importante tenere presente che questo fenomeno può interessare qualsiasi linguaggio di programmazione e qualsiasi DBMS.
Il problema è relativamente semplice da capire, ma è anche molto pericoloso: effettuando una query SQL costruita sulla base di input passati da un utente, senza eseguire un controllo preventivo sullo stesso input, tale query può essere manipolata a piacimento. L’input dell’utente può essere trasmesso in vari modi: tramite URL (query string), tramite una form HTML oppure tramite un cookie costruito su misura.
I principali problemi che può portare una query manipolata arbitrariamente da un utente sono: manipolazione indesiderata dei dati sul server, accesso indesiderato ad aree riservate, visualizzazione di dati privati. Se poi l’attaccante agisce su Microsoft SQL Server, i pericoli sono ancora maggiori. Basti pensare a cosa potrebbe fare una volta acquisiti i permessi di amministratore.
Una particolare tipologia di SQL injection è il CRLF injection (detto anche Cookie Tampering), che in altre parole è una tecnica di SQL injection, dove il codice arbitrario è inserito nei cookie.
Ecco, quindi, il bisogno di implementare una serie di controlli preventivi allo scopo di arginare ogni possibile falla delle proprie applicazioni web. Le vulnerabilità possono essere numerose (dipende dalla fantasia dell’attaccante) e derivano solitamente da una distrazione del programmatore o comunque da una errata implementazione.
Non esiste una soluzione assoluta, che sia sicura e portabile allo stesso tempo. Lo stesso concetto di sicurezza è relativo e viene influenzato da numerosi parametri.
L’SQL injection prevede l’inserimento di istruzioni SQL nella query di interrogazione del database: una possibile difesa potrebbe essere quella di accettare solo input corretti.
In generale, comunque, eseguire controlli non significa sprecare tempo e risorse, ma rendere la propria applicazione molto più affidabile.

Parameter Tampering

Il Parameter Tampering (letteralmente Falsificazione dei Parametri) è una semplice tecnica di attacco informatico, spesso utilizzata a minare la logica delle applicazioni commerciali. Questo attacco trae vantaggio dal fatto che molti programmatori si affidano all’utilizzo di campi nascosti o prefissati (come un tag nascosto in una form o un parametro in una URL) come le uniche misure per rendere sicure determinate operazioni. Gli attaccanti, però, possono facilmente modificare questi parametri scavalcando il meccanismo di sicurezza su cui sono basati.
Il funzionamento è davvero molto semplice.
Sappiamo che il compito principale di un web server è quello di fornire file e, spesso, durante una sessione, per mantenere informazioni sul client evitando di gestire complessi database sul server, vengono scambiati diversi parametri tra browser e applicazione web. Questi scambi avvengono mediante URL, campi form e cookie.
Un classico esempio di Parameter Tampering si ha modificando i parametri nei campi form. Quando un utente effettua delle scelte in una pagina HTML, queste vengono di solito memorizzate come valori di campi form e inviate all’applicazione web sottoforma di richiesta HTTP. Questi valori possono essere preselezionabili (mediante combo box, check box, radio button, etc…), testo libero o nascosto, e possono essere facilmente manipolati da un attaccante: si salva la pagina, si modifica il codice HTML e si ricarica la pagina nel browser.
Uno stesso tipo di attacco può essere realizzato modificando i campi nascosti. Questi campi nascosti sono parametri invisibili all’utente finale, normalmente usati per fornire informazioni di stato all’applicazione web. Ad esempio, consideriamo una form per l’ordine di un prodotto, che include un campo nascosto relativo al prezzo. La modifica di questo campo forza l’applicazione web ad addebitare, per l’acquisto di quel prodotto, il nuovo prezzo introdotto dall’attaccante!
A questo punto, è facile immaginare la varietà di possibilità che si presentano in una normale sessione on line, per poter muovere questo attacco. Una ovvia difesa a riguardo sarebbe quella di adottare politiche di sicurezza più appropriate!