Non passa ormai giorno senza che vengano annunciati problemi di sicurezza in questo o quel programma o sito web. La maggior parte dei comunicati viene però presa sotto gamba, fino a quando non ci si scontra concretamente con i risultati del problema: computer infettati, furto di denaro dai conti correnti, violazione dei segreti industriali o della privacy dei singoli utenti.
D'altro canto però, molti dei bollettini sono spesso pensati per gli addetti ai lavori, e utilizzano quindi termini estremamente specifici e sconosciuti ai più.
Proprio per questo ho pensato di realizzare questo articolo, nel quale cerco di illustrare, in modo quanto più semplice possibile, cosa si intende con espressioni come buffer overflow, cross-site scripting e via dicendo.
La sicurezza dei sistemi informativi è comunque un argomento estremamente ampio e complesso: ognuno dei temi qui proposti richiederebbe un libro (o forse addirittura"collane di libri") per essere pienamente sviscerati! Il mio intento qui è solamente quello di realizzare una "carrellata" dell'argomento, per consentire al lettore di comprendere quantomeno il lessico impiegato nei bollettini di sicurezza.
Siete (troppo) pronti per questo articolo?
L'articolo è pensato per un target di utenti appassionati, che posseggano già buone competenze inerenti l'amministrazione del sistema e, magari, un'infarinatura dei basilari concetti di programmazione.
D'altro canto, se siete già "guru" della sicurezza, qui non troverete niente di nuovo. Anzi: vista l'intrinseca complessità dell'argomento, ho ritenuto opportuno utilizzare una serie di banalizzazioni, che, sebbene possano far storcere il naso a qualcuno, sono, a mio avviso, indispensabili per presentare la terminologia a chi, ancora, guru non è.
Cause, tipi d'attacco ed effetti
La prima cosa da fare è classificare una terminologia che troppo spesso viene usata (impropriamente) in modo intercambiabile.
Cause
Tutto quello che stiamo per trattare ha origine da un errore: errore dell'hardware, errore del software eseguito su di esso, oppure errore dell'utente.
Volendo semplificare al massimo, possiamo affermare che qualsiasi problema di sicurezza è causato dal verificarsi di una circostanza che uno dei progettisti del sistema informativo non aveva considerato.
Pensate ad esempio al caso in cui in un area adibita alla memorizzazione di una "data di nascita" vada a finire "un cognome": cosa succederà alla base di dati che dovrà memorizzare tale informazione? e come reagirà il programma al successivo caricamento di una stringa di testo in una zona studiata per contenere un dato nel formato gg/mm/aaaa?
Un errore di questo tipo viene chiamato "bug". Un bug può portare a situazioni impreviste, come quella appena citata, e quindi a un possibile problema di sicurezza.
Precisiamo però che non si tratta di una condizione necessaria e sufficiente: ad ogni problema di sicurezza è associabile un errore di fondo, ma non è detto che ogni bug possa portare ad una situazione idonea a sferrare un attacco.
Tipi d'attacco
Una volta rintracciato uno scenario non debitamente gestito, un cracker deve capire se può essere sfruttato, ai propri scopi e, se sì, in che modo.
Ecco quindi che parliamo di tipo di attacco, ovvero il modo mediante il quale il cracker che avesse individuato una "causa" può sfruttarla per generare un "effetto".
Vedetela in questo modo: la causa "avere lo stomaco vuoto" porta a desiderare l'effetto "non aver più la fastidiosa sensazione di fame". Il "tipo d'attacco", in questo caso, è "preparare il pranzo".
Effetti
Gli effetti di un attacco di sicurezza sono quelli che richiamano l'attenzione del grande pubblico: trasferimento di denaro dal conto corrente, caselle di posta intasate, PC rallentato, violazione della privacy, milioni di dollari di danni, e tutti gli altri scenari che, ciclicamente, arrivano anche sulle pagine della stampa generalista.
L'effetto è "il premio" che attende il cracker in grado di portare con successo un assalto alla sicurezza di un sistema informativo.
Entriamo nel vivo
Ultimata questa distinzione, passiamo ad analizzare la terminologia impiegata in ognuna le tre fasi.
Alla pagina precedente, abbiamo visto che una falla di sicurezza è sempre causata da uno scenario non opportunamente gestito che da adito ad un errore.
Vediamo i più comuni problemi che possono portare a situazioni di pericolo.
Insufficiente validazione dell'input / Insufficient Input Validation
Forse la causa più comune di problemi di sicurezza è l'utilizzo, da parte del programma, di dati immessi dall'utente senza prima averne verificato la correttezza sintattica (cioè "corretta nella forma") e/o semantica (cioè "corretta nel significato").
Pensate a questo scenario: il programma richiede all'utente di inserire il proprio nome, quindi lo stampa a video senza effettuare alcun controllo preventivo su quanto digitato. Cosa succede se viene inserita una stringa estremamente lunga, oppure una parola "riservata" utilizzata dal programma stesso?
Ancora: pensate ad un modulo che consenta al visitatore di spedire una e-mail al webmaster: cosa succede se nel campo designato a contenere il "corpo" del messaggio finiscono anche una serie di intestazioni proprie del protocollo SMTP?
E se una web application per la creazione di forum (quale phpBB) consentisse l'inserimento di codice Javascript nei messaggi inseriti dai visitatori?
In determinate circostanze, la mancata o insufficiente validazione dell'input può consentire ad un cracker di prendere pieno controllo di un sistema tramite l'esecuzione di codice da remoto (v. pagina successiva), se sfruttata a dovere.
Approfondimento: CWE-20: Insufficient Input Validation
Caso pratico: Problemi di sicurezza per PowerPoint
Use after free
La vulnerabilità use after free è un difetto di progettazione che porta il programma a leggere (più propriamente a "referenziare") un area di memoria RAM precedentemente indicata come "libera".
Poiché le celle di memoria libere vengono periodicamente "riciclate" per immagazzinare nuovi dati, è possibile che, nel lasso di tempo intercorso fra l'attribuzione dello stato di "libero" e il suo utilizzo, l'area informativa in questione sia stata sovrascritta da informazioni potenzialmente invalide.
Un cracker che avesse identificato una debolezza use after free, potrebbe essere in grado di causare il crash del programma difettoso o l'esecuzione di codice da remoto (parliamo in modo più diffuso di questi termini nella pagina dedicata ai tipi di attacco).
Approfondimento: CWE-416: Use After Free
Caso pratico: Internet Explorer è nuovamente in pericolo
Race condition
Non è mai una buona idea affidare alla temporizzazione il controllo dello svolgimento ("flusso") del programma.
Pensate ad esempio allo scenario in cui un applicazione sia costituita da un programma che legge dati (da un tastiera, ad esempio), quindi li memorizza in un area di memoria, dalla quale un secondo processo legge tali informazioni ogni secondo per archiviarle sulla memoria secondaria. Cosa succede se il primo processo è in ritardo, ad esempio perché il processore nel frattempo è stato impegnato da un terzo programma, ed il secondo non è stato progettato per gestire questa eventualità?
In vero, non è necessario che siano due differenti entità ad operare su dati condivisi perché si possa verificare una race condition: pensiamo al caso in cui il programma controlli, all'istante t0, che un certo file non sia in esecuzione, ed in caso affermativo, cancelli tale documento all'istante t1. Cosa succede se, nel lasso di tempo che intercorre fra t0 e t1, il file viene aperto? il programma, sicuro di aver già verificato, eseguirebbe la cancellazione, con conseguenze non-immediate da prevedere.
Un cracker che avesse individuato una race condition potrebbe sfruttare tale condizione per alterare lo svolgimento del programma. Sebbene sia teoricamente possibile sfruttare tale errore per acquisire il controllo del calcolatore, l'effetto più probabile è il crash del programma, o del sistema operativo.
Approfondimenti: CWE-362: Race Condition, CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition, CWE-366: Race Condition within a Thread
Vettore d'attacco / Attack vector
Un cracker può sfruttare strumenti di comunicazione quali posta elettronica, web, messaggistica istantanea o quant'altro per veicolare il proprio attacco, che viene recapitato alla vittima sottoforma di virus o altro malware.
Possiamo quindi asserire che qualsiasi strumento di comunicazione sia afflitto da problemi di sicurezza? Non propriamente, poiché tali tecnologie vengono utilizzate solamente per traghettare un attacco destinato ad altre componenti.
In questi casi, si dice che i mezzi impiegati per veicolare l'aggressione sono meri "vettori d'attacco".
Caso pratico: Netsky ancora diffusissimo
Approfondimento: SearchSecurity.com Definitions
Trasmissioni "in chiaro"
Molte informazioni scambiate tra due calcolatori non sono opportunamente crittografate: i dati vengono semplicemente confezionati così come richiede il protocollo di comunicazione e quindi inviati all'interlocutore.
Chiunque riuscisse ad intercettare la trasmissione potrebbe curiosare fra i dati in transito: poco male se si tratta di mere pagine web o informazioni pubblicamente accessibili, ma la cosa può essere fonte di grossi problemi se vengono inviate credenziali d'accesso o altri dati confidenziali.
In vero, è piuttosto improbabile che un cracker riesca ad intercettare i dati che scorrono fra due fornitori di connettività Internet (ISP). Il problema interessa però i due tratti terminali, quelli cioè fra i calcolatori ed il punto di accesso ad Internet.
Le reti wireless sono chiaramente quelle più soggette a tale rischio, ma nemmeno le connessioni cablate sono completamente al sicuro.
Protocolli crittografici inefficienti
Sebbene la crittografia possa migliorare le cose rispetto alle trasmissioni "in chiaro", tali tecniche possono risultare inefficaci. Vedetela in questo modo: utilizzare una serratura migliora la situazione rispetto ad accostare la porta di casa, ma è comunque possibile che venga scassinata.
Più che di scasso, forzare un algoritmo di crittografia significa duplicare la chiave, ovvero il metodo che consente di recuperare il messaggio originale.
Alcuni algoritmi in particolare, sono afflitti da debolezze che consentono di ricavare la chiave confrontando un numero opportuno di messaggi scambiati fra le parti: il WEP, adottato da molte infrastrutture di rete wireless, è uno degli esempi più eclatanti.
Approfondimento: Security of the WEP algorithm
Inappropriato dimensionamento del sistema
Cosa succede quando un sito web molto trafficato viene ospitato su un server dotato di un processore troppo lento o un quantitativo di memoria insufficiente? Il servizio può essere interrotto dal carico eccessivo.
Un cracker che individuasse una situazione del genere, potrebbe raggiungere tale risultato in molti modi differenti. Nelle situazioni più gravi, potrebbe essere sufficiente saturare il server sotto attacco con un numero di richieste elevato, magari generato mediante uno script appositamente confezionato.
Scarsa preparazione dell'utente
L'inappropriata preparazione tecnica di chi utilizza il PC è indubbiamente uno delle falle di sicurezza più critiche.
Sfruttando i meccanismi psicologici più basilari, è possibile indurre l'utente stesso a compromettere il proprio sistema: virus travestiti da calendari di ragazze in abiti succinti, false denunce recapitate via e-mail, truffe che sfruttano il nome della banca per farsi consegnare le credenziali di accesso e chi più ne ha più ne metta.
Approfondimenti: La falsa versione di Internet Explorer 7 con virus incorporato, Microsoft invia virus!
Abbiamo detto che l'individuazione di un errore in un programma è solo la prima fase del processo che può portare a forzare la sicurezza di un sistema informativo.
La seconda fase è quella più propriamente offensiva: scegliere e portare l'attacco vero e proprio, a seconda del tipo di vulnerabilità che è stata individuata.
Buffer overflow
Quando un programma assegna i dati ricevuti ad una variabile di grandezza predefinita senza prima verificarne le dimensioni, è possibile causare lo "straripamento" ("overflow", appunto) di tale variabile.
Per fare una similitudine con il mondo reale, pensate di avere una serie di scatole una di fianco all'altra, grandi ognuna 20 centimetri. Ora, pensate di inserire un oggetto lungo 30 centimetri nella prima scatola: se non vi accorgete che la capienza è effettivamente insufficiente, finirete con inserire 10 centimetri del vostro oggetto nella seconda scatola. In tale circostanza, si è verificato un "buffer overflow".
Un attacco di questo tipo può avere conseguenze critiche. Si spazia dalla possibilità di causare un crash al programma, fino alla modifica non autorizzata di dati.
Le cose possono però andare anche peggio: poiché le celle contigue a quelle originariamente designate a contenere il buffer sono adibite a memorizzare le informazioni relative allo svolgimento del programma, il cracker potrebbe riuscire a modificare tale spazio con istruzioni malevole, consentendo così l'esecuzione di codice arbitrario.
È bene precisare comunque che non tutti i programmi sono vulnerabili: le applicazioni realizzate in linguaggi quali Java o C #sono infatti immuni dal problema, poiché la verifica del corretto dimensionamento del buffer prima dell'assegnazione viene effettuata intrinsecamente dall'interprete, che blocca preventivamente l'assegnazione del dato malevolo. Altri linguaggi invece, quali il C oppure l'onnipresente C++, non hanno invece questi meccanismi.
Sebbene a livello concettuale il procedimento sia banale per chiunque abbia una buona preparazione tecnica, trasporre in pratica un attacco di questo tipo non è altrettanto semplice. Tale trattazione va oltre sia gli scopi di questo articolo, sia le competenze di chi lo sta realizzando: si rimanda quindi ai documenti linkati quali fonte di maggiori informazioni pratiche.
Approfondimento: CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'); Analysis of Buffer Overflow Attacks; Smashing The Stack For Fun And Profit
Stack-based o Heap-based
In alcune circostanza, si utilizzano i nomi Stack-based buffer overflow, oppure Heap-based buffer overflow: si tratta semplicemente di una ulteriore informazione che specifica se l'attacco è portato all'una oppure all'altra sezione in cui è organizzata la memoria allocata ad ogni processo, ma la dinamica non cambia.
Iniezione di SQL - SQL Injection
Un attacco di SQL injection può essere rivolto ad un database che utilizzasse parametri non opportunamente validati come componenti di una interrogazione.
Il principio, così come l'esecuzione di un attacco di questo tipo, è semplicissimo.
Pensiamo allo scenario in cui una pagina web mostri all'utente due campi di testo in cui immettere le proprie credenziali d'accesso. Come è facilmente intuibile, i dati immessi verranno confrontati con quelli presenti sulla memoria secondaria (un database, nel caso più comune), con una interrogazione che suona più o meno così: "esiste un utente di nome mario.rossi e password 123456?"
Ma... cosa succede se un cracker immette come dati l'equivalente del concetto "qualsiasi"? L'interrogazione si trasforma in "esiste un utente di nome qualsiasi e password qualsiasi?" Il database ritornerà l'intera tabella e, con tutta probabilità, consentirà al cracker l'accesso con le credenziali del primo record presente nella lista.
Allo stesso modo, un cracker che fosse entrato in possesso dello username di un utente dotato dei massimi privilegi potrebbe accedere al sistema forzando l'interrogazione a qualcosa equivalente a "esiste un utente di nome amministratore e password qualsiasi?".
Un attacco di questo tipo può avere conseguenze molto gravi: si spazia dalla possibilità di accedere all'applicazione con i privilegi di amministratore, fino alla cancellazione totale del database o della modifica "silenziosa" di alcune voci ivi contenute.
Approfondimento: SQL Injection Attacks by Example; CWE-89: Failure to Sanitize Data within SQL Queries (aka'SQL Injection')
Cross-site scripting (XSS)
Gli attacchi Cross-site scripting (la cui abbreviazione è "XSS", per evitare confusione con i fogli di sitle "CSS") sono causati da un'insufficiente validazione dei parametri in ingresso da parte dell'applicazione. Aggressioni di questo tipo sono al primo posto nella classifica di popolarità stilata da Open Web Application Security Project (OWASP) per il 2007.
Si tratta di un tipo d'attacco rivolto alle web application, e si presenta quando l'applicazione invia al browser dell'utente dati potenzialmente "attivi".
Pensate ad esempio allo scenario nel quale una web application acquisica la stringa di ricerca dall'URL: saremo quindi davanti a qualcosa del tipo http://www.dominio.com/cerca.php?stringa=supercalifragilisti. Una volta richiamata tale pagina, verrà mostrato qualcosa del tipo Risultati che soddisfano 'supercalifragilisti':.
Ma.. cosa succede se sostituiamo alla stringa di ricerca una parte di codice HTML come <img src="http://www.sitodelcracker.com/immagine.jpg">? Se la web application è vulnerabile, il navigatore dell'utente riceverà tale istruzione, e mostrerà l'immagine.
Ancora niente di realmente pericoloso, ma un utente ostile potrebbe ulteriormente affinare la cosa per utilizzare codice Javascript in grado di acquisire i cookie impostati da dominio.com e trasmetterli verso sitodelcracker.com. Ecco quindi che il cracker potrebbe inviare l'URL così creato agli utenti con privilegi maggiori, persuadendoli a visitare tale link: in caso una delle vittime cadesse nel tranello, potrebbe consegnare il proprio cookie di autenticazione al cracker che, immettendolo nel proprio navigatore, potrebbe accedere a dominio.com con gli stessi privilegi della propria vittima.
Approfondimento: OWASP: Cross-site Scripting (XSS); CWE-79: Failure to Sanitize Directives in a Web Page (aka'Cross-site scripting'(XSS))
Cross-site request forgery (CSRF)
Mediante un attacco CSRF è possibile realizzare un collegamento che, "cavalcando" la sessione di un utente correttamente autenticato, potrebbe consentire ad un cracker di eseguire operazioni in sua vece.
Per capire il problema, immaginiamo lo scenario nel quale l'utente sia correttamente autenticato al sito dell'istituto bancario miabanca.com. Immaginiamo altresì che tale sito offra una funzione "ricordami" che, sfruttando i cookie, consenta all'utente di auto-autenticarsi ad ogni accesso.
Il problema si verifica in caso il sito della banca consenta di effettuare trasferimenti di denaro seguendo un indirizzo del tipo http://www.miabanca.com/trasferimenti.php?somma=5000&cc_destinatario=55555. A questo punto, un cracker potrebbe confezionare il link facendo puntare cc_destinatario al proprio conto corrente, e indurre la vittima a cliccare su tale indirizzo: in caso l'utente fosse ancora autenticato al momento del click, il trasferimento avrebbe luogo in modo automatico.
In alternativa, il cracker potrebbe mimetizzare l'URL mediante uno dei servizi come SnipURL o, ancora, inserire l'URL malevolo come destinazione di un tag HTML.
Approfondimento: OWASP: Cross-Site Request Forgery (CSRF)
Ingegneria sociale / Social engineering
Abbiamo detto che ogni attacco alla sicurezza di un sistema informatico si basa sull'individuazione di un errore. Non è però detto che l'errore sia nella piattaforma informativa: l'anello debole può essere anche l'utente del sistema stesso.
Un attacco di ingegneria sociale non è indirizzato al calcolatore, ma piuttosto all'utilizzatore.
Il cracker sfrutta alcuni basilari espedienti psicologici (quali timore dell'autorità, paura, cupidigia o desiderio) per indurre l'utente a compromettere, inconsapevolmente, il proprio calcolatore o la riservatezza delle informazioni.
Le tecniche in cui si concretizza l'ingegneria sociale sono molteplici: oltre ai virus travestiti da patch Microsoft, oppure da calendari per adulti, o da minacciose lettere di FBI o Polizia di Stato, la tecnica più popolare degli ultimi anni è quella del phishing.
Malware: virus, worm, backdoor, rootkit eccetera
Il numero di programmi malevoli che possono essere utilizzati per compromettere un sistema è estremamente variegato, ed ogni tipologia ha le sue caratteristiche.
Procedere ad una classificazione del codice maligno va oltre gli scopi del presente articolo: in questa sede, basti sapere che si tratta di programmi che, se eseguiti su un calcolatore, possono consentire al cracker di eseguire pressoché qualsiasi operazione consentita all'utente corrente: quindi visionare, modificare o eliminare dati sensibili, accedere alla webcam o al microfono eventualmente presenti o perfino eseguire operazioni cinematografiche quali disabilitare gli allarmi dell'abitazione, in caso il calcolatore venisse impiegato anche a tale scopo.
In caso l'attacco andasse a buon fine, il cracker potrebbe ottenere una serie di benefici differenti.
Ecco i principali.
Esecuzione di codice da remoto / Remote code execution
Il risultato più grave che una breccia nella sicurezza può portare è la possibilità di eseguire codice da remoto.
Arrivando a questo risultato (ad esempio, portando con successo un attacco di tipo "buffer overflow", oppure di Social engineering), il cracker è in grado di trasferire e lanciare un programma sul sistema della propria vittima: in tale scenario, l'aggressore opterà probabilmente per l'utilizzo di una qualche forma di malware, grazie al quale garantirsi pieno controllo del calcolatore assaltato via Internet.
Innalzamento dei privilegi / Privilege escalation
In certe situazioni, il cracker potrebbe disporre preventivamente di un accesso limitato al sistema che desidera violare. Questo si traduce in una minore libertà d'azione: per esempio, un account limitato potrebbe essere soggetto a restrizione circa le informazioni visualizzate o la durata della sessione.
Sfruttare opportunamente una falla nel metodo di autenticazione del sistema operativo o dell'applicazione potrebbe consentire al cracker di innalzare i propri privilegi, guadagnandosi pieni potre di amministrazione.
Divulgazione di informazioni / Information disclosure
Un attacco andato a buon fine potrebbe consentire al cracker di accedere ad informazioni potenzialmente riservate.
Potrebbe trattarsi di dati confidenziali, credenziali di accesso, o, ancora, di informazioni riguardanti la configurazione dell'applicazione o del sistema operativo, utili per stabilire lo stato corrente del calcolatore (percorso della directory di sistema, nome dell'utente correntemente loggato eccetera) e poter così intraprendere un secondo attacco.
Approfondimento: CWE-200: Information Leak (Information Disclosure)
Privazione di servizio / Denial of Service (DoS)
Una "privazione di servizio" può essere classificata sia come una metodologia di attacco, sia come l'esito di un assalto. Personalmente, reputo nettamente più corretta la seconda.
Ottenere un "Denial of Service" significa, genericamente, che l'attaccante è riuscito a bloccare un programma oppure l'intero calcolatore da cui lo stesso viene erogato.
Vi sono vari modi mediante i quali il cracker può ottenere tale risultato: ad esempio, portando un attacco di tipo buffer overflow o, ancora, aumentando il carico di lavoro richiesto al server-vittima fino a saturarne le risorse.
Si pensi, ad esempio, ad una web application in grado di offrire una schermata riassuntiva dei risultati delle partite di calcio, comprensive di brevi statistiche personali dei giocatori di ogni partita. È presumibile che, dato il numero di interrogazioni rivolte alla base di dati ed il calcolo dei vari valori, un servizio del genere impieghi pesantemente le risorse del web server. Rilevato tale comportamento, il cracker potrebbe causare una situazione di DoS semplicemente richiedendo centinaia di volte al secondo la stessa pagina, magari sfruttando uno script realizzato appositamente.
Vi sono comunque decine di metodi diversi mediante i quali il cracker può giungere ad inibire il regolare funzionamento di un servizio sotto attacco. È comunque importante ricordare che, anche in caso di successo, il cracker non sarà in grado di eseguire codice da remoto (e quindi acquisire pieno controllo del calcolatore) ma semplicemente di portare ad una interruzione del servizio.
Sebbene il risultato sia intrinsecamente meno grave (il cracker non potrà, ad esempio, accedere ad informazioni riservate o modificare i dati memorizzati sul sistema), l'effetto di un attacco DoS può essere comunque considerevole: si pensi ad esempio ai danni di natura economica che un'azienda potrebbe subire in caso il relativo sito di e-commerce fosse paralizzato da un attacco di questo tipo.
Privazione di servizio distribuita - Distributed Denial of Service (DDoS)
Se la partita per arrivare ad una situazione di Denial of Service è giocata fra un aggressore ed un aggredito, il cracker può tentare di sopraffare il bersaglio anche con un attacco di gruppo: in questo caso, i calcolatori impiegati per compromettere il servizio saranno più di uno.
Probabilmente, gli "alleati" del cracker saranno del tutto ignari di quanto sta avvenendo: in molti casi infatti, aggressioni di questo tipo sono perpetrate sfruttando dei sistemi detti "zombie", ovvero calcolatori che sono stati precedentemente compromessi e sui quali è stato installata una qualche forma di malware che consente al cracker di controllare la propria armata attraverso Internet.
MegaLab.it rispetta la tua privacy. Per esercitare i tuoi diritti scrivi a: privacy@megalab.it .
Copyright 2008 MegaLab.it - Tutti i diritti sono riservati