sarpantkeltiek/cve-2024-37010Exploit para el CVE-2024-37010: acceso al almacenamiento externo de otros usuarios y movimiento lateral
Exploit para CVE-2024-37010: acceso al almacenamiento externo de otros usuarios y movimiento lateral:
https://www.cert.ssi.gouv.fr/avis/CERTFR-2024-AVI-0753/
https://owncloud.com/security-advisories/insecure-direct-object-reference-in-external-storage
Owncloud convierte un servidor en una nube para almacenar archivos, como Google Drive. Esto permite a las empresas, por ejemplo, ofrecer una nube a sus empleados sin que sea gestionada por un tercero.
Si los administradores lo han configurado así, los usuarios también pueden conectar almacenamientos externos, como otras nubes, FTP o Google Drive, para centralizar los archivos en una única nube y, de este modo, facilitar la vida a los usuarios.
Una vez que hemos creado nuestro almacenamiento externo, podemos actualizar este formulario para cambiar, por ejemplo, el campo "Nombre de la carpeta". Cuando se actualiza el formulario, se envía una solicitud con el formulario completo en formato JSON. En este formulario, el campo «ID», al ser un número entero, es el identificador de nuestro almacenamiento externo, generado por el servidor cuando creamos el almacenamiento.
Imaginemos que otro usuario en Owncloud, por ejemplo el administrador, también tiene almacenamiento externo, con el ID «18».
Ahora, volvamos a ejecutar la solicitud de actualización del formulario como un usuario «normal_user», sin derechos especiales, pero cambiando el ID a 18, el almacenamiento externo del administrador.
![[images/req.png]](images/req.png)
Una vez enviada la solicitud, el servidor muestra un error 404 (4) y nos dice que no ha encontrado ningún almacenamiento con el ID que especificamos (5).
Sin embargo, cuando nos conectamos a la cuenta de administrador, esto es lo que vemos:
![[pwned_article.png]](images/pwned_article.png)
El almacenamiento del administrador ha sido actualizado.
Si volvemos a iniciar sesión como «normal_user», podemos ver que ahora tenemos acceso a «storage_pwned», el almacenamiento del administrador.
![[access.png]](images/access.png)
El usuario A ha conseguido actualizar el almacenamiento del usuario B y recuperar los derechos de acceso al mismo. Le recordamos que el usuario A NO debe modificar el host durante la solicitud de actualización, para no romper la configuración del usuario B y poder acceder así a los archivos de este último.
Este es el código utilizado para actualizar el almacenamiento externo.
![[Pasted image 20241016114714.png]](images/2.png)
En primer lugar, podemos ver que no hay ninguna verificación de los derechos del usuario que acaba de realizar la solicitud. El código no comprueba que el almacenamiento pertenezca al usuario que realiza la solicitud. Esto explica por qué «normal_user» pudo actualizar el almacenamiento del administrador.
En segundo lugar, podemos ver que en cada actualización, el código añade al usuario que acaba de realizar la solicitud a los usuarios autorizados a conectarse al almacenamiento, lo que explica por qué «normal_user» obtuvo mágicamente acceso al almacenamiento del administrador después de la actualización.
En este ejemplo, hemos visto cómo era posible que un usuario obtuviera acceso completo al almacenamiento externo de otro usuario y, por tanto, a sus archivos personales. Esto ya la convierte en una vulnerabilidad bastante crítica.
En esta fase, como puedes ver, este IDOR (Insecure Direct Object Reference) ya es una vulnerabilidad importante. Pero intentemos seguir explotándola para aumentar el impacto que podría tener.
Para ello, comprendamos el proceso de autenticación que realiza el servidor de Owncloud para el almacenamiento externo con el fin de recuperar archivos. En los sistemas de autenticación básica que utilizan un simple par usuario/contraseña, el servidor de la nube simplemente
![[Pasted image 20241017162909.png]](images/20241017162909.png)
Ahora, imaginemos que un atacante consigue actualizar esta configuración cambiando el host a una dirección que controla. Esto significa que el servidor de Owncloud enviará ahora las credenciales a esta nueva dirección, que está controlada por el atacante.
![[Pasted image 20241017163143.png]](images/20241017163143.png)
Esto es exactamente lo que podemos hacer gracias a nuestra vulnerabilidad.
Cuando repetimos la solicitud de actualización especificando el ID de almacenamiento de otro usuario, solo tenemos que cambiar el host indicando, por ejemplo, nuestro colaborador de Burp.
![[Pasted image 20241017163326.png]](images/20241017163326.png)
De este modo, cuando el usuario se reconecta, el servidor de Owncloud intenta autenticarse en nuestro colaborador enviándole las credenciales del usuario.
![[Pasted image 20241017163644.png]](images/20241017163644.png)
Mágicamente, el colaborador recibe la solicitud de autenticación del servidor de Owncloud con las credenciales codificadas en Base64.
![[Pasted image 20241017163945.png]](images/20241017163945.png)
Así que acabamos de recuperar las credenciales en texto claro del almacenamiento externo del administrador.
Para la autenticación en el almacenamiento externo, puedes usar tus propias credenciales de Owncloud para iniciar sesión, si usas la misma contraseña, por ejemplo. Al solicitar una actualización del almacenamiento externo, puedes especificar «password::sessioncredentials» en el campo «authMechanism».
El servidor de Owncloud guardará entonces nuestras credenciales en texto claro la próxima vez que nos conectemos y las transferirá a nuestro dispositivo de almacenamiento externo para la autenticación.
Así que ya puedes verlo venir...
Esto significa que un atacante también puede activar este mecanismo para el almacenamiento externo de otro usuario y transferir así las credenciales en texto claro de la sesión de Owncloud de la víctima a un host que controle, como acabamos de hacer.
Por lo tanto, CVE-2024-37010 permite a un atacante con una cuenta en un servidor Owncloud:
