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. Descubrimos 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. 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 anterior al desbloqueo. La siguiente figura es el código para realizar esta 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 IOHK anunció el ajuste exitoso del parámetro k, mejorando aún más el grado de descentralización de Cardano: IOHK anunció el ajuste exitoso del parámetro k, mejorando aún más el grado de descentralización de Cardano. Según un comunicado emitido por la compañía, el ajuste ocurrió en la Época 234 de Cardano, el 6 de diciembre a las 21:44 UTC. De esta manera, IOHK busca fomentar la participación de la comunidad en grupos de participación más pequeños (menos de 65 millones de ADA). Hace unos días se le dijo a la comunidad que deberían usar la billetera Daedalus para asegurarse de que su participación en el grupo de participación esté saturada en más del 30%. (Crypto News Flash) [2020/12/7 14:28:07] 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. Lectura del almacenamiento local usando JavaScript 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 dos: Vulnerabilidad XSS reflejada en una billetera web alojada El segundo caso de estudio se refiere a 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 del usuario como en el primer caso. En este caso, nuestro plan es tratar de usar esta vulnerabilidad para secuestrar las cuentas de los usuarios. Cookie Después de que el usuario inicia sesión, su token de sesión es almacenado en la cookie "PHPSESSID", y la característica especial de esta billetera es que el token no tiene "HttpOnly". Si la cookie está configurada en HttpOnly, el navegador evitará que JavaScript acceda a la cookie. En otras palabras, puede evitar que los atacantes utilicen secuencias de comandos entre sitios (XSS) para robar el token de sesión en la cookie. 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 un ataque de secuencias de comandos entre sitios (XSS). Obtenga el token de sesión Después de eso, se puede usar para iniciar sesión en la cuenta de la víctima. Ahora que tiene el token de sesión, es hora de hacer una ola de saqueo. El objetivo final de piratear la billetera es en la mayoría de los casos para robar los fondos del usuario, pero aún hay un problema, porque la verificación 2FA también se requiere para las transacciones de divisas. En este punto, los piratas informáticos no pueden restablecer 2FA ni desactivar 2FA. Por lo tanto, los atacantes necesitan encontrar formas para omitir la verificación 2FA Omitir la verificación 2FA Como se mencionó anteriormente, esta billetera tiene una función de regalo de Twitter: cuando el usuario ingresa a esta interfaz de función, le preguntará qué tipo de moneda quiere regalar, cuánta moneda quiere dar de distancia, y cuántas personas quieren regalar. En esta captura de pantalla, puede ver que el usuario puede regalar hasta 2 bitcoins. Cuando el usuario ha configurado el evento de regalo, otras personas deben hacer clic para seguir, Aite 3 amigos y reenvía este tweet de regalo, siempre que completes estos pasos, puedes ir a recibir el premio. ¡Pero el problema es que esta función no requiere 2FA! Los atacantes pueden usar XSS reflejado para robar la sesión de la víctima, iniciar sesión en la cuenta de la víctima cuenta, crear muchas actividades de regalo, y luego reclamar las recompensas ellos mismos. De esta manera, se puede retirar todo el saldo de la cuenta de la víctima. El método de reparación es HTML la salida del fabricante. La codificación, que resuelve la vulnerabilidad XSS. En 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. Escritorio Una billetera es una aplicación que se ejecuta en los sistemas operativos de Apple, Windows y Linux. ¿Qué marco utilizan las carteras de escritorio? Los ingenieros de seguridad de CertiK han estudiado 18 carteras de escritorio, incluidas QT (C++), Dot Net (C#), Java One cada una y las 15 restantes Ele usado marco ctron. 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 fragmento de código a continuación. La billetera envía una solicitud HTTP POST al servidor y devuelve la URL de carga del archivo, "upload.php" es el código en el servidor que maneja las cargas de archivos. Ahora que sabemos que el servidor usa PHP detrás de escena, si podemos cargar un webshell de PHP al servidor y abrirlo en un navegador, podríamos ejecutar código de forma remota en el servidor. Carga de archivos Después de cargar con éxito un archivo PHP webshell con la billetera, los ingenieros de seguridad de CertiK intentaron acceder al archivo cargado en el navegador. Accedió con éxito al Webshell cargado y puede ejecutar comandos en el Webshell. También encontramos que el servidor de la billetera se ejecuta bajo el usuario "administrador", por lo que los comandos se pueden ejecutar con privilegios de "administrador". En este caso, el atacante tiene control total sobre el servidor y puede manipular los archivos subidos por otros usuarios. Sin embargo, dado que se trata de una billetera descentralizada, el servidor no almacena ninguna clave privada de usuario, por lo que esta vulnerabilidad no puede explotarse para comprometer directamente las cuentas de los usuarios. La solución es muy simple, los desarrolladores simplemente eliminaron la función de carga de archivos para que ya no tengan que preocuparse por este problema de seguridad. Esta es una buena idea, ya que las billeteras criptográficas deben mantener su funcionalidad lo más simple posible para evitar problemas de seguridad. A continuación, hablemos de la seguridad de la billetera Electron. Caso 2: ¿Cuál es la vulnerabilidad de ejecución remota de código del cliente de billetera de escritorio Electron? ¿Por qué usar Electron? Electron es un marco de software de código abierto que permite a los desarrolladores crear aplicaciones de escritorio multiplataforma utilizando HTML, CSS y JavaScript. La ventaja de usar Electron es que los desarrolladores pueden reutilizar el código de la aplicación web para crear aplicaciones de escritorio, lo que significa que no es necesario buscar otra biblioteca de código ni aprender un nuevo lenguaje de programación. Usar DevTools de Google Chrome es muy fácil al depurar aplicaciones de Electron.

Tags：

ADA