www.sti-innsbruck.at Ciberseguridad en Blockchain y Smart Contracts: Explorando los Desafíos y Soluciones José Manuel Ortega @jmortegac

About me 2 http://jmortega.github.io https://josemanuelortegablog.com/ • Security researcher & Python developer • Master Big Data & Analytics • Master CiberSeguridad • DevSecOps, Ethical Hacking, OSINT, Web Crawling • Cloud Computing, Blockchain

Agenda • Fundamentos de Blockchain y Smart Contracts • Desafíos de Seguridad en Blockchain • Seguridad en Smart Contracts • Auditorías y Pruebas de Seguridad en smart contracts 3

Fundamentos de Blockchain y Smart Contracts 4

Desafíos de Seguridad en Blockchain 5 Blockchain Pública Blockchain Privada Un blockchain público no tiene permisos Un Blockchain privado es una cadena de bloques permitida. Cualquiera puede unirse a la red y leer, escribir o participar dentro del blockchain. Los blockchains privados funcionan basados en controles de acceso que restringen a las personas que pueden participar en la red. Un blockchain público está descentralizado y no tiene una sola entidad que controle la red. Hay una o más entidades que controlan la red y esto lleva a depender de terceros para realizar transacciones. Los datos en un blockchain público son seguros ya que no es posible modificar o alterar los datos una vez que han sido validados en el blockchain. En un blockchain privado, sólo las entidades que participan en una transacción tendrán conocimiento de ella, mientras que las demás no podrán acceder a ella. Bitcoin y Ethereum son ejemplos bien conocidos de un blockchain público. Hyperledger Fabric de Linux Foundation es un ejemplo perfecto de un blockchain privado.

Desafíos de Seguridad en Blockchain • Ataques de phishing • Ataques de enrutamiento • Ataques de Sybil • Ataques del 51% 6

Desafíos de Seguridad en Blockchain • Ataques de phishing • Sitios web falsos de intercambios y billeteras • Por correo electrónico • Mensajes de redes sociales y grupos de chat • Extensiones de navegador maliciosas 7

Desafíos de Seguridad en Blockchain • Ataques de enrutamiento • Ataque de doble gasto • Ataque de reorganización de la cadena (chain reorg) • Ataque de partición de red • Ataque de eclipse • Ataque Sybil 8

Desafíos de Seguridad en Blockchain • Ataques de Sybil 9

Desafíos de Seguridad en Blockchain 10

Desafíos de Seguridad en Blockchain • Ataques del 51% • Revertir sus propias transacciones para que las monedas o tokens puedan ser gastadas dos veces. • Impedir la validación de nuevas transacciones. • Cambiar el orden en el que se procesan nuevas transacciones. • Bloquear a los mineros de generar nuevas monedas o tokens. 11

Desafíos de Seguridad en Blockchain 12

Desafíos de Seguridad en Blockchain 13 ● El riesgo de sufrir un ataque del 51% en una blockchain basada en el algoritmo de Prueba de Trabajo (Proof of Work, PoW) puede depender de varios factores: ● Distribución del hashrate ● Capitalización de mercado ● Costo del hardware y electricidad ● Incentivos económicos

Desafíos de Seguridad en Blockchain • Denial of Service(DoS) • Inundar de la red con transacciones • Hacer inaccesible los recursos en un smart contract 14

Desafíos de Seguridad en Blockchain • Ataques de maleabilidad de transacciones: los hackers intentan engañar al usuario para que pague dos veces por algo, generalmente cambiando la identificación (ID) de la transacción. 15

Seguridad en Smart Contracts • Programa que se ejecuta sobre la blockchain y permite realizar diferentes tareas. • Son fragmentos de código que permiten almacenar datos y funciones. • Los smart contracts son contratos alojados en una cadena de bloques que se ejecutan cuando se cumplen sus condiciones. 16

Solidity • Lenguaje de programación más utilizado para programar smart contracts • Creado para estar adaptado a la Ethereum Virtual Machine(Máquina de estados o de Turing) • Es un lenguaje orientado a objetos • Lenguaje tipado estáticamente • Soporta herencia y herencia múltiple • Posibilidad de incorporar librerías 17

Solidity 18

Seguridad en Smart Contracts • Pruebas exhaustivas • Código simple y modular • Reutilización de código • Estándares y buenas prácticas • Uso de herramientas de análisis estático y dinámico • Manejo de excepciones y errores 19

Seguridad en Smart Contracts 20

Seguridad en Smart Contracts 21

Seguridad en Smart Contracts 22 pragma solidity ^0.4.0; // THIS CONTRACT CONTAINS A BUG - DO NOT USE contract Fund { /// Mapping of ether shares of the contract. mapping(address => uint) shares; /// Withdraw your share. function withdraw() public { if (msg.sender.send(shares[msg.sender])) shares[msg.sender] = 0; } }

Seguridad en Smart Contracts 23 pragma solidity ^0.4.0; // THIS CONTRACT CONTAINS A BUG - DO NOT USE contract Fund { /// Mapping of ether shares of the contract. mapping(address => uint) shares; /// Withdraw your share. function withdraw() public { if (msg.sender.call.value(shares[msg.sender])()) shares[msg.sender] = 0; } }

Seguridad en Smart Contracts 24 pragma solidity ^0.4.11; contract Fund { /// Mapping of ether shares of the contract. mapping(address => uint) shares; /// Withdraw your share. function withdraw() public { var share = shares[msg.sender]; shares[msg.sender] = 0; msg.sender.transfer(share); } } SOLUCIÓN

Seguridad en Smart Contracts 25 contract Victim { mapping (address => uint) public balances; function deposit() public payable { balances[msg.sender] += msg.value; } function withdraw() public { uint bal = balances[msg.sender]; require(bal > 0); (bool sent, ) = msg.sender.call{value: bal}(""); require(sent, "Failed to send Ether"); balances[msg.sender] = 0; }

Seguridad en Smart Contracts 26 function transfer(address to, uint amount) external { if (balances[msg.sender] >= amount) { balances[to] += amount; balances[msg.sender] -= amount; } } function withdraw() external { uint256 amount = balances[msg.sender]; require(msg.sender.call.value(amount)()); balances[msg.sender] = 0; }

Seguridad en Smart Contracts 27 contract Attack { Victim public victim; constructor(address _victim) { victim = Victim(_victim); } fallback() external payable { if (address(victim).balance >= 1 ether){ victim.withdraw(1 ether); } } function attack() external payable { require(msg.value >= 1 ether); victim.deposit{value: 1 ether}(); victim.withdraw(1 ether); } }

Seguridad en Smart Contracts 28 • Prevenir ataques de reentrada • Uso de las funciones send() y transfer() en lugar de call() • El método más fiable para protegerse contra ataques de reentrada es utilizar el patrón checks-effects-interactions. Este patrón define el orden en el que debes estructurar tus funciones. function withdraw() external { uint256 amount = balances[msg.sender]; balances[msg.sender] = 0; require(msg.sender.call.value(amount)()); }

Seguridad en Smart Contracts 29 • Prevenir ataques de reentrada • Uso de funciones mutex function transfer(address to, uint amount) external { require(!lock); lock = true; if (balances[msg.sender] >= amount) { balances[to] += amount; balances[msg.sender] -= amount; } lock = false; } function withdraw() external { require(!lock); lock = true; uint256 amount = balances[msg.sender]; require(msg.sender.call.value(amount)()); balances[msg.sender] = 0; lock = false; }

Seguridad en Smart Contracts 30 • Prevenir ataques de reentrada • Uso de OpenZeppelin ReentrancyGuard contract ReEntrancyGuard { bool internal locked; modifier noReentrant() { require(!locked, "No re-entrancy"); locked = true; _; locked = false; } }

Auditorías y Pruebas de Seguridad en smart contracts • Slither https://github.com/crytic/slither • Securify https://github.com/eth-sri/securify2 • MythX https://mythx.io/ • Truffle Security https://trufflesecurity.com • Consensys Diligence https://consensys.io/diligence • Quantstamp https://quantstamp.com 31

Auditorías y Pruebas de Seguridad en smart contracts • Slither • https://github.com/crytic/slither • https://pypi.org/project/slither-analyzer 32 ● Análisis de vulnerabilidades: Slither utiliza un conjunto de reglas predefinidas para buscar posibles vulnerabilidades en el código. Puede detectar problemas como el desbordamiento de enteros, condiciones de carrera, problemas de acceso a la información y muchas otras vulnerabilidades comunes. ● Identificación de debilidades: Además de buscar vulnerabilidades específicas, también puede identificar debilidades generales en el código, como redundancia, ineficiencia o malas prácticas de programación. Esto nos ayuda a mejorar la calidad y la eficiencia de los smart contracts. ● Integración con herramientas de desarrollo: Slither se puede integrar fácilmente en el flujo de trabajo de desarrollo de smart contracts. Puede ser utilizado desde la línea de comandos, como una biblioteca en otro programa o incluirse en nuestro pipeline de desarrollo. ● Informes detallados: Slither proporciona informes detallados sobre las vulnerabilidades y debilidades encontradas en el código. Estos informes incluyen descripciones de los problemas, ubicaciones exactas en el código fuente y recomendaciones para corregirlos. Esto facilita a los desarrolladores la tarea de corregir los problemas identificados.

Auditorías y Pruebas de Seguridad en smart contracts • Slither • https://github.com/crytic/slither • https://pypi.org/project/slither-analyzer • 33

Auditorías y Pruebas de Seguridad en smart contracts 34

Auditorías y Pruebas de Seguridad en smart contracts 35

Auditorías y Pruebas de Seguridad en smart contracts 36

Auditorías y Pruebas de Seguridad en smart contracts • Solhint • https://www.npmjs.com/package/solhint 37 ● Variables que no se utilizan. ● Funciones que no se utilizan. ● Contratos que no se utilizan. ● Uso inadecuado de las funciones. ● Vulnerabilidades conocidas en el código. ● Malas prácticas de seguridad.

Auditorías y Pruebas de Seguridad en smart contracts 38 https://protofire.github.io/solhint/docs/rules.html#security-rules

Auditorías y Pruebas de Seguridad en smart contracts 39 https://remix.ethereum.org

Auditorías y Pruebas de Seguridad en smart contracts 40 https://remix-ide.readthedocs.io/en/latest/static_analysis.html

Auditorías y Pruebas de Seguridad en smart contracts 41 1. Librería de Contratos Inteligentes: OpenZeppelin proporciona una serie de contratos inteligentes estándar que cubren diversas funcionalidades comunes, como la gestión de tokens (ERC-20, ERC-721, etc.), la autenticación de usuarios, la gestión de permisos y la gestión de fondos. Estos contratos están diseñados para ser seguros y eficientes. 2. Utilidades de Seguridad: OpenZeppelin incluye herramientas y prácticas recomendadas para mejorar la seguridad de los contratos inteligentes. Esto incluye patrones de diseño seguros, auditorías de código y buenas prácticas para evitar vulnerabilidades comunes en contratos inteligentes. 3. Auditorías de Seguridad: OpenZeppelin ha sido auditado por empresas de seguridad de renombre y se considera una base segura para el desarrollo de contratos inteligentes. Estas auditorías ayudan a identificar y mitigar posibles vulnerabilidades en el código. 4. Actualizaciones y Mantenimiento Continuo: OpenZeppelin se mantiene activamente y se actualiza regularmente para adaptarse a las cambiantes condiciones de seguridad y tecnología en el espacio de contratos inteligentes. 5. Documentación y Comunidad: OpenZeppelin ofrece documentación detallada y una comunidad activa de desarrolladores que pueden ayudar con preguntas y problemas relacionados con el uso de la biblioteca. 6. Frameworks y Herramientas de Desarrollo: Además de la biblioteca de contratos inteligentes, OpenZeppelin proporciona herramientas y marcos de desarrollo que facilitan la creación, prueba y despliegue de contratos inteligentes.

Auditorías y Pruebas de Seguridad en smart contracts 42 ● SC01:2023 - Reentrancy Attacks ● SC02:2023 - Integer Overflow and Underflow ● SC03:2023 - Timestamp Dependence ● SC04:2023 - Access Control Vulnerabilities ● SC05:2023 - Front-running Attacks ● SC06:2023 - Denial of Service (DoS) Attacks ● SC07:2023 - Logic Errors ● SC08:2023 - Insecure Randomness ● SC09:2023 - Gas Limit Vulnerabilities ● SC10:2023 - Unchecked External Calls

Auditorías y Pruebas de Seguridad en smart contracts 43 SC05:2023 - Front-running Attacks

Auditorías y Pruebas de Seguridad en smart contracts 44 SC05:2023 - Front-running Attacks

Auditorías y Pruebas de Seguridad en smart contracts 45 SC05:2023 - Front-running Attacks

Auditorías y Pruebas de Seguridad en smart contracts 46 https://libsubmarine.org

Conclusiones 47 ● Usar estándares de facto de código abierto y aceptados por la comunidad para los contratos de biblioteca, tales como los contratos de Open Zeppelin. ● Utilizar los patrones recomendados y las pautas de mejores prácticas, como los que proporciona Consensys. ● https://consensys.github.io/smart-contract-best-practi ces