Robo de tarjetas de crédito: el largo y sinuoso camino del fracaso de la cadena de suministro

Los investigadores de la empresa de seguridad de aplicaciones Jscrambler acaban de publicar un cuento con moraleja sobre los ataques a la cadena de suministro...

… ese también es un poderoso recordatorio de cuán largas pueden ser las cadenas de ataque.

Lamentablemente, eso es largo simplemente en términos de equipo, no larga en términos de complejidad técnica o el número de eslabones de la propia cadena.

Hace ocho años…

La versión de alto nivel de la historia publicada por los investigadores se cuenta simplemente, y dice así:

• A principios de la década de 2010, una empresa de análisis web llamada Cockpit ofreció un servicio de análisis y marketing web gratuito. Numerosos sitios de comercio electrónico utilizaron este servicio obteniendo código JavaScript de los servidores de Cockpit, incorporando así código de terceros en sus propias páginas web como contenido de confianza.
• En diciembre de 2014, Cockpit cerró su servicio. Se advirtió a los usuarios que el servicio se desconectaría y que cualquier código JavaScript que importaran de Cockpit dejaría de funcionar.
• En noviembre de 2021, los ciberdelincuentes compraron el antiguo nombre de dominio de Cockpit. Para lo que solo podemos suponer que fue una mezcla de sorpresa y deleite, los ladrones aparentemente descubrieron que al menos 40 sitios de comercio electrónico aún no habían actualizado sus páginas web para eliminar los enlaces a Cockpit, y seguían llamando a casa y aceptando cualquier código JavaScript. código que estaba en oferta.

Puedes ver hacia dónde va esta historia.

Cualquier desafortunado ex usuario de Cockpit que aparentemente no había revisado sus registros correctamente (o tal vez ni siquiera) desde fines de 2014 no se dio cuenta de que todavía estaban tratando de cargar un código que no funcionaba.

Suponemos que esas empresas se dieron cuenta de que no obtenían más datos analíticos de Cockpit, pero debido a que esperaban que la fuente de datos dejara de funcionar, asumieron que el final de los datos era el final de sus preocupaciones de seguridad cibernética relacionadas. al servicio y su nombre de dominio.

Inyección y vigilancia

Según Jscrambler, los delincuentes que se hicieron cargo del dominio desaparecido y que, por lo tanto, adquirieron una ruta directa para insertar malware en cualquier página web que aún confiara y usara ese dominio ahora revivido...

…comenzó a hacer exactamente eso, inyectando JavaScript no autorizado y malicioso en una amplia gama de sitios de comercio electrónico.

Esto permitió dos tipos principales de ataque:

• Inserte código JavaScript para monitorear el contenido de los campos de entrada en páginas web predeterminadas. Datos en input, select y textarea (como cabría esperar en un formulario web típico) se extrajo, codificó y exfiltró a una variedad de servidores de "llamada a casa" operados por los atacantes.
• Inserte campos adicionales en formularios web en páginas web seleccionadas. Este truco, conocido como Inyección HTML, significa que los delincuentes pueden subvertir páginas en las que los usuarios ya confían. Es probable que los usuarios se sientan atraídos a ingresar datos personales que esas páginas normalmente no solicitarían, como contraseñas, cumpleaños, números de teléfono o detalles de tarjetas de pago.

Con este par de vectores de ataque a su disposición, los delincuentes no solo podrían desviar lo que haya escrito en un formulario web en una página web comprometida, sino también buscar información de identificación personal (PII) adicional que normalmente no podrían obtener. robar.

Al decidir qué código JavaScript servir en función de la identidad del servidor que solicitó el código en primer lugar, los delincuentes pudieron adaptar su malware para atacar diferentes tipos de sitios de comercio electrónico de diferentes maneras.

Este tipo de respuesta personalizada, que es fácil de implementar si se observa el Referer: encabezado enviado en las solicitudes HTTP generadas por su navegador, también dificulta que los investigadores de seguridad cibernética determinen la gama completa de "cargas útiles" de ataque que los delincuentes tienen bajo la manga.

Después de todo, a menos que sepa de antemano la lista precisa de servidores y URL que los delincuentes buscan en sus servidores, no podrá generar solicitudes HTTP que liberen todas las posibles variantes del ataque que los delincuentes han programado. en el sistema.

En caso de que te lo estés preguntando, el Referer: El encabezado, que es un error ortográfico de la palabra inglesa "referrer", recibe su nombre de un error tipográfico en el Internet original. estándares de salud documento.

¿Qué hacer?

• Revise los enlaces de su cadena de suministro basada en la web. En cualquier lugar en el que confíe en las URL proporcionadas por otras personas para obtener datos o códigos que proporcione como si fueran suyos, debe verificar con regularidad y frecuencia que aún puede confiar en ellos. No espere a que sus propios clientes se quejen de que "algo parece estar roto". En primer lugar, eso significa que está confiando completamente en medidas de ciberseguridad reactivas. En segundo lugar, puede que no haya nada obvio que los propios clientes deban notar e informar.
• Revisa tus registros. Si su propio sitio web utiliza enlaces HTTP incrustados que ya no funcionan, entonces algo está claramente mal. O no deberías haber confiado en ese enlace antes, porque era el incorrecto, o no deberías confiar más en él, porque no se está comportando como solía hacerlo. Si no va a revisar sus registros, ¿por qué molestarse en recopilarlos en primer lugar?
• Realice transacciones de prueba regularmente. Mantenga un procedimiento de prueba regular y frecuente que pase de manera realista por las mismas secuencias de transacciones en línea que espera que sigan sus clientes, y realice un seguimiento de cerca de todas las solicitudes entrantes y salientes. Esto lo ayudará a detectar descargas inesperadas (p. ej., su navegador de prueba absorbiendo JavaScript desconocido) y cargas inesperadas (p. ej., datos extraídos del navegador de prueba a destinos inusuales).

Si aún obtiene JavaScript de un servidor que se retiró hace ocho años, especialmente si lo usa en un servicio que maneja PII o datos de pago, no es parte de la solución, es parte del problema. …

…así que, por favor, ¡no seas esa persona!

---

Nota para los clientes de Sophos. El dominio web "revitalizado" utilizado aquí para la inyección de JavaScript (web-cockpit DOT jp, si desea buscar sus propios registros) está bloqueado por Sophos como PROD_SPYWARE_AND_MALWARE y SEC_MALWARE_REPOSITORY. Esto denota que se sabe que el dominio no solo está asociado con la ciberdelincuencia relacionada con el malware, sino que también está involucrado en la entrega activa de código de malware.

---