ownCloud en el KEV: elusión de autenticación en WebDAV mediante URLs prefirmadas

CISA incorporó CVE-2023-49105 a su catálogo de vulnerabilidades explotadas conocidas (KEV). Se trata de una vulnerabilidad de ownCloud que permite acceder a archivos a través de la API WebDAV sin autenticación. Para quien gestiona un perímetro externo, la pregunta clave es sencilla: ¿existe alguna instancia de ownCloud accesible desde internet y, si existe, cuál es su configuración?

Cuando llega una alerta del KEV, la primera acción es determinar qué hay realmente detrás de las direcciones IP externas de la empresa. ownCloud suele desplegarse como servidor de archivos interno, pero a veces resulta que está expuesto hacia fuera, ya sea de forma directa o a través de un balanceador. Si el puerto 80 o el 443 está abierto y responde con un servicio ownCloud, ese nodo debe revisarse, aunque se diera por supuesto que solo era accesible desde la red corporativa.

Qué está roto exactamente

El boletín de ownCloud describe el problema como una elusión de autenticación en la API WebDAV mediante URLs prefirmadas. Normalmente, el acceso a recursos por WebDAV exige autorización: el cliente envía una solicitud y el servidor valida las credenciales. En este caso se encontró una ruta en la que una URL construida de forma específica permite saltarse esa comprobación.

• Versiones afectadas: ownCloud 10.6.0 hasta 10.13.0. La corrección se publica en 10.13.1.
• Puntuación CVSS asignada al problema: 9.8.
• Condiciones descritas por el proveedor: el atacante necesita conocer un nombre de usuario y el propietario de los archivos no debe tener configurada una signing key.

El resultado es un fallo de control de acceso: una solicitud puede llegar a los datos sin usuario ni contraseña. Según la descripción del proveedor, eso abarca leer, modificar y eliminar los archivos del usuario afectado, no el control del servidor en sí. Para un almacenamiento de archivos esto importa, porque el valor de los datos es mayor que la estabilidad operativa del sistema.

Por qué esto afecta al perímetro externo

ownCloud rara vez es el único servicio de una máquina, pero suele destacar por su respuesta característica a una solicitud HTTP. El problema aparece cuando un dominio o una dirección IP que debía permanecer interna pasa a ser pública. Las causas varían:

1. Un ingeniero configuró un reverse proxy para hacer pruebas y olvidó eliminar la regla de enrutamiento al terminar el trabajo.
2. El servicio se desplegó en un VPS para arrancar rápido un proyecto, el proyecto se cerró y la máquina siguió funcionando.
3. Un cambio de proveedor o una migración de red dejó accesible desde fuera una IP antigua a la que seguía apuntando un registro DNS, aunque antes estuviera detrás de NAT.

Cómo revisar su propio perímetro

Un ataque contra su infraestructura no puede reproducirse desde fuera en su nombre, pero los pasos siguientes ayudan a determinar si tiene activos vulnerables. Van de lo sencillo a lo más complejo.

Paso 1. Inventario de puertos abiertos

Empiece por la lista de todas las direcciones IP públicas que pertenecen a la organización. Si no dispone de una lista exacta, utilice fuentes OSINT pasivas o sistemas internos de monitorización que registren el tráfico entrante. Después realice un escaneo básico de los puertos 80/TCP y 443/TCP. El objetivo de esta etapa es encontrar los nodos que responden a tráfico web desde la red externa.

Conviene revisar algo más que las direcciones asignadas a los entornos productivos. El inventario debe incluir cuentas de nube, VPS, entornos de prueba antiguos, direcciones de balanceadores y dominios que siguen presentes en el DNS. Son precisamente los recursos temporales y olvidados los que con más frecuencia se salen del registro interno, aunque sigan respondiendo a solicitudes desde fuera.

Paso 2. Identificación de ownCloud

No todo servidor web es ownCloud, y hay que distinguirlo de otros sistemas de almacenamiento de archivos. Envíe una solicitud GET al directorio raíz de las IP encontradas. Observe el cuerpo de la respuesta y las cabeceras: busque cadenas que identifiquen la interfaz de ownCloud, por ejemplo <title>Log in · ownCloud</title> u otros elementos de interfaz equivalentes. También puede intentar solicitar archivos estáticos característicos de este producto. Si el archivo se devuelve con código 200 y el tipo MIME correcto, la probabilidad de estar ante ownCloud es muy alta.

Tenga en cuenta el hosting virtual. Una solicitud directa a la IP puede devolver una página por defecto, mientras que ownCloud solo es accesible con el valor correcto de la cabecera Host. Por eso los resultados del escaneo de IP deben contrastarse con los registros DNS y con los nombres indicados en la configuración del reverse proxy o del balanceador. Una redirección hacia otro nombre también debe seguirse hasta la respuesta final, en lugar de dar por vacía la dirección original.

También merece la pena mirar la versión. En algunas versiones de ownCloud, ciertos endpoints revelan el número de versión. Si consigue averiguarlo, contrástelo con el boletín de ownCloud para saber si entra en el rango afectado. Si la versión no se determina desde fuera, eso no demuestra que la vulnerabilidad no exista: la información habrá que obtenerla del sistema de gestión de paquetes, de la imagen de contenedor, del panel de administración o de la configuración del despliegue.

Paso 3. Evaluación de la configuración de URLs prefirmadas

Aquí empieza lo más importante y aparece de inmediato una limitación: no es posible comprobar de forma segura la presencia del exploit sin intentar utilizarlo. Cualquier intento de enviar una URL prefirmada mal formada puede quedar registrado por un sistema de seguridad —un WAF o un IDS— y disparar una alerta. Por eso la auditoría externa se reduce a una evaluación de riesgos:

1. ¿Hay acceso a archivos sin autenticación? Pruebe a solicitar rutas conocidas de la API WebDAV. Si en lugar de un error 401 Unauthorized recibe un listado de carpetas o una respuesta XML con datos, es una señal de alarma seria.
2. ¿Se utiliza HTTPS? Si la conexión va por HTTP, el tráfico se intercepta con facilidad y transmitir cualquier token o cookie de sesión deja de ser seguro. Pero incluso con HTTPS persiste el error lógico en la validación de la firma.
3. ¿Hay un WAF? Si en el camino hay un Web Application Firewall, puede bloquear patrones sospechosos en la URL. Sin embargo, las vulnerabilidades del KEV suelen explotarse con formatos de solicitud legítimos que el WAF deja pasar.

La comprobación de una ruta WebDAV conocida debe realizarse únicamente contra un nodo propio y sin tocar archivos de usuarios. Su tarea es ver la denegación de acceso esperada, no demostrar que se pueden leer datos. Si el resultado es ambiguo, es preferible establecer el estado de la corrección a partir de la versión del software y del boletín del proveedor, en lugar de ampliar la prueba externa hasta la explotación.

Si encuentra un ownCloud expuesto, asuma lo peor: es vulnerable mientras no se demuestre lo contrario. El parche debe aplicarse de inmediato, sea cual sea la configuración actual. Si la actualización no puede instalarse enseguida, conviene cerrar la ruta externa al servicio o restringir el acceso a una VPN o a la red interna hasta terminar el trabajo.

Dónde podría haberse roto la cadena

Veamos este incidente desde el punto de vista de la prevención. CVE-2023-49105 se conocía antes de entrar en el KEV. Aun así, una parte de los sistemas pudo quedarse sin corregir por las brechas entre el inventario de activos, la evaluación de vulnerabilidades y la operación de los servicios.

Punto de fallo uno: ausencia de auditoría periódica del perímetro externo

Muchas organizaciones conocen sus activos dentro de la DMZ, pero pierden visibilidad de los nodos que se sacaron hacia fuera para tareas de corta duración. Cuando el proceso de crear un nuevo servicio externo exige pasar por el área de seguridad, estos casos son menos frecuentes. Cuando cualquier ingeniero puede abrir un puerto en el balanceador sin registrarlo en el inventario, el riesgo aumenta.

La mera existencia de un registro de activos no resuelve el problema si nunca se contrasta con el estado observado de la red. La ficha puede decir que ownCloud solo es accesible internamente, mientras que la regla de publicación en el reverse proxy quedó activa después de las pruebas. Por eso el inventario debe comparar los datos administrativos con lo que realmente responde en las direcciones públicas y en los nombres de dominio.

Punto de fallo dos: priorización de parches

En un entorno donde cientos de servicios necesitan actualizaciones, un CVE que todavía no está en el KEV suele acabar al final de la cola. La aparición de una entrada en el catálogo KEV de CISA debería elevar automáticamente la prioridad al máximo. Si el sistema de gestión de vulnerabilidades no está integrado con el feed del KEV, el equipo pierde esa señal.

Además, asignar una prioridad alta no basta por sí solo. Para cada instancia encontrada hay que vincular la dirección externa, el responsable del servicio, la versión instalada y el estado de la corrección. De lo contrario, la tarea de actualización puede existir al margen del nodo realmente publicado y el equipo no podrá confirmar que cerró justamente la instancia visible desde internet.

Punto de fallo tres: la arquitectura del propio ownCloud

Los servidores de archivos son, por su naturaleza, objetivos de alto interés, porque contienen documentos confidenciales. Ubicar un servicio así en la zona de internet sin protección adicional —por ejemplo, autenticación de dos factores en el inicio de sesión, reglas estrictas de rate limiting y aislamiento de red— genera un riesgo excesivo. Incluso después de instalar la corrección, el acceso externo debería corresponder a una necesidad real: si WebDAV solo lo usan los empleados, no hace falta publicarlo para todo internet.

El resultado práctico de la comprobación no debería ser una simple lista de puertos abiertos, sino una relación de instancias de ownCloud con sus dominios y direcciones IP, versiones, responsables, forma de publicación externa y estado de actualización. Una relación así permite distinguir una corrección confirmada de una situación en la que el escaneo simplemente dejó de ver la página de inicio de sesión por un cambio de enrutamiento.