www.MegaLab.it

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!