Análisis del incidente de seguridad en la plataforma Pump

Recientemente, se produjo un grave incidente de seguridad en la plataforma Pump, que resultó en la pérdida de fondos de numerosos usuarios. Este artículo llevará a cabo un análisis exhaustivo de los antecedentes y las consecuencias de este evento.

Proceso de ataque

El atacante no es un hacker excepcional, sino que probablemente es un ex empleado de la plataforma Pump. Él tiene el acceso a la billetera de permisos que Pump utiliza para crear pares de intercambio de tokens en un DEX, la cual llamamos "cuenta víctima". Y todos los fondos de LP de Bonding Curve en Pump que aún no cumplen con los estándares necesarios para ser listados en un DEX, los llamamos "cuenta de preparación".

El atacante primero obtuvo un préstamo relámpago de una plataforma de préstamos para llenar todos los grupos de tokens que no cumplían con los estándares de listado. Normalmente, cuando el grupo alcanza los estándares de listado, el SOL en la "cuenta de preparación" debería transferirse a la "cuenta víctima". Pero el atacante retiró el SOL transferido en ese momento, lo que provocó que los tokens que deberían haberse listado y bloqueado en el grupo no pudieran listarse a tiempo.

Análisis de víctimas

Según el análisis, las víctimas eran principalmente usuarios que habían comprado tokens que aún no habían llenado la piscina en la plataforma Pump antes del ataque. Sus SOL fueron sustraídos mediante el método de ataque mencionado. Esto también explica por qué la estimación inicial de pérdidas podría alcanzar los 80 millones de dólares (los últimos datos indican que la pérdida real es de aproximadamente 2 millones de dólares).

Es importante notar que los tokens que ya están listados en algún DEX no deberían verse afectados por este ataque, ya que su LP está bloqueado.

Especulación sobre la identidad del atacante

El atacante tiene la clave privada de la "cuenta víctima", lo que sin duda expone una gran negligencia en la gestión de permisos de la plataforma. Podemos suponer que llenar el fondo de tokens podría haber sido una de las responsabilidades laborales anteriores del atacante.

A diferencia de lo que hacen otras plataformas, Pump podría haber asignado a este empleado la responsabilidad de utilizar los fondos del proyecto para llenar el fondo de nuevos tokens emitidos (muy probablemente muchos de ellos sean tokens de prueba emitidos por él mismo), para que estos tokens pudieran listarse en el intercambio y generar interés. No esperaba que esto se convirtiera finalmente en un punto de ruptura de la amenaza interna.

Lecciones aprendidas

1. Para proyectos similares, simplemente imitar la superficie no es suficiente. Para atraer a los usuarios a comerciar, se necesita proporcionar un impulso inicial.

2. El equipo del proyecto debe prestar especial atención a la gestión de permisos y a las medidas de seguridad. Es crucial asignar permisos de manera razonable, realizar auditorías periódicas y prevenir riesgos internos.

3. Los usuarios deben mantenerse alerta al participar en plataformas emergentes, especialmente en lo que respecta al comercio de tokens que no están completamente llenos o que no están listados en intercambios de renombre.

4. El equipo del proyecto debe establecer un mecanismo de gestión de riesgos completo, incluyendo múltiples firmas, niveles de autorización, etc., para reducir el riesgo de fallo único.

5. Realizar auditorías de seguridad y pruebas de penetración de manera regular para identificar y corregir vulnerabilidades potenciales de manera oportuna.

6. Fortalecer la formación de empleados y la educación ética, establecer una cultura empresarial saludable y reducir el riesgo de amenazas internas.

Este evento nos recuerda una vez más que, en la rápida evolución de la industria de las criptomonedas, la seguridad siempre es la prioridad número uno. Tanto los desarrolladores de proyectos como los usuarios deben mantenerse alerta y tomar las medidas de seguridad necesarias.