Análisis de incidentes de seguridad del proyecto Pump
Recientemente, ocurrió un incidente de seguridad en el proyecto Pump que resultó en la pérdida de una gran cantidad de fondos. Este artículo realizará un análisis en profundidad de las causas, impactos y lecciones aprendidas relacionadas con este evento.
Explicación detallada del proceso de ataque
Este ataque no fue llevado a cabo por hackers sofisticados, sino que probablemente fue obra de un ex-empleado del proyecto Pump. El atacante tenía acceso a la billetera de permisos utilizada para crear pares de comercio en Raydium, a la que llamamos "cuenta atacada". Al mismo tiempo, todos los fondos de Bonding Curve LP en Pump que aún no alcanzaron los estándares para estar en Raydium se denominan "cuentas en preparación".
El atacante primero solicita un préstamo a través de un préstamo relámpago para llenar todos los fondos de los grupos que no cumplen con los estándares 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 que se había transferido en este proceso, lo que impidió que estos tokens, que deberían haber cumplido con los requisitos de Raydium y bloqueado su liquidez, se lanzaran a tiempo.
Análisis de víctimas
Según el análisis, este ataque afectó principalmente a los siguientes grupos:
Antes de que ocurriera el ataque, todos los usuarios en los grupos de Pump que aún no estaban llenos. Los SOL comprados por estos usuarios fueron transferidos, lo que resultó en grandes pérdidas.
Los proyectos de tokens que ya están en línea en Raydium no deberían verse afectados, ya que su liquidez ya está bloqueada.
La plataforma que ofrece préstamos relámpago no ha sufrido pérdidas, ya que el préstamo se reembolsó dentro del mismo bloque.
Discusión sobre las causas del ataque
El incidente se atribuye principalmente a la negligencia en la gestión del equipo del proyecto. Es muy probable que los atacantes hayan estado a cargo de llenar el fondo de tokens, similar a las operaciones de mercado realizadas por algunos proyectos en las etapas iniciales para generar entusiasmo.
Se sospecha que el proyecto Pump pudo haber autorizado a los atacantes a utilizar los fondos del proyecto para llenar la piscina de nuevos tokens emitidos, con el fin de lograr un arranque en frío del proyecto y atraer atención. Esta práctica se convirtió finalmente en la fuente de una vulnerabilidad de seguridad.
Lecciones aprendidas
Estrategia de mercado en las primeras etapas del proyecto: simplemente imitar la forma superficial de otros proyectos no es suficiente. Los nuevos proyectos deben desarrollar una estrategia de promoción inicial razonable, en lugar de esperar que los usuarios participen de manera espontánea.
La importancia de la gestión de permisos: Una gestión de permisos estricta y medidas de seguridad son cruciales para la estabilidad a largo plazo del proyecto. Se deben revisar y actualizar regularmente los ajustes de permisos, especialmente después de la salida de empleados.
La necesidad de auditoría de código: realizar auditorías de código completas de manera regular para detectar y corregir a tiempo posibles vulnerabilidades de seguridad.
Preparación del plan de emergencia: elaborar un plan de respuesta a emergencias completo para poder actuar de manera rápida y efectiva en caso de un incidente de seguridad, minimizando así las pérdidas.
Transparencia en la comunicación con la comunidad: Comunicar de manera oportuna y transparente con la comunidad después de un evento de seguridad ayuda a mantener la confianza de los usuarios y la reputación del proyecto.
Este evento subraya nuevamente la importancia de la seguridad y la gestión de riesgos en el ámbito de las blockchain y las criptomonedas. Los proyectos deben priorizar la seguridad de los activos de los usuarios mientras buscan la innovación.
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
10
Compartir
Comentar
0/400
WhaleWatcher
· Hace20m
Otro que ha sido arruinado por un topo.
Ver originalesResponder0
JustAnotherWallet
· hace17h
Otra trampa interna
Ver originalesResponder0
AirdropBuffet
· 07-20 23:55
El equipo detrás del proyecto son fraudes de Schrödinger.
Ver originalesResponder0
MetaMisery
· 07-20 01:44
Entonces, ¿es un infiltrado de nuevo?
Ver originalesResponder0
tokenomics_truther
· 07-19 23:03
Un típico caso interno, jeje
Ver originalesResponder0
ProbablyNothing
· 07-19 23:02
El destino de los tontos inversores minoristas
Ver originalesResponder0
LadderToolGuy
· 07-19 23:00
Un infiltrado es imposible de prevenir.
Ver originalesResponder0
tx_pending_forever
· 07-19 22:52
Otra vez es un tomar a la gente por tonta y salir corriendo
Ver originalesResponder0
MetaverseLandlady
· 07-19 22:52
Ay, fortalecer la gestión del código.
Ver originalesResponder0
StablecoinArbitrageur
· 07-19 22:49
*ajusta las gafas* seguridad de aficionados... apuesto a que su ratio de Sharpe también era negativo
Análisis de incidentes de seguridad del proyecto Pump: errores operativos de personal interno provocan una gran pérdida de fondos
Análisis de incidentes de seguridad del proyecto Pump
Recientemente, ocurrió un incidente de seguridad en el proyecto Pump que resultó en la pérdida de una gran cantidad de fondos. Este artículo realizará un análisis en profundidad de las causas, impactos y lecciones aprendidas relacionadas con este evento.
Explicación detallada del proceso de ataque
Este ataque no fue llevado a cabo por hackers sofisticados, sino que probablemente fue obra de un ex-empleado del proyecto Pump. El atacante tenía acceso a la billetera de permisos utilizada para crear pares de comercio en Raydium, a la que llamamos "cuenta atacada". Al mismo tiempo, todos los fondos de Bonding Curve LP en Pump que aún no alcanzaron los estándares para estar en Raydium se denominan "cuentas en preparación".
El atacante primero solicita un préstamo a través de un préstamo relámpago para llenar todos los fondos de los grupos que no cumplen con los estándares 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 que se había transferido en este proceso, lo que impidió que estos tokens, que deberían haber cumplido con los requisitos de Raydium y bloqueado su liquidez, se lanzaran a tiempo.
Análisis de víctimas
Según el análisis, este ataque afectó principalmente a los siguientes grupos:
Antes de que ocurriera el ataque, todos los usuarios en los grupos de Pump que aún no estaban llenos. Los SOL comprados por estos usuarios fueron transferidos, lo que resultó en grandes pérdidas.
Los proyectos de tokens que ya están en línea en Raydium no deberían verse afectados, ya que su liquidez ya está bloqueada.
La plataforma que ofrece préstamos relámpago no ha sufrido pérdidas, ya que el préstamo se reembolsó dentro del mismo bloque.
Discusión sobre las causas del ataque
El incidente se atribuye principalmente a la negligencia en la gestión del equipo del proyecto. Es muy probable que los atacantes hayan estado a cargo de llenar el fondo de tokens, similar a las operaciones de mercado realizadas por algunos proyectos en las etapas iniciales para generar entusiasmo.
Se sospecha que el proyecto Pump pudo haber autorizado a los atacantes a utilizar los fondos del proyecto para llenar la piscina de nuevos tokens emitidos, con el fin de lograr un arranque en frío del proyecto y atraer atención. Esta práctica se convirtió finalmente en la fuente de una vulnerabilidad de seguridad.
Lecciones aprendidas
Estrategia de mercado en las primeras etapas del proyecto: simplemente imitar la forma superficial de otros proyectos no es suficiente. Los nuevos proyectos deben desarrollar una estrategia de promoción inicial razonable, en lugar de esperar que los usuarios participen de manera espontánea.
La importancia de la gestión de permisos: Una gestión de permisos estricta y medidas de seguridad son cruciales para la estabilidad a largo plazo del proyecto. Se deben revisar y actualizar regularmente los ajustes de permisos, especialmente después de la salida de empleados.
La necesidad de auditoría de código: realizar auditorías de código completas de manera regular para detectar y corregir a tiempo posibles vulnerabilidades de seguridad.
Preparación del plan de emergencia: elaborar un plan de respuesta a emergencias completo para poder actuar de manera rápida y efectiva en caso de un incidente de seguridad, minimizando así las pérdidas.
Transparencia en la comunicación con la comunidad: Comunicar de manera oportuna y transparente con la comunidad después de un evento de seguridad ayuda a mantener la confianza de los usuarios y la reputación del proyecto.
Este evento subraya nuevamente la importancia de la seguridad y la gestión de riesgos en el ámbito de las blockchain y las criptomonedas. Los proyectos deben priorizar la seguridad de los activos de los usuarios mientras buscan la innovación.