A brute force attack is the most common method of attacking an SBC. The technique is straightforward – use cheap computing resources to keep guessing the password for an extension. Think like this: a hacker learns the IP address and port to register as an extension. Now all the hacker will do is incessantly enter your extension and try one access after another (automatically, of course, that’s what computers are for!) until the right password is found — and your SBC security is compromised.

Why hackers use brute force to hack SBCs

As seen from its name, brute force does not rely on elegance or intelligence. It is usually undertaken by script kiddies – people who rely on simple, off-the-shelf hacking software to attack systems, precisely because it is easy to understand and try. It can be frustrated by some simple hygiene, and yet up to 5% of all successful attacks have been the result of brute force.

In the case of SBCs, it is entirely possible that brute force attacks are actually more successful – because of the distressingly simple requirements that many companies have for extensions and passwords.

SBCs are critical because they protect your communication network – they are the gatekeepers for significant amounts of data – contact centers have access to huge amounts of sensitive data from customers – and hackers love to get their hands of this kind of info. For a company, this is a terrifying thing – the kind of hacking that leads to loss of revenue due to angry customers walking away, loss of reputation in the industry, and the loss of sensitive data.

The anatomy of a hack

• First, the hacker tries to find your SBC’s coordinates – IP and port and protocol 
• Then they try to connect to it on SIP and SIPS (5060 / 5061) 
• They will also check all the services it exposes on the internet to detect its signature (vendor) 
• They will usually send OPTIONS or REGISTER message, emulating an endpoint that your SBC is expected to support (this will help them bypass User-Agent filters of your SBC) 
• They will check if your SBC exposes a reverse proxy. This gives them an opportunity to hunt around for the endpoint configuration file. If they get it, then it’s party time – this can tell them the extension range, the supported UAs, and even sometimes the path of your server certificate. 
• They then establish the transport connection and send an OPTIONS, REGISTER or INVITE message to the SBC to try and gauge its response. 
• Once the SBC responds, the game begins! 
• They try to guess the valid extension range and once they get a valid extension, they guess the password

How do you prevent your SBC from getting brute-forced?

A brute force attack is a simple one that can be prevented by security hygiene.

1. Obscurity – You can make your SBC listen on a non-standard secure port
2. Secure protocols only – Make sure your SBC is only listening on SIPS port (5061) and not listening for non-secure SIP.
3. Controlled Reverse-proxy – If the SBC is also used as a reverse proxy and exposes endpoint configuration files, make sure you only serve those files that are necessary. Also, check the files to ensure that no internal path, or other file names are exposed (certificates get leaked via this manner, so it is important to eyeball check each line of the files being exposed by the reverse proxy)
4. Make sure the SBC protocol stack does not send a lot of “signature” details in its rejection message. Better still, ignore messages instead of rejecting them with an error message. An error message sent out by the SBC will help the hacker detect its signature.
5. Set up User-agent filters to ensure that only the supported endpoints can send a message.
6. Set up URI filters to ensure that only certain extension ranges are supported. Any message from/to an extension other than the supported range can be ignored.
7. Use mutual TLS to connect to remote worker endpoints. Yes, setting up and managing TLS certs for all endpoints can be cumbersome, costly and a management headache, but the security gain is well worth the effort (use tools to make this easier and manageable).
8. Last but not the least, set up passwords that are not extension in reverse, 1234, extension + 1, and so on – super easy to guess passwords. There is some merit to using complex passwords. If your SBC supports it, use AD for authenticating the extension.

If you have any questions or concerns about SBC Security and how it can help you improve your SIP security posture, please get in touch with us at sales@assertion.cloud