VOIP voicemail hacked aka DISA toll fraud
-
My VOIP provider has made me aware that we have been victims of a voicemail hack which I believe is known as DISA toll fraud. Our voicemail system was perpetrated for the purpose of placing long distance calls at the expense of our company. The malicious user(s) took advantage of a weak PIN/password in voicemail.
The malicious user racked up a large 5 digit number in charges to the Caribbean Island. All these calls took place over a 5-day period. Our VOIP provider is telling us the international call activity did not generate any alarms at the time. They are saying the user(s) were able to disguise the activity from them seeing the source calls. I guess the Caribbean Islands utilize US style area codes and are often overlooked.
The voicemail is a Cisco Unity system. The VOIP provider provides the infrastructure and support for the VOIP phone system. They are saying they are not responsible for the maintenance of user logins and PINs within the Cisco Unity system along with the pass-through dialing option within the Cisco Unity system.
They ended up resolving this by applying and forcing a stronger voicemail PIN policy at our expense. I have a call with the VOIP provider tomorrow with their services team to discuss the charges and the events in more detail. Ok, the voicemail PINs were weak which caused the toll fraud. However, we are not managing the phone system infrastructure and we don’t manage the alerts. I don’t feel like my VOIP provider protected us from the large long distance bills and I’m trying to understand how they are able to put the long distance bill on us. I would love to hear the reactions and comments regarding this from the MangoLassi users before I’m on the call tomorrow.
-
@magicmarker said in VOIP voicemail hacked aka DISA toll fraud:
I don’t feel like my VOIP provider protected us from the large long distance bills and I’m trying to understand how they are able to put the long distance bill on us.
So the $10,000 question here is... to what degree was or is it their responsibility to do this?
Under normal circumstances, it is not their responsibility in any way. Now that might not be the case here, because they are also the managers of the phone system. But even then, you'd need a 100% solid contract that said that they were not only responsible for attempting to avoid hacking, but also providing insurance against being hacked anyway. And I've never heard of any consulting or service company willing to do that.
Think of it as an IT department. If you had your systems hacked, even though you were trying to secure things, do you think that the management should make the IT people pay for the damage that was caused by a third party? No, it's completely unreasonable.
When something bad like this happens, it's a natural, emotional reaction to want to find a scape goat. And maybe there is one. But take a minute and empathize, chances are, this isn't their issue and not their risk.
-
@magicmarker said in VOIP voicemail hacked aka DISA toll fraud:
Ok, the voicemail PINs were weak which caused the toll fraud.
This, I think, answers everything. If the PINs were weak, and they weren't chosen by the provider, I see no grey area. This particular instance appears to be both legally and ethically completely on the end customer. Ensuring proper security from the end user's (employee's) perspective cannot be that of the provider.
Unless they were told that they had to do this and had the authority and expectation of firing offenders, there is no way for that to be on them. The party hiring and managing the people choosing the PINs is the responsible party.
-
@magicmarker said in VOIP voicemail hacked aka DISA toll fraud:
... However, we are not managing the phone system infrastructure and we don’t manage the alerts. I don’t feel like my VOIP provider protected us from the large long distance bills ...
So this is hard. Basically you have one party (Cisco) trying to make an alerting system to warn you when something looks fishy. Then you have another party (the hackers) trying to make calls not look fishy so that the alarms don't sound. The service provider probably has no means of modifying how the alerts work, they are likely at the mercy of the phone system you chose (Cisco.) Not that Cisco is good or bad here, it just is part of the choice and defines your options.
Like a door lock, you buy a door lock based on how hard it is to pick. But a good thief can pick even the best lock. You can't expect the door lock maker to pay for anything stolen from your house. They do their best, but the thief has more tools at his disposal. If you hold the door lock maker responsible for anything you choose to protect only with their lock, then they'd simply refuse to sell to you and leave you totally exposed with no lock at all.
Alerts can only do so much. They only work when you define what "unusual" looks like and the hacker does something that everyone agreed upon ahead of time as being unusual. And only in a way that the mechanism supports.
For anyone with phone systems, we always either use strong protections (like zero international calling or price limits) that hackers can't get around (or if they do, not our problem); or we always say that it is the customer's responsibility to always audit the calls more or less in real time - because no third party can determine what calls are or are not legitimate. That requires the caller(s) themselves to verify.
-
This is one of the reasons I never setup automatic funding on SIP trunks.
The account will run out of money before things get super out of control.
-
Thank you for your comments Scott and Jared. This is what I needed. I will asking about putting some sort of stoppage on long distance calls so they don't rack up like this. This should be turned on by default for customers to prevent this. Unbelievable.
-
@magicmarker said in VOIP voicemail hacked aka DISA toll fraud:
This should be turned on by default for customers to prevent this. Unbelievable.
And what happens when the business needs to make a legitimate long distance call and can't? Then the customer complains to the provider and other issues ensue.
-
I've been through this myself. Thankfully in my case, it was my own money and not a customer's. This was long, long ago in a different era, but it was a great learning experience. So I've lost more than $10K to this, personally. I learned a lot of lessons.
Some lessons are...
- Phone systems are risky, riskier than you'd think. Huge bills can happen fast.
- As the end user using the system, there is no one responsible for security except for me. Even if I do things perfectly, it is still my responsibility if I'm the one who gets hacked. Just like a store that does everything right, might still get robbed. And while that's awful, it is still that store's responsibility to cover the cost of the damage, not one of their service providers or neighbors. We don't have public funds to insure against "bad things."
- The best way to avoid giant disasters is to not even let them be a possibility. We disable calling that we don't need so that the ability to do damage is trivially small, instead of astronomically large.
- We have "hard monitoring" - meaning service turns off if money is spent faster than anticipated, rather than soft monitoring (just getting an alert that you have to respond to.)
- If even a few extra dollars goes out, we look at the call record and see what calls have happened to make sure that they are all legitimate.
- Don't expose phones to the outside unless you need to. We expose them often, and need to, but only because we have the other controls in place to make that not a real risk.
-
@JaredBusch said in VOIP voicemail hacked aka DISA toll fraud:
This is one of the reasons I never setup automatic funding on SIP trunks.
The account will run out of money before things get super out of control.
Yup, same here. That's what made us change.
-
@scottalanmiller said in VOIP voicemail hacked aka DISA toll fraud:
@magicmarker said in VOIP voicemail hacked aka DISA toll fraud:
Ok, the voicemail PINs were weak which caused the toll fraud.
This, I think, answers everything. If the PINs were weak, and they weren't chosen by the provider, I see no grey area. This particular instance appears to be both legally and ethically completely on the end customer. Ensuring proper security from the end user's (employee's) perspective cannot be that of the provider.
Unless they were told that they had to do this and had the authority and expectation of firing offenders, there is no way for that to be on them. The party hiring and managing the people choosing the PINs is the responsible party.
In regards to this statement. The voicemail policy was set by the VOIP provider. The default voicemail password they pushed out to all the handsets was 1234. So it seems I do have some ground to stand on.
-
@magicmarker said in VOIP voicemail hacked aka DISA toll fraud:
Thank you for your comments Scott and Jared. This is what I needed. I will asking about putting some sort of stoppage on long distance calls so they don't rack up like this. This should be turned on by default for customers to prevent this. Unbelievable.
Yes, when it happened to us, all of the fraud was to Libya. Why was Libya turned on? Because we simply had never thought about it. Now we think about that a lot.
-
@magicmarker said in VOIP voicemail hacked aka DISA toll fraud:
@scottalanmiller said in VOIP voicemail hacked aka DISA toll fraud:
@magicmarker said in VOIP voicemail hacked aka DISA toll fraud:
Ok, the voicemail PINs were weak which caused the toll fraud.
This, I think, answers everything. If the PINs were weak, and they weren't chosen by the provider, I see no grey area. This particular instance appears to be both legally and ethically completely on the end customer. Ensuring proper security from the end user's (employee's) perspective cannot be that of the provider.
Unless they were told that they had to do this and had the authority and expectation of firing offenders, there is no way for that to be on them. The party hiring and managing the people choosing the PINs is the responsible party.
In regards to this statement. The voicemail policy was set by the VOIP provider. The default voicemail password they pushed out to all the handsets was 1234. So it seems I do have some ground to stand on.
The policy doesn't matter. Were they given the ability to fire people if they didn't follow the policy? What power were they given to police the PINs? What did the policy state?
-
@magicmarker said in VOIP voicemail hacked aka DISA toll fraud:
This should be turned on by default for customers to prevent this. Unbelievable.
Well, this is a tough position. Having this on or off is a "feature" offered by different providers. If you want it on by default, there are providers like voip.ms (that Jared and I recommend often) that provide that. Others provide international calling by default.
No matter how you slice or dice it, that choice is one made by the person who selected the provider. Most providers that allow the calling by default, still allow you to shut it off optionally. So there are two layers of protection already - selecting a provider with defaults you want, and then changing the defaults to match your security profile. And there is always the chance that they are off by default, but someone, at some point, said "I want international calling, turn that on!"
Allowing phone calls to International is typically on by default and can't be something to fault the carrier on. I prefer off by default, too. But preferring it doesn't change whose responsibility it is.
-
@magicmarker said in VOIP voicemail hacked aka DISA toll fraud:
@scottalanmiller said in VOIP voicemail hacked aka DISA toll fraud:
@magicmarker said in VOIP voicemail hacked aka DISA toll fraud:
Ok, the voicemail PINs were weak which caused the toll fraud.
This, I think, answers everything. If the PINs were weak, and they weren't chosen by the provider, I see no grey area. This particular instance appears to be both legally and ethically completely on the end customer. Ensuring proper security from the end user's (employee's) perspective cannot be that of the provider.
Unless they were told that they had to do this and had the authority and expectation of firing offenders, there is no way for that to be on them. The party hiring and managing the people choosing the PINs is the responsible party.
In regards to this statement. The voicemail policy was set by the VOIP provider. The default voicemail password they pushed out to all the handsets was 1234. So it seems I do have some ground to stand on.
Um. . . what? I can almost guarantee that their policy was we set a default and your users are expected to change it when they first use it.
-
@DustinB3403 said in VOIP voicemail hacked aka DISA toll fraud:
@magicmarker said in VOIP voicemail hacked aka DISA toll fraud:
This should be turned on by default for customers to prevent this. Unbelievable.
And what happens when the business needs to make a legitimate long distance call and can't? Then the customer complains to the provider and other issues ensue.
Right, this is why most do "on" by default. And why most that are off by default end up turned on anyway.
I like how easily voip.ms let's me turn it on and off, and by single country. Like we had to run interviews in Panama two weeks ago, so we turned on Panamanian calling. But it is like $.50 a minute! So as soon as the interviews were done, we turned it off again.
-
@DustinB3403 said in VOIP voicemail hacked aka DISA toll fraud:
@magicmarker said in VOIP voicemail hacked aka DISA toll fraud:
@scottalanmiller said in VOIP voicemail hacked aka DISA toll fraud:
@magicmarker said in VOIP voicemail hacked aka DISA toll fraud:
Ok, the voicemail PINs were weak which caused the toll fraud.
This, I think, answers everything. If the PINs were weak, and they weren't chosen by the provider, I see no grey area. This particular instance appears to be both legally and ethically completely on the end customer. Ensuring proper security from the end user's (employee's) perspective cannot be that of the provider.
Unless they were told that they had to do this and had the authority and expectation of firing offenders, there is no way for that to be on them. The party hiring and managing the people choosing the PINs is the responsible party.
In regards to this statement. The voicemail policy was set by the VOIP provider. The default voicemail password they pushed out to all the handsets was 1234. So it seems I do have some ground to stand on.
Um. . . what? I can almost guarantee that their policy was we set a default and your users are expected to change it when they first use it.
That's what I would expect it to read as.
-
@DustinB3403 said in VOIP voicemail hacked aka DISA toll fraud:
@magicmarker said in VOIP voicemail hacked aka DISA toll fraud:
@scottalanmiller said in VOIP voicemail hacked aka DISA toll fraud:
@magicmarker said in VOIP voicemail hacked aka DISA toll fraud:
Ok, the voicemail PINs were weak which caused the toll fraud.
This, I think, answers everything. If the PINs were weak, and they weren't chosen by the provider, I see no grey area. This particular instance appears to be both legally and ethically completely on the end customer. Ensuring proper security from the end user's (employee's) perspective cannot be that of the provider.
Unless they were told that they had to do this and had the authority and expectation of firing offenders, there is no way for that to be on them. The party hiring and managing the people choosing the PINs is the responsible party.
In regards to this statement. The voicemail policy was set by the VOIP provider. The default voicemail password they pushed out to all the handsets was 1234. So it seems I do have some ground to stand on.
Um. . . what? I can almost guarantee that their policy was we set a default and your users are expected to change it when they first use it.
Good point. Yes, the user needed to change the PIN after first login.
-
@scottalanmiller said in VOIP voicemail hacked aka DISA toll fraud:
@DustinB3403 said in VOIP voicemail hacked aka DISA toll fraud:
@magicmarker said in VOIP voicemail hacked aka DISA toll fraud:
@scottalanmiller said in VOIP voicemail hacked aka DISA toll fraud:
@magicmarker said in VOIP voicemail hacked aka DISA toll fraud:
Ok, the voicemail PINs were weak which caused the toll fraud.
This, I think, answers everything. If the PINs were weak, and they weren't chosen by the provider, I see no grey area. This particular instance appears to be both legally and ethically completely on the end customer. Ensuring proper security from the end user's (employee's) perspective cannot be that of the provider.
Unless they were told that they had to do this and had the authority and expectation of firing offenders, there is no way for that to be on them. The party hiring and managing the people choosing the PINs is the responsible party.
In regards to this statement. The voicemail policy was set by the VOIP provider. The default voicemail password they pushed out to all the handsets was 1234. So it seems I do have some ground to stand on.
Um. . . what? I can almost guarantee that their policy was we set a default and your users are expected to change it when they first use it.
That's what I would expect it to read as.
It's the same policy that Verizon and company use for all of their customers, business and otherwise. You get a default which might be the last 4 of the number, and when you first login you're required to change it.
Even if you put in the same 4 digits, it's on you the user at that point and not the carrier.
-
@magicmarker said in VOIP voicemail hacked aka DISA toll fraud:
@DustinB3403 said in VOIP voicemail hacked aka DISA toll fraud:
@magicmarker said in VOIP voicemail hacked aka DISA toll fraud:
@scottalanmiller said in VOIP voicemail hacked aka DISA toll fraud:
@magicmarker said in VOIP voicemail hacked aka DISA toll fraud:
Ok, the voicemail PINs were weak which caused the toll fraud.
This, I think, answers everything. If the PINs were weak, and they weren't chosen by the provider, I see no grey area. This particular instance appears to be both legally and ethically completely on the end customer. Ensuring proper security from the end user's (employee's) perspective cannot be that of the provider.
Unless they were told that they had to do this and had the authority and expectation of firing offenders, there is no way for that to be on them. The party hiring and managing the people choosing the PINs is the responsible party.
In regards to this statement. The voicemail policy was set by the VOIP provider. The default voicemail password they pushed out to all the handsets was 1234. So it seems I do have some ground to stand on.
Um. . . what? I can almost guarantee that their policy was we set a default and your users are expected to change it when they first use it.
Good point. Yes, the user needed to change the PIN after first login.
That's what'll get you, I'm afraid. It sounds like the phone provider had a good policy, but policing it had to fall to your HR department or whatever. Unless the phone company had the power and authority and responsibility to see, verify, punish, etc. with customers, there's no way for them to be in the line of accountability. And even if they had all those things, they'd have to agree to provide indemnity on top of that, which they would never agree to, because the Cisco boxes aren't all that secure and if they get hacked that's not their fault nor something they can prevent. And even good PINs can be hacked.
-
There is another aspect, too. And that is that there is such a thing as reverse toll fraud. Meaning, you make a bunch of somewhat unusual calls, rack up a crazy bill, then try to not pay it by claiming it was toll fraud. The phone provider can't tell that the calls were legit (which is why their alarms aren't very useful, either.) They can sometimes tell that they are abnormal for you on a client by client basis, but that requires some serious software to determine. And unusual isn't the same and "not legit."
So one of the reason that they never offer indemnity is because 99% of the time that "hack" can't be traced to anyone, and so they can't tell the difference between a hacked customer and a customer that is just trying to not pay their bill.
Compare it to someone breaking into your house, hopping on your computer, and surfing some websites. The website can tell that you don't often go to that website, but it has no way to know that it is or isn't you.
