One of our security researchers was asked to take a look at the network security of a London coworking space.

What our researcher discovered is startling.

In spite of the tech focus of the businesses on the site and a lot of very clever developers, anyone with malicious intent would be able to cause a lot of trouble.

Method: 1. IRL Exploit 2. Port scan

The WiFi password for the entire network is posted on laminate pieces of paper around the co-working space. Getting into the space without membership requires a bit of charm and confidence, this was aided by how helpful the people at reception were. No one would look out of place with a MacBook and a copy of Nmap running while sipping a flat white.

The coworking space has 802.11ac WiFi which was connecting at 866mbit/sec.

This offers significant power to do port scanning. Everyone loves fast WiFi, especially if you aim to get your port scan done and get out before someone questions why you’re there.

The network has an enormous netmask, although this was easy enough to scan through. Our researcher didn’t want to cause any problems to the people working or flood the network to the point of it falling over so we just did a SYN port scan on a few of the most important ports.

Findings: Be afraid, be very afraid

There was an enormous array of services running on the rest of the network. Most with non-existent or neglible protection.

Hosts alive: 219

With open ports: 39

Consider that many of these devices are smartphones or iPads with (hopefully) no open services running, so the number of devices with open ports is very high for what is, in effect, a public network. A piece of paper with a password really does undermine WPA2.

Hosts breakdown:

sshd: 31, of which 16 were running critically out of date versions of sshd, predominantly shipped with older versions of OS X. Most of these hold serious security issues and, given those issues, it  would be quite easy to gain access to the entire development system.

mysql: 17, most critically, many were out of date and with probably limited security on (why set up remote hosts filtering when you are used to NAT?) and many installers allow a default root password of blank or similar. Game over, again.

elasticsearch: 6, only one had authentication set and elasticsearch is by far the worst offender in our eyes. Elasticsearch doesn’t ship with authentication by default.

While many of these people would never dream of not using a firewall on a production server, they still carry the production database around on their laptop.

ES also allows you to trivially run shell scripts and many of them can escape the java sandbox if you’re not using the latest versions of everything.

mongod: 4, it wasn’t easy to ascertain the status of these servers. It’s likely many will have the default homebrew/apt password set.

There was even some fun stuff like ancient versions of MS-SQL, VMWare admin ports, etc. kicking around.

What does all this mean and what should I do?

If you work in a co-working space, assume that the local network is insecure as sitting on the public internet with no firewall and take precautions accordingly:

Use a local firewall

Look at using a VPN if you need to create a genuinely ‘secure’ local network

Help, I manage a coworking space and this sounds bad.

Take more precaution with your wireless network (and physical ethernet ports if you have them). Don’t leave the password everywhere, instead have a separate guest network.

Considering vlan’ing the network so every computer is locked down and can’t see the rest of the network. This will cause some things to break though, so ask a network specalist for some options.