Carga de archivos sin restricciones en JBoss

5

Actualmente estoy trabajando en la aplicación web pentest donde descubrí una pequeña vulnerabilidad Unrestricted File Upload . El único (y gran) problema es que todavía no puedo escalar esto a un shell web remoto que funcione completamente.

Básicamente, puedo cargar el contenido que quiera en el servidor (usando change Avatar picture feature ). Punto importante, el archivo cargado se almacena en whatever.com/something/avatar/2 .

Parece que la tecnología subyacente es un servidor Apache que se ejecuta en CentOS y un servlet de JBoss.

Intenté cargar un shell inverso JSP que no funcionó. Luego leí que, para los servlets de JBoss, los archivos war deberían usarse para desplegar páginas web. Los archivos war deberían colocarse en una carpeta específica /deploy . Mi problema aquí es que cuando subo un archivo, siempre termina siendo almacenado en whatever.com/something/avatar/2 .

¿Alguien tiene algunas sugerencias que podrían ayudarme a obtener un shell web inverso?

EDIT1:

Al cargar un archivo, debo establecer Content-type en image/jpeg , pero la extensión del archivo se puede establecer en lo que quiera, por lo que, obviamente, la única comprobación se realiza en el Content-type .

EDIT2:

Solicitud / respuesta para subir un archivo:

POST /something/profile/upload HTTP/1.1
Host: HOST
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Referer: REFERER
Cookie: JSESSIONID=COOKIE
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Content-Type: multipart/form-data; boundary=---------------------------18769807824524
Content-Length: 1541

-----------------------------18769807824524
Content-Disposition: form-data; name="email"

[email protected]
-----------------------------18769807824524
Content-Disposition: form-data; name="avatarImageUpload"; filename="cmd.war"
Content-Type: image/jpeg
Hello world

HTTP/1.1 200 OK
Date: Mon, 16 Jan 2017 17:26:12 GMT
Content-Type: text/html;charset=ISO-8859-1
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Length: 54

{"success":true,"fileUrl":"/something/profile/avatar/2"}

Solicitud / respuesta al acceder al archivo cargado: para mostrar correctamente la respuesta en el navegador, solo tengo que manipular el encabezado Content-type devuelto:

GET /something/profile/avatar/2 HTTP/1.1
Host: HOST
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: */*
Accept-Language: en-GB,en;q=0.5
Referer: REFERER
Cookie: JSESSIONID=COOKIE
Connection: keep-alive

HTTP/1.1 200 OK
Date: Tue, 17 Jan 2017 09:18:34 GMT
Content-Type: image/jpeg
Content-Length: 11
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive

Hello world
    
pregunta AresS31 16.01.2017 - 22:05
fuente

1 respuesta

1

Para que una carga sea segura, debe tener una serie de restricciones, principalmente las siguientes:

  1. Tamaño máximo del archivo de carga
  2. Recuento máximo de carga por IP / sesión por día
  3. Máximo total de bytes de archivos por IP / sesión por día
  4. Máximo total de bytes de archivos por día (todas las direcciones IP)
  5. Ruta del directorio de destino del lado del servidor específico
  6. Denegar privilegios de ejecución en archivos cargados
  7. Conjunto específico de tipos MIME permitidos
  8. Eliminación de código ejecutable incrustado en medios [1]

La restricción del tipo de extensión es irrelevante porque solo se relaciona con las asociaciones de aplicaciones predeterminadas y preferidas, no con la red. Cualquier tipo de contenido se puede colocar en cualquier nombre de archivo, independientemente de su extensión.

No (si desea cualquier nivel de seguridad) nunca abriría un documento originado desde una conexión pública en un servidor con un navegador u otra aplicación cliente.

Los atacantes también pueden sintetizar los tipos MIME a voluntad, por lo que las medidas de seguridad deben asumir lo peor. Así 5-7 arriba. Los elementos 1-4 son para reducir la negación de la vulnerabilidad de ataque del servidor y la sobrecarga de almacenamiento accidental u otras causas y riesgos de indisponibilidad del sitio.

Notas :

[1] El código ejecutable se puede eliminar al buscar encabezados ejecutables y lenguajes de scripts compatibles con el servidor o al decodificar y volver a codificar el archivo multimedia de forma impredecible.

    
respondido por el Douglas Daseeco 11.02.2017 - 05:06
fuente

Lea otras preguntas en las etiquetas