Un paquete PyPi malicioso recién descubierto llamado ?disgrasya? que abusa de tiendas WooCommerce legítimas para validar tarjetas de crédito robadas ha sido descargado más de 34.000 veces desde la plataforma de paquetes de código abierto.

El script se dirigía específicamente a las tiendas WooCommerce que utilizan la pasarela de pago CyberSource para validar las tarjetas, lo cual es un paso clave para los actores de carding que necesitan evaluar miles de tarjetas robadas de vertederos de la web oscura y bases de datos filtradas para determinar su valor y potencial explotación.

Aunque el paquete ha sido retirado de PyPI, su elevado número de descargas demuestra el enorme volumen de abuso para este tipo de operaciones maliciosas.

"A diferencia de los típicos ataques a la cadena de suministro que se basan en el engaño o la typosquatting, disgrasya no hizo ningún intento de parecer legítimo", explica un informe de los investigadores de Socket.

"Era abiertamente malicioso, abusando de PyPI como canal de distribución para llegar a un público más amplio de estafadores".

De particular interés es el descarado abuso de PyPi para alojar un paquete que los creadores indicaban claramente en la descripción que se utilizaba para actividades maliciosas.

"Una utilidad para comprobar tarjetas de crédito a través de múltiples pasarelas utilizando multi-threading y proxies", se lee en la descripción del paquete disgrasya.

Socket señala que la funcionalidad maliciosa en el paquete se introdujo en la versión 7.36.9, probablemente un intento de evadir la detección por parte de los controles de seguridad que podrían ser más estrictos para los envíos iniciales en comparación con las actualizaciones posteriores.

Emulando compradores para validar tarjetas

El paquete malicioso contiene un script Python que visita sitios WooCommerce legítimos, recopila IDs de productos y luego añade artículos al carrito invocando el backend de la tienda.

A continuación, navega a la página de pago del sitio desde donde roba el token CSRF y un contexto de captura, que es un fragmento de código CyberSource usuarios para procesar los datos de la tarjeta de forma segura.

Según Socket, estos dos elementos suelen estar ocultos en la página y caducan rápidamente, pero el script los captura al instante mientras rellena el formulario de pago con información inventada del cliente.

En el siguiente paso, en lugar de enviar la tarjeta robada directamente a la pasarela de pago, la envía a un servidor controlado por el atacante (railgunmisaka.com), que se hace pasar por CyberSource y devuelve un token falso para la tarjeta.

Solicitud POST enviando los datos de la tarjeta

Fuente: Socket

Por último, el pedido con la tarjeta tokenizada se envía a la tienda web y, si se tramita, se comprueba que la tarjeta es válida. Si falla, registra el error e intenta con la siguiente tarjeta.

Resultados de la transacción impresos

Fuente: Socket

Utilizando una herramienta como ésta, los actores de la amenaza son capaces de realizar la validación de un gran volumen de tarjetas de crédito robadas de forma automatizada.

Estas tarjetas verificadas pueden utilizarse para cometer fraudes financieros o venderse en mercados de ciberdelincuentes.

Cómo bloquear los ataques de cardado

Socket comenta que este proceso de emulación de la compra de principio a fin es especialmente difícil de detectar para los sistemas de detección de fraudes en los sitios web atacados.

"Todo este flujo de trabajo - desde la recolección de identificadores de producto y tokens de pago, hasta el envío de los datos de la tarjeta robada a un tercero malicioso y la simulación de un flujo de pago completo - es muy específico y metódico", afirma Socket.

"Está diseñado para mezclarse con los patrones de tráfico normales, lo que hace que la detección sea increíblemente difícil para los sistemas tradicionales de detección de fraude".

Aun así, Socket afirma que existen métodos para mitigar el problema, como bloquear los pedidos de muy poco valor inferiores a 5 dólares, que suelen utilizarse en los ataques de carding, vigilar múltiples pedidos pequeños que tengan tasas de fallo inusualmente altas, o volúmenes de pago elevados vinculados a una única dirección IP o región.

Socket también sugiere añadir pasos CAPTCHA en el flujo de pago que puedan interrumpir el funcionamiento de los scripts de carding, así como aplicar límites de velocidad en los puntos finales de pago.

Fuente: bleepingcomputer