Esta publicación analiza el ataque a Ledger como un ejemplo de cómo un phising de lanza condujo a un ataque a la cadena de suministro de software (SSC) contra la herramienta de kit de conexión de software que utilizaban las billeteras de hardware de la compañía, lo que permitió al actor drenar dinero por valor de al menos $600,000.
Este ataque se produjo al final de un año plagado de incidentes en la cadena de suministro. En este post analizamos el ataque, su impacto, cómo se manejó y qué lecciones se podrían extraer.
Ledger y sus usuarios de billeteras de hardware son objetivos obvios para los ciberdelincuentes. Los usuarios de Wallet atacaban a los usuarios de Ledger mediante intentos de phising en las interfaces de las aplicaciones criptográficas, y los delincuentes necesitan conocer las coordenadas de los usuarios para impulsar las campañas de phising. Libro mayor tenía un violación de datos para julio de 2023 además de ser parte del Robo de datos de septiembre de 2020 en su e-commerce Shopify, un incidente de gran impacto. El cargo "Actualización: Esfuerzos para proteger sus datos y procesar a los spammers”muestra cuán profundas fueron estas violaciones.
Ledger necesita tomarse en serio la seguridad (es una parte clave de su negocio), con un laboratorio de investigación interno (torre principal) manejo certificación de seguridad del dispositivo recompensa de errores programa, boletines de seguridad y modelado de amenazas. Hasta ahora, todo bien …
Cómo se hizo el ataque
Ledger detectó un exploit usando Ledger Kit de conexión de DApps el jueves 14 de diciembre de 2023. Este exploit inyectó código malicioso dentro de aplicaciones descentralizadas (DApps) basadas en Ethereum que utilizaban Ledger Connect Kit, engañando a los usuarios para que firmaran transacciones que agotan sus billeteras.
El exploit se detectó rápidamente y poco después se implementó una solución. Mientras tanto, un pequeño volumen de usuarios cayó en el ataque y firmó transacciones que vaciaron sus billeteras.
El ataque comenzó cuando un ex empleado de Ledger fue víctima de un ataque de phishing que obtuvo acceso a su cuenta NPM a través del token de sesión. Los atacantes publicaron versiones maliciosas del @ledgerhq/kit-conectar (1.1.5, 1.1.6 y 1.1.7, ahora retirados). Los atacantes podrían ejecutar código arbitrario con el mismo nivel de permisos que la aplicación de billetera: los atacantes pueden drenar inmediatamente los fondos de los usuarios sin interacción, distribuir numerosos enlaces de phishing para engañar a los usuarios o explotar el pánico de los usuarios convenciéndolos de transferir activos a una nueva dirección. , lo que resulta en pérdida de activos debido a la descarga de una billetera falsa.
Las interfaces de billetera (dApps) generalmente usaban el conectar-kit-cargador paquete de Ledger para cargar el kit Connect en tiempo de ejecución desde una CDN de JavaScript (jsDelivr). Desafortunadamente, la URL https://cdn.jsdelivr.net/npm/@ledgerhq/connect-kit@1 no estaba fijando la versión exacta (1.1.4 en ese momento), por lo que cuando se cargaron las versiones maliciosas, la CDN las entregó (y las almacenó en caché). Y no se utilizó ninguna suma de verificación para garantizar que el recurso descargado de la CDN fuera realmente el esperado (que debería usarse al distribuir código desde una CDN). Este esquema basado en suma de verificación se denomina Integridad de recursos (SRI).
El código inyectado probablemente manipuló los datos de las transacciones, engañando a los usuarios para que confirmaran los pagos manipulados. Por ejemplo, un usuario que aprueba un pago simbólico para habilitar la funcionalidad de una aplicación puede haber visto en su lugar una aprobación para un pago a la dirección del hacker. No importa cuán segura sea la billetera de hardware, el dinero se agotó.
Descubrimiento e investigación
Diferentes usuarios comenzaron a publicar mensajes en X (también conocido como Twitter) de que la interfaz de Zapper "fue secuestrada". El crédito es para Mathew Lilley, el CTO del criptotrader Sushi, quien advirtió por primera vez en un Twitter poste que un "conector web3 de uso común" se ha visto comprometido. Más tarde señaló LedgerHQ/kit de conexión como la biblioteca comprometida, y dio una primera evaluación, un poco brusca:
¿Qué ha pasado?
— Soy Software 🦇🔊 (@MatthewLilley) 14 de diciembre de 2023
En breve, @Libro mayor cometió una cadena de terribles errores.
1. Están cargando JS desde una CDN.
2. No son JS cargados con bloqueo de versión.
3. Tenían su CDN comprometida.
Evitaría usar CUALQUIER dApp hasta que sus equipos confirmen que han mitigado el ataque. https://t.co/a3brXNQSx9
El usuario 0xViva abrió un ticket en el repositorio del proyecto GitHub: [URGENTE] Este repositorio utiliza una versión maliciosa del paquete npm @ledgerhq/connect-kit, 1.1.7.
El 15 de diciembre de 2023, el formulario de seguridad blockchain SlowMost publicó un publicación de análisis dando todos los detalles de las versiones maliciosas.
La billetera de hardware de Ledger no se vio comprometida, solo el kit Ledger Connect. Sin embargo, dado que muchas aplicaciones utilizan esa biblioteca, como SushiSwap, Zapper, MetalSwap, Harvest Finance, Revoke.cash, etc., el alcance del impacto fue significativo. De acuerdo a bittrace.io, algunas víctimas, presas del pánico, intentaron transferir activos a una nueva dirección, ¡pero descargaron una aplicación de billetera falsa!
El mismo día, Jameson Lopp con precisión tuiteó sobre las fallas que permitieron que el ataque tuviera éxito:
Parece que el incidente de seguridad de hoy fue la culminación de 3 fallas distintas en Ledger:
- Jameson Lopp (@lopp) 14 de diciembre de 2023
1. Cargar código a ciegas sin fijar una versión específica ni una suma de comprobación.
2. No aplicar "reglas de 2 personas" en torno a la revisión e implementación del código.
3. No revocar el acceso a ex empleados.
Cómo se manejó el incidente
El director general de Ledger, Pascal Gauthier, publicó el mismo día del ataque un carta de divulgación dando más detalles sobre el incidente, lo cual es definitivamente bueno: esconder la cabeza en la arena como un avestruz es la peor manera de manejar cualquier incidente de ciberseguridad.
La estructura de la carta es interesante: rápidamente reconoció la existencia de versiones maliciosas de la biblioteca que consumen dinero, lo cual es bueno (negar la realidad es una tontería):
“Hoy experimentamos un exploit en Ledger Connect Kit, una biblioteca de Javascript que implementa un botón que permite a los usuarios conectar su dispositivo Ledger a DApps (sitios web conectados a billetera) de terceros.
Este exploit fue el resultado de que un ex empleado fuera víctima de un ataque de phishing, que permitió a un mal actor cargar un archivo malicioso en NPMJS de Ledger (un administrador de paquetes para código Javascript compartido entre aplicaciones).
Trabajamos rápidamente, junto con nuestro socio WalletConnect, para abordar el exploit, actualizando el NPMJS para eliminar y desactivar el código malicioso dentro de los 40 minutos posteriores al descubrimiento. Este es un buen ejemplo de cómo la industria trabaja en conjunto rápidamente para abordar los desafíos de seguridad”.
¿Qué? ¿A un ex empleado con derechos de publicación no se le revocaron sus credenciales en el NPM?
El CEO siguió enumerando los controles de seguridad existentes, pero insinuando que algo andaba débil con el acceso al NPM:
“Ahora me gustaría explicar por qué sucedió esto, cómo mejoraremos nuestras prácticas de seguridad para mitigar este riesgo específico en el futuro y compartir nuestra recomendación con la industria para que podamos ser más fuertes juntos.
La función standard En Ledger, la práctica es que ninguna persona puede implementar código sin la revisión de varias partes. Contamos con estrictos controles de acceso, revisiones internas y código multifirma en la mayor parte de nuestro desarrollo. Esto ocurre en el 99 % de nuestros sistemas internos. A cualquier empleado que deje la empresa se le revoca el acceso a todos los sistemas Ledger.
Este fue un desafortunado incidente aislado. Es un recordatorio de que la seguridad no es estática y que Ledger debe mejorar continuamente nuestros sistemas y procesos de seguridad. En esta área, Ledger implementará controles de seguridad más estrictos, conectando nuestra construcción pipeline que implementa estrictos software supply chain security al canal de distribución de NPM."
Bueno, parecía que la cuenta de NPM con permisos para publicar nuevas versiones de la biblioteca tenía controles de seguridad menos estrictos que otras partes de su infraestructura de software. ¿Incidente aislado por mala suerte?
El final de la carta es más standard Sección de compromiso con las autoridades, “declaración bajo control” y disculpas:
“Ledger se ha comprometido con las autoridades y está haciendo todo lo posible para ayudar a medida que se desarrolla esta investigación. Ledger ayudará a los usuarios afectados a encontrar a este mal actor, llevarlos ante la justicia, rastrear los fondos y trabajar con las autoridades para ayudar a recuperar los activos robados del pirata informático. Lamentamos profundamente los acontecimientos que se desarrollaron hoy para las personas afectadas.
La situación ahora está bajo control y la amenaza ha pasado. Entendemos el pánico que esto causó en la comunidad y en el ecosistema en general”.
La carta adjunta un cronograma, lo cual es muy bueno para que los usuarios comprendan cómo se descubrió el incidente, qué acciones específicas de contención y remediación se tomaron, y cómo se recuperará/compensará el daño a los usuarios afectados. Esta es la parte más específica de las monedas:
“Esta mañana CET, un ex empleado de Ledger fue víctima de un ataque de phishing que obtuvo acceso a su cuenta NPMJS. El atacante publicó una versión maliciosa del Ledger Connect Kit (que afecta a las versiones 1.1.5, 1.1.6 y 1.1.7). El código malicioso utilizó un proyecto falso de WalletConnect para redirigir fondos a una billetera de piratas informáticos. Los equipos de tecnología y seguridad de Ledger fueron alertados y se implementó una solución 40 minutos después de que Ledger se diera cuenta. El archivo malicioso estuvo activo durante aproximadamente 5 horas; sin embargo, creemos que la ventana en la que se drenaron los fondos se limitó a un período de menos de dos horas.. Ledger se coordinó con WalletConnect, quien rápidamente desactivó el proyecto fraudulento. La versión 1.1.8 genuina y verificada del Ledger Connect Kit ahora se está propagando y es seguro de usar.
Para los desarrolladores que desarrollan e interactúan con el código de Ledger Connect Kit: el equipo de desarrollo de connect-kit del proyecto NPM ahora tiene acceso de solo lectura y, por seguridad, no puede enviar directamente el paquete NPM. Hemos rotado internamente los Secretos para publicarlos en el GitHub de Ledger. Desarrolladores, por favor, comprueben que están usando la última versión, la 1.1.8.
Libro mayor, junto con Monedero Conectar y nuestros socios, han informado la dirección de la billetera del mal actor. La dirección ahora es visible en Cadena de análisis. Tether ha congelado el USDT del mal actor”.
Según esto, la contención fue rápida ya que el proyecto malicioso WalletConnect para desviar fondos se desactivó rápidamente. Pero incluso con esto, algunas billeteras quedaron vacías.
Consecuencias: cómo reaccionó la industria
Algunos usuarios expresaron enojo con Ledger por no haber podido evitar el compromiso, mientras que otros advirtieron contra los peligros de depender de bibliotecas de terceros.
La industria de la ciberseguridad tiene un nicho en las cibermonedas. Son bien conocidas las campañas de drenaje de billeteras, que utilizan principalmente sitios de phishing para engañar a los usuarios finales. El negocio SaaS habitual (estafa como servicio) cuenta con actores especializados en el vaciado de billeteras, como el proveedor de estafas. Escurridor infernal lo cual anunció el cese de operaciones en noviembre de 2023. Esto parece ser una bandera falsa de todos modos, según la actividad reciente observada en Dune @estafasniffer. El esquema que siguen fue explicado en esta publicación del Grupo IB:
Algunos analistas dieron pistas sobre lo que no hizo posible el ataque. Este comentario del usuario brianddk en el ticket en el repositorio del proyecto nos brinda información sobre la causa raíz:
A comentario de otro usuario, HenryQW, señaló la segunda cosa que hizo que las versiones maliciosas pudieran propagarse a través de CDN:
Es demasiado pronto para ver iniciativas a largo plazo que fortalezcan las interfaces de las billeteras de criptomonedas contra ataques de phishing. Parece que se requiere el cumplimiento de un standard similar a lo que el PA-DSS lo que hace para los proveedores de software de aplicaciones de pago podría ser bien recibido en la industria de la criptografía.
¡Y ahora, lecciones aprendidas!
Es sorprendente cómo una billetera de hardware, el epítome de la seguridad criptográfica, fue violado simplemente al obtener acceso a las credenciales de NPM de un “ex empleado” de Ledger (probablemente nombre de usuario/contraseña sin protección 2FA o un token de acceso). Este incidente sirve como un sorprendente recordatorio de que cuando uno está bajo fuego, su infraestructura de software debe protegerse con el mismo cuidado que sus productos de software o hardware.
La mayoría de los ataques a la cadena de suministro de software comienzan comprometiendo una cuenta interna (a menudo de un desarrollador o ingeniero de DevOps). Los atacantes luego se mueven lateralmente para vulnerar los sistemas internos de la infraestructura de software, como... CI/CD El sistema o las herramientas de implementación, o bien, logran añadir lógica maliciosa a los repositorios de código fuente, lo cual podría detectarse si se gestionan adecuadamente los cambios con protección de ramas y revisiones de código. Sin embargo, los atacantes no necesitan profundizar tanto cuando el objetivo es una biblioteca popular publicada en un registro público, especialmente si pueden acceder a las credenciales de publicación (escritura). Y esto es lo que ocurrió en este ataque.
Autenticación 2FA, específicamente utilizando elementos robustos como claves de seguridad, limita el riesgo en las operaciones interactivas. Para CI/CD pipelines, tokens de acceso con acceso limitado almacenados como un CI/CD Secreto es la forma habitual de proceder (y el token de acceso no debería filtrarse). Desafortunadamente, parece que el empleado no contaba con una autenticación de dos factores robusta. NPM permite... organizaciones para hacer cumplir 2FA (pero esto es opcional, no predeterminado), que es probablemente lo que debería tener Ledger. Y no olvides agregar lo apropiado. revocación de credenciales procedimientos para ex empleados, especialmente con acceso a recursos tan críticos como el alcance de NPM propiedad de la organización.
Fijación de versión para dependencias con versiones revisadas es una práctica que mitiga la propagación de dependencias maliciosas. En el contexto del incidente de Ledger, las versiones de la biblioteca que el conectar-kit-cargador tomado de CDN debería haber sido fijado y "no confíes en lo que arroje el CDN". Teniendo un verificación de suma de control por ejemplo, se debe utilizar a través de SRI (o incluso un esquema de firma digital que también autentique la fuente) al extraer de una CDN para la carga dinámica de código.
El resto es una historia.
Para las campañas de phishing más convencionales dirigidas a usuarios de billeteras, la pregunta es: ¿Qué hace que los usuarios caigan en trampas tendidas por delincuentes y confirmen transacciones que nunca tuvieron la intención de realizar? Los sitios de phishing en este dominio están bien diseñados y son convincentes, e imitan marcas de criptografía populares; y también ofrecen tokens gratis, acuñación de NFT y otras recompensas. Evitar que los usuarios caigan en este tipo de trampas es un problema que busca solución.
y para no olvidar la relacionada criptohacking ataques, una amenaza más general, en la que los adversarios se apoderan de las infraestructuras de la nube para ejecutar mineros de criptomonedas, a menudo de monedas de privacidad como Monero XMR y Zcash, con historiales de transacciones ocultos. El criptojacking es relevante porque puede afectar a CUALQUIER organización, y aunque la ganancia para el atacante podría ser baja, el costo para la víctima podría ser grande (Sysdig mencionó en este informe (que la organización víctima tiene un costo de 53 dólares por cada dólar extraído para el atacante).
Referencias
- Boleto "[URGENTE] Este repositorio utiliza una versión maliciosa del paquete npm @ledgerhq/connect-kit, 1.1.7”en el repositorio de Github.
- Carta del CEO de Ledger sobre el incidente, 14 de diciembre de 2023.
- Informe de incidentes de seguridad, por Ledger, 20 de diciembre de 2023.
- La explotación del libro mayor pone en peligro a DeFi; Sushi dice "No interactúe con NINGUNA dApp", publicar CoinDesk por Oliver Knight, 14 Dec 2023.
- Kit de ataque a la cadena de suministro en Ledger Connect: análisis del impacto y medidas preventivas. Publicación de SlowMist sobre el ataque, diciembre de 2023.
- Conceptos de seguridad de Web3: drenaje de billeteras, de Jammel Weaver, en Rektify AI, julio de 2023.
Vea nuestra demostración en vídeo
