Análisis del incidente de ataque de hackers a Pump
Recientemente, la plataforma Pump sufrió un ataque de un Hacker, lo que provocó pérdidas significativas. Este artículo analizará en profundidad el proceso del ataque, el alcance de los afectados y las posibles causas.
Análisis de técnicas de ataque
Los atacantes de este incidente no son hackers altamente capacitados, sino que probablemente son exempleados de la plataforma Pump. Los atacantes tienen en su poder la clave privada de una cuenta de cartera clave, que tiene permiso para crear pares de intercambio de tokens en un determinado intercambio descentralizado. Llamamos a esta cuenta "cuenta atacada".
El atacante primero obtuvo un préstamo relámpago de una plataforma de préstamos, utilizando esos fondos para llenar todos los grupos de tokens que aún no habían alcanzado el estándar de lanzamiento. Normalmente, cuando el grupo alcanza el estándar, los tokens SOL que originalmente estaban en la "cuenta de reserva" deberían transferirse a la "cuenta atacada". Sin embargo, el atacante interceptó los SOL transferidos en este proceso, lo que impidió que estos tokens, que deberían haber sido lanzados y bloqueados en liquidez, se lanzaran a tiempo.
Análisis de víctimas
Es importante destacar que la plataforma de préstamos relámpago no sufrió pérdidas, ya que el préstamo relámpago se devolvió dentro del mismo bloque. Además, los proyectos de tokens que ya se han lanzado en intercambios descentralizados y han bloqueado la liquidez también deberían no haberse visto afectados.
Los verdaderos perdedores son aquellos usuarios que compraron tokens en una piscina que aún no estaba completamente llena antes de que ocurriera el ataque. Los tokens SOL que invirtieron fueron transferidos por los atacantes, lo que también explica por qué se estimó inicialmente que las pérdidas ascendían a 80 millones de dólares (aunque los datos más recientes muestran que la pérdida real es de aproximadamente 2 millones de dólares).
Investigación de las causas de las vulnerabilidades
Aparentemente, este incidente expone la grave negligencia del equipo de Pump en la gestión de permisos. Podemos suponer que el control de la llenado del fondo era originalmente una de las responsabilidades del atacante.
Al igual que las prácticas de otros proyectos, como una plataforma de redes sociales que en sus inicios podría utilizar robots oficiales para simular la actividad comercial, podemos atrevernos a suponer que Pump, para lograr un arranque en frío, podría haber contratado a hackers para usar los fondos del proyecto para llenar la piscina de nuevos tokens emitidos (muy probablemente muchos de estos tokens son emitidos por el propio equipo del proyecto), con el objetivo de que estos tokens pudieran lanzarse sin problemas y generar interés. Lamentablemente, esta estrategia se convirtió finalmente en la raíz de una vulnerabilidad de seguridad.
Lecciones aprendidas
Para los equipos que desean replicar el modelo de proyectos exitosos, simplemente imitar la superficie no es suficiente. Para atraer a los usuarios a realizar transacciones, también se necesita proporcionar un impulso inicial.
El equipo del proyecto debe dar una gran importancia a la gestión de permisos y a las medidas de seguridad. La asignación razonable de permisos, así como la revisión y actualización periódica de las políticas de seguridad, son clave para garantizar la operación segura del proyecto.
Al realizar intentos de innovación, es necesario considerar de manera integral los riesgos potenciales y establecer un mecanismo de control de riesgos completo.
Los usuarios deben mantenerse alerta al participar en nuevos proyectos, comprender plenamente los riesgos del proyecto y evitar seguir ciegamente la tendencia.
Este incidente nos recuerda una vez más que en el rápido desarrollo del campo de las criptomonedas, la seguridad siempre es un factor primordial a considerar. Tanto los proyectos como los participantes deben mantenerse alerta en todo momento y trabajar juntos para mantener el desarrollo saludable del ecosistema.
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.
12 me gusta
Recompensa
12
9
Compartir
Comentar
0/400
PrivateKeyParanoia
· hace1h
Otra vez un traidor está causando problemas
Ver originalesResponder0
AirdropGrandpa
· hace23h
Haciendo cosas, siempre hay problemas. Proyectos inútiles, fuera.
Ver originalesResponder0
CryptoSurvivor
· 08-02 17:56
¿Qué demonios? ¿Hay un traidor que está saboteando desde adentro?
Ver originalesResponder0
rugpull_ptsd
· 08-02 17:54
Así que es un traidor dentro de otro traidor.
Ver originalesResponder0
ParallelChainMaxi
· 08-02 17:54
El espectáculo de dejar el trabajo y hacer un escándalo no se acaba.
Ver originalesResponder0
FUDwatcher
· 08-02 17:52
¿No fue demasiado cruel la acción del ex empleado?
Ver originalesResponder0
PessimisticOracle
· 08-02 17:50
El ex-empleado fue demasiado severo.
Ver originalesResponder0
ImpermanentPhilosopher
· 08-02 17:44
Justo después de pagar la deuda, un excompañero me apuñaló por la espalda.
Ver originalesResponder0
ToMakeALotOfMoney
· 08-02 17:43
Inmediatamente Donald Trump pasó la flota de portaaviones Ford.
La plataforma Pump fue atacada por hackers, y un ex-empleado abusó de sus permisos causando una pérdida de 2 millones de dólares.
Análisis del incidente de ataque de hackers a Pump
Recientemente, la plataforma Pump sufrió un ataque de un Hacker, lo que provocó pérdidas significativas. Este artículo analizará en profundidad el proceso del ataque, el alcance de los afectados y las posibles causas.
Análisis de técnicas de ataque
Los atacantes de este incidente no son hackers altamente capacitados, sino que probablemente son exempleados de la plataforma Pump. Los atacantes tienen en su poder la clave privada de una cuenta de cartera clave, que tiene permiso para crear pares de intercambio de tokens en un determinado intercambio descentralizado. Llamamos a esta cuenta "cuenta atacada".
El atacante primero obtuvo un préstamo relámpago de una plataforma de préstamos, utilizando esos fondos para llenar todos los grupos de tokens que aún no habían alcanzado el estándar de lanzamiento. Normalmente, cuando el grupo alcanza el estándar, los tokens SOL que originalmente estaban en la "cuenta de reserva" deberían transferirse a la "cuenta atacada". Sin embargo, el atacante interceptó los SOL transferidos en este proceso, lo que impidió que estos tokens, que deberían haber sido lanzados y bloqueados en liquidez, se lanzaran a tiempo.
Análisis de víctimas
Es importante destacar que la plataforma de préstamos relámpago no sufrió pérdidas, ya que el préstamo relámpago se devolvió dentro del mismo bloque. Además, los proyectos de tokens que ya se han lanzado en intercambios descentralizados y han bloqueado la liquidez también deberían no haberse visto afectados.
Los verdaderos perdedores son aquellos usuarios que compraron tokens en una piscina que aún no estaba completamente llena antes de que ocurriera el ataque. Los tokens SOL que invirtieron fueron transferidos por los atacantes, lo que también explica por qué se estimó inicialmente que las pérdidas ascendían a 80 millones de dólares (aunque los datos más recientes muestran que la pérdida real es de aproximadamente 2 millones de dólares).
Investigación de las causas de las vulnerabilidades
Aparentemente, este incidente expone la grave negligencia del equipo de Pump en la gestión de permisos. Podemos suponer que el control de la llenado del fondo era originalmente una de las responsabilidades del atacante.
Al igual que las prácticas de otros proyectos, como una plataforma de redes sociales que en sus inicios podría utilizar robots oficiales para simular la actividad comercial, podemos atrevernos a suponer que Pump, para lograr un arranque en frío, podría haber contratado a hackers para usar los fondos del proyecto para llenar la piscina de nuevos tokens emitidos (muy probablemente muchos de estos tokens son emitidos por el propio equipo del proyecto), con el objetivo de que estos tokens pudieran lanzarse sin problemas y generar interés. Lamentablemente, esta estrategia se convirtió finalmente en la raíz de una vulnerabilidad de seguridad.
Lecciones aprendidas
Para los equipos que desean replicar el modelo de proyectos exitosos, simplemente imitar la superficie no es suficiente. Para atraer a los usuarios a realizar transacciones, también se necesita proporcionar un impulso inicial.
El equipo del proyecto debe dar una gran importancia a la gestión de permisos y a las medidas de seguridad. La asignación razonable de permisos, así como la revisión y actualización periódica de las políticas de seguridad, son clave para garantizar la operación segura del proyecto.
Al realizar intentos de innovación, es necesario considerar de manera integral los riesgos potenciales y establecer un mecanismo de control de riesgos completo.
Los usuarios deben mantenerse alerta al participar en nuevos proyectos, comprender plenamente los riesgos del proyecto y evitar seguir ciegamente la tendencia.
Este incidente nos recuerda una vez más que en el rápido desarrollo del campo de las criptomonedas, la seguridad siempre es un factor primordial a considerar. Tanto los proyectos como los participantes deben mantenerse alerta en todo momento y trabajar juntos para mantener el desarrollo saludable del ecosistema.