4

I am currently working on webapp pentest where I discovered a nice little Unrestricted File Upload vulnerability. The only (and big) problem is that I am unable to escalate this to a fully working remote web shell yet.

Basically, I am able to upload whatever content I want on the server (using the change Avatar picture feature). Important point, the uploaded file is stored at whatever.com/something/avatar/2.

It appears that the underlying technology is an Apache server running on CentOS and a JBoss servlet.

I tried to upload a JSP reverse shell which did not work I then read that for JBoss servlets war files should be used to deploye webpages also war files should be put into a specific /deploy folder. My issue here is that when I upload a file it always end up to be store at whatever.com/something/avatar/2.

Anyone has some suggestions which could help me to get a reverse web shell?

EDIT1:

When uploading a file I have to set Content-type to image/jpeg but the extension of the file can be set to whatever I want, so obviously, the only check is done on the Content-type.

EDIT2:

Request/response to upload a 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"

nope@nope.com
-----------------------------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"}

Request/response when accessing the uploaded file -- to properly display the response in the browser I just have to tamper with the returned Content-type header:

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
  • 1
    Do you only have access to a deployed war/webapp or do you have access to the JMX console? – Herringbone Cat Jan 16 '17 at 21:30
  • 1
    I only have acces to a deployed web app. – AresS31 Jan 16 '17 at 21:32
  • In that case my question becomes, " my problem is that the file I upload will always be store in whatever.com/something/avatar/2." Why can't it be named something.com.war? – Herringbone Cat Jan 16 '17 at 21:34
  • Where does the uploaded file map to on the OS? You're only specifying the external URL. Also, have you tried specifying previous directory for the filename? i.e. ../MyFile? – Steve Sether Jan 16 '17 at 21:40
  • 1
    I have no idea where does it map on the OS I am carrying a Pentest, I only have access to the web application, I have no visibility on the server/OS. – AresS31 Jan 16 '17 at 21:58
1

For an upload to be secure, it must have a number of restrictions, primarily these:

  1. Max upload file size
  2. Max upload count per IP/session per day
  3. Max total file bytes per IP/session per day
  4. Max total file bytes per day (all IPs)
  5. Specific server side target directory path
  6. Deny execution privileges on uploaded files
  7. Specific set of allowable MIME types
  8. Elimination of executable code embedded in media [1]

Restricting the extension type is irrelevant because that only relates to the default and preferred application associations, not networking. Any type of content can be placed in any file name regardless of its extension.

You wouldn't (if you want any level of security whatsoever) ever open a document originating from a public connection on a server with a browser or other client app.

MIME types can be synthesized at will by attackers too, which is why security measures must assume the worst. Thus 5-7 above. Items 1-4 are to reduce denial of server attack vulnerability and accidental storage overload or other site unavailability causes and risks.

Notes:

[1] Executable code can be eliminated by scanning for executable headers and server supported scripting languages or by decoding and re-encoding the media file in an unpredictable way.

  • Sure restricting the extension of the created file helps, for example it is much easier for an attacker to drop a .php file if it gets executed by the web server on request. Also the list of checks is not complete, it is usually also required to actually check (and re-encode) multi media files when they are to be served back to users and admins (to avoid a JPG file to contain a JS text which can be used for script injection) – eckes May 12 '17 at 9:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.