Skip to main content

Los atacantes abusan del archivo Swap para robar tarjetas de crédito

julio 23, 2024


En lo que respecta a la seguridad de los sitios web, a veces las funciones más inocuas pueden convertirse en herramientas poderosas en manos de los atacantes. Tal fue el caso de un incidente reciente que investigamos, en el que los actores maliciosos explotaron el humilde archivo de intercambio para mantener un escáner de tarjetas de crédito persistente en un sitio de comercio electrónico de Magento. Esta táctica inteligente permitió que el malware sobreviviera a múltiples intentos de limpieza, es decir, hasta que nuestros analistas concluyeron su investigación.

En esta publicación, analizaremos en profundidad este sofisticado ataque al comercio electrónico y ofreceremos información valiosa sobre cómo puede proteger su propia tienda en línea de amenazas similares.

¡Vamos a ver!

Inspeccionando el malware

Al navegar a la página de pago del sitio web comprometido, pudimos ver un script interesante oculto en el código fuente de la página.

El script tenía todos los indicadores habituales de malware, como variables codificadas en base64 y cadenas codificadas en hexadecimal. Pero una vez decodificado, pudimos ver algunos indicadores claros de que el script estaba buscando detalles de tarjetas de crédito.

Comportamiento malicioso en la página de pago

El siguiente fragmento habilita un botón de pago y agrega enlaces personalizados a la función de clic normal en la página de pago comprometida.

Una vez que se hace clic en el botón de pago, el script captura los datos ingresados ​​en el formulario de tarjeta de crédito a través de un consultaSelectorAll función como se ve aquí.

Otras variaciones de la función en otras partes del script capturan información confidencial como nombre, dirección, número de tarjeta y otros datos que necesitan los atacantes para utilizar los datos de la tarjeta robada. También podemos ver un dominio, Amazon Analítica[.]conutilizado por los atacantes para recuperar los datos de la tarjeta de crédito robada.

Este análisis de Amazon[.]El dominio .com se registró en febrero de 2024 y también se ha visto que se utilizó en otros casos anteriores de robo de tarjetas de crédito. Tenga en cuenta el uso del nombre de marca; esta táctica de aprovechar productos y servicios populares en los nombres de dominio suele ser utilizada por actores maliciosos en un intento de evadir la detección.

Rastreando el código fuente hasta bootstrap.php

Una vez que desciframos la página de pago, llegó el momento de encontrar la fuente. Una investigación más profunda nos llevó a Magento aplicación/bootstrap.php archivo que ha sido reemplazado completamente de la versión oficial.

Al descifrar ese contenido base64 se reveló el código malicioso exacto que se encontró en la fuente de la página de pago. También localizamos el rizo función utilizada por los atacantes para filtrar los datos robados a su dominio externo.

El devolución de llamada de filtro ob La función se utiliza para agregar el script skimmer a las páginas web si sus URL contienen la palabra clave “checkout” y las páginas se solicitaron mediante el método GET.

El proceso de eliminación de malware

Pensamos que eliminar el malware debería ser tan simple como reemplazar aplicación/bootstrap.php con la versión correcta y luego borrando cachés, ya que sabemos que el contenido es el que estamos viendo en el checkout, ¿no? Bueno, no en este caso.

Una vez que reemplazamos el archivo con el contenido correcto, notamos que el script todavía se estaba cargando en el proceso de pago. No es imposible que los archivos se vuelvan a infectar con bastante rapidez, por lo que volvimos a analizarlo. programa de arranque.php con nuestras herramientas de limpieza de malware y noté que el malware había regresado.

Lo que fue especialmente extraño fue que cuando miramos el archivo en el servidor directamente a través de SSH, estaba completamente limpio.

Sin embargo, cuando buscamos en el sistema de archivos indicadores del malware utilizando nuestras herramientas de limpieza, el malware seguía apareciendo.

Como prueba adicional, copiamos el archivo aparentemente infectado. programa de arranque.php archivo a un nuevo nombre de archivo —bootstrap.php.clean— y lo revisamos con nuestras herramientas de limpieza de malware. El contenido del archivo era correcto.

Entonces, de alguna maneraparecía que el archivo estaba limpio e infectado al mismo tiempo (¿malware de Schrödinger?).

No sucede a menudo, pero en ocasiones el malware permanece en la memoria y puede acceder a los datos de la sesión de archivo. Reiniciamos los servicios Apache y PHP y, finalmente, reiniciamos todo el servidor para intentar solucionar el problema. Sorprendentemente, el malware seguía allí y claramente nos estábamos perdiendo algo.

Volver a lo básico: intercambiar archivos

Volvimos a revisar el script de malware y el archivo donde se originó el script y notamos algo interesante en la parte inferior.

A primera vista, no parecía haber ningún archivo con ese nombre en el servidor.

El Intercámbiame Parte del nombre del archivo nos indicó que podría haber algún archivo swap por ahí. Cuando los archivos se editan directamente a través de ssh, el servidor creará una versión «swap» temporal en caso de que el editor falle, lo que evita que se pierda todo el contenido.

Aunque no pudimos ver nada ~intercambiame archivo con el es comando, ejecutando un comando vi en bootstrap.php-swapme Editar directamente el archivo de intercambio reveló que el archivo estaba efectivamente allí y que contenía exactamente el mismo contenido que la versión infectada de programa de arranque.php.

Se hizo evidente que los atacantes estaban aprovechando un archivo de intercambio para mantener el malware presente en el servidor y evadir los métodos normales de detección. Eliminamos ese archivo de intercambio, borramos los cachés nuevamente y listo: la fuente de la página de pago finalmente estaba limpia.

Mitigación de futuros ataques

El uso indebido del sistema de archivos de intercambio por parte del atacante resalta la importancia de las medidas de seguridad que van más allá de Escaneos y limpiezas a nivel de superficie. En este caso, estaba claro que los atacantes pudieron acceder a través de SSH o alguna sesión de terminal, de lo contrario no habríamos encontrado el archivo de intercambio que se creó cuando se editó el archivo.

Para mitigar el riesgo de infecciones persistentes de malware de comercio electrónico como esta, puede restringir sFTP, SSH, FTP, CPanel y cualquier otro acceso de administrador a direcciones IP confiables. Si bien las restricciones de FTP y SSH deben configurarse directamente en el servidor de alojamiento, nuestro cortafuegos del sitio web También agrega capas adicionales de protección para evitar el acceso no deseado a áreas como los paneles de administración de WordPress y Magento. También es una buena práctica mantener actualizados el CMS y los complementos o módulos. Las versiones anteriores del software de sitios web suelen contener vulnerabilidades que los atacantes pueden explotar fácilmente con herramientas de ataque automatizadas.

Si cree que su sitio ha sido infectado, nuestros analistas de seguridad experimentados están Disponible 24×7 para ayudar a limpiar el malware en el entorno de su sitio web. Si prefiere hacerlo usted mismo, también ofrecemos guías gratuitas con información detallada Pasos para limpiar un sitio web infectado.



Source link

Translate »