- Uso de canales de datos WebRTC para exfiltrar datos de tarjetas evitando la inspección de tráfico HTTP.
- Aprovechamiento de la vulnerabilidad PolyShell en Magento y Adobe Commerce para la inyección inicial.
- Capacidad de saltarse las políticas de seguridad CSP mediante la sustracción de nonces legítimos.
Imagínate que tienes tu tienda online blindada, con los mejores firewalls y una política de seguridad de contenido impecable. Pues resulta que los ciberdelincuentes han encontrado una puerta trasera invisible que deja en ridículo las defensas tradicionales. Recientemente, Sansec ha dado la voz de alarma sobre un skimmer de pagos que no juega según las reglas habituales, utilizando una tecnología pensada para videollamadas para vaciar las carteras de los clientes.
Este ataque es un auténtico dolor de cabeza para los administradores de sistemas porque no utiliza los típicos métodos de envío de datos. Mientras que los skimmers de siempre mandan la información mediante peticiones HTTP o imágenes falsas, este nuevo espécimen usa canales de datos WebRTC. Esto significa que el robo ocurre en un plano que la mayoría de las herramientas de monitoreo ni siquiera miran, convirtiendo la exfiltración en un proceso prácticamente indetectable.
El truco maestro: ¿Por qué WebRTC es tan peligroso?
La clave del éxito de este malware reside en que WebRTC establece conexiones punto a punto (P2P) utilizando el protocolo DTLS sobre UDP. Para que nos entendamos, la gran mayoría de los WAF (Web Application Firewalls) y los sistemas de inspección de red están diseñados para analizar el tráfico web convencional. Al viajar los datos cifrados por una vía distinta a la TCP/HTTP, el robo de datos pasa totalmente desapercibido para el radar de seguridad.
Pero lo más grave es el agujero que deja en la Content Security Policy (CSP). La CSP es esa regla que le dice al navegador: «solo confía en estos dominios». Sin embargo, RTCPeerConnection no está regulada por las directivas estándar de CSP. Así que, aunque tengas una configuración restrictiva que bloquee cualquier conexión HTTP externa, el skimmer puede seguir sacando la información de las tarjetas porque la política de seguridad simplemente no sabe cómo detener a WebRTC.
La puerta de entrada: El agujero de PolyShell
Para que este script malicioso llegue al navegador del usuario, primero tiene que entrar en la tienda. Aquí es donde entra en juego PolyShell, una vulnerabilidad crítica que afecta a las plataformas Adobe Commerce y Magento Open Source. Este fallo permite que cualquier atacante, sin necesidad de tener una cuenta, suba archivos maliciosos a través de la API REST y ejecute código en el servidor.
Los datos son escalofriantes: desde mediados de marzo se detectó una oleada de escaneos masivos provenientes de más de 50 direcciones IP. Se estima que el 56,7% de las tiendas vulnerables ya han sido comprometidas. Una vez que el atacante logra meter el pie gracias a PolyShell, inyecta el skimmer en el proceso de pago, dejando la tienda convertida en una trampa para los clientes.
Análisis técnico del ataque y robo de nonces
El funcionamiento interno de este malware es una obra de ingeniería maliciosa. El script se ejecuta automáticamente y crea una conexión hacia la dirección IP 202.181.177.177 en el puerto UDP 3479. Lo curioso es que el malware no necesita un servidor de señalización externo; tiene todo el apretón de manos SDP (Session Description Protocol) hardcodeado en el código, lo que agiliza la conexión directa con el servidor de comando y control (C2).
Para evitar que el navegador bloquee la ejecución del payload, el skimmer emplea una técnica muy astuta: roba el nonce de la CSP. Busca etiquetas de script legítimas que ya estén en la página, copia su código de validación (el nonce) y lo aplica a su propio script malicioso. De este modo, el navegador piensa que el código del atacante es parte oficial del sitio y lo ejecuta sin rechistar.
Cómo blindar tu e-commerce frente a esta amenaza
Si tienes una tienda online, no puedes quedarte de brazos cruzados. Lo primero y más urgente es actualizar Magento y Adobe Commerce a las versiones que corrigen PolyShell. No es una sugerencia, es una necesidad vital, ya que los atacantes han automatizado la explotación de este fallo a una velocidad increíble.
- Bloqueo de directorios: Es fundamental restringir el acceso a la ruta
pub/media/custom_options/para cortar el vector de entrada. - Monitoreo de integridad: Utiliza herramientas que detecten cambios no autorizados en el JavaScript de tu web, ya que el análisis de red no será suficiente.
- Revisión de terceros: Haz una limpieza de scripts externos cada trimestre. Menos plugins y widgets significan menos puntos de ataque disponibles.
- CSP Experimental: Aunque no es un estándar total, Chrome permite algunas directivas para restringir WebRTC que podrías intentar implementar.
Es fundamental entender que confiar solo en la CSP o en el firewall es un error garrafal. Este incidente demuestra que los grupos de Magecart están evolucionando y que el juego es una carrera constante. La única defensa real es la protección en capas, combinando parches actualizados, auditorías de código y un monitoreo constante del comportamiento de los formularios de pago.
La aparición de este método basado en WebRTC marca un punto de inflexión en la ciberdelincuencia, ya que convierte la infraestructura de comunicación moderna en un arma para el robo de datos masivo, afectando incluso a gigantescorporativos y bancos. La rapidez con la que se ha explotado la vulnerabilidad PolyShell y la capacidad de evadir los controles de seguridad habituales obligan a los dueños de tiendas a adoptar una postura de vigilancia extrema y actualización inmediata para evitar el colapso de su confianza y su negocio.
