All Work and Some Play: A risky security scenario when working from home

We just launched Illumio Edge to deliver endpoint Zero Trust. In effect, it extends our strength in stopping attacker lateral movement in the data center and cloud to the endpoint.

Since Illumio was founded in 2013, we’ve known the most effective segmentation was based on data and host analytics that help people build least privilege policy. This is true for both the data center, with our Illumination application dependency map, and now for the endpoint. 

You can imagine our own internal security policy and processes are heavily weighted to practice what we preach with respect to least privilege. This is true for micro-segmentation and visibility in our public clouds (yes, multiple) and data centers, and now equally true with Illumio Edge running on our employee endpoints.

Over the past few months, we’ve all seen vendors discuss the vague security perils of a remote workforce. In this post, I wanted to share a specific scenario that plagues companies with employees at home.

Some incidental security

Every network, at home or work, sits behind Network Address Translation (NAT) boxes that allow us to reuse RFC1918 private address spaces all over the world due to the scarcity of IPv4 addresses. The NAT boxes do the translation from these private addresses to a single public address that is usable by the internet. That’s why your IP address could be 10.0.0.77 at work, 10.0.0.77 at your local Starbucks, and 10.0.0.77 when you are at home working from your kitchen counter. And there are complex mappings inside those boxes that allow your whole company (or your whole family at home) to share a single IPv4 public address.

NAT, often configured on enterprise firewalls or routers, provides some incidental security. Since connections need to originate from inside the corporate enterprise, it “accidentally” shields organizations from malicious internet traffic coming in.

But what about at home? Most homes use a router provided by their internet service provider. The home router has a “Firewall” tab and NAT functionality so your family can safely connect out to your favorite websites, and those websites can establish connections back to you.

All of our employees are working at home – so our enterprise-grade firewall at the edge of our corporate network isn’t protecting them. Fortunately, we have Illumio Edge deployed on all employee laptops to protect them. 

A risky WFH scenario

Let’s get to the story.

It started when a member of our data science team showed me something odd that Illumio Edge spotted – inbound connections from the internet directly into a private IP address of an employee’s laptop at home. Illumio Edge logged a machine on the public internet establishing an inbound connection to “10.0.0.77.”  

That seemed impossible to me. As I mentioned above, there are thousands of machines out there with the 10.0.0.77 address, so routing directly to a private address behind a home router didn’t make sense. When somebody shows you something surprising like this, you first need to double-check to ensure it’s not an error or bug at work.

We checked the data aggregation code we used with the data science team. There wasn’t a problem there.

Illumio products don’t just collect network information – because there is a host agent, we also knew what processes were originating this traffic. We tracked it down to a process known to leverage peer-to-peer (P2P) connections across the internet. We also looked into what other traffic that application was sending, and we saw that it was talking to a lot of internet hosts on high ports. Again, this seemed like the normal behavior of such a P2P application, but it didn’t explain how traffic could go FROM the internet to the employee’s laptop.  

Then we found the key.  

We know that employees will use work devices to play – for personal use like collaboration or gaming. This being the case, we saw the P2P app that the employee downloaded to their work laptop was talking to the employee’s home router using the Universal Plug and Play (UPnP) protocol. As you may know, one capability of UPnP for ease of device setup is to automatically port forward and open up a high port pinhole in the NAT to allow traffic back into the device behind the NAT. This is called NAT Traversal. In short, when anybody on the internet sends a packet to the agreed-on high port, for example 55443, the NAT box forwards it to the application port on 10.0.0.77. This explained the data we saw.

Thanks to a single application, inbound internet traffic was allowed directly into an employee endpoint. Our enterprise firewalls at the office would obviously not permit this, making it an exclusive risk of employees working from home. The risk? We don’t know what vulnerability this P2P application has, or if it’s possible to remotely exploit while employees are working from home with weaker security functionality.

Candidly, it was a huge surprise. I think the last time I did UPnP was in 2009. And since that same time frame, it’s been blocked in enterprise environments and its risks repeatedly underscored. Even in modern home routers, this activity generally seems to be disabled.  

Yet here we are in 2020, still dealing with UPnP opening ports to massively augment risk. Yes, this risk has existed for quite some time. But now, with so many more information employees working from home without the protection of our enterprise security stack, the risk multiplies and is hard to monitor.

Lastly, what would I do to address this risk? I’d start by figuring out a way to identify the internet P2P apps running on your employees’ systems. Disable them if they are not crucial or block them from sending any UPnP traffic to avoid them opening up those NAT pinholes. Also, block inbound connections from the internet completely to any application.  

Stay safe, and stay vigilant. Bad actors understand how to take advantage of the situation we are all in, so security professionals need to understand the shifted risk landscape. Otherwise, we as defenders are going to see some serious losses.

This article was originally published on Illumio’s blog.