Tor y Firefox, ¿la mejor combinación para conseguir anonimato y seguridad?

Todo comenzó con un correo de Sigaint, un servicio de correo público orientado a la privacidad. Una vulnerabilidad previamente desconocida en Firefox estaba siendo aprovechada en esos momentos contra usuarios de Tor (cuyo navegador se basa en Firefox) a través de JavaScript. Un 0-day de verdad (no son 0-day las vulnerabilidades recién descubiertas si no están siendo aprovechadas). Sin haber analizado aún el código, se intuía la gravedad del problema. Veamos qué ha ocurrido y cómo la red Tor combinado con TorBrowser pueden no ser la mejor combinación para conseguir lo que sus usuarios pretenden.

El código, sin necesidad de ser analista, resultaba bastante “autoexplicativo”.

Parte del código del exploit, donde se cargaba una animación para ser interpretada por SVG

Algunas líneas permitían deducir que se trataba de un fallo a la hora de procesar animaciones SVG como después se confirmó. Y en otras se adivinaba la ejecución de cadenas ROP (típicamente necesarias para eludir DEP) para conseguir la ejecución de código.

Parte del código en el que reserva memoria para preparar la ejecución (luego llama a CreateThread)

En JavaScript también se ve cómo utiliza una expresión regular que casa solo con los Firefox utilizados para TorBrowser… ¿por qué limitarse a este navegador? Probablemente porque el objetivo eran solo los usuarios de esta red, y no los de Firefox, y por tanto, se intuye algún componente de control de internautas que buscan el anonimato.

Expresión regular para atacar solo a los TorBrowsers (basados en Firefox)

El exploit se tradujo a código máquina, donde se observa a qué IP se conecta. Aunque se podría hacer cualquier cosa en la máquina (el exploit permite la ejecución de código), este en concreto se limitaba a tomar la dirección MAC e IP del equipo y llevársela a una dirección IP en Francia (OVH). Algo muy parecido al exploit que se encontró en 2013 que luego se supo que provenía del FBI. Pero este exploit resulta tan “simple” en su forma como en su intención, que parece más bien una especie de prueba de concepto que se ha hecho pública antes de tiempo. 

En una sola imagen el exploit con IP, ruta y parte del JavaScript que explota la importante vulnerabilidad en Firefox que se ha usado contra Tor.

Los fallos en la red y el navegador

Lo llamativo no es tanto que “alguien” vigile a los usuarios de la red Tor (otra vez) e intente sacar su información, como ha sido el caso. A estas alturas, es conocido que la red Tor es la herramienta de anonimato que debes evitar si quieres pasar realmente inadvertido. Inyectar este JavaScript o cualquier otro en un nodo de salida sería sencillo. Tor, es necesario admitirlo, es la red más vigilada (exploits, posibilidad de nodos de salida trampa, posibles colaboraciones con la policía…). No suele ser una opción para los que “de verdad” necesitan anonimato por actividades criminales. O al menos, no por sí solo (se puede combinar con tráfico cifrado punto a punto, navegadores muy limitados, etc). Es una buena opción para el ciudadano medio que quiere privacidad ante las operadoras, gobiernos y publicistas, etc… pero es un secreto a voces que los verdaderos delincuentes buscan alternativas.
Tor no ofrece de por sí seguridad, sino en cierta manera anonimato (escondiendo el origen, más específicamente). Para añadir seguridad, es necesario la participación del navegador, en este caso. Y es aquí donde, analizando este incidente, se han desvelado algunas torpezas. 

El fallo en Firefox al procesar SVG parece que ya se conocía en cierta forma en 2013. SVG no es muy usado hoy por hoy. De hecho, la parte de código de Firefox afectada no se ha tocado en cinco años.
Parece que existen desde junio reportes de “crashes” del sistema en esta misma zona de código explotada, lo que podría significar que alguien experimentaba con la vulnerabilidad desde entonces. El exploit no es complejo: no necesita eludir ninguna sandbox. Y aquí se evidencia lo atrás que queda Firefox con respecto a Chrome o IE… no usa procesos aislados por pestaña, no aprovecha una buena sandbox… están en ello, y lo reconocen. 

Todavía están probando lo efectivo que podría ser una sandbox y aprendiendo qué se necesita hacer

Siempre que se habla de seguridad en navegadores, parece que estalla alguna vena sensible más basada en lo visceral que en los hechos. Pero Firefox ha quedado técnica y objetivamente atrás a la hora de implementar medidas de seguridad reactivas y proactivas y no está a la altura del resto. Discutir esto es entrar en filosofía (en el terreno de la privacidad y libertad, donde Firefox sí que funciona mejor que las alternativas…) más que evaluar hechos técnicos.

Chrome con niveles de integridad en “no confianza” y procesos separados. Igual Internet Explorer con su AppContainer, mientras Firefox no separa procesos y usa nivel medio.

Firefox ha arreglado en tiempo récord el problema, como siempre. Pero la solución es un parche de emergencia que no soluciona el problema de raíz. También ellos mismos lo reconocen. Recordemos que esto abre la puerta a que, como tantas otras veces, un parche rápido que no soluciona el problema permita que el fallo siga siendo explotable. Por poner un ejemplo, con este tipo de parches Tavis Ormandy ya ridiculizó a Red_Hat con shellshock. El parche hace que Firefox haga “crash”, pero al menos no se ejecute código. 

En resumen, resulta llamativo que en 2016 se utilice un exploit tan “sencillo” (porque está basado en código que se encuentra en Firefox desde hace más de 5 años) y que el efecto sea tan devastador (porque el navegador no implementa medidas de contención adecuadas) con el fin de espiar a usuarios especialmente preocupados por su privacidad y seguridad. Ni el navegador Firefox ni la red Tor en sí mismas, son los mejores garantes ni lo uno ni de lo otro.