El ciberataque a Segway explicado

Resumen: skimmer Magecart del favicon booctstrap de Segway

• Un payload en un favicon: Un favicon debería servir píxeles, no payloads. Los atacantes de Segway escondieron un skimmer de Magento dentro de un archivo favicon que apuntaba a booctstrap[.]com, y todos los threat feeds volvieron a llegar tarde.
• Inspección del payload completo: El script malicioso se mostraba como un falso texto de copyright en el pie de página mientras cargaba silenciosamente un skimmer alojado en el favicon desde booctstrap[.]com para capturar los datos de las tarjetas. cside inspecciona el payload completo de cada script de terceros antes de que el navegador lo ejecute.
• Verifica cada dominio: Si tu tienda Magento carga algún script por nombre desde un partner de diseño o un plugin, verifica cada dominio hoy mismo. Si no puedes verificarlos todos, pon un análisis de scripts en tiempo de ejecución delante de la tienda antes de que el próximo atacante esconda un skimmer en un recurso de imagen.

¿Poco tiempo? Consulta el bloqueo de Magecart y skimmers en el navegador de cside. Cubre todo lo de abajo en un solo despliegue.

En enero de 2022, la tienda web de Segway sufrió un ataque a la cadena de suministro web, también conocido a menudo como ataque Magecart. En este tipo de ataques, se añade código JavaScript malicioso que se carga desde el lado del cliente, conocido como scripts de terceros.

Muchas herramientas habituales son scripts de terceros: analíticas, captchas y más. Pero esta vía también puede utilizarse con fines maliciosos, como fue el caso aquí.

En este ataque a Segway, su tienda está montada sobre Magento. Los atacantes se aprovecharon de vulnerabilidades en el propio CMS o en alguno de los plugins instalados en el sitio de Segway. Tras vulnerar el sitio, añadieron el JavaScript que aparentaba mostrar el copyright del sitio, pero que en realidad se usaba para cargar un favicon externo.

Dentro de ese archivo favicon se ocultaba un dominio malicioso, 'booctstrap[.]com'. Como puede verse en esta imagen de Malwarebytes, quienes destaparon el ataque:

Ese dominio cargaba el código JavaScript malicioso de terceros, cuyo objetivo era capturar los datos de tarjetas de crédito de los usuarios.

Como se vio más recientemente en el ataque a Polyfill de 2024.

Cómo no protegerse contra esto

Las listas de amenazas siguen siendo la solución más utilizada para resolver este problema, pero sostenemos que no es el enfoque preferible. En esencia, no pueden detectar lo que no conocen. Los atacantes registran un nuevo dominio y, sin necesidad de reescribir ningún código, el ataque vuelve a estar activo. Durante días, o a veces semanas, hasta que se detecta de nuevo y las listas de amenazas actualizan sus registros.

cside fue diseñado para detener estos ataques a la cadena de suministro web antes de que ocurran.

Al colocar estos scripts de terceros en un proxy y analizar el payload completo del código antes de que se cargue, detectamos código malicioso como el de este ejemplo. Lo bloqueamos, evitando que afecte al usuario, y alertamos al propietario del sitio web sobre el posible ataque.

Además, guardamos el código de los scripts para que el propietario del sitio pueda revisarlo después del incidente y resolver el problema de raíz.

Se presta demasiado poca atención a estos ataques del lado del cliente. Si otras medidas de seguridad fallan, como ocurrió en el caso de Segway, este ataque igualmente podría haberse detectado. Monitorizando exactamente lo que ocurre en el navegador del usuario, se habría detectado y detenido la exfiltración de datos.

Regulación

Como se ve en este caso, el comercio electrónico es a menudo un objetivo. Y la regulación está avanzando: PCI DSS 4.0 exige ahora la monitorización de scripts de terceros en las páginas de pago (a partir de marzo de 2025). Aunque celebramos esto, te instamos a aplicarlo en todas las páginas de tu sitio web. En abril de 2024, lo explicamos en detalle, por qué no hacerlo sigue exponiendo tu sitio a un riesgo significativo.

Además de otros problemas explicados en ese artículo, los actores maliciosos podrían aprovechar scripts comprometidos en tu sitio para secuestrar sesiones de usuario, suplantar identidades y realizar acciones no autorizadas, potencialmente eludiendo la autenticación de dos factores y saltándose así también la protección de tu portal de pagos.

Puedes usar cside para monitorizar scripts en todas las páginas y cumplir con esa parte de PCI DSS 4.0. Y puedes proteger tu sitio contra este tipo de ataques con cside.

Empieza en minutos, gratis.