viernes, marzo 16, 2012

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)
**************************************************************************************************

10 comentarios:

  1. Ahora vas y lo cascas ... Muy interesante.

    ResponderEliminar
  2. Por lo menos, podías haber tenido la dignidad de poner a tu compañero Manu "The Sur" en algún post o agradecimiento, no?

    Que por lo que vimos todos en la Rooted, fuisteis los "dos" quien hicisteis el proyecto.

    Por cierto, muy buen trabajo! Sea quien sea el que lo haya hecho.

    [Un Saludo]

    ResponderEliminar
  3. @Anónimo Manu "The Sur" ha sido el que ha implementado el panel. Pensé que estaba claro porque dimos la charla juntos y por eso hablo en todo momento en primera persona del plural, pero que no se diga, ya le he puesto aquí. }:))

    Saludos!

    ResponderEliminar
  4. anoninoninonino16/3/12 9:56 a. m.

    @Chema las 5 partes geniales. Pero tengo una dudilla.

    Pones al final al mismo nivel TOR que un Proxy y yo creo que es un error, ya que la "fortaleza" de un proxy depende enteramente de la conexión que esté realizando el cliente (si se asegura que es SSL y los cert son válidos...). En cambio con Tor la fortaleza o debilidad depende de si eres un nodo final o no, ya que a medida que pasas nodos se van añadiendo capas.

    No te servirá de nada estar troyanizando una red TOR si no eres un nodo final.

    Y a fin de cuentas, todo el mundo debería saber que TOR es bueno para el anonimato, pero no para la privacidad.

    ResponderEliminar
  5. Es más, podías mencionar a los verdaderos "pensaores" del tema.... que por la rooted se oían cosas muy feas...

    ResponderEliminar
  6. @Maligno, lo que da lastima es que te lo tengan que decir y que no salga de ti. Porque al fin y al cabo no todos estuvimos en la rooted.

    Y es muy fácil colgarse las medallas a costa de otros.

    ResponderEliminar
  7. @anónimo de "los pensadores". La idea, como está explicada en la primera parte del post, se la propuse yo a 3 de mis alumnos del master de la UEM por una charla que vi en la BH DC 2010. Luego se sumó un cuarto estudiante al proyecto y en la prueba de exposición, le pedí a mis chicos de i64 que asistieran. De ahí le propuse a Manu que hiciera la botnet y montara un Rogue Proxy, y el resto está aquí...

    Saludos!

    ResponderEliminar
  8. Completamente de acuerdo, y si aun despues de saber que TOR y cualquier tipo de proxy anonimo no es precisamente algo "seguro" aun se desea utilizar este tipo de técnologias, una buena recomendación seria utilizar navegadores independientes, tuneles cifrados con SSH y algunas extensiones de Firefos para la privacidad nunca vienen mal, como por ejemplo HTTPS Everywhere...
    Muy buenas publicaciones, gracias por compartir.

    ResponderEliminar
  9. Muy interesante el artículo
    Enhorabuena por el curro

    ResponderEliminar
  10. Hola Chema, como se manejaron con las legalidades? me podrías indicar donde va el disclaimer de los proxys?

    Gracias!

    ResponderEliminar