Cronología y reflexiones del hack de Vyper

"Confía pero verifica" (confía, pero para verificar), no hagas "después del hecho". El error más grave es negro bajo las luces.

Debido a la inmutabilidad del contrato, el proyecto se basará implícitamente en el código escrito hace muchos años. Cuando solucionamos errores, debemos prestar más atención a su impacto potencial.

Esta vez sucedió así.

línea de tiempo

En este artículo, usaré "nosotros" para referirme a todos aquellos que trabajaron duro en este evento. Siento que aunque inicialmente contribuí un poco a encontrar el error, innumerables personas ayudaron mucho más a lo largo del proceso.

13:10 UTC pETH/ETH $11 millones [1] drenar.

13:19 UTC Michal publica en ETHSecurity sobre la repentina caída del precio de pETH.

Igor fue el primero en notar que algo andaba mal. Gracias a él, empezamos a investigar más.

Pero, ¿cómo el robot vuelve a ingresar add_liquidity() en la llamada remove_liquidity()?

14:01 UTC Se formó un equipo de contingencia sobre el problema.

14:07 UTC Usamos nuestro descompilador favorito [2] Descompilé el contrato JPEGd y noté que las ranuras de protección de reingreso son un poco diferentes.

// Entrada de la tabla de despacho para add_liquidity(uint256 [2] ,uint256) etiqueta_0057: si (almacenamiento [0x00] ) { revertir (memoria [0x00: 0x00]); } almacenamiento [0x00] = 0x01; // Entrada de la tabla de despacho para remove_liquidity(uint256,uint256 [2] ) etiqueta_1AF3: si (almacenamiento [0x02] ) { revertir (memoria [0x00: 0x00]); } almacenamiento [0x02] = 0x01;

14:27 UTC Confirmamos este problema con un simple contrato de prueba local.

@externo @nonreentrant("bloqueo") def prueba(dirección: dirección) -> bool: volver verdadero @externo @nonreentrant("bloqueo") def test2(dirección: dirección) -> bool: falso retorno

Este no es solo otro error de reingreso.

En este punto, nos dimos cuenta del impacto que esto iba a tener. Bloquear mensaje, eliminamos los mensajes públicos sobre esta vulnerabilidad.

14:37 UTC Wavey ayudó a identificar la confirmación vulnerable y la versión afectada. Charles y yo también confirmamos esto al inspeccionar manualmente la salida del compilador Vyper.

Es una carrera contra los piratas informáticos.

Afortunadamente, la gente también lo confunde con la reentrada de solo lectura. Extracto del canal de alerta de seguridad Web3: Alchemix y Metronome DAO también fueron pirateados debido a un error de reingreso de solo lectura [3]

Michael también encontró vulnerabilidades potenciales en los grupos de alETH y msETH que ejecutan la versión 0.2.15.

14:50 UTC msETH/ETH agotado [4] 。

15:34 UTC alETH/ETH se agota [5] 。

15:43 UTC Encontramos una vulnerabilidad en CRV/ETH compilado con Vyper versión 0.3.0 [6] . Es vital que mantengamos la confidencialidad de los contratos afectados durante el mayor tiempo posible.

16:11 UTC Empezamos a trabajar en las vulnerabilidades de sombrero blanco.

Desafortunadamente, demasiadas organizaciones están realizando investigaciones independientes al mismo tiempo y abundan los rumores. A las 16:44 UTC, decidimos emitir una declaración pública sobre la versión afectada [7] 。

A las 18:32 UTC, teníamos un exploit de prueba de concepto que podría usarse para un posible rescate de sombrero blanco. El bpak de Chainlight también está trabajando en una vulnerabilidad al mismo tiempo y la compartió a las 19:06 UTC.

Cinco minutos después, a las 19:11 UTC, alguien robó los fondos [8] 。

La estructura de ataque es muy diferente de nuestra prueba de concepto y es poco probable que sea una filtración de nuestro equipo. De todos modos, es muy frustrante.

Aún así, hay mucho por hacer.

21:26 UTC Addison ideó un plan ambicioso para salvar los activos restantes en el grupo CRVETH.

Si envía 30k crv a crv/eth pool, Puede actualizar la tarifa administrativa luego establezca la tasa crv/eth alrededor de 0.15 eth por crv Básicamente, todos los cientos de K crv en el grupo se pueden extraer

21:52 UTC bpak realizó una prueba de concepto funcional que podría ahorrar 3100 ETH.

Diez minutos después, a las 22:02 UTC, volvimos a ser derrotados. Sorprendentemente, CRV administra robots de gastos [9] Se han tomado fondos y la piscina está drenada. [10] 。

culpa

culpar (Balme) es una palabra fuerte. Señalar con el dedo es inútil. Creo que es útil pensar en lo que podría hacerse mejor.

Concurso

Todos los esfuerzos de White Hat fueron derrotados en menos de media hora. A veces, cada segundo cuenta.

Quizás estos ataques podrían haberse llevado a cabo con mejor preparación y recursos. Al mismo tiempo, esto parece ser un arma de doble filo. ¿Es realmente una buena idea recopilar información sobre cómo realizar un hackeo? ¿En quién debemos confiar?

Por otro lado, creo que todo el proceso es muy efectivo. Pasamos de la sospecha inicial a la confirmación de quién era vulnerable en 2 horas y 4 minutos.

Divulgación de información

Soy auditor y hacker de sombrero blanco.

La industria de la auditoría tiene una cultura editorial única. Nos pagan por nuestro liderazgo de pensamiento técnico y nuestro profundo conocimiento de las vulnerabilidades. Una forma de demostrar su liderazgo y profundidad es publicar [11] La "primicia" sobre la piratería. Los investigadores son caros y el retorno de la inversión es la publicidad.

Por otro lado, existe un argumento convincente de que una divulgación temprana de una versión afectada tendría un impacto significativo en un rescate de whitehat.

Si hubiera sido una media hora extra, se podrían haber ahorrado $18 millones.

Los auditores no pagan por el impacto de sus informes. En cambio, obtienen me gusta, retweets y cobertura. Esto parece ser un problema.

Próximo paso

No estoy de acuerdo con "necesitamos una verificación formal para resolver este problema" y cosas por el estilo. Este error puede detectarse mediante pruebas unitarias. La verificación formal es muy útil para muchos tipos de errores, pero no creo que sea igualmente útil para compiladores relativamente simples que no optimizan.

Tenga en cuenta que este error se solucionó en noviembre de 2021 [12] 。

Creo que esta vulnerabilidad de Vyper no es un problema con la tecnología o el lenguaje del equipo de Vyper en sí, sino más bien un problema de proceso. Este error se solucionó hace mucho tiempo sin darse cuenta de su impacto potencial en el momento de la corrección.

Desafortunadamente, los bienes públicos se pasan por alto fácilmente. Debido a la inmutabilidad del contrato, los proyectos se basan implícitamente en el código escrito hace muchos años. Los desarrolladores de protocolos y los expertos en seguridad deben estar al tanto de los últimos desarrollos de seguridad en la pila de ejecución.