So two separate clients of mine got nailed separately during the week. In both cases the root cause was a combination of weak passwords on SIP accounts, and public Internet connectivity.
For VoIP service providers obviously public Internet connectivity is not negotiable. Often clients are able to set their own passwords. Usually you get bent over the table pretty quickly – fortunately in the latter case one can just have a disclaimer which purely serves as an income protector – it does NOT save your business relationship with your client. In the case of PABX systems usually they are behind a firewall that only allows connectivity from the local network, but we had one case now where the router “accidentally” (misconfiguration due to misunderstanding of how the router’s DMZ and port-forwarding functionality works – not configured by ULS) forwarded SIP traffic to the VoIP server (router was set up to forward all traffic instead of just TCP/22 for ssh).
So in the case of a publicly accessible VoIP service – what can be done to protect both your client and yourself?
How toll fraud actually works
Firstly, I’m not a cop, a lawyer, a criminal master mind, an accountant, an attorney or a judge. This is how I understand it and my understanding may be wrong and misguided, or at the very least there will be variations on this.
Basically there are two types of fraud, but they’re both the same. The first and simplest is the case where there is a negative price jump. Eg, Johny pays ULS R1/min for a call and ULS pays it’s upstream R2/min. Now Johny somehow gets a cut from that R2 (presumably some cut larger than R1). Now all Johny does is call his own number via ULS, pays us R1/min and gets (eg) R1.50 out, so makes 50c/min for simply leaving a phone on his desk. Now he realizes his premium number has a PRI – and ULS allows higher than one concurrency so nails us at 30 concurrent calls and makes R15/min. Gettting scarier. Now, what if you could phone on someone else’s account? Now he makes R1.50/min/call or R45/min. Now, even if ULS did charge the exact same R2/min that we pay Johny wouldn’t care, someone else is footing the bill.
With SIP this is actually as simple as high-jacking email or http traffic. Just trust me – it’s relatively simple. Find a SIP server, brute-force a username + password – profit $$$
This article considers methods of restricting and hopefully eliminating the damage.
Pre-paid
Jip, believe it or not but this actually works. Granted you need to deal properly with call concurrency or your client will run up a negative credit but the fraud WILL get stopped. Fortunately ULS can handle quite crazy call concurrencies on our platform correctly. Of course we’ve had our pitfalls in this respect too and we’ve lost a few fingers, but all in all it’s working now and even at multi-reseller levels it does what it’s supposed to.
This method purely limits the damage that can be done. However, trust me, when a client with R2000 pre-paid credit loses it in a single day – they are understandably angry.
Firewalls
So the first of the clients this week said what about firewalls and continued on the fact that they’ve spent large sums of money on firewalls to protect all their clients etc etc. The problem with a firewall is that even when it’s on and working as intended it’ll still allow all traffic to the exposed services (eg, SIP). Now, there are probably protection mechanisms you can put in place to detect things, but at an appliance level you will pretty much need to perform layer7 inspection of the SIP packets, looking for an excess of authentication failures (not authentication prompts, SIP/2.0 401 Authentication Required, vs SIP/2.0 403 Access Denied). Sounds way too much like work.
On the asterisk server itself it’s possible to just tail the logs looking for failed registration attempts. Grab the IPs, if the same IP appears more than n times – blacklist the IP. Simple. Effective. Overly so. As it turns out when users configures PABX systems they usually get the secret or authentication details wrong a few times before they get it right and the effect here is over zealous. We still use this strategy on our core switches where the actual SIP credentials doesn’t get handed out until we (or the reseller) have created it – thus reducing this risk somewhat. We also don’t block any IP with an active registration.
Again, highly effective, even in reducing load on servers (these damn scanners care not about your systems, they just want to make money), but also extremely effective in cutting legitimate users’ service.
Characteristics of Toll Fraud
Right, so a few things we’ve picked up in the SIP world … these fraudsters care not about system resources, they will call at whatever concurrency you allow them (if it wasn’t for this they’d quite possibly get away with it). They will make a few test calls and then increase concurrency over time. Based on the access patterns I’ve searched for it seems as if the most prominent dialers will make a few long-standing calls with shorter calls inbetween (presumably to try and hide or something). However, they all, without exception (on all cases we’ve picked up), escalates the concurrency very quickly.
Essentially what we’re looking for is ways to detect toll fraud and to block them as soon as they land. I reckon we can do this with the total damage of a handful of calls.
Characteristics of Normal Use
There are two cases of “normal”. Yes, they do differ but they are still similar. When normally a phone is connected to a SIP account it’s very seldom that a phone will make more than one call. It does happen, but it’s the exception rather than the rule. I have yet to find an example where the same phone makes a second call to the same number (legitimately), but I guess this can happen. Right, so when we have a single phone and call concurrency goes to two – probable false alarm. If it’s to the same number, alarm bells. When call concurrency goes above 2, and especially if the destination number is the same – CODE RED! Nail that fraudster!
From a PABX call concurrencies are of little use (We’ve had clients racking up to 35 concurrent calls over a single DSL line – yes I know your VoIP provider is going to tell you this isn’t possible – come to ULS, we will prove it – I hope I actually have enough phones in the office). However, again, based on records of a few million calls I find very few examples of the same B numbers that’s originating from the same source (PABX) where the calls overlap. So like the single user/phone, if we have multiple calls to the same number, alarm bells, same number at concurrencies higher than 2 – HIGHLY probable toll fraud.
Strategy to nail them in their tracks
Note that this has not yet been tested in any way. In fact – I don’t own a premium number, nor do I have one of these war dialer jobs. So I’ll have to test with a single phone as best I can to ensure that my heuristics triggers and that it works, but only time will tell if it actually stops any toll fraud.
Firstly, there may well be legit reasons for violating the constraints provided here, so however you implement this, you MUST have a mechanism for whitelisting certain destination numbers. So the basic idea is as follows:
# When a number gets called, check whether the dialed number is in the white list. If so, allow the call and let it through unmolested.
# If the dialed number is in our auto-accumulated black list – reject the call (for the first few call attempts you probably want to send some early media indicating why the call is getting blocked).
# If there are no other calls with the same source (ULS will use the concept of a trunk, generic variant of sip and/or iax/2 account) and dialed number, let the call through unmolested.
# At this point we know there is already a call with the same source and dialed number (I will call this call the blocking call), so:
## If this is one of the first n (I like n=2 for no good reason whatsoever) such calls since the blocking call started, play back an error message and terminate the call (actual cause to be used is your pick, BUSY is as good as anything).
## Add the number to the auto-accumulated black list and drop it like a hot potato
In any error message played back to the caller you should provide instructions on notifying you (either via automated system response or by giving your number or something – exact details beyond the scope of this conceptual article :p).
There is a few alternative ideas for the first n calls. My brother came up with the concept of randomly picking a digit from 0 to 9 and requesting the user to press that digit. If the same dialed number passes this test x number of times it goes into the whitelist. Each missed digit press counts as an additional call (in which case n=2 is probably still good but when the fraudsters start sending random dtmf down at us a higher value of n will also be sufficient). The downside of this is voice recognition. And seeing that we’re mostly using pre-compiled audio clips they can actually just hard-code the appropriate G.729, GSM, WAV, PCMu, PCMa etc stuff from asterisk straight into their war dialers (Do use custom voice tags – at a minimum it will for the moment make your system a harder target than the neighbor by forcing to actually spend some CPU on actually doing voice recognition).
How about putting the caller on hold in the first n call attempts and only once n concurrent calls are reached do we blacklist and drop the lot?
Conclusion
I don’t think this is bullet proof by a long shot. At worst it will cause you headaches due to clients bitching and moaning that they can’t call. At best it’ll restrict toll fraud to a particular number to one or two calls. Chances are they’ll learn and start reducing their concurrencies to one per busted server if this gets implemented too far and wide. If not – well, kudus for ULS. At a concurrency of one at least the damage also gets controlled. Eg, even at R10/min we get nailed at R600/hour or R14000/day. The fraud that triggered this writing was rated at half of that, ran for around 16 hours and caused significantly more damage at an average concurrency of 3.6.
Jaco,
Kristoff tells me you are the Linux guru. I just need help on 3 things if you may?
1. How to do shortcuts for all users on Ubuntu?
2. How to mount a file share on Ubuntu from a Windows 2008 server share?
3. Using likewise to authenticate, how can we auto mount a drive according to the login credentials given?
Hi Thato,
Inappropriate location to post I reckon. I’m not an ubuntu user, so won’t know where the shared desktop folder is located where you can dump those shortcuts, it’ll typically be under /usr/share somewhere.
Regarding mount, depends on how it’s exported, but you’re probably looking at using the samba utitlies. Probably something like smbmount //servername/share /mnt/mount/point.
You can look at pam_mount for the auto-mounting of shares depending on credentials. All of this is well explained in the various man pages, they are big though, but you really should read them proper. Especially the smbmount one.
Excellent analysis. One thing that struck me right away after reading is that you must remember to white list emergency numbers. If case of a fire, there’s bound to be a lot of calls from the same customer to the emergency service.
It’s been suspected that some cases of fraud originate from rouge calling card operators. They use open systems for dialling expensive international destinations. I heard of a case where the calls were set up to different destinations on Cuba. It is one of the most expensive destinations apart from satellite calls. I’m not sure how to best handle that. The above approach would not cover it, since the destinations are different for each call. However, a prepaid billing system would eventually catch it, limiting the damage.
In my systems I do log long term both the IP addresses from which each and every call gets originated, as well as keep track of registrations. It may be an idea to analyze these too and limit calls to originate from the registered location. Those operators is not likely to risk registering to the trunk in order to avoid being discovered. This will cover the case where they place a call directly via a “weak” password, but not the case where they high-jack a PABX system.
That might explain why some ITSPs give a 200 in response to a wrong authentication too, and just discard it. And you can’t call unless you’re calling from the registered location. So yes, that too would help with avoiding fraud.
I wonder how one would detect that at the ITSP level if the PABX gets knocked.
Best is still to keep your systems secure and avoid checks like these actually becoming required.