Configure "Host:" header when scanning web applications

Scanning / scan configuration
1

Hi everyone.

Using Greenbone Community on Debian 12, it works really fine, except for one problem though.

I know Greenbone is not a web application vulnerability scanner per-se, but some checks can be done on those, and are present in the scan settings.

In my targets, i have two domain names, examplecom and apiexamplecom, pointing to the same reverse proxy. They resolve fine : all tests can be completed.

Thing is : when doing HTTP request to scan a web app, the agent does not use any “Host: examplecom”. Thing is, depending on what you have up front as reverse proxy (let’s say Apache, Nginx or as i have, HAProxy), you can’t scan ALL web applications, as the reverse proxy routes the query to one and only one, or even none, responding 503 (which is my case).

This is not a problem of HAProxy (or a WAF intercepting requests). Everything routes fine, except Greenbone agents.

So now my question : is it possible to configure scans to use the target domain as “Host: ” ?

Thanks a lot in advance.

2

Hello,

and welcome to this community forum.

AFAICT there is no such setting and none should be required. The scanner will add the hostname to the Host header automatically if one or more of these applies:

  1. The hostname was passed to the target definition of the scan task
  2. Only an IP was passed to the target definition and the scanner is able to resolve the IP to a hostname
  3. Additional hostnames could be gathered during the scan from e.g. SSL/TLS certificates

A prerequisite is that the scanner preference expand_vhosts is set to yes.

There might be special cases where either no Host header is passed at all or only an IP is included:

  1. For service detection / probes
  2. The VT in question had modified the HTTP request for checking a specific flaw / vulnerability (e.g. an authentication bypass by modifying the Host header)
  3. Aged/old VTs (from e.g. pre2008) which are crafting their own HTTP headers instead of using more “modern” functions handling the Hostname addition
    • Usually these shouldn’t be a big problem and are getting updated from time to time during maintenance works to use more standard functions from the scanner
2 Likes
3

Hi, and thanks for the answer.
I’m gonna try again, not sure expend_vhosts is yes on my scan configuration. Will check that.
As far as I can tell, targets are FQDNs, so the item 1. of your list seems to be OK in my target configuration. Since it is a reverse proxy with TLS and a certificate, item 3. should work as well.

And noted for the exception list.

I’ll try again, and mark as a solution if it solves my problem.

Thank you very much for your answer and have a nice day :slight_smile:

1 Like
5

I’d like to add my question here.

I configured a target with it’s vhost name.
The scanner resolves it’s IP and FQDN, and tests the FQDN instead of the vhost name.

I looked up all the expand_vhost settings but nothing addresses this issue.
In that case Openvas is unable to test a vhost hidden behind an nginx.

6

I don’t see any resolution to this issue and this seems like a big problem from many different posts. I am running the latest version from source and still no virtual host scanning. I have verified expand vhost and included the name in the target host, I even created manual PTR records for it to match and still does not scan by a virtual host name/header. In fact it also doesn’t include the name in any SSL test so if your web services are looking for the subject name indicator to present certificate information, this scanner will never find them.

7

There is no solution required for this issue, AFAICT virtual host scanning via HTTP and the relevant Host header should work out of the box since ever. There could be still some environmental factors playing a role but maybe some one else with more knowledge on this topic will provide some guidance on the correct / required scan configuration here.

SSL/SNI is completely unrelated to this topic and separately tracked / discussed in Greenbone is not detecting the problem

1 Like
8

I will do some testing in my lab and confirm with a capture that vhost is working fine. The hosts I am testing refuse to even negotiate SSL without the appropriate SNI in the client hello so may not be a vhost issue and purely SNI.

1 Like
9

FYI I did confirm with a network capture against a :80 server that the hostname provided in the scan target is properly being injected as the host header.

1 Like
10

You’re scenario doesn’t make sense to me. Scans are only able to resolve IP addresses and FQDNs. If your vhost name is not a FQDN, then what is it? A local DNS server resolution for a non-FQDN? An entry in /etc/hosts? It must be something like this for the scanner to resolve it to an IP because global DNS will only resolve FQDNs.

So, the IP is resolved to a FQDN and the IP and FQDN are scanned. You must have some misconfiguration of your proxy or misunderstanding about how the scanner works.

1 Like