sábado, septiembre 17, 2022

Jumping level up (from) web2 (to) web3: Vulnerabilities & SCAMs - SmartContracts

En el equipo de IdeasLocas nos gusta compartir lo que vamos aprendiendo, conociendo, investigando y probando. No se para. Prohibido pararse. Seamos ágiles, trabajemos, busquemos las vueltas y volvamos a iterar, iterar e iterar. En este 2022 hemos tenido la suerte de acudir, en algunos casos online y en otros en presencial, a diversos congresos. 

Figura 1: Jumping level up (from) web2 (to) web3.
Vulnerabilities & SCAMS on SmartContracts

Uno de los que guardo un grato recuerdo cuando estuve en 2018 y 2020 es la DragonJARCON. Este año llegaba a su novena edición y nos cogieron una propuesta en la que queríamos hablar de la seguridad en el mundo Web3 y los SmartContracts. La necesidad que tiene el mundo "cíber", hoy día, de conocer más sobre este mundo. Un mundo interesante y del que puedes aprender, no una, si no cientos de cosas diariamente.

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

En la charla se habló sobre varias cosas, principalmente sobre algunas vulnerabilidades con los riesgos asociados en los SmartContracts, así como de ejemplos de SCAMs que pueden hacer perder muchos fondos a los usuarios que sean víctima de ellos. El tema Web3 es un tema que llama mucho la atención a la gente, pero tiene una barrera de entrada, por lo que empezamos contando la base sobre algunos conceptos. Empezamos hablando sobre:
  • ¿Qué es la Blockchain?
  • ¿Qué es un wallet?
  • ¿Qué es un Smart Contract?
Son términos que todo el mundo conoce, pero quizá no todo domina desde un punto de vista claro. Cuando uno empieza a meterse en profundidad en este mundo se puede hacer algunas preguntas: ¿Dónde se ejecuta el SmartContract? ¿Qué es un nodo? ¿Qué es un proveedor? ¿La cadena Blockchain está en cada nodo? En la siguiente imagen se podía explicar que los SmartContract se encuentran en ejecución en un nodo y que los cambios persistentes que se hacen se replican a la Blockchain (es decir, en todos los nodos).

Figura 3: Gráfico de estructura de una cadena Blockchain

Otros conceptos explicados y necesarios son el de transacción. Transacciones entre wallets, entre SmartContract o de wallet a SmartContract y viceversa. Por otro lado, el despliegue de un contrato también es algo que llama la atención. Para explicar bien el concepto de despliegue de un contrato decidimos hacerlo práctico a través de un video.

Figura 4 Nodos de una cadena Blockchain

En el video se puede ver cómo se usa Remix IDE para tener nuestros contratos programados con Solidity. Además, disponemos de una Blockchain Ganache (de la suite Truffle), la cual se ejecuta en local y sirve para probar desarrollos antes de llevarlo a un entorno de Pre-Producción (una Testnet) o, posteriormente, subir nuestro contrato a una mainnet, que sería llevarlo a Producción. Os dejo el vídeo donde se puede ver que con Remix IDE todo es transparente, pero si nos ponemos a programarlo con librerías en diferentes lenguajes veríamos que tenemos que ir haciendo todos estos pasos.

Figura 5: Vídeo de despliegue con Remix IDE

Como digo en el vídeo se ve la conexión del entorno Remix IDE con la Blockchain (a través del endpoint RPC de Ganache, en este caso en localhost). Una vez tenemos el IDE conectado, el despliegue es sencillo, ya que será darle a un botón (o un par si contamos la compilación, pero que está pasando a bajo nivel, lo comentaremos):
  • Compilamos el contrato: y se obtiene un bytecode (representación hex para la EVM de Ethereum), obtenemos los Opcodes (como el lenguaje ensamblador) y el ABI (que será nuestra Application Binary Interface, el cual almacena el nombre de las funciones, el tipo de datos que se les pasa, los tipos de datos de variables, nombres, etcétera. Todo esto es fundamental para, posteriormente, cuando el contrato está desplegado poder interactuar con él).
  • Construimos la transacción: En este caso el IDE genera la transacción que constará de:
    • Contrato
    • Chain_ID
    • Gas
    • From (cuenta que despliega el contrato). Si fuera una transacción para enviar fondos de una cuenta a otra tendríamos que meter en la transacción también un To.
    • Nonce
  • Transacción creada: Debemos firmarla con la clave privada.
  • Envío de transacción a la red: Aquí entra en juego el tiempo de mineros, pruebas, etc.
Si todo va bien, contrato desplegado. 

Algunas vulnerabilidades

El objetivo principal de la charla era mostrar qué la seguridad es muy importante en el mundo Web3 y más cuando los SmartContracts están gestionando activos constantemente y una vulnerabilidad puede provocar la pérdida de activos, no solo al dueño del contrato, si no a la comunidad que hay detrás de un proyecto. Algunas de las vulnerabilidades comentadas fueron:
  • Re-Entrancy.
  • DoS (con algún ejemplo particular).
  • Flash_Loans.
  • Integer Overflow.
En algunos casos se exponía un esquema interactivo con el que el asistente podía entender mejor la vulnerabilidad y cómo la podían explotar en contra de nuestros activos. En el siguiente esquema se puede ver un Re-Entrancy, una vulnerabilidad conocida, pero que puede provocar un gran caos en un proyecto en caso de darse.

Figura 6: Ataque de Re-Entrancy

Un ejemplo con casos reales a través de la explotación de un Re-Entrancy se puede ver en la siguiente imagen:

Figura 7: Coste de algunos incidentes de seguridad informática

Por último, se presentaban mitigaciones o buenas prácticas para no crear esas vulnerabilidades a la hora de codificar el contrato. Esta parte era fundamental en la charla ya que se cerraba el ciclo: vulnerabilidades – ejemplo – caso real – mitigación.

SCAMs

Una vez finalizada la parte de las vulnerabilidades, comenzamos con la parte del phishing (principalmente). Se habló del problema de implementar tx.origin en un contrato y el phishing que puede surgir de ahí y el problema del Ice-Phishing, el cual se comparaba con la delegación de permisos de cuentas de proveedores en el mundo Web2. 

Figura 8: Demo de Ice-Phishing

En este blog ya se ha comentado sobre Ice-Phishing por lo que no vamos a entrar en ese detalle, pero si os dejaremos un video sobre una demo que se ha generado y que explica el detalle claro del Ice-Phishing. Vamos a hacer un resumen:
  • En el Ice Phishing, el atacante consigue capturar peticiones de usuarios para intercambiar tokens (o activos).
  • El atacante puede haber suplantado un sitio web de un DEX o simplemente puede hacernos llegar a ese sitio de otra forma.
  • Cuando el usuario quiere usar el DEX para pasar un token de un tipo a otro token, éste delegará una cantidad X (los que quiera intercambiar) de tokens al DEX. El DEX será el encargado de traspasar esos tokens al nuevo valor.
  • Como se puede ver la confianza en el DEX es total por parte del usuario, ¿Cuál es el problema?
  • En el video hay dos partes. En la primera se muestra el proceso legítimo, dónde no hay engaño. Se puede ver que el usuario delega los tokens en el DEX real y éste hace el cambio de un token a otro (pero los activos siguen siendo propiedad del usuario).
  • En la segunda parte, se puede ver que el usuario entra a un sitio web que parece el mismo, pero no lo es (una dapp para ser más puros). En esta dapp, cuando el usuario le indica que quiere delegar una cantidad X de tokens en el supuesto DEX, si nos fijásemos veríamos que la dirección del contrato al que se delega no coincide con el del DEX.
  • Al delegarlo… el atacante obtiene la cantidad X de tokens delegados. Se produce la estafa.
Como contramedida, tal y como ocurre en el phishing en el mundo Web2, hay que fijarse en los detalles. Hay que conocer la dirección de contrato del DEX que solemos utilizar, hay que estar muy seguro a quién se delega los Tokens. Verificándolo las veces que haga falta.

Conclusiones

Es un mundo que está aquí, es presente y, por supuesto, futuro. La Web3 es una realidad y debemos conocerla, entenderla, no tiene una experiencia de usuario aún cómoda, pero seguramente mejore en los próximos años, ya que es una barrera de entrada alta. Debemos entender el paradigma Web3 y el concepto de descentralización (lo que es un nuevo front-end y lo que es el nuevo Back-End). Para los equipos de seguridad que empiecen a enfrentarse a esto, utilizar herramientas SAST y DAST para llevar a cabo auditoría. 

Por supuesto, utilizar Security Guidelines (que existen) a la hora de generar los desarrollos y que los equipos de seguridad encargados de probar la seguridad de los proyectos también las revisen. Cuando se cree un proyecto Web3 hay diseñar el parcheo de vulnerabilidades. Se puede con Arquitecturas de Proxy, lo cual está bastante recomendado para separar lógica de datos.

Figura 9: Docker: SecDevOps 2ª Edición de Fran Ramírez, Elias Grande
y Rafael Troncoso en 0xWord.

El concepto de S-SDLC encajaría muy bien en el desarrollo de SmartContracts, por lo que es posible que veamos pronto este tipo de situaciones (aunque podemos amoldar lo que conocemos de ese mundo al mundo Web3). La formación es fundamental, por lo que formar a los equipos de seguridad a través de retos, entrenamientos y CTFs sobre DeFi como, por ejemplo, con Damn Vulnerable DeFi (aunque hay muchos distintos, lo cual es bueno).

Nosotros por nuestra parte seguiremos aprendiendo, investigando y jugando con la tecnología Web3 y con todo lo que a seguridad se refiere. Esperemos que pronto tengamos más noticias que contaros. Nos vemos en los siguientes artículos, pero tienes muchos más artículos sobre este mundo Web3 aquí:
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
a las

No hay comentarios:

Publicar un comentario