Recompenzamos a todos aquellos que dedican tiempo y esfuerzo para mejorar la plataforma de RSK
Reglas y recompensas
Envíe sus hallazgos y gane recompensas
El remitente debe ser la persona que ha descubierto la vulnerabilidad. El envío de informes de vulnerabilidades no puede delegarse.
Aceptamos envíos anónimos, pero en ese caso la recompensa se dona a organizaciones benéficas.
El remitente le concede a RSK el derecho de usar partes o la totalidad del informe enviado, para comunicar la vulnerabilidad al público.
RSK puede citar el nombre del remitente y los puntos obtenidos en publicaciones del blog de RSK y en tablas de posiciones de recompensas en internet.
Si prefiere que no se lo identifique por su nombre real en comunicados de RSK, debe dejarlo en claro y debe proporcionarnos un seudónimo cuando realice el envío.
Los problemas que otros usuarios ya nos han informado o que ya conoce el equipo de RSK no reúnen los requisitos para recibir recompensas.
La divulgación pública de las vulnerabilidades anula el derecho a recibir recompensas por ellas. Si el usuario informa la vulnerabilidad a otros equipos de seguridad (por ejemplo, Ethereum o ETC), pero la comunica a RSK con una demora considerable, RSK podría reducir o cancelar la recompensa.
Puede iniciar o bifurcar una cadena privada para cazar recompensas. Le rogamos que evite atacar a la mainchain y a las redes de prueba de RSK. También le rogamos que evite atacar las mainchains y las redes de prueba de ETH o ETC. Un ataque hará que la vulnerabilidad deje de reunir los requisitos para recibir recompensas.
El equipo de desarrollo de RSK, sus empleados y demás personas que reciben una remuneración de RSK, de manera directa o indirecta, no reúnen los requisitos para recibir recompensas.
Las personas que hayan enviado un cambio en la base de código de RSK no reúnen los requisitos para recibir recompensas por vulnerabilidades originadas o desencadenadas por el cambio enviado.
Los sitios web, la infraestructura y los activos de RSK no forman parte del programa de recompensas.
El programa de recompensas de RSK toma en cuenta múltiples variables para determinar las recompensas.
Las decisiones sobre derecho a las recompensas, puntuaciones y todos los términos relacionados con cada concesión son a entero criterio de RSK Labs.
Ejemplos
El valor de las recompensas que se paguen variará según la gravedad. La gravedad se calcula de acuerdo con el modelo de clasificación de riesgo OWASP basado en impacto y probabilidad.
Los errores desencadenados por una única transacción de bajo costo que bifurca la RSK Blockchain en nodos que aceptan un bloque que contiene la transacción y nodos que rechazan ese bloque se considerarán, por lo general, de riesgo Alto.
Eso se debe a que es muy probable que se utilicen para realizar un ataque, pero el impacto es medio, porque también debe perpetrarse un ataque de gasto doble para robar activos.
Los ataques remotos a un nodo en particular, que roban sus claves privadas con una probabilidad muy baja serán considerados, por lo general, de riesgo Alto.
Eso se debe a que el impacto es alto, pero la probabilidad es media, y el atacante debe sondear muchos nodos hasta hallar la víctima apropiada.
A los ataques por envío de spam a la blockchain o al estado con un costo mucho más bajo que el esperado se los considerará por lo general de riesgo Medio.
A los ataques remotos que revelan información privada de un nodo que no conduce a la pérdida de fondos se los considerará por lo general de riesgo Bajo.
Nuestro programa de recompensas es de extremo a extremo
Desde la solidez de los protocolos (como el modelo de consenso de la blockchain, los protocolos de transferencia y p2p, prueba de trabajo, etc.) hasta la implementación de protocolos. Tanto la seguridad clásica de clientes como la seguridad de primitivas criptográficas también forman parte del programa. Incluimos a continuación detalles del alcance:
La stack de protocolos RSK tiene similitudes con Ethereum, pero difiere de varias maneras. La mayoría de los protocolos, como los de consenso, sincronización de blockchain, trie de estado y EVM, se han rediseñado o modificado. Como actualmente no hay una descripción formal de estos nuevos protocolos, las vulnerabilidades en el diseño de protocolos deberían evaluarse en comparación con la funcionalidad prevista, lo cual podría no ser evidente.
Recomendamos a los investigadores buscar problemas en el diseño de las siguientes áreas:
Bitcoin Bridge (conector bidireccional)
Administración de miembros de la Federación
Algoritmo de ajuste de dificultad de bloques
Incentivos para la minería egoísta
Seguridad de SPV
Incentivos para la minería de bloques tíos
Seguridad de trie de estado
Incentivos económicos incongruentes o no intencionales, y deficiencias de la teoría del juego.
Puntos débiles de seguridad / ataques al algoritmo de prueba de trabajo o al sistema de minería combinada. Un ejemplo concreto podría ser un contrato que consuma muy poco combustible, pero exija mucho esfuerzo computacional, lo cual abre las puertas a ataques de denegación de servicio (DoS).
Si suponemos que los protocolos y el diseño de los algoritmos es perfecto, ¿la implementación de un cliente se ajusta al comportamiento previsto? Los problemas podrían ser:
Validación de bloques, transacciones y mensajes
Ejecución de código de máquina virtual de RSK
Realización de transacciones
Creación de contratos
Llamadas por mensaje
Cálculo y aplicación de combustible y tarifas
Esta categoría se centra en ataques generalizados en toda la red o una parte de ella:
Ataques de 51 % y otro X %.
Ataques por aislamiento.
Ataques de Finney.
Ataques de Sybil.
Ataques de reproducción.
Maleabilidad de mensajes / transacciones.
Denegación de servicio (global).
Ataques a un único cliente de RSK relacionados con la plataforma RSK:
Denegación de servicio / abuso de recursos
Cuenta / sondeo/recopilación de direcciones wallets
Ataques de transmisión / retención
Esta categoría es sobre problemas de seguridad más clásicos:
Desbordamiento / empaquetamiento de tipo de dato, p. ej., desbordamiento de enteros.
Pánicos o errores manejados incorrectamente.
Concurrencia, p. ej., sincronización, estado, carreras.
Problemas relacionados con el uso de bibliotecas externas.
Esta categoría incluye:
Implementación / uso / configuración incorrectas de: Curva elíptica (secp256k1, ECDSA)
Algoritmos de hash (Keccak-256)
Árboles Merkle-Patricia
Administración de claves
Calidad aleatoria de las fuentes
Canales laterales y filtraciones de información
¿Desea conocer más?