Explotación y análisis de vulnerabilidades de billetera web y billetera de escritorio

Con el rápido desarrollo de la tecnología blockchain, los activos cifrados se han convertido gradualmente en uno de los métodos de inversión para el público. El rápido crecimiento de la escala de activos cifrados globales hace que la billetera sea una herramienta de gestión de activos indispensable para todos los propietarios de activos cifrados. En el campo del cifrado, las billeteras digitales están estrechamente relacionadas con los fondos, y cada vez más personas se dan cuenta de la importancia de la seguridad de las billeteras digitales. La 28ª conferencia DEF CON, conocida como la "Fiesta de Carnaval de los Hackers Globales", ha llegado a una conclusión exitosa recientemente. El 9 de agosto de 2020, Peiyu Wang y Minzhi He, ingenieros de seguridad de CertiK, pronunciaron un discurso en la Conferencia de seguridad de cadena de bloques DEF CON sobre el tema: informe temático Exploit Insecure Crypto Wallet (utilización y análisis de vulnerabilidad de billetera cifrada). Este artículo lo llevará a revisar las ideas de los ingenieros de seguridad de CertiK sobre la seguridad de las billeteras cifradas. Una billetera criptográfica es un dispositivo, programa o servicio que almacena claves privadas y/o públicas. Debido a que las criptomonedas son virtuales, las billeteras encriptadas no se pueden usar para almacenar monedas reales. Pero cuando hacemos una transacción, la billetera encriptada puede usar la clave privada del usuario para firmar la transacción y transmitirla en la cadena de bloques. Hay diferentes tipos de monederos criptográficos, como monederos de software y monederos de hardware. Esta charla se centrará en las billeteras web y las billeteras de escritorio. Speech Live Review: Encryption Wallet Introducción Esta es una interfaz típica de billetera web, que es nuestra billetera CertiK Deepwallet. Los usuarios pueden ver el saldo de la cuenta y la opción de enviar moneda en esta interfaz. Debido a que esta es una billetera basada en COSMOS, tiene una función de delegación. Cuando hablamos de seguridad de aplicaciones web, lo primero que viene a la mente son las diez principales vulnerabilidades de seguridad del Proyecto de seguridad de aplicaciones web abiertas (OWASP). Aquí hay algunas estadísticas sobre las 10 principales vulnerabilidades de seguridad del "OWASP Top 10" entre 27 billeteras web encuestadas por ingenieros de seguridad de CertiK. Los ingenieros de seguridad de CertiK encontraron ataques de secuencias de comandos en sitios cruzados (XSS) en 3 billeteras, y aquí se seleccionan 2 casos para el estudio de caso. La red experimental de Polkadot, Kusama, ha lanzado una página de introducción a la subasta de paracaídas: noticias del 7 de abril, la red experimental de Polkadot, Kusama, ha lanzado oficialmente una página web de subastas de paracaídas, que explica en detalle qué es la subasta de paracaídas de Kusama, cómo participar y más preguntas comunes. El mecanismo de subasta de paracaídas de Kusama se dividirá en 5 partes: el equipo primero carga su código de paracaídas y los parámetros relacionados, las ofertas se pueden abrir durante la subasta, la hora precisa del final de la subasta se determina mediante VRF (función aleatoria verificable) y la oferta del equipo ganador KSM se bloqueará (luego se podrá desbloquear), y el período de arrendamiento se puede extender a través de otra subasta cuando finalice el arrendamiento de parachain. [2021/4/7 19:55:51] Encontramos una vulnerabilidad de inyección SqI en una billetera descentralizada. Pero su base de datos solo contiene datos de transacciones.Dado que los datos de transacciones en la cadena de bloques se han hecho públicos, no tiene sentido usar la inyección Sql para robar datos. Dado que no hay forma de usar la inyección SqI para lograr la ejecución de código en segundo plano, en este caso, este ataque de inyección SqI tiene poco impacto práctico. Además, existe una laguna en la autoridad de acceso de una API en esta billetera descentralizada. Los usuarios no autorizados pueden manipular la configuración 2FA de otras personas, pero no hay forma de usar esta laguna para robar activos en las cuentas de otras personas. Muchas billeteras web carecen de encabezados de seguridad, como la Política de seguridad de contenido (CSP) y los encabezados "X-Frame-Options", que pueden hacer que la billetera sea vulnerable a los ataques de clickjacking (Clickjacking). Algunas billeteras todavía usan bibliotecas de JavaScript obsoletas y servidores Nginx/Apache con CVE, y estas vulnerabilidades no se pueden explotar directamente. Los ingenieros de seguridad de CertiK no han encontrado ningún monedero que procese datos en formato XML, ni ningún monedero que haya realizado operaciones de deserialización, por lo que no se han encontrado vulnerabilidades relacionadas con XXE ni con la deserialización. En cuanto a registros y monitoreo, no hay más información por el momento. Caso 1: vulnerabilidad DOM XSS de billetera web descentralizada Este es un caso de vulnerabilidad DOM XSS de billetera web descentralizada. Esta billetera admite un solo protocolo y tiene todas las funciones básicas de una billetera web. Anuncio | Loopring lanzó la versión web de la plataforma de negociación descentralizada de última generación basada en zkRollup: Loopring lanzó la versión web de la plataforma de negociación descentralizada de última generación basada en zkRollup, esta versión está basada en el protocolo Loopring 3.1.1 y se posiciona como beta pública Beta1. (Loopring) [2020/2/28] Función vulnerable Esta aplicación guardará la última ubicación de acceso: después de que el usuario desbloquee la billetera con la contraseña, volverá a la página antes de desbloquear. La imagen a continuación es para realizar este código de función . Si tiene experiencia probando aplicaciones web, sabe que existe una alta probabilidad de vulnerabilidades DOM XSS en este caso, que es el caso en este caso. DOM XSS DOM XSS requiere Fuente y Sumidero. El origen es donde la aplicación recibe datos que no son de confianza (entrada del usuario), que luego pasa al receptor. Cuando un usuario visita este vínculo, "ventana.ubicación.búsqueda" devolverá  "?returnTo=/validators", y luego "{returnTo}" contendrá "/validators". Sink es donde se procesan los datos no confiables de Source, por lo que Sink está aquí: "window.location.href", si el usuario ingresa "returnTo=/validators". La billetera vuelve a "/validadores", es decir, va a la página de validadores. Si ingresa "returnTo=javascript:alert(1)", aparecerá una ventana de alerta en el navegador. Las carteras Keystore y Password son carteras web descentralizadas. Después de que un usuario crea una cuenta o importa una cuenta, tanto Keystore como Password se almacenan en el almacenamiento local. Anuncio | La exención de la tarifa de transacción de la versión web móvil de ZB (ZB) finaliza hoy: el 28 de noviembre, ZB (ZB) lanzó la versión web móvil basada en la tecnología H5 y anunció una actividad sin tarifa de transacción de medio mes. El evento finalizará a las 14:00 hoy. La versión web móvil es una parte importante de Zhongbi (ZB) para mejorar el acceso y la experiencia de transacción de varios terminales inteligentes. Construye una matriz de clientes adaptable globalmente junto con terminales móviles iOS/Android, terminales de escritorio Windows/Mac y terminales web de navegador. , lo que permite a los inversores comerciar en cualquier momento y en cualquier lugar. [2019/12/12] Use JavaScript para leer el almacenamiento local JavaScript puede leer información en el almacenamiento local. En este caso, los datos de clave-valor aparecen como "Hello World" almacenados en el almacenamiento local. JavaScript puede ejecutar LocalStorage.getItem("Hello") para obtener "Mundo". Usando DOM XSS ¿Cómo usar la vulnerabilidad DOM XSS descubierta para robar Keystore y Password en el almacenamiento local? En esta URL a continuación, puede leer el contenido de Keystore y Password y enviarlo al servidor del hacker. En el registro del servidor del pirata informático, puede ver directamente el contenido y la contraseña del almacén de claves. Una vez en posesión de esta información, es equivalente a controlar la cuenta del usuario, puede iniciar sesión en su billetera y transferir dinero. Método de reparación El método de reparación del fabricante de la billetera web es que cada vez que el usuario desbloquea la billetera, la billetera web siempre será redirigida a la página de inicio personal, para no darle al atacante ninguna oportunidad de insertar código malicioso. Caso 2: Dinámica de vulnerabilidades XSS reflectantes en billeteras web alojadas | Fuga de datos a gran escala en Alemania Parte de los datos se han transferido a páginas web mediante blockchain: según un informe de China Youth Daily reimpreso por Chinanews, una fuente de datos a gran escala Se produjo una fuga en el evento de Alemania. Se divulgó la información privada de cientos de políticos, celebridades y periodistas, y también se publicaron en línea dos direcciones de correo electrónico y un número de fax de la canciller alemana Angela Merkel. Múltiples departamentos en Alemania han iniciado conjuntamente una investigación sobre el caso, con la participación de la Agencia Federal de Seguridad de Tecnología de la Información y la Oficina Federal de Policía Criminal, y el Centro Nacional de Ciberdefensa de Alemania coordinando toda la investigación. En la actualidad, Twitter y Google han respondido eliminando la cuenta, los blogs relacionados y los enlaces de búsqueda. Sin embargo, eliminar los datos filtrados de todas las plataformas es una tarea casi imposible. Parte de los datos se han cargado en la página web mediante blockchain, lo que evita que la información cargada se destruya o elimine. [2019/1/9] El segundo estudio de caso trata sobre una vulnerabilidad XSS reflejada en una billetera web alojada. Las billeteras web alojadas son servidores que administran todas las claves privadas. Para iniciar sesión en la aplicación de billetera, el usuario recibe una contraseña de un solo uso por correo electrónico. La billetera en este caso admite 16 monedas diferentes, tiene todas las funciones básicas de la billetera y una función adicional llamada "dar twitter". Funcionamiento de la API El formato de URL de la API es similar a "/API/{endpoint}", por ejemplo, la API para obtener información de transacciones del usuario es "/apiUser/cloudTrans". Si accede a un extremo de la API que no existe, como "/api/test", el servidor devolverá una página con un mensaje de error, como se muestra en la figura siguiente "No se puede analizar la solicitud". Además, encontramos que el contenido del enlace aparecía en la página devuelta por el servidor. Esto representa una señal: si no hay procesamiento o codificación de la entrada del usuario en segundo plano, puede ser atacado por Reflected XSS. alert(document.domain) Agregue el siguiente contenido después de la solicitud API de esta billetera: <svg+onload=alert(document.domain)>" La aplicación abrirá una ventana. Esta es una billetera web alojada, clave privada Es administrado por el servidor, por lo que es imposible robar directamente la información de los usuarios como en el primer caso. En este caso, nuestro plan es tratar de usar esta vulnerabilidad para secuestrar las cuentas de los usuarios. Noticias | La versión web y la aplicación de Bancor vuelven a estar en línea : Se informa que el intercambio Bancor publicó un tweet que dice que la versión web y la aplicación están nuevamente en línea, y el servicio de Bancor estuvo temporalmente fuera de línea durante 10 minutos antes.[2018/7/15] Cookie Después de que el usuario inicia sesión, su sesión El token se almacena en la cookie "PHPSESSID", y la característica especial de esta billetera es La razón es que este token no tiene "HttpOnly". Si la cookie está configurada en HttpOnly, el navegador evitará que JavaScript acceda a la cookie. En En otras palabras, puede evitar que los atacantes roben el token de sesión en la cookie a través de secuencias de comandos entre sitios (XSS). Obtenga el token de sesión Dado que no hay HttpOnly en el token de sesión en este caso, puede leer el contenido de la cookie y enviarlo a su propio servidor a través de secuencias de comandos entre sitios (XSS). Después de obtener el token de sesión, puede usarlo para iniciar sesión en la cuenta de Victim. Ahora que tiene un token de sesión, es hora de hacer un botín. El objetivo final de la piratería wallets es principalmente para robar fondos de los usuarios, pero hay un problema porque 2FA también se requiere para la verificación de transacciones de divisas. En este punto, el pirata informático no puede restablecer 2FA ni deshabilitar 2FA, por lo que el atacante necesita encontrar una manera de eludir la verificación 2FA. Omitir la verificación 2FA Como se mencionó anteriormente, esta billetera tiene una función de obsequio de Twitter: cuando el usuario Al ingresar a esta interfaz de función, le preguntará al usuario qué tipo de moneda quiere regalar, cuánta moneda quiere regalar y cómo. muchas personas a las que quieren regalar. En esta captura de pantalla, puede ver que el usuario puede regalar hasta 2 bitcoins. Cuando el usuario configura la actividad de regalo, Otros deben hacer clic para seguir, Aite 3 amigos y volver a publicar este tweet de regalo, siempre que se completen estos pasos, puede ir a recibir el premio. ¡Pero el problema es que esta función no requiere 2FA! Los atacantes pueden usar XSS reflexivo, robar la sesión de la víctima, iniciar sesión en la cuenta de la víctima, crear muchos actividades de regalo, y luego reclamar las recompensas usted mismo. De esta manera, se puede retirar todo el saldo de la cuenta de la víctima. El método de reparación El fabricante codifica la salida en HTML, lo que resuelve la vulnerabilidad XSS. Al mismo tiempo, configure "HttpOnly " para la cookie "PHPSESSID" que contiene el token de sesión. De esta manera, incluso si la aplicación es atacada por secuencias de comandos entre sitios, el atacante no puede robar directamente el token de sesión de la cuenta. La billetera de escritorio es una , que se ejecuta en Windows y Linux solicitud. ¿Qué marco utilizan las billeteras de escritorio? Los ingenieros de seguridad de CertiK estudiaron 18 carteras de escritorio, incluidas QT (C++), Dot Net (C#) y Java, y las 15 restantes utilizaron el marco Electron. Esta parte del estudio de caso explorará la vulnerabilidad de ejecución remota de código del servidor de la billetera de escritorio Dot Net y la vulnerabilidad de ejecución remota de código del cliente de la billetera Electron. Caso 1: Vulnerabilidad de ejecución remota de código del servidor de la billetera de escritorio Dot Net La siguiente sección analiza una vulnerabilidad de ejecución remota de código encontrada en la billetera de escritorio. Primero, permítanme presentarles los antecedentes: esta billetera es una billetera de protocolo único descentralizada, escrita en lenguaje C#, utilizando el marco Dot Net. Contiene muchas funciones comunes de billetera, como administración de cuentas, transferencia de transacciones e implementación/invocación de contratos inteligentes, etc. Más interesante aún, también permite a los usuarios cargar archivos en el servidor. Esta función no es común en las billeteras, por lo que decidimos investigar más a fondo esta función. Como se mencionó anteriormente, esta billetera se basa en Dot Net. Si el código no está ofuscado, es fácil obtener el código fuente a través de la descompilación. Este fue el caso de esta billetera de caso, por lo que pudimos restaurar su código fuente para un análisis más detallado. Análisis de código fuente estático Después de descompilar el archivo ejecutable, encontramos el código fuente que implementa la carga de archivos, como se muestra en el siguiente fragmento de código.

Tags：

AVAX