Domain accounts, website accounts, phone system accounts, and any other account that requires a user to log in to perform certain tasks or access secured data are vulnerable to attack and probably always will be. The reality is that if an attacker can authenticate as a valid user in a given system, the attacker can then do anything that the compromised user has permission to do in that system.
For an Interactive Intelligence phone system, the purpose of an attack is typically international toll fraud... though it could be MUCH worse. An attacker could change a voicemail greeting to request sensitive information from callers, could activate unplanned schedules to shut down a call center, or worse. Remember, once an attacker compromises a user account, the attacker can do anything that the user has rights to do in the system.
Here is an example of a typical attack against an Interactive Intelligence Customer Interaction Center system:
- Call company main number
- Select menu option to dial by name and gather a list of user extensions
- Return to main menu and attempt remote access (see if option exists in main menu)
- If option does not exist in main menu, dial a user's extension to be directed to their voicemail and press * to attempt to access default profile
- Use remote access feature to try different combinations of user extensions and passwords (ext + 1234, ext + ext, ext + 0000, etc.)
- Once a user account has been compromised, use one of the following 2 methods to perform international toll fraud
- Change user's status to Available, Forward at an international number, then call user directly to be transferred to that number
- Reply to a voicemail message at an international number to be connected to that number
Using this method, an attacker can leverage a target system to fill up the system's line capacity and potentially make thousands of dollars in international toll calls in a relatively short period of time. Keep in mind that the attacker is NOT exploiting a vulnerability in the system, but simply leveraging a system feature. As far as the system knows, the attacker is a valid user.
Any system operates with a balance of usability vs. security. The simplest way to protect against basic attacks like this is to remove the remote access feature… but doing this would remove a number of very useful features including remote presence management and messaging.
Here are a number of methods a system administrator can use to prevent and mitigate attacks against a CIC system:
- Implement good password policies:
- Consider requiring at least 5-digit CIC account passwords
- Do not allow sequential digits (12345)
- Do not allow the same digit to be used more than once
- Require passwords to be changed often
- Do not allow the same password to be used time after time.
NOTE: It is currently possible for a user's password to be the same as the extension as long as it complies with the password policy. This should be strongly discouraged. There is also currently no method to perform a security audit to ensure that user passwords comply with their assigned policy. If your system has been compromised, it is currently easiest to reset all user accounts passwords. In Interaction Administrator, select multiple user accounts, right-click, and select Set Password… Select the Generate and e-mail random password(s) option and click OK.
IMPORTANT: Simply assigning a secure password policy is not sufficient to protect the system as it only requires that passwords meet the policy when they are changed. If a user never logs into the system (and therefore is not prompted to change the account password), the password may not comply with the assigned policy.
- Re-route the Default Profile in Interaction Attendant – One of the most common methods of attack is to attempt to access the default Attendant profile and use the default remote access method (9, 9, ext, pwd, #). Remove all prompts, timeouts, repeats, and fax listeners from the Default Profile and the schedules beneath it, then add a menu transfer for each schedule as the default action to send all calls to a different profile, perhaps for the main company number. This will prevent an attacker from using the Default Profile in its out-of-the-box configuration.
IMPORTANT: If you need to use some of the advanced features included by default in this profile (such as multisite), be sure to create these elsewhere and route calls appropriately.
- Don't prompt users for account information – When providing users with a remote access method, don't play prompts telling them what to do ("Welcome to XYZ voicemail. Please enter your extension and password…"). Play something less obvious like a beep or tone sequence. This prevents an attacker from being told what they need to do.
- Restrict international calls to specific country codes – If you know that your organization only calls a handful of specific country codes, consider creating dial plan entries that reference a list of allowed country codes and then re-route all others to an invalid internal extension. This will limit the ability of attackers who do compromise a user account to successfully re-route calls to the international number of their choice.
- Remove option to reply to a voicemail at a different number – If this option is not used by the organization (and the server license allows handler customization), the base handler SystemIVRReplyMessage can be modified to remove the capability to reply to a voicemail message at a custom number.
IMPORTANT: Base handler customizations are not supported by Interactive Intelligence. This should only be done after careful consultation with your ININ partner.
Remember that the first line of defense, when remote access is allowed, is the account password. An account with an insecure password is a vulnerability. The impact of a successful attack can be reduced with good planning and configuration, but it is best if an attacker finds it too difficult to compromise a user account.