giovedì 23 maggio 2013

Form delle credenziali su HTTP


Nella lezione di ieri abbiamo descritto HTTPS, il protocollo utilizzato comunemente per accedere a servizi autenticati (GMail, Facebook, banche, acquisti on line, etc).

Abbiamo evidenziato che di norma il web server espone il form nel quale inserire le credenziali attraverso HTTPS. Ciò sembra inutile, in quanto non c'è nessun vantaggio nell'imporre che la richiesta di prelievo del form e lo stesso form viaggino con garanzia di riservatezza. La riservatezza è necessaria solo per la richiesta inviata subito dopo avere prelevato il form, cioè per la richiesta che contiene le credenziali. Questa slide sintetizza il motivo per il quale prelevare il form su HTTPS sembra inutile ma non lo è:


Secondo molti esperti, nel 2011 il governo della Tunisia ha forzato tutti gli Internet provider del paese a modificare i form esposti su HTTP dai servizi "importanti" (GMail, Facebook etc). Nelle pagine contenenti i form venivano aggiunte, durante il transito dal server al browser, un paio di linee Javascript. Questo codice, eseguito sul browser durante la visualizzazione della pagina contenente il form, prelevava le credenziali inserite dall'utente e le inviava ad una locazione scelta dall'attaccante (ometto alcuni dettagli tecnici irrilevanti su questo punto).

Questo è un esempio lampante di cosa può accadere quando i form sono esposti su HTTP e non su HTTPS: l'integrità dei messaggi non è garantita, ergo possono essere modificati in transito senza che il destinatario se ne accorga.

I dettagli sono indicati qui: Tunisian government harvesting usernames and passwords

Ho scoperto questo aneddoto, che non conoscevo, perché proprio stamani mattina mi sono imbattuto su un articolo che discute questo aspetto specifico in dettaglio:

Your login form posts to HTTPS, but you blew it when you loaded it over HTTP

(per inciso, già altre volte mi è capitato di avere una sorta di sfera di cristallo per prevedere il futuro: agli studenti dico una cosa che potrebbe accadere, probabilmente loro pensano che sono paranoico o fissato, e dopo qualche giorno quella cosa si verifica davvero; riporto un paio di esempi in coda a questo post).

Non è semplicissimo da leggere ma ha alcuni punti molto chiari, proprio sugli aspetti evidenziati ieri:
  • Loading login forms over HTTP renders any transport layer security almost entirely useless.
  • What people forget about SSL is that it’s not about encryption. Well that’s one feature of secure sockets, another really essential one is integrity insofar as it gives us confidence that the website content hasn’t been manipulated. Anything you load over an HTTP connection can be easily changed by a man in the middle which is why it’s absolutely essential to load those login forms over a secure connection.
L'articolo mostra anche esempi di siti molto importanti che NON espongono il form delle credenziali su HTTPS (e quindi sono fatti male).

Sfera di cristallo (esempi di mia previsione del futuro):


mercoledì 22 maggio 2013

Come si prende un virus con il browser

Un esempio semplice ed istruttivo.

Prima:

Utente che:
Dopo:
  1. Utente ha in esecuzione un nuovo programma, senza saperlo;
  2. Questo programma, che può fare tutto ciò che può fare l'utentericeve comandi da un attaccante esterno.
Prima di procedere nella lettura leggere e rileggere questi due punti in modo da comprenderne le implicazioni (tragedia !!!)

Spiegazione:


Federal News Radio 1500 AM and FederalNewsRadio.com comprise the key source of breaking news, information and analysis for the individuals responsible for carrying out and supporting the missions of federal agencies. Federal News Radio addresses federal agency managers, policy makers and contractors. ...
We cover both the federal government and those who do business with the government concentrating on management, defense, technology, contracting, policy and pay & benefits.


WTOP is an all-news formatted broadcast radio station licensed to Washington, D.C., serving Metropolitan Washington, DC area.

Ieri sera sulla mailing list dell'US-CERT (United States Computer Emergency Readiness Team) è stato inviato un avviso, appunto, semplice ed istruttivo relativo a questi due siti, che nel frattempo sono stati ripuliti:

On May 16, 2013, US-CERT was notified that both www.federalnewsradio[.]com and www.wtop[.]com had been compromised to redirect Internet Explorer users to an exploit kit. The compromised websites were modified to contain a hidden iframe referencing a JavaScript file on a dynamic-DNS host. The file returned from this site was identified as the Fiesta Exploit Kit.
Cioè, gli attaccanti hanno fatto in modo di inserire un paio di linee HTML nel contenuto servito da questi siti. Queste linee dicono al browser "carica il file Javascript F che si trova sul server N ed eseguilo". Il file F è il file maligno generato appositamente dall'attaccante (Fiesta Exploit Kit), mentre il server N è associato ad un indirizzo IP che varia rapidamente (non è essenziale approfondire) e che corrisponde ad un calcolatore su cui l'attaccante ha messo un piccolo server web dal quale prelevare F.
The exploit kit script uses one of several known vulnerabilities to attempt to download an executable:
Any systems visiting running vulnerable versions of Adobe Reader or Acrobat or Oracle Java may have been compromised.

Cioè, il file Javascript eseguito dal browser provoca il download da parte del browser di file PDF e file Java generati opportunamente dall'attaccante. Il contenuto del file PDF sfrutta errori software dei programmi Adobe Reader e Adobe Acrobat per fare eseguire, a questi stessi programmi, un piccolo programma scelto dall'attaccante. Il contenuto del file Java sfrutta errori software di Java 7 per fare la stessa cosa. L'attaccante usa più strategie invece di una sola in modo da aumentare la probabilità di trovare installato uno di questi 3 programmi, nella versione che abbia gli errori a lui necessari---a lui basta che sia installato uno di quei programmi.

Questo piccolo programma scarica e manda in esecuzione sul PC del browser un programma più complicato e molto più pericoloso: 
a known variant of the ZeroAccess Trojan. Additionally, according to open source reporting, the malware also downloads and installs a variant of FakeAV/Kazy malware.
The ZeroAccess Trojan attempts to beacon to one of two hardcoded command-and-control addresses, 194.165.17.3 and 209.68.32.176. The beaconing occurs using an HTTP GET using the Opera/10 user-agent string.
After beaconing, the malware then downloads a custom Microsoft Cabinet file and the malware uses port UDP/16464 to connect to the peer-to-peer network...

Alla fine, il PC dell'utente ha in esecuzione un programma (ZeroAccess Trojan) che si collega ad una network "command and control" ed è quindi controllato da remoto da un attaccante.

lunedì 20 maggio 2013

Crittografia quantica o quantistica

Crittografia quantica, un passo avanti significativo
Ricercatori dell'agenzia spaziale tedesca aprono la strada per una rete mondiale di comunicazioni satellitari supersicure.
...La crittografia quantistica è una specie di santo Graal per i crittografi, in quanto dovrebbe permettere di rendere inattaccabili le comunicazioni. Essa permetterebbe infatti ai due soggetti della comunicazioni di rendersi immediatamente conto di un eventuale intruso...
(link)


Premessa:

  1. Non sono un esperto di crittografia.
  2. Tutto ciò che so della notizia indicata qui sopra è contenuto nella notizia stessa (anche se ho letto varie riflessioni, in passato, sulla crittografia quantistica e cose di questo genere)
  3. Tutto quanto segue è implicitamente preceduto da "secondo me".

E' bene rendersi conto che cose di questo genere in pratica servono a molto poco.

Se un ladro desidera entrare in un appartamento al piano terra che ha pareti spesse due metri e porte superblindate, ma ha le finestre aperte oppure apribili facilmente, ovviamente non si mette a sbattere la testa contro le pareti e non cerca di scardinare la porta. Entra dalla finestra.

Nell'informatica è la stessa cosa. Nessuno attacca la crittografia. Qualunque attaccante attacca le numerose componenti vulnerabili che esistono in ogni sistema.

La crittografia quantistica non farà altro che rendere ancora più spesse delle pareti che sono già spesse abbastanza.

(per approfondimenti: http://reti-inginf-units.blogspot.it/2010/03/crittografia-e-sicurezza-informatica.html)




venerdì 17 maggio 2013

Firewall: Tutto proibito o tutto permesso ?

In una recente lezione di Reti abbiamo detto che alla frontiera di ogni organizzazione c'è un firewall che analizza tutto il traffico entrante ed uscente. Abbiamo anche detto che:

  1. I firewall moderni sono del tipo "tutto proibito"; ad ogni pacchetto sono applicate le regole specificate dall'amministratore; se il pacchetto non soddisfa nessuna di queste regole, allora il pacchetto è buttato via; le regole cioè specificano il traffico permesso.
  2. In precedenza i firewall erano del tipo "tutto permesso": le regole specificano gli attacchi, invece del traffico lecito; se il pacchetto soddisfa una regola allora è buttato via.
  3. L'approccio "tutto proibito" è più difficile da configurare ma è preferibile a "tutto permesso", in quanto per usare "tutto permesso" è necessario 1) conoscere tutti gli attacchi; 2) aggiornare rapidissimamente le regole per rilevare gli attacchi, in quanto questi cambiano di continuo.

Un modo indiretto per avere una idea di "quanto" sia complicato realizzare il punto 3 si può avere con la considerazione seguente.

Molte organizzazioni utilizzano, in aggiunta e indipendentemente dai firewall, dei sistemi di "intrusion detection". Un sistema di questo genere è, concettualmente e semplificando, una sorta di firewall "tutto permesso": applica un insieme di regole che descrivono gli attacchi possibili ad ogni pacchetto; se un pacchetto soddisfa una regola, il pacchetto non è scartato ma viene generato un alert (oppure viene memorizzato il pacchetto su disco per analisi successive). Inoltre, le regole non si basano solo sugli header ma possono basarsi anche sul payload.

Uno dei sistemi di intrusion detection più diffusi è Snort. La comunità degli utenti Snort mantiene collettivamente le regole e le aggiorna periodicamente.

Bene, il numero di regole nella distribuzione di pochi giorni fa è 2500 (duemilacinquecento). Molte di queste regole possono essere inutili, se utilizzate in organizzazioni che hanno firewall "tutto proibito" (in tal caso infatti descrivono pattern di traffico che in quelle organizzazioni non si possono verificare). L'aspetto importante da notare è però proprio il fatto che la comunità ha costruito ben duemilacinquecento pattern di traffico sospetti...

giovedì 16 maggio 2013

"La crittografia / sicurezza mi ha sempre affascinato..."


sono un suo studente del corso di Reti I e la crittografia mi ha sempre affascinato. Credo che sia un mondo parecchio vasto e purtroppo in rete si trovano un sacco di informazioni sparse. 
Visto che oggi a lezione abbiamo ne abbiamo accennato vorrei chiederle se può consigliarmi dei testi, oppure uno in particolare, di riferimento sul quale iniziare a studiare (o approfondire) questi aspetti. 

Per iniziare ad approfondire, questo è un ottimo testo disponibile online (molto interessante ma secondo me non scritto in modo "scorrevole"):
L'autore è Ross Anderson, dell'Università di Cambridge. E' una persona che certamente le banche di mezzo mondo vorrebbero rinchiudere da qualche parte buttando via la chiave. Non perché sia un ladro, ma perché è quello che ha dimostrato che:
  1. Le truffe via Bancomat esistono veramente---prima le banche ne negavano l'esistenza, dicendo "hai scritto il PIN su un foglietto e te l'hanno rubato", "è stata tua moglie a fare il prelievo senza dirtelo" etc."Your bank statement arrives in the post, and you find a thousand pounds missing. Someone has been making ATM withdrawals using your card and your PIN. Yet your card wasn't stolen, you've told no-one your PIN, and you're careful to make sure you're not watched as you type it in. If this sounds like you, your dispute is a phantom withdrawal, and this website is designed to help you." (http://www.phantomwithdrawals.com)
  2. Le nuove tessere Bancomat introdotte da poco in tutta Europa, quelle con il chip, hanno errori di protocollo che permettono di fare tante cose interessanti---per i ladri (http://reti-inginf-units.blogspot.it/2010/03/bancomat-c.html).
Per studiare in modo approfondito la crittografia invece occorre considerare "il" libro:
di Bruce Schneier (non so se la copia linkata sia legale; è il primo risultato fornito da Google).

Se invece uno è interessato alla storia della crittografia, c'è un libro davvero fantastico che è anche una ottima lettura serale o estiva. Non si tratta di un libro tecnico, è una sorta di racconto scritto in modo molto semplice, accurato ed avvincente:
ATTENZIONE: spesso le persone sono "interessate alla crittografia" perché pensano che conoscere la crittografia sia importante per soddisfare il loro vero interesse, che è quello della "sicurezza informatica" in generale. In realtà sono pochi i casi in cui conoscere approfonditamente la crittografia sia davvero "utile / importante". A meno di non essere uno studioso di crittografia.

Nella stragrande maggioranza delle applicazioni pratiche è sufficiente considerare gli algoritmi crittografici come una black box. Si sa cosa fanno, ma non come lo fanno. Inoltre, cosa ben più importante, avere un algoritmo crittografico assolutamente perfetto e inattaccabile è spesso del tutto inutile. Cito me stesso:


L’effettivo ruolo della crittografia nelle applicazioni informatiche, peraltro, è spesso frainteso. Si tende infatti a considerare il mero uso della crittografia come sinonimo di “garanzia assoluta di sicurezza”. Purtroppo questa conclusione è del tutto infondata ed in questo breve contributo cercheremo di spiegarne il motivo. In estrema sintesi, la sicurezza di un’applicazione informatica richiede la soluzione di numerosi problemi. La crittografia risolve alcuni di essi ma è del tutto inutile per altri. Nella pratica, gli attaccanti sfruttano proprio i numerosi problemi irrisolti.


Lo stesso concetto era stato spiegato, in modo infinitamente più autorevole di me, dallo stesso Ross Anderson già nel 1993:

("Why cryptosystems fail", si trova via Google Scholar http://meslab.snu.ac.kr/courses/2007f/dip/papers/12-Anderson94.pdf)

dato il mio interesse per la sicurezza informatica volevo chiederle se poteva consigliarmi del materiale su cui approfondire.uno in particolare, di riferimento sul quale iniziare a studiare (o approfondire) questi aspetti. 

In questo caso è difficile rispondere, perchè la "sicurezza informatica" è un settore vastissimo e che si può studiare a molti livelli di astrazione ed approfondimento diversi. Si va dagli aspetti molto specifici per i quali sono necessarie competenze tecniche molto approfondite (come si penetra in un sistema operativo; come si attacca un sito web o una applicazione specifica; come si cercano le vulnerabilità in una applicazione o in una installazione fisica). Ci sono poi tutti i numerosi protocolli e tecnologie per la difesa (SSL/HTTPS che si fa alla fine di Reti I; varie tecnologie che si fanno a Reti II come Kerberos, VPN, OAuth etc; molte altre tecnologie che ho insegnato in corsi vari ma mai a Reti, come DNSSEC; molte altre tecnologie che personalmente conosco solo di nome).

Personalmente penso che un tema molto affascinante sia quello della nascente economia del crimine informatico. Tema che meriterebbe di essere conosciuto da tutti. Potete dare un'occhiata qui:

Nei mesi scorsi ho tenuto un corso di Sicurezza Informatica in Area di Ricerca. Nelle prime lezioni ho cercato di convincere i partecipanti che ormai gli attacchi informatici sono un vero e proprio business e quindi non devono essere considerati come una attività ludica-o-quasi. A tale scopo ho esposto i risultati di alcuni studi recenti molto interessanti sulla "underground economy" del settore....Ho inserito anche alcune slide (leggermente più tecniche) sul malware in generale. Consiglio caldamente un'occhiata all'argomento "Botnet: Torpig case study", a partire dalla numero 44. Mostra che questa botnet sostituisce tutti i programmi dei computer infettati, compresi i  browser...

lunedì 13 maggio 2013

Concretezza

Io stimo più il trovar un vero, benché di cosa leggiera, che 'l disputar lungamente delle massime questioni senza conseguir verità nissuna.

Galileo Galilei

(altre "WordsOfWisdom": http://reti-inginf-units.blogspot.it/search/label/WordsOfWisdom)

giovedì 9 maggio 2013

L'attacco più bello degli ultimi anni

Questo è uno degli attacchi più belli e più istruttivi degli ultimi anni:


Stealthy, malware-spewing server attack not limited to Apache


someone is replacing legitimate web server software with binaries containing the Cdorked backdoor, but exactly how they're doing it remains a mystery.

In parole poverissime, il codice sorgente di alcuni tra i web server più diffusi è stato modificato in modo fraudolento; adesso contiene del codice che:

  1. effettua, in modo nascosto, redirection verso siti che tentano di iniettare malware;
  2. è controllabile, in modo nascosto, da remoto;

Questo attacco è "bello" perché nessuno ha ancora capito come faccia l'attaccante a modificare il codice del web server, e perché il funzionamento del codice fraudolento incorpora numerose tecniche per renderne complicata la rilevazione. Sono elencate nell'articolo: solo alcuni utenti subiscono la redirection, secondo un pattern "inexplicable"; un utente che è stato rediretto può non essere rediretto nuovamente; etc

E' anche un attacco molto "istruttivo" perché dimostra in modo lampante il problema più radicale e più evidente di tutti i marchingegni informatici. Problema di cui però, purtroppo, pochi hanno coscienza, nonostante sia un problema molto semplice da capire---non occorre avere grandi competenze tecniche.

Il problema è che ogni calcolatore può eseguire azioni fraudolente in modo completamente nascosto al suo proprietario. Può farlo attraverso software di cui il proprietario non sospetta neanche la presenza, oppure attraverso software che dovrebbe fare una cosa e invece ne fa un'altra. Ergo, ogni calcolatore può essere un nemico.

Ciò non è una "possibilità teorica", ma un fenomeno concreto e diffuso. Sia sul lato client (vedi ad esempio questo post) sia, come si vede in questo caso, sul lato server.

Le implicazioni di questi dati di fatto sono enormi.

lunedì 6 maggio 2013

Posso crittare i dati nel cloud ?

Questo è complicato da leggere ma ne vale la pena (per aggiornarsi).
IBM takes a big new step in cryptography: practical homomorphic encryption
In breve, i servizi di cloud storage (come Dropbox, Box, Google Drive, Microsoft Skydrive etc etc etc) memorizzano i dati degli utenti "in chiaro", cioè senza crittarli. Ciò è un problema enorme per molte categorie di utenti ed organizzazioni. Dati potenzialmente sensibili, o comunque rilevanti per l'organizzazione, diventano accessibili al provider del servizio e soprattutto possono diventare accessibili se un attaccante riesce a "bucare" il servizio. In altre parole, la difesa principale nei confronti del furto dei dati (crittare i dati) non può essere applicata nei servizi di cloud.

In linea di principio l'utente potrebbe crittare i propri file con una chiave nota solo a lui, e poi potrebbe memorizzare sul cloud i dati crittati. In questo modo però il servizio di cloud non potrebbe effettuare nessuna operazione. Neanche una semplice ricerca testuale---sul cloud ci sarebbero infatti dati crittati. Ogni operazione dovrebbe essere fatta sulla macchina dell'utente, sui dati decrittati.

Le limitazioni di questo approccio sarebbero enormi. Senza contare il fatto che, in pratica, crittare il contenuto dei file sarebbe addirittura troppo poco, in quanto un eventuale attaccante avrebbe visibile la struttura in directory, nome dei file etc---informazioni che in molti casi possono essere sufficienti per lo scopo dell'attacco. Sarebbe cioè necessario crittare completamente il filesystem, nascondendo all'attaccante anche la struttura in directory. In tal caso però il servizio di cloud non potrebbe neanche elencare il contenuto di una directory---non saprebbe neanche quali e quante directory o file esistono.

La cosiddetta "homomorphic encryption" è uno strumento che permette di rivoluzionare il tutto e risolvere proprio problemi di questo genere. Con questa tecnica crittografica, il servizio di cloud storage può fare ricerche sui dati crittati ed ottenere i risultati corretti (!)---sto ultrasemplificando e scrivendo cose inesatte, solo per descrivere l'idea. Io ho i dati, il servizio di cloud storage ha i dati crittati (che non sa come decrittare) ma può eseguirci sopra operazioni per me utili.

La cosa ovviamente è enormemente complicata---visto che il servizio di cloud storage può usare utilmente i dati crittati, come fare in modo che non possa farlo anche un attaccante ? quali utilizzi sono praticamente possibili ?

L'articolo citato descrive in modo sommario la faccenda e lo stato attuale dell'arte, così come implementato in un software open source rilasciato da IBM.

giovedì 2 maggio 2013

What is the real difficulty in hacking Internet banks ?

La notizia riportata qui sotto descrive in modo interessante un dato di fatto ben noto:

  1. Il vero problema non è prendere il controllo di un conto corrente;
  2. il problema è riuscire a spostare i soldi senza generare trasferimenti anomali.

Da un altro punto di vista:

  1. il vero problema non è superare le difese tecnologiche dell'Internet Banking;
  2. il problema è superare i controlli tradizionali, effettuati in background e a posteriori.

Il che dice molto sulla vera natura delle tecnologie moderne per la sicurezza informatica.
  • Organized hackers in Ukraine and Russia stole more than $1 million from a public hospital in Washington state earlier this month.
  • roughly $133,000 of the lost funds have been recovered so far,....
  • ...the attack occurred on Apr. 19, and moved an estimated $1.03 million out of the hospital’s payroll account into 96 different bank accounts,... 
  • ..."Take the $9,180 just deposited into his account and send nearly equal parts via Western Union and Moneygram to four individuals, two who were located in Russia and the other pair in Ukraine. After the wire fees — which were to come out of his commission — Contreras said he had about $100 left over."...
http://krebsonsecurity.com/2013/04/wash-hospital-hit-by-1-03-million-cyberheist/