Tengo la suerte de ser un "papaete" que tiene dos niñas que me vuelven loco. Son totalmente distintas, la mayor es "Mi Hacker" y la pequeña "Mi Survivor". Cada una es como es ella. No es fácil encontrar puntos en común en su forma de ver la vida, pero si hay algo que tienen las dos es que les encanta la tecnología.

Figura 1: 2FWB: Second Factor Web Browsing [Parte 1 de 4] "Second Channels"

Supongo que su "papaete" habrá tenido algo que culpa, y es que desde muy pequeñas las he expuesto a la tecnología, para que la vivan conmigo. Han estado en robótica y en tecnología desde que eran muy pequeñas. Scratch, Arduino, Lego Mindstorms, o lo que sea. Yo las apunto a cursos, seminarios, les compro libros de programación o simplemente les cuento cosas. Pero no solo eso, también las incito a hacer cosas conmigo en mi trabajo. Y les encanta.

Niñas y Tecnología

No intento que esta forma mía de vivir con mis salvajes deba ser la que se aplique con los niños y niñas. Esta es la forma en la que yo vivo la tecnología con Mi Hacker y Mi Survivor. Con Mi Hacker, en el año 2017, cuando aún no estaba lanzada AURA en ninguno de los países subimos juntos en el "Encuentro de Telefónica". Un acto privado con unas 1.000 personas donde ella hizo una demo completa guiada conmigo de cómo iba a funcionar AURA en la app móvil de Movistar+ en España.

Figura 2: Presentando Aura en Movistar+ en Noviembre de 2017 con Mi Survivor

Y con Mi Survivor, pues ya sabéis que rodé un pequeño anuncio el verano pasado con Movistar Home, dando rienda a su afición al Atlético de Madrid y jugando un rato con ella. Nos lo pasamos genial ese día, y se pasó dos días antes aprendiéndose las frases y repitiéndolas durante horas y horas a todo el que se acercaba.

Y como os podéis imaginar, he estimulado mucho su interés por la tecnología, así que las preguntas que todo padre sufre, yo las tengo que debatir durante días y semanas con ellas. Preguntas que seguro que os suenan a la mayoría.

Y claro, el verano pasado me tenían la cabeza llena de sus peticiones, así que decidí que tenía que hacer algo. Como todo buen investigador de seguridad me he pegado mucho con los ataques de red, y cuando estamos de viaje y hay que usar un ordenador, las redes WiFi me dan mucho miedo. Es lo que tiene haber estado criando y construyendo a nuestra querida Evil FOCA, o de jugar con los servidores Proxy. Ya sean por IPv4 o por IPv6, en cualquier red a la que te conectes puede aparecer un atacante.

Y como me tenía muy preocupado, empecé a pensar cómo podía vigilar sus conexiones mirando por encima del hombro todo lo que hacían pero sin estar. Y así fue como se me ocurrió esta idea del Second Factor Web Browsing (2FWB) que os voy a contar en esta serie, pero dejadme que lo haga uniendo los puntos de atrás adelante después de haberos explicado el punto de partida. La gracia es poder unir los puntos de cosas que vas dejando en el pasado para poder crear cosas nuevas en el futuro. Como lo que os cuento hoy.

Recuerdo cuando llegó la primera vez que se me ocurrió empezar a utilizar un Second Channel en un producto. Era el año 2013 y acabamos de terminar nuestra primera patente de un producto que se llamaba en CodeName Path2. Era nuestra primera patente y estábamos construyendo el producto y todos los detalles del servicio que iba a proveer.

Ese Path2 se convirtió a la postre en Latch, y la pregunta que teníamos que resolver era... ¿cómo abrimos y cerramos el pestillo si estamos en una situación en la que no hay Internet? Las soluciones a estos problemas se suelen resolver con algoritmos TOTP generados en el end-point o generados en el bank-end y enviados por SMS, pero yo quería hacer algo distinto. Quería utilizar el canal SMS como si fuera un canal de comunicaciones y permitir que la app siguiere funcionando normalmente enviando "tramas" SMS.

En aquel entonces, haciendo lo que tiene que hacer un equipo de producto, decidimos quitar esa característica del roadmap principal y aceptar que no la teníamos para enfocar los recursos en partes del producto y servicio que consideramos más prioritarias en aquel en entonces.

Pero ni mucho menos se me olvidó.

Tiempo después empezamos a trabajar en la idea de ver cómo podrían funcionar las apps maliciosas en los Identity Providers de Internet para robar los Tokens OAuth y hacer ataques como el de RansomCloud lo que nos llevó a que hiciéramos nuestro querido y famoso SAPPO del que hablamos en la RootedCON 2016 y con el que nuestro amigo Kevin Mitnick asusta a los ejecutivos de todo el mundo en sus charlas.


Figura 5: Kevin Mitnick explicando Ransomcloud
Y fue con esa idea de hacer cosas con los Tokens OAuth la que volvió a tocar en mi cabeza la idea de los Second Channels. Lo que sucedió es que preparando la presentación del MWC de Febrero de 2017 fui a ver UNICEF en New York tras pasar a dar una pequeña charla en la Universidad de Columbia.

Allí nos estuvieron contando cómo el canal SMS era aún una poderosa herramienta para ellos porque en muchos de los países en los que trabajaban, o en muchas situaciones de emergencia, era el único canal de comunicaciones que existía. Inundaciones, corrimientos de tierra, situaciones de emergencia humanitaria por hambre o enfermedad, etcétera.

View this post on Instagram

Explicación de Pigram en uno de mis dibus }:) Mola ver como mis compañeros me ayudan a llevar mis ideas de la concepción al delivery }:)

A post shared by Chema Alonso (@chemaalonso) on Dec 27, 2017 at 9:16am PST

Y a la vuelta, junté a mi equipo de Ideas Locas y les dibujé un pequeño esquema de lo que íbamos a construir. Íbamos a hacer Pigram, nuestro sistema para comunicarse en redes sociales y correo electrónico por medio de un canal SMS y el uso de tokens OAuth.


Figura 7: SafePost, publica en Internet con canal SMS
Con el tiempo tuvimos que cambiar el nombre de Pigram a SafePost, por presiones ajenas que algún día os contaré, pero a día de hoy el servicio sigue estando activo y lanzado en varios países. Y lo más importante, decidimos estandarizarlo y crear un SDK para que cualquier app móvil pudiera utilizar el canal SMS para comunicarse. Hoy en día se llama Stack SMS y tenéis el paper, las herramientas y los vídeos explicativos públicos en la red.

Figura 8: Paper de Stack SMS

Hicimos un juego de prueba con el ahorcado para explicar cómo podía utilizarse, pero durante la última Vuelta Ciclista a España, tras hacer una etapa con el Movistar Team, me di cuenta de que podíamos hacer un sistema de mensajería en grupo basado en Internet+Stack SMS que diera más velocidad y cobertura a las comunicaciones durante carrera por las zonas más inhóspitas de los países, y nació el juguete que enseñamos en Diciembre de 2018.


Figura 9: Movistar Team Chat Room con Stack SMS
Pero aún lo podíamos utilizar para muchas más cosas. El poder contar siempre con un Second Channel tan cómodo, accesible y común como el SMS nos abría muchas posibilidades, y cuando en este Mobile World Congress 2019 nos pidieron alguna charla de seguridad, mis compañeros del equipo de Ideas Locas crearon el IoT AntiDDOS SMS Shield, es decir, una solución de control remoto de dispositivos IoT que estuvieran siendo inhabilitados por un ataque de denegación de servicios.


Figura 10: IoT AntiDDOS SMS(GSM) Shield
Como podéis ver, la idea de utilizar Second Channels ha sido una constante durante los últimos años en nuestro equipo, así que no es raro que apareciera la idea de Second Factor Web Browsing (2FWB) que os voy a contar a continuación. Pero como ha quedado muy largo, dejadme que esto sea en la siguiente parte del artículo.

Saludos Malignos!

*****************************************************************************************
- 2FWB: Second Factor Web Browsing [Parte 1 de 4] "Second Channels"
- 2FWB: Second Factor Web Browsing [Parte 2 de 4]
- 2FWB: Second Factor Web Browsing [Parte 3 de 4]
- 2FWB: Second Factor Web Browsing [Parte 4 de 4]
*****************************************************************************************