Exploiting PUT method for uploading WebShell

Introduce

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response code SHOULD be sent to indicate successful completion of the request. If the resource could not be created or modified with the Request-URI, an appropriate error response SHOULD be given that reflects the nature of the problem. The recipient of the entity MUST NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUST return a 501 (Not Implemented) response in such cases.
If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.
The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request — the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request is applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request. __w3.org

Weevely is a webshell management tool written in python. This article describes from basic to advance its most function on your penetration testing. Weevely is available on Kali Linux.

Penetration Testing

Information gathering

The first, I need to gather information about my target like services, port, web directory… On this post, I use Nessus to do this. I got http://192.168.1.9:8585/ directory

Go to http://192.168.1.9:8585/uploads directory

Vulnerability scanning

I like to use Nikto to enumerate attack vector. Using Nikto with command: nikto –host http://192.168.1.9:8585/uploads/

I found that “OSVDB-397: HTTP method ‘PUT’ allows clients to save files on the web server.”

Exploiting

Install poster add-on and run it

Generate webshell using weevely. Visit here for detail about weevely.

On poster add-on, set URL and File parameter, and click PUT button

Enjoy…

Demo