Recientemente, un usuario publicó sobre la pérdida de millones de RMB en activos debido a un ataque de phishing en Solana. Según la descripción, accidentalmente hizo clic en un enlace publicado por un grupo de phishing en un tuit del proyecto Maneki, lo que lo llevó a un sitio web fraudulento.

lo que lo desconcertó fue que, durante la interacción, el sitio web no parecía requerir ninguna operación de autorización de token, y el hacker logró robar los activos directamente. cuando se dio cuenta de que podría haber un problema con el sitio web e intentó transferir tokens desde su billetera para evitar el robo, descubrió que varios intentos de transferencia fallaron y ya no podía retirar sus activos.

debido a la limitada información proporcionada, no podemos recrear completamente la escena del incidente. Sin embargo, está claro que el usuario perdió el control de la cuenta de token maneki, lo que explica por qué los intentos de transferir activos desde su billetera fallaron. Los usuarios acostumbrados a EVM podrían estar confundidos acerca de lo que significa el control de la cuenta.

esto se debe a que Solana utiliza una implementación diferente de la cadena EVM. Continuar interactuando con Solana utilizando los hábitos de EVM es como usar una espada obsoleta para luchar en una batalla moderna, lo que conduce inevitablemente a riesgos significativos.

para disfrutar jugando en Solana, es esencial entender las características y tácticas fraudulentas de Solana. Por esta razón, hemos compilado algunos de los métodos de ataque en Solana que difieren de los de EVM, con la esperanza de ayudar a los usuarios no familiarizados con Solana a evitar contratiempos.

1. cucú en el nido: transferencia de propiedad de cuenta de token

el protagonista de nuestro caso inicial se encontró con este tipo de ataque. en una billetera solana, cada token tiene una cuenta separada (cuenta de token), similar a cómo una cuenta bancaria puede tener cuentas separadas para diferentes monedas como el RMB y el USD, que son independientes entre sí. cada cuenta de token también tiene un atributo de propiedad.

de forma predeterminada, el propietario de una cuenta de token se designa como la billetera actual. sin embargo, esto no está codificado de forma rígida. mediante la operación createsetauthorityinstruction, se puede cambiar la propiedad de la cuenta de token. los hackers utilizan esta operación para engañar a los usuarios y transferir la propiedad de una cuenta de token desde su billetera a la billetera del hacker.

una vez que tenga éxito, aunque las fichas aún estén en la billetera, el usuario no puede transferirlas, lo que es esencialmente lo mismo que tener las fichas robadas.

debido al alto riesgo de esta operación, tanto Phantom como @Backpack_CNlas carteras interceptan y advierten a los usuarios sobre los riesgos de la transacción, requiriendo una segunda confirmación para la transacción, a menos que el usuario insista en aprobarla.

2. no se requiere preautorización para transacciones en Solana

en EVM, un contrato de phishing necesita que el usuario autorice el contrato en el contrato de token antes de poder transferir tokens desde la billetera del usuario. El contrato de phishing solo puede iniciar la transacción para transferir los activos del usuario después de recibir la autorización.

sin embargo, en solana, "aprobar" no significa autorización, sino aprobación de transacción. si el usuario lo trata erróneamente como el paso de autorización y lo aprueba, la transacción de phishing se envía, dejando pocas posibilidades de recuperación.

una situación más peligrosa es si el usuario es engañado para autorizar tokens en EVM, solo el token autorizado se ve afectado, y otros tokens no autorizados permanecen seguros. en Solana, dado que no se requiere autorización y solo se necesita la aprobación del usuario para transferir tokens, combinado con el tercer punto que discutiremos a continuación, podría resultar en pérdidas significativas para el usuario.

3. tenga cuidado de ser inducido a transferir múltiples tokens

El diseño de transacción de Solana permite incluir múltiples subtransacciones en una sola transacción, siendo cada subtransacción una interacción completa, como transferir un token específico. En comparación con EVM, donde transferir cada token requiere una transacción separada, esta característica de Solana proporciona cierta comodidad.

por ejemplo, su billetera podría contener algunos tokens con un valor muy bajo, menos de 1 usd. sol-incinerator utiliza esta característica para permitir a los usuarios enviar lotes de tokens de pequeño valor desde su billetera y convertirlos de vuelta a sol sin necesidad de múltiples conversiones, lo que consumiría mucha gas y ahorraría tiempo operativo.

si bien esta función proporciona comodidad, también facilita en gran medida las actividades de pirateo. si un pirata informático logra engañar a un usuario para que confirme una transacción, puede vaciar la billetera del usuario de tokens, NFT e incluso sol. por lo tanto, si ves una transacción que implica la transferencia de muchos tokens, ten cuidado, ya que podría ser un pirata informático que intenta vaciar tu billetera utilizando esta función.

4. robo de firmas de transacción

en el ecosistema de EVM, las firmas de permiso son favorecidas por grupos de phishing debido a su sigilo y al hecho de que no aparecen en la billetera del autorizador. Actualmente, más de la mitad de los ataques de phishing utilizan este método. En el mundo de Solana, existe un método similar: nonce duradero.

Las funciones de nonce duraderas funcionan de manera similar a permitir. si un usuario firma una transacción sin saberlo, no perderá inmediatamente activos ni verá esta transacción en su billetera. En cambio, la información de transacción firmada se envía al grupo de phishing, que luego presenta la transacción a la cadena de bloques. Esta característica de transacción sin conexión es tan peligrosa como permitir.

Dado que Solana puede simular resultados de transacciones, el nonce duradero es más legible que el permiso, lo que facilita a los usuarios identificarlo. Sin embargo, los grupos de phishing han combinado el nonce duradero con actualizaciones de contrato para robar activos de manera más efectiva mientras evitan las advertencias de simulación de transacciones.

los sitios web de phishing primero interactúan con los usuarios utilizando contratos normales sin transacciones maliciosas. La función de simulación de transacciones de la billetera no muestra problemas en esta etapa. Una vez que el usuario aprueba la transacción, el grupo de phishing no la transmite de inmediato a la cadena de bloques. En cambio, esperan y luego actualizan el contrato a una versión con código malicioso antes de transmitirlo. El usuario luego descubrirá repentinamente que sus activos han desaparecido, a menudo días después de firmar la transacción.

este método de ataque actualizado es extremadamente sigiloso y dañino. Las funciones actuales de simulación de transacciones no pueden mostrar este riesgo. Por lo tanto, es crucial mantener una alta vigilancia y no depender demasiado de las advertencias del software de billetera ni confiar ciegamente en los resultados de la simulación de transacciones.

conclusión

El propósito original de estas características era reducir las barreras para los usuarios y proporcionar más comodidad. Sin embargo, como una espada de doble filo, las nuevas tecnologías también han proporcionado a los grupos de phishing una gama más amplia de métodos de ataque.

justo antes de escribir este artículo, solana lanzó dos nuevas características: acción y blink. mientras hay mucha anticipación en torno a estas características, algunos también han advertido sobre el potencial de grupos de phishing para explotarlas.

El phishing en Solana se caracteriza por operaciones de un solo clic y alta sigilosidad. Debido a la inestabilidad de RPC y otras razones, las funciones de simulación de transacciones no siempre pueden funcionar, por lo que no se puede confiar completamente en ellas.

Se recomienda a los usuarios que tengan los medios utilizar una cartera de hardware Keystone para las interacciones. Esto añade una capa adicional de confirmación, evitando transacciones de confirmación rápida causadas por impulsos o clics accidentales.

además, Keystone analiza las transacciones en el extremo del hardware. En casos en los que las simulaciones de transacciones de la billetera de software fallan, el hardware aún puede analizar el contenido de la transacción, proporcionando la última línea de defensa.

La tecnología blockchain está en constante evolución y transformación. Si bien nos preocupa los riesgos asociados con las nuevas tecnologías, no podemos permitirnos dejar de progresar. Los grupos de phishing son como plagas que todos quieren eliminar, y los profesionales, incluidos los fabricantes de monederos hardware y las empresas de seguridad, están desarrollando continuamente soluciones para contrarrestar las nuevas amenazas.

como usuarios comunes, es esencial recordarnos a nosotros mismos que no nos dejemos seducir por los "regalos gratuitos", sino que examinemos detenidamente los detalles de la transacción. Con este nivel de conciencia de seguridad, los intentos de phishing son mucho menos probables de tener éxito.

descargo de responsabilidad：

1. este artículo ha sido reimpreso de [Keystone]. todos los derechos de autor pertenecen al autor original [keystone]. si hay objeciones a esta reimpresión, por favor contáctenos Gate learnequipo y ellos lo resolverán rápidamente.
2. exención de responsabilidad: las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. las traducciones del artículo a otros idiomas son realizadas por el equipo de aprendizaje de Gate. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.