Subestimando a #Javascript II - NSA (National Security Agency)

Para establecer un marco en este articulo, vamos a tomar consciencia de la existencia de la National Security Agency como organismo omnipresente en internet, en las comunicaciones y hasta en la sopa ( http://en.wikipedia.org/wiki/PRISM_(surveillance_program) ), entre las compañías mas involucradas están: Microsoft, Yahoo!, Facebook, Google, Apple y Dropbox. 

Para conectarnos con el articulo anterior "Subestimando a Javascript" (http://cxo-community.com/articulos/blogs/blogs-seguridad-informatica/5685-subestimado-a-javascript-i.html ) vamos a poner en claro que tanto Google, Yahoo, Facebook, etc. brindan servicios vinculados externamente desde Javascript o iFrame ( http://www.google.com/analytics/ http://yuilibrary.com/yui/quick-start/ https://developers.facebook.com/docs/reference/plugins/comments/ ) , esta vez vamos a plantearnos un caso hipotético que podría convertirse en realidad de tener los medios y recursos necesarios (que Google, Facebook, Yahoo y la NSA, aparentan tener).

Posible Vector de ataque

En el documento anterior ( Subestimando a Javascript http://cxo-community.com/articulos/blogs/blogs-seguridad-informatica/5685-subestimado-a-javascript-i.html ) habíamos planteado que se podría modificar un website desde una inclusión remota de un archivo Javascript o un iFrame, esto expone los sistemas que utilizan este tipo de servicios a los proveedores remotos de Javascript, vamos a explicar un caso practico. En la actualidad, una gran cantidad de sitios gubernamentales utilizan (quizás por comodidad) servicios como Google Analytics, que como lo explicado anteriormente utiliza inclusión remota de Javascript alojado en servidores de Google.

El Posible

Imaginemos por un segundo que Google quisiese hacerse con el usuario y la contraseña de administración de algún sitio gubernamental de los que utilizan el servicio Google Analytics, Google buscaría atacar a un usuario particular, al administrador, que usando otros recursos podría identificar y ahí comenzaría el ataque ...

Cuando el usuario objetivo se dirigiese al sitio afectado (pongamos como ejemplo www.sitiodegobierno.gob.ar/gestion ), Google enviaría una versión modificada de ga.js ( archivo de inclusión remota ) en donde aparte de comportarse como debería, también adjuntaría una rutina de modificación para el formulario que requiere usuario y contraseña para así realizar un ataque de MiTM ( https://www.owasp.org/index.php/Man-in-the-middle_attack )

Impacto

Es claro que el impacto en este ejemplo es el robo de credenciales de acceso administrativas pero esto se puede extender a un defacement ( http://en.wikipedia.org/wiki/Website_defacement ) lo que afectaría la imagen corporativa. 

Aclaraciones

• El ataque debería ser concretado desde Google.
• El ataque afecta al cliente y no al servidor por lo cual para el dueño del sitio es completamente invisible.
• El hecho de que el sitio corra sobre HTTPS ( http://en.wikipedia.org/wiki/Secure_Socket_Layer ) no afecta al resultado final.
• El ataque emula un ataque de Phishing ( https://www.owasp.org/index.php/Phishing ).

Conclusiones

Para sitios que podrían ser un claro objetivo de Agencias de inteligencia o si deseamos que nuestro sitio no pueda ser modificado por el gran hermano, recomendamos no usar bajo ningún punto inclusiones remota en el cliente sea iFrame o Javascript.

este articulo es republicado, la version original fue publicada el 23 de Octubre de 2013