1

I've just scanned a target and noticed that HTTP PUT is allowed.

So, just to verify I used nmap:

# nmap --script http-methods <IP>

Starting Nmap 7.25BETA2 ( https://nmap.org ) at 2016-11-11 15:05 CET
Nmap scan report for <IP>
Host is up (0.16s latency).
Not shown: 989 closed ports
PORT      STATE SERVICE
21/tcp    open  ftp
22/tcp    open  ssh
23/tcp    open  telnet
25/tcp    open  smtp
80/tcp    open  http
| http-methods: 
|   Supported Methods: GET HEAD POST PUT DELETE CONNECT OPTIONS PATCH PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK TRACE
|_  Potentially risky methods: PUT DELETE CONNECT PATCH PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK TRACE
111/tcp   open  rpcbind
139/tcp   open  netbios-ssn
199/tcp   open  smux
443/tcp   open  https
| http-methods: 
|   Supported Methods: GET HEAD POST PUT DELETE CONNECT OPTIONS PATCH PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK TRACE
|_  Potentially risky methods: PUT DELETE CONNECT PATCH PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK TRACE
995/tcp   open  pop3s
32768/tcp open  filenet-tms
MAC Address: <MAC> (VMware)

Nmap done: 1 IP address (1 host up) scanned in 10.47 seconds

Great. So that would mean that I can upload files using the HTTP PUT method.

I tried using curl:

# curl http://<IP>/ --upload-file ./test.html 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>403 Forbidden</TITLE>
</HEAD><BODY>
<H1>Forbidden</H1>
You don't have permission to access /test.html
on this server.<P>
<HR>
<ADDRESS>Apache/1.3.23 Server at 127.0.0.1 Port 80</ADDRESS>
</BODY></HTML>

and nmap again:

# nmap -p 80 <IP> --script http-put --script-args http-put.url'/',http-put.file='./test.html'

Starting Nmap 7.25BETA2 ( https://nmap.org ) at 2016-11-11 15:09 CET
Nmap scan report for <IP>
Host is up (0.15s latency).
PORT   STATE SERVICE
80/tcp open  http
MAC Address: <MAC> (VMware)

Nmap done: 1 IP address (1 host up) scanned in 7.10 seconds

So apparently PUT is allowed, but I can't use it. Am I doing something wrong or are there other safeguards in place, which I'm not aware of?

closed as off-topic by LvB, Steffen Ullrich, Matthew, HashHazard, Stephane Nov 14 '16 at 11:11

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "This question does not appear to be about Information security within the scope defined in the help center." – LvB, Steffen Ullrich, Matthew, HashHazard
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 4
    403 is not 405. PUT is allowed but you have to be logged in. – Z.T. Nov 11 '16 at 14:20
  • I see, thanks! I'm a bit stumped, because there's no user login apparent anywhere on the website. In fact it's just the apache Test Page. – SaAtomic Nov 11 '16 at 14:24
  • 1
    You wouldn't need a login screen to allow for log in - it might rely on people accessing from a specific IP address, or with a particular header (a known value in an Authorization header, for example). It could also be that the server supports it, but there aren't any handlers in place to accept PUT requests on the paths you're using. – Matthew Nov 11 '16 at 15:40
  • 1
    403 usually means that some logic disallows PUT in the server configuration. 405 means PUT is entirely disabled or unsupported. One logic to disallow PUT could be for example by only allowing PUT for 192.168.x.x. So 401 = you must use HTTP authentication to access. 403 = You are either deemed completely unauthorized (cannot authenticate to get authorized) or you need to authenticate "outside" of the HTTP protocol, for example via a login form, and 405 = function completely disabled, for everyone. – sebastian nielsen Nov 11 '16 at 21:27
  • Thanks guys! That was very helpful! Is there any way to test which authentication method is put in place, except test various approaches (e.g. access from different IPs, ..)? – SaAtomic Nov 14 '16 at 6:51
2

What you see in the nmap scan is the response to an OPTIONS request. It simply says that these are the things the webserver will accept (i.e. are not disabled).

That does not mean that the webserver has a means for implementing those requests; typically PUT/POST/DELETE will be handled by some sort of logic engine outside the webserver itself. Similar for the webDAV commands - but these will usually only be exposed where webDAV is explicitly installed (the webDAV module is an external component).

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