BlockThreat - Semana 28, 2025 💙 Patrocinado por @SecurityOak 🔥 Explotación masiva de contratos de representación descubiertos por @deeberiroz y de sombrero blanco por @pcaversaccio @dedaub y @_SEAL_Org 💸 @GMX_IO hackeo de reentrada 42 millones de dólares (37 millones de dólares recuperados) 💸 @KintoXYZ proxy no inicializado. 1,55 MILLONES DE DÓLARES

Lecciones para expertos en seguridad: Audite el proxy en los its rigurosamente. Supervise las cadenas de llamadas delegadas (fácil de hacer en nuestra aplicación) y garantice la integridad del almacenamiento con patrones de proxy complejos. Los accesorios van a @deeberiroz @VennBuild @pcaversaccio @_SEAL_Org Mantente alerta.

así que descubrí que es aún más elegante. Observé que el tx de ejecución frontal (por parte de los atacantes) llama a 'initialize' y los protocolos también llaman _successful_ 'initialize' después (por lo tanto, piensan que todo es normal). Pero espera, ¿cómo es esto posible? Tuve que mirar muy a fondo los cambios en las ranuras de almacenamiento y adivinar lo que encontré: _restablecieron_ el valor de la ranura de almacenamiento '_initialized' al final de la tx de ejecución frontal (después de que cambiaron al contrato de implementación malicioso). Esto significa que el almacenamiento proxy se ve ahora como si nunca se inicializara. La ranura de almacenamiento relevante a mirar es 'keccak256(abi.encode(uint256(keccak256(" - 1)) & ~bytes32(uint256(0xff))' = '0xf0c57e16840df040f15088dc2f81fe391c3923bec73e23a9662efc9c229c6a00' Este es el mal del siguiente nivel.

A principios de esta semana, se identificó una posible vulnerabilidad en el contrato de administrador de cadena cruzada de Orderly en la cadena BNB. En respuesta, nuestra bóveda de BNB para depósitos y retiros se detuvo de inmediato, los contratos se migraron y los depósitos/retiros se reanudaron en 2 horas. ✅ Los fondos de los usuarios no están en riesgo ni se han perdido. ¡Un agradecimiento especial a @deeberiroz, @VennBuild, @seal_911, @pcaversaccio y al resto del equipo que ayudaron a señalar esto! Juntos 🤝 estamos más seguros

[5/5] Pase de lista de gratitud • @SlowMist_Team por la clasificación y los parches ininterrumpidos • @dedaub, @pcaversaccio y la sala de guerra @seal_911 por un barrido de código de 36 horas • @etherscan por una limpieza de la interfaz de usuario ultrarrápida • Y de nuevo, gracias @deeberiroz, @VennBuild @davidberiro: su aviso salvó el día 💙

Se vuelve aún más elegante: la forma en que Etherscan fue engañado mostrando el contrato de implementación incorrecto se basa en la configuración de 2 ranuras de proxy diferentes en la misma tx de frontrunning. Por lo tanto, Etherscan utiliza una cierta heurística que incorpora diferentes ranuras de almacenamiento para recuperar el contrato de implementación. Hay un proxy antiguo de OpenZeppelin que usaba la siguiente ranura: 'keccak256("org.zeppelinos.proxy.implementation")' = '0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3' Ahora también tenemos la ranura estándar EIP-1967 'bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)' = '0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc' Entonces, lo que sucedió es que la antigua ranura de proxy OpenZeppelin se escribió con la dirección de implementación benigna _y_ la ranura estándar EIP-1967 también se escribió con la dirección de implementación maliciosa. Dado que Etherscan consulta primero la ranura de proxy anterior, primero recuperó la de aspecto benigno y, por lo tanto, la mostró.

RT @devops199fan: .@seal_911 básicamente sirve como el centro voluntario de operaciones de seguridad global (GSOC) de las criptomonedas Tenemos la suerte de tener gente como...

No sé hombre, pero la verdadera amenaza para Ethereum no es el estado en realidad (al menos no hoy). Son los capitalistas de riesgo y los arribistas del protocolo los que intentan neutralizarlo para convertirlo en un brillante patio de recreo de tecnología financiera para DeFi "seguro" y que cumple con las normas. Escúchame: no quieren un código imparable. No quieren resistencia. Quieren un puto _control_. Porque en el fondo, saben en lo que podría convertirse Ethereum si se deja desencadenado: una capa de ejecución global resistente a la censura y que prioriza la privacidad y que ningún estado, ninguna corporación, ningún cártel de demandas podría detener. Hagámoslo realidad.

Así que alguien se pone en contacto contigo en LinkedIn con una oportunidad de trabajo prometedora. Suena bien, ¿no? Parecen legítimos (después de verificarlos durante 1 minuto) y después de una breve conversación, te envían un repositorio de GitHub con una simple Next.js "tarea de reclutamiento". Lo clonas, lo ejecutas... Y 10 minutos después, su dispositivo está completamente comprometido cuando descubre que sus billeteras calientes se agotaron. Ok, ¿qué pasó? Dado el hecho de que nosotros (= SEAL 911) hemos visto este ataque una y otra vez, permítanme revelar algunos de los detalles más importantes: - primero, la advertencia más importante: NO ejecutes código aleatorio que algún tipo al azar te envió. Honestamente, joder, no. - Revisa siempre a fondo los archivos de configuración _ejecutables_ de los repositorios. En este caso en particular, el archivo 'next.config.js' tenía un gran relleno que ocultaba la carga maliciosa muy a la derecha. - Desplácese siempre horizontalmente: el hecho de que no vea nada malicioso cuando mire el contenido no significa que esté limpio. Importante: El código malicioso puede estar oculto en los archivos en los que confías, pero no donde lo esperas. Realmente espero que este tuit llegue a suficientes personas para evitar que al menos algunas víctimas futuras caigan en este tipo de ataques.

Mira, por lo general soy un gran partidario de Proton. Pero en un mundo lleno de ladrones de información, no le dices a la gente que almacene las claves privadas de su billetera criptográfica en un administrador de contraseñas, ¡incluso si es Proton Pass! Y seamos claros: tampoco debes almacenar cosas como pasaportes, licencias de conducir, registros médicos o números de seguro social en un administrador de contraseñas. Si se ve comprometido, todo eso se puede usar para pasar las comprobaciones KYC y robar su identidad o activos. Respeto a Proton, pero en serio, a la mierda con esto. Esa no es la forma de proteger sus datos más críticos.