Owning bad guys & mafia with Javascript botnets (5 de 5)

**************************************************************************************************
- Owning bad guys & mafia with Javascript botnets (1 de 5)
- Owning bad guys & mafia with Javascript botnets (2 de 5)
- Owning bad guys & mafia with Javascript botnets (3 de 5)
- Owning bad guys & mafia with Javascript botnets (4 de 5)
- Owning bad guys & mafia with Javascript botnets (5 de 5)
**************************************************************************************************

Llegando a la Intranet

Una de las cosas que más nos llamó la atención al revisar los datos recolectados es que era posible encontrar información de equipos que no estaban publicados en Internet, es decir, de aplicaciones que estan siendo utilizadas internamente en una Intranet, tal y como se puede ver en los datos siguientes de un registro de personas en una base de datos.

Figura 20: Datos de Intranet. El servidor no era accesible desde Internet.

La razón por la que estos datos han sido recogidos por una arquitectura de botnet Javascript como la descrita en este estudio son simples:

1) En algún momento esta persona decidió voluntariamente en una arquitectura de man in the middle con un servidor Proxy.
2) En algún momento solicitó un fichero Javascript a Internet que estaba siendo compartido por la aplicación de la Intranet y este fue infectado.

Esto deja a las claras que utilizar ficheros Javascript remotos en una Intranet quizá no sea lo deseable y deja abierta la puerta a posibles ataques de este tipo.

Viendo esto se nos ocurrió que sería sencillo preparar una ataque dirigido a una aplicación de una Intranet o de Internet analizando previamente los ficheros Javascript que carga y obligando a los clientes a cargar esos ficheros desde cualquier dominio, de tal manera que se fuerza el cacheo.

Analizando los ficheros Javascript de una web

Para preparar un ataque dirigido a un sitio, es decir, para garantizar que un usuario que forma parte de la botnet esté infectado cuando visita un sitio concreto, hay que saber cuáles son las ficheros javascript que utiliza ese sitio. Para hacer esto se puede hacer uso de la inspección de red en Google Chrome o de Firebug en Firefox, igual que se comprueba si una webshell está troyanizada.

Figura 21: Ficheros Javascript cargados en una página login de un dominio .mil

Por ejemplo, en este sitio se puede ver que en esta página de login se están cargando ficheros Javascript de manera estática, es decir, que siempre se cargan los mismos ficheros, lo que permite forzar un cacheo previo de todos ellos en las víctimas que se quieran infectar. Para ello, en el panel de control se haría un payload en Javascript que hiciera algo como

document.write(<script src=http://www.objetivo.com/target.js >);

Simplemente con esto se consigue que, se visite la web que se visite, se pueda infectar el fichero Javascript que se ejecutará en la página objetivo, esperando que en el futuro el usuario vaya a visitar la página objetivo.

Ficheros Javascript dinámicos

Durante la demo que preparamos para la RootedCon pudimos ver - y sufrir en nuestras carnes mi compañero Manu "The Sur" - que sitios como Facebook cargan ficheros script con nombres que cambian dinámicamente, lo que evita que se pueda cachear previamente el fichero Javascript, por lo que no se puede hacer este tipo de ataques con ellos.

Figura 22: Ficheros Javascript cargados en la página de login de Facebook

Sin embargo, la lista de sitios que cargan ficheros Javascript estáticos en la página de login en bancos, instituciones, empresas, etc... es brutal, ya que no debería ser una vulnerabilidad de seguridad si los usuarios no hicieran mal uso de sus conexiones.

Ficheros Javascript previamente cacheados y HTTPS

Una de las cosas que no implementamos en esta prueba de concepto fue la de forzar que se cacheara el fichero infectado si ya estaba en la caché del navegador. Suponiendo que un sitio cargue un fichero Javascript que el navegador ya tiene en la caché, el cliente no va a solicitar ese fichero, por lo que quedaría sin infectar. Sin embargo, jugando con las opciones de HTTP Etags sería posible forzar al navegador a solicitar los nuevos ficheros, pero esto es algo que no implementamos en esta prueba de concepto

Por otro lado, para no levantar la más mínima sospecha, decidimos no interferir las comunicaciones HTTPs, lo que dejaba fuera de nuestro alcance cualquier conexión segura y cualquier cookie marcada con el flag Secure. No olvidéis que esto sólo fue una POC.

Recomendaciones finales

Tanto las redes TOR como los sistemas Proxy representan esquemas de hombre en medio en los que hay que confiar para hacer uso de ellos. En Internet, poner un servidor malicioso resulta demasiado sencillo como para pensar que no esté siendo realizado de manera masiva por gente con peores intenciones, por lo que si vas a hacer uso de alguna de estas infraestructuras lo mejor es que te prepares para sufrir ataques.

No navegues con sistemas desactualizados por esas redes, firewalls y antimalware alerta, y recuerda que al terminar de hacer uso de ellos deberás tomar precauciones de desinfección. Como recomendación por defecto, borra la caché en cada sesión del navegador, y usa siempre  el modo de navegación privada.

Saludos Malignos!

**************************************************************************************************
- Owning bad guys & mafia with Javascript botnets (1 de 5)
- Owning bad guys & mafia with Javascript botnets (2 de 5)
- Owning bad guys & mafia with Javascript botnets (3 de 5)
- Owning bad guys & mafia with Javascript botnets (4 de 5)
- Owning bad guys & mafia with Javascript botnets (5 de 5)
**************************************************************************************************