Recientemente, la plataforma Pump sufrió un grave incidente de robo de fondos. Este artículo analizará en detalle los antecedentes del evento y discutirá las lecciones aprendidas.
Análisis del proceso de ataque
El autor de este incidente no es un hacker excepcional, sino muy probablemente un ex-empleado de Pump. Esta persona tenía acceso a una billetera de permisos utilizada para crear pares de negociación en una plataforma de intercambio descentralizada, a la que nos referimos como "cuenta robada". Mientras tanto, el grupo de liquidez de tokens en Pump que aún no cumple con los estándares de listado se conoce como "cuenta preliminar".
Los atacantes primero obtuvieron un préstamo relámpago a través de una plataforma de préstamos para llenar todos los pools de tokens que no cumplían con los estándares de listado. Normalmente, cuando el pool alcanza el estándar, el SOL en la cuenta preparatoria se transfiere a la cuenta robada. Sin embargo, los atacantes retiraron el SOL transferido en este proceso, lo que impidió que estos tokens, que deberían haberse listado y bloqueado la liquidez, se listaran a tiempo.
Análisis de víctimas
Según el análisis, 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 listados en la plataforma de intercambio descentralizada, debido a que su liquidez está bloqueada, también deberían estar a salvo.
Los que realmente sufrieron pérdidas son los usuarios que compraron tokens en todos los fondos no completos en la plataforma Pump antes del ataque. Sus SOL fueron transferidos en el ataque mencionado, lo que también explica por qué la cantidad de pérdidas inicialmente estimada era tan alta. Sin embargo, las últimas noticias indican que la pérdida real es de aproximadamente 2 millones de dólares.
Posibles razones por las que un atacante obtiene la clave privada
Sin duda, esto refleja una grave negligencia del equipo del proyecto en la gestión de permisos. Podemos suponer que llenar el fondo de tokens puede haber sido una de las responsabilidades laborales anteriores del atacante. Similar a algunas plataformas sociales en sus primeras etapas que usan bots oficiales para estimular la actividad comercial, Pump también puede haber encargado al atacante llenar el fondo de liquidez de los nuevos tokens emitidos con fondos del proyecto (muy probablemente incluyendo algunos tokens de prueba), para atraer atención y lograr un arranque en frío. Desafortunadamente, esto se convirtió finalmente en un punto de ruptura para una amenaza interna.
Lecciones aprendidas
Para los imitadores, simplemente copiar las funciones superficiales no es suficiente. Es importante darse cuenta de que desarrollar un producto por sí solo no atraerá automáticamente a los usuarios. En proyectos colaborativos, proporcionar un impulso inicial es crucial.
El equipo del proyecto debe dar gran importancia a la gestión de permisos y las medidas de seguridad. Este incidente ha resaltado nuevamente la gravedad de las amenazas internas, enfatizando la necesidad de establecer un mecanismo sólido de asignación y monitoreo de permisos.
Los usuarios deben mantenerse alerta al participar en plataformas emergentes, especialmente con respecto a proyectos que no han sido completamente verificados. La diversificación de inversiones, la investigación cuidadosa del trasfondo del proyecto y la atención a los comentarios de la comunidad son métodos efectivos para reducir riesgos.
La regulación de la industria y los mecanismos de autorregulación necesitan ser mejorados. La ocurrencia de eventos similares destaca la necesidad de fortalecer la autorregulación de la industria y establecer mecanismos de auditoría más estrictos.
Este incidente ha sonado la alarma para todo el ecosistema de criptomonedas, recordándonos que al perseguir la innovación, no podemos ignorar los principios básicos de seguridad y la gestión de riesgos. Solo encontrando un equilibrio entre la seguridad y la innovación, podremos fomentar el desarrollo saludable de la industria.
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.
17 me gusta
Recompensa
17
7
Republicar
Compartir
Comentar
0/400
PoetryOnChain
· hace1h
Un traidor es completamente RATS.
Ver originalesResponder0
StablecoinArbitrageur
· hace3h
literal pico alfa fuga... clásico exploit de administrador con permiso smh 2m desaparecido así de rápido
Ver originalesResponder0
DefiPlaybook
· hace5h
¿Los empleados del equipo están haciendo un Rug Pull y aprovechándose de los cupones de clip?
Ver originalesResponder0
ShitcoinConnoisseur
· hace5h
¿Se puede poner un topo? Es la conciencia del sector.
Ver originalesResponder0
MEVEye
· hace5h
Lo hizo un traidor.
Ver originalesResponder0
AltcoinOracle
· hace5h
ngl el modelo de seguridad de pump parece directamente medieval... los trabajos internos se están convirtiendo en el nuevo meta fr
Ver originalesResponder0
UncommonNPC
· hace5h
Resulta que aún son conocidos los que cometieron el crimen.
La plataforma Pump sufrió un robo interno de 2 millones de dólares, destacando la importancia de la gestión de permisos.
Detalles del incidente de robo de Pump
Recientemente, la plataforma Pump sufrió un grave incidente de robo de fondos. Este artículo analizará en detalle los antecedentes del evento y discutirá las lecciones aprendidas.
Análisis del proceso de ataque
El autor de este incidente no es un hacker excepcional, sino muy probablemente un ex-empleado de Pump. Esta persona tenía acceso a una billetera de permisos utilizada para crear pares de negociación en una plataforma de intercambio descentralizada, a la que nos referimos como "cuenta robada". Mientras tanto, el grupo de liquidez de tokens en Pump que aún no cumple con los estándares de listado se conoce como "cuenta preliminar".
Los atacantes primero obtuvieron un préstamo relámpago a través de una plataforma de préstamos para llenar todos los pools de tokens que no cumplían con los estándares de listado. Normalmente, cuando el pool alcanza el estándar, el SOL en la cuenta preparatoria se transfiere a la cuenta robada. Sin embargo, los atacantes retiraron el SOL transferido en este proceso, lo que impidió que estos tokens, que deberían haberse listado y bloqueado la liquidez, se listaran a tiempo.
Análisis de víctimas
Según el análisis, 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 listados en la plataforma de intercambio descentralizada, debido a que su liquidez está bloqueada, también deberían estar a salvo.
Los que realmente sufrieron pérdidas son los usuarios que compraron tokens en todos los fondos no completos en la plataforma Pump antes del ataque. Sus SOL fueron transferidos en el ataque mencionado, lo que también explica por qué la cantidad de pérdidas inicialmente estimada era tan alta. Sin embargo, las últimas noticias indican que la pérdida real es de aproximadamente 2 millones de dólares.
Posibles razones por las que un atacante obtiene la clave privada
Sin duda, esto refleja una grave negligencia del equipo del proyecto en la gestión de permisos. Podemos suponer que llenar el fondo de tokens puede haber sido una de las responsabilidades laborales anteriores del atacante. Similar a algunas plataformas sociales en sus primeras etapas que usan bots oficiales para estimular la actividad comercial, Pump también puede haber encargado al atacante llenar el fondo de liquidez de los nuevos tokens emitidos con fondos del proyecto (muy probablemente incluyendo algunos tokens de prueba), para atraer atención y lograr un arranque en frío. Desafortunadamente, esto se convirtió finalmente en un punto de ruptura para una amenaza interna.
Lecciones aprendidas
Para los imitadores, simplemente copiar las funciones superficiales no es suficiente. Es importante darse cuenta de que desarrollar un producto por sí solo no atraerá automáticamente a los usuarios. En proyectos colaborativos, proporcionar un impulso inicial es crucial.
El equipo del proyecto debe dar gran importancia a la gestión de permisos y las medidas de seguridad. Este incidente ha resaltado nuevamente la gravedad de las amenazas internas, enfatizando la necesidad de establecer un mecanismo sólido de asignación y monitoreo de permisos.
Los usuarios deben mantenerse alerta al participar en plataformas emergentes, especialmente con respecto a proyectos que no han sido completamente verificados. La diversificación de inversiones, la investigación cuidadosa del trasfondo del proyecto y la atención a los comentarios de la comunidad son métodos efectivos para reducir riesgos.
La regulación de la industria y los mecanismos de autorregulación necesitan ser mejorados. La ocurrencia de eventos similares destaca la necesidad de fortalecer la autorregulación de la industria y establecer mecanismos de auditoría más estrictos.
Este incidente ha sonado la alarma para todo el ecosistema de criptomonedas, recordándonos que al perseguir la innovación, no podemos ignorar los principios básicos de seguridad y la gestión de riesgos. Solo encontrando un equilibrio entre la seguridad y la innovación, podremos fomentar el desarrollo saludable de la industria.