Judging from my recent experience, at least one North American SIP trunk provider has not understood the importance of SIP authentication.
While working on a customer’s VoIP system, I noticed that SIP messages sent from their PBX to their SIP trunk provider were triggering an immediate response, without the usual authentication challenge.
This meant that the trunk was not bothering to authenticate call requests, leaving the system open to a toll fraud and other attacks.
The SIP standard specifies a challenge/response authentication mechanism. A well regulated SIP trunk should implement this.
When a device such as PBX attempts to make a call, the trunk should refuse the initial request and challenge the PBX to re-try with the appropriate authentication credentials. When the requesting device receives this challenge, it uses information stored in its configuration database to respond.
The North American trunk provider (who will remain nameless) had issued authentication credentials for the SIP trunk circuits, and the customer had diligently added this information to the PBX’s configuration database.
Unfortunately, for a reason that still remains unclear, the provider seemed unable to configure their own systems properly, so both registration requests and call requests went completely unchallenged. This problem has two very serious consequences.
Firstly, given some basic information on the trunk provider including details of the phone numbers, it is possible for any Internet connected SIP device to make calls. These calls would be billed to the customer. I verified this by making an international call to my own cell phone.
Secondly, because the trunk provider is also failing to authenticate registrations, it is easy to for an attacker to register his own PBX which will then receive all calls made to the registered phone. I ran my own tests, and was able to dial the North American number and confirm that the call was routed to one of my test systems in London. This is call hijacking made easy!
The most worrying aspect of this is that because the problem was caused by issues with configuring equipment at the trunk provider, it is very difficult for the end-user to detect the problem; at least until the first phone bill arrives.
Sadly, my customer was not alone. Checking a block of 10,000 consecutive phone numbers with the same area code, I was able to find other numbers with similar problems. The trunk provider has been informed of these issues.
The lesson is clear; any SIP trunk user should carefully check the security of their own systems but also check that the provider has done their job.
The alternative is to wait for the phone bill, but you be in for a nasty surprise. One Australian company recently received a £57,000 bill.