2. Abbiamo visto
Cifrari simmetrici (AES, DES, Cesare)
Cifrari asimmetrici (RSA, EC, DH, PGP)
Blockchain
Infrastrutture PKI
TLS
eIDAS, TSP, Qualified Certificates
E soprattutto, concetto di CIA, e IA&A
3. Operazione Black Tulip
2011: Janam Fadaye Rahbar (I will sacrifice my soul for my leader) 竪
entrato nella CA Diginotar.nl
Il 10 di luglio ha generato 300 certificati, fra cui *.google.com,
*.microsoft.com, tutti revocati, except one
Il 28 agosto, un utente ha riportato su un forum di google un
certificate warning .
(https://support.google.com/mail/forum/AAAAK7un8RU3J3r2JqFNTw
/?hl=en&gpf=d/category-topic/gmail/share-and-discuss-with-
others/3J3r2JqFNTw)
4. Black Tulip
Per oltre un mese mail.google.com in Iran, e in alcune provincie
statunitensi 竪 stato sotto attacco MITM
Chrome of
the user
Fake
Gmail
Gmail
5. Operazione Black Tulip
Lattaccante ha avuto accesso a DNS di larga scala in Iran,
probabilmente tramite ARP spoofing, o tramite un accesso a una
tavola di routing di un ISP
Lattaccante per due mesi ha fatto un MITM di larga scala,
intercettando le password degli utenti, e generando 300.000 richieste
OCSP.
Questo 竪 solo un suggerimento: non sappiamo quanti utenti sono
stati compromessi
6. 3 problemi
Diginotar non ha ha riportato immediatamente lattacco n辿 ai suoi
clienti n辿 ai governi, mettendo a rischio la privacy di milioni di
cittadini (2 mesi di delay)
Errori nellimplementazione HTTPS: i truststore (ad esempio
Microsofts certificate store) hanno fiducia in troppe CA
Diginotar non ha mai richiesto un audit di terze parti (no antivirus,
password di amministrazione deboli, no log), ma prendeva la
sicurezza in maniera seria (iso 27k)
Sarebbe possibile oggi un attacco come questo?
7. Forse no
La GDPR impone una immediata disclosure dei security breaches
eIDAS definisce il concetto di 束reti chiuse損
eIDAS definisce le caratteristiche tecniche e legali per i 束Trusted
Service Providers損, per cui i servizi pubblici serviti non ricadrebbero
nella compromissione di come Diginotar
(Attenzione: Diginotar era stata certificata da ETSI TS 101 456 e ETSI TS 102
042)
8. Il modello CA e la scalabilit
Pi湛 una CA 竪 grande, pi湛 竪 alto il rischio di attacco
I server OCSP e le CRL diventano un unico punto di fallimento
HTTPS 竪 difficile da usare
Riferimenti:
Operation Black Tulip: Certificate Authorities lose authority (ENISA)
https://www.eff.org/deeplinks/2011/03/iranian-hackers-obtain-fraudulent-https
https://www.eff.org/deeplinks/2011/08/iranian-man-middle-attack-against-google
https://www.eff.org/it/deeplinks/2011/09/post-mortem-iranian-diginotar-attack
https://slate.com/technology/2016/12/how-the-2011-hack-of-diginotar-changed-the-
internets-infrastructure.html
9. SAML e JWT
Ritorniamo alla definizione di IA&A
Identificazione, processo in cui si ritorna vero o falso (la persona in
possesso di queste credenziali, 竪 Massimiliano Masi? Come mi fido?)
Something that you have
Something that you know
Something that you are
Context
Autenticazione, traduzione del processo di identificazione in un token
elettronico
Autorizzazione, uso del token di autenticazione per accedere
10. SAML e JWT
Identificazione: username/password, VPN, certificato, pin
Autenticazione: username/password, SAML, Kerberos, JWT
Autorizzazione: username/password, XACML, bit di unix, Role Based
Access Control
Username e password sono ovunque (ma in alcuni casi troppo deboli)
11. SAML e JWT
SSO: Single Sign On: una volta identificato, creo un token di
autenticazione che 竪 valido e fidato da diverse parti
Una volta fatto login su lufthansa.com, posso, con lo stesso account
miles&more prenotare una macchina e un albergo
Identificato una volta, autenticato n e autorizzato m.
12. Excursus: firme XML
XMLDSG fornisce uno standard per la firma di un documento in
formato XML (standard W3C)
13. XMLDSG: Esempio Enveloped Signature
Input: un formato XML
Si passa attraverso un c14n (canonicalization) algorithm per poter
creare un hash in modo univoco (XML sono sintatticamente uguali
anche se lessicalmente diversi)
Si calcola lhash sha256
Si cifra con la chiave privata
Si crea un xs:Id per lelemento firmato e si mette in un riferimento
Si mettono tutte queste informazioni in un SignedInfo
14. XMLDSG Validazione
Chi valida fa loperazione inversa
Trasforma lXML in forma canonica (rimuovendo i dati di supporto di
XMLDSG)
Cerca il riferimento xs:Id
Calcola lhash, e lo confronta con il DigestValue
Decifra lhash della firma e valida il SignedInfo
Problema. XML Signature Wrapping (XSW) (vedi SOAPFirmato.xml)
16. Excursus: Prudent Engineering Practices
Abadi e Needham (due colossi della sicurezza) hanno scritto un
articolo 束milestone損 nel disegno e la scelta di protocolli di sicurezza:
https://www.cs.utexas.edu/~shmat/courses/cs380s/prudent.pdf
Elenca 12 principi di sicurezza, che si possono definire in 2 grandi
insiemi
Every message should say what it means its interpretation should
depend only on its content
The conditions for a message to be acted upon should be clearly set
out so that someone reviewing a design may see whether they are
acceptable or not
17. Abadi e Needham
Principio 3: If the identity of a principal is essential to the meaning
of a message, it is prudent to mention the principals name
explicitly in the message
Andrew Gordon di Microsoft Research ha pubblicato un altro articolo
fondamentale: https://www.microsoft.com/en-us/research/wp-
content/uploads/2016/02/secure-sessions-sws.pdf
Definisce un framework per la sicurezza di servizi web (e un tool da
scaricare, TulaFale)
18. SAML
Security Assertion Markup Language (SAMLv2) definisce un
meccanismo standard per scrivere e ottenere una asserzione di
sicurezza
Una asserzione (o token) 竪 uno statement su un processo di
identificazione avvenuto nel passato che garantisce il SSO
Un token ha un
Issuer: the identity provider
Authentication Context: how the subject has been authenticated
Subject: the identity of the assertion
Attributes: additional identity attributes (e.g., role)
19. SAML
SAML usa XMLDSG per fornire autenticit e integrity
La firma 竪 quella dellIdP
SAML (come tutti gli standard WS-*) sono aperti: fornisce un
framework per limplementazione dei principi di Abadi&Needham,
ma questi devono essere comunque definiti. Usare SAML di per s辿 竪
solo un punto di partenza!
Un token SAML realizza SSO in diversi domini in base al trust model
(lezione 1).
20. JWT
SAML 竪 basato su XML. Essendo tipato gli errori sono molto minori
In un ambiente RESTFul luso di XML 竪 considerato 束anacronistico損
Nascita di OAuth2.0: framework basato su REST per ottenere un
generico token
Usato da Facebook, Google, Linkedin, etc. etc.
Sopra OAuth2.0 竪 nato OpenID che fornisce ulteriori servizi per
linteroperabilit
Chiunque pu嘆 usare Facebook o Goole per lautenticazione ->
incoraggiato
21. JWT
OAuth2.0 竪 agnostico al token: 竪 relativamente facile da
implementare, e il token 竪 consumabile solo dal dominio stesso.
impensabile usare un token emesso da Facebook per accedere ad
un servizio google -> siamo regrediti rispetto a SAML?
Si: https://hueniverse.com/oauth-2-0-and-the-road-to-hell-
8eec45921529
Per ottenere linteroperabilit 竪 stato introdotto Json Web Token
(JWT)
22. JWT
Basato su JSON (e quindi non tipato) ha lo stesso scopo di un token
SAML
Definito in tre parti: un Header, un Payload e la sua Firma
See JWT.io
23. Attacco di Armando
Definito durante il progetto di ricerca europeo AVANTSSAR
Formal Analysis of SAML 2.0 Web Browser Single Sign-On: Breaking
the SAML-Based Single Sign-One for Google Apps
http://www.avantssar.eu/pdf/publications/saml-sso.pdf
25. Che cosa abbiamo visto?
Violazione del principio di sicurezza 3
DNS spoofing
Mancanza di fiducia nella CA
TLS da solo non basta, qualunque sia la ciphersuite usata (simmetrica,
o asimmetrica)
Lattaccante 竪 onnipotente (Dolev Yao)
Se lidentificazione fallisce, anche A&A falliscono
Da sola la CIA non basta
26. E ora vediamo BURP!
Dopodich辿, grazie per lattenzione in queste lezioni