Kubernetes: Cómo comprobar la salud de los pods con “probes”

Pues sí amigos y amigas, en este 2020 también vamos a seguir hablando de Docker y sobre todo, de Kubernetes. Cuanto más lo utilizamos, más vemos las grandes posibilidades que ofrece para todo tipo de entornos. Por este motivo es importante también centrarnos especialmente en su seguridad, integridad y disponibilidad.

Figura 1: Kubernetes: Cómo comprobar la salud de los pods con “probes”

De esto trata esta serie, no sólo de mostraros cómo funciona sino, además, de intentar aplicar buenas prácticas para minimizar al máximo todo tipo de riesgos asociados a esta arquitectura. No olvidéis que en nuestro libro Docker: SecDevOps podéis comenzar a adentraros en el mundo de Docker y los contenedores.

Figura 2: Libro Docker: SecDevOps

Kubernetes es una plataforma que nos permite definir el estado de nuestro clúster en profundidad. Por ejemplo, cuando desplegamos un servicio, especificamos cómo queremos correrlo, el número de réplicas o copias que queremos, entre otras muchas acciones.

En ese momento, Kubernetes se encargará de desplegar nuestro servicio e intentará cumplir con “nuestros deseos”. Es decir, levantará el número de copias que hayamos especificado, y si una de dichas copias se cae, levantará una nueva. En otras palabras, Kubernetes nos permite definir el estado de nuestro clúster de forma declarativa e intentará realizar todo lo posible por mantener dicho estado.

Pero ¿cómo sabe cuando un servicio está listo para recibir tráfico? ¿Y si un servicio tiene problemas y necesita ser reiniciado o reemplazado? Para responder a esas preguntas, Kubernetes nos ofrece tres tipos de puntos de comprobación o probes.

Readiness Probe

Esta es la forma en la que podemos decir a Kubernetes que nuestro pod está listo para recibir peticiones. Un ejemplo típico de uso de este tipo probe puede ser que por ejemplo tu pod necesite conectarse a un servicio externo, y éste por el motivo que sea no se encuentra disponible. Asumiendo que tu pod requiera, de forma imperativa, dicho servicio para poder funcionar, no tiene sentido que reciba peticiones nuevas.

Liveness Probe

Es usado por Kubernetes para saber si el pod está en un estado digamos, saludable. En caso contrario, Kubernetes lo reiniciará de forma automática. Un ejemplo de uso podría ser que nuestro pod tuviera algún tipo de problemas de recursos como la memoria, o el disco (volumen). Supongamos que escribimos los logs de pod en un volumen (no persistente) y, bueno, a veces por algún motivo la limpieza de esos logs falla y éste se llena.

El resultado es que nos hemos quedamos sin espacio y la mejor forma de recuperarnos del problema es reiniciando el pod. Normalmente, tiramos de este probe para recuperarnos de excepciones de las que nuestro pod no es capaz de recuperarse. Si un contenedor muere por algún tipo de error, Kubernetes reiniciaría el mismo de la misma forma que lo haría si el liveness probe fallara.

Startup Probe

Este apareció en la versión 1.16 de Kubernetes y actualmente está en versión alpha. El uso ideal del mismo es aplicarlo cuando nuestro pod tarda algún tiempo antes de arrancar por completo. Por ejemplo, hemos movido una aplicación antigua a un contenedor, y ésta tarda demasiado tiempo en levantarse. En este caso, podría ser problemático si no especificamos correctamente nuestro liveness probe ya que podríamos acabar en un reinicio constante del pod, debido a que Kubernetes podría pensar que el pod no responde propiamente y necesita reiniciarlo, cuando en realidad, el problema es que el pod está justo durante su proceso de arranque.

Cuando definimos el startup probe, Kubernetes no habilita el liveness probe para que le indique si el pod ya está arrancado. Si este probe fallara, Kubernetes reiniciaría el pod. Se recomienda que este se ejecute en el mismo chequeo que definamos para nuestro liveness probe. Para ello asignaremos el valor failureThreshold lo suficientemente alto para que nuestro pod tenga el tiempo suficiente para arrancar.

Figura 3: Esquema de un nodo y las "probe"

Vale, ya conocemos los probe, pero ¿cómo los definimos? Existen básicamente tres formas de definir la comprobación de un probe:

· HTTP: quizás la forma más utilizada. En este caso, Kubernetes consulta a través de una petición GET el punto de acceso de nuestro servicio. Si la respuesta se encuentra en el rango de los 200s o 300s, le indica que el probe está saludable. Cualquier otro código de respuesta implica algún tipo de anomalía o error.

· Comando: en este caso, Kubernetes ejecuta el comando indicado. Si éste devuelve 0, el probe se considera saludable, en cualquier otro caso, el resultado se considera problemático .

· TCP: no todos los servicios no son necesariamente HTTP. Por eso, Kubernetes nos ofrece la oportunidad de definir probes basados en TCP. En esta caso, intentaría establecer una conexión TCP al puerto especificado. Si la conexión es satisfactoria, el probe se considera en buena salud, en caso contrario, existe algún problema.

Ok, entonces ¿cuál es la frecuencia de consulta a nuestros probes? ¿cuántos intentos son necesarios para considerar un probe en buen o mal estado? Existen varios parámetros que nos permite definir dicho comportamiento:

· initialDelaySeconds: número de segundos que Kubernetes espera después de que un contenedor se haya inicializado para activar los probes liveness y readiness. Por defecto su valor es 0.

· periodSeconds: Con qué frecuencia Kubernetes ejecuta el probe. Por defecto su valor es 10, y el valor mínimo es 1.

· timeoutSeconds: tiempo, en segundos, que Kubernetes espera cuando ejecuta el probe. El valor por defecto es 1, así como su valor mínimo.

· successThreshold: número de veces consecutivas en que el probe se ejecuta de manera satisfactoria después de un fallo, para que el pod se considere saludable de nuevo. Valor por defecto y mínimo es 1. Para un probe tipo liveness debe ser 1.

· failureThreshold: número de veces consecutivas que debe fallar un probe para que Kubernetes lo considere con problemas. En cuyo caso, si hablamos de liveness, reiniciará el pod, y el caso de readiness, cortará el tráfico a dicho pod. El valor por defecto es 3 y el mínimo 1.

Cada probe puede devolver uno de los tres valores siguientes:

· Success: el contenedor pasa el diagnóstico. 

· Failure: el diagnóstico ha fallado. 

· Unknown: el diagnóstico ha fallado, pero no se toma ninguna acción.

Ahora que ya tenemos la teoría, vamos a pasar a la práctica. Los probes se configuran dentro de la especificación del contenedor.

Ejemplo de Liveness Probe

Veamos algún ejemplo con liveness probe:

    apiVersion: v1
    kind: Pod
    metadata:
        labels:
            test: liveness
        name: liveness-http
        spec:
        containers:
        - name: liveness
            image: k8s.gcr.io/liveness
            args:
            - /server
            livenessProbe:
            httpGet:
                path: /healthz
                port: 8080
                httpHeaders:
                - name: Custom-Header
                  value: Awesome
            initialDelaySeconds: 3
            periodSeconds: 3

Como se puede ver en el ejemplo, el probe se define bajo “livenessProbe:”. En este caso definimos un probe del tipo HTTP, se mandará una petición GET a la IP_CONTENEDOR/healthz:8080, en dicha petición, además se manda una cabecera llamada Custom-Header con el valor Awesome.

Figura 4: PoC Kubernetes Liveness Probe

También se establece que Kubernetes que espere 3 segundos antes de que empiece a mandar dichas peticiones, y que estas se repitan cada 3 segundos. Como no definimos el valor failureThreshold, en el momento en el que Kubernetes reciba tres fallos (valor fuera del rango 200-399) reiniciará el pod.

Ejemplo de Readiness Probe

Ahora veamos un ejemplo para readiness:

    ...
    containers:
    - name: readiness
        image: k8s.gcr.io/busybox
        args:
        - /bin/sh
        - -c
        - touch /tmp/healthy; sleep 10; rm -rf /tmp/healthy; sleep 10; touch /tmp/healthy; sleep 600
        readinessProbe:
          exec:
            command:
            - cat
            - /tmp/healthy
          initialDelaySeconds: 2
          periodSeconds: 2

En este caso, lo que hacemos es cuando arranca nuestro contenedor crea un fichero /tmp/healthy, espera 10 segundos, borra dicho fichero, espera otros 10 segundos y vuelve a crear el mismo fichero y luego espera 5 minutos (después de los 5 minutos, el contenedor morirá y Kubernetes reiniciará el pod).

En este caso nuestro probe lo que hace es ejecutar el comando `cat /tmp/healthy`. Este comando se ejecutará de forma satisfactoria cuando /tmp/healthy exista y fallará cuando éste no exista. El chequeo empieza 2 segundos después de que el contenedor se haya arrancado y lo efectúa cada 2 segundos. En el siguiente vídeo veremos como Kubernetes muestra cuando el pod está listo para recibir tráfico y cuando no.

Figura 5: Kuberneters: PoC Readiness Probe

Definir estos chequeos se consideran buenas prácticas y son aconsejables tenerlos definidos, pero hay que tener cuidado con los parámetros ya que podríamos crear un pequeño caos y hacernos a nosotros mismos un DoS ;)

Reflexión final

Para terminar, estos son algunos consejos sobre cómo utilizar los probes:

· Si defines startup probe, usa la misma comprobación que liveness. 

· No uses la misma comprobación para liveness y readiness. 

· No uses ninguna dependencia en liveness. Por ejemplo, no definas en liveness ninguna lógica conectando a una base de datos. Si la base de datos se cae, Kubernetes reiniciará tu pod y esto no arreglaría el problema y acabaría reiniciado el pod de forma constante. En esta caso readiness sería una mejor opción. 

· Si no tienes ninguna razón por la que reiniciar tu contenedor, no definas liveness. Si el contenedor por algún motivo se rompe, Kubernetes se encargará de reiniciarlo de todas formas. 

· Si tu contenedor tiene algún bug en el que hay veces que deja de funcionar, pero el contenedor sigue vivo, define liveness de forma que chequee esa condición extraordinaria para así poder indicarle a Kubernetes que reinicie el pod. Asegúrate de que implementas bien este chequeo. 

· Conoce los valores por defecto de tiempos. Para asegurarte y evitar confusiones declaralos de forma explícita.

Y esto ha sido todo en este artículo. Esperamos que os sean de utilidad estos ejemplos y consejos en vuestro trabajo con Docker y Kubernetes.

Happy Hacking Hackers!!!!

Autores:

Fran Ramírez, (@cyberhadesblog) es investigador de seguridad y miembro del equipo de Ideas Locas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps", también de "Machine Learning aplicado a la Ciberseguridad” además del blog CyberHades. Puedes contactar con Fran Ramirez en MyPublicInbox.

Figura 6: Contactar con Fran Ramírez en MyPublicInbox

Rafael Troncoso (@tuxotron) es Senior Software Engineer en SAP Concur, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" además del blog CyberHades. Puedes contactar con Rafael Troncoso en MyPublicInbox.

Figura 7: Contactar con Rafael Troncoso en MyPublicInbox

Consent Commons: protección de datos para todos los públicos

Leer textos legales es complicado y muy aburrido. Todos quisiéramos saber cuáles van a ser las consecuencias de aceptar una política de privacidad, descargar una app o contratar un servicio web en términos que podamos comprender.

Figura 1: Consent Commons: protección de datos para todos los públicos

Cuando se comprueban las estadísticas de lectura de las condiciones de contratación y de privacidad, es evidente que es necesario simplificar la manera de presentar la información. De los valientes que se atrevieron a abrir en su móvil un texto legal (menos de un 20%), solo un 3% lo terminó, aunque reconocen que no entendieron una palabra. El 97% restante de ese generoso 20 dedicaron 30 segundos en leer las condiciones legales, lo que supone que apenas vieron los primeros párrafos antes de aceptarlas. Es de suponer que estos entran en el mismo grupo que, intentando cerrar un banner sin éxito, acaban abriendo la web del anunciante sin querer.

La última política de privacidad de Google tiene 32 páginas. Esas 32 páginas no recogen toda la información necesaria, ya que el texto está repleto de links a otros sitios en donde encontrar una información más granular. Pero aceptemos que 32 páginas y 8898 palabras son lo único que habría que leer.

Figura 2: Política de Privacidad de Google

Aunque los buenos lectores leen a velocidades de más de mil palabras por minuto, con cerca del 85% de comprensión, solamente representan el 1% del total. Los lectores promedio, que constituyen la mayoría, sólo alcanzan alrededor de 200 palabras por minuto con una comprensión típica del 60%. Así que, antes de aceptar los servicios de Google, al menos, hay que dedicarle 45 minutos de lectura reposada con amplios conocimientos legales.

La lectura de todas las condiciones legales de los servicios, aplicaciones y productos nos llevaría un mes completo de nuestra vida, según datos del año 2008. Desde entonces, con la aparición de los teléfonos inteligentes, el número de aplicaciones, productos y servicios ha aumentado sin control. Es más que probable que la estimación de un mes al año, por tanto y a la vista del ejemplo anterior, se haya quedado muy corta.

Así pues “He leído y aceptado las condiciones de privacidad” se ha convertido en “The biggest lie on Internet”, la mayor mentira de Internet.

Con la entrada en vigor del Reglamento General de Protección de Datos (RGPD) la transparencia, el comportamiento ético más allá del cumplimiento legal y la responsabilidad proactiva o demostrable se incorporan a nuestro ordenamiento jurídico imponiendo a las empresas que recaban y tratan datos personales una obligación de hacer que sus cláusulas de información para la recogida del consentimiento sean claras y comprensibles para un consumidor y lector medio.

Pensé que esa claridad se podía conseguir con iconos (como inicialmente incluía los borradores del RGPD) y como ya se hizo con algo tan complicado como las licencias de propiedad intelectual. Si Creative Commons lo consiguió con estas licencias, había que hacer el mismo esfuerzo de simplificar la ley que afecta a la privacidad de todos nosotros usando sentido común y lenguaje visual.

Figura 3: Ejemplos de políticas de privacidad con iconografía Consent Commons

Con menos de 30 segundos de atención el usuario puede tomar decisiones sobre si le compensa o no dar sus datos. Gracias al efecto de superioridad visual, una imagen se procesa 60.000 veces más rápido que un texto, la recordamos en un 80% de las ocasiones, frente a un 20% de lo que leemos y un 10 % de lo que oímos. La simplificación del lenguaje legal y la incorporación del lenguaje visual mejora la transparencia, comprensión y recuerdo de los textos con contenido jurídico.

Figura 4: Más ejemplos de uso de Consent Commons

De ahí nace Consent Commons, un sistema de iconos sencillo, práctico y usable para que de un vistazo sepamos para qué damos los datos, qué van a hacer con ellos quien nos los pide, si para prestarnos el servicio o para venderlos a terceros; si se los van a pasar a otras empresas o no; si los datos están en servidores dentro de la UE o fuera; si nuestros datos se van a analizar junto con otros para hacer perfiles de nosotros, para sacar nuestro doble virtual y tomar decisiones sobre nosotros basados en la pinta que tenga él.


Figura 5: Presentación de Consent Commons
No solo es ventajoso para el usuario. Las empresas que lo usan se toman en serio ser transparentes con sus clientes. Usar Consent Commons es un signo de respeto. Porque los derechos son de los ciudadanos. Lo mínimo que deben esperar es poder entenderlos.

Autor: Paloma Llaneza

Figura 6: Contactar con Paloma Llaneza

Doctor Honoris Causa por la URJC

No estaría siendo honesto si dijera que ayer no fue un día bonito para mí ya que durante el acto de entrega de los títulos a los nuevos doctores, la Universidad Rey Juan Carlos me invistió como Doctor Honoris Causa, un honor que llevaré con orgullo conmigo. Algo que no sé lo que significará para los demás, pero para mí, que estudié allí mi título de Doctor durante varios años, es muy bonito. De hecho, creo que es la primera vez que la URJC inviste como Doctor Honoris Causa a alguien que ha estudiado allí, que ha hecho sus exámenes allí aprobando y suspendiendo cuando ha tocado, y que ha realizado sus investigaciones y tesis allí.

Figura 1: Doctor Honoris Causa por la URJC

El acto en sí está lleno de simbología y detalles que intentan representar lo que significa para la Academia investir a alguien con este título, pero para mí es, además, una forma de llevar la universidad donde estudié con orgullo, ya que siempre he sido un defensor de tener una universidad potente que nos permita tener una sociedad mejor educada y más competitiva.

Figura 2: Ayer, recibiendo el título de Doctor Honoris Causa

Los que lleváis más tiempo cerca mía sabéis que he estado durante muchos años ligado a la universidad, no solo en las dos en las que estudié, sino también en las que he trabajado. No me puedo olvidar en este recuerdo de mi querida Universidad Politécnica de Madrid,  de la que además llevo con todo orgullo también los títulos de Ingeniero Técnico en Informática de Sistemas que estudié de los 18 a los 22 años, y el de Embajador Honorífico de la Escuela Técnica de Ingenieros de Sistemas Informáticos de la UPM que me concedieron en el año 2012.

Figura 3: Recibiendo el birrete de Doctor con el color de Informática

Luego, ya con 30 años, volví a estudiar el Grado de Ingeniería Informática, el Postgrado en Sistemas de Información y el Doctorado en la Universidad Rey Juan Carlos, lo que me tomó 8 años de estudios - tres para los dos últimos años del grado y TFG, uno para el postgrado y 4 años de doctorado -. De todo esto en un artículo donde explicaba el proceso para sacarse un título de doctor en una universidad, que es un trabajado largo y duro, así que te debe apasionar el tema que investigues.

Pero durante estos últimos 20 años he estado durante 8 años dirigiendo el Máster Universitario de Seguridad de las Tecnologías de Información y las Comunicaciones en la Universidad Europea de Madrid, he sido profesor del Grado de Ingeniería Informática en la Universitat Oberta de Catalunya, y he dado clases puntuales en otras muchas universidades. Además, ya me habían pedido ser padrino de una promoción de alumnos en la URJC, como alumno distinguido, algo que hice encantado.

View this post on Instagram

Si os digo que ha sido un día especial ... tenéis que creerme }:)

A post shared by Chema Alonso (@chemaalonso) on Jan 28, 2020 at 8:51am PST

Pero en este caso, el título de Doctor Honoris Causa es distinto. Se trata de un título que conceden los miembros de la universidad por tu carrera personal y profesional en la vida, lo que genera aún más responsabilidad personal. Durante el año pasado, la Doctora Marta Beltrán del departamento de Ciencias de la Computación, Arquitectura de Computadores, Lenguajes y Sistemas Informáticos y Estadística e Investigación Operativa, y que fuera co-directora de mi tesis doctoral, presentó la candidatura en el departamento. Una vez aprobada, la Facultad de Informática presentó la propuesta a la Junta de Gobierno de la Universidad, que lo aprobó por unanimidad, y me lo comunicaron a finales de Noviembre del año pasado.

Ni por asomo se me hubiera pasado a mí por la cabeza que algún día pudiera pasar algo así. Como muchas otras cosas que me han pasado en la vida, es verdad, pero no se me había pasado ni por la cabeza algo así. Y durante el acto estuve bastante nervioso. Yo soy de Móstoles. Estudié en la URJC.  Estudié mucho para obtener mi título de Doctor. Y el día que me investía como Doctor, el que recibía el título de Doctor Honoris Causa fue el Doctor James A. Yorke, matemático y uno de los introductores del concepto de "chaos" en matemáticas. Y yo solo soy un ingeniero al que le gusta jugar con la tecnología. 

Figura 5: Con el rector y con la Doctora Marta Beltrán tras la investidura

Ahora que voy a llevar este título conmigo, lo haré con orgullo. Y más después del precioso Laudatio de Investidura que la Doctora Marta Beltrán hizo en la ceremonia. Son muchas cosas las que me unen, no solo a la URJC, sino al mundo académico, donde el trabajo de investigación que se hace es tan parecido al que se realiza en la comunidad de hackers. De hecho, muchos son los hackers que vienen del mundo universitario, y muchos son investigadores y profesores de la universidad.

De momento, este viernes me voy a pasar por el Grado de Ingeniería de la Ciberseguridad de la URJC. Como os podéis imaginar es para mí una alegría que el primer Grado de Ciberseguridad Oficial de una Universidad en España se haya lanzando en mi querida Móstoles gracias la URJC. Somos muchos los alumnos que nos hemos dejado las pestañas estudiando  y muchos profesores se dejan las noches investigando y dando clases. Y tenemos la obligación de hacer que las ciudades en las que están las sedes de esta universidad disfruten de la mejor oferta académica posible.

Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

Sh3llCON 2020: Taller, Charla y Reto CTF BLE

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.

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ísticas

• 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…)

Sin 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.

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

Grita fuerte su nombre: Despistaos @despistaos

Si lees este blog, no hace falta deciros que el grupo Despistaos es la niña de mis ojos de la música española, y que tengo una relación muy especial con Dani, Krespo, Pablo y Lázaro, más allá de la estrictamente ser un fan, pero ha sido durante el lanzamiento del último disco "Estamos Enteros" cuando he tenido la oportunidad de disfrutarlos más en corto. 

Figura 1: Grita fuerte su nombre: Despistaos

Todo comenzó cuando vi que desde Tuenti patrocinaba el festival Gigante en Guadalajara y que allí tocaban Despistaos. Como sabía que Dani es de allí, pensé que sería un buen concierto de estos chicos que tanto me gustaban cuando empezaban. Me organicé plan y fui para allá. Y allí mismo descubrí que estaban sacando canciones de un nuevo disco. De "Estamos Enteros". De hecho, el día que tocaban en Guada, salieron nuevos temas.

View this post on Instagram

Quería decirte, como te he dicho otras veces, que pase lo que pase...

A post shared by Chema Alonso (@chemaalonso) on Aug 30, 2018 at 3:46pm PDT

Quiso el azar que yo publicara un vídeo en Instagram de Despistaos en Guadalajara, y que Dani escuchara al día siguiente un Podcast de El País de los Horrores, en el que yo participaba, y que me buscara por Instagram. Para llevarse la sorpresa de verse a sí mismo en mi cuenta. Me escribió, y comenzamos una bonita relación.

View this post on Instagram

Con estos chicos tan “Despistaos” aprovechando que ayer pasaban por @laresistenciacero }:)

A post shared by Chema Alonso (@chemaalonso) on Mar 14, 2019 at 10:25pm PDT

Después de estar con ellos en varios conciertos, acabamos cenando el día que salía el disco físico, con todos los temas, de "Estamos enteros", que coincidía justo, justo, justo, cuando Dani visitaba La Resistencia con todo el elenco de creadores de la mítica serie "Física y Química". 

View this post on Instagram

Cosas que hacer en un puente largo: a)Ver a Metallica b)Hacer mucha bicicleta c) Tocar la batería d) Escribir muchos posts e) Celebrar el día de la Madre en familia f) Leer y escuchar música }:)

A post shared by Chema Alonso (@chemaalonso) on May 6, 2019 at 1:44am PDT

Luego... nos hicimos amigos y Krespo intentó enseñarme a tocar la batería y todo. Fracasó. Conciertos, comidas con "Los 50 chuletones de Grey". Montar en bicicleta. E incluso mee liaron para la campaña de "Todos Somos Despistaos".

View this post on Instagram

Comida de los 50 Chuletones de Grey. Foto de familia }:)

A post shared by Chema Alonso (@chemaalonso) on May 24, 2019 at 9:16am PDT

y vi en primera mano cómo aparecían temas como "Grita fuerte mi nombre", o las colaboraciones con David Otero en "En tus manos", o con Arnau Griso "Las cosas se me olvidan",  "El primer paso" con Taburete, o "Las cosas se me olvidan" con Marlon.

Figura 6: Grita Fuerte mi nombre

A día de hoy, tiene más de 1.000.000 de oyentes mensuales en Spotify y han conseguido atraer a un montón de público joven, incluidas Mi Hacker y Mi Survivor que me piden cosas como "Octavius" o "Mi accidente preferido" con Sidecars constantemente. 

View this post on Instagram

Y todo gracias a ustedes 🙌🏻

A post shared by Despistaos (@despistaos) on Jan 22, 2020 at 7:40am PST

Y todo esto que os he contado es porque, este viernes salió la "Edición Deluxe" de "Estamos Enteros", donde aparecen todas las canciones que han ido trabajando, madurando, afinando, haciendo que brillen más las letras y la música.

Figura 8: Estamos Enteros Edición Deluxe de Despistaos en Spotify

Ya lo tienes en Spotify, y como querían hacer una nota para enviar a los medios, me dijeron: "Chema, por qué no haces tú el texto que acompaña la nota que enviamos desde Warner". Y acepté encantando. Aquí tienes la nota que hice para ellos, con todo el cariño, admiración y amistad que me une a este grupo que ha conseguido estar 15 años ganándose la vida con su música.

GRITA FUERTE SU NOMBRE: DESPISTAOS

Tocaban Despistaos en Guadalajara y movilicé mi agenda para prepararme un plan especial. Sabía de siempre que Dani era de allí, y pensé “¡Seguro que lo da todo sobre las tablas!”, así que busqué en Spotify las canciones que me conocía de “Despis” y mi sorpresa fue encontrarme con que había nuevos temas de un disco que aún no estaba completo. “Estamos Enteros” estaba siendo lanzado poco a poco, con mimo, eligiendo cada uno de los nuevos temas con esmero y cariño. Y flipé. ¿Cómo era posible que después de tanto tiempo Despistaos sonara tan genial? Sin escapatoria posible, me enganché de manera muy emocional al grupo, al disco y a los temas del nuevo trabajo. Y me hice fan de carretera para acompañarlos por diferentes conciertos y festivales.

Figura 9: El primer paso con Taburete

Tuve la suerte de poder cenar con ellos el día que recibían el disco físico de “Estamos Enteros” para llevármelo dedicado, y he vivido en primera persona el nacimiento de un tema como “Gríta fuerte mi nombre”, que se ha convertido en un himno nada más nacer. Pero no solo eso, ya que durante este año hemos disfrutado la madurez y crecimiento de canciones como “Las cosas se me olvidan”, “En tus manos”, “El primer paso” o “Quién te acompañará”, que las hemos redescubierto gracias al arte y el alma que han puesto Arnau Griso, David Otero, Taburete y Marlon, que nos han hecho sentirlas con matices en algunos otros rincones del corazón.

Figura 10: Quién te acompañará con Marlon

Hoy vemos a unos Despistaos mucho más maduros, centrados en ese arte que han refinado cual orfebres, rejuvenecidos como si fueran niños, para hacer temas joviales y sinceros. Disfrutando en el escenario. Disfrutando en los festivales esos que llenan una y otra vez como el que llena una copa de vino sabroso. No importa la hora ni el lugar donde Lázaro saque las baquetas, Pablo dé vueltas y vueltas con su bajo o Krespo sonría con esa mirada de sinvergüenza encantador, vaya afeitado o sin afeitar. En el momento en que Dani salta sobre el escenario y nos endulza el espíritu con esas letras honestas y afiladas abrigadas de esa voz cálida y ruda, la gente no puede dejar de cantar. En ese momento se hacen eternos, y flotan en el infinito.

View this post on Instagram

Nos cuesta olvidar lo que pasó el sábado en nuestro concierto de Madrid. Uno de los días más bonitos de nuestra carrera. . Os dejamos unas imágenes para que os hagáis una idea 😊 . 🎥: @joseamesti

A post shared by Despistaos (@despistaos) on Jun 12, 2019 at 12:41pm PDT

Hoy en día, con más de 1.000.000 de oyentes en Spotify, Despistaos se han convertido en algo mucho más grande que el grupo de seguidores que los escuchamos con clásicos como “Cada dos minutos”, “Ruido” o esas que ya seguro que te sabes. Hoy en día son un grupo que han unido a varias generaciones, y que disfrutan los más jóvenes – incluidas mis hijas -, para cantar a voz en cuello “Mi accidente preferido” o la onírica letra sobre la armoniosa sonoridad que ilustra la historia de “Octavius”.

Figura 12: Mi accidente preferido con Juancho de Sidecars

Dentro de unos años, volveremos a este disco. A esta edición nueva que tenemos hoy de “Estamos Enteros” que recoge el magnífico trabajo que se ha hecho con la poesía y la música de estas piezas de arte en pocos minutos, y nos daremos cuenta de que “Despistaos” creció varios enteros en el arte de la música popular con él. Nos metió nuevos temas en el alma que nos acompañarán muchos años. Así que, si al final no recuerdan quién son, grita fuerte su nombre: Despistaos.

Chema Alonso.

Además, puedes contactar con todos ellos en MyPublicInbox, que cada uno de ellos tiene su buzón público correspondiente.

- Contactar con Daniel Marco, cantante de Despistaos

- Contactar con Krespo, guitarrista de Despistaos

- Contactar con Pablo Alonso, bajista de Despistaos

- Contactar con Lazaro, batería de Despistaos

Y como sabéis, están de gira, así que toma nota que el calendario que tienen de ciudades es el siguiente. Verás que en directo son un grupo que nunca defrauda.

View this post on Instagram

2020 viene cargado de conciertos. ¿Ya le has pedido tu regalo a Papá Noel? 🎁 . Entradas en despistaos.com

A post shared by Despistaos (@despistaos) on Dec 22, 2019 at 1:55pm PST

Os dejo un vídeo clip hecho por el realizador José Amesti que recoge un poco de lo que ha sido este año para ellos en conciertos.

View this post on Instagram

Queda muy poco para que acabe este 2019 y podemos decir que ha sido un año increíble 💿🚐✈️🎵😍 . . En marzo y tras 6 años sin publicar nada, salió nuestro disco Estamos Enteros y a día de hoy lleva 20 millones de reproducciones solo en Spotify. 4 canciones nuevas están entre las 5 más escuchadas de Despistaos y esto es muy emocionante . Hemos arrancado la primera parte de #EstamosEnterosLaGira y nos hemos paseado por alguno los festivales más importantes del país. Mención especial a nuestro Sold Out en La Riviera de Madrid . Ha sido el año del regreso a nuestro querido México y hemos tocado en Argentina, Uruguay, Chile y Perú, estos dos últimos países con entradas agotadas . Le hemos dicho al mundo que hasta que no encontramos nuestro verdadero talento, no somos fracasados, #TodosSomosDespistaos y de todo esto ha nacido la canción Grita Fuerte Mi Nombre . Esto y muchas cosas más es gracias a ti. Te deseamos un feliz 2020 ❤️ . 📹: @jose_amesti

A post shared by Despistaos (@despistaos) on Dec 29, 2019 at 1:15am PST

Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)