Detección de JavaScript malicioso con la puerta de enlace web segura de Secure Internet Access Enterprise
Escrito por: Jordan Garzon
Introducción
Imagine un mundo sin JavaScript. Ya ni recuerdo cuántas veces mis colegas y yo hemos pensado en esto en algún momento de nuestras carreras y, por el momento, es difícil imaginar un mundo sin JavaScript. Como alguien que trabaja en una empresa que lleva años lidiando con JavaScript, conozco bien los desafíos que presenta y su gran presencia en nuestro sector. De hecho, la protección de JavaScript sigue siendo una parte muy importante de nuestra misión, nos guste o no.
JavaScript está en todas partes. Todas las solicitudes a un sitio web o a una aplicación móvil cargan decenas de líneas de código JavaScript, y todos los navegadores están preparados para ello. Su presencia es tan elevada que se podría considerar fácilmente una tecnología crítica. Es una tecnología que define la forma en que se construyen y funcionan los sitios web. Y, como todos sabemos, si hablamos de seguridad, cuanto más crítica sea una tecnología, más formas hay de usarla de un modo malicioso.
Debido a su presencia generalizada, el uso de JavaScript proporciona a los adversarios la oportunidad de generar daños significativos utilizando de forma incorrecta la enorme superficie de ataque que ofrece JavaScript. El impacto potencial de un vector grande fue ilustrado por la vulnerabilidad Log4j que se descubrió en diciembre de 2021, un vector de ataque que proporcionó escalabilidad inmediata una vez que se detectó. Log4j, una biblioteca Java, incluye función de registro, una funcionalidad básica que utilizan casi todos los desarrolladores. Esa es la diferencia entre las vulnerabilidades de JavaScript y otras vulnerabilidades: su enorme presencia en el código de producción.
Si tenemos todo esto en cuenta, la pregunta constante es la siguiente: "¿Qué podemos hacer?" Después de ver los estragos que causó Log4j, decidimos intentar responder definitivamente a la pregunta e iniciamos una investigación para comprender y detectar JavaScript malicioso. El resultado es el proyecto sobre el que escribo hoy. Las investigaciones sobre seguridad siempre son entretenidas y, cuando vimos que nuestra teoría funcionaba, fuimos un paso más allá y probamos algunas situaciones contextuales del mundo real.
En esta publicación del blog, quiero hablarles de nuestra investigación y de las técnicas que hemos utilizado para identificar y aislar JavaScript malicioso con el fin de crear una nueva función en nuestro producto. Se incluye un análisis del panorama de amenazas relacionadas con JavaScript, como la arquitectura del sistema, los algoritmos aplicados y un caso real.
Panorama de amenazas de JavaScript malicioso
Antes de entrar en materia, echemos un vistazo al panorama que hace que el JavaScript malicioso sea un vector de amenaza tan destacado. Ya he hablado de su omnipresencia, pero ¿cuál es su alcance real? Si comprendemos este factor, conseguiremos poner realmente el proyecto en perspectiva. A continuación, se describen algunos de los ataques más frecuentes que utilizan JavaScript en el mundo real.
Vulnerabilidad del navegador
No hace falta que les explique las increíbles dimensiones de esta amenaza: los navegadores y los plugins de los navegadores son un elemento clave de cualquier persona que usa un ordenador. Un gran ejemplo es The Browser Exploitation Framework Project, también conocido como BeEF. BeEF es una herramienta de pruebas de penetración centrada en navegadores web, uno de los mayores vectores de ataque del lado del cliente, que refleja muy bien la vulnerabilidad.
Ladrones de información
Los ladrones de información son un famoso ejemplo de cómo la ciberseguridad puede afectar a la vida fuera del mundo empresarial y convertirse en algo muy personal. Puesto que JavaScript controla el modelo de objetos de documento, puede modificar no solo el HTML generado, sino también las solicitudes HTTP destacadas. Con solo hacer clic en un botón, se puede ver esta acción.
Se puede obtener un ejemplo del mundo real de cualquier sitio que ofrezca comercio digital. Si se inyecta JavaScript malicioso en un sitio web benigno, todas las credenciales de la tarjeta de crédito capturadas por el ladrón de información se pueden redirigir al atacante. El caso más destacado fue el ataque de Magecart de 2018 en el sitio web de British Airways, del que se robaron aproximadamente 380 000 números de tarjeta de crédito.
El robo de información ha cambiado desde 2018. Una forma común de utilizar esta técnica actualmente es reemplazar las direcciones bitcoin por la dirección del atacante en un sitio web benigno, tal como ha ocurrido con el grupo Lazarus en los últimos años.
Clickjacking
Aunque operar en un sitio web benigno ofrece una amplia difusión, su alcance es limitado en comparación con un servidor sobre el que mantiene un control total. Si el atacante logra que el usuario se acerque, tiene la ventaja de jugar en casa, lo que permite al atacante tener un impacto mucho mayor. Una vez que las víctimas llegan a su territorio, el atacante puede hacer que descarguen malware, recuperar información de su sesión de navegación y realizar muchas otras actividades maliciosas.
Uno de los métodos clásicos consiste en crear un iframe transparente sobre uno legítimo, lo que da a los usuarios una falsa sensación de seguridad cuando hacen clic en él. Este iframe redirige a los usuarios al servidor controlado por el atacante, donde los atacantes pueden ejecutar sus innumerables actividades maliciosas.
Criptominería no autorizada
La criptominería ha despertado un gran interés en los últimos años con el increíble aumento de la criptomoneda que se usa en la actualidad. ¿Por qué no utilizar la CPU del usuario para minar criptomonedas? Sobre todo si solo se necesita una línea de JavaScript. La biblioteca más famosa era Coinhive, que se supone que dejó de funcionar en 2019, pero han aparecido otras como CoinIMP o CryptoLOOT.
Motor de detección de JavaScript malicioso: arquitectura y algoritmos
Después de repasar el panorama, es hora de hablar de lo que hemos creado. Hay dos formas de introducir JavaScript en un sitio web: escribiendo un archivo JavaScript en el mismo servidor o utilizando uno existente de otra fuente e insertando el enlace en la página HTML. En el lado del proxy, veremos dos solicitudes HTTP diferentes: una para el archivo HTML y otra para el archivo JavaScript. Al acceder a un solo sitio web, su navegador puede realizar cientos de solicitudes HTTP para mostrar todo el contenido del sitio web.
También puede escribir el código JavaScript en el HTML. Por tanto, no se necesitan solicitudes adicionales para recuperarlo. Si hablamos sobre cómo detectar JavaScript malicioso, tiene que haber una manera de abordar ambas solicitudes, que es lo que hemos creado.
Nuestro nuevo motor logra extraer los códigos JavaScript "en línea" y analizarlos por separado. A continuación, se muestra un extracto de la página fuente de The New York Times donde se muestran estos dos tipos de JavaScript:
Extracto de código HTML del sitio web de The New York Times (https://www.nytimes.com/) del 2 de febrero de 2022
La puerta de enlace web segura (SWG) Akamai Secure Internet Access Enterprise está compuesta por diferentes motores que analizan el tráfico en tiempo real. También está conectada a nuestra inteligencia ante amenazas e incluye nuestros algoritmos personalizados.
High-level overview of the Enterprise Threat Protector secure web gateway
Vamos a ver con más detalle el cuadro rojo con la leyenda "JS Models" (Modelos de JavaScript):
Base de datos
Los modelos dependen de una base de datos relacional para mantener metadatos y almacenar el código JavaScript real a través de un proveedor de almacenamiento.
La base de datos incluye un conjunto de formación, es decir, nuestros datos etiquetados. Los datos benignos provienen principalmente de JavaScript popular detectado en nuestro tráfico. Los datos maliciosos se corresponden con varias fuentes: VirusTotal (VT), detecciones de otros algoritmos y código malicioso que realmente detectamos. Por lo tanto, se actualizan constantemente.
La base de datos también incluye el conjunto de pruebas, que básicamente son los últimos días de tráfico que vemos en el proxy.
Modelo para la detección en tiempo real
Para poder detectar JavaScript malicioso en tiempo real, usamos reglas de YARA que implementamos en el Edge. Esas reglas se crean en función del conjunto de formación. Puesto que no resulta sencillo crear reglas, basamos un algoritmo en este documento que genera automáticamente reglas de Yara. Lo adaptamos para clasificar el código JavaScript de forma no binaria y cambiamos la lógica de generación de reglas, lo que significa que podemos actualizar el motor JavaScript malicioso que se ejecuta en la SWG a petición.
Example of a YARA rule generated with AutoYara
Enriquecimiento de inteligencia ante amenazas mediante el modelo de aprendizaje automático
Un problema conocido al que se enfrentan los investigadores al capturar JavaScript es la ofuscación, una técnica (también utilizada por sitios web benignos) que simplifica el código y lo convierte en texto incomprensible. Or Katz escribió una publicación de blog sobre esto en octubre de 2020.
Para detectarla, integramos nuestra lógica en un modelo inspirado en JStap, que se ejecuta en el árbol de sintaxis abstracto, (una representación en árbol del código), que es la forma en que evadimos esta técnica.
Un modelo de aprendizaje automático puede proporcionar mayor precisión que las reglas de YARA. Sin embargo, su implementación en el Edge para el análisis en tiempo real es un desafío. Por tanto, llegamos a un punto intermedio. Nuestro modelo se crea con el mismo conjunto de formación, analiza el tráfico sin conexión (en el entorno de aprendizaje automático Azure) y proporciona a la inteligencia ante amenazas lo que encuentra.
La inteligencia ante amenazas se revisa en todas las conexiones con la SWG. De esa manera, los clientes se benefician de la detección del modelo de aprendizaje automático.
Caso real
La mejor manera de demostrarlo es con un caso real. El 8 de marzo de 2022, el modelo de aprendizaje automático detectó JavaScript alojado en cigarettesblog[.]blogspot[.]com.
Este dominio, a partir del 10 de marzo de 2022, mostraba 0 detecciones en VT.
![Página de inicio de cigarettesblog[.]blogspot[.]com a 9 de marzo](/site/es/images/blog/2022/detecting-malicious-javascript-with-swg5.jpeg)
Home page of cigarettesblog[.]blogspot[.]com seen on March 9
En el siguiente extracto, el código JavaScript sustituye todos los enlaces HTML por direcciones URL maliciosas.
Uno de ellos, hxxps://myprintscreen[.]com/soft/myp0912.exe, que se ha comentado en el código, está descargando un troyano (4a6ffa02ff7280e00cf722c4f2235f0e318e6cc8a2b9968639ba715f1a38c834), que ha generado 23 detecciones en VT. Muchos proveedores señalaron otras URL como maliciosas en VT.
Se trata de un comportamiento clásico de JavaScript malicioso: sustituir las URL de las páginas, enviar solicitudes POST a otros dominios (consulte el siguiente extracto) o realizar un ataque de descarga involuntaria para colocar malware en el equipo del usuario.
![Código JavaScript extraído de cigarettesblog[.]blogspot[.]com el 9 de marzo de 2022](/site/es/images/blog/2022/detecting-malicious-javascript-with-swg6.png)
JavaScript code extracted from cigarettesblog[.]blogspot[.]com on March 9, 2022
URL:
myprintscreen[.]com/soft/myp0912.exe
www[.]blog-hits.com
Hash del archivo:
4a6ffa02ff7280e00cf722c4f2235f0e318e6cc8a2b9968639ba715f1a38c834 (troyano)
fc311d002d7139e0a58b00464731ba8d4faea4670cff9fedfb35057fe838c285 (archivo JavaScript cargado por nosotros el 10 de marzo)
Se ha detectado el mismo mecanismo en penis-photo.blogspot[.]com.br (el 10 de marzo), en mateyhderesa[.]blogspot.com (el 13 de marzo) y en playboy-college-girls.blogspot.sk (el 14 de marzo).
Resumen
Como comenté al comienzo de esta publicación, cualquier elemento crítico para la seguridad también se puede utilizar de forma maliciosa, y un lenguaje tan presente como JavaScript puede tener consecuencias importantes. También puede ser bastante difícil de descifrar; en una publicación anterior del blog se recogió que el 25 % del código malicioso que vemos está ofuscado. No se trata de un porcentaje insignificante y, considerando el porcentaje de Internet que vemos, es bastante representativo de su extensión.
Esta investigación comenzó como una manera de lograr que nuestros clientes estén más seguros, así que tomamos lo que encontramos y lo aplicamos a nuestra SWG. Tenemos dos nuevos modelos: modelo basado en reglas de YARA y modelo basado en aprendizaje automático. El modelo basado en las firmas de reglas de YARA analiza cualquier código JavaScript que pase por la SWG para ofrecer protección en tiempo real. El modelo basado en aprendizaje automático analiza minuciosamente el tráfico para actualizar la inteligencia ante amenazas en el Edge. Ambos modelos se actualizan y entrenan constantemente. Tienen en cuenta las amenazas más recientes, así como el nuevo JavaScript benigno del mundo real.
