Lo comentaba ayer en el CIGTR (ES), en plena efervescencia, y para variar, me quedé con ganas de dedicarle un artículo completo.
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.
Índice de contenido
¿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. hoy en día 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.
- 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).
- 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 :).
Edit a día 18 de Octubre: Por petición de un lector, pongo la manera de protegernos en Internet Explorer.
Edit a día 20 de Octubre: Por petición de un suscritor, pongo los enlaces a los parches que ha liberado este fin de semana Apple para usuarios de OS X y Safari.
Hola pablo, al realizar el consejo que das en tu articulo en crhome 64 bit bajo win 7 ultimate, no me deja realizarlo avisandome de que la ruta no es correcta. En cambio en crhomiun, lo acepta perfectamente. ¿ que estoy haciendo mal ?. Observo que en Crhome el destino es el siguiente “C:\Program Files (x86)\Google\Chrome\Application\chrome.exe”, entrecomillado en cambio en Crhomium C:\Users\Pau\AppData\Local\Chromium\Application\chrome.exe -ssl-version-min=tls1, no lleva estas comillas. Probe a quitarlas en crhome pero no me deja. A ver si tienes la gentileza de ayudarme. Gracias amigo
¿y has probado a incluirlo con el espacio dentro de ellas? La verdad es que normalmente es sin comillas, pero oye, lo mismo justo esa versión las utiliza por alguna razón.
Si no es solución, pues me pongo a navegar por internet buscándola, que no tengo ningún dispositivo con Windows 7 para hacer la prueba (soy de los locos que vive con Windows 8.1, y tengo por ahí un portátil viejete con el XP sin acceso a internet :P).
Conseguido amigo en los 4 Crhome, Chromiun, firefox e IE 11. Eres la caña XD. Muchísimas gracias pablo. Me has echo INVULNERABLE….. jajajajajajajaaj
Jajajaja ¡Me alegro! Ahora a seguir usando el sentido común, que este es un vector más de los múltiples por donde nos pueden atacar 😛
Hola pablo. De nuevo vulnerable al realizar el tes sin haber tocado nada en los 4 navegadores. Increíble… ¿ que ha pasado ?
Y entiendo que sigues entrando con el mismo enlace que contiene el código insertado ¿verdad? Fíjate a ver si es que se te han actualizado, y de paso, te han borrado la configuración jajaj.
Lo que no te pase Pau… xD
Hola pablo buenos días. Si si, no he tocado nada, el firefox esta actualizado, pero mire la configuración recomendada por ti y esta intacta, acabo de comprobarlo en todos los navegadores de nuevo ( recien iniciado el equipo )y sigo siendo vulnerable. No comprendo nada
Y yo tampoco… Mira que por si acaso he probado con los míos y siguen tal cual… ¿Te das cuenta de haber instalado algo estos días?
En principio el cambio se hace una única vez y ya puedes olvidarte…
Si solamente instale el Backup Thunderbird y actualice a avas2015 ¿ puede ser esta la causa ?. Ahora que recuerdo detecte el fallo horas mas tarde de haber instalado la versión nueva del antivirus
Hombre, el antivirus debería ayudar, no ser el problema, pero quién sabe, jeje.
Ten en cuenta que el antivirus es quizás de las herramientas que más permisos tiene del sistema. Si hay alguna herramienta externa que puede saltarse protecciones del propio navegador, esa es sin duda el antivirus.
No sé qué decirte Pau. Antes de todo, probaría a volver a realizar los cambios (es decir, volver a ponerlo vulnerable, guardar, y volver a realizar los pasos para securizar cada navegador), por si hay suerte y se reescribe.
Si no es la solución y te sientes con fuerzas, desinstála el antivirus o vuelve a una versión anterior de tu sistema (donde todavía no habías instalado la actualización), reinicia, limpia de nuevo el sistema (los antivirus dejan muchísima mierda dentro), confirma que los cambios en el navegador siguen bien y prueba a ver si es el problema. Y si es instala otro antivirus, jajaja.
La putada es que con desinstalarlo es posible que no tengamos la certeza de que si la culpa es de él, se haya solucionado. Con la cantidad de librerías que modifican puede que justo lo que necesitamos se quede sobreescrita…
Si “C:\Program Files (x86)\Google\Chrome\Application\chrome.exe -ssl-version-min=tls1” pero me sigue dando el mismo aviso de error. El nombre “C:\Program Files (x86)\Google\Chrome\Application\chrome.exe -ssl-version-min=tls1”, aplicado en el cuadro de destino no es valido. Compruebe que el nombre del archivo y la ruta de destino son correctos. Ademas cuando teste con poodletest.com con crhomium que si me acepta la instrucción, me aparece el caniche diciendo que sigo siendo vulnerable. Con firefox perfecto. Gracias y disculpa las molestias
Fíjate que no hayas escrito -ssl-version-min=tls1 por –ssl-version-min=tls1. La diferencia estriba en que el segundo (el correcto) tiene un guión distinto (no el habitual con el que escribimos).
Al menos en mi caso, probado en Windows 8.1 y Chrome 64bits, funciona…
Hola pablo, he cambiado el guión en Chrome 64 ya que en efecto use el guion normal
(ahora esta así : –ssl-version-min=tls1) -y sigue sin funcionar dándome el mismo error. En chromiun si,lo acepta con ambos guiones ( uso tambien el que me recomiendas ) pero al testear sigue siendo vulnerable. No se lo que sera. Pero trank, tampoco deseo acerté perder tanto tiempo, cuando puedas si quieres lo miras. Gracias por tu interés amigo
Venga, sigamos probando cosas, jaja. Prueba a poner –ssl-version-min=tls1 (con dos guiones seguidos la primera vez, que en WordPress no se muestra). Y si no traga, a colocar algo tal que así –args –ssl-version-min=tls1 (con dos guiones seguidos tanto antes de args, como de ssl), donde especificamos que tenga en cuenta el argumento. También probaría a cambiar las comillas dobles por comillas sencillas (no debería ser el problema pero por si acaso), o incluso por comillas rectas (las que usan los ingleses y americanos). Si no ya no se me ocurren alternativas…
Antes que nada darte las gracias Pablo. No se que decir. Si te refieres a ‘C:\Program Files (x86)\Google\Chrome\Application\chrome.exe ––args––ssl-version-min=tls1’ y a ‘C:\Program Files (x86)\Google\Chrome\Application\chrome.exe ––ssl-version-min=tls1’, no funciona ninguna de las dos. «C:\Program Files (x86)\Google\Chrome\Application\chrome.exe ––ssl-version-min=tls1’» y usando la comillas inglesas en ambos casos tampoco y. No se si esta bien escrito. Te reitero las gracias y el interés. Un abrazo amigo
Lo de –args era por probar. En la shell de Unix se suele utilizar, pero en Windows no. Pues no sé que más decirte Pau. No encuentro ningún comentario por internet de gente a la que le haya pasado. En principio para incluir parámetros debería ser fuera de las comillas dobles, es decir:
“C:Program Files (x86)GoogleChromeApplicationchrome.exe” ––ssl-version-min=tls1
En algunos casos lo he visto con el doble guión inicial, en otros con el guión largo (que suele escribirse con el doble guión) y en otros con el sencillo. Pero el formato debería ser ese.
Es más, fíjate que este tutorial (EN) lo hacen exactamente igual que como te comento (¿Porque no será que lo estás escribiendo en Empezar en y no en Destino verdad?)
A ver si algún lector puede arrojar más luz al asunto.
Saludos!
“C:\Program Files (x86)\Google\Chrome\Application\chrome.exe” ––ssl-version-min=tls1 ahora si, lo ponía dentro de las comillas. Ya lo coge, pero https://www.poodletest.com/, me dice:
If you see a poodle below, then your browser supports SSLv3 and you maybe vulnerable. If you see a Springfield Terrier below, your browser doesn’t support SSLv3.
The image may take a bit time to appear. The test requires JavaScript. Earlier versions of this site did show recent Firefox versions as non vulnerable. Turns out, that these versions of Firefox do support SSLv3, but will not accept an SSLv3 server that supports ciphers usually only associated with TLS. (e.g. ECDHE). I am now only using weaker ciphers on my SSLv3 server, and Firefox should now connect via SSLv3.
So in short: Firefox is less likely to downgrade to SSLv3 if the server follows best practices on cipher selection, even if SSLv3 is still supported.
Creo que es por esto que ne firefox, navego seguro:
POODLE Test
If you see a poodle below, then your browser supports SSLv3 and you maybe vulnerable. If you see a Springfield Terrier below, your browser doesn’t support SSLv3.
The image may take a bit time to appear. The test requires JavaScript. Earlier versions of this site did show recent Firefox versions as non vulnerable. Turns out, that these versions of Firefox do support SSLv3, but will not accept an SSLv3 server that supports ciphers usually only associated with TLS. (e.g. ECDHE). I am now only using weaker ciphers on my SSLv3 server, and Firefox should now connect via SSLv3.
So in short: Firefox is less likely to downgrade to SSLv3 if the server follows best practices on cipher selection, even if SSLv3 is still supported.
Android 4.2.2 may show as non-vulnerable even though it is. Still investigating. Muchas gracias
Madre mía. Si ves, al final era una tontería.
¿Pero en el test te sigue apareciendo un perro que te dice que eres vulnerable (es una broma con el nombre que le han puesto a la vulnerabilidad)?
Piensa que para que el ataque surja efecto, además de tener que montar un MITM, hay que suplantar funcionalidades en el cliente, y normalmente se hace vía JavaScript. Si no tienes JavaScript habilitado, básicamente eres inmune al ataque (por ejemplo la mayoría de SO móviles actuales son inmunes por esta misma razón).
Hola Pablo:
Si en el test sigue sigue apareciendo un perro que te soy vulnerable, pero el javascript lo tengo activo. ya que si lo desactivo no podre ver la mayoría de paginas ( casi todas por no decir todas ) que lo usan. En firefox lo tengo habilitado tambien y siguiendo tu consejo about:config, buscar security.tls.version.min, y cambiarle el valor de 0 a 1., el perro me aparece como no vulnerable
¿Y supongo que has cerrado todos los procesos abiertos de Chrome y vuelto a abrirlos verdad? O reiniciado el ordenador.
Ya no debería salirte si en verdad está tomando ese parámetro, ya que lo que hace es forzar conexiones TLS. Por debajo de esas, directamente devuelve error.
Si claro he reiniciado el ordenador, pero en chrome y en chromium, sigo siendo vulnerable. Increíble pero cierto. En firefox sin embargo no. No lo entiendo sinceramente. ¿ puede ser que tenga dos usuarios en win 7 uno como administrador REAL y otro como admin de fabrica y el proceso lo realice desde este ultimo en lugar del primero ?
Pero entonces afectaría a Firefox también. Raro raro… :).
Cierto. desde aquí puedes ver los pantallazos en ambos navegadores:
http://paucompany.es/upload4/. Un saludo y gracias por el constante interés, y espero disculpes el tiempo que te robo. Un abrazo pablo
Por dios. Por un amigo lo que haga falta :).
Pablo, uso windows 7. Corri el test Poodle en Chrome y Firefox y me dio que no estoy vulnerable. Sin embargo en el Explorer version 11 me dio que si soy vulnerable……..y lo peor es que un banco con el que opero solo acepta explorer….
¿ como puedo solucionarlo ? En tus indicaciones no figura dicho navegador.
Saludos,
Hernan
Buenas Hernán. No hay ningún problema.
Acabo de actualizar el artículo explicando cómo se debería hacer en IE. Confírmame si puedes que lo has conseguido, y si no lo pruebo en mi portátil.
Voto realizado, 4 navegadores invulnerables, articulos de lujo diseño intuitivo. Te mereces ganar. Suerte
Muchísimas gracias Pau. A ver si hay suerte, y al menos quedamos por arriba :).
Buenas tardes a todos detectado problema en AVAST 2015 estarán controlando los certificados SSL y TLS por encima del navegador y todavía no lo han parcheado quedando expuestos y vulnerables. Solución:
1.- Restaurar el sistema.-
2.- desinstalar avast 2015 con el desintalador oficial http://www.avast.com/es-es/uninstall-utility del antivirus
3.- Al AVG FREE 2015 también le pasa lo mismo (después del primer reinicio), por lo que no es una opción.
Todo esto ha sido resuelto gracias a la ayuda inestimable vía hangout de Pablo F. Iglesias. Gracias amigo
Muchísimas gracias Pau. Importantísimo lo que acaba de comentar. Todos los usuarios a AVAST2015, por ahora, hasta que saquen un parche, son vulnerables, aunque hagan los pasos oportunos que explicamos en el artículo.