La producción de software viene inherentemente acompañada de riesgos. Todo el software, especialmente las nuevas versiones y las reescrituras de código de gran tamaño, tienen una mayor probabilidad de producir errores durante la producción y la versión inicial. Para combatir esto, el equipo de ARK ha introducido métodos de prueba modernos, una mayor cobertura de pruebas, un marco de pruebas e2e desarrollado a medida y ha aumentado la disponibilidad de pruebas en nuestra Red de Desarrollo antes de su lanzamiento. A pesar de todo eso, nadie puede captar todos los problemas potenciales. Esta nueva serie de informes servirá como una revelación pública de cualquier vulnerabilidad descubierta y arreglada dentro de la plataforma ARK Blockchain (Core, Desktop Wallet, Mobile Wallet, ARK Pay & Deployer).
Durante nuestra fase de pruebas internas y públicas de la red de desarrollo, se encontraron y se arreglaron MUCHOS errores. Mientras que el equipo de ARK hace pruebas considerables, un par de ojos frescos a menudo pueden discernir problemas que podríamos haber pasado por alto. Es por eso que valoramos los comentarios de la comunidad y ponemos mucho esfuerzo en nuestros programas de recompensas (que hemos actualizado recientemente).
Pero, como ya dijo Edsger W. Dijkstra:
"Las pruebas del programa pueden ser usadas para mostrar la presencia de errores, pero nunca para mostrar su ausencia!"
Tras el exitoso lanzamiento de ARK Core v2 por parte del equipo de ARK y la migración pública de la red por parte de los delegados de la red de ARK, los miembros de la comunidad y los delegados de ARK revelaron a nuestro equipo varias vulnerabilidades de seguridad críticas. Debido a la naturaleza crítica de estas divulgaciones y al impacto que podrían haber tenido en la red, nos gustaría agradecer a los responsables por su arduo trabajo y esfuerzos para reportar estos temas de manera responsable. Las vulnerabilidades de seguridad se revelan a continuación con explicaciones y detalles adicionales sobre los arreglos asociados. Debido al profesionalismo de nuestros investigadores de seguridad de la comunidad, en ningún momento se probó o abusó de nada en la red pública y la integridad de la blockchain de ARK permanece intacta.
Después de las revelaciones, se hizo cada vez más importante que Ark notificará a aquellos que utilizaban la Plataforma de la blockchain de ARK (ARK Forks) de los errores críticos identificados para permitirles mitigar cualquier vulnerabilidad potencial de manera oportuna. Compartir las vulnerabilidades conocidas y los parches asociados beneficia a todas las partes implicadas y mantiene abiertas las líneas de comunicación entre los proyectos, lo que también puede ayudar en otros aspectos del desarrollo (evitando la duplicación de esfuerzos). Es por eso que hemos mejorado nuestros pasos relacionados con nuestro proceso de divulgación de vulnerabilidades de seguridad. Si está ejecutando un proyecto basado en la plataforma ARK, le recomendamos encarecidamente que nombre a un miembro del equipo dedicado para que compruebe el depósito principal y haga un seguimiento de cualquier cambio.
Nuevo proceso de divulgación
Todo el proceso de divulgación de vulnerabilidades de seguridad está siendo estandarizado por nuestra parte. A partir de ahora, este proceso se racionalizará. La información de divulgación pública crítica será publicada después de que dicha vulnerabilidad haya sido arreglada en la red de Ark. También notificaremos a todas las horquillas relacionadas (de las que somos conscientes) de forma automatizada después de que se cierren los parches, de modo que tengan todas las oportunidades de parchear vulnerabilidades críticas de forma oportuna.
Lista de vulnerabilidades de seguridad cerrada
Esta sección enumera las vulnerabilidades de seguridad que fueron identificadas y corregidas desde el lanzamiento de ARK Core v2
- Bloqueo no válido recibido
Causa: La última variableDownloadedBlock no se ha restablecido al descartar bloques no válidos. Esto provocó que los nodes de la red intentaran continuamente descargar nuevos bloques desde una altura incorrecta, deteniendo la red de forma efectiva. Este problema habría permitido que un usuario malintencionado interrumpiera los nodos de la red y la propia red.
Reportado por: delegate fun
Solución: Restablecer el último bloque descargado después de descartar un bloque no válido.
Patch PR: https://github.com/ArkEcosystem/core/pull/1692
- Generación un nuevo Ark utilizando una transacción de múltiples firmas
Causa: En una transacción multi-firma, el gestor de la transacción sólo verificó las firmas y no realizó correctamente las verificaciones de saldo. Esto hizo posible generar nuevos tokens ARK en la red utilizando una transacción de múltiples firmas.
Reportado por: delegate fun
Solución: Realice comprobaciones de saldo de billetera para transacciones con varias firmas.
Patch PR: https://github.com/ArkEcosystem/core/pull/1658
- Segunda repetición de la transacción de firma
Causa: Adjuntar una segunda firma a una transacción anterior enviada desde cualquier billetera que no tenga una segunda frase de contraseña permitiría que la transacción se falsificara infinitamente y se repitiera una y otra vez.
Reportado por: delegate pierce
Solución: Asegúrese de que la billetera del remitente tiene una segunda clave pública y, si no, rechace la transacción.
Patch PR: https://github.com/ArkEcosystem/core/pull/1658
Causa: La lista blanca podría ser pasada por alto por el spoofing de IP debido a la forma en que determinamos la IP de una solicitud. Esto también podría ser usado para llenar la lista de pares con direcciones IP loopback para causar un ataque DoS y prevenir la propagación en bloque.
Reportado por: delegate fun
Solución: Utilice request.info.remoteAddress como lo proporciona Hapi para obtener una IP del par.
Patch PR: https://github.com/ArkEcosystem/core/pull/1695
Lista de vulnerabilidades conocidas y abiertas
Mientras trabajamos continuamente para mejorar y corregir todos los problemas conocidos, algunos requieren soluciones más profundas a nivel conceptual y protocolario y pueden ser cuestiones fundamentales en la naturaleza de los modelos de consenso de prueba de participación y de prueba de participación de los delegados. Estos problemas pueden atribuirse a la confianza inherente depositada en los delegados en una red DPoS o están relacionados con cosas tales como que los usuarios pierdan sus claves de seguridad (palabras en código es mnemotécnico) o simplemente alguien que actúa como falsificador/delegado o como atacante.
Los desafíos actualmente abiertos que nos gustaría arreglar son los siguientes:
Doble forja de un bloque
Muchos de los probadores públicos podrían haber pensado que la doble forja fue mitigada y resuelta durante la fase de prueba, pero este nunca fue el caso. La forja doble parecía estar funcionando más correctamente debido a la forma en que manejamos la propagación de transacciones en las versiones iniciales de Core v2. Todos los nodes tenían pools de transacciones homogéneos y se transmitían a todos los pares. Los bloques dobles forjados tenían el mismo contenido y los mismos IDs. Es por eso que no se detectó como un problema durante las pruebas públicas iniciales.
Dicho esto, en cualquier momento dado un falsificador malicioso podría y todavía puede forjar múltiples bloques distintos y transmitirlos a diferentes pares causando inestabilidad en la red.
Hay un AIP-24: Borrador de Mejoras de Doble Forja en progreso que abordará este tema (https://github.com/ArkEcosystem/AIPs/blob/master/AIPS/aip-24.md), pero requiere una cuidadosa consideración.
Hasta entonces, los delegados de falsificación deben asegurarse de NO ejecutar dos o más servidores con el proceso de falsificación 'on' y la frase de contraseña configurada, tener más nodes de retransmisión delante de su delegado de falsificación, y no ejecutar scripts automáticos para activar a los falsificadores. Hemos visto que los scripts de conmutación por error causan una doble falsificación que detiene la red en el pasado y, hasta que se encuentre una solución, esta práctica corre el riesgo de dañar la red.
<(p>
A partir de ahora, la red detecta la doble falsificación e intenta recuperarse a través de la gestión de la horquilla, pero esto no es óptimo y todavía deja espacio para errores de usuario o de script.
Ataque de repetición de transacción con una segunda passphrase conocida / multisignatura
Causa: Actualmente es posible generar firmas distintas para la misma transacción a partir de la misma clave privada, que puede ser verificada por la misma clave pública. La segunda firma cambia el ID de una operación, por lo que no se considera una duplicación, sino una nueva operación. Esto significa que si su segunda frase de contraseña se pierde o es robada, un atacante puede repetir sus transacciones anteriores simplemente cambiando la segunda firma.
Reportado por: delegate pierce
Solución: Un AIP para abordar esta cuestión está en curso y hemos empezado a evaluar la mejor solución posible para abordar esta cuestión. Esto significa un tenedor duro a un nivel de hito y un guión de mitigación para las transacciones anteriores al hito incluido. Cuando el AIP esté finalizado, lo compartiremos con todos, como siempre. Hasta entonces, mantén tu frase de contraseña a salvo y NO la compartas con nadie (aunque sea la segunda). La utilización de la 2ª firma con un 2º partido como una forma de multi-firma nunca fue el uso previsto de la 2ª firma y, según lo anterior, puede dar lugar a robo o mal uso de los fondos.
Aporte para todos nosotros
Un nuevo producto con una nueva base de código fue lanzado recientemente y a pesar de nuestros mejores esfuerzos para entregar código libre de errores, hubo varios problemas críticos encontrados y también parcheados en el menor tiempo posible. Una vez más, gracias a todos los que ayudaron, especialmente a delegar la diversión por ser los más activos durante esta fase de prueba.
Haremos todo lo posible para continuar mejorando nuestros modelos de pruebas y validación y tomaremos lo que hemos aprendido y lo utilizaremos para mejorar nuestras mejores prácticas. En cuanto a los mantenedores de la red y todos los demás, asegúrese de que su frase de contraseña (palabras de código mnemonic) esté almacenada e impresa de forma segura.
También nos gustaría invitar a todos los investigadores de seguridad y a las partes interesadas a auditar la actual base de código, a tomarse su tiempo y revisar las secciones críticas, especialmente las relacionadas con la validación y el procesamiento de transacciones.
Si te lo perdiste, recientemente actualizamos nuestro programa de recompensas de desarrollo y seguridad para 2019(https://steemit.com/spanish/@valentinas23/programa-de-recompensas-de-desarrollo-y-seguridad-de-ark). Los años anteriores nos han enseñado cómo mejorar el programa y hacerlo más justo para todos los participantes, con niveles revisados para que todos puedan predecir sus ganancias. El programa revisado enfatizará la calidad sobre la cantidad.
También anunciamos la adquisición de los servicios de pruebas de seguridad y penetración de Bugcrowd(https://steemit.com/spanish/@valentinas23/ark-y-bugcrowd-van-de-caceria), la principal plataforma de seguridad del planeta. Los hackers de sombrero blanco altamente cualificados y de confianza de todo el mundo intentarán romper el casco de ARK e intentarán exponer las vulnerabilidades antes de que supongan un riesgo para el ecosistema de ARK. Las pruebas privadas de ARK-Bugcrowd ya están descubriendo y reportando errores de miembros verificados de Bugcrowd. Este programa debería estar abierto al público en general muy pronto, ya que optimizan todo lo que hay entre bastidores.
Con esto concluye la primera versión de la serie The ARK Security Vulnerabilities Disclosure. A través de un mayor enfoque en las pruebas y la validación y con su continua vigilancia en nuestra red de desarrolladores, esperamos minimizar el número de entradas en esta serie en el futuro. Gracias por todo su arduo trabajo y esperamos trabajar juntos para mantener la Red ARK segura y libre de errores en 2019!
¿Quieres saber más sobre ARK? Ingresa en: https://ark.io/
