martes, 21 de octubre de 2014

POODLE: cuando la retrocompatibilidad de versiones se vuelve peligrosa

Por Pablo F. Iglesias
Iba a escribirlo en plan guía técnica sobre el funcionamiento de esta vulnerabilidad, pero al ver el fenomenal trabajo que han hecho por Genbeta (ES) explicando el sistema de paring, creo que mejor enlazo a su artículo y trato por aquí todo aquello que no han resuelto, opinión personal incluida.
¿Qué es POODLE y en qué me afecta?
Para ponernos en antecedentes, POODLE es el nombre con el que en la madrugada del día de ayer se dio a conocer una vulnerabilidad que afecta a una versión específica del protocolo de comunicaciones seguras cliente servidor. En este caso, y para diferenciarnos del Heartbleed, hay que dejar claro que la vulnerabilidad afecta únicamente al cliente (los servidores no pueden ser atacados), y debido a su modus operandi, no es tan crítico como lo fue este o lo ha sido recientemente Shellshock.
Para realizar una comunicación segura con una página web o servicio), el cliente (esto es, el usuario normalmente) llama al servidor estableciendo una negociación para conectarse mediante un protocolo seguro. El servidor responde con la versión del protocolo última que tiene, y entre los dos, buscan la versión adecuada para hacer la comunicación. A día de hoy casi todos los clientes y servidores funcionan por TLS v1.2, pero precisamente para evitar posibles contratiempos, se ha permitido la retrocompatibilidad de versiones antiguas hasta llegar incluso a SSL v3.0, que podemos considerar la primera de todas (SSL v1.0 nunca se publicó, y la SSL v2.0 apenas duró un año en circulación por errores de desarrollo), desarrollada hace nada más y nada menos 15 años.
De esta manera, el ataque debe seguir tres pasos, que unidos permiten la escucha en claro de lo que el cliente y el servidor se están pasando, como pueden ser credenciales de usuario, datos bancarios de una transacción, comunicación supuestamente privada…
¿Cómo funciona POODLE?
El primer paso, es forzar al servidor a utilizar la versión SSL v3.0, pese a que tanto el cliente como el servidor son seguramente capaces de utilizar versiones más modernas. La forma que tiene normalmente de realizarlo es mediante un script en javascript que puede estar alojado en una página web corrompida. El cliente envía la petición y va denegando todas las versiones posteriores hasta llegar a la SSL v3.0, que es con la que establece la comunicación.
En el segundo paso, entra en juego la verdadera vulnerabilidad, y es que por la arquitectura del cifrado utilizado en SSL v3.0 (RC4, o CBC), se vulnera de una u otra manera, pudiendo leer la información. El cifrado continuo RC4 ya apenas se usa, y de hecho, se conoce que es vulnerable desde hace tiempo. La mayoría por tanto funcionan mediante un cifrado por bloques CBC, basado en el sistema de paring, que Genbeta lo explica en detalle (no apto para no técnicos), y que básicamente se trata de forzar unos bytes de pareado que nos permiten “contar” la información que navega supuestamente cifrada en cada paquete enviado.
El tercer paso, sería establecer un man in the middle que permitiera aprovecharse de esta vulnerabilidad. Es muy importante dejar claro que sin este paso, todo lo anterior no ha servido de nada, por lo que POODLE, por sí mismo, no presenta un problema de seguridad crítico, sino un vector de ataque más de los múltiples utilizados para el robo de información, volviéndose peligroso sobre todo en WIFIs públicas. Se necesita por tanto tiempo (realizar paring no es algo que se haga en segundos) y tener un canal alternativo para controlar la situación. Gracias al MITM, el atacante puede utilizar POODLE para leer la comunicación, saltándose por tanto el protocolo seguro.
¿Cómo evitarlo?
Aquí viene lo bueno. Al ser un ataque de cliente, queda en nuestra mano contrarrestarlo, y para este caso en particular, resulta realmente sencillo.
Bastaría con que bien el cliente (nosotros), bien el servidor, forzara a utilizar como mínimo una versión TLS, algo que se puede hacer mediante el forzado de TLS_FALLBACK_SCSV (EN) (sobre todo con vistas a servidores), instalando una extensión (EN), o más cómodo aún, realizando los siguientes ajustes:
En el caso de Chrome:
Si estamos en Windows, bastaría con cerrar Chrome, botón derecho en el botón del escritorio, Propiedades, y en acceso directo > ruta de destino, incluir al final de todo –ssl-version-min=tls1 (con un espacio entre la ruta .exe y este código).
Si estamos en OS X, abría que crearse un script con AppleScript que contuviera lo siguiente: open -a /Applications/Google\\ Chrome.app –args –ssl-version-min=tls1.
Para Firefox, bastaría con teclear en la barra de búsqueda about:config, buscar security.tls.version.min, y cambiarle el valor de 0 a 1.
En el caso de Internet Explorer, depende un poco de la versión, pero al menos en IE 9,10 y 11 habría que ir a herramientas > Opciones de internet. Abrir la configuración Avanzada y desactivar el checkbox donde aparece Uso de SSL 2.0 y Uso de SSL 3.0. Pongo igualmente una screen para los despistados.
En el caso de Safari para OS X, Apple ha puesto a disposición un parche (Security Update 2014-005) que da solución al fallo, desactivando el modo-CBC en SSL v3.0. Está disponible para su descarga tanto en Mavericks (EN), como en Mountain Lion (EN), y Yosemite (EN).
Podemos comprobar si ya no somos susceptibles de ser atacados en los siguientes enlaces: Para clientes: poodletest.com (EN). Para servidores: poodlebleed.com (EN).
¿Qué podemos aprender de POODLE?
Pues que a veces la retrocompatibilidad de versiones puede salirnos cara. Hablamos de un protocolo de hace 15 años que sigue pudiéndose elegir como alternativa para algo tan crítico como establecer una comunicación segura.
Cuando la seguridad manda, hay que dejar de lado la benevolencia y obligar a actualizar los sistemas. Que yo sepa, únicamente los usuarios de Internet Explorer 6 (y si los hay inferiores) tendrían problemas. Y si así fuera, me parece totalmente correcto que se les fuerce a actualizar, que ya es hora :).
Todas las soluciones de seguridad con la huella digital las encuentra en: https://sites.google.com/site/inbiosys/
Queremos mejorar cada día más, necesitamos que usted nos regale dos minutos de su precioso tiempo y nos conteste 5 preguntas de la encuesta que le traemos hoy.
Click Aquí para comenzar la encuesta
En INBIOSYS tenemos todas las Soluciones en Seguridad Informática, basada en la Huella Digital
NUESTROS PRODUCTOS
Somos la primera Empresa en el país en "Soluciones de seguridad para préstamos de libros utilizando la huella digital"
Puede seguirnos en Twitter. Follow inbiosys on Twitter
Puede seguirnos en Facebook.
Visita nuestra página en Facebook
INBIOSYS Biometria
INBIOSYS
Jairo Alonso Gómez Cano
Gerente Comercial
https://sites.google.com/site/inbiosys/
http://inbiosys.wordpress.com/
E-mail: inbiosys@gmail.com
PBX: (57)(4) 583 13 31
Celular: 312 782 60 21

INBIOSYS
Ingeniería y Sistemas Biométricos
Carrera 81 No. 43 - 72 Oficina 1109
Medellín Colombia
Publicado por en
Etiquetas: , , , , , , ,
Ubicación: Carrera 81 No. 43 - 72 Of. 1109, Medellín, Antioquia, Colombia

No hay comentarios:

Publicar un comentario

Suscribirse a: Enviar comentarios (Atom)