jueves, abril 28, 2022

SmartContracts: Bugs que pueden dejar tu contrato ‘fuera de juego’

Hemos hablado sobre el Ataque de Reentrancy y cómo evitarlo en un SmartContract. Vemos que el crecimiento de los SmartContract es rápido y nos abre un mundo nuevo de posibilidades a través de la Web3. Hoy vamos a trabajar otras vulnerabilidades que pueden afectar a las posibilidades de un SmartContract. Las denegaciones de servicio son la pérdida de disponibilidad de un activo y es una vulnerabilidad que afecta a una de las dimensiones de la ciberseguridad.

Figura 1: SmartContracts: Bugs que pueden dejar tu contrato ‘fuera de juego’

Por esta razón, un DoS en un contrato puede suponer la pérdida de disponibilidad de dicho contrato y los usuarios que tienen fondos o que tienen que operar con dicho contrato pueden verse afectados no pudiendo realizar operaciones. Esto es un problema que como se irá viendo en el artículo, puede llevar a la pérdida de las operaciones y el bloqueo de fondos en un contrato.

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

En el ámbito de la denegación de servicios de un contrato existen muchas formas, por lo que desde el punto de vista de desarrollo se deben tener en cuenta muchos aspectos y realizar muchas pruebas antes del despliegue para encontrar fallos que provoquen el bloqueo de operación en el contrato.

Ejemplificando el caso de DoS

Para entender mejor todo esto, vamos a ejemplificar el caso de la denegación de servicio (o un caso) a través de un supuesto. Para ello, vamos a proponer el siguiente escenario:
  • Pensemos que tenemos un sistema de pujas a través de un SmartContract.
  • El SmartContract tiene una función que se encarga de recibir una puja de un contrato / usuario. Si este contrato / usuario pujan con más cantidad de fondos, lo que hace el contrato es devolver los fondos metidos por el anterior “pujista” y colocan como virtual ganador de la puja al nuevo “pujista”.
Para entender esto último podríamos comentarlo de la siguiente manera:
  • Recibo puja
  • Compruebo si la puja es mayor que la que tengo almacenada como ganadora
  • Si la puja es mayor, devuelvo los fondos del anterior ‘pujista’ y guardo los nuevos fondos y pongo el nuevo virtual ganador de la puja
¿Dónde puede estar el problema?

La función interactúa en una misma llamada con dos contratos. El contrato al que se le devuelven los fondos, en caso de que haya una puja mayor, y el contrato que está pujando. Si el contrato al que devolvemos los fondos no acepta pagos tenemos un problema, ¿Por qué?

Figura 3: Esquema del ataque

Si el contrato al que se le devuelven los fondos, rechaza esto, la función (dependiendo de cómo se implemente) puede no poder devolver los fondos. Esto produce que el nuevo pujista no pueda ser ‘coronado’ virtual ganador, provocando la denegación de servicio, ya que el SmartContract que gestiona la puja no podrá nunca devolver los fondos y no podrá colocar un nuevo ganador.

Figura 4: Pablo González "SmartContrats:

En el vídeo anterior de la charla de Open Expo CyberSecurity Talent Day 2022 sobre Seguridad en SmartContrats se puede ver un ejemplo concreto de este caso expuesto con Remix IDE y Ganache como BlockChain local. Además, en el video se pueden ver conceptos básicos por si quieres comenzar a aprender sobre este y ver cómo se puede montar un laboratorio para hacer pruebas con tus SmartContracts.

Mitigando o evitando el DoS

¿Cómo podemos evitar que este tipo de fallo concreto no lo tengamos? Vamos a proponer algunas ideas, aunque no son las únicas. A continuación, enumeramos algunas opciones:

  • Lo primero que se nos puede ocurrir es hacer que el usuario sea el que solicite la devolución al ver que ya no es ganador de la puja, por lo que el contrato gestor de la puja debe tener un registro de qué fondos ha aportado cada ‘pujista’ y una función dónde el usuario solicite la devolución de sus fondos.
  • Es importante el separar la lógica de interacción con varios usuarios en una función (es justo lo que ocurría en este caso). Ya que, como se ha visto, un usuario puede afectar al resto por una decisión suya.
Una recomendación que os dejamos es que si te interesa este mundo pruebes los entornos de prueba con vulnerabilidades como, por ejemplo, https://www.damnvulnerabledefi.xyz/. En otros artículos ya trataremos más a fondo sobre estos entornos, que nos ayudan a aprender y conocer más en detalle las vulnerabilidades a las que nos enfrentamos en el mundo SmartContracts.

Figura 5: Retos para probar vulnerabilidades.

El objetivo es concienciar a las personas y que aprendan a evitar estas vulnerabilidades. Seguiremos mostrando más vulnerabilidades en el mundo de los SmartContracts y seguiremos aprendiendo más sobre este interesante mundo de la Web3. Más artículos sobre este mundo Web3:
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

Contactar con Pablo González

Publicado por Chema Alonso a las 7:41 a. m.

Etiquetas: , , , , , , ,

No hay comentarios:

Publicar un comentario

Suscribirse a: Enviar comentarios (Atom)

Entrada destacada

10 maneras de sacarle el jugo a tu cuenta de @MyPublicInbox si eres un Perfil Público

Cuando doy una charla a algún amigo, conocido, o a un grupo de personas que quieren conocer MyPublicInbox , siempre se acaban sorprendiendo ...

Entradas populares