Here’s the surprising truth: It doesn’t take a state attacker or a very skilled hacker to take down an SBC — even a script kiddie could do it. All it takes is an open-source hacking tool, some tinkering with a few parameters, an unsuspecting SBC — and there you have it — a compromised SBC.
We know what you’re thinking. How can SBCs — supposedly security devices themselves — be breached so easily? You’d think that SBCs, or VoIP firewalls as we know them, would need sophisticated attacks to take them down. Unfortunately, our experience scanning hundreds of SBCs has shown us quite the opposite.
And, it’s not the SBC that is to blame — as you’ll find out in the rest of this article. Read on to find out what gives SBCs such a bad rep, the number one cause of compromised SBC, and how you can DIY-protect your SBC.
Is the SBC then really a security device?
Absolutely. In and by itself, the SBC is a perfectly capable and useful security device. The reason for its vulnerability lies in the configuration, or more precisely, the lack of attention to it.
The SBC is a complex device — with thousands of configurable parameters that you can tweak based on the use-cases of the customer. But with this flexibility in usage, comes risk and responsibility: you need to configure it correctly.
After scanning hundreds of SBCs, here’s what we found: a majority of SBC hacks happen because of one configuration oversight or error. Let’s get some basics out of the way before we dive into the issue and show you how you can fix it.
The User-Agent filter
Imagine this: A school mandates that all its students wear a uniform. At the entrance of the school stands a guard who allows only children wearing the school uniform to enter the premises. Anyone without the uniform is reported to the office.
Now, replace the watchman with an SBC and the uniform with a parameter called the User-Agent string.
Like the security guard at the gate, the SBC does a due diligence check of any incoming connection request – from endpoints like room systems, desk phones, softphones (application on your laptop, mobiles), etc.
Each endpoint connects to the SBC and presents its identity in the form of the User-Agent parameter. This User-Agent typically includes the manufacturer, type/model, version, and the OS. Here are some common UA strings:
Avaya Communicator for iPhone\3.1
Grandstream SIP UA 1.0.4.23
Avaya Communicator\3.0
eyeBeam release 3002s stamp 15131
You can configure your SBC to only allow certain types of endpoints (devices) to connect while rejecting (or reporting) the others. This way, every endpoint connects to the SBC and waits for its approval to enter.
How Organizations Use User-Agent Filters
As we saw above, every endpoint type has its own identity in the form of its UA string. In most organizations across the globe, typically only a few device types and software applications are standardized for use by internal IT teams.
This means that an organization can identify and list down the complete list of UA strings across all their approved device types. (This list should ideally contain no more than 10 or 20 such UA strings.)
The #1 mistake companies make and how hackers benefit from it
The most common mistake companies make is not setting the UA field in their SBCs. Let’s see why this is a problem
At a basic level of an attack, script kiddies use ready-made tools to attempt to hack SBCs. These tools use a variety of UA strings to present various identities to the SBC. Going back to the school example, think of it as an attacker trying to send 20 kids to your school, each with a different uniform — in the hope that one matches your school’s uniform.
What you can do?
Set the UA filter in your SBC to allow only those endpoints approved by your IT team. This ONE step alone removes you from the risk of widespread reconnaissance attacks.
In the later sections, we show you how you can do this for your SBC.
While setting UA filters is a great idea, you may have realized that it could pose an implementation challenge. Apps receive updates as frequently as every week. That means that their UA strings change every time users update their apps.
How can the IT team standardize this?
Thankfully, there’s a solution. SBCs support wildcards for the UA filters. You do not need to specify the exact version, but rather you can specify a “*” to allow a range. E.g. to allow all Grandstream phones above version 1.x, you could use a * at the end. Eg:Grandstream SIP UA 1.*
A note of caution
It’s important to know that the UA filter is a very basic deterrent and does not secure your SBC 100%. But you’d be surprised at how many basic attacks it can protect you from.
Here are some additional tips for you to consider while setting UA fields.
- Pro-tip 1: Make sure you do not have too many user-agents in use or effectively, too many endpoint types approved for use. This clearly indicates that there is scope for improvement in the standardization or enforcement processes.
- Pro-tip 2: To find all the unique User-Agents in use, scan your SBC logs, filter out the UA line, and grab all the unique ones. You can do this manually. Or, you could use Assertion’s simpler automated method to do this.
To know how this UA fix can protect your SBC, we take you through a real-life example in the next section.
How a UA filter could have averted a million-dollar attack: A case study
A top telecom operator in the Middle East lost millions to a recent attack — one that a UA filter could have averted. Let us dig deep and see how the chain of events unfolded and how having an effective User-Agent filter could have helped.
Here’s the background: The telecom operator had an Avaya SBCE in front of an Avaya Aura setup. Forensic analysis of the attack showed that the attacker used a relatively well-known technique of “Reconnaissance – Target – Brute force – Toll fraud”.
- Step 1: Reconnaissance – The attacker used standard tools to scan for all extension numbers valid at the SBC — by sending a REGISTER message to a range of extensions starting with 1001 and going up to 99999 with a default password. The user agents used in the attack were “Avaya Agent”, “Avaya Deskphone”, “Avaya Onex Deskphone”
- Step 2: Target – Once the attacker got a valid rejection message from the SBC about an invalid password for a few extensions, they narrowed down valid extensions to break into.
- Step 3: Brute force – With these extensions at their disposal, the attacker brute-forced their way into guessing the correct 4-digit password. Eventually, they broke into one of them.
- Step 4: Toll fraud – Once they took over one extension, they launched calls to premium-rate numbers across the world using that number, running up a massive toll fraud.
Here’s where things get interesting. The attack could have been stopped at the very first step by using a robust user-agent filter. All the endpoints in the customer network were of the type “Avaya Communicator”. If only this UA filter was set, the reconnaissance step would have been a real hurdle for the attacker.
As you can see, the UA filter is a very important gate that can stop reconnaissance attacks or make it more difficult, buying you precious time. Eventually in the game of security, if the odds of breaking your defense are too low, the attacker is bound to go elsewhere, looking for low-hanging fruits.
Combining UA filters with other security measures like URI filters, DoS/DDoS parameters, CAC settings, and many more fortifies your defense. Having robust monitoring in place in addition to a strong defense ensures that SBCs are protected at all times.
How you can set your SBC’s UA filter?
SBCs of all the top vendors support the capability to administer the UA filter. The location on the UI and the approach may vary, but the inherent functionality is present in all the SBCs. Do check this parameter on your SBC and make sure it is set today.
Here’s a handy guide to help find this configuration on your SBC.
| SBC vendor | Where is the UA filter configured? |
| Avaya | Check the administration webpage under“Endpoint flows -> Subscriber flows -> User-Agent” |
| Audiocodes | Check the Classification and ensure that the Message Condition configured has the User-Agent regex. |
| Oracle | Check the Header Manipulation Rule for User-Agent header |
How we can help
Assertion® SecureVoice™ is purpose-built to detect, block, and prevent threats and attacks that pass through your SBC. The UA filter is one of the hundreds of parameters that it checks. It provides you real-time threat protection against Toll Fraud, Telephony Denial of Service, Robocalls, Vishing, and Remote Worker Attacks.
Curious to see what this looks like in action? Talk to us for a custom POC.
Write to us at sales@assertion.cloud.