MarioNet y Service Workers

Leo en zdnet.com acerca del nuevo MarioNet, un nuevo ataque que no requiere intervención del usuario, y esto es lo más importante, ni está basado en una falla de programación que pueda ser arreglada en el futuro. Más que estar basado en una falla, está basado en una característica, de haber algún fallo este estaría en las especificaciones mismas, ya que parece no haberse considerado la posibilidad de abusar de esta característica de esta manera.

MarioNet es un juego con la pronunciación de la palabra “marionette”, que es el inglés para “marioneta”. En efecto, durante el estudio se refiere a los integrantes de la botnet como “las marionetas”, y al atacante como “el titiritero” o “pupeteer”.

Desde hace tiempo se viene hablando de los Web Workers, única manera de ejecutar código en paralelo usando JavaScript en la actualidad, o bueno al menos en el navegador web. Están pensados para hacer tareas computacionalmente intensivas y están muy limitados, no pueden tocar el DOM por ejemplo, ni acceder a la mayoría de APIs, lo que sí pueden hacer es comunicarse con el hilo principal. Con un poco de creatividad, se pueden hacer malabares para que el hilo principal actualice el DOM según lo que le comunica un Web Worker. Claro que para esto el JavaScript que sí es parte del DOM debe estar escrito a conciencia para comunicarse con el Worker.

Seguro mucha gente conoce a estas alturas los Web Workers, pero dudo que tanta gente conozca los Service Workers.

El principal problema de diseño de estos Workers es que pueden seguir ejecutándose aún después de que se cerró la pestaña que los creó.

Pueden ver qué Service Workers tienen en ejecución ahora escribiendo en la barra de direcciones de su navegador (Firefox al menos):

about:serviceworkers

Yo, por ejemplo, sólo tengo el de WhatsApp Web, sitio que uso y en el que confío, así que no me preocupo.

Pueden desactivar definitivamente los Service Workers, al menos en Firefox, poniendo lo siguiente en about:config:

dom.serviceWorkers.enabled = false

Probé a desactivarlos y WhatsApp Web funciona lo mismo. He leído que Google Docs sin conexión, en Chrome, los usa y posiblemente no funcione bien si se desactivan, pero a la fecha de escribir esto, no sé cómo desactivarlos en Chrome ni si se pueden desactivar.

En Firefox, después de desactivarlos de la forma indicada más arriba, al volver a visitar about:serviceworkers aparece un mensaje que dice que “los service workers están desactivados”.

Los Service Workers pueden:

• Ser registrados de forma programática y sin transparencia para el usuario (el usuario ni se entera que se ha registrado un nuevo Worker)

• Seguir ejecutándose después de abandonar el sito que los registró, aunque eventualmente serán suspendidos.

• Hacer HttpRequests aunque con limitaciones: la descarga de recursos sólo es posible o bien del mismo sitio que lo registró o bien de sitios que envían una cabecera HTTP amigable con CORS. Nótese que para hacer un DDoS a un sitio competidor no es necesario que el sitio use estas cabeceras, pues su servidor web igual deberá procesar el request, por lo que es posible saturarlo y arruinar la experiencia para el resto de visitantes.

• Interceptar HttpRequests pero sólo si van al sitio que registró el Worker, por lo que no es posible un ataque del tipo “hombre en el medio”.

Al principio, mientras leía el PDF del estudio, asumí que no era posible plantar el Service Worker a través de un anuncio, así como tampoco por un iframe, por todas las limitaciones impuestas por el navegador, pero luego se dice que sí se puede aunque de forma indirecta. En la sección III se habla de cómo un sitio web inocente podría llegar a participar en la implantación del Service Worker de un tercero sin saberlo. En el caso de los iframes, puede ocurrir que el tercero use ingeniería social, clickjacking o algún otro método para redirigir al visitante a su sitio o conseguir que éste se abra como popup para así hacer el registro inicial del Service Worker. Luego, mantenerlo funcionando mientras el visitante navega por otros sitios depende de que cada tanto vuelva a ver algún anuncio del sitio malicioso que hizo el primer registro, esto hará que el navegador, de forma silenciosa, reviva al Worker.

Características de una botnet MarioNet:

• Persistencia aún después de abandonar el sitio atacante y cerrar y volver a abrir el navegador web. Pero con limitaciones, esta “persistencia” requiere de hacer constantemente “malabares” con JavaScript moderno. Tienes que valerte de notificaciones y otros trucos para mantener comunicación constante con el sitio atacante, sino no hay forma de reiniciar la bot net después de que el navegador abandonó el sito atacante y fue cerrado y vuelto a abrir.

• Invisible a extensiones de seguridad o de monitorización de tráfico.

• Se puede usar para:

  • Minería de cripto-monedas.

  • Crackeo distribuido de contraseñas (en cierta forma implicado por el punto anterior, si puedes hashear puedes crackear y para minar cripto-monedas debes poder hashear).

  • Lanzar DDoS a terceros.

  • Distribución de archivos ilegales o indeseables, siendo muy laborioso (posiblemente no viable) determinar la fuente original de los mismos.

  • Manipular campañas de anuncios (haciendo que parezca que mucha gente está visitando un sitio web determinado y así obtener las ganancias de los anuncios)

¿Debo desactivar mis Service Workers?

Cambiar el estado por defecto del navegador siempre le da problemas a los diseñadores web, y puede interferir con el comportamiento esperado de ciertos sitios. Pero, tratándose de una característica tan “obscura” yo diría que desactivarlos es algo que bien podría causarnos ningún problema, al menos que nuestro caso de uso sea muy particular.

Y es que, al menos que seas un gigante como Google, y tengas un producto de cierta complejidad como Google Docs, es en extremo sospechoso que utilices Service Workers. ¿Para qué los necesitas?

Lamentablemente, en el mundo que vivimos hoy, el uso ilegítimo de este tipo de cosas supera por mucho al uso legítimo, así que nadie debería sorprenderse de que la gente los empiece a desactivar.

¿Pero por qué no se ha oído de verdaderos ataques?

Voy a especular.

Si asumimos que los blogs de Kaspersky, DrWeb, y otros, son fuente confiable de información a este respecto. Yo no he dado con ningún ataque relacionado con Service Workers.

Creo que se debe al requerimiento de que el sito que instala el Service Worker debe tener la conexión establecida vía https. Así es, no sirve http a secas. Una vez más los certificados al rescate. Para configurar https en tu servidor web, primero debes comprar un certificado. Esto ya frena a la mayoría de potenciales atacantes, debido a que tienen que asumir el riesgo de abandonar el anonimato. La compra del certificado implica que el operador del sitio web se vuelve rastreable.

Por lo tanto la única manera sería que el atacante tomara el control de otro servidor web, que no es de su propiedad, para así poder actuar desde el anonimato. Pero aquí viene otro problema, los servidores populares, que son los que podrían servir para hacerse de una botnet con un tamaño como para que resulte de alguna utilidad al atacante, son justamente los servidores que jamás podrán tomar.

No nos olvidemos de la relación costo/beneficio. Muchas veces esto hace viable o no un ataque. Quizá usando los Service Workers se pueda implantar una botnet de navegadores web con relativa facilidad. Pero esta facilidad es sólo en lo que a JavaScript respecta. No es tan fácil desde el punto de vista de la inversión inicial y para mantenerla funcionando. Los anuncios cuestan dinero, y sin ellos es difícil mantener viva la botnet. Una botnet que despierta una vez cada tanto y luego se va a dormir no es útil como botnet, y no sirve para mucho más que la minería de criptomonedas que ya se usa en algunos sitios como reemplazo de los anuncios.

En lugar de anuncios se puede usar las notificaciones web, pero el usuario tiene el control sobre ellas, puede negarse o bloquearlas si se arrepiente de haberlas aceptado.

Por otro lado, podrían haber cientos o miles de estas botnets y pasar totalmente sin ser detectadas.

Los servidores que las plantaron podrían haber decidido que vale la pena correr el riesgo. Quizá piensen que pueden obtener un gran beneficio y apagar la botnet antes de ser descubiertos.

El https juega tanto en contra como a favor del atacante en este caso. Pues ni tu ISP puede saber qué está pasando a ciencia cierta. El estudio dice claramente, que lo único que se ve es el request GET. Y al ser por https esto implica que los parámetros no se ven, por lo que aún si usaran una url tan obvia como esta:

https://www.masterpuppeteer.com?puppet_id=4432123&last_command_id=22112232&request=give_orders

Esta parte no se vería: ?puppet_id=4432123&last_command_id=22112232&request=give_orders

Pero yo imagino que el ISP podría observar si las máquinas implicadas en un DDoS suelen comunicarse con un sitio determinado. De nuevo, de aquí la importancia de que el sitio atacante sea popular. Es fácil saber lo que ocurre si se llama masterpuppeteer.com. Yo creo que aquí nos juega a favor el perfil del ciber criminal. No creo que ninguno tenga la paciencia de lanzar un servicio útil para la sociedad, si lo hicieran ya tendrían ganancias con él y no necesitarían la botnet.

Reflexiones

Hay que tener mucho cuidado con la forma que le estamos dando al mundo. Es muy feo que yo pueda permitirme confiar en WhatsApp Web basándome en que es un servicio muy exitoso y que tiene mucho que perder si se lo llega a descubrir abusando de esta tecnología. Mientras que no puedo dar la oportunidad a alguien que está empezando porque las estadísticas dicen que si alguien así está usando Workers de algún tipo seguro sea para minar criptomonedas haciéndome pagar a mí la tarifa del suministro eléctrico, y si tengo mala suerte para algo mucho peor que minar criptomonedas. Y si usa Service Workers en concreto seguro sea porque quiere prolongar el abuso lo más que pueda.

Pero como está la cosa, culpable hasta que se demuestre lo contrario es la mejor defensa. Así que ya saben, ni se molesten en usar Service Workers hasta que sean tan exitosos como Facebook.