How your VPN can be a front door access to your system

Tld;dr: double check your local software firewall settings while using commercial VPN!

Introduction

VPNs are used by different people for different purposes. Some use it to bypass censorship, others use it to access services which is not available in their own country, and some use it to add a layer of privacy.

During our daily work we use VPN for two reasons: to access exploit kits and to anonymously test AV and Endpoint Security products. Most exploit kits filter the attack based on the IP address of the country the victim is from. Also it happened in the past that AV and Endpoint Security products behaved differently in a lab environment than at home or enterprise users. Thus VPN is very important in our daily work. But sometimes, it can surprise us.

vpn

The following story happened in February 2016. We used a commercial VPN as always, and meanwhile our exploit replay proxy (Fiddler) was used to serve malicious traffic to the Virtualbox guest machines. For this configuration, “allow remote computers to connect ” was turned on (non-default option).  The lab machine is behind firewall and NAT. After some exploit tests (exciting results will be published later) our analysts went home, but the proxy and the VPN was left open for the night.

In the morning after having a cup of tee (we are a British company 😉 ), we found some suspicious traffic in the Fiddler history. But all guest machine was shut down, strange…. Which means either a malware is running on the host, or someone accessed the Fiddler proxy from the Internet. After a quick investigation it turned out that the traffic was coming through the VPN network interface. I did a quick Nmap scan on the VPN IP, and it proved our suspicion. The lab machine was accessible through the VPN IP to the whole Internet. All services (Apache, FTP, Fiddler, RDP) were accessible. The Fiddler proxy port was found as an open proxy by a bot, and it was instantly used for malicious purposes – possible click fraud. At least the SMB port 445 was filtered by the firewall …

Although the Windows Firewall was up and running, and the VPN interface was in Public mode,  the primary network interface in Private (home) mode, the services were accessible because these services were manually configured to be allowed for the private profile (our mistake).

2251.clip_image001_627A00E5

We believe most VPN companies don’t have this issue (although we have not tested others yet). Other VPN providers have less public IPs than active VPN users, which means they have to use NAT somewhere. And with NAT this can’t happen.

Lessons learned

  • Always check for suspicious things
  • Test your VPN provider
  • Every new layer of defense introduces a new vulnerability

Questions and answers

Where is the technical mambo jambo?
We planned to do a detailed technical analysis about how this could have happened, but it turned out without access to the VPN server configuration, we can only guess. Is this a site-to-site VPN configuration where one site is the Internet and the other is the VPN client? Is this configured via routing or iptables? We don’t know. But actually, it does not really matter to most people.
Have we contacted the VPN provider?

Yes, at the same time as this post was published. We will update this post with the vendor response.

Are users at risk?

Yes, as most people are not aware that using VPN can “publish” their system on the Internet. Many people turn off their firewall at home, and also a lot of systems have misconfigured firewalls (like ours).

Is this behaviour documented by the VPN provider?

We don’t know, but we could not find it. But we are sure average people are not aware of this risk.

PS: we left an easter egg in the video. If you find it, please don’t post it. Thank you!

 

Update 2015/02/17: I got the official reply from HMA, see below:

Untitled

Leave reply

 

Our partners