Hacked Calls via Embedded Voicemail

[Pepp77]

We have a customer who had a little bit of fraud last night on their SIP trunks, but the SIP was not their route into the system it would seem, as this system is all digital users with no H323 or SIP registrar active on the system and looking at the audit trail/system programming there was no intrusion into the config.

The only thing I did see was congestion showing on the voicemail around the time it was happening (2am) and they did have a DDI pointing to voicemail for remote access to check messages. I decided to delete the incoming route for this number and delete the catch all so that if the calls were coming into the voicemail SSA would show me under config alarms.

Low and behold I have just checked and there have been 39 attempts to call into the number that I removed from the programming.

So my question : what exploit is there in the embedded voicemail on a 500v2 on 10.0.0.3.0 Build 5?

| ACSS SME |

 

[janni78]

The things that come to mind is "Call the message sender" or they configure "Outcalling".

"Trying is the first step to failure..." - Homer

 

[Pepp77]

On further investigation it turns out FNE 31 might have been active on a duplicate of the same DDI number, but already removed by 1st line before asking me to have a look. So will be investigating further in the morning, as am happy no further fraudulent calls are happening (I also added a time profile and barred ARS to the system, so only 01 and 02 numbers can be called overnight).

| ACSS SME |

 

[Pepp77]

I managed to find a config from a couple of months ago that showed the number that I can see calls being made to was not setup for FNE and was just configured to point to Voicemail.

| ACSS SME |

 

[janni78]

They shouldn't be able to use FNE31 unless they manage to spoof a CLI that is entered in Mobile Twinning.

Did they actually manage to make any calls or did they just try to hack it via VM?

"Trying is the first step to failure..." - Homer

 

[Pepp77]

First night they made about 50 calls, second night nothing as the DDI they were dialling was no longer programmed.

| ACSS SME |

 

[Okkie26]

Maybe a vm box with a breakout option to an external number?

 

[IPGuru]

Had one of these recently

Fraudster calls in with a spoofed CLI & leaves a message, hey then call back & access the mailbox (Mailbox had week passcode) dialling ** to return the call thus initialising the connection.

If remote access to VM is not required then remove the VM passcode on all users
If remote access is req then either program known Secure numbers (using V<number> in source numbers) or users must set a secure password ( my policy is to remove the VM passcode & insist that the individual users set themselves from the handset if necessary)

if off switch transfers are not required this can be disabled in current firmware releases.





Do things on the cheap & it will cost you dear