Primera versión | Uso compartido de productos secos: explotación y análisis de vulnerabilidades de billetera cifrada

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. 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). 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. Esta es una interfaz de billetera web típica, 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 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 2: Vulnerabilidad XSS reflejada en una billetera web alojada El segundo caso de estudio 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 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 todavía hay un problema, porque la verificación 2FA también se requiere al realizar transacciones de divisas. En este punto, los piratas informáticos no pueden restablecer 2FA ni desactivar 2FA, por lo que el atacante necesita encontrar una forma de eludir la verificación 2FA.Como se mencionó anteriormente, esta billetera tiene una función de sorteo de Twitter: cuando el usuario ingresa a esta interfaz de función, le preguntará qué tipo de moneda quiere regalar, cuánta moneda dar y cuántas personas para regalar. En esta captura de pantalla, puede ver que el usuario puede dar hasta 2 bitcoins. Cuando el usuario configura Después de registrarse en el evento de regalo, otras personas 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 pasar Reflective XSS, robar la sesión de la víctima, iniciar sesión en la cuenta de la víctima, crear mucho de 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 fabricante codifica en HTML la salida, lo que resuelve la vulnerabilidad XSS. También 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 un sistema operativo, aplicaciones que se ejecutan en Windows y Linux. ¿Qué marco hacen las billeteras de escritorio? Los ingenieros de seguridad de CertiK han estudiado 18 carteras de escritorio, incluidas QT (C++), Dot Net (C#), Java y las 15 restantes Se utiliza el marco Electron. El caso de esta parte La investigación 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. Después de cargar con éxito un archivo PHP webshell con la billetera, el ingeniero de seguridad de CertiK intentó 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. Al depurar una aplicación Electron, usar DevTools de Google Chrome es muy fácil. Las aplicaciones de Electron pueden ejecutarse directamente en el sistema operativo, ya que puede acceder a los módulos de Node.js, por lo que puede crear aplicaciones de escritorio más potentes que las aplicaciones web. En junio de este año, el equipo de seguridad de CertiK descubrió una vulnerabilidad de ejecución remota de código en la billetera de escritorio de Symbol y envió la vulnerabilidad al programa de recompensas por errores de Symbol

Tags：

Ethereum