OpenVPN-AS portal responding with 302 when used as HTTP proxy

[gchialli]

Hello,

I have a Qualysguard finding stating my OpenVPN-AS can be used as a public web proxy.

I see the following when I test this with curl:

Code: Select all

# curl -kI -X GET http://www.google.com/__session_start__/ --proxy https://35.198.139.32:443 --proxy-insecure
HTTP/1.1 302 Found
Transfer-Encoding: chunked
Date: Mon, 21 Oct 2019 22:03:32 GMT
X-Frame-Options: SAMEORIGIN
Content-Type: text/html; charset=UTF-8
Location: https://www.google.com/__session_start__/
Server: OpenVPN-AS
Set-Cookie: openvpn_sess_14b6f2774ac1fa1a4ea47acf0595447c=5a903acf68bf8a888a8483f05eb5c076; Expires=Mon, 21 Oct 2019 22:33:32 GMT; Path=/; Secure; HttpOnly

I can see it's always responding with a 302, so it's not really acting as a web proxy. But I would like to find a way to have OpenVPN-AS to respond with an error code instead, in order to get rid of the finding.

Is there any setting I can try?

Thanks in advance

[novaflash]

We have received reports that the Qualys Labs test indicates that the OpenVPN Access Server runs an open web proxy, and that this is considered a critical vulnerability. We have determined that this is a false positive. By that we mean that the Access Server is not an open web proxy, and that the Qualys Labs test falsely indicates that it is. It is therefore not a real vulnerability and can therefore safely be dismissed in this particular case. It happens sometimes, though rarely, that the method used to scan for certain vulnerabilities is incorrect or can be triggered by some unexpected output. And so, while there is no vulnerability of this type, it can falsely indicate that there is. This is one of such cases.

In our tests to determine if this issue really exists, what actually happens is that the request to retrieve an external URL, or any URL, is simply entirely ignored by the Access Server. The only thing we do is we look at the host name that your browser reports when connecting to the Access Server and use that as a basis for the next step. For example if your Access Server is at https://vpn.mycompany.com/ then the web browser will report host name vpn.mycompany.com. The Access Server then takes that URL and adds /__session_start__/ to it and redirects your web browser to that URL. So to be clear, your web browser is being redirected to the URL that your web browser gives to the Access Server, and then to a specific page there where the web session handling begins. There is no exploit here. You end up at the server that you originally intended to visit. Any GET (URL) command to retrieve an external website will simply be ignored entirely. Where an open web proxy would retrieve external website data and send it to you, our Access Server most certainly does not.

If you have any further questions please contact the support ticket system on our website:
https://openpvn.net/support

[novaflash]

Regarding the question if there is any setting you can try to get rid of the finding, the answer is no. We can of course make changes to our code to make this particular test by Qualys Labs pass. But this is akin to giving the wrong answer on purpose on a test where the question is wrong. In any case there is no exploit and we'll see if we can detect this particular type of test and consider any steps to take to satisfy this test - if it makes sense to do so.

[gchialli]

Thanks for the detailed answer. I agree this is a false positive. But shouldn't the Access Server respond with an HTTP error if the HTTP Host header doesn't match the configured hostname?

[novaflash]

We're not going to do that, because it would break things and make things harder to use. For example, we have a lot of customers that access the web interface through an internal address for admin purposes, and a public address for client installation purposes. We would have to ask the customer to provide all possible addresses that it can be reached at before it is able to respond. And how will we handle the situation when Access Server has just been installed, and people want to access the web interface? Let's say that you access it by IP address and then they get an access denied message. It would mean you have to configure more things before the web interface will even be usable. And what if the address of your server ever changes - you have to reconfigure the web server settings just to be able to access it.

To do it the way you say we have to start asking a lot more technical questions of our customers trying to install and use the product. We are trying to make the product easier to use, not more difficult. And this is definitely not a security issue.

[gchialli]

OK. Thanks again for your response.