lunedì 26 aprile 2010

Posta Elettronica Certificata (PEC)

In questi giorni si sente parlare spesso di "Posta Elettronica Certificata".

Si tratta di messaggi email esattamente come quelli che abbiamo visto a lezione, ai quali sono però associati degli attachment che costituiscono una "firma digitale" del messaggio.

La firma digitale viene trattata nella seconda parte del corso. Essenzialmente, utilizza tecniche crittografiche per garantire che il contenuto del messaggio firmato sia autentico (generato veramente da chi afferma di averlo generato) ed integro (non sia stato alterato neanche un bit).

Il funzionamento di questa tecnologia e le ipotesi su cui si basa saranno discussi ampiamente nella seconda parte del corso.

A titolo di cronaca, che non ha nulla a che vedere con il corso, può essere utile dare un'occhiata a questo mio post sul blog del mio laboratorio.

giovedì 22 aprile 2010

Risultati Prima Provetta

Tra pochissimi minuti metterò in bacheca al DEEI i risultati (non li espongo su Internet perché forse qualcuno potrebbe sollevare obiezioni di privacy).

Chi non può venire al DEEI per molto tempo per favore cerchi di contattare qualche amico. Se proprio non ci riesce, mi contatti per email.

La provetta potrà essere visionata durante la lezione di martedi prossimo e del martedi successivo. Chi non segue più (3 CFU) venga per favore in aula al termine della lezione. Chi non può venire a lezione mi contatti per email.

Per favore non vi presentate nel mio ufficio chiedendo di visionare la provetta (sono state consegnate 92 provette).

Alcune (piccolissime e marginali) note sulla valutazione
  • Molti hanno risolto l'esercizio che richiedeva di elencare i mail server fornendo solo il nome, oppure solo l'indirizzo IP. Io avrei voluto entrambi, ma la formulazione dell'esercizio era effettivamente ambigua. Pertanto non ho penalizzato.
  • Molti hanno risolto l'esercizio che richiedeva di elencare i mail server fornendo solo parte dell'elenco, omettendo cioè alcuni server identificabili nel testo. Ho applicato una penalizzazione bassissima, quasi trascurabile.
  • Alcuni hanno svolto la conversione Base64 solo per la parte iniziale della stringa oppure hanno commesso errori di calcolo su uno o due caratteri. Non ho applicato penalizzazioni.
  • Alcuni hanno indicato i nomi degli header HTTP in modo erroneo, ma con un significato chiaramente corretto. Non ho applicato penalizzazioni.

Informazioni sugli errori frequenti/significativi sono nel post precedente.

Altre informazioni utili e curiosità:





venerdì 16 aprile 2010

"Come guadagna Google ?"

Ne avevamo parlato pochi giorni fa a lezione.

Sono appena uscite informazioni interessanti:

Google's Q1 earnings show continued ad growth

Google continues to demonstrate that an online advertising recovery is well under way...

For its fiscal first quarter, which ended March 31, Google reported revenue of $6.77 billion, up 23 percent from the same period last year.


mercoledì 14 aprile 2010

"Execution of arbitrary code by a remote attacker"

Come ho detto in una delle ultime lezioni di Complementi, il CERT emette con regolarità scoraggiante "advisory" contenenti le paroline magiche ("The impact of these vulnerabilities includes execution of arbitrary code by a remote unauthenticated attacker").

(il primo di ieri ed il secondo di oggi...)

Update successivo di pochi minuti:

lunedì 12 aprile 2010

Testare le vulnerabilità del proprio PC

Uno studente (Maurizio Pozzobon) mi ha segnalato un servizio interessante per fare l'analisi delle vulnerabilità del proprio sistema. Si tratta di Shields Up, uno dei services resi disponibili da Gibson Research (https://www.grc.com).

Attenzione però. Con Gibson Research si dovrebbe stare tranquilli, in quanto è un nome molto noto (tra l'altro sono quelli che qualche anno fa scrissero una cronaca molto appassionante di un attacco Distributed Denial of Service di cui furono bersaglio; il link a questa cronaca si trova da qualche parte sul mio My Library @ Evernote). In generale, comunque, fare testare le vulnerabilità del proprio sistema da un agente remoto non è una operazione da fare a cuor leggero.
  1. Con chi sono collegato ?
  2. Come faccio ad essere certo che sono collegato veramente con chi penso di essere collegato ?
  3. Cosa sta facendo il suo sw sul mio sistema ?
  4. Come faccio ad essere certo che se trova una vulnerabilità sul mio sistema poi non la sfrutti (o non la scriva in un qualche DB per poi rivenderla in un qualche mercato di hacker) ? ...
I software fasulli di sicurezza sono infatti una delle ultime mode, molto redditizie per gli attaccanti...

mercoledì 7 aprile 2010

"Sniffata" HTTP su mail di ateneo

Uno studente di Reti I (Alfredo Canziani) mi ha inviato una "sniffata" di traffico HTTP ottenuto quando si autenticava da casa al servizio webmail di ateneo. Ha provato con Internet Explorer, senza riuscire ad autenticarsi, e con Firefox, riuscendo ad autenticarsi. La cosa è interessante anche perché il lato server sembra Microsoft.

Il traffico (lungo e prolisso) si trova qui.

Ci sono alcuni aspetti interessanti per Reti II, tra i quali:
  1. Firefox supporta veramente NTLM;
  2. il valore "Negotiate" per lo header "WWW-Authenticate" non significa "mettiamoci d'accordo ed usiamo uno dei valori dei WWW-Authenticate seguenti" (il significato che avevo detto a lezione); significa invece "mettiamoci d'accordo, se scegli questo valore ti elenco i meccanismi che supporto in aggiunta a quelli che ho già elencato nei WWW-Authenticate seguenti". E' stato proposto da Microsoft per l'interazione con i propri web server. Tipicamente viene usato per l'autenticazione Kerberos su HTTP ma può essere usato anche per NTLM. Permette cioè di "incastrare" Kerberos con HTTP; non ho approfondito se si tratti della variante safe, private o insomma. Maggiori dettagli:
  • http://www.ietf.org/rfc/rfc4559.txt
  • http://msdn.microsoft.com/en-us/library/ms995329.aspx
Qualche commento sul traffico sniffato:
  • Il server risponde dicendo: ti devi autenticare, io supporto 3 meccanismi: Negotiate, NTLM, Basic;
  • Firefox sceglie NTLM e dopo lo scambio "solito" riesce ad autenticarsi
  • IE sceglie invece Negotiate e non riescono a mettersi d'accordo (!). Il che è singolare perché il server è Microsoft ed il browser è Microsoft, pertanto dovrebbero essere in grado di mettersi d'accordo.
Non so perché non riescano a mettersi d'accordo, sospetto che il motivo sia questo:
  • Il client (per come è configurato) se gli viene proposto Negotiate allora lo sceglie;
  • Il server è stato configurato in modo che quando il client chiede Negotiate, allora il server accetta solo Kerberos;
  • Questo particolare client non supporta Kerberos e quindi non si mettono d'accordo.
Altro esempio di quello che dico spesso: per capire le reti bisogna sforzarsi di guardare alla realtà con molta elasiticità. altrimenti non si capisce nulla di nulla...la realtà è troppo complicata per la presenza di molti dettagli concettualmente irrilevanti.

sabato 3 aprile 2010

Attacchi ai sistemi VoIP

Attacco Man-In-The-Middle alle funzionalità di billing dei sistemi VoIP. Sfrutta il fatto che non tutti i messaggi SIP (protocollo HTTP-like usato nei sistemi VoIP) sono autenticati; e l'integrità è garantita solo su parti dei messaggi. E' cioè un attacco sul protocollo, non sulla crittografia o sulle vulnerabilità software (quindi sfrutta vulnerabilità intrinseche al progetto, non all'implementazione del progetto).

Questo articolo è interessante per la descrizione degli attacchi ed anche per la descrizione del funzionamento di SIP.

...we analyze several deployed SIP-based VoIP systems, and present three types of billing attacks: call establishment hijacking, call termination hijacking and call forward hijacking. These billing attacks can result in charges on the calls the subscribers have not made or overcharges on the VoIP calls the subscribers have made.

1.Zhang, R., Wang, X., Yang, X. & Jiang, X. On the Billing Vulnerabilities of SIP-based VoIP Systems. Computer Networks In Press, Accepted Manuscript,

http://www.sciencedirect.com/science/article/B6VRG-4YCWNPD-2/2/b1bfdcd59ac1b12a72a63deedd5faf03


(accessibile dalla rete di ateneo)