4. Crypto Goofs
¿Cuando?
“La seguridad es como una cadena, que se rompe
por su eslabón más débil”
• Cualquier interacción esta dando información.
• Es muy arriesgado dejar escapar información.
• No es buena idea cifrar parcialmente las comunicaciones:
• El uso mixto de HTTP/HTTPS permite incluso comprometer las
comunicaciones seguras.
• Muchas vulnerabilidades de TLS/SSL derivan de la negociación en plano.
• La experiencia demuestra que el cifrado parcial tiene demasiadas
implicaciones. Los protocolos de red mixtos generalmente terminan
liándola parda.
• Actualmente cualquiera con cara y ojos no se plantea usar algo que
no sea HTTPS.
RootədCON 2018
4
5. Crypto Goofs
¿Cuando? [Ejemplos]
• Robo de sesiones HTTP/HTTPS
• Se protegen las credenciales, pero no las acciones.
• Se intenta optimizar mezclando contenidos HTTPS (sesiones, acciones),
pero se desprotege el código JavaScript
• SSL Stripping
• Existencia del mismo servicio en dos versiones distintas (HTTP/HTTPS).
Se mitiga con HSTS (HTTP Strict Transport Security)
• IIS/FTP STARTTLS command injection
• En IIS 7.0/7.5 es posible inyectar comandos junto al mensaje STARTTLS,
que se ejecutarán en la sesión cifrada
• Skinny/RTP: llamada entre un teléfono cifrado y otro no cifrado
• MySQL (BACKRONYM):
• Los de MySQL pensaron que en caso de fallar la conexión TLS/SSL la
mejor solución por defecto es saltar a plaintext.
• https://github.com/duo-labs/mysslstrip/blob/master/mysslstrip.py
RootədCON 2018
5
6. Crypto Goofs
¿Quien? ¿Qué?
• La criptografía tienes tres objetivos:
• Confidencialidad
• Integridad
• Autenticidad
• Y deben proteger algo para alguien.
• Los algoritmos por sí mismos no los garantizan ninguno de ellos.
• Los protocolos son la madre del cordero
• No tienen porque tener relación con la red.
• Es un conjunto de reglas que rigen un acto donde todos los actores y
posibles estados están formalmente especificados.
• Self-enforcing protocols son los ideales
• Es muy importante seguir El Principio de Horton:
Authenticate what is being meant, not what is being
said.
RootədCON 2018
6
7. Crypto Goofs
¿Quien? ¿Qué? [Ejemplos]
• Un error típico es no ver con claridad entre el qué y el quien en
comunicaciones con varios participantes:
• Algunas antiguas bancas electrónicas enviaban las credenciales por
HTTPS desde el navegador al frontal web. ¿Realmente el frontal web
necesita ver las contraseñas de los usuarios?
• Autenticación en plano, sin desafío-respuesta.
• Correo electrónico.
• Se cifra el sistema de archivos de la base de datos, pero las filas
siguen estando disponibles a un usuario.
• TLS/SSL - SSLv2, SSLv3 – Cipher-suite rollback attacks derivados
de no seguir bien El Principio de Horton.
RootədCON 2018
7
8. Crypto Goofs
¿Dónde, cómo? ¿Dónde como? ¿ein?
• No se debe ser creativo, a no ser que sepas lo que estás haciendo:
• La criptografía es muy compleja: una pequeña mala decisión puede
comprometer todo un protocolo.
• No te compliques la vida: no por ser más complicado es más seguro.
• Desconfía de los secretos.
• Piensa que todo participante, incluido el propio plaintext puede
actuar en contra de los algoritmos, del protocolo y de ti:
• Cada decisión debe ser detenidamente sopesada.
• Cuanto más simple, más fácil es de analizar por un atacante, pero
también por ti.
• Cada algoritmo usado debe ser estudiado, conocer sus debilidades y
limitaciones.
• Piensa en todos los casos de uso, pero no olvides ninguno de abuso.
RootədCON 2018
8
9. Crypto Goofs
¿Dónde, cómo? ¿Dónde como? ¿ein? [Ejemplos]
• IPSec – Buena intención, pero varios cripto analistas lo califican de
desastre:
• AH/ESP: cifra y luego firma. El problema es que ESP es independiente de
AH, por lo que se podría realizar una inyección Cut-and-past.
• De hecho hay muchas configuraciones donde sólo se usa ESP, por lo que
no hay autenticación.
• Pero meter autenticación (AH) hace que no se pueda usar fácilmente por
internet.
• Complejidad demasiado alta:
• Interacciones inesperadas, difícil de visualizar todos los riesgos (The Complexity
Trap).
• Es difícil configurarlo y usarlo correctamente.
• ¿Por qué tantos modos de trabajo?
RootədCON 2018
9
11. Crypto Goofs
Los números aleatorios
• Los números aleatorios son una de las pieza clave en la criptografía.
• Muchas veces se obvia su importancia ya que a priori un RND es
algo aparentemente fácil de conseguir.
• Fácilmente se cae en el error de infravalorarlos.
• Hay tres tipos de números aleatorios:
• Números aleatorios
• Números pseudo-aleatorios
• Números tontunos
RootədCON 2018
11
12. Crypto Goofs
Los algoritmos (1/2)
• Aleatorios:
• Son muy lentos de conseguir.
• No siempre son tan aleatorios como parecen.
• Necesitamos muchas fuentes de aleatoriedad. Por suerte el ordenador
está repleto de subsistemas indeterministas (sarcasmo).
• /dev/random
• Números pseudo-aleatorios:
• Son sistemas retroalimentados que se enriquecen con puntual
información aleatoria.
• El algoritmo es importante, aunque todos se basan en algo similar a esto:
10 X = EAT SOMETHING RANDOM
20 FOR(N = 0; NOT_TIRED || N << THE_PERIOD_OF(H); N++)
30 PRINT X
40 X = H(X)
50 NEXT
60 GOTO 10
RootədCON 2018
12
13. Crypto Goofs
Los algoritmos (2/2)
• Números pseudo-aleatorios (continuación):
• Referentes:
• Mersenne Twister
• xorshift generators
• WELL
• /dev/urandom
• Números tontunos
• Internet está repleta de algoritmos que los generan.
• Algunos son verdaderas triunfadas, y son una combinación que beben de
los Linear Congruential Generators y se alimentan de:
• int rand(void);
• int gettimeofday(struct timeval *tv, struct timezone *tz);
• Y no sólo los aficionados la lían:
• Debian en 2008 mejoró openssl limitando el número de claves TLS a 32768
(¿para que necesitamos más?)
• Un estudio de 2012 sobre las claves públicas presentes en Internet relevó que
había en ese momento unas 25000 factorizables y repetidas.
RootədCON 2018
13
14. Crypto Goofs
Los algoritmos [Ejemplo]
RootədCON 2018
14
WIKIPEDIA
IBM's RANDU is widely considered to be one of
the most ill-conceived random number generators
ever designed[2], and was described as "truly
horrible" by Donald Knuth.
• Basado en el algoritmo LCG (Linear
Congruential Generator)
uint32_t RANDU() {
static int seed = 1;
return seed = (65539*seed) &
0x7FFFFFFF;
}
Proyección 3D “bien elegida”Proyección 2D
“
15. Crypto Goofs
La guinda del pastel: sesgado
• Muchas veces no necesitamos un número de 0 a 2^(n-1), cuando
vete a saber que barbaridad es n
• Yo solo quiero sacar una valor entre 0 y 2. Tengo una función muy
rara que devuelve entre 0 y 10.
• Solución estándar:
int valor = mi_random_raro() % 3;
• Implicaciones:
rand(x) % 3 == 0, x = { 0, 3, 6, 9 } => P(0) = 4/11
rand(x) % 3 == 1, x = { 1, 4, 7, 10 } => P(1) = 4/11
rand(x) % 3 == 2, x = { 2, 5, 8 } => P(2) = 3/11
• Normalmente la solución es:
• o bien trabajar con un valor congruente M (MAX_RAND % M == 0)
• o bien descartar valores:
do {
x = rand();
} while (x >= (RAND_MAX - RAND_MAX % n));
x %= n;
RootədCON 2018
15
17. Crypto Goofs
Los bloques
• Los algoritmos de cifrado funcionan por bloques habitualmente
• Esto implica que los mensajes deben descomponerse en bloques, los
cuales posteriormente son cifrados de forma secuencial.
• Existen los stream ciphers, pero con cuidado. Se reservan normalmente a
hardware.
• Como se encadenan los bloques se conoce como Modo de operación.
• Actualmente el modo más usado es GCM (Galois/Counter Mode).
• Sólo para bloques de 128 bits e incluye función de HMAC.
• Hash algo débil (se conocen weak keys). No apto para largas transmisiones.
• El tamaño SÍ importa:
• Bloques pequeños
• Normalmente es un error cualquier cosa igual o menor a 64 bits.
• Paradoja del cumpleaños -> SWEET32.
• Se facilitan los Encryption Oracles.
• Bloques grandes
• Demasiado grandes.
• No caben en los algoritmos. Tampoco en otros sitios.
RootədCON 2018
17
18. Crypto Goofs
Modos de operación
RootədCON 2018
18
ECB
Eres una Calamidad y un Burro
Usarlo es un pecado
CBC
Cipher Block Chaining
Puede ser susceptible a ataques de
padding
PCBC
Propagating Cipher Block Chaining
Dos bloques adyacentes pueden
intercambiarse
OFB
Output Feedback
Similar a un stream cipher
El IV es crítico
Ci = Ek(Pi)
C0 = Ek(IV Pi)
Ci = Ek(Ci-1 Pi)
C0 = Ek(P0 IV)
Ci = Ek(Pi Pi-1 Ci-1)
I-1 = IV
Ii = Ek(Ii-1)
Ci = Ek(Ii-1) Pi
19. Crypto Goofs
Vectores de inicialización: la eterna discusión
• A cero o constantes, es igual, la hemos pifiado.
• Igualmente jamás debe ser escogido por el usuario.
• Es el problema más común al examinar código fuente.
• Tan recurrente que la ficha que suelo hacer ya parece la Wikipedia.
• Depende del modo de cifrado, reusarlos puede ser devastador:
• Es uno de los problemas que tenía WEP (en OFB o en stream ciphers
jamás se puede repetir la secuencia)
• En CBC nos puede permitir saber si dos streams son el mismo o
comienzan igual, y a partir de que bloque difieren.
• Además en CBC un IV malo es útil para crear Encryption Oracles (si
conocemos parte de P0, o es fijo, podemos ir pidiendo cifrados para que
coincida con algo en concreto:
Ek(0 P0) = Ek(Q)
• En CFB nos encontraríamos esto (y se nos quedaría cara de gilipollas):
C0 = Ek(IV) P0
RootədCON 2018
19
¡OJO!
IMAGEN
INÉDITA
20. Crypto Goofs
Vectores de inicialización [Ejemplo]
• Los documentos Office (hasta Office 2003), usaban RC4:
• RC4 usa un mecanismo similar a OFB para cifrar.
• Excel y Word usaban el mismo IV cuando guardabas un fichero.
• Esto implica que gran cantidad de texto plano reutiliza tanto la clave
como el IV.
• El resultado es que hace posible recuperar e inferir mucha información
entre dos versiones del mismo fichero y del stream sin tener información
de la clave.
• En WEP (cifrado RC4) el vector de inicialización es constante.
• Al cabo de 5/7 horas se repetía el key-stream.
• El ataque BEAST:
• Aprovecha que viendo cualquier bloque cifrado podemos predecir el valor del próximo IV.
• Esto permite inyectar en las comunicaciones bloques que sean operaciones del estilo:
Cn = Ek(Cn-1 Cn-1 Cx-1 Px O)
= Ek(Cx-1 Px O) ¿=? Cx
RootədCON 2018
20
21. Crypto Goofs
La clave
• Escogerlas/generarlas es un acto solemne.
• La mejor clave, la que no hace un humano.
• No todas las claves sirven.
• Los algoritmos sufren de claves débiles, muchas veces en silencio.
• No tener claves débiles es un objetivo de diseño, aunque a veces hay
sorpresas que se van descubriendo.
• En DES hay claves intercambiables o que al aplicarse terminan entregando
un cifrado igual al texto plano.
• En Blowfish existen ciertas claves que dan lugar a S-Boxes débiles.
• En IDEA ciertos textos planos pueden dar información sobre algunas claves.
• A pesar de ello deben ser altamente aleatorias.
• O debemos usar mecanismos de derivación de claves.
• No es buena idea someterlas a limitaciones (ver DES).
• A no ser que nos guste reducir el espacio de claves.
RootədCON 2018
21
23. Crypto Goofs
Funciones de hash
• Las funciones de resumen no generan firmas ni
tampoco códigos de autenticación
• Se debe enmarcar su uso en un protocolo
criptográfico.
• Por si solas son solo algoritmos criptográficos.
• Se suele referir a ellas como función H(x)=h,
donde encontrar una x tal que devuelva h sea
prácticamente imposible.
• ¡No! CRC no es una hash criptográfica.
• Tienen muchos usos:
• Generar el fingerprint de un texto plano.
• Comprimir un valor muy grande en otro pequeño.
• Encadenarse.
• Y usarse mal.
RootədCON 2018
23
24. Crypto Goofs
Almacenamiento de contraseñas [Ejemplo]
• Es tradición encontrarse esto:
Password_hash = H(password)
• Esto presenta varios problemas:
• Todas las contraseñas tendrán la misma hash.
• Una contraseña que extienda otra pasará por un estado intermedio.
• Se puede precalcular muchos estados y atacar con rainbow tables.
• Si la función de hash está rota puede encontrarse un valor x tal que H(x)
= H(p) y no necesariamente P = X. Muchas veces eso ya nos vale.
• Recomendación
• Nosotros no nos fiamos ni un pelo de las funciones de hash a pelo.
• Por eso se me notan las entradas.
• Es mejor usar algoritmos especializados como bcrypt, scrypt, en su
defecto PBKDF2.
• Si aún se insiste, en última instancia se recomienda:
h = H(salt1 . p . salt2)
RootədCON 2018
24
25. Crypto Goofs
MAC vs HASH
• MAC significa Message Authentication Code:
• Va más allá de una función de hash. Aunque termina usando una.
• Ya no es un simple algoritmo, puede considerarse un protocolo.
• Si está bien diseñado fortalece una función de hash introduciendo varías
restricciones que harán más difícil un abuso de la misma.
• Parten de una expansión de la clave que aumenta su entropía.
• Protegen de ataques de extensión.
• En el caso de que un atacante dispusiese de un Oráculo que pudiese firmar
cualquier mensaje o disponer de la clave secreta, una función MAC garantiza
que no será posible calcular un mensaje que devuelva un cierto MAC.
• Aún así una función MAC no es la panacea:
• Hay que seguir El Principio de Horton.
• No se debe compartir nunca la clave de MAC con la clave de cifrado.
• Es tradicional intentar usar funciones de HASH como MAC.
RootədCON 2018
25
26. Crypto Goofs
CBC-MAC [Ejemplo]
• Ejemplo perfecto de como NO debe construirse un algoritmo MAC.
• Favorece a que se reutilicen claves de cifrado.
• Sufre de debilidad de extensión, es decir, podemos partir de un
cierto CBC-MAC y continuar con él otro texto más largo.
• Esto en algunos casos puede servir para entregar un mensaje más largo a
una función de validación que sólo tiene en cuenta los primeros bloques.
• Os acordáis de esto?
Cn = Ek(Cn-1 Cn-1 Cx-1 Px O) = Ek(Cx-1 Px O)
• Podemos usarlo para insertar nuevos bloques:
• Tenemos bloques Cn y Cn+1
Cn = Ek(Cn-1 Pn) Cn+1 = Ek(Cn Pn+1)
• E insertamos esto:
Cm = Ek(Cn X)
Cm+1 = Ek(Cm Y) = Ek(Cm Cm Pn Cn-1) =
= Ek(Pn Cn-1) = Cn+1
RootədCON 2018
26
27. Crypto Goofs
¿Cuando MACear?
RootədCON 2018
27
Se abre la veda a ataques de texto
plano sobre data.
La integridad del texto plano puede ser
verificada.
No se garantiza la integridad del
cyphertext.
No se si tiene nada de bueno.
No podemos verificar la integridad del
mensaje cifrado m.
Pero se garantiza la integridad del
contenido data.
El MAC ya no puede ofrecer ningún
tipo de información, ya que no es
visible. Aumenta la entropía de m.
La firma va con el texto plano, sin el
contexto de cifrado.
Ojo con el fenómeno surreptitious
forwarding: un mensaje de Alice para
Bob puede ser recifrado por él con el
fin de que Charlie crea que era el
verdadero destinatario.
Integridad en el cyphertext m. Sólo
leeremos mensajes auténticos.
Integridad en el texto plano data.
No nos hemos de preocupar por la
maleabilidad del algoritmo de cifrado.
El MAC no da información sobre el
plaintext.
La firma/MAC obliga que el mensaje
permanezca en el contexto de cifrado.
Naïve Encrypt-then-Sign: ¡podemos
firmar algo que viene cifrado de
alguien o fuera de contexto!
m = c . MACkf(c)
c = Ckc(data) m = Ckc(data . MACkf(data)) m = Ckc(data) . MACkf(data)
29. Crypto Goofs
No todo es lo mismo
• No todos los algoritmos son iguales
• RSA es útil para firmar y cifrar.
• DSA/ECDSA sirve para firmar.
• Diffie-Hellman es útil para el intercambio de
claves.
• Y cada uno tiene sus cosas:
• RSA es “sencillo” de usar, pero necesita un camión
para transportar las claves.
• DSA/ECDSA es muy seguro, y ECDSA se usa
actualmente de forma intensiva, pero tiene que
usarse con mucho ojo (o nos marcan un PS3).
• Diffie-Hellman no protege contra el Man-in-the-
Middle.
• Hay que conocer el objetivo de cada algoritmo y
sus limitaciones.
RootədCON 2018
29
30. Crypto Goofs
RSA - Uso con padding débil
• Es común ver este algoritmo usado al desnudo.
• La operación es c = md mod N, y m = ce mod N, por lo que
aprovechando propiedades de ℤ 𝑛
se puede operar con el resultado.
• Esto no sucede en los algoritmos simétricos.
• En este caso, si el contenido es predecible o tiene un padding horrible
aparecen los side-channel.
• Si es predecible, y además es una operación de clave pública, pensemos
que la operación se puede replicar.
• Un padding malo puede devolver un c más pequeño que N
(especialmente en operaciones con clave pública).
• Esto implica resolver la raíz e-ésima de c, sin tener en cuenta el módulo.
• Por lo que elegir un buen padding es crítico.
• PKCS#1 < v2.0 está afectado por diversas debilidades.
• OAEP es el estándar recomendado actualmente
RootədCON 2018
30
31. Crypto Goofs
RSA - Las claves
• El uso de un buen RNG es clave
• Si tenemos dos claves N = p . q y N’ = p’ . q’, y existe la posibilidad de p’ =
p, entonces la clave está comprometida calculando el GCD(N, N’).
• Mala composición:
• Una mala composición de la clave, siendo p <<< q podría poner en riesgo
el sistema.
• Obviamente p q tampoco es buena idea (el espacio de búsqueda queda
restringido a algo cercano a la raíz cuadrada de N).
• Calcular p y q que sean quasi-primos con una alta probabilidad:
• Podría darse el caso de una clave multi-primo.
• Siendo especialmente problemático el caso en que N = p1.p2...pN, siendo
algunos de esos factores pequeños.
RootədCON 2018
31
32. Crypto Goofs
RSA - Claves parejas
• Generalmente se cree que RSA sólo funciona con dos claves: una de
cifrado y otra de descifrado.
• Es falso: existen fenómenos derivados de los mecanismos
matemáticos que usa que permite la existencia de diversas claves.
• Supongamos este sistema RSA:
p = 37, q = 41, n = 1517, Φ(n) = 1440, e = 13, d = 997
e = 13: 100113 mod 1517 = 1088
d = 997: 1088997 mod 1517 = 1001
• Pero fijémonos en esta sorpresa:
d' = 277: 1088277 mod 1517 = 1001
d' = 637: 1088637 mod 1517 = 1001
d' = 1357: 10881357 mod 1517 = 1001
mcm((p-1), (q-1)) = 360!!!!
• Y lo mismo pasa con la clave pública!
• Siempre tenemos que buscar un par p y q que minimice el número de
claves parejas.
RootədCON 2018
32
33. Crypto Goofs
RSA - Malos usos (1/2)
• Usar el mismo par para firmar y cifrar:
• Nos la colaran a la primera distracción: o firmaran algún ciphertext y lo
descifraran, o cifraran algún hash y obtendrán nuestra firma.
• Es mala idea firmar el mensaje, no el resumen:
• El atacante crea dos mensajes aparentemente inofensivos m1 y m2.
• Nosotros que somos unos buenazos los firmamos:
fm1 = RSAd(m1)
fm2 = RSAd(m2)
• El atacante realiza una simple multiplicación y obtiene la firma de m:
fm1 . fm2 = m1
d . m2
d = md = fm
• Reciclar p y q para generar varias claves privadas:
c1 = me1 (mod N)
c2 = me2 (mod N) -- Siendo e1 y e2 primos relativos
r.e1 + s.e2 = 1
c1
r . c2
s = me1.r . me2.s = me1.r + e2.s = m1 (mod N)
RootədCON 2018
33
34. Crypto Goofs
RSA - Malos usos (2/2)
• Firmar y codificar, nunca al revés:
• Alice usa RSA para mandar y firmar un mensaje a Bob:
A --> B: RSAeB(m), RSAdA(RSAeB(m))
• Entonces Bob puede escoger un mensaje arbitrario m’,
y usando los factores de su clave, calcular el logaritmo
discreto x del mensaje de Alice:
m’x = m mod NB
• Ahora Bob tiene que exponer (xe, NB) como su clave
pública, para que la gente piense que m’ es de Alice:
RSAdA(RSAxe(m’)) = RSAdA(RSAeB(m))
• Este ataque tiene ciertas limitaciones en la forma de xe
y dimensiones de NB, pero es posible.
RootədCON 2018
34
35. Crypto Goofs
Algoritmos asimétricos, con cuidado
• Con DSA (y ECDSA) hay que ser extremadamente cuidadoso con la
K. Minuto de silencio por la Sony PS3.
• Con Diffie-Hellman se debe tener en cuenta la paradoja del
cumpleaños, y la manía de olvidar que no protege contra MitM.
• Con RSA aún nos queda tener en cuenta que hay mensajes que no
se pueden cifrar, aunque la probabilidad sea baja.
• Son operaciones matemáticas complejas, los timing attack y otros
side channels están a la orden del día.
• Son lentos. Lentos a rabiar. Ojito donde los metemos.
• Conclusión: al ser matemática modular hay muchos detalles que
pueden implicar un fracaso completo. Se debe ser muy cuidadoso y
seguir al detalle las buenas prácticas.
RootədCON 2018
35
36. Crypto Goofs 36
Confidential information for the sole benefit and use of PwC’s client.
Quote attribute
JOB TITLE
36
Espero que os haya
gustado.
¿Preguntas?
“
36
RootədCON 2018
Crypto Goofs