Primera versión | Análisis de vulnerabilidad: el peligro de una configuración incorrecta de la herramienta de código abierto CORS-anywhere software de terceros

Durante una prueba de penetración de aplicaciones web reciente, el equipo técnico de CertiK descubrió una vulnerabilidad grave e inesperada. Después de obtener el permiso del cliente, escribimos este descubrimiento en este artículo para compartirlo, a fin de ayudar a los desarrolladores relevantes a evitar los mismos errores en el futuro. La aplicación web de destino es un navegador de cadena de bloques, que tiene funciones como la búsqueda de información de bloques, la búsqueda del historial de transacciones y los contratos inteligentes implementados. El front-end de la aplicación está escrito en React, un marco web que está bien protegido contra ataques como XSS (cross-site scripting) e inyección de HTML. En términos de implementación, el JavaScript front-end obtiene periódicamente nuevos datos de bloque de la API RPC de blockchain. Debido a que una cadena de bloques es una aplicación simple, no hay servidores back-end "tradicionales", no requiere autenticación ni autorización, y no es necesario manejar grandes cantidades de entradas de usuarios. Entonces, en general, es difícil encontrar vulnerabilidades graves en las aplicaciones de exploración de blockchain. Sin embargo, durante las pruebas de penetración, el equipo de CertiK encontró algunas anomalías con respecto a las URL de solicitud utilizadas para obtener datos de bloques. La URL se ve así: https://cors.x.y/http://load-balancer.us-east-1.elb.amazonaws.com/blocks/270865 Si mira de cerca, puede ver que la URL completa es dada por Consiste en dos URL conectadas de ida y vuelta. La "segunda" URL se parece al nombre DNS de un balanceador de carga de AWS, entonces, ¿a qué apunta la primera? Después de visitar solo la primera URL "https://cors.x.y", ingresa a la página predeterminada de una herramienta de código abierto llamada "CORS-anywhere". El equipo técnico de CertiK descubrió que la herramienta estaba mal configurada, lo que permitía el acceso a información confidencial. El siguiente texto explica más detalladamente los antecedentes y describe los hallazgos y otras investigaciones realizadas por el equipo técnico de CertiK. Antes de comprender los resultados de la encuesta, comprendamos CORS (intercambio de recursos de origen cruzado). Si tiene experiencia en desarrollo web, debe haber encontrado este tipo de errores innumerables veces: cuando una aplicación web solicita un recurso de un dominio, protocolo o puerto diferente al servidor donde se encuentra el recurso en sí, la aplicación web iniciará un Solicitud HTTP entre dominios. Si no hay un encabezado (referencia) "access-control-allow-origin" correcto en la respuesta, el navegador bloqueará la página web que inició la solicitud de origen cruzado y leerá el contenido devuelto por la solicitud de origen cruzado. En este artículo, los mecanismos SOP (Same Origin Policy) y CORS (Cross-Origin Resource Sharing) no se discutirán con demasiada profundidad. En resumen, SOP evita que JavaScript lea respuestas en solicitudes de origen cruzado, mientras que CORS es una forma de eludir las restricciones impuestas por la política del mismo origen. ¿De dónde provienen las solicitudes de origen cruzado en los navegadores de blockchain? ¿Por qué tenemos que lidiar con eso? En este caso, el fondo del explorador blockchain mencionado anteriormente es la cadena Cosmos. En Cosmos, la forma de interactuar con los nodos es utilizar la API JSON RPC (https://cosmos.network/rpc). El nombre de host del nodo generalmente lo asigna el desarrollador o el nombre DNS del balanceador de carga de aplicaciones de AWS. Si el nombre de host del explorador de blockchain es "explorer.mychain.com", y el nombre de host de la API de RPC es "api.mychain.com". Luego, cuando el navegador "explorer.mychain.com" realiza una solicitud a "api.mychain.com", se convierte en una solicitud de origen cruzado. Si no hay un encabezado CORS correcto, el navegador evitará que el sitio web de la aplicación lea la respuesta HTTP de la API de RPC. Actualmente hay muchas formas de resolver el problema de las solicitudes de origen cruzado, y se darán explicaciones al final del artículo. Para este explorador de blockchain, el equipo técnico de CertiK descubrió que utiliza una herramienta de proxy similar llamada "CORS-anywhere" como solución para manejar los encabezados de CORS. Por lo tanto, el equipo comenzó a investigar sobre "CORS-anywhere". CORS-anywhere es una herramienta de código abierto que brinda a los desarrolladores una forma de manejar solicitudes de origen cruzado. El repositorio del proyecto tiene más de 3 mil estrellas en Github, lo que es testimonio de su popularidad. "CORS -Anywhere es un proxy NodeJS  que agrega encabezados CORS a las solicitudes enviadas por proxy". Cierre de acciones A: el índice Blockchain 50 de la bolsa de valores de Shenzhen aumentó un 0,21 %: Jinse Financial News, las acciones A cerraron, el índice compuesto de Shanghái cerró en 3225,12 puntos, cerró con un aumento del 0,02 %, el índice de componentes de Shenzhen cerró en 13420,96 puntos, cerró con un aumento del 1,39 %, Distrito de la Bolsa de Valores de Shenzhen El índice Blockchain 50 reportó 3799.36 puntos, cerrando un 0.21%. El sector de la cadena de bloques cerró con una caída del 0,63 % y el sector de la moneda digital cerró con una caída del 0,55 %. [2020/11/2 11:26:27] Al comenzar a investigar esta herramienta, hubo una pregunta en Github (problema de Github) sobre los posibles riesgos de seguridad de CORS en cualquier lugar. Sobre este tema, el autor (Rob--W) dio su punto de vista. En resumen, su respuesta enumera 3 puntos principales: Denegación de servicio (Denial of Service) Suplantación de direcciones IP SSRF (Server Side Request Forgery) En las pruebas de penetración para aplicaciones web, lo más interesante es el último punto: la falsificación de solicitudes del lado del servidor. La falsificación de solicitud del lado del servidor (también conocida como SSRF) es una vulnerabilidad de seguridad web que un atacante puede explotar para engañar a una aplicación del lado del servidor para que realice una solicitud HTTP a un dominio arbitrario de la elección del atacante. En un ejemplo típico de SSRF, las acciones de un atacante pueden hacer que el servidor establezca una conexión consigo mismo o que establezca conexiones con otros sistemas de terceros externos o basados ​​en servicios web dentro de la infraestructura de la organización. Si quieres saber más sobre SSRF, puedes visitar la Referencia 8. Formas comunes de explotar las vulnerabilidades de SSRF Realice escaneos de puertos y reconocimiento de red en redes internas Envíe solicitudes a API de servidores internos Acceda a recursos confidenciales en redes internas Ahora que hay formas de realizar SSRF, ¿qué puede ganar usando SSRF? El servidor en la nube de AWSEC2 tiene un punto final especial: http://169.254.169.254/latest/meta-data/  Solo se puede acceder a este punto final dentro del servidor. Este punto de enlace contiene metadatos de la instancia de AWS, como el ID de la instancia, el nombre de host, la IP pública/privada y las credenciales de la función de AWS. Al buscar en Google, Y Combinator define http://169.254.169.254 como "la función más peligrosa de EC2". Si al servidor en la nube de EC2 se le asigna un rol de IAM (Administración de identidad y acceso), las credenciales correspondientes aparecerán en los metadatos. Con las credenciales de rol, hay privilegios de rol de IAM adjuntos al servidor en la nube de EC2. Por ejemplo, el rol de IAM tiene un rol denominado "aws-elasticbeanstalk-ec2-role". Este es el rol que se crea al iniciar el entorno con el servicio de Elastic Beanstalk. Según la documentación de AWS, este rol tiene acceso completo al repositorio s3. Si puede obtener las credenciales del extremo de metadatos, puede acceder al repositorio s3 en su organización. El servicio de metadatos del servidor en la nube de EC2 tiene dos versiones: IMDSv1 (Servicio de metadatos de instancia, versión 1); IMDSv2 (Servicio de metadatos de instancia, versión 1). Para IMDSv1, solo se requiere una solicitud GET para recuperar los metadatos de la instancia: Para IMDSv2, se debe crear un token de sesión que defina la duración de la sesión antes de que se puedan consultar los metadatos. Cree una sesión enviando una solicitud PUT a "http://169.254.169.254/latest/api/token". Luego, los metadatos se pueden solicitar utilizando el token devuelto por la solicitud PUT. En comparación con IMDSv1, IMDSv2 proporciona medidas de seguridad adicionales para proteger contra vulnerabilidades SSRF en aplicaciones web. En resumen, hay varias ventajas: los tokens deben obtenerse mediante solicitudes PUT, mientras que la mayoría de los ataques SSRF solo admiten métodos GET y POST. La solicitud PUT incluye un encabezado HTTP "X-aws-ec2-metadata-token-ttl-seconds". En un ataque SSRF, el atacante normalmente no puede insertar encabezados HTTP adicionales en la solicitud. Puede encontrar más información sobre las diferencias entre IMDSv1 e IMDSv2 en el blog de seguridad de AWS (Referencia 3). Como se mencionó anteriormente, CORS-anywhere se puede usar para realizar ataques SSRF y se implementa en servidores en la nube EC2, es hora de explotar esto. El equipo técnico de CertiK utiliza Elastic Beanstalk para lanzar un servidor en la nube EC2. Para facilitar la demostración, se supone que la URL para acceder a cors-anywhere implementada en el servidor en la nube de EC2 es http://cors.x.y: Utilización para IMDSv1: Es muy simple y directo para IMDSv1. El equipo técnico de CertiK envía una solicitud GET al servidor que implementa CORS en cualquier lugar para obtener las credenciales de AWS adjuntas con el rol de IAM. Explotación contra IMDSv2: estas credenciales se pueden usar para obtener acceso completo (lectura y escritura) a los repositorios de S3 y los registros de Cloudwatch. Debido a la popularidad de "CORS-where" y el uso intensivo de la nube de AWS. ¿Cuántos servidores en la nube EC2 sufren vulnerabilidades SSRF causadas por "CORS-wherewhere"? La página predeterminada de CORS en cualquier lugar genera automáticamente el contenido de la página para que los posibles piratas informáticos puedan encontrarlos más fácilmente, incluida esta primera línea: "Esta API permite solicitudes de origen cruzado en cualquier lugar". Entonces, el equipo técnico de CertiK usó dos motores de búsqueda, Shodan.io y Zoomeye, para encontrar dispositivos conectados a Internet y buscó instancias explotables. La página predeterminada de CORS-anywhere "Shodan" devuelve 6 resultados y "Zoomeye" devuelve 447 resultados. Para eliminar los falsos positivos y verificar aún más los resultados del motor de búsqueda, el equipo técnico de CertiK escribió scripts para confirmar que el host está en línea y puede acceder al servicio de metadatos con la ayuda de "CORS-anywhere". Finalmente, se encontró que un total de 100 servidores en la nube AWS EC2 en Internet serán atacados por SSRF debido a la implementación de CORS-anywhere. Pero debido a que no estaba autorizado, no siguió intentando recuperar las credenciales del rol de AWS. Durante la prueba de penetración de ZoomEye, el equipo técnico de CertiK explotó la vulnerabilidad SSRF en CORS, en cualquier lugar, utilizada por el navegador de la cadena de bloques para obtener las credenciales de la función EC2 y, por lo tanto, obtuvo acceso completo (lectura y escritura) al repositorio S3 de la empresa y el permiso de CloudWatch Logs. Pero no se realizó más penetración en la nube de AWS, ya que estaba fuera del alcance de la prueba de penetración. Puntos clave: 1.  Las vulnerabilidades en las aplicaciones web se pueden encontrar no solo en el front-end y back-end del sistema, sino también en la infraestructura. 2.  Antes de implementar herramientas de terceros en el sistema, opere con precaución y comprenda los posibles riesgos de seguridad. 3.  Las auditorías de seguridad y las pruebas de penetración, ya sea que las realice un equipo de seguridad interno o una empresa externa, son fundamentales para garantizar la seguridad del sistema. Los profesionales de la seguridad intentarán comprometer los sistemas desde la perspectiva de los piratas informáticos malintencionados, lo que ayudará a identificar y corregir las vulnerabilidades antes de que los piratas informáticos las exploten. 4. Comprender el modelo de responsabilidad compartida de AWS. Los clientes son responsables del software que se ejecuta en sus sistemas. No permita que el software mal configurado sea la clave para interrumpir su infraestructura en la nube. 5.  El servicio de metadatos en el servidor en la nube de AWS EC2 se puede cerrar: en AWS, el acceso al servicio de metadatos se puede cerrar deshabilitando el acceso al punto final HTTP del servicio de metadatos. Esto se puede hacer ejecutando el siguiente comando en la CLI de AWS: 6. Al comunicarse con la API RPC de Cosmos, hay una forma más segura de manejar las solicitudes de origen cruzado: especifique permitir "cors_allowed_origins" en config/config.toml valor del archivo de configuración. Configure la aplicación y la API RPC bajo el mismo nombre de host. Coloque un proxy inverso Nginx frente a sus servidores de nodo (cadena) para insertar encabezados CORS en las respuestas HTTP. Comuníquese con la API RPC usando WebSockets en lugar de HTTP. La moraleja de esta historia de pruebas de penetración es que, si bien se beneficia del valor y la funcionalidad del código de terceros, también debe asumir los riesgos y las vulnerabilidades de seguridad que puedan existir en él. En este servicio de pruebas de penetración, el equipo técnico de CertiK pudo capturar la vulnerabilidad antes de que los hackers maliciosos explotaran la vulnerabilidad SSRF. Pero no siempre tan afortunado. Por lo tanto, las auditorías, ya sea que utilicen directamente equipos de seguridad internos o externos, son fundamentales para identificar y mitigar los factores de riesgo y garantizar la seguridad del código y del usuario. El equipo de CertiK tiene una amplia experiencia y conocimientos en todos los aspectos de blockchain, diferentes lenguajes como Solidity, RUST y Go; varias plataformas como Ethereum, Cosmos y Substrate. Además, el equipo técnico de CertiK también es muy profesional en la cobertura de aplicaciones no específicas de blockchain, incluidas las pruebas de penetración de infraestructura, front-end y back-end. Si desea realizar una auditoría de seguridad exhaustiva del ecosistema de la cadena de bloques (incluidos los contratos inteligentes, la implementación del protocolo de la cadena de bloques subyacente y las aplicaciones de red, etc.), CertiK puede ayudarlo

Tags：

ETH