SlowMist: las billeteras MetaMask de los usuarios de iCloud encontraron ataques de phishing debido a su propia falta de conciencia de seguridad

[SlowMist: las billeteras MetaMask de los usuarios de iCloud encontraron ataques de phishing debido a su propia falta de conciencia de seguridad] Según las noticias oficiales, SlowMist publicó un breve análisis de las billeteras MetaMask de los usuarios de iCloud que encontraron ataques de phishing. Primero, los usuarios encontraron ataques de phishing debido a su propia seguridad El conocimiento insuficiente y la fuga de la contraseña de la cuenta de iCloud, el usuario debe asumir la mayor parte de la responsabilidad. Sin embargo, desde la perspectiva del diseño del producto de billetera, la aplicación MetaMask iOS en sí tiene fallas de seguridad.

MetaMask Android tiene android:allowBackup=\"false\" en AndroidManifest.xml para prohibir que el usuario y el sistema realicen una copia de seguridad de la aplicación, a fin de evitar que los datos de la copia de seguridad se restauren en otros dispositivos.

No se encuentra tal mecanismo en el código MetaMask iOS que prohíba que el sistema haga una copia de seguridad de los datos de la billetera (como los archivos KeyStore). De forma predeterminada, iCloud realizará automáticamente una copia de seguridad de los datos de la aplicación. Cuando un atacante malicioso obtiene información de permiso, como la contraseña de la cuenta de iCloud, el atacante puede restaurar los datos relevantes de la billetera de la aplicación MetaMask para iOS desde el iCloud de destino.

El equipo de seguridad de SlowMist ha probado y restaurado los datos a través de iCloud antes de abrir la billetera MetaMask. También es necesario ingresar la contraseña para verificar la billetera. Si la contraseña es menos compleja, puede ser descifrada.

Otras noticias:

Niebla lenta: las direcciones sospechosas relacionadas con Gemini han transferido más de 200 000 ETH en las últimas 5 horas: Golden Finance News, el monitoreo de niebla lenta muestra que la dirección relacionada con Gemini de intercambio de encriptación sospechosa (0xea3ec2a08fee18ff4798c2d4725ded433d94151d) se ha recopilado y transferido en las últimas 5 horas Se emitieron más de 200.000 ETH (más de 300 millones de dólares estadounidenses). [2022/7/19 2:22:08]

SlowMist: Esté alerta a la vulnerabilidad de ejecución remota de código Apache Log4j2 de alto riesgo: según SlowMist Security Intelligence, el código de ataque de vulnerabilidad de ejecución remota de código Apache Log4j2 apareció en la noche del 9 de diciembre. El exploit de esta vulnerabilidad no requiere ninguna configuración especial, tras múltiples verificaciones, Apache Struts2, Apache Solr, Apache Druid, Apache Flink, etc. Apache Log4j2 es un marco de registro de Java popular. Se recomienda que los intercambios, las billeteras y las partes del proyecto DeFi verifiquen si están afectados por vulnerabilidades y actualicen a la nueva versión lo antes posible. [2021/12/10 7:30:00]

SlowMist: el protocolo Cover fue pirateado debido a la diferencia en los parámetros de cálculo específicos de rewardWriteoff: el 29 de diciembre de 2020, el equipo de seguridad de SlowMist realizó un breve análisis de todo el proceso de ataque del protocolo Cover.

1. En el contrato Blacksmith del protocolo Cover, los usuarios pueden hipotecar tokens BPT a través de la función de depósito;

2. Después del primer retiro de depósito, el atacante actualizará el grupo a través de la función updatePool y usará accRewardsPerToken para registrar las recompensas acumuladas;

3. Posteriormente, las recompensas se asignarán a través de la función _claimCoverRewards y se registrarán mediante el parámetro rewardWriteoff;

4. Después de que el atacante se retira por primera vez, todavía queda una pequeña parte de BPT para la hipoteca;

5. En este punto, el atacante depositará por segunda vez y retirará las recompensas a través de ClaimRewards;

6. El problema radica en el cálculo específico de rewardWriteoff. El valor del Pool obtenido cuando el atacante realiza deposit-claimRewards por segunda vez se define como memoria. En este momento, el Pool obtenido en la memoria es el valor actualizado cuando el atacante retira por primera vez y realiza updatePool;

7. Dado que el valor del Pool obtenido en la memoria es antiguo, el accRewardsPerToken correspondiente al registro también es antiguo y se le asignará al minero;

8. Cuando se realiza un nuevo updatePool más tarde, dado que el lpTotal en el grupo se ha vuelto más pequeño después de que el atacante realiza el retiro por primera vez, el accRewardsPerToken obtenido al final será más grande;

9. En este momento, el accRewardsPerToken asignado por el atacante es antiguo y tiene un valor pequeño, y el valor obtenido durante el cálculo de la cancelación de la recompensa también será pequeño, pero el atacante usa el valor accRewardsPerToken actualizado del grupo al reclamar Recompensas;

10. Por lo tanto, debido a la diferencia entre los parámetros antiguos y nuevos al realizar cálculos de recompensa específicos, se calculará un valor mayor;

11. Entonces, al final, se acuñarán más tokens COVER adicionales al generar recompensas para el atacante en función de los resultados del cálculo, lo que dará como resultado la emisión adicional de tokens COVER. Los cambios específicos de la diferencia del parámetro accRewardsPerToken se muestran en la figura. [2020/12/29 15:58:07],