Los investigadores de ESET han descubierto y analizado un troyano previamente indocumentado que roba información de pago de los clientes de sitios web que se dedican al comercio electrónico. El troyano, al que hemos llamado IIStealer, es detectado por las soluciones de seguridad de ESET como Win64/BadIIS.
Esta publicación es la primera entrega de una serie en la que los investigadores de ESET analizan distintas amenazas que apuntan al servidor web IIS. Para obtener una guía completa sobre cómo detectar, analizar y eliminar el malware para IIS, consulte nuestro whitepaper Anatomy of native IIS malware, donde IIStealer aparece como una de las familias de malware analizadas (Grupo 5).
Resumen del ataque
IIStealer se implementa como una extensión maliciosa para Internet Information Services (IIS), el software del servidor web de Microsoft. Al ser parte del servidor, IIStealer es capaz de acceder a toda la comunicación de red que fluye a través del servidor y robar datos de interés para los atacantes; como son, por ejemplo, los datos de pago de transacciones que se realizan en sitios web de ecommerce.
Como se observa en la Imagen 1, IIStealer opera interceptando el tráfico regular entre el servidor comprometido y sus clientes (el vendedor y los compradores), apuntando a las solicitudes HTTP POST realizadas a rutas URI específicas:/checkout/checkout.aspx o checkout/Payment.aspx.
Siempre que un visitante legítimo de un sitio web realiza una solicitud en las páginas de pago (1), IIStealer registra el cuerpo de la solicitud HTTP en un archivo de registro (2), sin interferir de ninguna manera con la respuesta HTTP generada por los componentes del sitio web legítimo (3).
Los atacantes pueden entonces exfiltrar los datos recopilados haciendo una solicitud HTTP especial al servidor IIS comprometido: una vez que IIStealer detecta una solicitud realizada a un URI específico (/privacy.aspx) con una contraseña del atacante incluida en el encabezado X-IIS-Data (4), embebe los datos recopilados en la respuesta HTTP para esa solicitud (5,6).
Imagen 1. IIStealer: mecanismos de recolección y exfiltración de datos de los visitantes
Con estas capacidades, IIStealer puede robar los datos de las tarjetas de crédito introducidas en sitios web de comercio electrónico que no utilizan pasarelas de pago de terceros. Tenga en cuenta que SSL/TLS y los canales de comunicación cifrados no protegen estas transacciones contra IIStealer, ya que el malware puede acceder a toda la información que maneja servidor, que es donde se procesa la información de la tarjeta de crédito en su estado no cifrado.
Las muestras que analizamos de este malware parecen estar diseñadas para sitios de ecommerce específicos (con la URI de páginas de pago hardcodeada). Según nuestra telemetría, entre septiembre de 2020 y enero de 2021, el objetivo fue una pequeña cantidad de servidores IIS en los EE. UU. Sin embargo, considerando que todavía es común que los administradores no usen ningún software de seguridad en estos servidores, esto probablemente sea solo el reflejo de nuestra visión limitada sobre los servidores IIS.
Análisis técnico
IIStealer se implementa como un módulo nativo malicioso para IIS: una DLL en C ++ droppeada en la carpeta %windir%\system32\inetsrv\ del servidor IIS comprometido y se configura en el archivo %windir%\system32\inetsrv\config\ApplicationHost.config. En algunos casos, IIStealer se implementa con el nombre dir.dll y, como se observa en la Imagen 2, utiliza un recurso VERSIONINFO falsificado para imitar un módulo de IIS legítimo llamado dirlist.dll.
Imagen 2. Recurso VERSIONINFO en IIStealer (izquierda) imita el módulo legítimo dirlist.dll (derecha).
Debido a que es un módulo de IIS, IIStealer se carga automáticamente mediante el proceso de trabajo de IIS (w3wp.exe), que maneja las solicitudes enviadas al servidor web IIS. Así es como IIStealer logra la persistencia y cómo puede afectar el procesamiento de las solicitudes entrantes.
No tenemos ninguna información sobre cómo se propaga el malware, pero sabemos que se requieren permisos de administrador para instalarlo como un módulo nativo para IIS, lo que reduce las opciones de compromiso inicial. Una vulnerabilidad o fallo de configuración en una aplicación web o en el propio servidor probablemente sean los culpables del compromiso.
En cuanto a sus características técnicas, IIStealer implementa una clase Core heredada de CHttpModule (clase de módulo) y anula el método CHttpModule::OnPostBeginRequestcon su código malicioso. Al igual que con todos los módulos nativos para IIS, IIStealer exporta una función denominada RegisterModule (ver Imagen 3), donde crea una instancia de la clase del módulo y registra sus métodos para los eventos del servidor. Más específicamente, se registra para la notificación posterior al evento RQ_BEGIN_REQUEST que se genera cada vez que el servidor comienza a procesar una solicitud HTTP entrante. Como resultado, el método OnPostBeginRequest es llamado con cada solicitud nueva, lo que permite que IIStealer afecte el procesamiento de la solicitud.
Imagen 3. Punto de entrada del RegisterModule de IIStealer
En el controlador OnPostBeginRequest, IIStealer filtra las solicitudes HTTP mediante solicitud de URI. Todas las solicitudes POST realizadas a OnPostBeginRequest o /checkout/Payment.aspx se registran, junto con sus cuerpos HTTP completos, en un archivo llamado C:\Windows\Temp\cache.txt. Estas solicitudes las realizan visitantes legítimos de los sitios web de comercio electrónico comprometidos y pueden contener información confidencial, como datos personales y números de tarjetas de crédito.
Los datos recopilados se pueden filtrar a través de una solicitud HTTP diseñada específicamente por el atacante. Esta solicitud debe tener un encabezado X-IIS-Data configurado con una contraseña alfanumérica codificada de 32 bytes (que hemos elegido no revelar), y debe enviarse a una ruta especificada en la muestra de malware:
- /privacy.aspx
- /checkout/Payment.aspx
Una vez que el módulo malicioso detecta dicha solicitud, utiliza el método IHttpResponse::Clear para eliminar cualquier respuesta HTTP preparada por el servidor IIS y copia el contenido no cifrado del archivo de registro en el cuerpo de la respuesta HTTP mediante la función del API IHttpResponse::WriteEntityChunks, como se ve en la Imagen 4.
Imagen 4. IIStealer reemplaza el cuerpo de la respuesta HTTP con sus propios datos
Esto permite a los operadores de IIStealer acceder y filtrar los datos recopilados simplemente enviando una solicitud especial al servidor IIS comprometido; no es necesario que el malware implemente canales de C&C adicionales o embeba dominios de servidor C&C en su configuración.
Mitigación
IIStealer es una amenaza del lado del servidor que escucha a escondidas las comunicaciones entre un sitio de comercio electrónico comprometido y sus clientes con el objetivo de robar información de pago confidencial, pero por supuesto, los módulos para IIS maliciosos también pueden apuntar a credenciales y otra información. Aunque SSL/TLS es vital para asegurar la transmisión de datos entre el cliente y el servidor, no evita este escenario de ataque ya que IIStealer es parte del servidor. Esto debería ser inquietante para todos los portales web serios que se interesen por proteger los datos de sus visitantes, incluidos los datos de autenticación y la información de pago.
La mejor manera de fortalecer un servidor IIS contra IIStealer y otras amenazas es:
- Utilice cuentas dedicadas con contraseñas únicas y seguras para la administración del servidor IIS.
- Instale periódicamente las actualizaciones de seguridad para su sistema operativo y revise cuidadosamente qué servicios están expuestos a Internet para reducir el riesgo de explotación del servidor.
- Instale únicamente módulos nativos para IIS de fuentes confiables.
- Considere usar un firewall de aplicaciones web y/o una solución de seguridad para endpoints en su servidor IIS.
- Verifique regularmente el archivo de configuración %windir%\system32\inetsrv\config\ApplicationHost.config, así como las carpetas %windir%\system32\inetsrv\ y %windir%\SysWOW64\inetsrv para corroborar que todos los módulos nativos instalados son legítimos (firmados por un proveedor de confianza o instalado a propósito).
Para desarrolladores web: incluso si no tiene control sobre el servidor IIS donde está alojado su servicio web, aún puede tomar medidas para reducir el impacto en los usuarios de su servicio web en el caso de un compromiso, especialmente:
- No envíe la contraseña al servidor (ni siquiera a través de SSL/TLS); use un protocolo como Secure Remote Password (SRP) para autenticar a los usuarios sin la necesidad de que la contraseña sin cifrar se transmita al servidor, ni datos que puedan usarse para volver a autenticarse. Los infostealers para IIS son un buen ejemplo de por qué el hash del lado del servidor no es lo suficientemente bueno.
- Evite el envío innecesario de información sensible desde la aplicación web. Utilice pasarelas de pago.
- Si identifica un compromiso exitoso: notifique a todas las partes involucradas en cualquier brecha de seguridad para que puedan tomar medidas rápidas.
Para los consumidores: desde la perspectiva del visitante, es imposible saber si un servidor IIS está comprometido, pero estos consejos lo ayudarán a reducir el riesgo:
- Tenga cuidado dónde ingresa los datos de su tarjeta de crédito. Considere utilizar pasarelas de pago de proveedores externos confiables en sitios de comercio electrónico cuya reputación desconozca: el uso de pasarelas de pago de terceros quiere decir que dichos sitios no manejarán la información de pago confidencial.
- Esté atento a su estado de cuenta por si aparecen pagos pequeños o inusuales: a menudo se procesan pequeñas cantidades para probar si las tarjetas son válidas.
- Si detecta algo inusual, notifique a su banco de inmediato.
