A growing problem
Like a slice of Victoria sponge cake on a summers day attracts wasps, so new technologies seem to attract the attention of cyber-criminals. The more widely used the technology, the greater the interest. It was inevitable, and widely predicted, that VoIP would become a favorite target for hackers as its popularity and uptake increased – it has the accessibility of an email server combined with the potential for fraud of an online bank account. Irresistible!
And so it has come to be. The level of sophistication and the number of attacks against VoIP servers and PBX’s has gradually escalated over the years and then really taken off in the last 12 months. Automated port scanning and security probing can be seen many times a day, even on IP addresses that are not part of any published SIP service. What is more, each new attempt seems to come from a different IP address! This makes it harder to just block them at the firewall and indicates that the would-be hackers are using a botnet. Another possibility is that the source address is being deliberately spoofed. This would make it difficult to detect the true source address which is masked by the “noise” of many randomly generated addresses. Whatever the mechanism, it suggests that the hackers are really serious about their undertaking and expect to make a lot of money out of it.
What are the hackers hoping to do?
In most cases they want to find a weakness that will allow them to make long distance, international or other chargeable calls for free. The numbers that get called are often in African countries, but I have also seen North Korea and others. One service provider told me that China is a popular destination. This is often described as “toll fraud”. In some cases, the fraudster is reselling the hijacked call time from your server to unsuspecting end users who think they have signed up to a legitimate call service (or who don’t care if it is legal as long as it is cheap). Alternatively, the numbers being called are on a premium rate service – this allows the fraudster to collect part of the call charges directly to their own bank account.
Another possibility for an attack on your systems would be DoS (Denial of Service). Asterisk servers are not that good at handling floods of SIP requests, so once someone has identified your server it would be relatively easy for them to fire hundreds of requests at it with the intention of bringing it to its knees. Deliberate DoS attacks are not common compared to toll fraud. However, brute force password guessing can have the same impact as a DoS attack – see “password guessing gone crazy” below.
Toll fraud is clearly the main issue today. However, the time may come when unwanted spam calls (enjoying the delightful acronym of SPIT) are as big a problem as toll fraud. When that happens, it will present administrators with a whole new set of problems.
What do the attacks look like?
SIP port scanning – locating target servers
Port 5060 is the standard SIP port and the first step for the would-be hacker is to send a SIP request to this port to see what response comes back. If you can use a non-standard port or block all access at the firewall except from addresses known to be trusted, then it will elevate your protection to a completely new level. However, for most VoIP applications this is simply not possible.
Probing requests may come in the form of a SIP INVITE, REGISTER or OPTIONS request. I have recently seen a big increase in OPTIONS requests that come from a wide range of Internet IP addresses, but they contain certain elements that identify a common ancestry. First, all the requests have the User-Agent field set to either “sundayddr” or “friendly-scanner”. Second, they often identify their origin as “sip:100@1.1.1.1”, “sip:100@192.168.1.9” or similar. It may not be possible to block or even detect these if you are using an Asterisk server, but in OpenSIPS, I recommend that you drop the packet rather than send any response.
Password guessing
Once a SIP server has been identified, vulnerabilities can be searched for. I have seen Asterisk logs that clearly show an initial scan where an attempt is made to register on every extension number from 10 to 9999. The response coming back tells the attacker if that extension exists (bad password) or does not exist (not found). Then, armed with a list of your extensions, the second phase of the scan will keep trying hundreds of passwords on a known extension.
Password guessing gone crazy
Under some circumstances (possibly when Asterisk is more tightly locked down than usual) the password guessing attack seems to get stuck in an endless loop. It sends REGISTER requests for various randomly named accounts in a relentless and unceasing stream at a rate in excess of 80 per second. I have written an article dedicated just to this one problem and its solution. Click here to be linked to the relevant article.
Open relay
If the SIP server has been configured by an inexperienced person who perhaps did not appreciate the risks, then the worst case scenario would be that your Asterisk server will accept INVITE requests from any Internet address without any password being required and connect the caller to destinations on the PSTN. I’m glad to say that Asterisk, Trixbox or FreePBX will not generally do this “out-of-the-box”, but it would be easy to tweak the dial plan such that it could. For many years, I have seen evidence in the logs of SIP requests to numbers on the PSTN, often with various prefixes, in the hope that they will hit the jackpot.
Weaknesses in the server
This form of exploitation is more likely with OpenSIPS than with Asterisk because the rules and routing logic in OpenSIPS are almost completely under the control of the installer and system administrator rather than the authors of the product. With a protocol as complex as SIP, there is plenty of scope for missing some detail or assuming a function behaves one way when it actually behaves in some subtly different manner. One of my clients was caught out by a weakness in the handling of deliberately malformed From headers. A function that should return true if the SIP domain is local would return false when the caller’s number was missing. This meant the calls were not being challenged for a password yet would then be handled as if coming from an authenticated user. Such mistakes can be very costly.
The human factor
Remember that not all IT fraud takes the form of a unknown third party hacking into your systems from the Internet. A disgruntled or dishonest employee finding they have access to account passwords or the ability to add a hidden access route, may be tempted to exploit their position of trust. As a VoIP service provider, you may find you are approached by clients who talk of temptingly large and growing volumes of traffic that they want to put through your service. They might be very believable and indistinguishable from a legitimate client, but it may not always be what it appears. Your billing systems need to be able to stop traffic from a client whose credit limit has been reached. And always get advance payment for your minutes!
Protecting your Asterisk server – part 2
In part 2 of this article, I will be looking at the ways you can protect your Asterisk PBX and other SIP server services.
You don’t mention blocking Asterisk intrusion attempts that fail2ban (www.fail2ban.or) can block, or blocking based on geographic region like SecAst (www.generationd.com) can block. Or detecting if someone has already broken in and is using your PBX resources. Blocking the middleast and china alone dramatically reduce the exposure of our PBX.
Fail2ban is mentioned in part 3 in the context of preventing Denial of Service attacks. However, you’re right it would also help to prevent password guessing or other intrusion attempts that involve multiple requests from the same source. Blocking based on geographic region may not be appropriate for all and didn’t look viable when I wrote the articles in 2010. I now generally block ranges of IP’s esp for Palestinian Territories. Most recently, I find that intrusion attempts often come from USA, France and other countries you might not guess. Detecting when someone has already broken in has to really be dealt with by the Billing and credit control software or by detecting unusual call patterns so is a bit outside the scope of what I was trying to cover. However, it should have been mentioned.
These three articles were written about 3.5 years ago and focused on explaining what the basic problem was (not as well understood then as today) and on how to harden a standard Asterisk box. It would be great to update them, giving more emphasis to FreePBX and exploring some of the newer solutions being offered now, but my time is limited. You will find a more recent article on this site reviewing the Pika uFirewall. Do you publish info about your experiences?