De 'Código Rojo' a 'Mucho ruido y pocas nueces': ¿Se exageró la explotación de NPM?

Un ‘Nothingburger’ Con Una Llamada de Atención

Informes iniciales de un ataque a gran escala a la cadena de suministro de JavaScript Node Package Manager (NPM) desencadenaron un periodo breve pero intenso de pánico dentro de la comunidad de criptomonedas. Durante algunas horas, los pesimistas se aferraron a la advertencia, especulando sobre un robo masivo de fondos de usuarios. En ese momento, el CTO de Ledger, Charles Guillemet, aconsejó a los usuarios de billeteras de software cesar las transacciones en cadena y a los usuarios de billeteras de hardware verificar cada transacción.

Sin embargo, a medida que pasaron las horas, la magnitud del ataque se hizo más clara. Se reveló que el código malicioso estaba altamente dirigido, y el número de aplicaciones afectadas era limitado. Proyectos prominentes como Uniswap, Metamask, OKX Wallet y Aave confirmaron con declaraciones que no fueron afectados.

La falta de daño generalizado transformó rápidamente el pánico inicial en un debate. Algunos usuarios de criptomonedas aliviados comenzaron a cuestionar la gravedad de la advertencia original, ahora viéndola como alarmista e incluso potencialmente como un ataque indirecto a las billeteras de software. Esta perspectiva sugiere que la advertencia, aunque destacaba una vulnerabilidad genuina, pudo haber sido exagerada para promover el uso de billeteras de hardware.

Aunque el daño en términos de criptomonedas robadas ha llevado a algunos a calificar el exploit como un “nothingburger,” algunos expertos en seguridad blockchain insisten en que el incidente debe servir como una llamada de atención para todos los desarrolladores de software. Estos expertos coinciden en que el incidente valida el modelo de seguridad de las billeteras de hardware, pero también advierten que los usuarios de dichas billeteras podrían perder fondos en un ataque similar bajo ciertas circunstancias.

Augusto Teixeira, co-fundador de Cartesi, ilustró este punto, afirmando: “Incluso los usuarios de billeteras de hardware podrían ser afectados por tales ataques. Por ejemplo, varias personas usan sus billeteras de hardware con la ayuda de Metamask, sin verificar los datos en la pantalla del dispositivo. Esto se está volviendo más común a medida que las transacciones se hacen más elaboradas y las personas las firman a ciegas. Verificar es difícil.”

Según Teixeira, las billeteras de hardware carecen de características importantes como agendas de direcciones o integración con ABI’s JSON, lo que permitiría a los usuarios entender mejor lo que están firmando desde la pantalla del dispositivo.

Implicaciones a Nivel de la Industria y Mejores Prácticas

El incidente de NPM ha puesto en tela de juicio las prácticas de seguridad utilizadas por desarrolladores, gestores de paquetes y organizaciones. Algunos en la industria de criptomonedas creen que seguir mejores prácticas, como la revisión por pares y no permitir que los desarrolladores publiquen código en producción sin aprobación, puede minimizar la probabilidad de tal ataque. Además, argumentan que los desarrolladores deben mantener los sistemas actualizados y evitar reutilizar contraseñas.

Shahaf Bar-Geffen, co-fundador y CEO en COTI, cree que gestores de paquetes como NPM deberían dificultar el proceso de inicio de sesión para un atacante potencial. Argumenta que un “Marco de Seguridad para Paquetes Críticos,” potencialmente supervisado por entidades como la OpenJS Foundation, “podría exigir autenticación fuerte (2FA, tokens API con alcance), construcciones reproducibles, y auditorías anuales de terceros para paquetes que superen umbrales altos de descarga.” Bar-Geffen cree que este modelo de verificación escalonado ayudaría a incentivar las mejores prácticas al tiempo que protege la infraestructura crítica.

Para evitar tener que depender de una sola persona (que pueda tener intereses creados) para exponer actividad maliciosa, Carlo Fragni, Arquitecto de Soluciones en Cartesi, alienta a los proyectos a mantenerse atentos a los canales utilizados por investigadores. También aboga por “usar herramientas de análisis de dependencias y realizar la debida diligencia en cada dependencia siempre que se actualice a una nueva versión.”