Llegó el último fin de semana de enero y ya es costumbre encontrarse con la Sh3llCON en Santander. Cumplían 6 años. He tenido la suerte de que cuenten conmigo para las 6 ediciones. Para mí es jugar en casa, por lo que me une a Cantabria. Este año iba a hablar de un taller sobre BLE o Bluetooth Low-Energy y se podría ver herramientas como nuestro HomePwn. Además, mostrábamos la charla “GANS & Roses: Weaponizing the CEO Scam Fraud with AI & Autoencoders”. Una charla que, por ejemplo, estuvo en la 8dot8 de 2019 en Santiago de Chile.
En esta edición hubo un nuevo reto para los ponentes. Aquellos que quisieran podían generan una prueba para el CTF. Me gustó mucho la idea y cuando Carol, directora de Sh3llCON, me lo pidió allí que me lancé. Aprovechando que el taller era sobre BLE y, recientemente, había jugado con el BLECTF me lancé a generar una prueba con MakeCode y la Micro:Bit.
En este artículo contaré cómo se generó una sencilla prueba de CTF para Sh3llCON. En mi opinión, una prueba llamativa, ya que la interacción con una placa desconocida para la mayoría de la gente es interesante y provoca que la gente se tire un buen rato leyendo documentación sobre ella y sobre cómo interactuar con dicha placa. Algo que me parecía interesante. Nadie puede saber de todo y en un CTF te encontrarás con cosas que desconoces y tendrás que mirar y trabajar.
Figura 3: GANs & Roses: CEO Scam con AI & Autoencoders
La prueba puede descargarse desde este Github llamado CTF-giveMeNumber. Subir el fichero HEX a la Micro:Bit es trivial, simplemente hay que copiarlo dentro de la unidad de disco que se genera al conectar la Micro:Bit en el equipo. El esquema de Micro:Bit es muy sencillo. ¿Cuál fue la idea? La idea era buscar que los concursantes tuvieran que interactuar con una placa, la cual podíamos decir que simulaba ser una cerradura inteligente.
Al final, el objetivo es obtener una flag para contabilizar puntos en el juego. Por ello, pensé en que los concursantes deberían interactuar con la placa mediante algún tipo de juego sencillo. Recordando los años iniciales de carrera, cuando te enseñaban en el primer cuatrimestre la programación básica, te enseñaban a programar un juego de adivinar un número a la máquina con varios intentos. Jugabas con los bucles y con los condicionales.
Basándome en esta idea, decidí que de alguna forma se debía interactuar con la placa y ésta te propondría, en dicho comienzo de interacción que la dieras un número. Así, cuando el concursante se conectase mediante BLE a la placa, ésta mostraría un mensaje en su display (de 5x5) indicando: “GiveMeNumber”. Ahora tocaría a los concursantes investigar, ¿Cómo puedo interactuar en BLE? ¿Cómo puedo enviarle un número? ¿Cómo puedo…?
La placa está visible y tiene como nombre una suma de nombres entre “MicroBit” y un nombre aleatorio que recibe cada placa. Es fácil de identificar en el aire. Se pueden utilizar diversas herramientas como, por ejemplo, gatttool, bettercap o el propio homepwn. Incluso, se puede hacer con un dispositivo móvil a través de herramientas como nRF Connect. Y quizá, ésta fuera la idea primaria, que de forma rápida se pudiera conectar contra un dispositivo y enviarle ciertos comandos de manera muy efectiva.
Una vez que uno se conecta, bloquea al resto para poder conectarse contra el dispositivo, por lo que se tendrían que ir turnando con el uso de algunas pruebas o disponer de una Micro:Bit para cada equipo. Sea como fuera, se puede ver rápidamente con nRF Connect, lo lejos que se está de la placa y también se puede observar las características del BLE. En estas características encontraremos algunas de lectura, otras de escritura y también de subscripción o notificación.
Aquí toca hacer muchas pruebas y conjeturas. No nos dicen nada… aunque siempre puedes pedir una pista que te haga perder puntos cuando consigas el flag. Tú eliges. Si decides no pedir pista, una buena praxis sería hacer mucho caso a las características de escritura, mientras miras el display de 5x5 en busca de algún nuevo mensaje.
Mirando la documentación de BLE puede que envíes un comando y no haya respuesta, pero puede que envíes un comando y éste responda en alguna característica. Para poder recibir la respuesta debes marcar la notificación/subscripción en una característica. Este era un punto complejo para los usuarios que no han manejado nunca BLE a este nivel.
Si se pulsa sobre las características que tienen permiso de lectura se pueden obtener valores como el nombre del dispositivo, versión del firmware, etcétera. Si el usuario se da cuenta que hay varias características de escritura se podría ir probando a ver qué ocurre, tanto en el display de la placa como en las características destinadas a responder.
Hay que fijarse en que hay un UART Tx y un UART Rx. Entendemos que podemos comunicarnos con la placa y enviarle “algo”. Podemos probar diferentes configuraciones: bytes, números, strings, etcétera. Esto es probar y probar para ver qué puede hacer la placa, tanto desde el punto de vista del display y desde los valores que puede devolvernos a través de las características dónde la placa nos puede devolver valores. En este caso, nos devolverá información a través de UART RX char.
Entonces, escribiremos en UART TX y recibiremos valores en UART RX, siempre y cuando hayamos marcado la notificación previamente. Llegar a esa conclusión es importante y vital, si no, aunque la placa pueda recibir lo que le enviamos, no nos responderá nada, aunque si mostrará algo en el display. Generalmente, el mensaje que se mostrará en el display es: “Uy!”. Algo llega, se evalúa y fallamos. ¿Cómo acertaremos?
Si vamos al entorno de MakeCode y vemos un poco de documentación en la interacción con el BLE, podemos observar que hay una serie de delimitadores. Esto es fundamental. Hay varios delimitadores marcan el final del comando o la cadena enviada. En este caso, se programó con una # y era una de las pistas que se podían proporcionar a los concursantes, en caso de requerirla. Más adelante, podré las pistas preparadas.
Si el usuario envía un número seguido de una almohadilla, la placa hará algo y contestará con información interesante. Propondrá un nuevo juego basado en aritmética básica. Eso sí, en la versión de iPhone, te la dará codificada en hexadecimal. En el caso de utilizar Android, será un poco más sencillo, ya que verás algo que te es más familiar: o un string o un número. Si enviamos un 0#, la placa contestará en la característica UART Rx el siguiente mensaje: “Zero? Serious?”
Como se puede observar, recibimos una serie de bytes en hexadecimal. Al pasarlo por el conversor a ASCII encontraremos el mensaje comentado anteriormente. Parece que reconoce el número, pero no le termina de gustar. Lo normal sería probar con otro número. En otras palabras, habría que probar con una secuencia de número y ver qué tipo de mensajes nos empieza a proporcionar.
Ahora enviamos un 1# y obtenemos un nuevo hexadecimal. Eso sí, al pasarlo por el conversor obtenemos un ASCII que dice “78399491”. ¿Qué es esto? Es un número grande. Si ahora probamos con el 2#, obtenemos un nuevo hexadecimal que al convertirlo es “78399490”. Aquí ya se puede ver una relación.
Si se mete un 3# se obtendría un “78399489”. ¿Y si metemos un -1#? -1 también es un número. En este caso se obtiene un “78399493. ¿Esto cómo puede ser? Al ser un número negativo se obtiene un número mayor. La placa propone un sencillo juego de adivinar el número exacto programado. Quizá nos de algo más interesante si acertamos el número.
Es un juego basado en suma y resta. Cualquier dato numérico que se introduce es restado al número buscado, si el número introducido es positivo. En este caso número buscado – número introducido. Si el número introducido es negativo, la fórmula que parece aplicar es número buscado + valor absoluto número negativo.
Introduciendo varios números de manera secuencial se puede llegar a la conclusión de que cuando se introduzca el número “78399492” ocurrirá algo diferente. Como se puede ver en la imagen, lo primero que se obtiene es un hexadecimal largo. Hay que convertirlo a ASCII y ver qué es lo que pone.
¿Qué pone? Lo que se ha encontrado en este caso es la propia "flag". Hemos detectado el número secreto que se buscaba y se obtiene una flag.
Pistas
¿Cuáles eran las pistas? Por cada pista que solicitase un equipo o concursante se restaría valor al flag, en caso de que lo consiguiesen. Aquí os dejo las 3 pistas que se podían proporcionar:
Saludos,
Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root", “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.
Para consultas puedes usar el Buzón Público para contactar con Pablo González
 |
| Figura 1: Sh3llCON 2020: Taller, Charla y Reto CTF BLE |
En esta edición hubo un nuevo reto para los ponentes. Aquellos que quisieran podían generan una prueba para el CTF. Me gustó mucho la idea y cuando Carol, directora de Sh3llCON, me lo pidió allí que me lancé. Aprovechando que el taller era sobre BLE y, recientemente, había jugado con el BLECTF me lancé a generar una prueba con MakeCode y la Micro:Bit.
 |
| Figura 2: Buzón Público de Sh3llCON en MyPublicInbox |
En este artículo contaré cómo se generó una sencilla prueba de CTF para Sh3llCON. En mi opinión, una prueba llamativa, ya que la interacción con una placa desconocida para la mayoría de la gente es interesante y provoca que la gente se tire un buen rato leyendo documentación sobre ella y sobre cómo interactuar con dicha placa. Algo que me parecía interesante. Nadie puede saber de todo y en un CTF te encontrarás con cosas que desconoces y tendrás que mirar y trabajar.
Figura 3: GANs & Roses: CEO Scam con AI & Autoencoders
La prueba puede descargarse desde este Github llamado CTF-giveMeNumber. Subir el fichero HEX a la Micro:Bit es trivial, simplemente hay que copiarlo dentro de la unidad de disco que se genera al conectar la Micro:Bit en el equipo. El esquema de Micro:Bit es muy sencillo. ¿Cuál fue la idea? La idea era buscar que los concursantes tuvieran que interactuar con una placa, la cual podíamos decir que simulaba ser una cerradura inteligente.
 |
| Figura 4: GitHub CTF-GiveMeNumber |
Al final, el objetivo es obtener una flag para contabilizar puntos en el juego. Por ello, pensé en que los concursantes deberían interactuar con la placa mediante algún tipo de juego sencillo. Recordando los años iniciales de carrera, cuando te enseñaban en el primer cuatrimestre la programación básica, te enseñaban a programar un juego de adivinar un número a la máquina con varios intentos. Jugabas con los bucles y con los condicionales.
 |
| Figura 5: Esquema de Macro:bit. |
Basándome en esta idea, decidí que de alguna forma se debía interactuar con la placa y ésta te propondría, en dicho comienzo de interacción que la dieras un número. Así, cuando el concursante se conectase mediante BLE a la placa, ésta mostraría un mensaje en su display (de 5x5) indicando: “GiveMeNumber”. Ahora tocaría a los concursantes investigar, ¿Cómo puedo interactuar en BLE? ¿Cómo puedo enviarle un número? ¿Cómo puedo…?
 |
| Figura 6: Placo Micro:Bit |
La placa está visible y tiene como nombre una suma de nombres entre “MicroBit” y un nombre aleatorio que recibe cada placa. Es fácil de identificar en el aire. Se pueden utilizar diversas herramientas como, por ejemplo, gatttool, bettercap o el propio homepwn. Incluso, se puede hacer con un dispositivo móvil a través de herramientas como nRF Connect. Y quizá, ésta fuera la idea primaria, que de forma rápida se pudiera conectar contra un dispositivo y enviarle ciertos comandos de manera muy efectiva.
 |
| Figura 7: Se puede observar cómo se encuentra la placa a través del uso de nRF Connect desde el smartphone |
Una vez que uno se conecta, bloquea al resto para poder conectarse contra el dispositivo, por lo que se tendrían que ir turnando con el uso de algunas pruebas o disponer de una Micro:Bit para cada equipo. Sea como fuera, se puede ver rápidamente con nRF Connect, lo lejos que se está de la placa y también se puede observar las características del BLE. En estas características encontraremos algunas de lectura, otras de escritura y también de subscripción o notificación.
Aquí toca hacer muchas pruebas y conjeturas. No nos dicen nada… aunque siempre puedes pedir una pista que te haga perder puntos cuando consigas el flag. Tú eliges. Si decides no pedir pista, una buena praxis sería hacer mucho caso a las características de escritura, mientras miras el display de 5x5 en busca de algún nuevo mensaje.
 |
| Figura 8: Características de la Micro:Bit por nFR Connect |
Mirando la documentación de BLE puede que envíes un comando y no haya respuesta, pero puede que envíes un comando y éste responda en alguna característica. Para poder recibir la respuesta debes marcar la notificación/subscripción en una característica. Este era un punto complejo para los usuarios que no han manejado nunca BLE a este nivel.
Si se pulsa sobre las características que tienen permiso de lectura se pueden obtener valores como el nombre del dispositivo, versión del firmware, etcétera. Si el usuario se da cuenta que hay varias características de escritura se podría ir probando a ver qué ocurre, tanto en el display de la placa como en las características destinadas a responder.
Hay que fijarse en que hay un UART Tx y un UART Rx. Entendemos que podemos comunicarnos con la placa y enviarle “algo”. Podemos probar diferentes configuraciones: bytes, números, strings, etcétera. Esto es probar y probar para ver qué puede hacer la placa, tanto desde el punto de vista del display y desde los valores que puede devolvernos a través de las características dónde la placa nos puede devolver valores. En este caso, nos devolverá información a través de UART RX char.
 |
| Figura 9: Escritura de valor 0 vía nFR Connect |
Entonces, escribiremos en UART TX y recibiremos valores en UART RX, siempre y cuando hayamos marcado la notificación previamente. Llegar a esa conclusión es importante y vital, si no, aunque la placa pueda recibir lo que le enviamos, no nos responderá nada, aunque si mostrará algo en el display. Generalmente, el mensaje que se mostrará en el display es: “Uy!”. Algo llega, se evalúa y fallamos. ¿Cómo acertaremos?
Si vamos al entorno de MakeCode y vemos un poco de documentación en la interacción con el BLE, podemos observar que hay una serie de delimitadores. Esto es fundamental. Hay varios delimitadores marcan el final del comando o la cadena enviada. En este caso, se programó con una # y era una de las pistas que se podían proporcionar a los concursantes, en caso de requerirla. Más adelante, podré las pistas preparadas.
Si el usuario envía un número seguido de una almohadilla, la placa hará algo y contestará con información interesante. Propondrá un nuevo juego basado en aritmética básica. Eso sí, en la versión de iPhone, te la dará codificada en hexadecimal. En el caso de utilizar Android, será un poco más sencillo, ya que verás algo que te es más familiar: o un string o un número. Si enviamos un 0#, la placa contestará en la característica UART Rx el siguiente mensaje: “Zero? Serious?”
 |
| Figura 10: Lista de mensajes. Uno tiene un valor HEX. |
Como se puede observar, recibimos una serie de bytes en hexadecimal. Al pasarlo por el conversor a ASCII encontraremos el mensaje comentado anteriormente. Parece que reconoce el número, pero no le termina de gustar. Lo normal sería probar con otro número. En otras palabras, habría que probar con una secuencia de número y ver qué tipo de mensajes nos empieza a proporcionar.
Ahora enviamos un 1# y obtenemos un nuevo hexadecimal. Eso sí, al pasarlo por el conversor obtenemos un ASCII que dice “78399491”. ¿Qué es esto? Es un número grande. Si ahora probamos con el 2#, obtenemos un nuevo hexadecimal que al convertirlo es “78399490”. Aquí ya se puede ver una relación.
 |
| Figura 11: Conversor HEX to ASCII |
Si se mete un 3# se obtendría un “78399489”. ¿Y si metemos un -1#? -1 también es un número. En este caso se obtiene un “78399493. ¿Esto cómo puede ser? Al ser un número negativo se obtiene un número mayor. La placa propone un sencillo juego de adivinar el número exacto programado. Quizá nos de algo más interesante si acertamos el número.
Es un juego basado en suma y resta. Cualquier dato numérico que se introduce es restado al número buscado, si el número introducido es positivo. En este caso número buscado – número introducido. Si el número introducido es negativo, la fórmula que parece aplicar es número buscado + valor absoluto número negativo.
 |
| Figura 12: Nuevo valor hexadecimal capturado |
Introduciendo varios números de manera secuencial se puede llegar a la conclusión de que cuando se introduzca el número “78399492” ocurrirá algo diferente. Como se puede ver en la imagen, lo primero que se obtiene es un hexadecimal largo. Hay que convertirlo a ASCII y ver qué es lo que pone.
 |
| Figura 13: Nos da el Flag del CTF |
¿Qué pone? Lo que se ha encontrado en este caso es la propia "flag". Hemos detectado el número secreto que se buscaba y se obtiene una flag.
Pistas
¿Cuáles eran las pistas? Por cada pista que solicitase un equipo o concursante se restaría valor al flag, en caso de que lo consiguiesen. Aquí os dejo las 3 pistas que se podían proporcionar:
• Pista 1: Para los que están muy perdidos: nRF Connect + mensajes con # como delimitador o final de línea
• Pista 2: Revisa los permisos de BLE (escritura, lectura, notificación). Mira cómo recibir respuestas de dispositivos BLE a través de característicasSin duda, fue un reto primero para mí, ya que me tocó diseñar y pensar en algo que permitiera jugar con BLE, ya que mi taller era sobre dicha tecnología. Por otro lado, fue divertido poder estar el sábado por la tarde un rato con los chicos ayudándoles con el reto. Y una satisfacción ver cómo lo resolvieron, tras un poco de ayuda.
• Pista 3: La fuerza bruta nunca fue un buen método. Utiliza la mente y piensa en los números. Ellos te darán la solución (recuerda la # al final de tus apuestas…)
Saludos,
Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root", “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.
Para consultas puedes usar el Buzón Público para contactar con Pablo González |
| Figura 14: Contactar con Pablo González en MyPublicInbox |
No hay comentarios:
Publicar un comentario