1

I'm currently learning how to discover web applications running on a machine using port scanning, vhost bruteforcing and directory fuzzing. When it comes to port scanning, there is one thing I can't wrap my head around.

Let's say I have scanned all ports on a host and discovered a HTTP service exposed. To validate it's indeed HTTP, I would send a GET request to that port and examine the response:

$ telnet <IP> 8080
Trying <IP>...
Connected to <IP>.
Escape character is '^]'.
GET / HTTP/1.1

HTTP/1.1 200 OK
Content-Type: text/html
<snip...>

But even if it is HTTP, can I be sure there aren't any virtual hosts configured that require the HTTP Host header field for the request to reach them?

Sven
  • 115
  • 3
  • There can be virtual hosts, and these can be hard to find. You can try common hostnames, inspect TLS certificates and search by IP using shodan or similar - although all these approaches have limitations. – paj28 Sep 24 '22 at 19:25
  • @paj28: Thank you for pointing me to additional techniques, I'll gladly check them out! – Sven Sep 24 '22 at 19:41

2 Answers2

1

... can I be sure there aren't any virtual hosts configured that require the HTTP Host header field for the request to reach them?

No you can't. In order to access a specific virtual host you must know the expected Host header, i.e. the expected domain name. With a non-matching header you usually get the default configuration only. This default configuration might be a dummy setup page or it might be real content - but in both cases there might be other content with different Host headers.

Apart from that, what you provided in your test isn't even a valid HTTP request, since HTTP/1.1 requires the Host header.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Thanks for the precise answer! Regarding the request: You are right, this is a mistake I made while typing the question. The requests I've send during my testing were indeed valid :-) – Sven Sep 24 '22 at 19:40
1

Try to find out which domain name(s) could be hosted on that server. Then you can attempt a zone transfer (either plain old AXFR or "DNSSEC zone walking"). Most of the time, zone transfers won't be allowed, but not always so you should try. Otherwise there are brute force tools for this purpose.

The default page shown when accessing the webserver by IP address may provide some clues. Also try https on port 443 and inspect the presented certificate.

Try to trigger errors on the server (4xx and 5xx range).

Look at the response headers carefully. The cookies too.

Look at the HTML source code - there may be embedded resources (images etc) exposing domain names in URLs.

Kate
  • 6,967
  • 20
  • 23