Análisis del incidente de ataque interno en el proyecto Pump

Recientemente, el proyecto Pump sufrió un ataque interno que causó pérdidas significativas. Este artículo realizará un análisis detallado de este evento.

Proceso de ataque

El atacante no es un hacker externo, sino que probablemente es un ex-empleado del proyecto Pump. Él tiene acceso a la billetera de permisos utilizada por Pump para crear pares de intercambio de tokens en Raydium, que llamamos "cuenta objetivo". Al mismo tiempo, el fondo de liquidez de Bonding Curve LP de los tokens creados en Pump pero que aún no cumplen con los estándares para lanzarse en Raydium se llama "cuenta preparatoria".

El atacante obtuvo un préstamo relámpago a través de una plataforma de préstamos y utilizó esos fondos para llenar todos los fondos que no cumplían con los estándares de Raydium. Normalmente, cuando el fondo alcanza el estándar, los SOL en la "cuenta de preparación" deben transferirse a la "cuenta objetivo". Sin embargo, el atacante retiró los SOL transferidos durante este proceso, lo que impidió que los tokens que debían lanzarse en Raydium y bloquear el fondo completaran la operación de lanzamiento.

Análisis de las víctimas

Este ataque no afectó los fondos de la plataforma de préstamos, ya que el préstamo relámpago se devolvió en el mismo bloque. Los tokens que ya están en línea en Raydium no deberían verse afectados debido a que el LP está bloqueado.

Los verdaderos perjudicados son los usuarios de Pump que aún no habían llenado la piscina antes del ataque. Todo el SOL que compraron fue transferido durante el ataque mencionado. Esto también explica por qué se estimó inicialmente que las pérdidas podrían alcanzar los 80 millones de dólares ( Nota: Los datos más recientes muestran que las pérdidas reales son de aproximadamente 2 millones de dólares ).

Investigación de las causas del ataque

Es evidente que este incidente expone una grave negligencia del equipo del proyecto en la gestión de permisos. Podemos suponer que llenar el grupo podría haber sido una de las responsabilidades laborales anteriores del atacante. Similar a cómo algunas plataformas sociales en sus primeras etapas utilizan bots oficiales para simular la actividad comercial.

Es muy probable que el proyecto Pump, para lograr un lanzamiento en frío, haya hecho que los atacantes se encarguen de utilizar los fondos del proyecto para llenar el fondo de los nuevos tokens emitidos ( como $test, $alon, etc. ), para que puedan lanzarse en Raydium y aumentar el precio para atraer atención. Pero no anticiparon que esto eventualmente se convertiría en un punto de ruptura para un ataque interno.

Resumen de lecciones

1. Para proyectos similares, simplemente imitar la superficie no es suficiente. Debe considerarse cómo proporcionar el impulso inicial, en lugar de simplemente pensar que una vez que hay un producto, las transacciones ocurrirán naturalmente.

2. El proyecto debe dar gran importancia a la gestión de permisos y las medidas de seguridad. Las amenazas internas suelen ser más peligrosas que los ataques externos, ya que el personal interno tiene acceso a información y permisos clave.

3. Al diseñar el sistema, se debe seguir el principio de menor privilegio, asegurando que cada rol solo pueda acceder a los recursos necesarios para realizar su trabajo.

4. Realizar auditorías de seguridad y revisiones de permisos de forma regular para detectar y corregir a tiempo posibles vulnerabilidades de seguridad.

5. Establecer y mejorar el proceso de salida de empleados, asegurando que se recuperen a tiempo todos los permisos e información sensible cuando un empleado se marche.

Este evento nos recuerda una vez más que en el rápido desarrollo del ámbito de las criptomonedas, la seguridad siempre debe ser la prioridad. Los equipos de los proyectos deben mantenerse alertas en todo momento y mejorar constantemente las medidas de seguridad para proteger los intereses de los usuarios y del propio proyecto.