Incidentes Asociados
Las consideraciones de seguridad anulan todas las demás consideraciones en el software en general y específicamente en blockchain. Si la seguridad falla, nada más importa. Blockchain demuestra que las transacciones descentralizadas y sin confianza funcionan, pero aún quedan muchas vulnerabilidades de seguridad de blockchain.
Las vulnerabilidades de seguridad existen a nivel de diseño y arquitectura, en la etapa de codificación y en la fase operativa. Y en caso de que te lo preguntes, sí, la cadena de bloques se puede piratear.
Vulnerabilidades de seguridad de blockchain: de aquí a la eternidad
Los diamantes son para siempre, y los contratos inteligentes viven mientras se siga utilizando la cadena de bloques en la que se implementan. En consecuencia, todos los errores y vulnerabilidades de seguridad de blockchain también viven mientras dure el contrato.
Por lo general, cada cadena de bloques proporciona su propio lenguaje de programación para implementar contratos inteligentes. Miremos más de cerca.
Idiomas de contratos inteligentes
Los entornos de blockchain incluyen sus propios lenguajes para desarrollar contratos inteligentes.
La plataforma Ethereum, por ejemplo, incluye el lenguaje Solidity para escribir contratos inteligentes. Los creadores diseñaron Solidity para que fuera un lenguaje completo de Turing.
Un lenguaje completo de Turing esencialmente permite al programador implementar cualquier cosa que el sistema subyacente sea capaz de hacer. En consecuencia, esto brinda a los programadores habilidades como implementar bucles en el código, lo que potencialmente puede causar vulnerabilidades de seguridad en la cadena de bloques.
Completitud de Turing
Los lenguajes completos de Turing contienen complejidad por naturaleza, y la complejidad invita a errores y vulnerabilidades.
La red Bitcoin también tiene un lenguaje de programación al que llama Script. El script no está completo a propósito para mejorar la seguridad.
Cuantas menos opciones se le den a un programador, es menos probable que las vulnerabilidades de seguridad de la cadena de bloques ingresen al sistema.
Para minimizar el riesgo de liberar código defectuoso, los programadores deben comprender las trampas comunes y los antipatrones inherentes a la programación de contratos inteligentes. (Los antipatrones representan malas prácticas de programación).
El truco de DAO: el problema de la reentrada
El problema de reingreso probablemente ocupe el lugar más alto entre los programadores de vulnerabilidades de seguridad de blockchain codificados en contratos inteligentes. El reingreso agota una cuenta a través de múltiples gastos para la misma transacción. El caso de uso de procesamiento de reembolsos se presta a este exploit, pero esta falla afecta a cualquier tipo de transacción si no se aborda en la etapa de diseño y codificación.
En uno de los ataques de criptomonedas más infames hasta la fecha, los piratas informáticos de DAO explotaron la reentrada. Ningún líder organizacional dictó cómo administrar la DAO (u Organización Autónoma Descentralizada), y la DAO propuso empoderar a los usuarios con la capacidad de votar sobre proyectos en los que invertir.
Recaudó más de $ 150 millones en fondos en su primer mes. El 17 de junio de 2016, los piratas informáticos extrajeron $ 50 millones de la organización a través de la falla de reingreso. La bifurcación dura de Ethereum Classic (ETC) a Ethereum (ETH) resultó en un esfuerzo por resolver los problemas que creó este truco.
Antipatrón vulnerable a la reentrada
Una lógica de reentrada vulnerable para el código se ve así:
función para procesar un pago () {
(1) verificar la validez de la transacción, el destinatario y el saldo de la cuenta;
(2) procesar la transacción;
(3) actualizar el estado del sistema para mostrar que la transacción ha sido procesada;
}
A primera vista, la lógica parece correcta y completa, pero la falla reside en el orden de hacer el paso 2 antes del paso 3.
Mientras la primera llamada a la función continúa procesando el paso 2, otra llamada para la misma transacción puede ingresar a la función. Dado que la información de estado permanece en su estado inicial y aún no se ha procesado en el paso 3, la segunda llamada se verifica como una transacción válida para procesar.
En consecuencia, el sistema gasta moneda para la misma obligación por segunda vez. Los piratas informáticos apresuran múltiples transacciones a la función antes de que el estado se establezca correctamente.
Cura para la reentrada
Este cambio en el algoritmo corrige el problema anterior:
función para procesar un pago () {
(1) verificar la validez de la transacción, el destinatario y el saldo de la cuenta;
(2) actualizar el estado del sistema para mostrar que la transacción ha sido procesada;
(3) procesar la transacción;
}
El código debe tener en cuenta todo el manejo de excepciones necesario y también debe tener en cuenta todas las dependencias lógicas.
Desbordamiento
El desbordamiento es otra falla de seguridad común que los programadores deben tener en cuenta.
Algunos lenguajes de programación proporcionan escritura fuerte y otros proporcionan escritura débil. Los lenguajes fuertemente tipados se niegan a permitir que los programadores asignen cadenas de datos a una variable numérica, por ejemplo, y los lenguajes débilmente tipeados permiten tales acciones.
Los lenguajes fuertemente tipados imponen restricciones de rango. Si una matriz tiene diez elementos, los programadores no pueden intentar acceder al undécimo elemento. Los lenguajes escritos débilmente permiten tal comportamiento, pero el resultado se bloquea. Si el valor máximo permitido que contiene una variable es 99, y le asigna un valor de 100, observe cómo se bloquea cuando la ejecuta.
En consecuencia, el desbordamiento es un exploit que utilizan los piratas informáticos. si un