El error de Gitpod muestra que los entornos de desarrollo basados en la nube necesitan evaluaciones de seguridad
Los investigadores de la empresa de seguridad en la nube Snyk descubrieron recientemente una vulnerabilidad que habría permitido a los atacantes realizar la toma de control de la cuenta completa y la ejecución remota de código (RCE) en Gitpod, un entorno de desarrollo en la nube (CDE) popular. Los entornos de desarrollo basados en la nube son populares porque son más fáciles de implementar y mantener que en las instalaciones y prometen una mejor seguridad. Sin embargo, las organizaciones deben evaluar adecuadamente los riesgos de seguridad que pueden presentar los CDEs que son exclusivos de sus arquitecturas, especialmente porque la comunidad de seguridad no los ha estudiado muy de cerca.
“Al adoptar entornos de desarrollo basados en la nube, quedan muchas preguntas sin respuesta: ¿qué sucede cuando un espacio de trabajo IDE en la nube se infecta con malware? ¿Qué sucede cuando los controles de acceso son inadecuados y permiten el acceso entre usuarios o incluso entre organizaciones a los espacios de trabajo? ¿Qué sucede cuando un desarrollador deshonesto extrae propiedad intelectual corporativa de una máquina alojada en la nube fuera de la visibilidad del software corporativo de prevención de pérdida de datos o seguridad de punto final?”, dijeron los investigadores de Snyk en su informeque es parte de un proyecto más grande para estudiar la seguridad de los CDEs.
Los entornos de desarrollo integrado (IDE) tradicionales que se implementan localmente en estaciones de trabajo de desarrolladores individuales también pueden tener una gran cantidad de problemas de seguridad y vulnerabilidades. De hecho, los CDE son una gran mejora con respecto a los IDE tradicionales de muchas maneras: pueden eliminar la desviación de la configuración que ocurre con el tiempo en las estaciones de trabajo/laptops de los desarrolladores, pueden eliminar las colisiones de dependencia que ocurren cuando los desarrolladores trabajan en diferentes proyectos, y pueden ser ventanas para ataques porque los espacios de trabajo de CDE se ejecutan como contenedores y pueden ser de corta duración.
Si se encuentran vulnerabilidades en su software, es probable que el proveedor de CDE pueda proporcionar una solución más rápido de lo que una empresa tendría que proporcionar parches de seguridad a todas sus estaciones de trabajo y computadoras portátiles para desarrolladores que ejecutan un IDE tradicional. Por supuesto, los tiempos de respuesta de seguridad pueden variar entre los proveedores de CDE, por lo que las empresas deben elegir a su proveedor con cuidado al confiarles su infraestructura de desarrollo, incluido el código, los tokens de acceso, los secretos de producción y otra propiedad intelectual.
El secuestro de WebSocket entre sitios comúnmente mal entendido
La vulnerabilidad encontrada por Snyk, que el equipo de Gitpod solucionó en un día, se rastrea como CVE-2023-0957 y cae en una categoría de problemas conocida como secuestro de WebSocket entre sitios.
Un mecanismo de seguridad central integrado en los navegadores se conoce como Política del mismo origen (SOP). Esto evita que el código que se ejecuta en un sitio web lea información de otro sitio web en el que ha iniciado sesión un visitante. Dado que las solicitudes del navegador a un sitio, por ejemplo, el Sitio A, generalmente contienen cookies de sesión de un usuario, un Sitio B malicioso visitado por el usuario sin un SOP podría cargar un recurso del Sitio A y, por lo tanto, robar la cookie de sesión de un usuario del Sitio A.
El problema es que este mecanismo de defensa solo existe para HTTP, no para WebSocket, una tecnología de comunicación bidireccional que permite que un navegador intercambie datos con un servidor a través de una conexión persistente. «Si un protocolo de enlace WebSocket se basa únicamente en las cookies HTTP para la autenticación, un sitio web malicioso podría crear una instancia de una nueva conexión WebSocket a la aplicación vulnerable, lo que permitiría que un atacante envíe y reciba datos a través de la conexión», explicaron los investigadores de Snyk.
En otras palabras, si un usuario visita un sitio web malicioso y ese sitio web abre una conexión WebSocket en su nombre a otro servidor en el que está autenticado, el sitio web malicioso puede enviar comandos maliciosos a través de la conexión y recibir respuestas utilizando las cookies del usuario. Por este motivo, las conexiones WebSocket deben implementarse con autenticación adicional.
Cómo los investigadores explotaron el error Gitpod ahora corregido
La arquitectura de Gitpod consta de varios microservicios implementados en un entorno de Kubernetes, con espacios de trabajo de usuario implementados como pods efímeros. Los espacios de trabajo de Gitpod consisten en un componente de servidor escrito en TypeScript y una aplicación web de panel creada con React que se comunica a través de WebSocket con una API JSONRPC proporcionada por el servidor. El tablero es la interfaz con la que interactúa el desarrollador y donde puede importar un repositorio desde un proveedor de control de código fuente como GitHub. Una vez configurado, también se puede acceder al espacio de trabajo a través de SSH y HTTP utilizando subdominios dedicados bajo el dominio gitpod.io.
Los investigadores de Snyk verificaron que la implementación de Gitpod WebSocket no usaba autenticación adicional y que un atacante podía abrir una conexión WebSocket al espacio de trabajo desde un origen diferente. Sin embargo, otro mecanismo llamado cookies de SameSite implementado recientemente en los navegadores hizo que su ataque fuera ineficaz.
Las cookies de SameSite están pensadas como una defensa contra los ataques de falsificación de solicitudes entre sitios (CSRF), en los que un sitio web puede obligar al navegador de un usuario a realizar una solicitud a otro sitio web en nombre del usuario. Sin embargo, a diferencia del SOP, que verifica esquema + host (incluidos los subdominios) + puerto de origen, la política de SameSite solo verifica que el dominio sea el mismo.
SameSite se aplica a todas las cookies, incluidas las enviadas a través de WebSocket, lo que significa que un atacante necesitaría usar una página web maliciosa también alojada en gitpod.io para lanzar un ataque de secuestro de WebSocket entre sitios contra Gitpod. Debido a que a cada espacio de trabajo se le asigna su propio subdominio, los investigadores de Snyk tuvieron que encontrar una manera de servir un sitio web malicioso desde un espacio de trabajo de Gitpod que configuraron.
El editor de código predeterminado en los espacios de trabajo de Gitpod es VS Code (Visual Studio Code) y se expone a través de una interfaz basada en web. Entonces, los investigadores de Snyk intentaron eliminar el proceso de VS Code dentro del espacio de trabajo usando la CLI y vinculando un servidor web basado en Python al puerto que VS Code usaba previamente para servir su archivo HTML malicioso. Esto no funcionó porque un proceso de «supervisor» que supervisaba el área de trabajo reinició el área de trabajo.
Eventualmente, los investigadores descubrieron que si simplemente eliminan el proceso de VS Code pero no vinculan el puerto a otro proceso, el supervisor solo intentará reiniciar VS Code y no todo el espacio de trabajo. Esto les dio la idea de detener VS Code y reemplazarlo rápidamente con una versión parcheada que crearon y que sirve para su exploit a través del punto final de la API /version, que normalmente solo devuelve el número de versión de VS Code.
«Lo modificamos para devolver el tipo de contenido correcto de texto/html y el contenido de un archivo HTML», dijeron los investigadores. «Ahora hemos eliminado el proceso de Vscode, por lo que nuestros cambios recién introducidos se pueden cargar en una instancia de proceso de VS Code recién generada».
Finalmente, tenían un enlace a su sitio web malicioso ejecutándose en un espacio de trabajo dentro de Gitpod y en un subdominio de Gitpod. Ahora todo lo que tenían que hacer era enviar ese enlace al usuario de Gitpod de la víctima que había iniciado sesión en su propio espacio de trabajo y, cuando se visitaba, permitía que el exploit abriera una conexión WebSockets al espacio de trabajo de la víctima y métodos JSONRPC como getLoggedInUser, getGitpodTokens, getOwnerToken y addSSHPublicKey. El último método permite que un atacante agregue su propia clave SSH al espacio de trabajo de la víctima y garantice el acceso remoto persistente al espacio de trabajo a través de SSH.
Los investigadores de Snyk elogiaron a Gitpod por su rápido tiempo de respuesta y parche, pero agregaron que «a medida que los trabajos de desarrollador en la nube continúan creciendo en popularidad, es importante considerar los riesgos adicionales que se están introduciendo».
Derechos de autor © 2023 IDG Communications, Inc.
Hemos recibido este contenido de ciberseguridad de: CSO Online
Puedes encontrar la noticia original en el siguiente enlace: https://www.csoonline.com/article/3689692/gitpod-flaw-shows-cloud-based-development-environments-need-security-assessments.html#tk.rss_news
