Xurum: Descubrimiento de una nueva campaña contra Magento

El comercio digital es un sector muy atacado por los ciberdelincuentes en general, pero la gran popularidad de Magento lo ha convertido, por desgracia, en un objetivo especialmente atractivo (y lucrativo). En concreto, el ataque más notable es el de Magecart,  cuyo objetivo es implementar ataques de robo de información basados en JavaScript para obtener de forma ilícita información confidencial de los usuarios. Estos atacantes de Magecart aprovechan vulnerabilidades web muy conocidas para llevar a cabo esta adquisición.

Ha habido al menos siete grupos de amenazas dirigidas a tiendas Magento desde 2015, lo que pone de manifiesto la importancia de la plataforma y el éxito que los atacantes han logrado a través de este exploit.

A principios de 2022, surgió la vulnerabilidad CVE-2022-24086, que permitía a los atacantes explotar el motor de plantillas de Magento y ejecutar código PHP arbitrario en objetivos susceptibles. La vulnerabilidad se ejecuta en varios pasos, con vectores de ataque comunes que abusan del proceso de pago o de la funcionalidad de la lista de deseos. Desde su aparición, esta vulnerabilidad se ha convertido en el principal punto de entrada para numerosos atacantes de Magecart que tienen como objetivo tiendas Magento 2 vulnerables.

En los últimos meses, Akamai ha estado supervisando de cerca una campaña dirigida específicamente a un número relativamente pequeño de implementaciones de Magento. Llamamos a la campaña Xurum para hacer referencia al nombre de dominio del servidor C2 utilizado por los atacantes.

Durante la campaña en curso, observamos que los atacantes intentaban ejecutar dos cargas distintas desde un total de cuatro direcciones IP (Figura 1). Estas IP están asociadas a la infraestructura de dos proveedores de alojamiento: Hetzner en Alemania y Shock Hosting en Estados Unidos.

Durante nuestra investigación del servidor xurum.com, se hizo evidente que está ubicado físicamente en los Países Bajos (Figura 4) y alojado por la empresa de alojamiento rusa VDSina.ru (Figura 5).

Como hay varias iteraciones de este ataque, decidimos llamarlo xurum para distinguir esta campaña del resto.

Con frecuencia, los atacantes emplean distintas convenciones de nomenclatura para sus dominios o malware, que, de manera inadvertida o deliberada, les sirven como distintivo. Durante nuestra investigación sobre el significado de "xurum", encontramos dos posibles interpretaciones.

Según el Traductor de Google, xurum se define como "bien" en latín, con el significado de "hacer lo correcto" (Figura 7). Por otra parte, el diccionario WordSense indica que xurum es la palabra correspondiente a "chico" en una lengua extinta que se hablaba en Guatemala (Figura 8).

Tenga en cuenta que, en el momento en que se escribió esta entrada del blog, los atacantes han desactivado su servidor xurum y se han trasladado a otro que parece estar todavía en fase de control de calidad.

El script PHP malicioso que se descarga del servidor xurum y se ejecuta en el equipo afectado consta de varias fases de infección.

En primer lugar, recopila información técnica sobre la víctima, como:

• Versión de PHP.

• Si el exploit aterrizó en el directorio "/pub" (estructura de directorios común en Magento).

• Si el archivo "/var/www/html/vendor/magento/google-shopping-ads/registration.php"  existe y es editable .

• El contenido del archivo "env.php", que incluye información crucial de la aplicación Magento, como ajustes específicos del entorno, pero también secretos como la clave de cifrado utilizada para proteger datos confidenciales como contraseñas, datos de tarjetas de crédito e información de los clientes.

A continuación, decodifica un blob oculto en Base64 y lo escribe en el archivo "/var/www/html/vendor/magento/google-shopping-ads/registration.php" (Figura 9).

El nuevo archivo tiene un contenido interesante. En lugar de mantener su propia copia de un shell web y alojarla en su servidor C2, el código del archivo nuevo apunta a un repositorio público de GitHub propiedad de un investigador de seguridad llamado "Bad Advertiser" o "@0xbadad". Dentro de este repositorio, hay un shell web conocido llamado wso-ng. Sin embargo, lo que resulta especialmente interesante es que el shell web no se registra en el disco del servidor. Sino que se obtiene y ejecuta únicamente en la memoria cuando se accede a la página recién creada "registration.php". Para protegerse aún más contra los accesos no autorizados, los atacantes también requieren la presencia de una cookie específica, "magemojo000", en la solicitud para que el shell web se ejecute correctamente.

A continuación, el atacante registra la nueva funcionalidad del shell web como un nuevo componente de Magento enmascarado como "GoogleShoppingAds" (Figura 10).

Después de instalar la puerta trasera, los atacantes extraen información sobre los métodos de pago de los pedidos de venta de los últimos 10 días y filtran estos datos a su zona de descarga de xurum.com, junto con la información técnica recopilada anteriormente (Figura 11).

En el último paso, los atacantes crean un usuario administrador de puerta trasera con el nombre "mageworx" (o "mageplaza" en algunas variantes). Estos nombres corresponden a las populares tiendas de extensiones de Magento 2, Mageworx y Mageplaza (Figura 12). Esta elección de nombres parece ser un intento de camuflar sus acciones como si se tratase de actividades legítimas relacionadas con estos reputados proveedores de extensiones.

Nótese un detalle interesante en las direcciones de correo electrónico de los usuarios de puerta trasera. Hay una doble "z" en "mageplazza" en la dirección de correo electrónico developer@mageplazza.com, mientras que el dominio legítimo de la tienda tiene una sola "z" en su nombre mageplaza.com, por lo que parece una errata de los atacantes. Existe una errata similar en la dirección de correo electrónico del otro usuario de puerta trasera: support@magaworx.com,  con una "a" en lugar de una "e" como en el nombre original de la tienda Mageworx.

Un shell web es un script o fragmento de código malicioso que los atacantes cargan y ejecutan en un servidor web para obtener acceso y control no autorizados sobre el servidor y sus archivos y datos subyacentes de forma persistente.

En esta operación, los atacantes aprovechan el avanzado shell web llamado wso-ng, que, como se ha mencionado anteriormente, fue creado por un investigador de seguridad hace varios años. Como afirma el autor, wso-ng es una nueva generación del antiguo y famoso WSO (del inglés Web Shell by Orb). 

Además de la funcionalidad típica de los shells web, como la recopilación de información del sistema y la gestión de archivos y SQL, wso-ng tiene otras características notables que lo hacen destacar (Figura 13).

Una de estas nuevas características es la página de inicio de sesión oculta. Al acceder a la página, esta responde con un código de estado HTTP 404 No encontrado, dando la impresión de que la página no existe. A primera vista, el contenido visible parece estar en blanco (Figura 14). Sin embargo, al inspeccionar el código fuente de la página, se descubre un formulario de inicio de sesión oculto.

El formulario se oculta de forma ingeniosa al usuario mediante un sencillo truco de CSS, por el que se desplaza 1000 píxeles a la izquierda, manteniéndolo fuera de la zona visible. Este formulario de inicio de sesión oculto está diseñado para esperar a que el usuario escriba la contraseña.

Encontramos otra herramienta interesante en el arsenal de los atacantes en el servidor xurum.com: un exploit público de un CVE-2016-5195 más antiguo denominado Dirty COW para derivaciones de privilegios locales en Linux (Figura 15).

Dado que muchos de nuestros clientes del firewall de aplicaciones web (WAF) mitigaron esta campaña de manera eficaz, no observamos directamente otras acciones llevadas a cabo por los atacantes. Sin embargo, durante nuestra investigación, observamos nombres de sitios web que estaban indirectamente relacionados con esta campaña y que aparecían en el encabezado HTTP de origen o referencia de la solicitud del exploit.

Al menos uno de estos sitios web estaba infectado con un sencillo sistema de ataque de robo de información web. El sistema de robo de información se instaló en la página principal sin aplicar ninguna técnica de ofuscación. Recopilaba la información de la tarjeta de crédito y la extraía a una zona de descarga alojada en "smileface.site" (Figura 16).

Al intentar acceder, este sitio web responde con un frío mensaje "Get out!" (Figura 17).

La información de la IP muestra que el servidor se encuentra en Moscú y está alojado en el servicio de alojamiento ruso "reg.ru" (Figura 18).

Nuestra investigación sobre esta campaña indica que se remonta al menos a finales de enero de 2023. Los atacantes han mostrado un enfoque meticuloso, dirigiéndose a instancias específicas de Magento 2 en lugar de esparcir sus exploits por Internet de forma indiscriminada. Demuestran un alto nivel de experiencia en Magento e invierten un tiempo considerable en comprender su funcionamiento interno, configurar la infraestructura de ataque y probar sus exploits en objetivos reales.

Esta campaña sirve como ejemplo práctico de cómo las vulnerabilidades más antiguas siguen siendo explotadas años después de su aparición, mientras las empresas se esfuerzan por adaptarse con parches y medidas de seguridad.

Para evitar el acceso inicial al servidor, se recomienda a los profesionales de la seguridad que se mantengan al día con los parches más recientes y que los complementen con la implementación de un WAF, como App & API Protector de Akamai.

Dado que el objetivo principal de estos atacantes de Magecart es infectar las páginas de Magento con sistemas de robo de información web para sustraer los datos de las tarjetas de crédito de los clientes, se recomienda encarecidamente el uso de soluciones de seguridad específicas adicionales. Estas soluciones deben proporcionar visibilidad sobre los comportamientos de los scripts del navegador y defender contra los ataques del lado del cliente.

Un enfoque eficaz consiste en implementar medidas de seguridad más próximas al lugar donde se producen los verdaderos ataques a los clientes. Esto incluye la identificación de intentos de lectura de campos de entrada confidenciales y la filtración externa de datos. Recomendamos recopilar estos eventos lo antes posible para facilitar una mitigación rápida y eficaz con la ayuda de productos de seguridad como Page Integrity Manager de Akamai.

Durante nuestro análisis de los recientes intentos de ataques de Magento CVE-2022-24086 contra nuestros clientes, descubrimos campañas adicionales que se están investigando en estos momentos. Seguiremos investigando y compartiremos nuestros hallazgos con la comunidad de seguridad. Para obtener más información sobre las últimas investigaciones en seguridad, síganos en Twitter.

Los siguientes indicadores de compromiso (IoC) se presentan para ayudar a la comunidad a detectar la actividad maliciosa descrita en la publicación.