DROWN: Atacando SSL/TLS (VII+I)

·|Razones para efectuar este <Ataque>|·

Tal y cómo terminamos el #anterior artículo# (y os comenté), a continuación veremos lasrazonesque hanimpulsado a este <ataque> y cómo ha sido posible:

– – #-> Aún hay <servidores> que ofrecen la posibilidad deutilizar” <protocolos inseguros> (para con este ejemplo; #SSLv2#).

<-# – – Sencillamente por: <falta de cuidado> (interés), #reducción de gastos o sencillez de gestión#, se estánreutilizando claveso inclusocertificados completosen <servidores> distintos.

– – #-> Las <implementaciones> de #SSLv2# no esperan aautenticar al clientemediante el paquete #ClientFinished# antes deenviarel #ServerVerify#. Esto habría impedido el <ataque> ya que el clientetendría que demostrarquesabe” (conoce) la <clave simétrica> antes de recibir la #información# que le permite conseguirla por <fuerza bruta>. Esto es algo que ya se “prohíbede forma <explícita> en #SSLv3/TLS#.

<-# – – El “problemadediseñoque implica tener <criptografía> voluntariamente debilitada (los <cifrados> #EXPORT#) en unsistema de cifrado-. Incluso aunque lasrestricciones de exportaciónde <criptografía> se levantaron (en su mayoría) en elaño 2000“, todavía siguen causando problemas.

La manera dedefendernuestra <infraestructura> de cara a esteataquees simple: No utilizar nunca #SSLv2#.

Hablamos (y nos referimos) de un <protocolo> con más de20 años de viday que al cabo de un añopoco más-, tras aparecer, ya tenía un sustituto (SSLv3) que además representaba un “rediseño desde cero. Pero, esto no debe hacer que caigamos en el placer de utilizar #SSLv3# o incluso #TLSv1.0#.

También disponen de sus propiosproblemasyes necesarioque realicemos la migración a #TLSv1.1# ó #TLSv1.2# de forma inmediata. Además, habrá que estar atentos aldiseñoque se lleva a cabo actualmente de #TLSv1.3#.

<Reutilizar> lasclaves asimétricasno es una muy buena #idea# y deberíaevitarsesiempre que sea posible.

·|Puntoscríticos en este <Ataque>|·

A continuación, podéis ver que existendos puntos– <críticos> en este #ataque#:

– – #-> El <servidor> #SSLv2# debepermitir la utilizacióndealgoritmos” #EXPORT# en lacomunicación“, ya que en caso dealgoritmosque no lo sean, el <coste computacional> delalgoritmoesexcesivo-.

<-# – – El <atacante> deberomperpor <fuerza bruta> elcifradode un <algoritmo> #EXPORT# en un tiempo razonable (lo que implica <240 operaciones criptográficas>).

La primera de lasopciones” (opuntos-) resulta la más #importante# y la que más #seguridad# nos ofrece. Sencillamente basta condeshabilitarlosalgoritmos” #EXPORT# en nuestro <servidor> (quetal vezya se encuentren <deshabilitados>) y con eso debería bastar para protegernos ante #DROWN#, ¿verdad? Pues, cabe laposibilidadde que lo más probable sea que no.

El <riesgo> que seasociapara con estepuntoes la <vulnerabilidad> #CVE-2015-3197#, queafectaa versiones de #OpenSSL# anteriores a #1.0.1r# y #1.0.2f# (en función de laramaque estemos utilizando). Para que podáis entender (y comprender) sufuncionamientodebemos volver al <protocolo> de #handshake# usado en #SSLv2#, y que ya hemosmencionadoen los #anteriores artículos# (veamos laversión– “realistaimplementada por los <servidores> #SSLv2# más habituales):

1, DRWN-8

Cuando se mostró (y vimos) elataque– #DROWN# general os expliqué este <proceso> de negociación desde elpunto de vistade losdatos cruzadospara <generar> las #claves simétricas#. A pesar de ello, en esteprocesotambién senegociael <algoritmo de cifrado> a usar. Esta #información# se cruza en lossiguientes paquetes-;

– – #-> El clientesugiere unalistadeposibles algoritmosa usar en el <paquete> #ClientHello#.

<-# – – El <servidor> –sugieresu <propia lista> dealgoritmosautilizaren el <paquete> #ServerHello#.

– – #-> Elclienteelige unalgoritmo comúnentre los sugeridos porambas partesy <envía> suelecciónen el <paquete> #ClientMasterKey#.

<-# – – El <servidor> –calculalasclaves simétricas asociadas al <algoritmo> seleccionado por elclientey <envía los datos de verificación> #cifrados# con dichoalgoritmo” en el <paquete>- #ServerVerify#.

Lavulnerabilidadde #OpenSSL# que <analizamos> en este momento consiste en que el <servidor> no comprueba que el algoritmo seleccionado por el cliente se encuentre en la <lista de algoritmos> sugeridos por él. Por lo cuál, dicha <negociación> continúa unprocesocomo el siguiente que os mostraré el #próximo artículo#.

Salu2

tumblr_myiza6Plri1qgp7iko5_400

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