Read-Only Reentrancy Attack: $220k robados y +$100M en riesgo

En el pasado hemos hablado sobre el “Reentrancy attack”, un tipo de vulnerabilidad que puede tener muy graves consecuencias sobre nuestros SmartContracts. El uso de este ataque es muy conocido en la comunidad de Web3 y rara es la vez que un contrato que ha sido previamente auditado es desplegado conteniendo esta vulnerabilidad. Pero, ¿y si os dijera que existe un exploit que se aprovecha de los contratos que previenen los ataques de reentrancy, una vulnerabilidad que ha pasado desapercibida por la comunidad durante bastante tiempo?

Figura 1: Read-Only Reentrancy Attack: $220k robados y +$100M en riesgo

Este exploit/vulnerabilidad es el “Read only reentrancy attack” una modalidad del reentrancy que no afecta directamente a la explotación de fondos, sino a los contratos DeFi que interactúen con él o dependan de los datos que este pueda proveer. Esto se traduce en que puede afectar a todos aquellos protocolos y oráculos que dependan de fuentes externas de alguna manera, y más en concreto a protocolos descentralizados de routing de DEXs (como QuickSwap o 1inch).

“Read-only reentrancy”

Fijaos en el siguiente contrato, en el que podréis ver que en la línea 14 el SmartContract es vulnerable a un reentrancy, en la función withdraw().

Figura 2: Contrato vulnerable al Reentrancy

El esquema de ataque para este contrato sería el típico de un reentrancy, si queréis una explicación en más detalle podéis ir a este artículo en el que Pablo Gonzalez nos explica cómo funcionaba la vulnerabilidad.

Figura 3: Esquema de vulneración de un contrato usando “Reentrancy”

Podríamos solucionar el exploit actualizando los datos del balance antes de hacer la llamada; o incluso implementando un “cerrojo”. En este caso usamos una librería de Openzeppelin que nos facilita bastante su implementación.

Figura 4 Contrato vulnerable al “Read only reentrancy”

Pero aun así seguiría siendo vulnerable al “Read only reentrancy”; aunque el “cerrojo” implementado no permite al atacante llevarse fondos al llamar a su función “fallback” (línea 9), éste sí que permite entre medias realizar una llamada a algún contrato DeFi dependiente de los datos del contrato original(el vulnerable), y el contrato llamado no dispondrá los datos actualizados. Un ejemplo de cómo se puede explotar esta vulnerabilidad es el siguiente:

1. Contrato Attacker, llama a la función withdraw() del contrato Vulnerable. 

 

2. Vulnerable, para devolver los fondos tiene que llamar a fallback() de Attacker. 

 

a. Llama a fallback() porque así se envía el ETH en este caso. 

 

b. Podría ser cualquier tipo de llamada externa 

 

3. Attacker desde fallback() llama a lendMe() en DeFi, dependiente de los datos de Vulnerable. 

 

4. DeFi lee los datos de Vulnerable pero estos están desactualizados y realizará acciones que no debería.

Figura 5: Diagrama explotación vulnerabilidad “Read only reentrancy”

Un ejemplo de mitigación sería actualizar los datos antes de hacer las llamadas, pero esto no siempre es posible, muchas veces necesitaremos obtener datos de otra fuente para poder continuar.

$200k en un ataque a Quick Swap

En este caso, el read only reentrancy ya se cobró una importante víctima el pasado 24 de octubre, el DEX de QuickSwap. En este caso el ciberatacante usó este tipo de reentrancy para manipular el precio de un activo en una pool de liquidez de Curve (otro DEX) que le permitió tomar prestado más cantidad de la normal en el Lending de QuickSwap.

Figura 6: Protocolos con riesgo, por ChainSecurity

Si queréis profundizar en detalle en cómo se realizó el ataque, podéis leerlo en este artículo. Además según ChainSecurity (firma que ha auditado protocolos como el de Curve o Compound) en reportes recientes de sus auditorías unos $100M estarían en riesgo por esta vulnerabilidad.

Conclusiones

Este ataque aunque no afecte de una manera directa a los fondos del contrato puede provocar la explotación del mismo o de otros contratos. Es un vector de ataque que en parte se aprovecha de los contratos que usan “cerrojos” para evitar ser vulnerados con un reentrancy “normal”, por ello es incluso más crítico aún.  Sobre todo este exploit afecta de manera importante a todos aquellos contratos que sirvan como fuente de datos, tokens, oráculos, sistemas de reputación basados en tokenomics...

Figura 7: Libro dedicado a "Bitcoin: La tecnología Blockchain y su investigación"
de Yaiza Rubio y Félix Brezo

Seguiremos hablando de este tipo de ataques que cada día van a ser más peligrosos en nuestros servicios digitales con la llegada masiva de la Web3.

Más artículos de Web3, Blockchain & SmartContracts

• Blockchain & SmartContracts: Una serie para aprender
• BlockChain & SmartContrats: Primer SmartContract con Solidity
• Blockchain & SmartContracts: Cómo probar y desplegar un SmartContract en Ethereum
• WWW, Web 1.0, Web 2.0, Web 3.0, Web3 y ¿Web 4.0?
• Metaverso, multiverso y las tierras digitales en que vivimos en forma de avatar
• Los Fan Tokens vs. las Criptomonedas y los NFTs: Level 101
• Tokenomics: Las criptomonedas y las "Proof-of-work": Level 101
• Los NFTs y el registro mundial de los dueños de activos digitales en el Metaverso
• BitCoin: Blockchain y su investigación
• BlockChain & SmartContrats: El Internet descentralizado y el almacenamiento off-chain en IPFS
• Reentrancy Attack: Cómo te roban criptomonedas por un bug en tu SmartContract
• BlockChain & SmartContract: Bugs que pueden dejar tu SmartContrat "fuera de juego"
• Blockchain & SmartContracts: Patrones y buenas prácticas de seguridad
• Blockchain & SmartContracts: Herramientas de Auditoría de Seguridad de SmartContracts
• BlockChain & SmartContracts: Ataque de phishing a tx.origin y robo de criptomonedas
• BlockChain & SmartContracts: Ataques de Ice Phishing
• Blockchain & SmartContracts: Herramientas de análisis dinámico
• ZIION: Una distribución Linux para auditar SmartContracts (& BlockChain)
• Dominios Web3 en Etherenum Name Service y la trazabilizad de las transacciones Blockchain
• BlockChain & SmartContracts: Actualizar SmartContracts como los grandes protocolos
• Jumping level up (from) web2 (to) web3: Vulnerabilities & SCAMs - SmartContracts
• 20 millones (Euros) en Tokens de Optimism perdidos por no saber cómo funcionan los Wallets Multifirma
• BlockChain & SmartContracts: Cómo crear una DApp de la Web3 con Python (y Flask)
• Pentesting SmartContracts: From Web2.0 to Web3
• Tokenomics 101: Una explicación con gráficos
• Read-Only Reentrancy Attack: $220k robados y otros +$100M en riesgo

Saludos,

Autor: Chema Garabito. Desarrollador Full-Stack. Ideas Locas Telefónica CDO.

Contactar con Chema Garabito

"Ser un escritor es un trabajo difícil en sí mismo", dijo la máquina

Si has empatizado con la frase del principio, entonces ChatGPT captura bien las emociones cuando le pides que te haga algo emotivo. Y si esto es así, probablemente, en breve, escribir un artículo para muchos escenarios, va dejar de merecer la pena invertir "recursos" humanos. Hoy, le he querido pedir que escriba él mi blog, que haga el artículo. ¿Sobre qué tema? Pues nada, sobre lo difícil que es escribir un artículo de seguridad informática cada día y qué significa para mí, pero que le diera un toque emotivo, como suelo hacerlo yo.

Figura 1: "Ser un escritor es un trabajo difícil en sí mismo", dijo la máquina

La trampa es que yo hice el artículo de "La página en blanco" hace un mes o así, comenzando a partir de esa sensación. Es cierto que luego le di varias vueltas de tuerca porque quería jugar un poco con la idea de que escribir un artículo es acto de comunicarse, y elegir bien y con quién tiene su arte y su magia. Pero el sentimiento de partida era el mismo. Lo que le he pedido ha sido algo tan sencillo como unos párrafos hablando emotivamente de esto, y para ello le he dado esta entrada:

"Escribe un artículo emotivo de unos cuatro párrafos en los que hables de lo duro que es para un escritor sacar todos los días un artículo hablando de seguridad informática"

"Ser un escritor es un trabajo difícil en sí mismo, pero cuando se trata de escribir sobre un tema tan técnico y poco emocionante como la seguridad informática, puede ser aún más desafiante. Todos los días me siento ante mi ordenador con la responsabilidad de encontrar nuevos ángulos y enfoques interesantes para hablar de un tema que, a pesar de su importancia, muchas veces puede parecer aburrido y desalentador.

A veces me encuentro luchando por encontrar la motivación para seguir escribiendo. La seguridad informática es un tema vasto y complicado, y a veces puede ser difícil mantenerse al día con las últimas tendencias y desarrollos. Además, sé que muchas veces mis artículos pueden ser leídos por un público limitado, lo que puede hacer que me sienta como si estuviera hablando en el vacío.

Pero a pesar de todas estas dificultades, sigo escribiendo sobre seguridad informática todos los días. Lo hago porque sé que la seguridad de nuestros dispositivos y datos es cada vez más importante en un mundo cada vez más conectado. A medida que dependemos cada vez más de la tecnología en nuestras vidas cotidianas, es crucial que nos aseguremos de que nuestros dispositivos y datos estén protegidos contra los ciberataques y otras amenazas.

A veces, cuando me siento abrumado por la tarea de escribir sobre seguridad informática todos los días, me recuerdo a mí mismo por qué lo hago. Escribo porque sé que lo que estoy haciendo tiene un propósito importante y puede ayudar a las personas a protegerse a sí mismas y a sus seres queridos en un mundo cada vez más peligroso. A pesar de las dificultades, sigo adelante porque sé que lo que estoy haciendo tiene un valor real."

No ha estado mal, pero creo que se puede mejorar, así que le he dado una nueva oportunidad, y le he pedido que lo vuelva a intentar. 

"Try Again."

"Ser un escritor puede ser un trabajo solitario y a veces difícil. Pero para aquellos que escriben sobre temas técnicos como la seguridad informática, el desafío puede ser aún mayor. La seguridad informática es un tema complejo y cambiante, y mantenerse al día con las últimas tendencias y desarrollos puede ser un desafío constante.

Pero lo más difícil de escribir sobre seguridad informática día tras día es encontrar una manera de hacerlo interesante y accesible para el público general. La seguridad informática puede ser un tema abrumador para aquellos que no tienen un conocimiento técnico profundo, y encontrar una manera de presentar la información de manera clara y concisa puede ser un desafío.

Además, la seguridad informática es un tema que a menudo se relaciona con noticias negativas, como brechas de seguridad y ciberataques. Hablar sobre estos temas de manera sensata y equilibrada puede ser difícil, y puede requerir una gran cantidad de investigación y análisis para asegurarse de que se está presentando la información de manera precisa y completa.

Pero a pesar de todos estos desafíos, los escritores que se dedican a la seguridad informática continúan trabajando día tras día para informar y educar al público sobre este importante tema. Hacen un trabajo valioso al ayudar a las personas a protegerse a sí mismas y a sus dispositivos contra amenazas cibernéticas, y su trabajo es vital para mantener a las personas seguras en un mundo cada vez más conectado.

En resumen, escribir sobre seguridad informática puede ser un desafío, pero es un trabajo importante y valioso que ayuda a mantener a las personas seguras en un mundo cada vez más digital. A pesar de los desafíos, los escritores que se dedican a este tema continúan trabajando día tras día para informar y educar al público sobre la importancia de la seguridad informática."

Y ahora el toque final, vamos a ponernos un punto de mártir en la redacción, así que le voy a pedir que el texto tenga empatía con alguno de nuestros problemas.

"Añade un párrafo en el que expliques que, además, para hacer las pruebas de las vulnerabilidades se arriesga uno a cometer un delito solo por contar mejor cómo funciona el problema."

"Además de todos los desafíos mencionados anteriormente, los escritores de seguridad informática a menudo se enfrentan a la difícil tarea de hacer pruebas de vulnerabilidades para demostrar cómo funcionan los problemas de seguridad. Esto puede ser arriesgado, ya que en algunos casos puede ser considerado un delito simplemente por hacer las pruebas.

Esto plantea un dilema moral para los escritores, ya que quieren informar y educar al público sobre los problemas de seguridad, pero al mismo tiempo no quieren cometer un delito. Esto puede ser aún más complicado cuando se trata de vulnerabilidades críticas que pueden afectar a miles o incluso millones de personas, y que requieren pruebas para ser comprendidas completamente.

En estos casos, los escritores de seguridad informática a menudo tienen que tomar decisiones difíciles y trabajar de cerca con las autoridades para asegurarse de que sus pruebas se realizan de manera segura y legal. Aunque puede ser un desafío, estos escritores siguen adelante en su labor de informar y educar al público sobre la importancia de la seguridad informática."

No he tocado ni una coma de su texto, y sinceramente creo que, si le cambio cuatro cosas, hubiera pasado por un posible artículo de esos que escribo yo de cuando en cuando sobre cosas personales de mi vida. Eso sí, os prometo que para escribir "La página en blanco" invertí más de dos horas.  Pero si le tiro de la lengua, le busco las cosquillas, y le pido que afine algunos párrafos, me hace uno que vaya que vaya. Así que, a partir de ahora, cuando leamos las cosas, vamos a ver si empatizamos con una persona que está detrás, o un algoritmo de Inteligencia Artificial que genera textos.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

MagicRecon: herramienta para la recolección de datos y la búsqueda de vulnerabilidades en un objetivo

En el mundo del pentesting la fase de reconocimiento, o también conocida como recolección de información, es una de las más importantes para poder llevar a cabo un proceso de Ethical Hacking efectivo, y de manera cómoda. La principal misión de esta fase es conocer todos los detalles de nuestro objetivo. Si utilizamos de ejemplo algún programa de Bug Bounty, nuestra fase de recolección de información se centrará principalmente en conocer todos los activos que tiene el objetivo, que tecnologías y servicios utilizan, en qué puertos están los servicios, etcétera.

Figura 1: MagicRecon: herramienta para la recolección de datos

y la búsqueda de vulnerabilidades en un objetivo

Para realizar esta fase de manera cómoda en el ámbito del Bug Bounty y también del Ethical Hacking en general, hemos creado la herramienta MagicRecon. La puedes encontrar en su repositorio de GitHub oficial: https://github.com/robotshell/magicRecon

Figura 2: magicRecon en GitHub

MagicRecon es una herramienta escrita en bash cuya principal finalidad es maximizar el proceso de recolección de datos sobre un objetivo y la búsqueda de vulnerabilidades comunes. Ejecutando la herramienta e introduciendo la URL del objetivo, podemos empezar a obtener información sobre el objetivo así como comprobar si es vulnerable a varias vulnerabilidades comunes como puedan ser Cross-Site Scripting (XSS), SQL Injection o Open Redirect. 

Figura 3: Libro de Ethical Hacking 2ª Edición
de Pablo González en 0xWord

También podemos comprobar otro tipo de vulnerabilidades como por ejemplo la falta de cabeceras, vulnerabilidades en certificados SSL, la falta de los registros SPF y DMARC en la configuración del correo o vulnerabilidades CORS. Todo ello, almacenado en diferentes formatos para que el usuario pueda posteriormente manejar los datos extraídos de forma fácil. A continuación, vamos a detallar cada una de las opciones de la herramienta.

Figura 4: Ejecución de MagicRecon

1) Install dependencies: La primera vez que descarguemos la herramienta desde su repositorio oficial, tendremos que utilizar esta opción para instalar todas las dependencias que hacen falta para utilizar la herramienta. Entre las dependencias encontramos muchas herramientas conocidas como Subfinder o Nuclei y lenguajes de programación como Go.

2) Massive vulnerability analysis with notifications via Discord, Telegram or Slack: La segunda opción que encontramos en la herramienta, es quizás unas de las opciones más interesantes para los usuarios que utilizan la herramienta en programas de Bug Bounty. Antes de poder lanzar esta opción, deberemos de configurar la herramienta Notify para poder recibir las alertas en alguna de las tres aplicaciones disponibles, Slack, Discord o Telegram. Una vez configurado, podremos lanzar esta opción de la herramienta. Lo primero que se nos pedirá es una URL objetivo y un número de segundos.

Figura 5: Libro de Bug Bounty: De profesión "Cazarrecompensas"

en 0xWord, escrito por Pablo García

La herramienta empezará a realizar una enumeración de subdominios sobre la URL objetivo introducida por el usuario y posteriormente a cada uno de los subdominios activos encontrados se le pasarán todas las  plantillas de la herramienta Nuclei en busca de vulnerabilidades. Si en alguno de los subdominios se descubre alguna vulnerabilidad, se nos enviará una notificación a la herramienta que hayamos configurado (Slack, Discord o Telegram) para recibir las alertas. 

Figura 6: La app Slack recibiendo notificaciones

Este proceso de enumeración de subdominios y posteriormente la búsqueda de vulnerabilidades se repetirá cada X segundos, donde X es el número de segundos que ha introducido el usuario.En resumen, con esta opción de la herramienta podemos tener un escáner automático de vulnerabilidades que está constantemente buscando nuevos subdominios y vulnerabilidades sobre un objetivo.

3) Subdomain enumeration: La tercera opción que encontramos en la herramienta nos permite realizar una enumeración de subdominios completa utilizando la herramienta Subfinder y Gobuster. Con httpx comprobaremos que subdominios están vivos y finalmente, con Aquanote, la herramienta realizará una captura de pantalla de cada uno de los subdominios para poder visualizar de forma fácil su contenido.

Figura 7: Aquatone realizando capturas de pantalla sobre

algunos subdominios de Hackerone.

4) Subdomain enumeration and vulnerability scanning with nuclei: Con esta opción de la herramienta podremos realizar la misma función que la opción anterior, pero cada uno de los subdominios activos descubiertos se ejecutará con la herramienta Nuclei para buscar vulnerabilidades.

5) Subdomain enumeration with common vulnerabilities scanning: Con esta opción de la herramienta realizaremos todos los pasos de la opción 3 pero incluiremos la comprobación de una serie de vulnerabilidades como la falta de cabeceras en los dominios, la falta de los registros SPF y DMARC en la configuración del correo, vulnerabilidades CORS, Open Redirect, XSS, SQL Injection, etcétera.

6) Scan for javascript files: Los ficheros JavaScript pueden esconder información interesante para un atacante como usuarios, contraseñas, endpoints o API keys. Con esta opción lo que hará la herramienta es analizar todos los ficheros JavaScript que se encuentren en el dominio y analizar su contenido en busca de datos de interés.

Figura 8: Libro de Hacking Web Technologies 2ª Edición en 0xWord de
Chema Alonso, Enrique Rando, Amador Aparicio, Pablo González y Ricardo Martín

7) Scan for files and directories: Mediante esta opción, podremos realizar un escaneo de directorios y ficheros usando la herramienta Wfuzz, para ello, el usuario deberá introducir un diccionario en las variables de configuración del script.

8) All in one!: Esta es sin duda la opción más usada de la herramienta ya que junta la opción 3, 5, 6 y 7 en una sola. Inicialmente esta opción era el core del proyecto MagicRecon ya que simplemente introduciendo una URL objetivo, la herramienta nos devuelve todos los subdominios posibles, las vulnerabilidades que se encuentran en cada subdominio, se analizan todos los ficheros JavaScripts encontrados y se realiza un escaneo de ficheros y directorios. Todo ello, almacenado de forma ordenada y en diferentes formatos para que el usuario pudiera manejar los resultados de la herramienta de forma fácil.

Figura 9: Resultados de utilizar la opción Subdomain Enumeration.

Acabamos de ver en detalle cada una de las opciones disponibles dentro de la herramienta, cabe destacar que la herramienta está en continuo desarrollo y es posible que se añadan nuevas funcionalidades o se mejoren algunas de las que ya había. Actualmente se está trabajando en mejorar el rendimiento de la herramienta y en la función de reporting para que los usuarios dispongan de un resumen más cómodo y llamativo, para ello, se está trabajando en poder almacenar los resultados en formatos como PDF, CSV y JSON.

Sin duda, se trata de una herramienta muy interesante y fácil de utilizar que hay que incluir en nuestra mochila de Red-Team, ya que con ella podemos abordar diferentes ámbitos del proceso de Ethical hacking, como la fase de recolección de información o la fase de búsqueda de vulnerabilidades.

HAPPY HUNTING!

Autor: Agustín Doménech "RobotShell"

Contactar con Agustín Doménech

Hazte un "Máster" en DevSecOps

Uno de los roles profesionales que más demandados se han hecho en los últimos cinco años y que tiene que ver con la ciberseguridad es el de DevSecOps o SecDevOps, que de las dos formas lo han estado solicitando las empresas. Este rol busca tener especialistas que automaticen los despliegues de los entornos, los entornos de seguridad, los desarrollos realizados, utilizando scripts automatizados que cubran todas las fases de ciclo de desarrollo y puesta en producción de un servicio con, por supuesto, todas las fases de seguridad.

Figura 1: Hazte un "Máster" en DevSecOps

De este tipo de actividades hemos hablado mucho por aquí, como hablaba hace poco del trabajo de SecDevOps y las Linux Capabilities, o el artículo que debes leer para entender bien este trabajo que se llama "SecDevOps: una explicación en 5 minutos (o alguno más)" donde vas a ver cómo se aplican los conocimientos de estos profesionales a las diferentes fases de la construcción de tecnología en las empresas. Esta, como ya he dicho es una profesión de las más demandadas hoy en día.

Figura 2: Máster en DevSecOps

Como ya sabéis, nosotros hicimos el libro de Docker: SecDevOps escrito por Fran Ramírez, Elías Grande y Rafael Troncoso en 0xWord precisamente por esta alta demanda para roles de ciberseguridad, y en el Campus Internacional de Ciberseguridad se ha diseñado el Máster en DevSecOps que dirigen nuestros compañeros Pablo González y Juanjo Salvador y que comienza el próximo 6 de Abril de 2021.

Figura 3: Máster Online en DevSecOps

Para este Máster Online de DevSecOps, el temario que se ha trabajado cuenta desde la parte pura de operaciones, hasta la parte pura de seguridad, para mezclar ambas con automatización de scripts en entornos de gestión de infraestructura, gestión de aplicaciones, y cumplimiento normativo, con un Trabajo Final de Máster que hemos diseñado los profesores. Estos son los módulos.

Módulo 1.- DevOps: Filosofía e Introducción.

Módulo 2.- DevOps: Construyendo la base.

Módulo 3.- DevSecOps: Ciclo de vida de desarrollo seguro.

Módulo 4.- DevSecOps: Monitorización.

Módulo 5.- SAST: Pruebas de seguridad a aplicaciones estáticas.

Módulo 6.- DAST: Pruebas de seguridad a aplicaciones dinámicas.

Módulo 7.- Infraestructura y Compliance.

Módulo 8.- Gestión de Vulnerabilidades.

Módulo 9.- Trabajo Final de Máster.

Dentro del Trabajo Fin de Máster yo, que como sabéis estoy de Mentor en el Campus Internacional de Ciberseguridad, he propuesto varios trabajos para diferentes Másters, así que lo mismo uno de estos trabajos acabas haciéndolo conmigo, si te gusta lo que yo propuesto, lógicamente.

Figura 4: Profesores del Máster en DevSecOps

El profesorado de este Máster Online DevSecOps, pues es de envidiar, por supuesto. Pablo González al que ya conocéis de muchos años conmigo por aquí, Fran Ramírez, Elías Grande y Rafael Troncoso que son los autores del libro de Docker:SecDevOps, Javier Espinosa, Head of Software de Movistar Home y Living Apps en mi unidad CDCO de Telefónica, Juanjo Salvador, Daniel Echeverry, escritor de los libros de Python para Pentesters [2ª Edición], Hacking con Python y DeepWeb: Tor, FreeNet e I2P, y Ricardo García, QA de seguridad en Telefónica.

Figura 5: Libro de Docker:SecDevOps

Además, todos los alumnos de este Máster Online de DevSecOps tendrán como material de complemento para su formación, el libro de Docker:SecDevOps de Fran Ramírez, Elías Grande y Rafael Troncoso que hemos publicado en 0xWord y 500 Tempos de MyPublicInbox para poder consultar con ellos con cualquiera de nosotros cualquier duda, así que después de esta formación, si la aprovechas estudiante, sales listo para empezar a trabajar en estos roles tan demandados. Si quieres más información para convertirte en un "máster" en DevSecOps puedes pedirla en la web de Máster Online DevSecOps.

Saludos Malignos

Autor: Chema Alonso (Contactar con Chema Alonso) - Consigue 100 Tempos en MyPublicInbox

Cómo fortificar containers en Kubernetes … "Like a Boss"

En esta pasada RootedCon 2020 tuvimos la oportunidad y el honor de presentar una charla sobre la fortificación de contenedores cuando desplegamos una aplicación en Kubernetes. En ella, reunimos algunos de los conceptos que hemos ido contando en este blog sobre este mismo tema y la tecnología Kubernetes durante los últimos meses.

Figura 1: Cómo fortificar containers en Kubernetes … "Like a Boss"

La presentación, que comenzamos el viernes 6 de marzo a las 10:00, empezó fuerte ;) directamente con una demo de una aplicación vulnerable desplegada en un clúster de Kubernetes local (minikube), especificando los parámetros necesarios para dicho despliegue. Per antes de continuar, nos gustaría recordaros que nuestro libro Docker:SecDevOps puede ser un buen punto de partida para comenzar en este mundo de los contenedores.

Figura 2: Libro de Docker:SecDevOps

Volviendo a la demo (aquí podéis ver las diapositivas), en ella mostramos una aplicación programada por nosotros, la cual nos permitía crear notas simples. Dichas notas se guardaban directamente en el sistema de ficheros. De forma intencionada, esta aplicación tenía una vulnerabilidad tipo path traversal, y través de la manipulación de una cookie, éramos capaces de listar el contenido que cualquier directorio del sistema, crear notas en cualquier directorio, ver el contenido de ficheros existentes, mostramos un el token de la cuenta de servicio asociada al pod, algo que Kubernetes hace por defecto, e incluso podíamos sobreescribir el contenido de ficheros existentes incluidos lo del sistema.

Figura 3: Demo de hacking web vulnerable

Vamos, que le podías hacer casi cualquier cosa. Esto era así porque como también pudimos ver, la aplicación corría como root (usuario por defecto de un contenedor Docker, a menos que especifiquemos otro). También mostramos cómo existía un punto de depuración que nos permitía ejecutar comandos en el sistema, y por último también demostramos que era posible descargar cualquier fichero desde Internet.

En el vídeo de la Figura 3 tienes muchos ejemplos de lo que podías hacer, pero si quieres aprender a hacerle más cosas, puedes leer el libro de Hacking Web Technologies de Chema Alonso, Pablo González, Enrique Rando, Amador Aparicio y Ricardo Martín.

Figura 4: Libro de Hacking Web Technologies de Chema Alonso,
Pablo González, Enrique Rando, Amador Aparicio y Ricardo Martín

Una vez terminada la demo (que funcionó a la perfección por cierto), mostramos las distintas opciones que tenemos a nuestra disposición en Docker/Kubernetes, para fortificar nuestros contenedores. Así que, cuando nuestro contenedor sea comprometido, podamos mantener confinado al atacante de forma que minimicemos las acciones y evitar que cree persistencia, se mueva lateralmente, etceera.

Primero hablamos de la creación de imágenes Docker, y algunas de las buenas prácticas desde el punto de vista de la seguridad. Como, por ejemplo, la importancia de la cadena de provisión, el escanéo de dichas imágenes y hicimos hincapié en el uso de imágenes pequeñas, a ser posible que tengan lo mínimo que nuestra aplicación necesite para ejecutarse. De esta forma reducimos mucho de los vectores de movimientos en caso de un incidente.

En la presentación usamos una imagen distroless como ejemplo de mejora sobre Alpine, imagen que utilizamos en la demo del inicio de la presentación. Y terminamos esta parte inicial de la charla creando un Dockerfile mejorado, dónde usamos una imagen distroless, y creamos un usuario y grupo con el cual la aplicación se ejecutará.

Figura 5: Dockerfile mejorado

De ahí, pasamos al contexto de seguridad de contenedores. Estos están muy relacionados con las Pod Security Policies que en su día ya hablamos. Nos centramos en la diferencia entre los contenedores privilegiados y los no privilegiados. También vimos las opciones que tenemos en Kubernetes para ejecutar un contenedor como no root, explicamos qué es la escalada de privilegios en contenedores y como evitarla.

Luego hablamos de la importancia de montar el sistema de ficheros como sólo lectura y de esta forma ponerle la vida más difícil a un atacante a la hora de crear persistencia o modificar cosas del sistema como se mostró en la demo inicial, y por último hablamos de la capacidades de GNU/Linux y el cómo remover éstas de nuestro contenedor y aplicar el principio de privilegios mínimos. Si quieres saber más del proceso de fortificación de un servidor GNU/Linux, te recomendamos este libro de Hardening de Servidores GNU/Linux (3ª Edición) de Pablo González y Carlos Álvarez Martín.

Figura 6: Libro de "Hardening de Servidores GNU/Linux" 3ª Edición
de Pablo González y Carlos Álvarez Martín

Siguiendo con la charla, continuamos hablando un poco de las cuentas de servicio en Kubernetes, y cómo cada pod tiene asociada una cuenta de servicio (default si no especificamos una explícitamente). Por defecto, como se mostró en la demo, Kubernetes monta dentro del pod el secreto asociado a la cuenta de servicio asignado al pod, este secreto contiene un token JWT, que no es más que una credencial que te da acceso al clúster. Con este token puedes hacer lo que tenga autorizado, pero es una credencial que el 90% de las aplicaciones no necesita.

A menos que tu aplicación necesite comunicarse con la API de Kubernetes, este token está demás, y si no lo necesitas, se recomienda que no se monte, para así evitar que se pueda exfiltrar en caso de un incidente. Por útltimo hablamos muy brevemente de las redes en Kubernetes, y nos enfocamos en las políticas de red, de las que ya hablamos en su día en el artículo: "Kubernetes: Gestionar Políticas de red Like a Boss".

Figura 7: Esquema que muestra el control de acceso en el contexto de seguridad de los Pods

En la fase final de la charla mostramos los cambios que hicimos en el fichero de despliegue con respecto al fichero utilizado para el despliegue de la demo inicial. Y con dichos cambios cambios, teníamos preparada una segunda demo con la que terminamos la presentación. En dicha demo no habíamos cambiado nada del código de dicha aplicación, por lo que las vulnerabilidades mostradas al principio aún existían, la diferencia en este caso era demostrar que ahora el atacante, tenía poco que hacer.

Mostramos, por ejemplo, que este todavía era capaz de listar el contenido de directorios y ficheros a los que el usuario appuser (usuario con el que se ejecutaba ahora el contenedor), sin embargo, ya no podía crear ficheros en otros directorios (el sistema de ficheros estaba montado como sólo lectura) o modificar el contenido de ficheros del sistema (además del sistema de fichero estar en modo sólo lectura, el contendor ya no corría como root).

Figura 8: Rafael Troncoso (izquierda) y Fran Ramírez minutos antes de la charla

De esta forma demostramos que, gracias a que usamos una imagen distroless, ya no podíamos ejecutar comandos a través del punto de acceso de depuración, ya que en las imágenes distroless no existe shell o utilidades extras.

Y por último aplicamos una política de red restrictiva que bloqueaba tanto el tráfico de entrada como de salida a nuestra aplicación, lo cual que no era de mucha ayuda ya que no podíamos acceder a la misma en principio, para ello aplicamos un nueva política que permitía el tráfico de entrada, pero no el de salida. De forma que ahora ya no podíamos descargar nada desde internet, tal y como ocurría durante la primera demo.


Figura 9: Demo de fortificación de la app insegura

También quisimos dejar muy claro que esto no es una forma de arreglar vulnerabilidades en una aplicación, sino más bien puede ser un Plan B o Plan de Contingencia para cuando tu aplicación sea comprometida, algo que seguro, pasará.

Figura 10: Repositorio de GitHub con todo el material de la charla

Finalmente, afortunadamente todo salió como teníamos previsto y la experiencia fue muy buena. Pronto estará la charla publicada en la web de la RootedCon, os avisaremos por las redes sociales. De momento, el contenido del material usado en las demos, así como las diapositivas se encuentran disponibles en nuestro repositorio de GitHub. Gracias a RootedCon y todos aquellos que fuisteis a la charla.

¡Quédate en casa!

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.

 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.

Contactar con Rafael Troncoso en MyPublicInbox

Los bares { y las "Rutas de las Tapa" } también necesitan [ciber]seguridad (Parte 1 de 2)

Rutappa es una aplicación usada por multitud de consistorios de localidades de la geografía española para dar soporte al evento “Ruta de la Tapa”. A través de ella, los bares, restaurantes y demás participantes suben su tapa estrella para ser votada por los visitantes o comensales (más información en rutappa.es). El visitante entra en un sorteo por votar (cuanto más tapas diferentes voten, más posibilidades de ganar) y los bares y restaurantes aspiran a convertirse en el ganador de la “Ruta de la Tapa” de ese año y, por tanto, a exhibir la placa indicativa que les es entregada. En las siguientes líneas vamos a contar qué ocurrió durante el año paso.

Figura 1: Los bares { y las "Rutas de las Tapa" } también necesitan [ciber]seguridad
(Parte 1 de 2)

Recibimos en la oficina de blockchain3rs una llamada de un amigo personal. Su padre es propietario y regente de un bar/restaurante situado en un pueblo cualquiera de una provincia cualquiera de España. Es el negocio familiar y en él está toda la familia implicada y volcada en mejorarlo día a día. Algunos, como nuestro amigo, tienen otra profesión pero echa una mano cuando puede. Quizá en esta ocasión no solo va a ayudar a su padre sino al resto de bares y restaurantes que, con esmero y esfuerzo, participan en la "Ruta de la Tapa" de su región cada año.

Nuestro amigo nos comenta que no se fía del sistema de voto: este año se vota vía app, y cree que el ganador puede que no sea aquel más votado por los comensales reales, sino alguien que esté haciendo trampas manipulando las votaciones. Si esto fuera así, podríamos estando poniendo en riesgo la reputación de un bar, o favoreciendo a la reputación de un restaurante de forma engañosa, simplemente porque alguien tiene conocimientos de algún fallo de seguridad.

Análisis inicial de sistema  de votaciones de Runtappa

Nosotros decidimos implicarnos, y revisar a ver si el sistema de votación era robusto o cabía lugar a una manipulación por parte de alguien "tramposo" que quisiera aprovecharse. “Le vamos a echar un vistazo a la app, es casi todo lo que podemos hacer” - Le dijimos. La lógica que implementa la app para permitir a un usuario votar es la siguiente:

1) El comensal se descarga la app desde Google Play (Android) o App Store (Apple) y selecciona la ruta en la que se encuentra:

Figura 2: Aspecto de Runtappa

2) El usuario selecciona la tapa que “más le gusta”, después de supuestamente haber podido probar todas o al menos algunas. No se puede comprobar mucho de esta parte porque hay que fiarse de la buena voluntad de la persona que participa en este evento de forma altruista y como manera de agradecer el esfuerzo de los bares y restaurantes por esmerarse en esta costumbre tan nuestra de poner tapas.

Figura 3: Selección de la tapa que vamos a votar

3) El comensal le da 5 estrellas (o aceitunas) e introduce el código propio de la tapa que se encuentra en el bar o restaurante en cuestión.

Figura 4: Votando con aceitunas a la tapa

4) Si el usuario quisiera volver a votar por la misma tapa, el sistema no le permitiría hacerlo pues las protecciones de la app, a priori, no permiten votar a la misma persona más de una vez la misma tapa.

Figura 5: No se puede votar dos veces a la misma tapa

Pero la pregunta es, ¿será posible saltarse fácilmente esta protección? ¿Se puede hacer que voten muchas personas sin necesidad de utilizar la app? ¿Se podría manipular completamente el sistema de votaciones de un evento de "Ruta de la Tapa" en el que muchos restauradores se dejan tiempo y esfuerzo?

La vulnerabilidad en Runtappa

La primera acción natural que nos venía a la mente ejecutar fue la de “enterarnos” qué datos se intercambiaban la app y el servidor y cómo (protocolo o lógica) tenían implementado para evitar el double spending (en este caso realmente que un usuario no pueda votar dos veces la misma tapa).

Inicialmente asumimos que las conexiones entre app y servidor irían cifradas (haciendo uso de conexiones https probablemente) así que directamente nos decidimos a preparar un entorno de man-in-the-middle attack a nosotros mismos. A nuestro cliente. A nuestro móvil. Esta es una práctica muy común en la auditoría de aplicaciones web que se usa para poder hacer el uso de servidores proxy que nos permitan ver, detener, manipular y enviar las peticiones que van entre el cliente y el servidor.

Figura 6: Hacking Web Technologies

Con el fin de descifrar los datos y entender el flujo de la lógica del sistema de votos, con esta técnica, haríamos creer al servidor que el cliente real es nuestro servidor Proxy Forward y al cliente (la app de Runtappa) que el servidor real es también nuestro servidor Proxy Forward. Nuestro proxy controlaría y podría reportarnos entonces la conversación en claro entre las dos partes.

En el protocolo de iniciación de conexión Https, el cliente terminaría cualquier intento de establecimiento de conexión con el servidor si la firma de la entidad certificadora que va incluida en el certificado que le envía el servidor no se verifica correctamente con la clave pública de tal entidad certificadora o si el certificado que presenta el servidor no pertenece a la lista de certificados “root” de entidades certificadoras conocidas y fiables que tiene instalado el cliente por defecto.

¿Qué podemos hacer entonces? Convertirnos nosotros en una entidad certificadora en la que el cliente confíe también para, así, hacer a la app cifrar sus mensajes con el certificado que le demos desde nuestro servidor proxy (simulando por supuesto los datos esperados por el cliente en cuanto nombre, dominio…) y poder descifrarlos, y a continuación, volver a cifrar esa petición en plano con el certificado que nos envíe el servidor real. La claves simétricas negociadas en el proceso “handshake” entre cliente (app) y servidor proxy (controlado por nosotros) y entre el servidor proxy y el servidor real son por tanto conocidas por nuestro proxy.

La herramienta propietaria Charles es ampliamente usada y reconocida como buen monitor / proxy para hacer el ataque que pretendemos; sin embargo, vamos a hacer uso de la herramienta Open Source mitmproxy, la cual, además, es muy flexible y permite interceptar y modificar “on the fly” los mensajes usando su API en Python (luego veremos que haber hecho uso de esta herramienta fue un “overkill”, aunque esto es algo inherente a la ciberseguridad, donde haz de empezar con tus propias premisas y donde casi todo es parte de una búsqueda). Preparamos la infraestructura a través de los siguientes pasos (nuestro proxy correrá sobre una máquina con OSX Catalina y nuestra app cliente en iOS 13.2.3).

Figura 7: Configuramos la conexión WiFi para redirigir el tráfico al proxy

1. Instalamos desde el terminal la herramienta mitmproxy: $ brew install mitmproxy
2. Ejecutamos el programa en su versión interfaz web: $ mitmweb
3. Redirigiremos el tráfico de nuestro móvil a nuestro servidor proxy. 

Para hacer este proceso, tanto nuestra máquina proxy como el móvil tienen que estar conectados a la misma red. En nuestro caso, a la red wifi de la oficina. Configuramos nuestro móvil de la siguiente manera. En “Server” pondremos la dirección IP de nuestra máquina, y el puerto por defecto donde corre nuestro proxy (mitmweb) es 8080.

Figura 8: Redirigiendo el tráfico a nuestro proxy

Para obtener la dirección IP de nuestra máquina OSX Catalina donde tenemos instalado el Servidor Proxy, podemos ejecutar el siguiente comando en terminal (si estás conectado vía WiFi):

$ ipconfig getifaddr en0

O bien obtenerla a través de Preferencias -> Red -> Avanzado -> TCP/IP -> IPv4 Address.

4. A continuación solo quedaría instalar el certificado.

a. Accede a esta URL y selecciona el de Apple.

Figura 9: Acceder a mitm.it para instalar el certificado

b. Instálalo y verifícalo accediendo a Settings -> General -> About -> Certificate Trust Settings. Habilítalo:

Figura 10: Confianza en el certificado del servidor proxy

5. Voilà! Abre la app rutappa y accede al navegador que arrancó cuando ejecutaste el paso 2.

La primera sorpresa es que, a pesar de todo, esta app no está usando conexiones seguras bajo HTTPs. Toda la comunicación con su backend ocurre sobre tráfico HTTP sin cifrado por lo que no está protegida su privacidad, ni su integridad y podríamos haber montado entornos mucho más sencillos para interceptar el tráfico.

Figura 11: Peticiones HTTP al servidor

La conversación ocurre en texto plano.  El endpoint en el servidor que usa la app para votar es una URL tan sencilla como:

 http://retalis.es/newrutappa/rutappa_connect/votar.php

Donde se envían como parámetros por POST “deviceid”, “pid”, “voto”, “telefono”. Demasiada poca información como para controlar todos los votos que se envíen de forma maliciosa.

Figura 12: Peticiones por POST con los parámetros

Como vemos en las imágenes, cuando hacemos un Replay Attack de la llamada, obtenemos en "Response" el mensaje que leíamos desde la app cuando intentábamos votar la misma tapa por segunda vez.

Figura 13: Ataque de replay controlado 

Sin embargo, variando simplemente los parámetros “deviceid” y “telefono” y podíamos hacer un replay exitoso: el sistema de votos es demasiado sencillo de saltar. La app en el servidor no valida nada. Ni que el número telefónico esté bien formado, ni que el identificador de dispositivo tenga cierto formato, hash de 32 caracteres generado con datos del dispositivo del cliente, del que hablaremos un poco más en la segunda parte de este artículo.

Figura 14: Modificando telefóno y hash se da por válido.

Modificando estos dos parámetros, podías votar infinitas veces a la misma tapa. Rompías el concurso. Por otra parte, nos resultaba extraño que te pidiese el número de teléfono y que activaras la geolocalización sin presentarte alguna hoja de condiciones para que las aprobases relacionado con la Ley General de Protección de Datos (GDPR).

Pero aún quedan muchas cosas por evaluar, y es verdad que podrían ponerse medidas en el lado del servidor para poder detectar aquellas que pudieran haber sido fraudulentas. Todo dependería de qué procesos hubiera en el servidor para mirar cosas como los parámetros DevideID, número de teléfono, USER-Agent, Time-Stamp y dirección IP de la votación, que son todos los datos que el servidor tiene de cada voto, pero lo veremos en la segunda parte de este artículo.

Saludos.

Autor: Paco García Villarán