Il blog sull'informatica

Una delle tecniche maggiormante utilizzate negli ultimi anni, che può portare a conseguenze a dir poco devastanti, è l'SQL injection. Gli unici siti che soffrono tale tipologia di attacco sono quelli dinamici, ovvero contenenti script lato server (PHP, ASP, JSP, ecc.) per la gestione delle informazioni e per l'inoltro delle interrogazioni al DBMS (Oracle, MySQL, SQLserver e molti altri).

L'SQL injection basa il suo funzionamento sulla costruzione di query "anomale" che se non opportunamente filtrate consentono all'utente malevolo di ottenere i privilegi di amministratore, oppure di accedere al sito senza possedere le credenziali necessarie per il login, o ancora di alterare il contenuto del database ed in alcuni casi del sito stesso (defacing), fino ad arrivare all'hacking della macchina su cui è in esecuzione il DBMS.

Ma facciamo un esempio pratico. Supponiamo di collegarci ad un sito in cui è presente un pannello di gestione dedicato all'admin. A tale pannello ci si può accedere inserendo username e password opportuni. Qui entra in gioco l'SQL injection: attraverso delle stringhe costruite ad hoc posso indurre in errore il sistema di autenticazione, ottenendo l'accesso abusivo alla pagina di amministrazione. Una stringa che potrei inserire nel campo username è la seguente:

'

Si, avete letto bene. Si tratta semplicemente di un apice, il quale viene utilizzato per delimitare il nome della variabile passata al server (ovvero il nome utente). E la password? Non ci serve, poichè se lo script ed il DBMS sono vulnerabili avremo già ottenuto l'accesso al pannello di amministrazione. Nel caso in cui tale stringa non produca i risultati sperati si potrebbe usare come username ' e come password = .

Un altro tipo di stringa usata frequentemente nell'ambito di questo attacco è la seguente:

' OR 'x' = 'x

da inserire sempre nel campo username. Con il primo apice non facciamo altro che delimitare il nome della (presunta) variabile passata al server, mentre con 'x' = 'x indico una condizione sempre vera (non ho inserito appositamente l'ultimo apice in quanto viene aggiunto automaticamente dal DBMS all'interno dell'interrogazione). Ma il vero punto di forza di tale stringa sta nell'OR: tale operatore logico fa in modo che nel caso in cui non venga rispettata la prima condizione, si passi direttamente alla seconda (sempre vera), ottenendo l'accesso.

Un'altra query interessante è la seguente:

' OR 0=0 -- 

In questo caso non è stato necessario inserire lo 0 tra due apici in quanto non si tratta di una stringa ma di un valore numerico. Per il resto la sintassi è identica a quella dell'interrogazione precedentemente esaminata, eccezion fatta per i due trattini posti alla fine, ovvero --. Questi due trattini hanno come scopo quello di portare il DBMS ad ignorare tutto ciò che è presente dopo la seguente istruzione. 

Inoltre, è necessario fare attenzione alle cosiddette query multiple (intervallate dal ;). Eccone un esempio:

 1; DROP TABLE users

In questo modo si riuscirà a cancellare la tabella "users", in quanto il DBMS interpreterà tale stringa come:

SELECT * FROM DATA WHERE id=1;DROP TABLE users;

Ovviamente le query malevole che possono essere "iniettate" al DBMS sono tantissime, cercate un pò sul Web e ne troverete a migliaia.

Arrivati a questo punto credo sia necessario accennare ad una particolare variante di SQL injection, cioè il blind SQL injection. Questo attacco viene perpetrato contro i database di cui non si conosce la struttura (ad esempio il nome delle tabelle oppure i campi relativi ad esse), e sfrutta gli eventuali messaggi di debug che manda in output il server nel momento in cui viene riscontrata la presenza di un qualche tipo di errore. Basta quindi creare le condizioni adatte affinchè si manifesti l'errore (usando query malformed) per capire qual è la "fisionomia" della base di dati oggetto del nostro attacco. Ecco un esempio:

Obiettivo: Trovare il nome della tabella e della prima colonna
Comando: ' having 0=0--
Risultato: Column 'members.UserID' is invalid in the select list because it is not contained in an aggregate function and there is no GROUP BY clause.

Obiettivo: Trovare il nome della colonna successiva
Comando: ' group by members.UserID having 0=0--
Risultato: Column 'members.Password' is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause.

Obiettivo: Estrarre i nomi di tutte le colonne successive
Comando: ' group by members.UserID, members.Password having 0=0 --
Risultato: Column 'members.FirstName' is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause.

Possiamo ripetere questo attacco andando ad inserire il nome della tabella visualizzato nel messaggio di errore immediatamente precedente, fino a quando il server non invierà più notifiche di questo tipo. A questo punto il gioco è fatto: la struttura del database non ha più segreti :)

Ah quasi dimenticavo... per MS SQLserver esiste un comando, ovvero sp-password, il quale fa in modo che la query malformed non venga salvata all'interno del file di log. Inoltre, questo server fa ampio uso di Transact SQL (altrimenti conosciuto con l'acronimo T-SQL), che è il "dialetto" mediante al quale vengono costruite moltissime interrogazioni malevole. Per questi (ed altri) motivi, a mio avviso SQLserver è uno dei DBMS più vulnerabili in circolazione.

A questo punto credo si possa parlare dei metodi grazie ai quali è possibile prevenire (o per lo meno limitare) gli effetti di un attacco di questo genere. Per prima cosa occorre scegliere un DBMS poco vulnerabile (ad esempio MySQL). Dopodichè è necessario prestare molta attenzione (a livello di script) alla cosiddetta validazione dell'input. Se ad esempio il server si aspetta un numero, è necessario controllare che tale variabile sia effettivamente di tipo numerico. Inoltre si deve evitare che all'interno della query vengano inseriti i cosiddetti caratteri speciali, quali ', ", #, ecc. , che potrebbero mandare il DBMS "in confusione". A tal scopo esistono alcune funzioni che i linguaggi di scripting, quali PHP, ci mettono a disposizione. Una di queste è mysql_real_escape_string(), ed è utilizzabile quando ad interfacciarsi con il nostro script è un server MySQL. Essa non fa altro che aggiungere automaticamente un carattere di "escape" (ovvero il backslash) davanti ad alcuni caratteri, quali backslah x00, backslash n, backslash " e così via. In tal modo si rende "immune" all'SQL injection l'argomento da passare alla funzione mysql_query() (che invierà l'interrogazione vera e propria).

Un'altra funzione che può tornare utile è stripslashes(). Essa aggiunge un escape davanti a tutti i ', ", e Null. Si potrebbe evitare di usarla semplicemente andando ad impostare correttamente il file di configurazione di PHP, cioè php.ini: basta abilitare l'opzione magic_quotes_gpc (dove gpc sta per GET, POST E Cookie).

Si potrebbe anche (in teoria) eliminare a priori gli apici (anche se questa soluzione è molto limitativa), oppure li si potrebbe raddoppiare. Si potrebbe anche effettuare un controllo delle stringhe passate al DBMS attraverso delle espressioni regolari, altrimenti dette Regex. Un'altra valida soluzione consiste nell'usare una whitelist, ovvero un insieme di stringhe ammissibili e considerate non malevole. Inoltre, per evitare il blind SQL injection, si potrebbero disabilitare i messaggi di debug (sempre via php.ini) oppure utilizzare opportunamente l'operatore di silence (@) messo a disposizione da PHP. Per quanto riguarda le query multiple, invece, conviene sempre disabilitarle (per ovvie ragioni di sicurezza).

Ricordatevi comunque di tenere sempre aggiornato il DBMS ed il server, installando le eventuali patch, e controllate che il sistema di gestione del database non abbia privilegi elevati, in quanto un hacker, ottenendone il controllo, potrebbe compromettere la sicurezza dell'intera macchina. 

Concludo questo post (redatto a titolo informativo) mettendovi in guardia sul fatto che il solo TENTATIVO di accesso abusivo ad un sito (oppure ad un sistema telematico in genere) è considerato reato penale. Quindi se proprio volete fare dei test, fateli sui vostri server per saggiarne la robustezza. Come si dice... uomo avvisato mezzo salvato :). A presto.

L'ARP poisoning (o ARP spoofing) è una tecnica che consente di effettuare attacchi man in the middle. Essa modifica intenzionalmente le ARP table degli host appartenenti ad un adato segmento della LAN, permettendo all'attaccante di intercettare le informazioni scambiate in locale o con un server remoto (se si riesce a sniffare il traffico diretto verso il gateway).

Ma a cosa servono le ARP table? Servono semplicemente a mappare il MAC address da 48 bit (detto anche indirizzo fisico) di ogni dispositivo collegato alla rete con il rispettivo indirizzo IP. 

Vediamo ora come viene realizzato questo tipo di attacco:

Trudy (l'attacker) invia un'ARP-reply ad Alice contenente il proprio indirizzo MAC e l'indirizzo IP di Bob. Successivamente invia a Bob un'ARP-reply contenente sempre il proprio MAC address ma l'indirizzo IP di Alice. In questo modo Trudy riuscirà ad intercettare le informazioni scambiate tra Bob ed Alice. 

Tale metodo di attacco, però, non è propriamente passivo. Infatti è necessario inviare continuamente le ARP-reply modificate ad Alice e a Bob, poichè le ARP table vengono continuamente resettate ed aggiornate.

E' bene notare inoltre che l'ARP poisoning non ha alcun effetto sulle reti che fanno uso di switch e di VLAN. Infatti, ogni Virtual LAN è come se fosse una rete locale a sè stante, suddividendo la rete in più comprartimenti stagni. Ecco allora che se ad esempio Trudy è connessa alla VLAN 1, mentre Alice e Bob si trovano nella VLAN 2, l'attacco non andrà a buon fine.

Una tecnica alternativa all'ARP poisoning, che consente di superare l'ostacolo rappresentato dalle VLAN, prende il nome di MAC flooding. Essa consiste nell'inviare continuamente indirizzi MAC allo switch, in modo da riempire completamente la CAM (ovvero la memoria in cui tale dispositivo tiene traccia degli indirizzi fisici), sovraccaricandola. A questo punto lo switch entrerà in uno stato, detto fail open, iniziando ad inoltrare il traffico su tutte le porte, comportandosi quindi come un normalissimo hub. Non bisogna però generalizzare: infatti alcuni switch anzichè andare in fail open entrano in fail close, bloccando tutti i pacchetti.

Maggiori informazioni sull'ARP poisoning le trovate a questo indirizzo. Bye.

Il WEP (ovvero Wired Equivalent Privacy) rappresenta il primo sistema standardizzato (IEEE 802.11) per la protezione delle reti wi-fi.  Poichè deve garantire un'elevata velocità di cifratura/decifratura, esso si basa sul cifrario a flusso RC4, ereditandone inevitabilmente i punti deboli. Ma in realtà ad essere vulnerabile non è l'RC4 in quanto tale, ma la sua implementazione nell'ambito del WEP. Ecco allora che può risultare conveniente spiegare come avviene la cifratura mediante tale sistema e successivamente analizzarne le vulnerabilità.

Sostanzialmente la cifratura WEP fa in modo che il testo in chiaro venga "xorato" byte per byte con il keystream (il quale, in teoria, funge da one time pad). Se però la chiave in ingresso allo pseudo random byte generator è sempre la stessa, verrà prodotto in output sempre lo stesso keystream e di conseguenza si arriverà sempre alla stessa cifratura. E' quindi necessario usare, oltre alla chiave, un vettore di inizializzazione (IV) da 24 bit, da dare in pasto al generatore di byte pseudo casuali, ovviamente insieme alla chiave stessa. In definitiva, nel caso di WEP-128, avrò una chiave da 104 bit + i 24 bit dell'IV.

Una prima osservazione che si potrebbe fare riguarda le dimensioni effettive della chiave: spesso, infatti, si parla di 64 bit, di 128 bit o di 256 bit, ma questo è fondamentalmente sbagliato. Infatti, nel caso di WEP-128 la chiave ha dimensione, come già descritto in precedenza, pari a 104 bit e discorso analogo vale per WEP-64 (chiave da 40 bit) e WEP-256 (chiave 232 bit).  I rimanenti 24 bit, quindi, rappresentano sempre il vettore di inizializzazione.

Vediamo ora come avviene l'invio dei pacchetti nell'ambito delle reti wireless che sfruttano il WEP.

Per prima cosa concateno il pacchetto in chiaro al CRC-32 (Cyclic Redundancy Check a 32 bit) calcolato sullo stesso, in modo da garantirne (in teoria) l'integrità. 

(M || CRC(M))

dove || rappresenta l'operatore di concatenazione.

Successivamente cifro tale quantità con RC4 ed otterrò il pacchetto cifrato C

(M || CRC(M)) XOR RC4(IV || K) = C

dove K rappresenta la chiave.

Adesso invio il pacchetto cifrato C insieme all'IV, il quale però dovrà rimanere in chiaro (senza di esso l'utente non sarebbe in grado di decifrare C). Da notare che L'IV verrà anteposto a C, come mostrato in figura:

Una prima vulnerabilità del WEP sta proprio nell'uso dell'IV. Come già detto in precedenza, esso non è altro che un contatore a 24 bit. Il numero massimo di IV diversi che posso generare è 2^24 e la probabilità di trovare due IV che collidono (ovvero identici) è di 2^12 (per il paradosso del compleanno). Inoltre, gli IV aventi valori più bassi sono quelli più probabili (per via di eventuali reset della scheda). Ma cosa succede se trovo due IV coincidenti? Vediamo questo semplice esempio:

C1 XOR C2 = M1 XOR k XOR M2 XOR k

dove C1 e C2 sono i due pacchetti cifrati aventi lo stesso IV,  M1 ed M2 sono i pacchetti in chiaro e k è il keystream (in questo caso si è assunto per semplicità che i due pacchetti cifrati abbiano anche lo stesso keystream).

Successivamente calcolo k XOR k che da come risultato 0 (è una proprietà fondamentale dello XOR), ed infine calcolo M1 XOR 0 che da come risultato proprio M1 (in quanto lo 0 rappresenta l'elemento neutro dello XOR). Ecco allora che sono riuscito a decifrare il messaggio criptato.

Un altro punto debole del WEP riguarda l'integrità. Infatti, il CRC è un sistema di controllo che può essere facilmente eluso, in quanto presenta le seguenti limitazioni:

1) CRC(A XOR B) = CRC(A) XOR CRC(B) (proprietà di linearità);

2) non soddisfa la proprietà di resistenza alle collisioni (sia forte che debole);

3) può essere facilmente calcolato mediante circuiti elementari.

Supponiamo ad esempio di creare un pacchetto alterato, dato dallo XOR tra il pacchetto originario ed una certa quantita Q

M' = M XOR Q.

Lo invierò in questo modo:

((M XOR Q) || CRC (M XOR Q)) XOR RC4(IV || K) = ((M XOR Q) || CRC(M) XOR CRC(Q)) XOR RC4(IV || K) = (M || CRC(M) XOR Q || CRC(Q)) XOR RC4 (IV || K)

dove (M || CRC(M)) rappresenta il pacchetto originario (comprensivo di integrity check) e Q || CRC(Q) rappresenta la quantità da me aggiunta arbitrariamente (compresinva di integrity check).  In tal modo, in fase di decifratura, il messaggio verrà considerato integro (anche se in realtà non lo è). Da notare inoltre che ((M XOR Q) || CRC (M XOR Q)) XOR RC4(IV || K) = ((M XOR Q) || CRC(M) XOR CRC(Q)) XOR RC4(IV || K) proprio a causa della linearità del CRC.

Tipi di attacco

Nel corso degli anni sono stati documentati diversi tipi di attacco perpetrati contro le reti WEP, i quali hanno decretato il completo fallimento di tale sistema per la sicurezza delle reti wi-fi, condannato ormai a scomparire. 

In particolare, nel 2001, Fluher, Martin e Shamir (coideatore dell'RSA), individuarono una vulnerabilità intrinseca al WEP che avrebbe consentito di carpire il primo byte del keystream per poi ricostruirlo interamente in modo incrementale e scoprire infine la chiave. Tale tipo di attacco si basa sull'utilizzo di pacchetti aventi tutti lo stesso header, ovvero i pacchetti LLC (Logical Link Control - standard 802.2). Nella fattispecie, il preambolo (denominato SNAP) associato a tali pacchetti è sempre il seguente: 0xAA. Basta quindi "xorare" ogni pacchetto cifrato di questo tipo con il pacchetto LLC in chiaro per ottenere il primo byte del keystream.  L'unica limitazione relativa a questo attacco consiste nell'elevato numero di IV necessari per portarlo a termine, ovvero da 500000 fino ad oltre 1000000. Capite bene che per ottenere un numero così alto di vettori di inizializzazione serve molto traffico, cosa che non sempre si verifica.

Successivamente, un altro tipo di attacco fu scoperto da Klein, che ridusse il numero di IV  a soli 25000. A Klein seguirono Tews e Weinmann, i quali misero a punto il cosiddetto attacco PWT. Esso si basa il protocollo ARP (che mappa gli indirizzi IP con i rispettivi MAC address), il quale non prevede alcun meccanismo di controllo. Proprio per questa ragione, posso forzare la rete a produrre molti pacchetti ARP, effettuando il cosiddetto ARP reinjection (prendo una ARP request e la moltiplico all'infinto reimmettendola continuamente nella rete). Però anche questo tipo di attacco ha i suoi punti deboli:

- non tutte le schede supportano il reinjection;

- è un attacco attivo (poichè fa aumentare il traffico della rete).

L'ultimo tipo di attacco che mi accingo a mensionare è denominato ChopChop. Esso permette di decriptare i messaggi senza ricostruire prima la chiave ed è l'unico tra quelli descritti a non essere stato messo a punto in ambito accademico (ecco perchè possiede scarsa documentazione).

Una volta scoperte le diverse vulnerabilità che affliggono il WEP si è deciso di correre ai ripari, implementando il cosiddetto WPA (Wi-Fi Protected Access). Anch'esso si basa sul cifrario a flusso RC4 e prevede due modalità di funzionamento: TKIP oppure PSK (Pre-Shared Key).

La modalità più sicura è certamente TKIP: per generare la chiave da cui ricavare il keystream, vado a calcolare l'hash della chiave condivisa K, della chiave di sessione Sk (ricavata dalla chiave K) e del MAC address appartenente al destinatario:

HASH(K, Sk, MAC)

L'11 novembre del 2008 è stata scoperta una vulnerabilità associata al WPA che consente di ricostruire alcune porzioni del keystream. Tale vulnerabilità affligge il servizio QoS (Quality of Service) e può essere in qualche modo limitata alzando la frequenza di ricambio della chiave di sessione Sk e disabilitando il QoS.

Anche per questa ragione, ben presto il WPA verrà abbandonato, in quanto lo standard 802.11i prevede l'uso del WPA2, basato su una variante di AES, ovvero CCMP, considerato completamente sicuro.

Nel prossimo post parlerò dell'ARP poisoning, tecnica utilizzata per gli attacchi man in the middle. A presto.

Il cifrario a flusso RC4 fu ideato nel 1987 da Ron Rivest e rimase segreto (per ragioni commerciali) fino al 1997, anno in cui l'algoritmo che ne regola il funzionamento fu inviato al remailer anonimo Cypherpunks. Oggi, tale cifrario, è ampiamente utilizzato nell'ambito di moltissime applicazioni, quali SSL/TLS (per il Web) oppure WEP e WPA (per le reti wi-fi).

Sostanzialmente RC4 effettua tre operazioni:

1) inizializzazione del vettore S;

2) permutazione iniziale di S;

3) generazione del keystream (altrimenti detta generazione del flusso).

Inizializzazione di S (in pseudocodice)

for i = 0 to 255 do

S[i] = i;

Temp[i] = K[i mod keylen];

Inizialmente tutti gli elementi di S verranno posti uguali alla posizione da essi occupata. Ad esempio:

S[0] = 0, S[1] = 1, S[2] = 2, ...  ,S[255] = 255.

dove, come si può facilmente notare, S è un vettore di 256 posizioni (da 0 a 255).

Successivamente, se la chiave K data in pasto allo pseudo random byte generator ha dimensione (keylen) pari a 256 byte, essa verrà completamente copiata all'interno del vettore Temp. Invece, nel caso in cui keylen fosse inferiore a 256 byte (poichè RC4 prevede l'uso di chiavi di lunghezza variabile), la chiave K verrà copiata tante volte in Temp fino a riempirlo completamente.

Permutazione iniziale di S (in pseudocodice)

j = 0;

for i = 0 to 255 do

j = (j + S[i] + T[i]) mod 256;

Scambia (S[i], S[j]);

Ad esempio, per i = 0, S[0] = 1 e T[0] = 3 avrò:

j = (0 + S[0] + T[0]) = (0 + 1 + 3) = 4;

Scambia (S[0], S[4]); // Scambio il byte in posizione 0 con il byte in posizione 4

Stesso procedimento va fatto per i = 1, i = 2 fino ad i = 255.

A questo punto l'array Temp non mi servirà più, in quanto la chiave era necessaria solo per calcolare la permutazione iniziale di S.

Generazione del keystream (in pseudocodice)

i, j = 0;

while (true) //continuo ad effettuare tale operazione fino a quando ho cifrato tutti i byte del plaintext

i = (i + 1) mod 256;

j = (j + S[i] ) mod 256;

Scambia (S[i], S[j]) mod 256;

k = S[t]; // k (da non confondere con K) è il byte del keystream che andrò a "xorare" con un byte del plaintext.

Osservazioni

Sia i che j sono variabili a 8 bit (quindi rappresentano un byte). Il massimo valore (in base 10) che può assumere un byte è pari a 256 (8 bit tutti pari a 1). All'interno dello pseudocodice, quindi, l'uso dell'aritmetica modulare si è rivelato necessario, in quanto sia i che j non devono mai assumere valori superiori a 256.

Facciamo un esempio:

j = (38 + S[128] + T[128]) = (38 + 64  + 192 ) = 294;

ma questo numero non è rappresentabile con 8 bit. Quindi calcolo 294 mod 256 che avrà come risultato 38. 

Vengono inoltre usati 8 bit per le variabili i e j in quanto il vettore S che le utilizza come indici consta di 256 posizioni (come detto in precedenza).

Per maggiori informazioni relative all'aritmetica modulare vi rimando a questo indirizzo.

Nei prossimi post vedremo come un uso sbagliato di RC4 possa portare a seri problemi legati alla sicurezza. A presto.

Fino ad ora mi sono soffermato a descrivere alcuni esempi di cifrari a blocchi, quali DES o 3DES, che suddividono il plaintext in blocchi di lunghezza fissa per poi processarli. Questa tipologia di cifrari però possiede diversi punti deboli, tra i quali una certa difficoltà di implementazione a livello software ed una certa lentezza. Ecco allora che quando l'obbiettivo principale della cifratura è, oltre alla segretezza delle informazioni criptate, anche un buon grado di efficienza, conviene utilizzare i cosiddetti cifrari a flusso.

Sostanzialmente i cifrari a flusso operano in continuo su un byte di plaintext per volta (anche se esistono alcune implementazioni che agiscono su unità superiori al byte). Essi utilizzano una chiave da dare in pasto ad un generatore di byte pseudocasuali, il quale, a sua volta, produrrà in output una chiave di flusso, detta appunto keystream. Quest'ultima verrà "xorata" byte per byte con il plaintext (che, come detto in precedenza, viene processato un byte per volta).

La fase di cifratura può essere schematizzata nel modo seguente:

mentre quella di decifraturà apparirà nel modo seguente:

dove M è il messaggio in chiaro, C è il messaggio cifrato.

Bene, ora sappiamo che i cifrari a flusso sono in genere più efficienti di quelli a blocchi, e soprattutto richiedono meno codice per la loro implementazione. Ma quali sono i possibili punti deboli dei cifrari in questione? Ovviamente, uno dei punti deboli di maggior rilevanza potrebbe essere il periodo associato al generatore di byte pseudocasuali. Infatti, se i byte generati si ripetono in un periodo troppo breve, la crittoanalisi diviene un'operazione piuttosto semplice da effettuare. Discorso analogo riguarda lo pseudo random byte generator in quanto tale: se i byte generati non hanno tutta l'apparenza di byte completamente casuali, allora gli attacchi di crittoanalisi diverranno molto meno complessi. Infine, la chiave da dare in pasto al generatore di byte pseudocasuali deve essere di almeno 128 bit, poichè sappiamo che chiavi di dimensioni maggiori riescono a garantire una maggiore robustezza nei confronti di attacchi a forza bruta.

Nel prossimo post parlerò del cifrario a flusso attualmente più utilizzato, ovvero RC4. A presto.

Negli ultimi anni si è assistito ad una rapida diffusione delle reti wireless, con aumento esponenziale degli hot spot che forniscono libero accesso ad Internet, soprattutto in luoghi pubblici quali bar e fast food. Quasi contemporaneamente, però, è stato escogitato un nuovo tipo di attacco, basato sull'uso di un dispositivo che "simula" il vero Access Point. Tale attacco prende il nome di "evil twin", che letteralmente significa "gemello malvagio" (potete immagginare il perchè).

Ma come viene messo in atto questo tipo di attacco? Semplicemente il cracker di turno, munito di notebook e di un adattatore wi-fi, userà un SSID (ed eventualmente un ESSID) uguale a quello dell'AP reale, facendone le veci. Per consentire all'utente sprovveduto l'associazione immediata alla rete fittizia, il cracker attiverà sulla propria macchina un server DHCP (che assegna in automatico gli indirizzi IP) e lascerà la rete in modalità "open". Infine, utilizzerà un programma di sniffing per portare a termine questo tipo di attacco passivo. Nella fattispecie, grazie alla tipologia di software in questione, tutti i dati inviati in chiaro ai server remoti (ad esempio la password della webmail o di messanger) potranno essere facilmente intercettati.

Come fare quindi a prevenire un attacco del genere? Diffidare, innanzitutto, dalle reti wireless che consentono la connessione senza effettuare alcun tipo di controllo. Verificare che non vi siano due AP con lo stesso SSID e, nel caso fosse possibile, prima di usufruire del collegamento gratuito, chiedere informazioni al gestore del locale o all'amministratore di rete. Infine, sconsiglio fortemente di effettuare un qualunque tipo di login verso server remoti che non supportano l'invio cifrato delle credenziali di accesso (https).

Aprite bene gli occhi, poichè non è tutto oro quello che luccica :)

Dopo che le vulnerabilità del DES contro attacchi a forza bruta furono messe in luce, l'NSA dovette correre ai ripari. Fare in modo che il DEA utilizzasse chiavi di lunghezza superiore ai 64 bit era improponibile (sarebbe stato necessario cambiare un pò tutto l'algoritmo), quindi si scelse un altro approccio, che portò alla realizzazione del 3DES (altrimenti detto TDES, ovvero Triple DES). Tale sistema di cifratura non è altro che la tripla implementazione del DES stesso: poichè una singola implementazione utilizza chiavi da 64 bit, il 3DES utilizza chiavi da 192 bit (di cui 168 effettivi e 24 parità, 8 per ogni implementazione).

La cifratura mediante triplo DES si articola nei seguenti passi:

C = E(K3,D(K2,E(K1,M)))

dove M è il messaggio in chiaro, E(K1,M) indica la cifratura di M mediante la chiave K1, D(K2,E(K1,M)) indica la decifratura del messaggio precedentemente criptato, utilizzando questa volta la chiave k2, ed infine,  E(K3,D(K2,E(K1,M))) indica la cifratura del messaggio appena decriptato, però mediante la chiave K3. Per capire meglio tale sequenza di operazioni, è conveniente illustrare la seguente schematizzazione:

Occorre notare che l'operazione di decifratura non viene eseguita con la finalità di aumentare la robustezza del 3DES, ma solo per renderlo retrocompatibile con il DES. Ciò significa che coloro che fanno uso del 3DES come algoritmo di cifratura/decifratura, possono tranquillamente decifrare messaggi criptati mediante DES puro.

La decifratura consiste nelle stesse operazioni della cifratura, ma utilizza le chiavi in ordine inverso:

M = D(K1, E(K2, D(K3,C))) 

dove C è il messaggio cifrato. Tale operazione viene rappresentata di seguito:

Esiste inoltre una variante del DES triplo, in cui le chiavi K1 e K3 sono identiche. Ecco allora che la chiave complessiva sarà composta da 128 bit, di cui 112 effettivi (e 16 di parità).

Ma anche il 3DES, nonostante unisca resistenza contro attacchi di tipo bruteforce ad un elevata robustezza nei confronti di attacchi basati sulla crittoanalisi (ereditata dal DEA), ha i suoi svantaggi. Quello maggiore riguarda l'uso di blocchi dalla dimensione di 64 bit, quando per ottenere un buon margine di sicurezza occorre utilizzare blocchi di almeno 128 bit. L'altro punto debole riguarda la complessità di implementazione a livello software. Infatti, poichè il DES è stato sviluppato in modo da essere eseguito facilmente sui dispositivi hardware, la sua esecuzione a livello software è poco efficiente e , di conseguenza, questa sua pecca viene ereditata inevitabilmente dal DES triplo.

Spero di essere stato esaustivo. A presto.

Con tutti gli spyware, i trojan, i worm ed i virus che oggigiorno circolano in rete, le precauzioni da prendere per rendere relativamente sicuro il nostro sistema non sono mai troppe. Un valido aiuto, per i sistemi di casa Microsoft, arriva da un programmino, tanto semplice quanto utile: hijackthis (potete scaricarlo da qui - è gratuito). Esso, in tempi relativamente brevi, riesce ad analizzare i servizi in esecuzione e le chiavi di registro, stilando un resoconto dettagliato all'interno di un file di log. Sarà nostro compito, successivamente, copiare tale file in un sito dedicato ad analisi di questo tipo, il quale ci segnalerà la presenza di chiavi "anomale" o di eventuali processi malicious.

Ecco come utilizzare hijackthis. Dopo averlo scaricato, facciamo doppio click sull'eseguibile ed installiamolo. A questo punto verrà creata un'icona ul desktop, clicchiamoci sopra ed avviamo il programma. La schermata iniziale ci apparirà nel modo seguente:

Selezioniamo "Do a system scan and save a log file" e tale programmino, dopo aver analizzato attentamente in nostro sistema, produrrà un file di log che si aprirà in automatico a scansione conclusa. Tale file sarà disponibile all'interno della cartella C:/Programmi/Trend Micro/hijackthis e potete aprirlo anche in un secondo momento utilizzando il semplice blocco note.

Ora non ci resta che individuare eventuali record malevoli segnalati dal log. Per fare ciò andiamo su questo sito e carichiamo il nostro file *.log. Clicchiamo quindi su "Analizza" ed una volta visualizzato il risultato possiamo procedere con la rimozione delle chiavi "anomale" oppure dei servizi indesiderati.

Inutile dirvi che tali operazioni, in teoria, andrebbero fatte più volte alla settimana, in modo da tenere continuamente il nostro sistema sotto controllo.

La miniguida termina qui. Bye.

Ho già accennato in diversi post a quanto lo standard di cifratura DES sia vulnerabile. Adesso cerchiamo di capire il perchè, andando ad analizzare la logica che ne regola il funzionamento.

Innanzitutto la sigla DES sta per Data Encryption Standard, ed è un sistema di cifratura adottato come standard dal governo degli Stati Uniti d'America nel 1976. L'algoritmo su cui si basa è il DEA (Data Encryption Algorithm), evoluzione di un altro algoritmo di cifratura, il Lucifer, sviluppato presso i laboratori della IBM da Horst Feistel (ideatore della rete omonima). Il DEA, sostanzialmente, è proprio una rete di Feistel ed il suo funzionamento può essere studiato utilizzando il solito approccio, ovvero partendo dai blocchi più esterni fino ad arrivare a quelli più interni.

Passiamo quindi alla descrizione dell'algoritmo in questione. Un esempio della sua struttura esterna è presente nella figura seguente:

Il DEA si avvale di un cifrario a blocchi, il quale riceve in ingresso una stringa di testo di lunghezza fissa (plaintext - testo in chiaro) e la trasforma, mediante una serie di operazioni complesse, in un'altra stringa della stessa lunghezza, però cifrata. Nel caso del DES la dimensione di ogni blocco del cifrario è pari a 64 bit. Nel caso in cui il testo in chiaro da cifrare dovesse essere superiore ai 64 bit, esso verrà suddiviso in blocchi da 64 bit ciascuno (aggiungendo eventualmente del padding). Ogni blocco verrà quindi dato in pasto ad un cifrario e gli output così generati verranno combinati tra di loro.

E' bene notare che IP (Initial Permutation) ed FP (Final Permutation, altrimenti conosciuta come IP^-1) non hanno alcun ruolo nell'ambito della cifratura vera e propria, ma sono state aggiunte per facilitare il caricamento dei vari blocchi di bit sui dispositivi hardware tipici degli anni '70.

Vediamo ora cosa succede all'interno dell'IP

Ciò significa che il 58-esimo bit della sequenza di input (derivante dal testo in chiaro) verrà spostato in prima posizione della sequenza di output, il 50-esimo bit della sequenza di input verrà spostato in seconda posizione della sequenza di output e così via (seguendo sempre delle regole prefissate). Alla fine dell'IP avremo la seguente situazione (rappresentata in forma matriciale per semplicità, anche se in realtà è un vettore):

che, come si può notare, è una matrice 8x8 (contiene 64 elementi, ovvero i 64 bit di input permutati).

Ora che abbiamo visto cosa succede all'interno del blocco identificato dalla sigla IP, è facile andare a descrivere cosa succede in FP. Tale blocco viene anche identificato come IP^-1 poichè non fa altro che invertire le operazioni svolte da IP. Ecco allora che la matrice 8x8 relativa all'output prodotto dal blocco in questione è la seguente:

Osserviamo tale matrice. Il bit pari a 1, nella matrice risultate associata all'IP, si trovava in posizione 40. Al termine della FP il bit 40 si troverà in posizione 1. Discorso analogo vale per il bit 2, che nella matrice relativa all'IP si trovava in posizione 8, quindi nella matrice prodotta dalla FP l'8 si troverà in posizione 2 (e così via).

Vediamo adesso cosa succede all'interno del blocco F (ovvero la funzione di Feistel). Essa, sostanzialmente, opera su mezzo blocco per volta (formato da 32 bit) e consiste in 4 passi, illustrati di seguito:

1) Espansione: il mezzo blocco da 32 bit viene espanso a 48 bit utilizzando la cosiddetta permutazione di espansione (contrassegnata proprio con E nello schema), che duplica alcuni bit. Ciò è necessario in quanto successivamente si dovrà effettuare uno XOR con una della 16 subkey da 48 bit prodotte dallo scheduler delle chiavi, e come sappiamo, è impossibile effettuare tale operazione tra sequenze di bit di lunghezza diversa. Ma come avviene effettivamente tale espansione? Semplicemente ripetendo 2 volte i bit contenuti all'interno di 16 posizioni della matrice prodotta dall'IP. Tali posizioni sono "standard" e furono scelte appositamente dall'NSA.

2) Miscelazione con la chiave: viene calcolato lo XOR tra il risultato dell'espansione ed una delle 16 subkey da 48 bit.

3) Sostituzione: I 48 bit che costituiscono il risultato dello XOR tra la subkey ed il semiblocco espanso andranno in ingresso ad 8 S-box. Ciascuna S-box riceve in ingresso 6 bit (6x8 = 48) e restituisce in uscita 4 bit (4x8 = 32). Quindi l'output complessivo delle 8 S-box sarà proprio pari a 32 bit.

Ma come operano effettivamente le S-box? Supponiamo che i 6 bit in ingresso ad una delle 8 S-box siano 110010. La S-box che li riceve in ingresso li trasformerà in modo non lineare, ovvero S-box(a1 XOR s1) != S-box(a1) XOR S-box(s1), dove a1 è il semiblocco ed s1 è la chiave.

La tabella usata dalle S-box e nella fattispecie da quella che ha ricevuto in ingresso la sequenza 110010, è simile alla seguente:

Dove la posizione della tabella in cui verrà salvata la sequenza è identificata dalla X. Occorre notare, inoltre,  che in ogni cella vi sarà un numero compreso tra 1 e 15 (ovvero i valori decimali rappresentabili mediante i 4 bit di output). 

I 32 bit così ottenuti, infine, costituiranno l'input di una Permutation Box, identificata con la lettera P, la quale provvederà a ricombinarli per assemblare il seguente output:

Ma qual è l'effettiva utilità del blocco E, delle S-Box e del blocco P? Semplicemente quella di fornire il giusto grado di confusione e diffusione all'algoritmo considerato. Inoltre, sono proprio le S-box a rendere la cifratura non lineare e quindi difficilmente violabile.

Vediamo adesso come avviene lo scheduling delle chiavi. In soldoni, viene ricevuta in ingresso una chiave da 64 bit (56 bit effettivi + 8 bit per il controllo di parità) e restituite in uscita 16 sottochiavi da 48 bit ciascuna.  Ma perchè proprio 16 sottochiavi? Perchè 16 è il numero minimo di round per garantire al DEA una buona resistenza contro una tecnica chiamata "crittoanalisi differenziale", ideata ufficialmente intorno agli anni '90. Però, il fatto che l'algoritmo DEA utilizzi proprio 16 round e quindi 16 sottochiavi (una per round),  può (giustamente) indurci a credere che gli studiosi afferenti all'NSA conoscessero tale tecnica già durante gli anni '70.

Ecco lo schema che rappresenta lo scheduling delle chiavi:

In ingresso a PC-1 (ovvero Permuted Choise - 1) ho 64 bit (come detto in precedenza). Da questi 64 bit verranno scartati gli 8 bit di parità fino ad ottenere una chiave da 56 bit (essi verranno inoltre permutati). Tale chiave verrà quindi divisa in due parti da 28 bit ciascuna, chiamate rispettivamente C0 e D0.  Esse andranno in ingresso ad LS1, che ne effettuerà uno o due shift a sinistra per ricavare C1 e D1. In generale, LS[i] esegue uno o due shift a sinistra su C[i-1] e D[i-1] per ricavare C[i] e D[i]. Ad esempio:

Infine, C1 e D1 vengono passate in ingresso a PC2 (Permutation Choise - 2), che produce il seguente output di permutazione:

generando la sottochiave K1 da 48 bit.

Ovviamente tali operazioni si ripetono per tutti e 16 i round.

Ma perchè DES è insicuro? Semplicemente perchè utilizza chiavi troppo piccole (di soli 56 bit), vulnerabili ad attacchi bruteforce, che rendono deltutto inutile la robustezza del DEA contro gli attacchi basati sulla crittoanalisi.

Alcune osservazioni

Per DES vale la seguente regola:

M' = E(K,M)

M = D(K,M') e non M = E(K,M')

dove E equivale all'operazione di cifratura (Encryption), la D a quella di decifratura, K è la chiave, M il messaggio in chiaro ed M' quello cifrato.

In particolare, l'operazione di cifratura e decifratura sono identiche se e solo se tutte le sottochiavi sono uguali (ciò si verifica soltanto per le 4 chiavi "deboli"). Esistono inoltre le cosiddette chiavi sottodeboli, in cui corrispondono solo alcune delle sottochiavi.

Curiosità

Per molto tempo si è creduto che l'NSA conoscesse un sistema per decifrare facilmente i messaggi criptati tramite DES, in modo da tenere sotto controllo il maggior numero possibile di conversazioni "private". Per la precisione, si riteneva che tale sistema si basasse su un uso particolare delle S-box, il cui funzionamento è rimasto nascosto a lungo, proprio per volere dell'NSA (security through obscurity). Quando però le S-box vennero pubblicate e descritte dettagliatamente, questa tesi cadde istantaneamente. Essa, nonostante ciò, fu uno dei motivi principali che resero il DEA uno degli algoritmi di cifratura più studiati della storia (soprattutto in ambito universitario).

Un'altra curiosità riguarda invece la chiave da 56 bit: perchè utilizzare una chiave di dimensioni così ridotte? Molti affermano che la vera ragione stia sempre nella volontà dell'NSA di controllare il contenuto dei messaggi cifrati, stavolta mediante bruteforce (la tecnologia che consentiva di perpetrare un attacco di questo tipo durante gli anni '70 era, in teoria, prerogativa dell'NSA). Ovviamente, per la disponibilità tecnologica dell'epoca, era impensabile effettuare attacchi a forza bruta (entro tempi accettabili) contro chiavi di dimensioni maggiori.

Il post termina qui, a presto.

Abbiamo già visto come i sistemi Unix/Linux gestiscono le password relative ai vari utenti. Vediamo adesso come si articola la gestione delle password sotto i sistemi Windows.

Anche in questo caso, come per i sistemi Unix like, le password non vengono salvate in chiaro ma vengono criptate. Esistono sostanzialmente due modi per generare gli hash, uno abbastanza obsoleto e quindi piuttosto vulnerabile, mantenuto per motivi di retrocompatibilità, e l'altro più robusto, anche se non totalmente sicuro. Tali metodi sono rispettivamente:

-Hash LM (dove LM sta per LanManager);

-Hash NT (detto anche Unicode Hash o MD4 Hash).

Ma andiamo per ordine. L'Hash LM non è altro che l'algoritmo DES vero e proprio (che non si avvale quindi dell'uso del salt, come avviene invece per i sistemi Unix/Linux). Esso accetta password di dimensione massima pari a 14 caratteri (in questo caso ogni carattere rappresenta un byte, come previsto dalla codifica ASCII). Nel caso in cui la password sia inferiore ai 14 caratteri verrà introdotto del padding costituito da una sequenza di bit pari a 0. Il suo funzionamento è schematizzato nella figura seguente:

Come potete notare, LM Host accetta in ingresso i 14 caratteri che costituiscono la password dell'utente, suddividendola siccessivamente in due parti da 7 byte ciascuna. Dopodichè esegue la cifratura DES, avvalendosi di una stringa prefissata, per poi generare l'hash da 16 byte.

E' facile notare come tale sistema per la generazione degli hash abbia diversi punti deboli. Uno su tutti è l'utilizzo del DES puro, che come sappiamo è un algoritmo di cifratura insicuro in quanto soggetto ad attacchi di tipo bruteforce, poichè utilizza una chiave troppo piccola (solo 56 bit). Un altro punto debole è rappresentato dall'uso di una stringa prefissata e dunque nota durante la cifratura, cosa che ha consentito la creazione di tabelle predefinite (dette rainbow table), in cui sono presenti gli hash di tutte le combinazioni di 14 caratteri possibili (appartenenti sempre al codice ASCII). L'individuazione della password può quindi avvenire semplicemente confrontando l'hash con tutti quelli presenti nella rainbow table, fino all'individuazione della password corretta (attacco di tipo time-memory tradeoff). La suddivisione della password in due parti da 7 byte ciascuna è un altro tallone di Achille del sistema in questione, visto che ciascuna delle due parti può essere attaccata separatamente. Infine, LM Hash trasforma in caratteri maiuscoli tutti i caratteri che costituiscono la password dell'utente, rendendo deltutto inutile l'alternanza di caratteri minuscoli e maiuscoli presenti all'interno della password stessa.

Come fare quindi a non utilizzare questo sistema fortemente vulnerabile? Si potrebbe, ad esempio, disabilitarlo dal registro di sistema. Un'alternativa a tale operazione sarebbe quella di scegliere password di dimensione superiore ai 14 caratteri, quindi almeno di 15 caratteri, in modo da consentire la generazione dell'hash solo attraverso Hash NT, escludendo Hash LM.

Vediamo ora come funziona l'Hash NT. Tale sistema di hashing è basato sull'algoritmo MD4, precursore del più famoso MD5. Occorre notare però che se MD4 è stato rimpiazzato da MD5 un motivo dovrà pur esserci. Infatti, dopo qualche tempo dal suo rilascio, MD4 è stato catalogato come vulnerabile ad alcuni attacchi la cui finalità era quella di andare ad individuare delle collisioni (parole diverse che generano la stessa impronta). Quindi, nonostante si utilizzi solo Hash NT trascurando completamente Hash LM, la sicurezza della nostra password non è assicurata. Un'altra caratteristica relativa a tale algoritmo, che lo rende sicuramente più sicuro dell'obsoleto Hash LM, è che accetta password dalla lunghezza massima di 256 caratteri. Peccato però che i progettisti di Windows abbiano avuto la brillante idea di limitare il buffer della finestra associata al login interattivo a soli 127 caratteri. Quindi, nonostante possa scegliere password da 256 caratteri, sono costretto ad utilizzare password da 127 caratteri. Tutto sommato, però, c'è una buona notizia: i caratteri utilizzabili non fanno parte del codice ASCII (di dimensioni abbastanza ridotte), ma del codice Unicode (inventato sempre da Microsoft), il quale contiene quasi un milione di caratteri. Purtroppo, anche Hash NT non usa il salting, ragion per cui un attacco basato sulle rainbow table può comunque essere effettuato, anche se sicuramente richiede più tempo rispetto all'Hash LM. Esistono inoltre delle rainbow table diverse a seconda della lingua (ad esempio una rainbow table per la lingua italiana contenente caratteri accentati), in modo da superare l'ostacolo rappresentato dalle elevate dimensioni del codice Unicode.

Ma le password degli utenti di Windows dove vengono salvate? La risposta è semplice: all'interno della chiave di registro HKEY_LOCAL_MACHINE/SUM (accessibile tramite il registry), dove l'acronimo SUM sta per Security Account Manager.

Alla cartella SUM può accedere soltanto il sistema operativo (con privilegi di tipo System), dunque nemmeno l'amministratore di sistema. Esistono però alcuni tool che consentono ad un eventuale utente malevolo di fingersi il sistema operativo per ottenere il dumping delle informazioni contenute nella cartella in questione.

In definitiva, i consigli che posso darvi sono i seguenti:

1) Disabilitate Hash LM o, in alternativa, scegliete password di almeno 15 caratteri;

2) Utilizzate caratteri alfanumerici, maiuscole e minuscole, caratteri accentati ed altri simboli per irrobustire ulteriormente la password.

Il post termina qui, a presto.