Caricamento file illimitato su JBoss

5

Al momento sto lavorando su webapp pentest dove ho scoperto una piccola vulnerabilità Unrestricted File Upload . L'unico (e grande) problema è che non riesco ancora ad inoltrarlo a una shell Web remota completamente funzionante.

Fondamentalmente, sono in grado di caricare qualsiasi contenuto che voglio sul server (usando change Avatar picture feature ). Punto importante, il file caricato è memorizzato in whatever.com/something/avatar/2 .

Sembra che la tecnologia sottostante sia un server Apache in esecuzione su CentOS e un servlet JBoss.

Ho provato a caricare una shell inversa JSP che non funzionava. Poi ho letto che per i file di guerra dei servlet di JBoss dovrebbero essere usati per distribuire le pagine web anche i file di guerra dovrebbero essere messi in una cartella /deploy specifica. Il mio problema qui è che quando carico un file finisce sempre per essere memorizzato in whatever.com/something/avatar/2 .

Qualcuno ha qualche suggerimento che potrebbe aiutarmi a ottenere una web shell inversa?

EDIT1:

Durante il caricamento di un file devo impostare Content-type su image/jpeg ma l'estensione del file può essere impostata su qualunque cosa io voglia, quindi ovviamente l'unico controllo è fatto su Content-type .

EDIT2:

Richiesta / risposta per caricare un file:

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"}

Richiesta / risposta durante l'accesso al file caricato - per visualizzare correttamente la risposta nel browser Devo solo manomettere l'intestazione Content-type restituita:

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
    
posta AresS31 16.01.2017 - 22:05
fonte

1 risposta

1

Perché un caricamento sia sicuro, deve avere un numero di restrizioni, principalmente queste:

  1. Dimensione massima del file di caricamento
  2. Numero massimo di caricamenti per IP / sessione al giorno
  3. Numero massimo di byte di file per IP / sessione al giorno
  4. Numero massimo di byte di file al giorno (tutti gli IP)
  5. Percorso directory di destinazione lato server specifico
  6. Rifiuta i privilegi di esecuzione sui file caricati
  7. Set specifico di tipi MIME consentiti
  8. Eliminazione del codice eseguibile incorporato nel file multimediale [1]

Limitare il tipo di estensione è irrilevante perché si riferisce solo alle associazioni di applicazioni predefinite e preferite, non alla rete. Qualsiasi tipo di contenuto può essere inserito in qualsiasi nome di file indipendentemente dalla sua estensione.

Non vorresti mai (se desideri alcun livello di sicurezza) aprire un documento proveniente da una connessione pubblica su un server con un browser o un'altra app client.

I tipi MIME possono anche essere sintetizzati a volontà dagli aggressori, motivo per cui le misure di sicurezza devono assumere il peggio. Quindi 5-7 sopra. Gli articoli 1-4 servono a ridurre la vulnerabilità di attacco denial of server e il sovraccarico accidentale di storage o altre cause e rischi di indisponibilità del sito.

Note:

[1] Il codice eseguibile può essere eliminato eseguendo la scansione di intestazioni eseguibili e linguaggi di scripting supportati dal server o decodificando e ricodificando il file multimediale in modo imprevedibile.

    
risposta data 11.02.2017 - 05:06
fonte

Leggi altre domande sui tag