Sicurezza e GNU/Linux (parte 1): tipologie di attacco

Un viaggio a puntate sulle tematiche legate alla sicurezza, ai sistemi Unix e al software libero.

Le tipologie di attacco

Prima di parlare di come proteggere un software, è bene capire da cosa un software va protetto. Possiamo distinguere grossolanamente i tipi di attacco informatico in tre categorie:

1. Attacchi che sfruttano la “buona fede” dell’utente (social engineering);

2. Attacchi che sfruttano una falla (vulnerabilità) involontaria del software;

3. Attacchi che sfruttano un difetto di progettazione del software, di un protocollo di comunicazione o di un formato dati (by design);

4. Attacchi che sfruttano una configurazione debole (o persino del tutto errata) del software.

La prima tipologia parte dall’assunto che l’utente è l’anello più debole di un sistema informatico. Sebbene a prima vista possa sembrare una banalità, in realtà si tratta di una vera filosofia, il cui postulato (corretto, ma non scontato) è che l’utente fa parte del sistema informatico stesso. Oggi l’ingegneria sociale è senza dubbio la metodologia preferita negli attacchi informatici a causa della larghissima diffusione dei computer presso utenti del tutto privi di ogni nozione fondamentale sulla sicurezza informatica. Inoltre, dal punto di vista tecnico, sfruttare l’ingenuità dell’utente è decisamente più semplice di studiare in modo approfondito un software per scoprire i suoi punti deboli.

La seconda tipologia di attacco si basa invece proprio sulla scoperta di errori di programmazione all’interno del software.

La terza tipologia invece non si appoggia su un vero e proprio errore di programmazione, ma su un errore di progettazione. La differenza a volte è sottile, ma ha (in certi casi) delle conseguenze pratiche molto rilevanti. Mentre una falla dovuta ad un errore di programmazione può essere facilmente corretta nelle versioni successive del programma, una falla dovuta ad un difetto di progettazione può voler dire dover riscrivere parti molto consistenti del software, disattivare funzionalità o realizzarle in modo differente, perdendo a volte la compatibilità verso il passato. Nel casi peggiori, la falla non potrà mai venire corretta, ma eventualmente si dovranno tamponare le conseguenze. Si tratta quindi di un caso più grave rispetto alla tipologia 2.

Per capire la differenza, possiamo fare questo esempio: in una partita di calcio, l’allenatore decide di usare lo schema 4-4-2. La partita va bene ma ad un certo punto un giocatore dà un pugno in faccia ad un avversario in area: il giocatore viene espulso, la sua squadra subisce un rigore e perde il confronto. Questo non significa che lo schema 4-4-2 sia errato: semplicemente un fattore contingente ha determinato la sconfitta. Nelle partite successive l’allenatore eviterà di schierare il giocatore troppo violento per risolvere il “bug”.

Un altro allenatore invece decide di adottare lo schema (assurdo, si intende) 1-1-8. La squadra perde tutte le partite allo stesso modo. In questo secondo caso, c’è poco da cambiare giocatori o intimare loro di adottare il fair play: è lo schema ad essere totalmente sbagliato, chi deve andarsene è semmai l’allenatore.

Vulnerabilità relative ad una cattiva progettazione possono riguardare anche protocolli o formati di dati. In questo caso, qualsiasi implementazione software, dovendo rispettare le specifiche del protocollo o del formato di dati, può potenzialmente essere affetta dalla vulnerabilità.

Infine, è frequente in caso di attacchi rivolti a sistemi la cui configurazione in termini di sicurezza è debole o errata.  Il caso più comune è quello di assegnare permessi eccessivi a script o eseguibili binari, contravvenendo alla regola aurea dei “permessi minimi”.

Bisogna sottolineare che spesso gli attacchi vengono condotti con tecniche miste: ad esempio, sapendo che un browser ha una certa falla, si deve però indurre l’utente a visitare il sito appositamente creato per sfruttarla. Per farlo tornano quindi utili le tecniche di social engineering.

Nella prossima puntata vedremo cos’è concretamente una vulnerabilità, analizzando le più comuni tipologie.

About these ads