Cómo solucionarlos – Cointelegraph Magazine

Los exploits de blockchain pueden ser extremadamente costosos; con contratos inteligentes mal diseñados, las apps y puentes descentralizados son atacados una y otra vez.

Por ejemplo, la Ronin Network experimentó una brecha de 625 millones de dólares en marzo de 2022 cuando un hacker fue capaz de robar claves privadas para generar retiros falsos y transfirió cientos de millones. Ese mismo año, en agosto, Nomad Bridge sufrió una brecha de 190 millones de dólares cuando unos piratas informáticos aprovecharon un fallo en el protocolo que les permitió retirar más fondos de los que habían depositado.

Estas vulnerabilidades en el código del contrato inteligente subyacente, junto con el error humano y los lapsus de juicio, crean riesgos significativos para los usuarios de Web3. Pero, ¿cómo pueden los proyectos de criptomonedas tomar medidas proactivas para identificar los problemas antes de que ocurran?

Hay un par de estrategias principales. Los proyectos Web3 suelen contratar a empresas para auditar su código de contrato inteligente y revisar el proyecto para proporcionar un sello de aprobación.

Otro enfoque, que a menudo se utiliza conjuntamente, es establecer un programa de recompensas por fallos que ofrezca incentivos a los hackers benignos para que utilicen sus habilidades para identificar vulnerabilidades antes de que lo hagan los hackers maliciosos.

Ambos enfoques plantean problemas importantes en su forma actual.

La auditoría de Web3 no funciona

Las auditorías, o evaluaciones externas, tienden a surgir en mercados donde el riesgo puede escalar rápidamente y crear un daño sistémico. Ya se trate de una empresa que cotiza en bolsa, de deuda soberana o de un contrato inteligente, una sola vulnerabilidad puede causar estragos.

Pero, lamentablemente, muchas auditorías -incluso cuando las realiza una organización externa- no son creíbles ni eficaces porque los auditores no son verdaderamente independientes. Es decir, sus incentivos pueden estar alineados para satisfacer al cliente en lugar de dar malas noticias.

“Las auditorías de seguridad llevan mucho tiempo, son caras y, en el mejor de los casos, dan como resultado que todo va bien. En el peor, pueden hacer que un proyecto reconsidere todo su diseño, retrasando el lanzamiento y el éxito en el mercado. Los gestores de proyectos DeFi se ven tentados a buscar otra empresa auditora más amable que esconda cualquier preocupación bajo la alfombra y dé el visto bueno a los contratos inteligentes”, explica Keir Finlow-Bates, investigador de blockchain y desarrollador de Solidity.

“He tenido experiencia de primera mano con esta presión de los clientes: argumentar con los desarrolladores y directores de proyecto que su código o arquitectura no está a la altura recibe empujones, incluso cuando las debilidades del sistema son fácilmente evidentes.”

El comportamiento basado en principios es rentable a largo plazo, pero a corto plazo puede resultar perjudicial para los clientes rentables que están ansiosos por comercializar sus nuevos tokens.

“No puedo evitar darme cuenta de que las empresas de auditoría poco rigurosas se hacen rápidamente con una presencia más significativa en el mercado de la auditoría debido a su amplia lista de clientes satisfechos… satisfechos, es decir, hasta que se produce un hackeo”, continúa Finlow-Bates.

Una de las empresas líderes en auditoría Web3, CertiK, proporciona “puntuaciones de confianza” a los proyectos que evalúa. Sin embargo, sus críticos señalan que han dado el visto bueno a proyectos que fracasaron estrepitosamente. Por ejemplo, aunque CertiK se apresuró a compartir el 4 de enero de 2022 que se había producido un tirón de alfombra en el proyecto de cadena inteligente BNB Arbix, “omitieron que habían emitido una auditoría a Arbix 46 días antes”. según Eloisa Marchesoni, especialista en tokenómica, en Medium.

Pero el incidente más notable fue la auditoría de alcance completo de CertiK sobre Terra, que más tarde se derrumbó y trajo a la mitad de la industria criptográfica con ella. La auditoría ha sido retirada desde entonces, ya que han adoptado un enfoque más reflexivo, pero algunos fragmentos permanecen en línea.

Terra-fied

Zhong Shao, cofundador de CertiK, dijo en un comunicado de prensa de 2019:

“CertiK quedó muy impresionado por el diseño inteligente y altamente eficaz de la teoría de la economía de Terra, especialmente por el desacoplamiento adecuado de los controles para la estabilización de la moneda y el crecimiento económico predecible.”

Añadió, “CertiK también encontró la implementación técnica de Terra como una de las de más alta calidad que ha visto, demostrando prácticas de ingeniería extremadamente basadas en principios, dominio de Cosmos SDK, así como documentaciones completas e informativas.”

Esta certificación desempeñó un papel importante en el aumento del reconocimiento internacional de Terra y en la recepción de inversiones. El recientemente detenido Do Kwon, cofundador de Terra, dijo a en ese momento:

“Estamos encantados de recibir un sello formal de aprobación de CertiK, que es conocido dentro de la industria por establecer un listón muy alto para la seguridad y la fiabilidad. Los exhaustivos resultados de la auditoría compartidos por el equipo de economistas e ingenieros experimentados de CertiK nos dan más confianza en nuestro protocolo, y estamos entusiasmados por lanzar rápidamente nuestra primera dApp de pago con socios de eCommerce en las próximas semanas.”

Por su parte, CertiK argumenta que sus auditorías fueron exhaustivas y que el colapso de Terra no se debió a un fallo crítico de seguridad, sino al comportamiento humano. Hugh Brooks, director de operaciones de seguridad de CertiK, explica a Magazine:

“Nuestra auditoría de Terra no arrojó ningún hallazgo que pudiera considerarse crítico o importante porque no se encontraron fallos de seguridad críticos que pudieran llevar a un actor malintencionado a atacar el protocolo. Esto tampoco ocurrió en la saga de incidentes de Terra”.

“Las auditorías y las revisiones de código o las verificaciones formales no pueden evitar las acciones de individuos con tokens de control o de vertido de ballenas, que causaron el primer depeg y las posteriores acciones de pánico.”

Dar un sello de aprobación a algo que luego resultó ser dudoso no se limita a la industria de blockchain y se ha repetido a lo largo de la historia, desde la firma de contabilidad pública Arthur Anderson, una de las cinco principales, que dio el visto bueno a los libros de Enron (destruyendo más tarde parte de las pruebas) hasta la agencia de calificación Moody’s, que pagó 864 millones de dólares por sus dudosas calificaciones optimistas de bonos que alimentaron la burbuja inmobiliaria de 2008-2009 y contribuyeron a la Crisis Financiera Mundial.

Es más, las empresas de auditoría Web3 se enfrentan a presiones similares en un sector mucho más nuevo, de crecimiento más rápido y menos regulado. (La semana pasada, CertiK publicó sus nuevas “puntuaciones de seguridad” para 10.000 proyectos; para más detalles, véase a la derecha).

No se trata de echar por tierra a CertiK, que cuenta con personal cualificado y bienintencionado, sino de señalar que las auditorías de Web3 no tienen en cuenta todos los riesgos para los proyectos y los usuarios, y que el mercado puede necesitar reformas estructurales para alinear los incentivos.

“Las auditorías sólo comprueban la validez de un contrato, pero gran parte del riesgo está en la lógica del diseño del protocolo. Muchos exploits no provienen de contratos rotos, sino que requieren una revisión de la tokenómica, la integración y el red-teaming”, afirma Eric Waisanen, responsable de tokenómica en Phi Labs.

“Aunque las auditorías suelen ser muy útiles, es poco probable que detecten el 100% de los problemas”, afirma Jay Jog, cofundador de Sei Networks. “La responsabilidad principal sigue recayendo en los desarrolladores, que deben emplear buenas prácticas de desarrollo para garantizar una seguridad sólida”.

Stylianos Kampakis, CEO de Tesseract Academy y experto en tokenómica, afirma que los proyectos deberían contratar a varios auditores para garantizar la mejor revisión posible.

“Creo que probablemente hacen un buen trabajo en general, pero he escuchado muchas historias de horror de auditorías que pasaron por alto errores significativos”, dice a Cointelegraph. “Así que no sólo depende de la empresa, sino también de las personas que participan en la auditoría. Por eso yo personalmente nunca confiaría la seguridad de un protocolo a un solo auditor.”

zkSync está de acuerdo en la necesidad de múltiples auditores y cuenta a Magazine que antes de lanzar su EVM compatible con zero knowledge proof rollup Era en mainnet el 24 de marzo, fue probado a fondo en siete auditorías diferentes de Secure3, OpenZeppelin, Halburn y un cuarto auditor aún por anunciar.

Hackers de sombrero blanco y recompensas por errores

Rainer Böhme, profesor de seguridad y privacidad en la Universidad de Innsbruck, escribió que las auditorías básicas “casi nunca son útiles y, en general, la minuciosidad de las auditorías de seguridad debe adaptarse cuidadosamente a la situación”.

En su lugar, los programas de recompensas por fallos pueden ofrecer mejores incentivos. “Los programas de recompensas por fallos ofrecen una forma establecida de recompensar a quienes encuentran fallos… encajarían de forma natural en las criptomonedas, dado que tienen un mecanismo de pago incorporado”, Böhme continúa.

Los hackers de sombrero blanco son aquellos que aprovechan su talento para identificar una vulnerabilidad y colaborar con los proyectos para solucionarla antes de que un hacker malintencionado (“sombrero negro”) pueda explotarla.

Los programas de recompensas por fallos se han convertido en esenciales para descubrir amenazas a la seguridad en toda la web, generalmente comisariados por propietarios de proyectos que desean que programadores con talento examinen y revisen su código en busca de vulnerabilidades. Los proyectos recompensan a los hackers por identificar nuevas vulnerabilidades y por el mantenimiento y la integridad de una red. Históricamente, las correcciones de los lenguajes de contratos inteligentes de código abierto -por ejemplo, Solidity- se han identificado y corregido gracias a los hackers de bug bounty.

“Estas campañas empezaron en los años 90: había una comunidad vibrante en torno al navegador Netscape que trabajaba gratis o por céntimos para arreglar fallos que iban apareciendo poco a poco durante el desarrollo”. escribió Marchesoni.

“Pronto quedó claro que ese trabajo no podía hacerse en los ratos muertos o como pasatiempo. Las empresas se beneficiaron doblemente de las campañas de bug bounty: además de los evidentes problemas de seguridad, también llegó la percepción de su compromiso con la seguridad.”

Los programas de recompensas por fallos han surgido en todo el ecosistema Web3. Por ejemplo, Polygon lanzó un programa de recompensas por fallos de 2 millones de dólares en 2021 para erradicar y eliminar posibles fallos de seguridad en la red auditada. Avalanche Labs gestiona su propio programa de recompensas por fallos, que se puso en marcha en 2021, a través de la plataforma de recompensas por fallos HackenProof.

Sin embargo, existe tensión entre el alcance de las brechas de seguridad que creen haber encontrado y la importancia que los proyectos otorgan al asunto.

Los hackers de sombrero blanco han acusado a varios proyectos de blockchain de gaslighting miembros de la comunidad, así como la retención de compensación bug-bounty para los servicios de sombrero blanco. Aunque no hace falta decirlo, el pago de recompensas por servicios legítimos es esencial para mantener los incentivos.

Un equipo de hackers afirmó recientemente que no fue compensada por sus servicios de bug bounty a la capa de aplicación Tendermint y Avalanche.

En el otro lado de la valla, los proyectos han descubierto que algunos hackers de sombrero blanco son en realidad sombreros negros disfrazados.

Tendermint, Avalanche y más

Tendermint es una herramienta para que los desarrolladores se centren en el desarrollo de aplicaciones de alto nivel sin tener que ocuparse directamente de la comunicación y la criptografía subyacentes. Tendermint Core es el motor que facilita la red P2P a través del consenso proof-of-stake (PoS). La Application BlockChain Interface (ABCI) es la herramienta con la que las blockchains públicas se vinculan al protocolo Tendermint Core.

En 2018, un programa de recompensas por errores para las comunidades Tendermint y Cosmos. El programa se diseñó para recompensar a los miembros de la comunidad por descubrir vulnerabilidades con recompensas basadas en factores como “impacto, riesgo, probabilidad de explotación y calidad del informe.”

El mes pasado, un equipo de investigadores afirmó haber encontrado un importante exploit de seguridad en Tendermint, que provocaba la caída de servicios a través de una API remota – se descubrió una vulnerabilidad en Tendermint de Llamada a Procedimiento Remoto (RPC), que afectaba a más de 70 blockchains. El exploit tendría un grave impacto y podría incluir potencialmente más de 100 vulnerabilidades peer-to-peer y API, ya que las blockchains comparten código similar. Diez blockchains de las 100 primeras del “Security Leaderboard” de CertiK se basan en Tendermint.

Sin embargo, después de pasar por los canales adecuados para reclamar la recompensa, el grupo de hackers dijo que no fue compensado. En su lugar, lo que siguió fue una serie de acontecimientos de ida y vuelta, que algunos afirman que fue un intento de dilación para Tendermint Core, mientras que rápidamente parcheado el exploit sin pagar el cazador de recompensas su cuota.

Este, entre otros que el grupo supuestamente ha documentado, se conoce como un exploit de día cero.

“El ataque específico de denegación de servicio (DoS) de Tendermint es otro vector de ataque de blockchain único, y sus implicaciones aún no están del todo claras, pero evaluaremos esta vulnerabilidad potencial en el futuro, fomentando parches y discutiendo con los clientes actuales que puedan ser vulnerables”, dijo Brooks de CertiK.

Según él, el trabajo de las pruebas de seguridad nunca termina. “Muchos ven las auditorías o las recompensas por errores como algo que se hace una sola vez, pero en realidad las pruebas de seguridad deben ser continuas en Web3, del mismo modo que en otras áreas tradicionales”, afirma.

¿Son siquiera sombreros blancos?

Las recompensas por fallos que se basan en sombreros blancos distan mucho de ser perfectas, dada la facilidad con la que los sombreros negros pueden disfrazarse. Los acuerdos ad hoc para la devolución de fondos son un enfoque especialmente problemático.

“Las recompensas por fallos en el espacio DeFi tienen un grave problema, ya que a lo largo de los años, varios protocolos han permitido a los hackers de sombrero negro convertirse en ‘sombrero blanco’ si devolvían parte o la mayor parte del dinero”, afirma Finlow-Bates.

“Extrae una suma de nueve cifras y puedes acabar con decenas de millones de dólares de beneficio sin ninguna repercusión”.

El hackeo de Mango Markets en octubre de 2022 es un ejemplo perfecto, con un exploit de 116 millones de dólares y sólo 65 millones devueltos y el resto tomado como una llamada “recompensa.” La legalidad de esto es una cuestión abierta, con el hacker responsable acusado por el incidente, que algunos han comparado más con la extorsión que con una legítima “recompensa.”

El puente Wormhole fue pirateado de forma similar por 325 millones de dólares en criptomonedas, con una recompensa de 10 millones ofrecida en un acuerdo al estilo sombrero blanco. Sin embargo, esto no fue lo suficientemente grande como para atraer al hacker a ejecutar el acuerdo.

“Compara esto con los verdaderos hackers de sombrero blanco y los programas de recompensas por fallos, en los que existe un estricto conjunto de reglas, se debe proporcionar documentación completa y el lenguaje legal es amenazador, por lo que no seguir las instrucciones al pie de la letra (incluso inadvertidamente) puede dar lugar a acciones legales”, detalla Finlow-Bates.

Las organizaciones que recurren al apoyo de los sombreros blancos deben ser conscientes de que no todos son igual de altruistas: algunos desdibujan los límites entre las actividades de los sombreros blancos y los de los sombreros negros.

“Tanto las recompensas por fallos como las auditorías son menos rentables que los exploits”, prosigue Waisanen, señalando que atraer a hackers de sombrero blanco de buena fe no es fácil.

¿Adónde vamos ahora?

Las auditorías de seguridad no siempre son útiles y dependen fundamentalmente de su grado de exhaustividad e independencia. Las recompensas por fallos pueden funcionar, pero también puede ocurrir que el sombrero blanco se vuelva codicioso y se quede con los fondos.

¿Son ambas estrategias sólo una forma de externalizar la responsabilidad y evitar la responsabilidad de las buenas prácticas de seguridad? Maurício Magaldi, director de estrategia global de 11:FS, opina que sería mejor que los proyectos de criptomonedas aprendieran a hacer las cosas bien desde el principio.

“Los BUIDLers de Web3 no suelen estar familiarizados con las prácticas de desarrollo de software de nivel empresarial, lo que pone en peligro a muchos de ellos, incluso si cuentan con programas de recompensas por fallos y auditorías de código”, afirma.

“Confiar en la auditoría de código para poner de manifiesto problemas en tu aplicación que pretende gestionar millones en transacciones es una clara externalización de la responsabilidad, y eso no es una práctica empresarial. Lo mismo ocurre con los programas de recompensas por fallos. Si externalizas la seguridad de tu código a partes externas, aunque proporciones suficientes incentivos monetarios, estás cediendo responsabilidad y poder a partes cuyos incentivos podrían estar fuera de tu alcance. Esto es no de lo que trata la descentralización”, dijo Magaldi.

Un enfoque alternativo es seguir el proceso de la fusión de Ethereum.

“Tal vez debido al hackeo de DAO en los primeros días de Ethereum, ahora cada cambio se planifica y ejecuta meticulosamente, lo que da a todo el ecosistema mucha más confianza en la infraestructura. Los desarrolladores de DApps podrían robar una o dos páginas de ese libro para hacer avanzar la industria”, afirma Magaldi.

Cinco lecciones para la ciberseguridad en criptografía

Hagamos balance. He aquí cinco lecciones filosóficas generales que podemos extraer.

En primer lugar, necesitamos más transparencia en torno a los éxitos y fracasos de la ciberseguridad Web3. Desgraciadamente, existe una subcultura oscura que rara vez ve la luz del día, ya que la industria auditora suele operar sin transparencia. Esto puede contrarrestarse hablando -desde un punto de vista constructivo- sobre lo que funciona y lo que no.

Cuando Arthur Anderson no corrigió ni señaló el comportamiento fraudulento de Enron, sufrió un duro golpe en su reputación y en la normativa. Si la comunidad Web3 no puede al menos cumplir esas normas, sus ideales no son sinceros.

En segundo lugar, los proyectos Web3 deben comprometerse a cumplir sus programas de recompensas por fallos si quieren que la comunidad en general obtenga legitimidad en el mundo y llegue a los consumidores a escala. Los programas de recompensas por fallos han sido muy eficaces en los entornos Web1 y Web2 para el software, pero requieren compromisos creíbles por parte de los proyectos para pagar a los hackers de sombrero blanco.

En tercer lugar, necesitamos auténticas colaboraciones entre desarrolladores, investigadores, consultorías e instituciones. Aunque el afán de lucro puede influir en el grado de colaboración de ciertas entidades, tiene que haber un conjunto de principios compartidos que unan a la comunidad Web3 -al menos en torno a la descentralización y la seguridad- y conduzcan a colaboraciones significativas.

Ya hay muchos ejemplos; herramientas como Ethpector son ilustrativas porque muestran cómo los investigadores pueden ayudar a proporcionar no sólo un análisis cuidadoso sino también herramientas prácticas para blockchains.

En cuarto lugar, los reguladores deberían trabajar con los desarrolladores y empresarios, en lugar de hacerlo en su contra o independientemente de ellos.

“Los reguladores deberían proporcionar un conjunto de principios rectores, que tendrían que ser tenidos en cuenta por los desarrolladores de interfaces DeFi. Los reguladores deben pensar en formas de recompensar a los desarrolladores de buenas interfaces y castigar a los diseñadores de interfaces deficientes, que pueden ser objeto de piratería informática y exponer los servicios DeFi subyacentes a costosos ataques”, afirma Agostino Capponi, director del Columbia Center for Digital Finance and Technologies.

Al trabajar en colaboración, los reguladores no tienen que ser expertos en cada tecnología emergente, sino que pueden delegar en la comunidad Web3 y aprovechar sus puntos fuertes, que es crear procesos escalables.

En quinto lugar, y como aspecto más controvertido, los proyectos DeFi deberían trabajar hacia un punto intermedio en el que los usuarios pasen por algún nivel de verificación KYC/AML para garantizar que los actores maliciosos no estén aprovechando la infraestructura Web3 con fines dañinos.

Aunque la comunidad DeFi siempre se ha opuesto a estos requisitos, puede haber un término medio: Toda comunidad requiere cierto grado de estructura, y debería existir un proceso para garantizar que los usuarios inequívocamente maliciosos no están explotando las plataformas DeFi.

La descentralización es valiosa en las finanzas. Como hemos visto una vez más con el colapso del Banco de Silicon Valley, las instituciones centralizadas son vulnerables, y los fracasos crean grandes efectos dominó para la sociedad.

Mi investigación en el Revista de Finanzas Corporativas también destaca cómo se reconoce que DeFi tiene mayores ventajas de seguridad: Tras una conocida filtración de datos en la bolsa centralizada KuCoin, por ejemplo, las transacciones crecieron un 14% más en las bolsas descentralizadas, en relación con las centralizadas. Pero aún queda trabajo por hacer para que DeFi sea accesible.

En última instancia, construir un ecosistema y un mercado prósperos para la ciberseguridad en la comunidad Web3 va a requerir esfuerzos de buena fe por parte de todos los interesados.