Los últimos 12 meses han sido frenéticos, histéricos, frustrantes y desconcertantes para la seguridad. Nunca en tan poco tiempo y de forma tan continuada nos habían dicho que las cerraduras, las llaves, las puertas y ventanas de nuestros sistemas habían sido violables desde hacía años. Nuestros sistemas han estado abiertos cuando pensábamos que estaban cerrados, nuestros datos estaban accesibles cuando pensábamos que estaban protegidos y hemos tenido que realizar una de las mayores migraciones en los sistemas de cifrado de comunicaciones por culpa de la implementación de cifrado más usada en el mundo, OpenSSL.
La mayor crisis de los últimos años empezó en abril de 2014, a la velocidad de la tinta de calamar en el agua se comenzó a hablar de algo que sólo en los foros se decía hacía años que podría pasar, a modo de mito: una importante vulnerabilidad en SSL se había publicado y se estaba empleando para comprometer sistemas de forma remota. No se facilitó mucha información inicialmente, realmente fue breve el momento de desconcierto, porqué cuando se publicaron los datos de la vulnerabilidad el día 7 de abril se vio la gravedad del problema: una implementación defectuosa del protocolo TLS y DTLS (Transport Layer Security) en las librería de OpenSSL (la implementación más utilizada en Internet) en ciertas versiones (masivamente utilizadas). Esta vulnerabilidad, que se denominó heartbleed por el hecho que el problema venía por la implementación de una funcionalidad llamada heartbeat permitía obtener 64kb de la memoria del servidor que ejecutaba las versiones vulnerables a cada petición malformada para explotar ese ataque (CVE-2014-0160).
Rápidamente aparecieron los exploits y pruebas de concepto que permitieron demostrar la cantidad de información que podía obtenerse: certificados, claves, contraseñas, información sensible tratada en la memoria del servidor. Es decir, como alguien describió gráficamente en full-disclosure (R.I.P.) “we are dommed” (estamos condenados). Trivial explotación de forma remota, situación ideal.
Tras la aparición de las actualizaciones de los fabricantes, de OpenSSL, LibreSSL y demás afectados, comenzó una carrera frenética para intentar volver a disponer de sitios web seguros. Muchos de ellos enviaron correos diciendo a sus usuarios que no podían garantizar que sus contraseñas no hubieran sido comprometidas. Millones de sitios web eran vulnerables y, lo peor de todo, millones de sistemas de nuestro querido IoT (Internet of Things) lo es y seguirá siendo durante mucho tiempo por la complejidad o imposibilidad de actualización.
Nos habían robado las llaves, realmente no habíamos tenido llaves y no lo sabíamos: heartbleed existía en el código de OpenSSL desde hacía más de 2 años. Si alguien conocía esa vulnerabilidad y no lo publicó, no lo sabemos, pero se presume que así fue.
Y pensamos que actualizando de versión de nuestras librerías SSL a versiones diferentes a las comprendidas entra las 1.0.1 1.0.1f estábamos salvados, pero era un espejismo…
El 4 de junio de 2014 ZDI publica un aviso de una nueva vulnerabilidad, con ejecución remota de código por una nueva vulnerabilidad recibida por Tipping Point en algún momento (ZDI compra vulnerabilidades 0-day para aplicar reglas de filtrado en sus IPS pero de forma opaca hasta su publicación cuando ZDI lo decide). Esta vulnerabilidad volvía a poner en riesgo relativamente alto cualquier sistema parcheado dos meses antes: servidores de comercio electrónico, comunicaciones cifradas, etc. etc. De nuevo, un “vulgar buffer overflow” de manual básico de exploiting. OpenSSL estaba más entredicho que nunca y los sysadmins ya empezaban a estar desquiciados. Nada que no solucionara la versión 1.0.1h…
Pero el 2014 no iba a terminar hasta poner la puntilla a OpenSSL y a las implementaciones de SSL hasta que POODLE (Padding Oracle On Downgraded Legacy Encryption) saltó al público y un nuevo aviso tras la vulnerabilidad identificada por miembros de Google (que dedica muchos recursos a la identificación de vulnerabilidades en proyectos Open Source y, con mucho ahínco en productos de “enemigos” tecnológicos). Esta vez, este ataque de man-in-the-middle básicamente destrozaba la supuesta versión solida de SSL 3.0 y la convertía en un protocolo inútil para el cifrado de comunicaciones de forma segura. Todas aquellas recomenciones, estándares, buenas prácticas, etc. que decían “deshabilite versiones inferiores a SSL v2.0 pase a v3.0” quedabas desactualizadas. Los sysadmins entraron en crisis porqué los exploits de POODLE empezaron a circular rápidamente, se empezaron a explotar servidores por todo el mundo.
Y los que migraron a TLS 1.0 o empleaban este protocolo alternativo de cifrado pensaron estar viviendo felices hasta que el 8 de diciembre de 2014 se publica una variante de POODLE que explota ese protocolo y versiones 1.0 a 1.2. No tan fácilmente explotable por la necesidad de que el usuario participara en la explotación pero acabando de poner la puntilla a esas comunicaciones cifradas, esa tranquilidad tras el “candado” que parece que lo protege todo… estaba desapareciendo.
Pero cuando la cosa va mal, siempre puede ir a peor, y en marzo de este año un nuevo nombre en clave de una vulnerabilidad que se dijo que era catastrófica para la protección de las comunicaciones se hizo pública, FREAK (Factoring RSA Export Keys). En este caso, el ataque permitía descifrar el tráfico de red cifrado con SSL/TLS mediante un ataque que forzaba el downgrade de un cifrado RSA robusto a uno débil en la comunicación y que, por tanto, podía ser descifrado con facilidad.
Lógicamente, SSL ha dejado de ser un protocolo de cifrado de comunicaciones viable en cualquiera de sus versiones, así como las versiones inferiores de TLS. Es decir, generalizando, las que prácticamente se empleaban de forma generalizada (y se siguen empleando allí donde no ha sido posible migrar o actualizar) en la mayoría de sistemas de información, componentes de comunicaciones, servidores embebidos, terminales móviles, es decir, un espectro nada desdeñable de potenciales objetivos. Se puede decir que lo difícil era “disparar” a un objetivo que no hubiera sufrido algunas de las vulnerabilidades en lugar de ser al revés.
Tantos torpedos por debajo de la línea de flotación de OpenSSL tuvieron un impacto remarcable, y que merece especial atención, en uno de los estándares de seguridad de los que posiblemente se ha hablado más estos últimos años: PCI DSS ( Payment Card Industry Data Security Standard). Este estándar público recoge los requerimientos que toda empresa que trate, transmita o almacene datos de tarjetas de pago deberá cumplir y es gestionado por el PCI SSC ( PCI Security Standards Council) tras el cual participan las marcas más influyentes de medios de pago: VISA, Mastercard, American Express, JCB y Discover.
Lógicamente, la norma define los requerimientos mínimos que deben tenerse en cuenta en cuanto al cifrado y SSL era una de las opciones que la norma, hasta su versión 3.0 aceptaba como usables.
Pero el PCI SSC publicó en Abril de este año lo que sería la confirmación de la sentencia de muerte de SSL, y las versiones inferiores de TLS, anunciando que estos protocolos deberían ser dejados de usar si cualquier empresa desea cumplir con la norma. Y esto, a grandes rasgos incluye a todo el sector financiero, cualquier tipo de comercio electrónico o no, proveedores de servicios, es decir, todas las empresas que cohabitan en Internet. Con una fecha límite posiblemente demasiado laxa, el 30 de junio de 2016.
La versión 3.1, que se publicaría al mismo tiempo que la guía de migración de SSL/TLS, de PCI DSS incluyó otros cambios o aclaraciones, como las clasifica principalmente el PCI SSC, pero realmente, fue una versión que, dados los “escándalos” generados por la inseguridad de estos protocolos, era necesario que se oficializara: SSL estaba oficialmente muerto.
Autor: Daniel Fernández Bleda - CISSP, CISM, CISA, ISO 27001 LA, CHFI, OPST/A
Membership chair, (ISC)2 Spain Chapter.
Global Sales Manager, Internet Security Auditors
La mayor crisis de los últimos años empezó en abril de 2014, a la velocidad de la tinta de calamar en el agua se comenzó a hablar de algo que sólo en los foros se decía hacía años que podría pasar, a modo de mito: una importante vulnerabilidad en SSL se había publicado y se estaba empleando para comprometer sistemas de forma remota. No se facilitó mucha información inicialmente, realmente fue breve el momento de desconcierto, porqué cuando se publicaron los datos de la vulnerabilidad el día 7 de abril se vio la gravedad del problema: una implementación defectuosa del protocolo TLS y DTLS (Transport Layer Security) en las librería de OpenSSL (la implementación más utilizada en Internet) en ciertas versiones (masivamente utilizadas). Esta vulnerabilidad, que se denominó heartbleed por el hecho que el problema venía por la implementación de una funcionalidad llamada heartbeat permitía obtener 64kb de la memoria del servidor que ejecutaba las versiones vulnerables a cada petición malformada para explotar ese ataque (CVE-2014-0160).
Rápidamente aparecieron los exploits y pruebas de concepto que permitieron demostrar la cantidad de información que podía obtenerse: certificados, claves, contraseñas, información sensible tratada en la memoria del servidor. Es decir, como alguien describió gráficamente en full-disclosure (R.I.P.) “we are dommed” (estamos condenados). Trivial explotación de forma remota, situación ideal.
Tras la aparición de las actualizaciones de los fabricantes, de OpenSSL, LibreSSL y demás afectados, comenzó una carrera frenética para intentar volver a disponer de sitios web seguros. Muchos de ellos enviaron correos diciendo a sus usuarios que no podían garantizar que sus contraseñas no hubieran sido comprometidas. Millones de sitios web eran vulnerables y, lo peor de todo, millones de sistemas de nuestro querido IoT (Internet of Things) lo es y seguirá siendo durante mucho tiempo por la complejidad o imposibilidad de actualización.
Nos habían robado las llaves, realmente no habíamos tenido llaves y no lo sabíamos: heartbleed existía en el código de OpenSSL desde hacía más de 2 años. Si alguien conocía esa vulnerabilidad y no lo publicó, no lo sabemos, pero se presume que así fue.
Y pensamos que actualizando de versión de nuestras librerías SSL a versiones diferentes a las comprendidas entra las 1.0.1 1.0.1f estábamos salvados, pero era un espejismo…
El 4 de junio de 2014 ZDI publica un aviso de una nueva vulnerabilidad, con ejecución remota de código por una nueva vulnerabilidad recibida por Tipping Point en algún momento (ZDI compra vulnerabilidades 0-day para aplicar reglas de filtrado en sus IPS pero de forma opaca hasta su publicación cuando ZDI lo decide). Esta vulnerabilidad volvía a poner en riesgo relativamente alto cualquier sistema parcheado dos meses antes: servidores de comercio electrónico, comunicaciones cifradas, etc. etc. De nuevo, un “vulgar buffer overflow” de manual básico de exploiting. OpenSSL estaba más entredicho que nunca y los sysadmins ya empezaban a estar desquiciados. Nada que no solucionara la versión 1.0.1h…
Pero el 2014 no iba a terminar hasta poner la puntilla a OpenSSL y a las implementaciones de SSL hasta que POODLE (Padding Oracle On Downgraded Legacy Encryption) saltó al público y un nuevo aviso tras la vulnerabilidad identificada por miembros de Google (que dedica muchos recursos a la identificación de vulnerabilidades en proyectos Open Source y, con mucho ahínco en productos de “enemigos” tecnológicos). Esta vez, este ataque de man-in-the-middle básicamente destrozaba la supuesta versión solida de SSL 3.0 y la convertía en un protocolo inútil para el cifrado de comunicaciones de forma segura. Todas aquellas recomenciones, estándares, buenas prácticas, etc. que decían “deshabilite versiones inferiores a SSL v2.0 pase a v3.0” quedabas desactualizadas. Los sysadmins entraron en crisis porqué los exploits de POODLE empezaron a circular rápidamente, se empezaron a explotar servidores por todo el mundo.
Y los que migraron a TLS 1.0 o empleaban este protocolo alternativo de cifrado pensaron estar viviendo felices hasta que el 8 de diciembre de 2014 se publica una variante de POODLE que explota ese protocolo y versiones 1.0 a 1.2. No tan fácilmente explotable por la necesidad de que el usuario participara en la explotación pero acabando de poner la puntilla a esas comunicaciones cifradas, esa tranquilidad tras el “candado” que parece que lo protege todo… estaba desapareciendo.
Pero cuando la cosa va mal, siempre puede ir a peor, y en marzo de este año un nuevo nombre en clave de una vulnerabilidad que se dijo que era catastrófica para la protección de las comunicaciones se hizo pública, FREAK (Factoring RSA Export Keys). En este caso, el ataque permitía descifrar el tráfico de red cifrado con SSL/TLS mediante un ataque que forzaba el downgrade de un cifrado RSA robusto a uno débil en la comunicación y que, por tanto, podía ser descifrado con facilidad.
Lógicamente, SSL ha dejado de ser un protocolo de cifrado de comunicaciones viable en cualquiera de sus versiones, así como las versiones inferiores de TLS. Es decir, generalizando, las que prácticamente se empleaban de forma generalizada (y se siguen empleando allí donde no ha sido posible migrar o actualizar) en la mayoría de sistemas de información, componentes de comunicaciones, servidores embebidos, terminales móviles, es decir, un espectro nada desdeñable de potenciales objetivos. Se puede decir que lo difícil era “disparar” a un objetivo que no hubiera sufrido algunas de las vulnerabilidades en lugar de ser al revés.
Tantos torpedos por debajo de la línea de flotación de OpenSSL tuvieron un impacto remarcable, y que merece especial atención, en uno de los estándares de seguridad de los que posiblemente se ha hablado más estos últimos años: PCI DSS ( Payment Card Industry Data Security Standard). Este estándar público recoge los requerimientos que toda empresa que trate, transmita o almacene datos de tarjetas de pago deberá cumplir y es gestionado por el PCI SSC ( PCI Security Standards Council) tras el cual participan las marcas más influyentes de medios de pago: VISA, Mastercard, American Express, JCB y Discover.
Pero el PCI SSC publicó en Abril de este año lo que sería la confirmación de la sentencia de muerte de SSL, y las versiones inferiores de TLS, anunciando que estos protocolos deberían ser dejados de usar si cualquier empresa desea cumplir con la norma. Y esto, a grandes rasgos incluye a todo el sector financiero, cualquier tipo de comercio electrónico o no, proveedores de servicios, es decir, todas las empresas que cohabitan en Internet. Con una fecha límite posiblemente demasiado laxa, el 30 de junio de 2016.
La versión 3.1, que se publicaría al mismo tiempo que la guía de migración de SSL/TLS, de PCI DSS incluyó otros cambios o aclaraciones, como las clasifica principalmente el PCI SSC, pero realmente, fue una versión que, dados los “escándalos” generados por la inseguridad de estos protocolos, era necesario que se oficializara: SSL estaba oficialmente muerto.
Autor: Daniel Fernández Bleda - CISSP, CISM, CISA, ISO 27001 LA, CHFI, OPST/A
Membership chair, (ISC)2 Spain Chapter.
Global Sales Manager, Internet Security Auditors