La curiosa historia de la vulnerabilidad "cíclica y programada" en HPKP de Firefox
2 de octubre de 2016
Probablemente esta sea una de las historias más curiosas sobre cómo se ha descubierto un fallo de seguridad, además de un fallo de seguridad en sí mismo de lo más rocambolesco.
De cómo se descubrió un problema de ejecución de código en Tor Broswer, que en realidad acabó además en un grave agujero de implementación de HPKP en Firefox tras un proceso complejo que ha desconcertado a muchos especialistas intentando aclarar la situación. Ha pasado desapercibida para los medios, pero merece la pena analizarla.
El "no fallo" en Tor Browser
Movrcx descubrió un fallo muy peculiar a principios de septiembre. Defendía que había encontrado una fórmula en el que podía ejecutar código en cualquier usuario de Tor Broswer (basado en Mozilla Firefox ESR, la Extended Support Release). Y no por un fallo explotable en el navegador, sino por el propio funcionamiento del ecosistema de Tor. Lo "único" que necesitaba el atacante era disponer de un certificado TLS válido del dominio "addons.mozilla.org". Esto mitiga mucho el alcance de la vulnerabilidad, y pocos se lo tomaron en serio. Pero aunque parezca complicado, lo cierto es que ese certificado ya fue comprometido en su día por iraníes... Y aun así, si lo que se quiere es espiar qué se hace en la red Tor, definitivamente es algo al alcance de un gobierno. Además, Movrcx no argumentaba el fallo en sí como el problema mayor, sino el hecho de que un simple certificado fuese el requisito más complejo para poder potencialmente ejecutar código en cualquier usuario del navegador Tor.
Si el atacante podía controlar la url de actualización haciéndole pensar que era addons.mozilla.org,
podría redirigir a la víctima a cualquier web para actualizar
El fallo consistía en una cadena de errores, como todo buen problema de seguridad con raíces en los procedimientos y no tanto en el código. Se basaba en que el sistema de actualización de plugins de Mozilla (y de Tor Browser), permitía autofirmar extensiones. Además, Tor Browser pregunta cada 24 horas por una actualización de extensiones de forma automática. Si en un nodo de salida (controlado por el atacante) se consigue redirigir a la víctima a una página que parece ser la de "versioncheck.addons.mozilla.org" (falseada gracias al certificado) y que durante la actualización se descargue una extensión que no es el verdadero NoScript (por poner un ejemplo de plugin que viene de serie con Tor Broswer), este sería validado e instalado de forma totalmente transparente para el usuario. Puede parecer un poco rebuscado porque precisamente para evitar esto están los certificados. El descubrimiento fue criticado no solo por eso, sino porque según los más avispados, no solo necesitaba el certificado para consumar el ataque, sino también romper el pinning del navegador, que es precisamente para lo que sirve (y con lo que demuestra su utilidad). El ataque parecía una farsa, irrealizable. Pero Movrcx no mentía, a él le había funcionado incluso con el pinning activo… y podía demostrarlo. ¿Había otro error en la implementación de pinning? No parecía, porque lo curioso es que avanzado septiembre, en fechas diferentes, el ataque ya no funcionaba a quien intentaba reproducirlo. El pinning lo protegía. ¿Qué demonios estaba pasando? Esto ha mantenido a una serie de expertos indagando durante días. Veamos qué pasaba.
El "sí fallo" en el "no uso" de HPKP
Muchos vieron un fallo fundamental en la conceptualización del ataque: le funcionaba porque en su entorno obviamente no falsificó un certificado real sino que en el laboratorio había usado una CA introducida a mano como raíz en Tor Browser, y por defecto, Mozilla no pinea certificados metidos por el propio usuario. En la vida real, no hubiera funcionado. Esta función se llama security.cert_pinning.enforcement_level en about:config, que está establecido a 1 en Firefox, o sea, no pinear certificados autointroducidos por el usuario.
Pero ya nos estábamos equivocando. Tor Browser es Firefox fortificado, y en Tor, security.cert_pinning.enforcement_level está por defecto a 2... pinear siempre. El ataque no tenía que haberle funcionado ni en real ni en laboratorio. ¿Qué pasaba? Compilaron Tor Broswer para ver si tenía algún error al detectar CA propias o ajenas, muchos expertos comenzaron a lanzar teorías… O bien creían la versión de Movrcx o bien no le daban la mayor importancia al ataque. Pero algo no cuadraba… y algunos se quedaron investigando.
Finalmente, se desveló un dato curioso: este fallo podía ser cíclico y funcionar durante ventanas de tiempo cambiantes y cada cierto tiempo. Por ejemplo, el ataque sería posible durante algunos días de noviembre en el futuro, o durante 35 días desde diciembre a enero de 2017. Como decía Ryan Duff.. una vulnerabilidad "programada" ya de por sí tiene interés.
La raíz del problema
Lo que pasaba es que addons.mozilla.org. no utiliza HPKP para pinear su certificado. Usa algo mucho más estático: en cada nueva publicación de Firefox, incrusta el pin en el código con fecha de caducidad. Esto tiene sentido porque así no tiene que recogerlos la primera vez del servidor (están "preloaded"), y esto nos alivia el problema de que esa primera vez que se recogen los pines, exista un hombre en el medio. Los pines, tanto de HPKP como incrustados, tienen que caducar. Si no, se corre el riesgo de que sean comprometidos, deban ser reemplazados, y el navegador que los recuerda nunca los olvide. Ante el miedo a que un usuario no pueda acceder a una página porque por una emergencia el servidor ha cambiado el certificado y el navegador recuerda otro, s e utilizan periodos de caducidad relativamente cortos. Si algo pasa, al menos la ventana de tiempo del problema se minimiza. También se corre el riesgo de que un usuario que no actualiza su Firefox (entre otros problemas de seguridad que asume al no hacerlo), pierda acceso al final hacia el sitio donde quiera ir porque nunca renovaría su certificado. En resumen, un pin caducado, deja de tener efecto. Así que es buena idea que caduquen pero… ¿cuándo es lo ideal? ¿cuándo deben caducar los pines incrustados de una página esencial de Firefox y controlada por ellos mismos? Muy sencillo: al menos hasta que aparezca la siguiente versión de Firefox con una nueva fecha. De lo contrario, el pinning no tendrá efecto desde la fecha de caducidad hasta que el navegador sea actualizado. Y aquí es donde justa y sorprendentemente fallaron todos los controles de Mozilla.
Por ejemplo (y son datos reales), Firefox ESR 45.3.0 salió el 2 de agosto con la caducidad de los pines incrustada para el 3 de septiembre. Firefox ESR 45.4.0 no salió hasta el 20 de septiembre… así que del 3 de al 20 de septiembre, para todo usuario de Firefox ESR 45.3 y 45.4 (y Tor Browser) incluso actualizando el mismo día, los pines no eran efectivos. Justo en el periodo en el que Movrcx realizó sus pruebas.
Simplemente no se hacía certificate pinning. Tor Browser sigue los pasos de las releases ESR de Mozilla y por tanto… Movrcx tenía razón, y sus escépticos detractores que hicieron pruebas más tarde… también.
Conclusiones
Mozilla ha reaccionado rápido y bien. Una de las contramedidas ha sido no depender solo de pines estáticos, sino introducir HPKP para que el pineo sea también dinámico. Gracias a la extensión de Firefox PinPatrol podemos comprobarlo, además de ver en claro cuándo expiran los pines, por si existiera algún otro problema… (Mozilla sigue sin dar una interfaz a este tipo de datos almacenados en el navegador).
Mozilla ha añadido pines HPKP a muchos de sus dominios y subdominios,
aunque estuvieran también incrustados en el navegador
Ivan Ristic planteaba curiosamente a principios de septiembre una pregunta: "¿ Está HPKP muerto?". Su argumentación es impecable, pero no creo que sea la conclusión adecuada. HPKP es útil, necesario y realiza su cometido. La mayor parte del problema, decía curiosamente, está en que los administradores no conocen qué políticas aplicar para desplegarlo. También en cómo lo implemente cada cliente (sobre esto presentaremos una investigación de ElevenPaths sobre HPKP y HSTS en la Cryptology and Network Security Conference 2016 en Milán en noviembre.). Con este fallo se demuestra que HPKP está vivo (ha resuelto un problema y prevenido un ataque) pero que como suele ocurrir, efectivamente es necesario entender el protocolo o de lo contrario, no servirá de nada. Pero esto ocurre con HPKP y cualquier otra medida de seguridad que se nos ocurra.
El "no fallo" en Tor Browser
Movrcx descubrió un fallo muy peculiar a principios de septiembre. Defendía que había encontrado una fórmula en el que podía ejecutar código en cualquier usuario de Tor Broswer (basado en Mozilla Firefox ESR, la Extended Support Release). Y no por un fallo explotable en el navegador, sino por el propio funcionamiento del ecosistema de Tor. Lo "único" que necesitaba el atacante era disponer de un certificado TLS válido del dominio "addons.mozilla.org". Esto mitiga mucho el alcance de la vulnerabilidad, y pocos se lo tomaron en serio. Pero aunque parezca complicado, lo cierto es que ese certificado ya fue comprometido en su día por iraníes... Y aun así, si lo que se quiere es espiar qué se hace en la red Tor, definitivamente es algo al alcance de un gobierno. Además, Movrcx no argumentaba el fallo en sí como el problema mayor, sino el hecho de que un simple certificado fuese el requisito más complejo para poder potencialmente ejecutar código en cualquier usuario del navegador Tor.
Si el atacante podía controlar la url de actualización haciéndole pensar que era addons.mozilla.org,
podría redirigir a la víctima a cualquier web para actualizar
El fallo consistía en una cadena de errores, como todo buen problema de seguridad con raíces en los procedimientos y no tanto en el código. Se basaba en que el sistema de actualización de plugins de Mozilla (y de Tor Browser), permitía autofirmar extensiones. Además, Tor Browser pregunta cada 24 horas por una actualización de extensiones de forma automática. Si en un nodo de salida (controlado por el atacante) se consigue redirigir a la víctima a una página que parece ser la de "versioncheck.addons.mozilla.org" (falseada gracias al certificado) y que durante la actualización se descargue una extensión que no es el verdadero NoScript (por poner un ejemplo de plugin que viene de serie con Tor Broswer), este sería validado e instalado de forma totalmente transparente para el usuario. Puede parecer un poco rebuscado porque precisamente para evitar esto están los certificados. El descubrimiento fue criticado no solo por eso, sino porque según los más avispados, no solo necesitaba el certificado para consumar el ataque, sino también romper el pinning del navegador, que es precisamente para lo que sirve (y con lo que demuestra su utilidad). El ataque parecía una farsa, irrealizable. Pero Movrcx no mentía, a él le había funcionado incluso con el pinning activo… y podía demostrarlo. ¿Había otro error en la implementación de pinning? No parecía, porque lo curioso es que avanzado septiembre, en fechas diferentes, el ataque ya no funcionaba a quien intentaba reproducirlo. El pinning lo protegía. ¿Qué demonios estaba pasando? Esto ha mantenido a una serie de expertos indagando durante días. Veamos qué pasaba.
El "sí fallo" en el "no uso" de HPKP
Muchos vieron un fallo fundamental en la conceptualización del ataque: le funcionaba porque en su entorno obviamente no falsificó un certificado real sino que en el laboratorio había usado una CA introducida a mano como raíz en Tor Browser, y por defecto, Mozilla no pinea certificados metidos por el propio usuario. En la vida real, no hubiera funcionado. Esta función se llama security.cert_pinning.enforcement_level en about:config, que está establecido a 1 en Firefox, o sea, no pinear certificados autointroducidos por el usuario.
Pero ya nos estábamos equivocando. Tor Browser es Firefox fortificado, y en Tor, security.cert_pinning.enforcement_level está por defecto a 2... pinear siempre. El ataque no tenía que haberle funcionado ni en real ni en laboratorio. ¿Qué pasaba? Compilaron Tor Broswer para ver si tenía algún error al detectar CA propias o ajenas, muchos expertos comenzaron a lanzar teorías… O bien creían la versión de Movrcx o bien no le daban la mayor importancia al ataque. Pero algo no cuadraba… y algunos se quedaron investigando.
Finalmente, se desveló un dato curioso: este fallo podía ser cíclico y funcionar durante ventanas de tiempo cambiantes y cada cierto tiempo. Por ejemplo, el ataque sería posible durante algunos días de noviembre en el futuro, o durante 35 días desde diciembre a enero de 2017. Como decía Ryan Duff.. una vulnerabilidad "programada" ya de por sí tiene interés.
La raíz del problema
Lo que pasaba es que addons.mozilla.org. no utiliza HPKP para pinear su certificado. Usa algo mucho más estático: en cada nueva publicación de Firefox, incrusta el pin en el código con fecha de caducidad. Esto tiene sentido porque así no tiene que recogerlos la primera vez del servidor (están "preloaded"), y esto nos alivia el problema de que esa primera vez que se recogen los pines, exista un hombre en el medio. Los pines, tanto de HPKP como incrustados, tienen que caducar. Si no, se corre el riesgo de que sean comprometidos, deban ser reemplazados, y el navegador que los recuerda nunca los olvide. Ante el miedo a que un usuario no pueda acceder a una página porque por una emergencia el servidor ha cambiado el certificado y el navegador recuerda otro, s e utilizan periodos de caducidad relativamente cortos. Si algo pasa, al menos la ventana de tiempo del problema se minimiza. También se corre el riesgo de que un usuario que no actualiza su Firefox (entre otros problemas de seguridad que asume al no hacerlo), pierda acceso al final hacia el sitio donde quiera ir porque nunca renovaría su certificado. En resumen, un pin caducado, deja de tener efecto. Así que es buena idea que caduquen pero… ¿cuándo es lo ideal? ¿cuándo deben caducar los pines incrustados de una página esencial de Firefox y controlada por ellos mismos? Muy sencillo: al menos hasta que aparezca la siguiente versión de Firefox con una nueva fecha. De lo contrario, el pinning no tendrá efecto desde la fecha de caducidad hasta que el navegador sea actualizado. Y aquí es donde justa y sorprendentemente fallaron todos los controles de Mozilla.
Por ejemplo (y son datos reales), Firefox ESR 45.3.0 salió el 2 de agosto con la caducidad de los pines incrustada para el 3 de septiembre. Firefox ESR 45.4.0 no salió hasta el 20 de septiembre… así que del 3 de al 20 de septiembre, para todo usuario de Firefox ESR 45.3 y 45.4 (y Tor Browser) incluso actualizando el mismo día, los pines no eran efectivos. Justo en el periodo en el que Movrcx realizó sus pruebas.
Simplemente no se hacía certificate pinning. Tor Browser sigue los pasos de las releases ESR de Mozilla y por tanto… Movrcx tenía razón, y sus escépticos detractores que hicieron pruebas más tarde… también.
Conclusiones
Mozilla ha reaccionado rápido y bien. Una de las contramedidas ha sido no depender solo de pines estáticos, sino introducir HPKP para que el pineo sea también dinámico. Gracias a la extensión de Firefox PinPatrol podemos comprobarlo, además de ver en claro cuándo expiran los pines, por si existiera algún otro problema… (Mozilla sigue sin dar una interfaz a este tipo de datos almacenados en el navegador).
Mozilla ha añadido pines HPKP a muchos de sus dominios y subdominios,
aunque estuvieran también incrustados en el navegador
Ivan Ristic planteaba curiosamente a principios de septiembre una pregunta: "¿ Está HPKP muerto?". Su argumentación es impecable, pero no creo que sea la conclusión adecuada. HPKP es útil, necesario y realiza su cometido. La mayor parte del problema, decía curiosamente, está en que los administradores no conocen qué políticas aplicar para desplegarlo. También en cómo lo implemente cada cliente (sobre esto presentaremos una investigación de ElevenPaths sobre HPKP y HSTS en la Cryptology and Network Security Conference 2016 en Milán en noviembre.). Con este fallo se demuestra que HPKP está vivo (ha resuelto un problema y prevenido un ataque) pero que como suele ocurrir, efectivamente es necesario entender el protocolo o de lo contrario, no servirá de nada. Pero esto ocurre con HPKP y cualquier otra medida de seguridad que se nos ocurra.
Sergio de los Santos
ssantos@11paths.com
.jpg)
.jpg)
 (1).jpg)