De EVM a Solana: cómo evitar estafas de phishing

Recientemente, un usuario publicó una historia sobre cómo perdió millones de RMB en activos a través del phishing en Solana. Según la descripción: hizo clic por error en el enlace enviado por la banda de phishing en la respuesta debajo del tweet del proyecto Maneki para ingresar al sitio web.

Lo que lo desconcertó fue que durante la interacción, el sitio web no parecía exigirle que realizara ninguna operación de autorización de token, y el hacker tuvo éxito directamente. Cuando se dio cuenta de que podría haber un problema con el sitio web y trató de transferir los tokens en su billetera para evitar ser robados, descubrió que las transacciones fallaron después de muchos intentos y ya no se podían transferir.

Debido a los limitados detalles proporcionados, no podemos reconstruir completamente lo que sucedió. Pero lo que es seguro es que el usuario perdió el control de la cuenta del token Maneki, por lo que el intento del usuario de transferir los activos en la billetera falló. Los usuarios acostumbrados a EVM pueden sentirse confundidos: ¿qué es este control de cuenta?

Esto se debe a que Solana adopta un método de implementación diferente al de la cadena EVM. Si continúa interactuando con Solana de acuerdo con los hábitos de uso en EVM y desea matar al funcionario actual con la espada de la dinastía anterior, sin duda enfrentará grandes riesgos. .

Si quieres jugar felizmente en Solana, debes comprender las características y los métodos de engaño de Solana. Con este fin, también hemos recopilado algunos métodos de ataque a Sol que son diferentes de EVM, con la esperanza de ayudar a los usuarios que no conocen Solana a evitar trampas.

1. Transferencia de propiedad de la cuenta simbólica

El protagonista de nuestro caso inicial se encontró con este tipo de ataque. En la billetera Solana, para cada token, habrá una cuenta separada (Cuenta Token), similar a la cuenta en RMB, la cuenta en dólares estadounidenses, etc. en nuestra tarjeta bancaria. son independientes entre sí y cada cuenta token también tendrá un atributo de propietario.

De forma predeterminada, el propietario de la cuenta token será designado como la billetera actual, pero esto no está codificado. Al llamar a la operación createSetAuthorityInstruction, se puede cambiar el propietario de la cuenta token. El usuario transfiere la propiedad de una determinada cuenta simbólica en la billetera a su billetera.

Una vez exitoso, incluso si el token todavía está en la billetera, el usuario no puede transferirlo, lo que no es diferente de que el token sea robado.

Debido al alto riesgo de esta operación, tanto las billeteras Phantom como @Backpack_CN interceptarán e indicarán el riesgo de la transacción, requiriendo una segunda confirmación de la transacción, a menos que el usuario insista en aprobar la transacción por la fuerza.

2. No se requiere autorización antes de negociar en Solana.

En EVM, si el contrato de phishing quiere transferir los tokens en la billetera de la víctima, el usuario debe autorizar el contrato de phishing en el contrato de phishing. El contrato de phishing autorizado puede iniciar una transacción para transferir los activos del usuario.

En Solana, aprobar no es autorización sino aprobación de transacciones. Si el usuario considera esto como el enlace de autorización del token, una vez aprobado, se enviará la transacción de phishing, lo que dificultará su almacenamiento.

Existe una situación más peligrosa: suponiendo que se induce al usuario a autorizar tokens en EVM, solo un token se ve afectado en este momento y otros tokens no autorizados no serán robados. Dado que Solana puede transferir tokens sin autorización siempre que el usuario lo apruebe, combinado con la tercera característica que se introducirá a continuación, puede causar grandes pérdidas a los usuarios.

3. Tenga cuidado de no verse inducido a transferir varios tokens.

El diseño de transacciones de Solana permite agregar múltiples subtransacciones a una transacción, y cada subtransacción puede completar una interacción, como transferir un determinado token. En comparación con la transferencia de tokens en EVM, cada token requiere una transacción separada para completarse. Esta característica de Solana brinda cierta comodidad.

Por ejemplo, puede haber algunos tokens con un valor muy bajo de menos de 1u en su billetera. Sol-incinerator aprovecha esta característica para permitir a los usuarios enviar y canjear pequeños tokens en la billetera a SOL en lotes sin necesidad de hacerlo. múltiples transacciones. Exchange consume mucho gas y ahorra tiempo de operación.

Hay ventajas y desventajas. Esta característica también brinda una gran comodidad a los piratas informáticos. Siempre que se engañe a un usuario para que confirme una transacción, todos los tokens, NFT e incluso SOL en la billetera del usuario pueden ser saqueados. Por lo tanto, si ve una transacción que contiene una gran cantidad de transferencias de TOKEN, tenga cuidado si los piratas informáticos están aprovechando esta característica para vaciar su billetera.

4. Firmas de transacciones fraudulentas

En el EVM, la firma del permiso es muy popular entre los grupos de phishing debido a su ocultación y al hecho de que no aparece en la billetera del autorizador. Actualmente, se utiliza en más de la mitad de los métodos de ataque de phishing. En el mundo de Solana existe un método similar: Durable Nonce.

Las características de Durable Nonce son similares a permitir que si un usuario firma una transacción sin saberlo, no perderá sus activos inmediatamente y no verá la transacción en su billetera, sino que almacenará la información de la transacción firmada. la banda de phishing, que luego enviará la transacción a la cadena de bloques. Las características de esta transacción fuera de línea son exactamente las mismas que las del permiso, y es igualmente peligrosa.

Dado que Solana puede simular los resultados de las transacciones, la legibilidad de Durable Nonce es mejor que la permitida y más fácil de identificar para los usuarios. Por lo tanto, para robar los activos de los usuarios con mayor facilidad, las bandas de phishing también combinaron Durable Nonce con actualizaciones de contratos, tratando de evitar las advertencias enviadas a los usuarios mediante simulaciones comerciales.

El sitio web de phishing primero utiliza un contrato normal sin transacciones maliciosas para interactuar con el usuario. En este momento, no hay ningún problema con la información presentada por la función de simulación de transacciones de la billetera.

Después de que el usuario aprueba, la banda de phishing que obtuvo la firma del usuario no tiene prisa por transmitir la transacción a la cadena, sino que espera un período de tiempo antes de actualizar el contrato a una versión que contiene código malicioso y finalmente transmite la transacción. transacción a la cadena El usuario de repente me encontré con que faltaba el activo, pero no hice nada porque era posible que la firma se hiciera hace unos días.

Este método de ataque actualizado está extremadamente oculto y es extremadamente dañino, y la función de simulación de transacciones actual no puede demostrar el riesgo por el momento. Por lo tanto, todavía necesitamos aumentar nuestra conciencia sobre la prevención y no confiar demasiado en los recordatorios del software de billetera y confiar ciegamente en los resultados de la simulación de transacciones.

Conclusión

Puede verse que las características funcionales mencionadas anteriormente se diseñaron originalmente para reducir el umbral de uso del usuario y proporcionar más comodidad. Nunca pensé que las nuevas tecnologías, como espadas de doble filo, también proporcionarían a los grupos de phishing métodos de ataque más diversos.

Justo antes de escribir este artículo, Solana lanzó dos nuevas funciones, Action y Blink. Mientras todos soñaban con estas dos funciones, algunas personas también advirtieron que las bandas de phishing podrían usar las nuevas funciones para cometer fraude.

La pesca en Solana tiene las características de operación con un solo clic y alto ocultamiento. La función de simulación de transacciones a veces no funciona debido a la inestabilidad de rpc y otras razones, por lo que no se puede confiar completamente en esta función.

Se recomienda que los usuarios calificados puedan interactuar con la billetera de hardware de Keystone, lo que equivale a agregar una confirmación adicional para evitar una confirmación rápida de las transacciones debido a impulsividad o retrasos.

Además, Keystone también analiza la transacción en el lado del hardware. Cuando falla la simulación de la transacción de la billetera de software, el lado del hardware aún puede analizar el contenido de la transacción y proporcionar la última línea de defensa.

La tecnología Blockchain está evolucionando a través del desarrollo y el cambio continuos. Nos preocupan los riesgos que conllevan las nuevas tecnologías, pero no podemos detenernos por esto. Las bandas de pescadores son como ratas que cruzan la calle y todos quieren golpearlas. Las empresas de seguridad también están iterando constantemente soluciones para nuevas amenazas.

Como usuario normal, recuerde siempre no dejarse deslumbrar por el "pastel gratis", sino comprobar cuidadosamente el contenido de la transacción. Con tanta conciencia de seguridad, será difícil que el phishing tenga éxito.