mgrube/cve-2019-9673Informe
NOTA: he divulgado este bug por completo al equipo de Freenet y he trabajado con ellos para verificar su parche. El parche ya está implementado en la última versión de Freenet.
Recientemente he encontrado una vulnerabilidad de seguridad en Freenet que podría permitir a un atacante desanonimizar a un objetivo o enviar documentos maliciosos a través de Freenet.
Esta vulnerabilidad afecta a los usuarios de Freenet que utilizan Firefox como navegador. Permite la desanonimización y otros comportamientos maliciosos en el ordenador del usuario. Está presente en todas las versiones hasta la 1483.
Esta explotación funciona aprovechando un desajuste entre Firefox y Freenet en cuanto al manejo de los tipos MIME. Freenet incluye filtros para muchos tipos de contenido diferentes: se ha dedicado un gran esfuerzo a asegurarse de que solo se pueda renderizar contenido bien formado y sin scripts sin una serie de advertencias para el usuario.
En general, Freenet hace un buen trabajo manejando los datos como debería y permitiendo al usuario especificar si prefiere que se manejen de otra manera.
Firefox, por otro lado, es un poco más matizado en cómo determina el tipo MIME de un archivo. Concretamente, como se documenta aquí. La mayor parte del proceso documentado en esta página está fuera del control de un atacante, especialmente si deben atacar a través de Freenet. Sin embargo, una cosa que sí está dentro del control de un atacante es el tipo MIME de los datos que se insertan. Cuando se insertan datos en la red Freenet, un usuario puede especificar el tipo MIME; cuando este campo se deja vacío, los datos se tratan como application/octet-stream y reciben todo el tratamiento adecuado en cuanto a advertencias.
Sin embargo, si vamos a la sección HTTP de la documentación de Mozilla, vemos que Firefox en realidad hace sus propias suposiciones sobre el tipo MIME de los datos cuando la aplicación que sirve el contenido no cumple ciertas condiciones. Concretamente, cuando la aplicación no envía la cabecera Content-Encoding, Firefox inspecciona el contenido para decidir qué hacer con él. Si el primer bloque de datos no es texto, Firefox tratará el archivo como el tipo MIME que indique la extensión.
Resulta que Freenet no enviaba esta cabecera en sus respuestas, lo que nos permite convertir esto en algo aprovechable. Dado que nuestros datos pueden insertarse como tipo MIME text/plain, que obviamente no recibe un filtrado sofisticado, pero pueden entregarse como cualquier tipo MIME que indique la extensión del archivo, ahora tenemos una forma de entregar un documento HTML sin filtrar (o PDF, o .docx...). Esto es un gran problema porque normalmente todo el contenido peligroso se recomienda descargarlo en una carpeta o espacio temporal y abrirlo fuera del navegador.
Este es un breve vídeo de la explotación funcionando; en este caso, para entregar un archivo HTML sin filtrar.
Para ver un ejemplo funcional, instala la versión 1483 o anterior y navega a:
Para quien quiera probarlo en casa, puede obtener la versión vulnerable más reciente de Freenet aquí.
Entonces, ¿cómo podríamos usar esto en el mundo real?
Resulta que si enlazas tu contenido malicioso dentro de Freenet en una página que el usuario ya está navegando, Freenet se asegurará de tratar el archivo como el tipo indicado por su extensión. Freenet verá que nuestro primer bit de datos es binario y advertirá al usuario de que nuestro archivo es malicioso.
:(
Esto significa que si queremos que nuestro objetivo vea nuestra página maliciosa con JS, debemos enlazarla externamente. Esto en realidad es bueno, porque los sistemas de mensajería más populares de Freenet no operan desde el proxy web de Freenet.
Si, por ejemplo, la URI de demostración de este artículo se enlazara dentro de FMS, no habría comprobación adicional y podríamos hacer que nuestro payload se ejecutara.
Todo lo que sería necesario para desanonimizar a varios usuarios de Freenet sería crear contenido con un título interesante, insertar un archivo cuyo primer bloque de datos sea binario y luego crear una página web convincente que informe silenciosamente de la dirección IP y la actividad en segundo plano. Combina esto con un conjunto de herramientas como el framework BeEF y tienes algunas oportunidades interesantes.
Por supuesto, también podemos usar esto como vector para entregar un PDF malicioso, .docx u otros archivos y obtener un punto de apoyo más permanente en la máquina del usuario.
Arreglar este bug es bastante simple: de ahora en adelante, FProxy siempre pasará la cabecera HTTP Content-Encoding cuando entregue contenido. Esta cabecera le indica al navegador Firefox que trate los tipos MIME explícitamente tal como los define FProxy. Como resultado, los datos de tipo text/plain siempre se mostrarán como texto plano y no se tratarán como ningún otro tipo MIME.
Este bug, en general, era bastante simple; sin embargo, tenía la capacidad de afectar la funcionalidad de Freenet de forma importante. La comprobación de tipos MIME es realmente importante, y una gran lección que se aprende de este bug es que los tipos MIME no siempre se manejan de manera consistente cuando los datos se pasan de un programa a otro.
Solo inserta algunos datos en Freenet con tipo MIME text/plain y el primer bloque conteniendo únicamente datos binarios. Firefox lo tratará como el tipo que especifique la extensión del archivo y se entregará directamente al usuario en lugar de ser filtrado por Freenet. Envíalo a tus víctimas por FMS o Frost. Recopila sus direcciones IP o haz que ejecuten un payload binario. ¡Beneficios!
