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.
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.
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.
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.
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.
Then 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 ?
- I found a webdav directory with 401 Unauthorized response status, WWW-Authenticate response header and an error message
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
4. Then I found another default webdav credentials in a blog
5. I again encoded it in base64 and this time they worked and I got 301 Moved Permanently response and following the redirection I got 200 OK response
6. I changed the HTTP verb from GET to OPTIONS for checking the allowed verbs and found many were allowed including PUT verb
7. I simply tried to upload a .txt file using PUT verb on the server and it was successful created
8. Then I uploaded .html file using PUT verb with XSS payload in request body and it got fired
9. Then I uploaded .php file using PUT verb with normal php payload in request body and it was successful
10. I again uploaded .php file using PUT verb with rce payload in request body and it gave me 204 No Content response
11. I visited the web page https://www.mytarget.com/webdav/Jerry.php and added ?JerryCommand=id as the parameter and it worked, I got remote code execution
12. Exploiting further I searched for reverse shell cheat sheet on pentestmonkey
13. Then I started a netcat listener on my machine
14. In next step I searched for python, is it using python or not
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.
Any user can easily upload file on the server which can lead to remote code execution because PUT method was allowed.
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 OPTIONS for checking how many methods are allowed.
Reference report : https://hackerone.com/reports/487656