Partager via

Is your Exchange Unified Messaging protected against telecommunication fraud?

  • Article

What is Telecommunications Fraud?
Telecommunications fraud is the process of exploiting a misconfiguration in telecommunications systems to gain access to your telecommunication platform to make calls on your behalf.

Few things that are really bad about this type of exploit:

  • The exploiter don't even need an internet to perform such hack.
  • The exploiter doesn't need your users PIN
  • It can be very costly.
  • it can go unnoticed for a long time, or till you get a surprise bill.
  • The exploiter caller ID will be your company number, might pretend to be your company representative.
  • it can even be so bad that they can sell calling cards to use your system for long distance calls.
  • other scenarios are left for imagination...

While Lync/SfB and Exchange UM doesn't have a DISA feature (direct inward system access ) the below mix of configuration can cause a serious leak in the system to allow telecom fraud even when your users have a secure voicemail PIN.

Lets first have a look on how that could be possible:

When you configure Lync/SfB integration with Exchange UM via the OCSUtil ; two contacts are going to be created in Lync/SfB and assigned automatic Dial Plan and Voice Policy.

  1. The Auto Attendant contact
  2. The Subscriber access contact

Also you in exchange UM an important component will be populated by running the exchUCUtil script which is the "virtual" 1:1 IP gateway.

Now lets go to the configuration:

I've seen a lot of companies now avoid the short extension assignment in Lync/SfB and just use E164 format with 10 digit North America DID for the users' line URI.

so when they start the integration with Exchange UM they will need to assign Exchange UM extensions for the users in Exchange, and to simplify things, they will use that 10 digit DID as an "Extension".

So far that is not going to cause an issue until they enable "Allow calls to Extension" in the UM dial plan, UM mailbox Policy or the Auto attendant.

Configuration of my lab was the following:

  • 7 and 10 digits North American plan is configured in SfB/Lync at the Default,Pool or Site Dial plan to allow E.164 normalization.; Also if you dont have Default,Pool or Site dial plan normalization defined and created Translation rules on Global trunk normalization to capture 10 digits coming from the Trunk and normalize to E.164 that will also work.

  • SfB Users have 10 digits DID normalized in E.164;  e.g: (lineURI is +1(NPA)XXX-XXXX)

  • Exchange UM dial plan is 10 digits extension and "allow calls to extensions" is enabled on Dial Plan , Auto Attendant and UM mailbox Policy

  • 10-digit policy calls-to-extencalls-to-exten-aa

With this configuration the following scenarios was dialled:

  1. Scenario 1:  Caller dials the AA number and as it prompts to dial an extension, I dialled any 10 Digits number (eg.my mobile) and the call was made outside of my SfB server. so for that to happen:
    • A- The Extensions expected are 10 digits based on the UM dialplan
    • B- ExUM send that through the 1:1 IP gateway.
    • C- The 7 or 10 digit Extension will get Normalized to E.164 on the SfB Global, Site or Pool Dialplan which is the default/automatic dialplan for the UMAA object OR on the Trunk Global number translation.
    • D- The UMAA contact object that was created by the OCSUtil has the default Global or Site voice policy that has a route to terminate E164 digits on the PSTN.
  2. Scenario 2: Caller dials the SA number and navigate till it prompts to dial an extension, I dialled any 10 Digits number (eg.my mobile) and the call was made outside of my SfB server.
  • A- The Extensions expected are 10 digits based on the UM dialplan
  • B- ExUM send that through the 1:1 IP gateway.
  • C- The 7 or 10 digit Extension will get Normalized to E.164 on the SfB Global, Site or Pool Dialplan which is the default/automatic dialplan for the UMSA object OR on the Trunk Global number translation.
  • D- The UMSA contact object that was created by the OCSUtil has the default Global or Site voice policy that has a route to terminate E164 digits on the PSTN.

ps

  • 3.   Scenario 3: Caller dials any SfB DID number and timeout to voicemail the caller press **## then it prompts to dial an extension, I dialled any 10 Digits number (eg.my mobile) and again the call was made outside of my SfB server.
    • A- The Extensions expected are 10 digits based on the UM dialplan
    • B- ExUM send that through the 1:1 IP gateway.
    • C- The 7 or 10 digit Extension will get Normalized to E.164 on the SfB Global, Site or Pool Dialplan which is the default/automatic dialplan for the Referred User (In that case the SfB Dialed/Voicemail User ).
    • D- The Referred User has the Global, Site or User voice policy that has a route to terminate E164 digits on the PSTN.

 

Below is a flowchart of my lab findings that I logged and how the call could be routed outside of your system from an anonymous caller.

 

exum-routing2

 

 

That was the problem now for the solution:

For the First and Second Scenario where the Caller Dials the AA and SA you need the Allow Extensions dialling to be enabled in both the UMdial Plan and Auto Attendant, the reason is that you may have a PBX that is behind the SfB server that the legitimate caller might need to call.

So the solution is to assign both the AA and SA objects a Voice Policy and a Route that ONLY routes to PBXes without PSTN access (if your PBX are 7 or 10 digits) ; if your PBX extensions is less than the UMDial plan, it will not route anyway. Also you can remove the Associated Trunk altogether from that Route so if the number isnt found in SfB Server it doesn't leave to any where.

ps2

 

But for the Third Scenario where the caller dials the voicemail and then press **## you wouldn't be able to change the voice policy as the Referrer is the SfB user.

So you will need to do the following:

  1. Turn off "Dial by Extension" from the UM Mailbox Policy to prevent callers from dialing on behalf of the user being dialed.
  2. Redirect the Caller to the Operator only; where they can dial other Internal Extensions from the Auto Attendant or Subscriber Access after we apply the restrictive voice policies as discussed above .

You will have to turn off the "dial by extension" from the UM Mailbox Policy. But at the same time you can enable the caller to dial (0) at the voicemail prompt to transfer only to the operator.

For a caller to be transferred to an operator, the caller must press 0 on their telephone keypad while the user's custom voice mail greeting is being played.

If the user has not created a customized voice mail greeting, the default system greeting will be used and the system will add the operator prompt automatically.

For example, "Please leave a message for Tony Smith. To speak to an operator, press 0."   If the caller does not press 0 during the voice mail greeting, they can leave a voice message for the user.

If you have not configured a personal operator extension for a user, or if you have not correctly configured the dialing rules on the UM dial plan that is associated with the UM-enabled user, the Unified Messaging server will use the operator extension number that is configured for the dial plan. The default digit to reach the dial plan operator is 0.

For that '0' Operator feature to work you have to configure dialing rule groups for the (UM) dial plan in the Exchange Server.

After you create a dialing rule group, you must add a dialing group entry.  After you create the dialing rule group and configure the dialing rule entries, you must add the dialing rule group to the dialing restrictions on the UM mailbox policy associated with the UM dial plan.

When you add the dialing rule group to the dialing restrictions on the UM mailbox policy, the settings you use will apply to all UM-enabled users associated with the UM mailbox policy.

Creating those Dialing groups and rules will allow the following features for the Users:

1- The ability for callers to press 0 at the voicemail to transfer to an operator

2- Ability to play on Phone for the applied Users from the OWA voicemail settings

3- Ability to use follow me settings from the OWA voicemail.

You'll probably find it unnecessary to build patterns in the dialing rules or dialing rule groups in Exchange Unified Messaging.

SfB Server voice policy will perform call routing and number translation for the corresponding users when the calls are made by Exchange Unified Messaging on behalf of users , so you can use the wildcard * for the Mask number and dialled number to allow any digits from the user OWA voicemail features like play on phone and/or follow me.