[Openvas-plugins] [openvas-Bugs][6925] False positive result from "ClearBudget Invalid '.htaccess' Unauthorized Access Vulnerability (OID: 1.3.6.1.4.1.25623.1.0.100010) "

[Chris Butler]

Hi,

Following up to my comment on: https://wald.intevation.org/tracker/?func=detail&atid=220&aid=6925&group_id=29

thanks for your report. That webserver behaved quite strange and returned a 200
<input type="hidden" name="AfterLoginGoTo" value="/application/db/budget.sqlite"
This matched the pattern in that check as it was looking for "sqlite" and a 200
in the response.
Just have commited a fix into the feed to avoid a false positive. Will also
check why we're getting a different response in the next few weeks.
For further NVT problems please use the
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-plugins
mailinglist as this bugtracker is abandoned.

Ah, I can see now why the webserver is returning a different response to what we see in a web browser. I'm guessing that OpenVAS isn't providing a "Host" header when it goes to the URL https://83-223-123-138.as29017.net/application/db/budget.sqlite but the browser is.

Without a host header, our nginx web server is taking the first host that matches based on the IP address, which ends up at the login page for our web application. It would actually give a 404 if logged in, but default behaviour is to redirect to login for all addresses to avoid any information disclosure to unauthenticated users.

When going there in a browser the Host header causes nginx to select the "catch-all" name-based vhost on the same server (since a name-based vhost match takes precedence over an IP-based one apparently), and this gives the 410 "domain not found" response.

[Christian Fischer]

Hi,

Post by Chris Butler
Hi,
Following up to my comment on: https://wald.intevation.org/tracker/?func=detail&atid=220&aid=6925&group_id=29

thanks for your report. That webserver behaved quite strange and returned a 200
<input type="hidden" name="AfterLoginGoTo" value="/application/db/budget.sqlite"
This matched the pattern in that check as it was looking for "sqlite" and a 200
in the response.
Just have commited a fix into the feed to avoid a false positive. Will also
check why we're getting a different response in the next few weeks.
For further NVT problems please use the
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-plugins
mailinglist as this bugtracker is abandoned.

Ah, I can see now why the webserver is returning a different response to what we see in a web browser. I'm guessing that OpenVAS isn't providing a "Host" header when it goes to the URL https://83-223-123-138.as29017.net/application/db/budget.sqlite but the browser is.
Without a host header, our nginx web server is taking the first host that matches based on the IP address, which ends up at the login page for our web application. It would actually give a 404 if logged in, but default behaviour is to redirect to login for all addresses to avoid any information disclosure to unauthenticated users.
When going there in a browser the Host header causes nginx to select the "catch-all" name-based vhost on the same server (since a name-based vhost match takes precedence over an IP-based one apparently), and this gives the 410 "domain not found" response.

thanks for your follow-up. I came to the same conclusion during my test,
currently httpver.nasl is only detection HTTP/1.0 support at this server
due to a broken test for HTTP/1.0 vs. HTTP/1.1 support. Because of this
no Host header is sent and this explains the difference.

Updating the httpver.nasl to correctly detect HTTP/1.0 vs. HTTP/1.1 on
such hosts is already on my TODO list since a few days but it will take
some time to implement and test the changes.

Regards,

[Christian Fischer]

Hi,

Post by Christian Fischer
Hi,

Post by Chris Butler
Hi,
Following up to my comment on: https://wald.intevation.org/tracker/?func=detail&atid=220&aid=6925&group_id=29

thanks for your report. That webserver behaved quite strange and returned a 200
<input type="hidden" name="AfterLoginGoTo" value="/application/db/budget.sqlite"
This matched the pattern in that check as it was looking for "sqlite" and a 200
in the response.
Just have commited a fix into the feed to avoid a false positive. Will also
check why we're getting a different response in the next few weeks.
For further NVT problems please use the
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-plugins
mailinglist as this bugtracker is abandoned.

Ah, I can see now why the webserver is returning a different response to what we see in a web browser. I'm guessing that OpenVAS isn't providing a "Host" header when it goes to the URL https://83-223-123-138.as29017.net/application/db/budget.sqlite but the browser is.
Without a host header, our nginx web server is taking the first host that matches based on the IP address, which ends up at the login page for our web application. It would actually give a 404 if logged in, but default behaviour is to redirect to login for all addresses to avoid any information disclosure to unauthenticated users.
When going there in a browser the Host header causes nginx to select the "catch-all" name-based vhost on the same server (since a name-based vhost match takes precedence over an IP-based one apparently), and this gives the 410 "domain not found" response.

thanks for your follow-up. I came to the same conclusion during my test,
currently httpver.nasl is only detection HTTP/1.0 support at this server
due to a broken test for HTTP/1.0 vs. HTTP/1.1 support. Because of this
no Host header is sent and this explains the difference.
Updating the httpver.nasl to correctly detect HTTP/1.0 vs. HTTP/1.1 on
such hosts is already on my TODO list since a few days but it will take
some time to implement and test the changes.

just want to let you know that issues has been fixed and should be
available in one of the next feed updates.

The main issue here was, that this old implementation of httpver.nasl
assumed HTTP/1.1 support if one of the following HTTP status codes matched:

buf =~ "HTTP/1.1 20[0-6]" || buf =~ "HTTP/1.1 30[0-7]" || buf =~
"HTTP/1.1 40[13]"

Your server responded with an HTTP/1.1 410 (which is absolutely fine)
and so only HTTP/1.0 support was assumed. I've simplified this check:

https://lists.wald.intevation.org/pipermail/openvas-nvts-commits/2017-May/006077.html

as we shouldn't make a decision of the HTTP version support based on a
response code other then 505 (HTTP Version Not Supported).

Regards,