Análisis del incidente de ataque de Hacker al proyecto Pump
Recientemente, el proyecto Pump ha enfrentado un grave incidente de seguridad que ha provocado la pérdida de una gran cantidad de fondos. Este artículo analizará las circunstancias específicas de este evento.
Proceso de ataque
Este ataque no fue llevado a cabo por hackers hábiles, sino que probablemente fue realizado por un ex-empleado del proyecto Pump. El atacante tenía acceso a la billetera de permisos utilizada por Pump para crear pares de trading en Raydium, que llamamos "cuenta atacada". Mientras tanto, todos los fondos LP de Bonding Curve en Pump que aún no han alcanzado los estándares para estar en Raydium se denominan "cuenta de preparación".
El atacante obtuvo una gran cantidad de fondos a través de un préstamo relámpago, utilizados para llenar todos los grupos que no alcanzaron el estándar de Raydium. Normalmente, cuando el grupo alcanza el estándar, el SOL en la "cuenta de preparación" debería transferirse a la "cuenta atacada". Sin embargo, el atacante retiró el SOL transferido durante este proceso, lo que impidió que los tokens que debían lanzarse en Raydium y bloquearse en el grupo completaran el lanzamiento.
Análisis de víctimas
Es importante señalar que el proveedor de préstamos instantáneos no sufrió pérdidas, ya que el préstamo se devolvió en el mismo bloque. Además, los tokens que ya están en Raydium no deberían verse afectados, ya que los LP están bloqueados.
Los que realmente sufrieron daños fueron los usuarios en los grupos de Pump que aún no estaban llenos antes del ataque. Los SOL que estos usuarios compraron fueron transferidos por los atacantes, lo que también explica por qué la pérdida inicialmente estimada alcanzó los 80 millones de dólares. Sin embargo, según las últimas noticias, la pérdida real es 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 la piscina podría haber sido una de las responsabilidades laborales previas del atacante. Similar a los robots que compraron en masa claves al principio de FriendTech V1, es muy probable que esto haya sido establecido por los oficiales para guiar el entusiasmo inicial.
Se puede suponer audazmente que el proyecto Pump, para lograr un arranque en frío, podría haber dejado que los atacantes se encargaran de usar los fondos del proyecto para llenar las reservas de los nuevos tokens emitidos (como $test, $alon, etc.), para que pudieran lanzarse en Raydium y generar entusiasmo. Sin embargo, no anticiparon que esto se convertiría en un punto de entrada para amenazas internas.
Lecciones aprendidas
Para los proyectos de imitación, simplemente copiar las funciones superficiales no es suficiente. Desarrollar un producto no significa que la gente vendrá a comerciar. Al operar plataformas de ayuda mutua, es crucial proporcionar un impulso inicial.
Más importante aún, el equipo del proyecto debe dar gran importancia a la gestión de permisos y las medidas de seguridad. Este incidente vuelve a demostrar que las amenazas internas pueden ser más peligrosas y difíciles de prevenir que los ataques externos.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
23 me gusta
Recompensa
23
7
Republicar
Compartir
Comentar
0/400
FundingMartyr
· 08-07 20:28
El daño causado por traidores es el mayor.
Ver originalesResponder0
TokenTherapist
· 08-05 18:16
Los traidores serán castigados por los cielos
Ver originalesResponder0
WhaleMinion
· 08-05 12:38
Los traidores son los más crueles.
Ver originalesResponder0
HodlNerd
· 08-05 12:34
Las amenazas internas dominan estadísticamente los exploits.
Ver originalesResponder0
TideReceder
· 08-05 12:23
Ex-empleado que traiciona desde adentro
Ver originalesResponder0
SandwichHunter
· 08-05 12:13
Los empleados internos serán atrapados.
Ver originalesResponder0
MetaverseVagabond
· 08-05 12:11
Una vez más, son las operaciones de permisos las que causan problemas.
El proyecto Pump sufrió un ataque interno de Hacker, con una pérdida de 2 millones de dólares.
Análisis del incidente de ataque de Hacker al proyecto Pump
Recientemente, el proyecto Pump ha enfrentado un grave incidente de seguridad que ha provocado la pérdida de una gran cantidad de fondos. Este artículo analizará las circunstancias específicas de este evento.
Proceso de ataque
Este ataque no fue llevado a cabo por hackers hábiles, sino que probablemente fue realizado por un ex-empleado del proyecto Pump. El atacante tenía acceso a la billetera de permisos utilizada por Pump para crear pares de trading en Raydium, que llamamos "cuenta atacada". Mientras tanto, todos los fondos LP de Bonding Curve en Pump que aún no han alcanzado los estándares para estar en Raydium se denominan "cuenta de preparación".
El atacante obtuvo una gran cantidad de fondos a través de un préstamo relámpago, utilizados para llenar todos los grupos que no alcanzaron el estándar de Raydium. Normalmente, cuando el grupo alcanza el estándar, el SOL en la "cuenta de preparación" debería transferirse a la "cuenta atacada". Sin embargo, el atacante retiró el SOL transferido durante este proceso, lo que impidió que los tokens que debían lanzarse en Raydium y bloquearse en el grupo completaran el lanzamiento.
Análisis de víctimas
Es importante señalar que el proveedor de préstamos instantáneos no sufrió pérdidas, ya que el préstamo se devolvió en el mismo bloque. Además, los tokens que ya están en Raydium no deberían verse afectados, ya que los LP están bloqueados.
Los que realmente sufrieron daños fueron los usuarios en los grupos de Pump que aún no estaban llenos antes del ataque. Los SOL que estos usuarios compraron fueron transferidos por los atacantes, lo que también explica por qué la pérdida inicialmente estimada alcanzó los 80 millones de dólares. Sin embargo, según las últimas noticias, la pérdida real es 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 la piscina podría haber sido una de las responsabilidades laborales previas del atacante. Similar a los robots que compraron en masa claves al principio de FriendTech V1, es muy probable que esto haya sido establecido por los oficiales para guiar el entusiasmo inicial.
Se puede suponer audazmente que el proyecto Pump, para lograr un arranque en frío, podría haber dejado que los atacantes se encargaran de usar los fondos del proyecto para llenar las reservas de los nuevos tokens emitidos (como $test, $alon, etc.), para que pudieran lanzarse en Raydium y generar entusiasmo. Sin embargo, no anticiparon que esto se convertiría en un punto de entrada para amenazas internas.
Lecciones aprendidas
Para los proyectos de imitación, simplemente copiar las funciones superficiales no es suficiente. Desarrollar un producto no significa que la gente vendrá a comerciar. Al operar plataformas de ayuda mutua, es crucial proporcionar un impulso inicial.
Más importante aún, el equipo del proyecto debe dar gran importancia a la gestión de permisos y las medidas de seguridad. Este incidente vuelve a demostrar que las amenazas internas pueden ser más peligrosas y difíciles de prevenir que los ataques externos.