DROWN: Atacando SSL/TLS (V)

1, DRWN-5
CapturaDROWN: Atacando SSL/TLS (IV)

Lo siguiente será manifestar el #valor# de #serverwritekey#, para intentarinferir cuál es el #masterkey# que hemos mandado al <servidor>. La solución pasa por lafuerza bruta“.

Recordad que en losprimeros artículos os decía que el #masterkey# estaba #parcialmente encriptado#, de tal forma que enciertas situacionesuna parte del #masterkey# puede ser enviado por el <atacante> en claro, fijando el #valor# como mejor le convenga, y el mensaje <c1> representaúnicamentela parte <cifrada> del #master key#.

En concreto, si el <atacante> “negociaunalgoritmo de cifrado– “EXPORT, el tamaño de la <parte cifrada> del #masterkey# es de40 bitsy por tanto el <atacante> sólo tiene que “probar un máximode 240 valores diferentes de #masterkey# hastaconseguirencontrar uno con el quecalculacomo #serverwritekey# –una clave que le permite <descifrar> el dato devuelto en #ServerVerify#- y obtener elchallengeenviado inicialmente.

Por lo cuál, el #valor# asignado a laparte cifradadel #masterkey# es el #valor# de <m1>.

Con todo esto y como <m1> y <m0> estánrelacionadosa través de <s>, puede calcular <m0>, que era el #premastersecret# de lacomunicación” #SSLv3/TLS# y con los #tres valores# conocidos, ya puede <calcular> lasclaves simétricasy <descifrar> la comunicación, ¿Cierto?

Pues la respuesta (yparafraseandode nuevo es) que va a ser que No.. Ya sería demasiada <casualidad> que elatacantehallara a la primera un <s> que le convierta un #valor# <m0> de “48 bytesen un #valor# <m1> de5 bytes” (los40 bits– <cifrados> del #masterkey# en los <algoritmos> #EXPORT#). En verdad, lo más verosímil es que el <m1> que ha usado vuelva a tener una longitud no correcta (la probabilidad de que un #valor# <s> por casualidad nos devuelva un <m1> válido es inferior a 1 entre 33 millones-).

4, DRWN-5

Lo que pasa es que la mayoría de losmétodos– (medidas) actuales de #SSLv2# (ironías del destino llamar actual a unaimplementación de #SSLv2#) incluyen #protección# contra un <ataque> conocido como el <oráculo de Bleichenbacher>. Un <servidor> que reciba un #masterkey# delongitud incorrecta– <genera> deforma aleatoriaun #masterkey# y lo utiliza en lugar del enviado por el cliente, pero continúa todo el procesamiento de la misma manera.

Como se responsabiliza que el clienteno será capaz de derivarla <clave correcta> (ya que no conoce el #masterkey# utilizado por el <servidor>), lacomunicaciónserá <incorrecta> y finalizará.

2, DRWN-5

Si tenemos en cuenta que cadamensajeprobado implicahasta 240 operaciones de <descifrado> paraconseguirlaclavepor #fuerza bruta#, será conveniente mejorar de formadrásticalas probabilidades de encontrar un <m1> válido.

·|Recapitulando

<Resumiendo un poco todo esto>; la situación parte de queexisteun mensaje <m0> que se conoce como #premastersecret# que contiene #información# sobre laclave simétricausada en unaconexión” #SSLv3/TLS#, del que sólo conocemos <c0>, que es elmensaje cifradocon laclave pública” #RSA# del <servidor>.

También habéis visto que esposiblederivar a partir de <c0> un mensaje <c1>, que es laversión cifrada de un mensaje <m1>, y que conociendo la relación entre <c0> y <c1> (que es un #valor# escogido por elatacante y al que llamamos <s>), conocemos también la relación entre <m0> y <m1>, por lo que si seconsiguedescubrirel #valor# dem1”, podemos calcular <m0>, a partir de él lasclaves simétricasde la conexión #SSLv3/TLS# y <descifrar> la #comunicación#. Elobjetivoahora mismo esencontrarun <m1> que sea aceptado como #masterkey# por un <servidor> #SSLv2# que comparta la clave #RSA# con el <servidor> #SSLv3/TLS# original.

El <problema radica> en que escogiendo un #valor# <s> alazarla posibilidad de conseguir que el mensaje <m1> seaaceptadocomo #masterkey# por el <servidor> #SSLv2# es inferior a1 entre 33 millones-, y que se necesita aplicar <240 operaciones> dedescifradotan sólo para saber si <m1> es un #masterkey# o no, lo que hace que esta <aproximación> no pueda ser realizada.

Será necesarioaumentar las posibilidades de éxito en lugar de elegir #valores# de <s> por casualidad. Para esto, hay queanalizarcómo se <cifran> tanto #premastersecret# (SSLv3/TLS) como #masterkey# (SSLv2). Ambos datosno se cifran directamentecon #RSA# sino que para <aumentar> laseguridad del cifrado“, se formatean de tal manera que se les añade #información# de forma aleatoria antes de <cifrarlos>. Dicho formato es conocido como “PKCS#1 v1.5” y tiene la siguiente estructura, veamos:

5, DRWN-5

Losbytesen rojo son <fijos>, mientras que losbytes marcados en azul son los <datos> que estamoscifrando-. Losbytesmarcados en verde actúan de relleno. El número debytesde relleno depende del tamaño de la clave #RSA# usada pero será como mínimo <8>. Para el caso de una clave #RSA 2048#, eltamaño totalserá de256 bytes“. Estosbytes tomarán un #valor# aleatorio pero siempre distinto de <0>, ya que de lo contrario se podría confundir con el separador entre el relleno y los datos que se están <cifrando>.

Aún nos queda mucho más, lo dejamos para el <próximo> #artículo#.

Salu2

commodore64

Anuncios

Responder

Por favor, inicia sesión con uno de estos métodos para publicar tu comentario:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s