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

Read More

How companies can stop most RAT attacks – spoiler alert, enforce HTTP proxy

RATs (Remote Admin Tools a.k.a Remote Access Trojans) are mainly used by two groups. Script kiddies and nation state attackers. Script kitties love RATs because of the easy to use GUI, no hacking knowledge is needed. They can spy on the victims webcam, pop-up new websites, or just steal Paypal passwords. Nation state attackers like RATs because it is easier to blend in, and attribution becomes harder (in theory, not in reality). And they get all the functionality they want, upload and download files, remote code execution, etc.

Rat

I have checked the following “public” RAT’s. Public RAT means everyone can download it or buy it easily:

  • XTreme RAT
  • Apocalypse
  • Bifrost
  • Blacknix
  • Cerberus
  • Cybergate
  • Darkcomet
  • PoisonIvy
  • Turkojan
  • JRat
  • NJRat
  • Meterpreter
  • Plasma RAT
  • Netwire
  • Imminent
  • BlackShades
  • JSPy
  • Bozok RAT
  • Dameware (not really a RAT)
  • Nanocore
  • Babylon RAT
  • LuminosityLink
  • n1nj4sec/pupy (thx @buherator for the recommendation)
  • Innuendo¬†(thx @buherator for the recommendation)

And the following “private” RATs, which means nation state attackers use it mostly:

  • HTTPBrowser RAT (User-Agent:¬†HttpBrowser/1.0 )
  • Hacking Team RCS Agent (HTTP)
  • Finfisher (injects into IE, tries multiple ports)
  • PlugX¬†(TCP, UDP or HTTP)
  • Havex RAT (HTTP)

There are of course a lot of RAT’s which have been developed by APT groups which are not listed here.

The following public RAT’s (the official, public versions) support proxies:

  • PoisonIvy (automatically finds the system proxy, uses CONNECT)
  • Netwire
  • Dameware¬†(not really a RAT, manual proxy configuration)
  • Meterpreter (uses Windows API, and real HTTP protocol)
  • Innuendo (can use proxy, but can’t authenticate to proxy via Windows API at the moment)

The following “private” RAT’s support proxies:

  • Hacking Team RCS Agent
  • PlugX (have to directly configure the proxy name)
  • Havex

Let’s assume that script kiddies don’t target governments and big corporations usually, and when these¬†are attacked, it is done by another government with high probability. Now¬†check the news for the headlines with RATs without proxy support:

2014 January: Xtreme RAT, Victim: Israeli Defense Ministry, http://www.tripwire.com/state-of-security/latest-security-news/israeli-defense-systems-hacked-xtreme-rat-trojan/

2012 November, Xtreme RAT, Victims: governments of the Israel, US, UK, Turkey, Slovenia, Macedonia, New Zealand, and Latvia http://blog.trendmicro.com/trendlabs-security-intelligence/new-xtreme-rat-attacks-on-usisrael-and-other-foreign-governments/

2014 June, Xtreme RAT, Victims: Palestinian and Israeli surveillance targets, Government departments in Israel, Turkey, Slovenia, Macedonia, New Zealand, Latvia, the U.S., and the UK, The Office of the Quartet Representative, The British Broadcasting Corporation (BBC), A major U.S. financial institution, Multiple European government organizations http://securityaffairs.co/wordpress/25533/cyber-crime/fireeye-molerats-attacks-xtreme-rat.html

2013 July, multiple RAT, Victims: Truecaller, Tango, Viber https://www.fireeye.com/blog/threat-research/2013/07/syrian-electronic-army-hacks-major-communications-websites.html

2014 March, NJRat, http://www.symantec.com/connect/blogs/simple-njrat-fuels-nascent-middle-east-cybercrime-scene

jrat

The fact that these organizations were targeted does not mean they did not have proxy and firewall properly set. It does not mean the attack was successful. But the fact that attackers are using it for a while means they are successful enough. Also I might be wrong according some samples’ proxy support, or I just tested an old version. If you spot any mistakes, let us know!

This is bad architecture

This is bad architecture

Which means that if a company follows basic security rules, most RATs does not have a chance:

  1. Enforce the use of a HTTP proxy
  2. Disable any traffic from the clients/servers to the firewall, only allow the HTTP proxy to talk to the Internet. Only allow server traffic to/from the Internet which is in line with the services of the server.
  3. Use user-agent whitelisting on the HTTP-proxy. Disable clients which don’t have the whitelisted user-agent.
  4. On the proxy, only allow connect() on port 443.
  5. Enable transparent proxy authentication
  6. Use “splash”¬†page, where visitors have to click accept on the first use of the website on that day
  7. If you have time and resources, implement SSL inspection on the HTTP proxy.
  8. Enforce strict software firewall rules for notebooks, use a local agent to filter suspicious traffic.

Actually, the first four can be implemented with free, open-source tools (e.g. Squid, iptables), and by implementing these, it is pretty much efficient against most RATs.

This is good architecture

This is good architecture

If you have any particular APT related RAT, and you have the possibility to test it’s proxy support, let us know the results!

 

Read More