Drenaje por burn público en SafeMoon

El 28 de marzo de 2023, la memecoin promocionada por Jake Paul SafeMoon perdió aproximadamente $8,9 millones de su pool de liquidez WBNB cuando un atacante explotó una función burn() pública accidentalmente expuesta en una actualización reciente del contrato. La función permitía a cualquier usuario quemar tokens desde cualquier otra dirección — incluido el propio Pool de Liquidez WBNB de SafeMoon. Tras la negociación, el atacante devolvió $7 M (80%).

Qué ocurrió

Una actualización del contrato de SafeMoon introdujo una función burn() con permisos de acceso públicos — casi con certeza una consecuencia no intencional de un refactor que se suponía dejaría la función como una operación admin interna. La función permitía a cualquier llamador especificar cualquier dirección y quemar tokens SFM desde el saldo de esa dirección, sin verificación de autorización.

El análisis de PeckShield notó el patrón de actualización y caracterizó el bug como probablemente relacionado con una filtración de clave admin — alguien con la autoridad de actualización parece haber desplegado la versión de burn público del contrato, ya sea mediante compromiso o mediante un error de desarrollador que no fue detectado en la revisión.

El ataque:

1. Identificó la función burn() pública en el nuevo contrato.
2. Quemó la mayoría de los tokens SFM mantenidos por el pool de liquidez WBNB/SFM — reduciendo drásticamente el suministro de SFM en el pool mientras dejaba el WBNB sin cambios.
3. El mecanismo automático de descubrimiento de precios del pool interpretó la reducción de suministro como un enorme pico de precio en SFM — porque el mismo WBNB ahora tenía que ser tasado contra un suministro diminuto de SFM.
4. Vendió una pequeña cantidad de SFM al pool al precio artificialmente inflado, drenando la mayoría del WBNB del pool a cambio.
5. Se marchó con aproximadamente $8,9 M en WBNB.

Consecuencias

• El equipo de SafeMoon alertó a la comunidad en horas y se comunicó con el atacante mediante mensajes on-chain.
• El atacante devolvió $7 M (80% de los fondos robados) tras la negociación, conservando $2 M como "recompensa" efectiva.
• SafeMoon pausó los contratos afectados y desplegó un token rediseñado con controles de acceso adecuados.
• El episodio contribuyó al desmoronamiento más amplio del proyecto SafeMoon, que ya había enfrentado acciones de aplicación de la SEC por acusaciones de fraude contra sus fundadores.

Por qué importa

SafeMoon es un caso impactante de cómo una sola función pública por error puede comprometer todo el modelo económico de un contrato. La función burn() en cuestión era, en su forma prevista, una operación administrativa rutinaria. Exponerla sin control de acceso la transformó en un drenador universal de pools para cualquier pool de liquidez que tuviera SFM.

Las lecciones estructurales:

1. Los modificadores de acceso en cada función externa deben ser revisados línea por línea, especialmente durante actualizaciones. El valor por defecto para cualquier operación privilegiada debería ser onlyOwner o equivalente; la carga de la prueba está sobre el desarrollador para justificar cualquier función que sea public o external sin restricciones.
2. Los permisos de funciones deben probarse explícitamente — cada auditoría debería incluir una prueba de "cualquiera puede llamar esto" para cada ruta privilegiada, no solo pruebas funcionales del flujo de usuario previsto.
3. Las actualizaciones recientes son de alto riesgo durante las primeras 48-72 horas tras el despliegue. Muchos protocolos ahora programan auditorías post-actualización independientes o recompensas comunitarias por bugs con pagos elevados durante la ventana inmediata post-actualización.

El desmoronamiento más amplio de SafeMoon — combinando el hackeo con la aplicación de la SEC y la tokenómica subyacente siendo ampliamente vista como depredadora — es también un patrón recurrente de memecoins: los fallos técnicos de seguridad, la presión regulatoria y el escepticismo a nivel de diseño suelen converger en los mismos proyectos en meses.