$30 off During Our Annual Pro Sale. View Details »

Ciberseguridad en Blockchain y Smart Contracts:...

jmortegac
October 29, 2023

Ciberseguridad en Blockchain y Smart Contracts: Explorando los desafíos y soluciones

En la actualidad, la tecnología blockchain y los smart contracts están revolucionando la forma en que interactuamos con la información y realizamos transacciones. Sin embargo, esta innovación no está exenta de desafíos en cuanto a la ciberseguridad se refiere. En esta charla, exploraremos los desafíos desde el punto de vista de la ciberseguridad en blockchain y smart contracts, así como las soluciones y enfoques para mitigar los riesgos asociados. A medida que continuamos adoptando estas tecnologías disruptivas, es fundamental comprender y abordar adecuadamente los aspectos de seguridad para minimizar los posibles riesgos. Entre los puntos a tratar podemos destacar:
1. Fundamentos de Blockchain y Smart Contracts 2. Desafíos de Seguridad en Blockchain 3. Seguridad en Smart Contracts 4. Auditorías y Pruebas de Seguridad en smart contracts

jmortegac

October 29, 2023
Tweet

More Decks by jmortegac

Other Decks in Technology

Transcript

  1. 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
  2. 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
  3. 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.
  4. Desafíos de Seguridad en Blockchain • Ataques de phishing •

    Ataques de enrutamiento • Ataques de Sybil • Ataques del 51% 6
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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; } }
  15. 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; } }
  16. 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
  17. 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; }
  18. 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; }
  19. 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); } }
  20. 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)()); }
  21. 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; }
  22. 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; } }
  23. 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
  24. 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.
  25. Auditorías y Pruebas de Seguridad en smart contracts • Slither

    • https://github.com/crytic/slither • https://pypi.org/project/slither-analyzer • 33
  26. 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.
  27. 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.
  28. 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
  29. 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