Todas las noticias se verifican rigurosamente y son revisadas por expertos en blockchain y profesionales de la industria.
- IOHK, la empresa de desarrollo de Cardano, ha revelado los resultados de la auditoría de seguridad del código de Byron Reboot por Root9b y ha explicado cómo se resolvieron los problemas identificados.
- En total, Root9b ha descubierto 13 vulnerabilidades, con IOHK ya sea emitiendo aclaraciones mitigantes o habiendo hecho ya el arreglo.
En un informe compartido con Crypto News Flash, Input Output Hong Kong (IOHK), la empresa responsable del desarrollo de Cardano, reveló 13 vulnerabilidades en el código de Byron Reboot. Estas fueron descubiertas y arregladas con éxito por Root9b durante las fases 1 y 2 de la auditoría de seguridad del código de Byron Reboot.
Con el fin de aumentar la transparencia y la seguridad en toda la industria, la IOHK también ha decidido publicar su estrategia de mitigación para fomentar una mayor colaboración intersectorial en la identificación y mitigación de las vulnerabilidades comunes. Charles Hoskinson, Director General de la IOHK, subrayó en referencia a la publicación de los resultados de la auditoría que esto es de «importancia crítica» para cumplir los principios de la industria blockchain de un sistema abierto y descentralizado, razón por la cual se publicaron los resultados (traducidos libremente):
Las empresas no deben dar prioridad al secreto y a la rapidez de comercialización por encima de la seguridad, porque de los programas informáticos que produzcamos dependerán enormes sumas de dinero e incluso vidas humanas.
La industria debe abrir su desarrollo de software a las pruebas de terceros y compartir su conocimiento de las vulnerabilidades en beneficio de toda la industria y la confianza de los usuarios. Con esto en mente, hemos decidido encargar una revisión a terceros del Byron Reboot de Cardano y hacer públicas las vulnerabilidades que hemos encontrado y las correcciones que hemos aplicado.
Root9b encuentra 13 vulnerabilidades en el código del Byron Reboot
En la declaración, compartida con Crypto News Flash, sobre la auditoría de seguridad del código de Byron Reboot por Root9b, IOHK ha comentado cada vulnerabilidad encontrada y ha descrito cómo se ha solucionado el error o ha emitido una aclaración mitigadora. Root9b ya ha reconocido todos los cambios como resueltos.
- Generación de claves inseguras de Génesis: Root9b ha descubierto que la generación de la clave de Génesis tenía una vulnerabilidad. IOHK ha aclarado que el código en cuestión sólo estaba destinado a fines de prueba y garantía de calidad y no para la red principal, y ha hecho un cambio en el código para la generación de claves seguras.
- Práctica de código en relación con el ReadFile: Una vulnerabilidad en relación con el ReadFile fue detectada por Root9b y también fue corregida por los cambios.
- Práctica de código y uso potencial de recursos relacionados con Async Read
- Posible utilización de los recursos / Denegación de servicio (DoS)
- Potencial de incompletitud del protocolo – conjunto de nodos estáticos: El IOHK ha dejado claro que el código era sólo para fines de prueba.
- Uso primitivo de Mock Crypto: IOHK ha confirmado que las implementaciones simuladas no están destinadas a ser usadas en producción y que las implementaciones reales son inminentes.
- Vulnerabilidades relacionadas con la CSP en el Daedalus de aplicaciones Electron: Root9b ha identificado presuntas medidas de seguridad débiles relacionadas con la Política de Seguridad de Contenidos (CSP). Según la IOHK, este es un requisito válido hasta que el Chrome WASM pueda funcionar sin él. Dado que no se trata de una vulnerabilidad, R9B acepta la aclaración.
- La función de hash de Blake fue ejecutada sólo una vez al aplicar una contraseña de salida: IOHK confirma que la conexión del front-end del Daedalus con el back-end de la Cartera Cardano depende de TLS para la seguridad de la contraseña durante la transferencia y planea descontinuar el hash de Blake.
- Aleatorización de direcciones: IOHK aclaró que la aleatorización de direcciones se utiliza para evitar conflictos entre puertos, por lo que la raíz 9b también aceptó esta aclaración.
- Posibles problemas futuros relacionados con el URI (Identificador Uniforme de Recursos) de pago: La IOHK tiene previsto abordar esta posible área problemática para el código.
- Vulnerabilidad de la denegación de servicio teórica (DoS): El problema identificado por Root9b se resuelve completamente con la implementación del líder de la ranura privada por Ouroborous Praos (Shelley).
- Proceso de actualización: Resolución mediante una actualización en abril de 2020.
- IOHK monitoreando la carga en el frontend de la web: IOHK ha eliminado la interfaz y ha retirado el fragmento de código.
¡Síguenos en Facebook y Twitter y no te pierdas ninguna noticia! ¿le gusta nuestro índice de precios?
