POODLE y REST APIs

Poodle es, como se presenta, un ataque de texto sin formato elegido , aunque no en una gran cantidad.

En su núcleo, la vulnerabilidad sobre la que se basa Poodle permite que un atacante activo intente adivinar un solo byte de datos de texto simple. Las condiciones son las siguientes:

• La transmisión utiliza SSL 3.0 con el cifrado realizado con un cifrado de bloque en modo CBC.
• El valor de byte en el que está interesado el atacante es parte del flujo y se produce al final de un bloque (los bloques tienen una longitud de 8 bytes con 3DES o RC2, 16 bytes con AES).
• Un registro posterior en el flujo (en la misma dirección) tiene una longitud que implica un relleno de bloque completo.
• La conjetura tiene una probabilidad de 1/256 para funcionar. Si falla, la secuencia de SSL se interrumpe, y tanto el cliente como el servidor lo saben.

Entonces, en la práctica, la situación debe ser tal que el atacante pueda activar las conexiones SSL de manera silenciosa y organizar las cosas de manera que se envíe un "secreto interesante" a través de la conexión en un lugar predecible, y el atacante también debe poder modifique el tamaño de los datos enviados para que cada "byte interesante" aparezca al final de un bloque, y también se produzca un registro con relleno de bloque completo. Vale la pena señalar que el atacante debe elegir la longitud de algunos elementos del mensaje, pero no necesita controlar el contenido (por eso es solo un CPA honoris causa ). Además, cada conexión rota no debe activar alertas demasiado visibles.

Un navegador web que ejecuta Javascript hostil y está conectado a Internet a través de puntos de acceso WiFi controlados por un atacante cumple todas estas condiciones. Lo más probable es que su aplicación que no sea de navegador no lo haga.

Sin embargo, realmente deberías usar TLS 1.0 (o, mejor aún, TLS 1.1 o 1.2). Ahora, el lado positivo es que el protocolo de enlace SSL / TLS está protegido contra los ataques de degradación del protocolo: si el cliente y el servidor siguen los estándares , los atacantes no pueden obligar a un cliente y servidor que ambos saben que TLS 1.0 recurre a SSL. 3.0. Desafortunadamente, los navegadores web han adquirido el desagradable hábito de trabajar alrededor de los estándares precisamente para usar SSL 3.0 en caso de falla con TLS 1.0. En ese sentido, los navegadores son débiles para Poodle porque insisten en ser débiles; favorecen el soporte continuo de un puñado de servidores antiguos que no se han actualizado desde el siglo pasado, en lugar de evitar que el usuario sea hackeado más allá de todo reconocimiento.

El problema real, sin embargo, es que el cliente y el servidor aún aceptan el uso de SSL 3.0, aunque ambos saben que es débil. Más sobre ese tema aquí . Deshabilitar el soporte SSL 3.0 y concentrarse en TLS 1.0 (que ya usa en la práctica) no es algo que deba hacer debido a Poodle; Es algo que debes hacer porque es hora de pasar de las herramientas de piedra al metal. ¡Abraza la Edad de Bronce antes de que sea demasiado tarde!

POODLE es el último clavo en el ataúd de SSLv3. Este problema es un error de diseño y no un error de implementación, como lo fue Heartbleed. Como es un defecto de diseño y es básicamente un protocolo muerto, nunca será "arreglado". Pasar a TLS es su única opción para no ser vulnerable a POODLE.

Entonces, sí, su aplicación que no es de navegador también es vulnerable a POODLE. Sin embargo, un atacante debe estar en la misma red que su aplicación o cliente para realizar el ataque MiTM requerido y debe poder activar muchas solicitudes del cliente al servidor para poder explotar realmente la vulnerabilidad de POODLE. Dependiendo de la situación exacta que puede o no puede hacer la explotación muy poco probable.

Dicho esto, es hora de pasar de SSLv3: plan para desactivarlo y pasar a TLSv1.2.