From open Guest Wi-Fi to pwning a lift

…or why validating network segregation is critical

TL;DR

A recent engagement took quite an unexpected turn and led to me having remote control of a bunch of building services including a lift from the street outside, unauthenticated. A single firewall rule bypassed some well configured VLANs and led to an emergency change being made to assure safety, let alone security!

I was on site and looking at a brand-new network installation in a shared office building. The ground floor offered public spaces including a café, so there was potential for any member of the public to be present.

Sat with a cuppa, my first port of call was the open Guest Wi-Fi access point. I was presented with a landing page asking me to accept a EULA before being given an IP address and a gateway to access the Internet.

Getting started

To avoid hitting other members of the public on the open Wi-Fi network, I focussed on the client provided internal IP range, which was a class B network. Using masscan I was able to probe the top 10 ports of all 61,441 (non-local subnet) hosts within a couple of minutes. Rather concerningly I was getting hits, a lot of hits. This confirmed that there was no physical segregation between the open Wi-Fi access point and the internal networks.

Exploring

The only two ports that were coming back as open were: 80/tcp and 443/tcp which sounds about right for a network that only permits web traffic outbound to 0/0 hosts. So I got started on the more interesting work of enumerating the various internal web services.

EyeWitness is pretty handy. It’s a great tool in which one feeds in an XML report from masscan or nmap, it then takes screenshots of all identified HTTP services and produces a convenient report for you, complete with categories such as response types and type of device.

The majority seemed to be duplicates, so taking one of each system I started the task of searching for “system name + default password” (Google Dorks not required) and inputting the provided values. Login success after login success – I was watching corridors, data centres and then the big one. I even found myself watching the watchers, the security room:

The CCTV network was identified as split into two categories, the internal camera being one vendor and the external being another. The former required just a username as the default password was blank, and the latter required no authentication at all. A simple HTTP request to the web service and you will be presented with a real-time imagery of every person walking in and out of the building.

Safety systems

Digging deeper, I was starting to gain an idea of the different networks and their functionalities: I was viewing fire alarms, programmable logic controllers (PLCs), power meters, foot traffic detectors and many more. Real care was required, as some OT can respond badly to malformed and unexpected network traffic.

So I turned my attention to the lift systems emergency intercom. Again, after a simple Google search, I was authenticating to these as administrator. These are just simple SIP devices that make calls out via VoIP.

Navigating through the web configuration portal I noticed that, with this level of privilege, I had the ability to block outgoing numbers. At this point if I was to block all outgoing calls, I would essentially render the lift alarm button useless.

As I could already view who was in the lift from the CCTV camera, it would then just take access to one of the power meters or the lift controller itself to lock someone in a lift. As these were industrial control devices renowned for being extremely sensitive and, given the possible outcomes, I felt it wise to stop immediately and debrief the client.

The client took immediate action and pulled some network cables whilst segregation was reviewed and enforced.

Conclusion

The internal networks contained building management systems such as smart lighting controllers, IP fire alarms, lift management systems and HVAC. All were correctly segregated using VLANs on Cisco hardware, following good practice.

It transpired that an erroneous firewall rule to permit traffic from the guest Wi-Fi network completely circumvented this.

Advice

Please double check your network segregation: it’s very easy for a rule to accidentally override your carefully segregated networks.

Pay even more attention to segregation of OT networks and building control systems. Historically, these networks were physically isolated, which was one way of assuring their separation from your core IT network!

Never overlook shadow IT systems, particularly those that may be under the remit of your facilities or building management teams. Ensure that a strong build process is in place to assess and assure the security of any controllers, starting with changing passwords from defaults and ensuring that software / firmware is kept up to date.