"Weaponizing" Features

El sol estaba en lo alto. El cielo era azul. La ciudad de San Diego estaba viva. Y había amigos, conocidos y hackers en la ToorCON. Los astros se alinearon y el fin de semana quedó para disfrutarlo. Visité Little Italy, comí y cené con amigos, y enredé con mi gran amigo Kevin Mitnick, al que había conseguido “engañar” para que se viniera a dar la charla de DirtyTooth Hack conmigo.

Figura 1: "Weaponizing" Features

Durante la misma tuvimos que lidiar con problemas no esperados – así son las demos en real – pero al final acabaron saliendo las demos y nos lo pasamos de maravilla. Y luego a tomarse unas cervezas para relajarnos y reírnos un poco al ver que me daban el Oscar al “Best Body” por la broma de todas las horas que desde hace un tiempo meto en el gimmasio para compensar los excesos con los amigos.

Yeahhhh! }:)

A post shared by Chema Alonso (@chemaalonso) on Sep 2, 2017 at 4:11pm PDT

Entre cerveza y charlas de hackers uno de los asistentes quiso hablar conmigo para ver cómo Apple podría arreglar el tema del DirtyTooth Hack. Hablamos un rato. “Es un bug”, me dijo. “Que un dispositivo cambie el BlueTooth Profile y consiga acceder a la agenda de contactos sin una alerta es un bug”, insistió. Y puede que tenga razón, pero hace tiempo que esos detalles son menos importantes para mí. “No lo sé, para mí es como funciona el sistema iOS, y lo único que he hecho es automatizar  un pequeño leak para hacer un juguete". El insistió que si había podido "weaponizarlo" como lo hacen los Rogue BlueTooth Speakers que son parte de DirtyTooth Hack, entonces es un bug.


Figura 3: DirtyTooth Hack en RootedCON 2017
Lo cierto es que este trabajo no es tan diferente a lo que hicimos con la primera versión de la FOCA. “Weaponizar” los pequeños leaks que se producen en los metadatos de los documentos publicados para convertirlo en una herramienta que pintaba parcialmente el mapa interno de una organización. Algo que se puede evitar limpiando los metadatos de los documentos que van a hacerse públicos en una web o al ser enviados por correo electrónico.

Figura 4: Mapa de red interno pintado por FOCA

Y no es nada distinto del estudio que hicimos con los discos de almacenamiento USB que se conectan a los equipos y generan hidden links en las redes de las empresas. Recoger pequeños datos y “automatizar” o “weaponizar” lo que se obtiene de esas fugas de información.

El último de esta serie, por no extenderme demasiado en los ejemplos, es el caso de la posibilidad que existe de saltarse el bloqueo del envío de mensajes de WhatsApp utilizando una tercera persona. No es un bug en sí, pero si se “weaponiza”, es decir, si alguien crea el sitio web automatizado como el que yo cree como PoC (que nunca publiqué ni publicaré), el bloqueo de contactos deja de tener sentido en WhatsApp. ¿Es un bug? No lo sé. Es solo una “weaponización” de una característica del servicio.


Figura 5: Desbloquéame WhatsApp

Por supuesto, hacer manualmente el ejemplo de WhatsApp tiene la vida muy corta, pero hacerlo con una plataforma automática como hicimos nosotros anula por completo el sentido del bloqueo. ¿Se debe arreglar eso? Pues no seré yo quién lo defina. Cada uno debe tener su opinión.

¿Qué se debe hacer?

En la mía, creo que en iOS la compartición de contactos con un dispositivo BlueTooth cuando este lo pida no debe ser YES por defecto. Apple hace revisión a todas las apps para ver cuáles piden permisos de acceso a información personal – como por ejemplo la agenda de contactos – y luego además pone permisos extras que el usuario puede gestionar. En el caso del dispositivo BlueTooth no hay ninguna revisión por parte de Apple y además el usuario no dispone de ese control para decir no a la compartición de los contactos.

Vale, sí que existe ese "toogle" para decir no, pero si el dispositivo ofrece la conexión con un perfil BlueTooth y en el futuro lo cambia para acceder a los contactos, el usuario no se entera. Y además, el acceso a los contactos es discreto. Es decir, el dispositivo Rogue BlueTooth Speaker puede esperar un tiempo aleatorio antes de convertirse en un PBAP (PhoneBook Access Profile), extraer los contactos y volver a comportarse con un perfil BlueTooth de escucha de audio. ¿Se enteraría el usuario? ¿Podría controlarlo? Lo dudo mucho.

¿Y en el caso de WhatsApp? Pues lo mismo. Como ya dije existen dos aproximaciones válidas. La primera es que si el usuario A bloquea al usuario B, entonces el usuario B no pudiera enviarle mensajes ni cuando estuviera en un grupo, pero eso sería un leak de información de todas las personas que están en ese grupo que podrían llegar a darse cuenta de que A está bloqueando a B y… quién sabe, tal vez se pudiera “weaponinizar” y hacer algo más automático.

La otra opción es la que aplica Telegram y que para mí tiene todo el sentido. Permitir al usuario de WhatsApp bloquear la opción de ser incluido en grupo si no lo hace una persona que él mismo tenga en la lista de contactos. Sencillo y funcional para anular la “weaponización” que hicimos con “Desbloqueamé”. ¿Debería hacerlo?

Figura 6: Opción de Telegram que evita el "desbloquéame"

La verdad es que, viendo cómo va el mundo, seguro que acabarán haciéndolo. Apple acabará poniendo algún control al cambio de perfiles BlueTooth y acceso a la agenda de contactos vía PBAP y seguro que WhatsApp acaba haciendo alguna cosa de las que he dicho o similares. Al final esa es la gracia de la weaponización. Algo que de forma discreta parece una “chorrada”, si alguien es capaz de automatizarlo y reducir las barreras de explotación de ese “leak” o “feature”, lo convierte en algo que incrementa seriamente el riesgo.

Saludos Malignos!