En febrero de 2018, más de 4,000 sitios web, incluyendo organismos gubernamentales de alto perfil como la Oficina del Comisionado de Información del Reino Unido (ICO), fueron víctimas de el ataque BrowseAloud. Esto no fue solo otra brecha de ciberseguridad; fue un potente recordatorio de los peligros ocultos de los scripts de terceros en nuestros ecosistemas digitales cada vez más interconectados.
¿Qué sucedió en el ataque BrowseAloud?
Un servicio de terceros aparentemente benigno llamado BrowseAloud, que ayuda a los sitios web a mejorar la accesibilidad convirtiendo texto a voz, fue comprometido. Actores maliciosos inyectaron el script de minería de criptomonedas CoinHive en el código base de BrowseAloud. Este script fue ejecutado sin saberlo por los navegadores de miles de visitantes en varios sitios web, utilizando sus dispositivos para minar criptomonedas sin consentimiento.
La minería de criptomonedas implica el proceso de resolver problemas matemáticos complejos para validar transacciones en la blockchain, una tarea que tradicionalmente requiere recursos computacionales sustanciales. Sin embargo, con la llegada de scripts como CoinHive, este proceso se llevó a los navegadores de usuarios desprevenidos. Así es como funciona:
- Ejecución de JavaScript: CoinHive y scripts similares están escritos en JavaScript, que puede ejecutarse dentro de cualquier navegador web estándar. Esto hace que sea increíblemente fácil de implementar a gran escala. Probablemente el aspecto más importante de los ataques a la cadena de suministro web y lo que cside asegura.
- Uso no consensuado de recursos: A diferencia de la minería típica que requiere consentimiento explícito y hardware dedicado, la minería basada en navegador utiliza los recursos de CPU de cualquier visitante a un sitio infectado. El script se ejecuta mientras la página web esté abierta, haciéndolo menos notorio pero potencialmente dañino para los dispositivos de los usuarios debido al aumento del consumo de energía y desgaste.
- Rentabilidad para los atacantes: Cada dispositivo secuestrado contribuye con una pequeña cantidad de poder de minería. Sin embargo, cuando se escala a través de miles de dispositivos, esto puede generar criptomonedas significativas para los atacantes.
El impacto de este ataque
Este ataque afectó a más de 4,000 sitios web, incluyendo sitios gubernamentales y educativos, exponiendo a miles de usuarios al cryptojacking sin su conocimiento. No se robaron datos personales, pero las implicaciones fueron significativas de todos modos. Los sitios web tuvieron que ser dados de baja, causando interrupciones del servicio y daño reputacional. Los atacantes explotaron una práctica común pero riesgosa: la aceptación automática de actualizaciones de scripts de terceros. Este incidente destacó la necesidad de un monitoreo y gestión rigurosos de componentes de terceros, que muchas organizaciones habían pasado por alto.
Esto es contra lo que cside previene, tanto en el monitoreo del cambio como en la posibilidad de tomar acción autónoma para prevenir que el código malicioso se cargue en el navegador del usuario.
En otras palabras, esto muy probablemente no habría sucedido si cside hubiera existido y estado implementado en ese entonces. Puedes comenzar con cside para protegerte contra cualquier tipo de ataque de scripts de terceros de forma gratuita.
¿Qué pasó con BrowseAloud después?
Después del ataque de cryptojacking, la empresa matriz de BrowseAloud, Texthelp, tomó medidas inmediatas al desconectar temporalmente el servicio para mitigar el problema y realizar una revisión de seguridad exhaustiva. El incidente llevó a una mayor conciencia sobre la seguridad de los servicios de terceros y la necesidad de vigilancia continua y auditorías de seguridad regulares.
BrowseAloud volvió a estar en línea con medidas de seguridad mejoradas y un compromiso de prevenir tales incidentes en el futuro. El ataque también generó una discusión más amplia entre los proveedores de servicios web sobre la importancia de asegurar y monitorear rigurosamente los scripts de terceros.
El destino de CoinHive
CoinHive, por otro lado, enfrentó una trayectoria diferente. Inicialmente lanzado como una herramienta legítima para monetizar el contenido de sitios web sin anuncios utilizando el poder de CPU de los visitantes para minar criptomonedas, CoinHive rápidamente se asoció con el cryptojacking no autorizado. La connotación negativa y el mal uso del script en varios ataques maliciosos llevaron a un escrutinio significativo.
La viabilidad del servicio fue desafiada aún más por la caída en el valor de Monero y la creciente dificultad para minarlo de manera rentable. En consecuencia, CoinHive anunció su cierre en marzo de 2019, citando la inviabilidad económica como la razón principal de su clausura.
El dominio CoinHive.com ahora es propiedad del experto de la industria Troy Hunt. Es seguro y aloja su visión sobre la protección contra ataques similares y el cryptojacking en general.
Similar a cómo ahora somos dueños del dominio Baways.com y lo hemos convertido en un sitio web educativo.
Usar dominios antiguos previamente utilizados como estos puede causar otros problemas, como Troy Hunt experimentó recientemente.
Correo electrónico divertido / estúpido / idiota del día:
ejecuta un servicio para rastrear instancias de imágenes con derechos de autor que se usan sin licencia. En marzo, me enviaron múltiples correos electrónicos exigiendo dinero por infracción de derechos de autor. Hoy, recibí otro pidiendo muchos cientos de euros:
— Troy Hunt (@troyhunt)
Ahora volviendo a sus recomendaciones sobre el tema, su enfoque implica usar CSP para hacer que los navegadores ignoren cualquier comando de cualquier dominio que no esté explícitamente permitido. En su caso, después de asegurar el dominio CoinHive, implementó un CSP que garantiza que incluso si se inyectan scripts maliciosos, no se ejecutarían porque no provendrían de una lista permitida de dominios.
En nuestra opinión, este enfoque es bueno, pero no suficiente. En resumen, los CSP no deberían ser la única medida de seguridad contra ataques de JavaScript de terceros. Nuestra página de comparación ofrece una excelente descripción general de las características que hemos implementado además de los CSP para proporcionar la mejor seguridad posible con respecto a las brechas de scripts de terceros.
Creemos que la clave está en analizar todo el script antes de que llegue al navegador del usuario. Naturalmente, esto presenta algunos desafíos, para los cuales hemos diseñado soluciones. Puedes leer más sobre esta visión y cómo aseguramos los scripts de terceros aquí.
