Remote Worker VVoIP Security – Part 2 (How do remote workers get attacked? )

Does your company allow work from home/café, and do your employees connect to your office telephony network to communicate on voice/video? Well, then your organization must worry about remote worker VoIP security. 

I’ve got this diagram here, which explains how communication systems work for remote workers. 30000 feet view. 

When we look at the diagram closely, we can almost immediately see some of the challenges of securing this setup. Remote workers connect over the internet to the company network. The most obvious security challenges are: 

1. Is the requested call connection coming in from a bonafide caller? 

2. Is the requested call connection coming in from a bonafide endpoint? 

3. Has the call been hijacked along the way? 

4. If some connection requests come in with ‘mangled’ protocols, are these real connection requests or attackers? 

5. If some connection requests come in from unusual locations, are these real requests or attackers? 

6. If duplicate connection requests come in from the same remote worker, are these real or attackers? 

While firewalls can check at the IP level, they are helpless at the SIP level because they do not understand the protocol and simply pass it on.  

These are not abstract threats. And the outcomes of attacks on remote working infrastructure are serious. Even a single broken-in extension can act as a jumping-off point for a whole series of additional attacks. For example, enterprise toll fraud almost always occurs as an outcome of remote worker security breaches.  

A Use Case 

Here is an example of how remote worker security issues play out in the real world. A major city transportation authority was an unsuspecting victim of several data exfiltration attacks and a successful takeover of nearly 50 of its remote worker extensions. The organization had been seeing a high percentage of call failures and de-registrations in its voice systems for several months. However, given its large call volumes and distributed workforce, these signs went unnoticed and predictably, raised no alarm. However, they were symptoms of undetected data exfiltration attacks. Let’s look at how attackers went about doing this. 

The Groundwork 

1. Attackers release crawlers on the internet to constantly look for devices to scan, often using the services of IoT search engines like ZoomEye, Shodan, and so on.  

2. When a crawler identifies that a device is an SBC or an exposed PBX, they begin a probe into the device, looking to gather as much information as possible about the device. 

3. Attackers then collect specific information like valid extension, OEM vendor, etc., to plan the next level of attacks: brute forcing a valid extension.  

The Attack 

1. Usually, extensions have a 4 or 6-letter password, and very often it’s just numbers. That’s the kind of stuff that attackers love – short passwords, with little ‘noise’. The transport company too used 6-digit number passwords. The attacker’s automated tools, easily and quickly brute-forced through the extensions – a spray of commonly used passwords is usually enough to find their way in. It was only a matter of time before they guessed the password and took over the extension. 

2. They didn’t stop with one extension. The next step, a password spray attack on all the valid extensions of the enterprise, provided access to 50+ remote extensions since their passwords were based on the same pattern of the already taken over extension.  

The Impact 

Attackers were found to be monitoring 25 users for nearly two months while tracking all call activity on their lines. This opened the possibility of user impersonation, lateral attacks, privilege escalation, and so much more. Remote workers’ compromises are gateways to a series of other attacks and compromises. 

Interestingly, attackers had the opportunity for toll fraud but chose not to exercise it, possibly because the value of data exfiltration was high enough that toll fraud was relatively lower value. 

How could this breach have been prevented? 

Short answer: Defense in Depth.  

Here’s the slightly longer version: Attacks on remote worker infrastructure are always going to take place, but instead of looking for a magic bullet that prevents attackers from getting through, we need to instead look at putting multiple obstacles in the way of attackers – to slow them down or stop them in their attempt to break through. In this case, some of the barriers that could’ve been in place are: 

1. Mutual Certificate Authentication: where the client and the server both authenticate each other. A non-authenticated client would not have been able to connect at all. 

2. Strong URI/URL requirements: where the SBC would check the software version details shared by the client and allow only approved versions to log in. 

3. Spoof checks: where the system could examine  

• The protocol details, to see if there are any red flags there, such as mangled or missing headers 

• The IP address to see if it belongs to a blacklist, which may also require access to a living database of such addresses 

In my next article, we will approach the remote worker security challenge in a different way. Instead of looking at a specific use case and trying to figure out how to prevent it, we will discuss how to prevent a vast majority of such attacks – security hygiene.  

Have more questions? Send me an email at securityeducation@assertion.cloud