www.MegaLab.it

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.