PSA: Serious OpenVPN Vulnerability w/ PureVPN (et al.)

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Advanced Networking
Goto page 1, 2, 3, 4  Next
Author Message
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 8034

PostPosted: Wed Feb 15, 2017 21:37    Post subject: PSA: Serious OpenVPN Vulnerability w/ PureVPN (et al.) Reply with quote
I’m not one to be an alarmist around here, but it has recently come to my attention that we have a serious vulnerability w/ PureVPN (and probably others) and the dd-wrt OpenVPN client GUI.

http://www.purevpn.com

Seems that PureVPN leaves their end of the tunnel WIDE OPEN! If you reference your VPN’s public IP from outside your WAN, you’ll probably find you can reach your router’s GUI and other services (telnet, ssh, etc.), even ping, from that public IP!

To test for the vulnerability, you need to be OUTSIDE your network, on the internet side of the WAN. Use the cellular network, a neighbor’s wifi, etc., but do NOT check from inside the same LAN as the OpenVPN client, otherwise you’ll receive a false positive. If you’re outside your WAN, enter http://<vpn-public-ip> into your browser, and see your router’s GUI, you’re vulnerable.

The implications are serious since the VPN is circumventing the normal protections of the WAN’s firewall. It doesn’t even require someone to use a secure channel to access the GUI (i.e., SSL/TLS). Just plain ol’ http will do. All someone has to do is hammer the GUI or telnet all day long until they crack your password. And given how many ppl are probably using weak passwords under the assumption that remote access is not possible (after all, you have remote access disabled on the Administration page, right?), it probably won’t take all that long.

A contributing factor is the firewall rules employed by the OpenVPN client GUI. They are far too weak, and are designed to permit bidirectional (aka site-to-site) configuration, by default. But that’s neither necessary nor desirable when working w/ a commercial OpenVPN provider. All you typically need is a unidirectional tunnel, one that allows all outbound connections but blocks all INBOUND connection attempts.

FWIW, PureVPN offers something called “NAT Firewall” that I think is supposed to block their end of the tunnel, or at least let you manage it. But it’s a PAID SERVICE! IOW, by default, you're UNPROTECTED unless you pony up!

http://www.purevpn.com/blog/ensure-optimal-security-with-purevpns-add-on-nat-firewall/

I always assumed my VPN provider would protect me by default, and perhaps have to pay for the privilege to port forward. These guys are working in reverse. I have no idea how common this is, but it’s worth noting when deciding to use any commercial OpenVPN provider.

In fairness to PureVPN, at least they are offering a solution. But my fear is that most dd-wrt users will not be aware of the situation, are not using their NAT Firewall service, and just assume they’re protected. And assume if anything did go wrong w/ the VPN provider, at least the router would be a last line of defense. The point of this post is to dispel any such notions.

And don’t be mislead by the Firewall Protection option in the GUI. It actually does little to protect you. After examining the rules generated both when it’s enabled and disabled, I’m frankly not sure what its purpose is.

Bottom line, for added security, I recommend the following modifications to all dd-wrt OpenVPN clients using PureVPN, and any other commercial OpenVPN providers you discover doing the same.

Under Additional Config:

Code:
dev tun0


Then add the following to your firewall script:

Code:
# allow only outbound connections to the VPN (no inbound)
iptables -I INPUT -i tun0 -m state --state NEW -j DROP
iptables -I FORWARD -i tun0 -m state --state NEW -j DROP
iptables -t nat -I POSTROUTING -o tun0 -j MASQUERADE


The net effect of these changes is to override the default firewall rules and replace them w/ safer, more secure ones. Once installed, you should NOT be able to create any INBOUND connections to your network using the public IP of the VPN.

Please be aware that due to these changes, the remote address (i.e., your public IP on the VPN) will no longer display on the OpenVPN status page (a small price to pay to prevent intrusions). You can always visit InfoByIp ( http://www.infobyip.com ) to get complete information on your current public IP.

And btw, it doesn’t really matter what you set for Firewall Protection at that point either. It’s just ignored.

On a happier note, it is possible to do port forwarding over the VPN w/ PureVPN. After installing the new firewall rules, you could add port forwarding rules as follows:

Code:
# port forward from the VPN and into the LAN
iptables -t nat -I PREROUTING -i tun0 -p tcp --dport 8081 -j DNAT --to 192.168.1.100:80
iptables -I FORWARD -i tun0 -p tcp -d 192.168.1.100 --dport 80 -j ACCEPT


In the above example, we're permitting remote access over the VPN using an external port of 8081 to a webserver running locally on 192.168.1.100 (port 80). It’s important to take note of this technique since the changes in the firewall rules will not allow port forwarding over the VPN via the GUI.

For completeness, you can add a kill switch as well.

Code:
# block all access to the WAN by the LAN
WAN WAN_IF="$(route -n | awk '/^0.0.0.0/{wif=$NF} END {print wif}')"
iptables -I FORWARD -i br0 -o $WAN_IF -m state --state NEW -j REJECT


The major take away, though, is to change the OpenVPN device name (tun0) and those firewall rules!


Last edited by eibgrad on Thu Jun 14, 2018 5:32; edited 2 times in total
Sponsor
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 5193
Location: Netherlands

PostPosted: Thu Feb 16, 2017 14:25    Post subject: Reply with quote
Big thanks for all your work, much appreciated.

I have tested Private internet Access (PIA) which is my VPN and get destination unreachable. So my limited testing shows that PIA is behaving well Smile

_________________
Routers:Netgear R7800, Netgear R6400v1, Netgear R6400v2, Linksys EA6900 (XvortexCFE), Linksys E2000 (converted WRT320N), WRT54GS v1.
Install guide Linksys EA6900: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=291230
OpenVPN Policy Based Routing guide: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=321686
Install guide R6400v2:http://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
OpenVPN Server Setup:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=318795
Install guide R7800: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Wireguard Setup guide:https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=1183135
phatbob
DD-WRT User


Joined: 03 Jan 2017
Posts: 211

PostPosted: Thu Feb 16, 2017 16:16    Post subject: Reply with quote
Being a PureVPN user I was certainly alarmed to find this out. My thinking is that they want to sell their Nat firewall addon. The thing is from what I can see the addon can be gotten for $0.99 a month. I got their 2 year package which was $59.95, or about $2.50 a month. Why wouldn't they just include the firewall and charge $3.50 a month. It's still less than most out there.

The biggest issue is that they don't tell you that you're unprotected, in fact they lead you to believe the total opposite. At least thanks to eibgrad I am now secure and I don't need the firewall.
sploit
DD-WRT User


Joined: 16 Apr 2016
Posts: 304
Location: California

PostPosted: Mon Feb 20, 2017 2:43    Post subject: Well... Reply with quote
Well atleast I know what VPN allows this by default that I can recommend to my customers who need the ports open.

That is laughable that they think in the reverse lol.

I had been referring customers to StrongVPN for opening up ports and dedicated IP's.

I might get a purevpn account to test with.... I have some things I'd like to experiment with for a week or so with open ports through a VPN service.

_________________
My Karma ran over your Dogma
SploitWorks Custom Flashed Routers
phatbob
DD-WRT User


Joined: 03 Jan 2017
Posts: 211

PostPosted: Mon Feb 20, 2017 3:23    Post subject: Reply with quote
Quote:
Well atleast I know what VPN allows this by default that I can recommend to my customers who need the ports open.


Just so you know, within days after this topic was started all the ports were closed up on their end. I did go ahead and purchase their Nat firewall so I could open up the ports I needed. It does give you the option of opening them all if you really are looking to test some things.
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 8034

PostPosted: Mon Feb 20, 2017 4:34    Post subject: Reply with quote
phatbob wrote:
Quote:
Well atleast I know what VPN allows this by default that I can recommend to my customers who need the ports open.


Just so you know, within days after this topic was started all the ports were closed up on their end. I did go ahead and purchase their Nat firewall so I could open up the ports I needed. It does give you the option of opening them all if you really are looking to test some things.


You may be right, but it's hard to say for sure. If PureVPN is in fact listening, then I wish someone there would just respond.

I just tested my own public IP on the VPN (w/o the changes I recommended above) and can no longer get into either the GUI or telnet. But I can still ping.

I then visited another PureVPN public IP (some other unknown user I found by searching w/ a script) and found his GUI is still accessible. It may be a long-lived connection, and if he disconnects and reconnects in the future, perhaps access to his GUI may be denied. But until that happens, I remain skeptical.

Remember too, these guys have 100's of VPN servers, and if indeed they made a change, it would have to be replicated across every server. Not something that's likely to happen overnight.

If this does prove to be the case, I still recommend the changes I described above as a second line of defense. Personally, I don't even want ping to respond. And I suspect PureVPN isn't the only one NOT firewall'ing their end of the tunnel.
phatbob
DD-WRT User


Joined: 03 Jan 2017
Posts: 211

PostPosted: Mon Feb 20, 2017 5:36    Post subject: Reply with quote
Quote:
If this does prove to be the case, I still recommend the changes I described above as a second line of defense. Personally, I don't even want ping to respond. And I suspect PureVPN isn't the only one NOT firewall'ing their end of the tunnel.


I agree and I do keep your changes implemented. The more protection the better. Also you're right to be skeptical, because they left their side open for however long, we can't be confident it will remain blocked.

Of course that other persons Gui that you found accessible, it is also possible that he or she intentionally has all their ports open, all though I can't imagine why.
ian.wright
DD-WRT Novice


Joined: 20 Feb 2017
Posts: 3

PostPosted: Mon Feb 20, 2017 14:50    Post subject: Reply with quote
eibgrad wrote:
phatbob wrote:
Quote:
Well atleast I know what VPN allows this by default that I can recommend to my customers who need the ports open.


Just so you know, within days after this topic was started all the ports were closed up on their end. I did go ahead and purchase their Nat firewall so I could open up the ports I needed. It does give you the option of opening them all if you really are looking to test some things.


You may be right, but it's hard to say for sure. If PureVPN is in fact listening, then I wish someone there would just respond.

I just tested my own public IP on the VPN (w/o the changes I recommended above) and can no longer get into either the GUI or telnet. But I can still ping.

I then visited another PureVPN public IP (some other unknown user I found by searching w/ a script) and found his GUI is still accessible. It may be a long-lived connection, and if he disconnects and reconnects in the future, perhaps access to his GUI may be denied. But until that happens, I remain skeptical.

Remember too, these guys have 100's of VPN servers, and if indeed they made a change, it would have to be replicated across every server. Not something that's likely to happen overnight.

If this does prove to be the case, I still recommend the changes I described above as a second line of defense. Personally, I don't even want ping to respond. And I suspect PureVPN isn't the only one NOT firewall'ing their end of the tunnel.


I'm also a user of PureVPN. After reading your post I went on to talk to their customer support. And they gave me this statement; "Service that blocks unsolicited ports for customers malfunctioned in some of our servers which has been fixed now."
I'm really concerned if the issue has been resolved.
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 8034

PostPosted: Mon Feb 20, 2017 15:35    Post subject: Reply with quote
ian.wright wrote:
I'm also a user of PureVPN. After reading your post I went on to talk to their customer support. And they gave me this statement; "Service that blocks unsolicited ports for customers malfunctioned in some of our servers which has been fixed now."
I'm really concerned if the issue has been resolved.


Here's the problem w/ that statement from PureVPN, at least from my perspective.

If they identified the problem, and if it's because of this thread, then why doesn't PureVPN respond to this thread and allay our concerns?

I never got the impression from their website that they ever intended to block their end of the tunnel by default. Usually when that's the case, the add-on product focuses on offering port forwarding over the VPN, since that then becomes the problem. Instead, the focus seems to be literally on selling you a *firewall*!

Consider the actual verbiage from their own website.

https://support.purevpn.com/why-do-i-need-nat-firewall

Quote:
Most OS have built-in Firewall (like Windows). However, your VPN constructs a tunnel between your PC and the VPN server. This tunnel passes that through the OS’s built-in Firewall and you lose the extra protection (as it cannot read the encrypted packet). Malicious IP packets can probably enter your system from your public IP assigned to you by your VPN service provider.

To provide you with an extra layer of online security, PureVPN has added paid NAT Firewall Add-on. By activating this Add-on, the VPN user activates a NAT Firewall between the VPN server and the internet so that all internet traffic passes through securely.


No matter how many times I read that, it sure doesn't sound like PureVPN has ever intended to firewall their side of the VPN by default. As I said from the beginning, they seem to be selling security as an add-on. And from my perspective, that's not acceptable. That leaves users at the mercy of their own ignorance, when in fact the VPN provider is in the best position to protect them.

We don't seem to be getting the straight story here. And if PureVPN wants to allay our concerns, they need to respond and explain the situation. If they simply had a change of heart regarding leaving their end of the tunnel open, then just say so. And if they did, it might be they're concerned that to acknowledge it would undermine sales of their NAT Firewall product. After all, why pay for something you're already getting?
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 8034

PostPosted: Mon Feb 20, 2017 15:44    Post subject: Reply with quote
P.S. In fairness, I should add that dd-wrt is partly to blame here as well. After all, the default firewall rules *are* inadequate. It's actually the combination of dd-wrt + PureVPN that's lethal. If either one was doing things right, we wouldn't be having this conversation.

Even if PureVPN eventually (and reluctantly) decided to firewall their end of the tunnel, I still recommend those changes I made above since you're still vulnerable to *local* users on the other end of the tunnel. IOW, anyone who has access to the network on which their VPN server is running. And that would apply to *all* VPN providers, not just PureVPN. Granted, that's not nearly as concerning as the public at large, but it should still be a concern.
SisyphusBond
DD-WRT Novice


Joined: 26 Jan 2017
Posts: 38

PostPosted: Mon Mar 06, 2017 0:35    Post subject: Reply with quote
Can I piggy-back on this to ask a few questions? I'm only just dipping my toes in the world of VPNs and I'm still learning a lot of the technical stuff.

Firstly, is this still an outstanding issue? There appear to be some suggestions that it was a temporary error, and some scepticism at these claims.

Secondly, does their NAT Firewall add-on that they sell basically cover this whole issue or are there still concerns? Adding an extra $1/month still puts them at a good price for what I was looking for.

My final question is a bit off-topic, so feel free to ignore it, but I read instructions for setting up an OpenVPN connection directly on a Netgear ReadyNAS Network Attached Storage device:

https://community.netgear.com/t5/New-to-ReadyNAS/Installing-and-running-OpenVPN-boot-PrivateInternetAcces/m-p/941794#M7559

and wondered how someone might go about adding in the code you've provided to that. Is it something fairly straightforward?
phatbob
DD-WRT User


Joined: 03 Jan 2017
Posts: 211

PostPosted: Mon Mar 06, 2017 15:25    Post subject: Reply with quote
It seems that it was PureVPN's claim that it was a malfunction that caused the security issue and it is now fixed. Whether you want to believe that or not is up to you. Being a user of their service myself, I feel much more secure using eibgrad's scripts to block traffic on my end so I'm protected in case they drop the ball again. I have also purchased the nat firewall from them and can tell you that it gives you the options to:

1-Block all ports
2-Open all ports
3-Open selected ports(up to 15 ports)

I have also noticed on 1 occasion that when their site was down that the port I have opened for my plex to work was not open, but that's preferable to having them all open I guess.

I guess it's possible for any VPN provider to have a breach of some sort that would cause the same issue that PureVPN was having and one would have to be checking constantly to know for sure that you are protected.

One thing I can tell you for sure is if you do decide to use PureVPN, their Tech support blows and for the most part their setup guides are inaccurate at best.
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 8034

PostPosted: Tue Mar 07, 2017 22:08    Post subject: Reply with quote
SisyphusBond wrote:
Firstly, is this still an outstanding issue? There appear to be some suggestions that it was a temporary error, and some scepticism at these claims.


Yes, because the problem is not just PureVPN. It’s also the router and its use of soft firewall rules w/ the OpenVPN client.

Even if we assume there was a problem and it was corrected by PureVPN, it doesn’t change the above. And if you don’t buy their NAT firewall product/service, and you use the dd-wrt default firewall rules, your GUI (or anything else exposed on the LAN side of the router) is potentially accessible. And once the router is breached, anything is now possible, including setting up port forwards over the VPN to the rest of your network. The only thing that prevents that from happening is a strong password.

Out of curiosity, I built some scripts to collect all the known PureVPN server IPs, convert them into class C networks, and run through the entire class (x.x.x.1-254) to see what responds to ping, and if it does, if it returns anything from port 80. Overwhelmingly most don’t respond at all. Perhaps 5-10% respond to ping. And of those, a very few will respond to port 80, among these dd-wrt and others routers (e.g., pfSense).

What’s impossible to tell is if having access to anything on port 80 is intentional or accidental. The only way I might be able to tell is if I ran through numerous other ports on the same public IP. I know of one user in particular that has had a persistent VPN connection w/ PureVPN for weeks. I suspect they’re NOT using the NAT Firewall product/service since I see telnet is available as well. I can’t imagine anyone intentionally leaving telnet accessible on the public side. I suspect this user just doesn’t realize their router is exposed on the VPN.

Quote:
Secondly, does their NAT Firewall add-on that they sell basically cover this whole issue or are there still concerns? Adding an extra $1/month still puts them at a good price for what I was looking for.


It certainly helps, but you’re still depending on a third party to protect you. You would expect the router to do likewise. If PureVPN did have a problem recently and they corrected it, the reason we detected it in the first place was due to the weak firewall rules in the router. The VPN provider is, for all intents and purposes, acting as your ISP. And even though your ISP/VPN provides some protections, you would never rely solely on them to protect you. That would be foolish.

Quote:
My final question is a bit off-topic, so feel free to ignore it, but I read instructions for setting up an OpenVPN connection directly on a Netgear ReadyNAS Network Attached Storage device:
https://community.netgear.com/t5/New-to-ReadyNAS/Installing-and-running-OpenVPN-boot-PrivateInternetAcces/m-p/941794#M7559
and wondered how someone might go about adding in the code you've provided to that. Is it something fairly straightforward?


I have no idea if this is even possible or necessary. Most appliances don’t give you low level access to things like firewall rules. Even commercial routers using OEM firmware don’t typically provide such features. You just have to assume they are sufficiently hardened to prevent these types of problems. The only way to know for sure is to try accessing the device from the public IP of the VPN. See what, if anything, responds.
phatbob
DD-WRT User


Joined: 03 Jan 2017
Posts: 211

PostPosted: Thu Mar 16, 2017 14:39    Post subject: Reply with quote
Currently I havesaved in my firewall:

Code:
# allow only outbound connections to the VPN (no inbound)
iptables -I INPUT -i tun0 -j ACCEPT
iptables -I INPUT -i tun0 -m state --state NEW -j DROP
iptables -I FORWARD -i tun0 -m state --state NEW -j DROP
iptables -t nat -I POSTROUTING -o tun0 -j MASQUERADE

# port forward from the VPN and into the LAN
iptables -t nat -I PREROUTING -i tun0 -p tcp --dport 32400 -j DNAT --to 192.168.101.125:32400
iptables -I FORWARD -i tun0 -p tcp -d 192.168.101.125 --dport 32400 -j ACCEPT

# block all access to the WAN by the LAN
WAN WAN_IF="$(route -n | awk '/^0.0.0.0/{wif=$NF} END {print wif}')"
iptables -I FORWARD -i br0 -o $WAN_IF -m state --state NEW -j REJECT


which works perfectly for running plex through the vpn. Just last night I noticed however that when the vpn is down, the only thing that is blocked is plex. Everything else connects via my ISP.
SisyphusBond
DD-WRT Novice


Joined: 26 Jan 2017
Posts: 38

PostPosted: Wed Mar 29, 2017 22:09    Post subject: Reply with quote
Just to clarify, do we still need any/all of the above when using your new Basic or Advanced scripts?
Goto page 1, 2, 3, 4  Next Display posts from previous:    Page 1 of 4
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Advanced Networking All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum