Cómo proteger su sitio web de los ataques de cryptojacking

En el último mes, se informó que más de 4000 sitios web, incluidos sitios web gubernamentales en los EE. UU. Y el Reino Unido, como la Oficina del Comisionado de Información del Reino Unido (ICO), estaban sirviendo el cripto minador CoinHive a sus usuarios. CoinHive crypto miner es un script de JavaScript que se puede instalar en cualquier sitio web y fue diseñado para extraer criptomonedas a expensas de la potencia de CPU de los usuarios.

Claramente, esta no era la intención de ninguna de las compañías afectadas. De hecho, ICO es una autoridad independiente establecida en el Reino Unido para defender los derechos de información en interés público, promoviendo la apertura de los organismos públicos y la privacidad de los datos para las personas. Este asalto ‘cryptojacking’ fue un resultado directo de un tercero proveedor (TextHelp) utilizado en el sitio web del ICO que se ve comprometido, sin el conocimiento de los propietarios del sitio web ni del proveedor externo. Inicialmente, este incidente fue detectado por el experto en seguridad Scott Helme luego de recibir información de otro experto en seguridad, Ian Trump.

Cómo se desarrolló el ataque

El sitio web de ICO, junto con todos los otros sitios web afectados, estaban cargando un archivo de un sitio web de un tercero que es donde comenzó el problema. Al cargar JavaScript directamente de un tercero como este, estos sitios web básicamente invitaban a ataques de inyección. Esto no es muy diferente del presunto ataque contra el CDN de jQuery que RiskIQ afirma que está sirviendo un kit de explotación para cada usuario de cada sitio web que carga jQuery’s directamente desde su CDN.

Este enfoque particular es muy atractivo para los atacantes que pueden comprometer a los usuarios a escala atacando las dependencias que se cargan dinámicamente. Incluso si cree que los proveedores de terceros son confiables, aún pueden estar comprometidos sin saberlo, lo que permite a los atacantes utilizarlos como un vehículo para inyecciones maliciosas.

¿Qué se puede hacer?

Un posible enfoque, como lo señala Scott Helme, es agregar atributos de integridad del Subfondo (SRI) a los elementos del script que cargan los scripts externos. Incluso sugiere complementar esto empleando Content Security Policy (CSP) para hacer cumplir el uso de las etiquetas SRI.

Si bien esta es una buena sugerencia, no funciona muy bien si la secuencia de comandos de dependencia debe actualizarse regularmente, lo que parece ser el caso aquí. CSP es útil para restringir que JavaScript externo (JS) se cargue en un sitio web, pero no está destinado a garantizar la integridad de los scripts que espera cargar.

La CSP basada en listas blancas es realmente difícil de llevar a cabo y los atacantes expertos probablemente encontrarán la forma de evitarlo, ya que no impide la inyección de código desde fuentes externas que se encuentran en los dominios de la lista blanca, por ejemplo. Con respecto a CSP, como precaución, cualquier control de seguridad basado en encabezado puede ser desarmado por una extensión de navegador.

Mitigación utilizando monitoreo en tiempo real de la página web

Si no hay una forma infalible de evitar que se inyecte un código no deseado o marcado en un sitio web, entonces lo mejor sería saber al respecto y poder reaccionar en tiempo real. Al monitorear el entorno DOM y JavaScript de la página web para cualquier inyección, el sitio web puede informar a un webhook en el back-end, lo que le permite detectar cualquier cambio realizado a sí mismo, incluidas las amenazas de 0 días y no solo las inyecciones conocidas.

Los equipos de seguridad pueden recibir alertas sobre lo que se inyectó y, en algunos casos, incluso eliminar la inyección de malware en el lugar hasta que se encuentre una solución permanente, lo que limita el número de usuarios afectados. Este enfoque es extremadamente útil porque no solo identifica lo que se inyectó, sino dónde. Entonces es posible averiguar cómo se insertó la inyección en primer lugar y tomar las medidas apropiadas para arreglar la situación de forma permanente. Este método es más rápido que otros ya que también detecta amenazas de 0 días.

El script modificado maliciosamente ya no se sirve desde browsealoud.com, pero fue posible replicar el ataque forzando el archivo infectado (en lugar del actual) al sitio web de ICO. Al mismo tiempo, se incrustó manualmente un agente incrustado en el sitio web del ICO para supervisar el DOM de la página web. El objetivo aquí fue obtener el resultado del aterrizaje de scripts maliciosos en el DOM de la página web del ICO y demostrar cómo mitigar el ataque con éxito. Los resultados están disponibles aquí.

Conclusión

Las soluciones que monitorean la página web en tiempo real son una alternativa eficiente cuando CSP y SRI se quedan cortos. Pueden buscar modificaciones DOM, ataques de envenenamiento JS, secuestro de eventos JS y XSS e informar al backend, permitiendo que la aplicación web reaccione de inmediato.

Con la creciente popularidad (y el valor) de las criptomonedas, el foco de estos ataques ahora es el criptoaccionamiento y los atacantes buscan robar los ciclos de la computadora como una forma de obtener efectivo. Los ataques de CBS Showtime y The Pirate Bay son otros ejemplos.

Este último incidente que involucra a TextHelp simplemente sirve para demostrar cuán atractivo es este enfoque para los atacantes, especialmente si pueden comprometerse.

Fuente: The Next Web

2018-06-02T17:34:28+00:00 Informática|