Protocolo Seneca - REKT

Más de $6.4 millones fueron robados de las billeteras de los usuarios el 28 de febrero, gracias al mal tao de Seneca.

Primero reportado por spreekaway en X, el ataque implicó un exploit crítico de aprobaciones, afectando a usuarios en Arbitrum y Ethereum.

Aproximadamente el 80% de los fondos fueron devueltos en un día, pero el resto ha sido transferido a 2 direcciones, posiblemente como recompensa.

Durante el concurso de auditoría cancelado el pasado noviembre, un investigador de seguridad descubrió el mismo bug detrás del ataque.

"Seneca utiliza código probado en batalla, verificable públicamente en el GitHub de Seneca." Seneca hizo esta declaración en X poco después de cerrar abruptamente su concurso de auditoría de Sherlock debido a posibles problemas de licencia de código.

Semanas después, entraron en batalla y lanzaron sin miedo, bajo la creencia de que tenían suficiente armadura gracias a la auditoría realizada por Halborn Security.

La fuente del bug, el contrato Chamber, fue auditado antes del despliegue, según Seneca. Cabe señalar, algunos de los hallazgos de Halborn estaban relacionados con aprobaciones, este problema exacto no fue destacado.

Claramente, los otros guerreros en el campo de batalla estaban listos para el desafío, porque solo les tomó menos de 2 meses encontrar grietas en la armadura de Seneca.

Después del hackeo, otros en la comunidad afirmaron que fueron expulsados de Discord por reportar el bug.

Claramente, Seneca sabía que había problemas, pero eligió la ruta imprudente.

Revoca las aprobaciones si fuiste desafortunado en invertir en este desastre.

Ethereum:

• PT-ezETH: 0x529eBB6D157dFE5AE2AA7199a6f9E0e9830E6Dc1
• apxETH: 0xD837321Fc7fabA9af2f37EFFA08d4973A9BaCe34
• PT-weETH: 0xBC83F2711D0749D7454e4A9D53d8594DF0377c05
• PT-rsETH: 0x65c210c59B43EB68112b7a4f75C8393C36491F06

Arbitrum:

• PT-weETH: 0x11446bbb511e4ea8B0622CB7d1437C23C2f3489b
• stEUR: 0x7C160FfE3741a28e754E018DCcBD25dB04B313AC
• PT-aUSDC: 0x4D7b1A1900b74ea4b843a5747740F483152cbA5C
• wstETH: 0x2d99E1116E73110B88C468189aa6AF8Bb4675ec9
• PT-rsETH: 0x2216E32006BB80d20f7906b88876964F9AF68aFb

¿Malas decisiones o simplemente otro protocolo malo?

Crédito: Crypto Smith, Seneca, Spreek, Beosin Alert

El exploit aprovechó un bug en el código de Seneca para drenar activos de usuarios que tenían aprobaciones activas para ciertos contratos.

El atacante utilizó parámetros calldata construidos para llamar a transferfrom y transferir tokens que estaban aprobados para los contratos del proyecto a la dirección del atacante.

Esto permitió al explotador robar cualquier LST no desplegado de la cartera del usuario.

Los contratos no pudieron ser pausados debido a una mala implementación de la función de pausa. Debido a que las funciones de pausa y despausa son internas, no hay forma de llamarlas.

El explotador incluso robó 50k senUSD de la dirección del equipo de Seneca. 50K que fueron aprobados 33 días antes, pero nunca desplegados. ¿Deberíamos preguntarnos por qué?

Se robaron más de 1.9k de ETH implicando varios LST que fueron intercambiados por ETH. Actualmente se mantienen en 3 direcciones.

Direcciones del explotador 1: 0x94641c01a4937f2c8ef930580cf396142a2942dc

Direcciones del explotador 2: 0x5217c6923a4efc5bcf53d9a30ec4b0089f080ed0

Direcciones del explotador 3: 0xe83b072433f025ef06b73e0caa3095133e7c5bd0

Ejemplo de transacción de ataque: 0x9f371267

Seneca abordó el exploit unas horas después, instruyendo a los usuarios a revocar las aprobaciones. Pero el daño ya estaba hecho.

Unas horas más tarde, Seneca publicó un mensaje en cadena en X dirigido a un sombrero blanco, solicitando que los fondos fueran devueltos a cambio de una recompensa del 20%.

Poco después, el hacker devolvió 1,537 ETH a la dirección del Gnosis Safe y transfirió 300 ETH a 2 nuevas direcciones.

Dirección 1: 0x0C77350C4BDe539FfCee261A149dbc6e6afDA517

Dirección 2: 0xa07c64E55F52AAf5c361321CF01b316eCbddB5A9

Afirmaron que se publicará un informe post-mortem una vez que se recopile toda la información.

La dirección del explotador detrás del ataque fue financiada hace 5 meses a través de FixedFloat. Permaneció inactiva, hasta poco antes de que se llevase a cabo el ataque en Seneca.

Sigue el flujo de fondos:

¿Seneca hará su debida diligencia o continuará el patrón de irresponsabilidad?

Las señales de advertencia estaban ahí desde varios en la comunidad de seguridad Web3. Todos sonaron la alarma, excepto Seneca.

Seneca actuó a prueba de balas con su código probado en batalla (es decir, bifurcado). Un miembro del equipo, en un Tweet eliminado, se jactó de su código impecable, mientras menospreciaba a Sherlock en el proceso.

Reclamar ninguna responsabilidad legal es la guinda del pastel en este desastre.

Hay una línea delgada entre la arrogancia y la ignorancia y Seneca cayó de cara en un lado. ¿De qué lado crees que es?

Tal vez deberían haber dedicado más tiempo a asegurar su código en lugar de comercializar un proyecto roto.

No hay tal cosa como tener demasiados ojos en tu código. Cuantas más auditorías, concursos y revisiones de seguridad, mejor.

El peor escenario probablemente se evitó, gracias a que el atacante devolvió la mayor parte de los fondos, pero esto podría haberse evitado.

Si no pagas a los sombreros blancos para que intenten romper tu código, se verán forzados a ponerte como ejemplo.

Pero dada la forma en que Seneca manejó esta situación, ¿puedes culparlos?

REKT sirve como plataforma pública para autores anónimos, nos deslindamos de la responsabilidad por las opiniones y contenidos alojados en REKT.

dona (ETH / ERC20): 0x3C5c2F4bCeC51a36494682f91Dbc6cA7c63B514C

aviso legal:

REKT no es responsable ni culpable de ninguna manera por cualquier Contenido publicado en nuestro Sitio Web o en conexión con nuestros Servicios, sin importar si fueron publicados o causados por Autores ANÓN de nuestro Sitio Web, o por REKT. Aunque determinamos reglas para la conducta y publicaciones de los Autores ANÓN, no controlamos y no somos responsables por cualquier contenido ofensivo, inapropiado, obsceno, ilegal o de cualquier forma objetable, que se pudiera encontrar en nuestro Sitio Web o Servicios. REKT no es responsable por la conducta, en línea o fuera de línea, de cualquier usuario de nuestro Sitio Web o Servicios.