VOIP voicemail hacked aka DISA toll fraud
-
@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.
-
There are only 10k 4 digit pin combo's anyways. It's never been a very secure mechanism, and without some sort of lockout for too many bad guesses, it's trivial to break any pin.
-
@Donahue most phone systems have a lockout function enabled. If this phone system did or didn't I don't know. But I also don't know if a 4 digit pin was the maximum length a pin could be.
-
@DustinB3403 said in VOIP voicemail hacked aka DISA toll fraud:
@Donahue most phone systems have a lockout function enabled. If this phone system did or didn't I don't know. But I also don't know if a 4 digit pin was the maximum length a pin could be.
true
-
@Donahue said in VOIP voicemail hacked aka DISA toll fraud:
There are only 10k 4 digit pin combo's anyways. It's never been a very secure mechanism, and without some sort of lockout for too many bad guesses, it's trivial to break any pin.
Assuming it's a four digit limit. If so, that's on Cisco, at least that part of it.
-
Not all phone systems let you rack up long distance via voicemail, either.
-
@scottalanmiller said in VOIP voicemail hacked aka DISA toll fraud:
@Donahue said in VOIP voicemail hacked aka DISA toll fraud:
There are only 10k 4 digit pin combo's anyways. It's never been a very secure mechanism, and without some sort of lockout for too many bad guesses, it's trivial to break any pin.
Assuming it's a four digit limit. If so, that's on Cisco, at least that part of it.
Which honestly wouldn't be surprising. . .
-
On this subject, Twilio blocks almost everything not NANPA by default.
I just checked, this is all you can call
North America: US & Canada
South America: Brazil
Europe: France, Germany, United Kingdom
Asia: India, Israel, Japan
Oceania: Australia/Cocos/Christmas Island -
The documentation for the Cisco Unity system says there are policies that can be set for the voicemail pin, including minimum length, the duration an account is locked, if an admin has to manually unlock an account etc.
-
@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.
I have adopted this same belief. My customer who I managed their phones asked me if we could just setup auto billing - I told them yes, but then they were at the mercy of hackers if they were hacked and how high the bills would be.
In this case, the customer decided that 4 months of normal billing would be tolerable to loose if hacked versus having to refresh the money more often than 3 times a year.i.e. let's say they spend $50/m normally. They will preload the account with $200 which should last 4 months. Now they only have to add more money three times a year, not monthly.
-
@Dashrender said in VOIP voicemail hacked aka DISA toll fraud:
@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.
I have adopted this same belief. My customer who I managed their phones asked me if we could just setup auto billing - I told them yes, but then they were at the mercy of hackers if they were hacked and how high the bills would be.
In this case, the customer decided that 4 months of normal billing would be tolerable to loose if hacked versus having to refresh the money more often than 3 times a year.i.e. let's say they spend $50/m normally. They will preload the account with $200 which should last 4 months. Now they only have to add more money three times a year, not monthly.
Correct. that is how I handle it wit clients. they determine how much to pre-load, but I never let them turn on auto-renew without signing a waiver of liability. So far no one has signed it.
-
Most of our customers control their own accounts, so if they pre-load or not doesn't come through us. But we never recommend just having it auto-load.
-
@scottalanmiller said in VOIP voicemail hacked aka DISA toll fraud:
Most of our customers control their own accounts, so if they pre-load or not doesn't come through us. But we never recommend just having it auto-load.
Some do, some do not. But when it is all set up the first time they are told that it is not allowed without signing a waiver that charges are not my problem.
Of course one could change it afterwards, but none have yet.
-
@DustinB3403 said in VOIP voicemail hacked aka DISA toll fraud:
The documentation for the Cisco Unity system says there are policies that can be set for the voicemail pin, including minimum length, the duration an account is locked, if an admin has to manually unlock an account etc.
After the fraud, the VOIP provider has implemented stronger policies for PIN's now. I will be talking to them about implementing some sort of stoppage on international calls after they hit a certain limit. We are also going to take a hard look at turning off international calling and/or picking specific countries that we need to contact.
-
@scottalanmiller said in VOIP voicemail hacked aka DISA toll fraud:
Most of our customers control their own accounts, so if they pre-load or not doesn't come through us. But we never recommend just having it auto-load.
With this customer - it's kinda 50/50. When I get the renewal notices (and they get them too) i remind them to log in or give me a CC to add more money.
-
@magicmarker said in VOIP voicemail hacked aka DISA toll fraud:
@DustinB3403 said in VOIP voicemail hacked aka DISA toll fraud:
The documentation for the Cisco Unity system says there are policies that can be set for the voicemail pin, including minimum length, the duration an account is locked, if an admin has to manually unlock an account etc.
After the fraud, the VOIP provider has implemented stronger policies for PIN's now. I will be talking to them about implementing some sort of stoppage on international calls after they hit a certain limit. We are also going to take a hard look at turning off international calling and/or picking specific countries that we need to contact.
Yeah, that's pretty much all you can do. Police your own people, investigate why voicemail was allowed to do as much as it was (maybe getting off of Cisco is part of your solution, not sure how many systems are really susceptible to voicemail attacks in this manner), find out how voicemail was accessed without access to something more, have the vendor lock down anything that could explode usage that isn't needed like calls to countries that you'd never made, and put in some kind of rate limiting.
There is always going to be some risk, but you can reduce it in both likeness of happening again, and in the scope of potential damage.
-
@JaredBusch is FreePBX susceptible to this kind of attack? On none of ours is voicemail ever the first line of defense, first of all. But even if someone breached voicemail, I don't think that they can use that to make calls. I know some systems do, and Cisco is pretty renowned for lacking security, and I might easily be overlooking something, but I feel like this isn't a normal attack vector outside of the Cisco world.
-
@scottalanmiller said in VOIP voicemail hacked aka DISA toll fraud:
@JaredBusch is FreePBX susceptible to this kind of attack? On none of ours is voicemail ever the first line of defense, first of all. But even if someone breached voicemail, I don't think that they can use that to make calls. I know some systems do, and Cisco is pretty renowned for lacking security, and I might easily be overlooking something, but I feel like this isn't a normal attack vector outside of the Cisco world.
IIRC it is possible but disable by default.
