RCE via WebDav - Power Of PUT

Hello everyone, at first I want to thank you all for 1K family and I hope you guys are getting some knowledge from my blogs. I decided to write something interesting on 1K followers and luckily I found this material for the blog on vulnerability which I discovered in 2018.

Summary :

Remote code execution has many different types and the easiest way to achieve it is when a “WebDav” is enabled allowing PUT method.

What is WebDav ?

WebDav stands for Web Distributed Authoring and Versioning which is an extension of the Hypertext Transfer Protocol that allows clients to perform remote Web content authoring operations. It provides the ability to create a file or folder, edit a file in place, copy or move or delete a file on a remote web server. It uses port 80 for unencrypted access and port 443 for secure access. It enables users access to cloud files or files on a separate server in real time, without any problem of downloading, caching, editing and uploading.

If WebDav is enable and all rights are given publicly then any user on the internet can upload, delete and modify the files on the remote server which can lead to remote code execution.

What is Authorization request header ?

The HTTP Authorization request header contains the credentials to authenticate a user agent with a server. When you send a request to server to access a resource for which you don’t have a permission, the server respond back the 401 Unauthorized error. It happens because no credentials were provided while trying to access the restricted resource.

In WebDav, for security purpose developers uses authentication mechanism for accessing resource or to make changes on the server.

Syntax :

Authorization: Basic YWRtMW46cEBzJHdvcmQ=

Here Basic is the type of authorization and YWRtMW46cEBzJHdvcmQ= (adm1n:p@s$word) are the base64 encoded credentials

What is WWW-Authenticate response header ?

The HTTP WWW-Authenticate is response header that defines the authentication method that should be used to gain access to a resource.

Syntax :

WWW-Authenticate: Basic realm=”webdav”

Here Basic is the type of authorization and realm is a description of the protected area. If no realm is specified, developers often display a formatted hostname instead.

Description :

I found this remote code execution vulnerability via WebDav in 2018 on a private project. At first I did a directory brute forcing and found that /webdav directory with 401 Unauthorized status code. When I checked the response I found a response header WWW-Authenticate and found that it needs credentials to access. I searched on the google for default credentials of webdav and found that default credentials are jigsaw and jigsaw as user and password.

I used the Authorization header in the request with the base64 encoded (amlnc2F3OmppZ3Nhdw==) credentials jigsaw:jigsaw, but it failed. Then I found a blog where the credentials were wampp as user and xampp as a password. I again used the Authorization header in the request with base64 encoded (d2FtcHA6eGFtcHA=) credentials wampp:xampp and got 200 OK response.

The I manipulated the HTTP verb from GET to OPTIONS to check how many methods or HTTP verbs are allowed. I found that HTTP PUT verb is allowed with other HTTP verbs. At first I tried to upload a normal text file which got uploaded successfully. Then I uploaded a file with XSS payload and it fired the pop-up. So the last thing was to upload a PHP file for remote code execution and it worked perfectly.

How I found this vulnerability ?

2. Then I searched for default credentials of WebDav and found it was jigsaw as username and password

3. Then I encoded them in base64 but it didn’t work

NOTE : Using a command “which python” will tell whether the system is using python3 or python2.

15. I used a normal python reverse shell payload of pentestmonkey and got a reverse shell on my netcat listener

Why it happened ?

In my opinion,

Fault 1 : The password set for authorization was one of the default credentials used by webdav.

Fault 2 : The webdav was enabled and was publicly accessible.

Fault 3 : WebDav was allowing some dangerous methods like PUT, DELETE, COPY etc.

Impact :

Any user can easily upload file on the server which can lead to remote code execution because PUT method was allowed.

Mitigation :

There are few mitigations that could be taken into consideration are stop using default credentials, do not enable webdav and stop allowing dangerous methods like PUT.

NOTE : This vulnerability is not only limited to WebDav, you can also try this where APIs are used. Just capture the request and change the HTTP verb from GET to POST for checking how many methods are allowed.

Reference report : https://hackerone.com/reports/487656