Blue VOIP Systems Misconfiguration for Locked Shields 2014

The article aims to examine misconfiguration of Cisco Unified Communications Managers 8.5.1 (CUCMs) that represented the core of pre-built VOIP infrastructure for the Locked Shields 2014 exercise. We (Green VOIP team members) developed Blue VOIP systems with working but improper security configuration in order to make them more vulnerable against Read team hack attempts.

Cisco Unified Communications Manager Misconfiguration

1. Compromising the Default Application Users  - CUCservice and WdSysUser

They are several default application users created after CUCM installation that CUCM does not allow to delete. However it is highly recommended to change their the passwords and if possible to decrease their privilege level. We modified configuration of the default applications users cucservice and wdsysuser in a following way:

  1. Passwords were changed to dictionary based words, contained 5 characters in total, small letters only
  2. Default privileges were escalated for both accounts so all settings under the following pages could be changed:
    • Cisco Unified Reporting
    • Cisco Unified CM Administration
    • Cisco Unified Serviceability

Thanks to this misconfiguration the Red could take full control of CUCM, for instance change / delete

  • Application and end users (except default application users)
  • Routing plan, devices (phones, Trunks)
  • Disable audit logging
  • Stop / start Feature and Network services

1.1. Configuration steps for privilege escalation of the application user CUCservice

a. First we created a new role Standard CCM Reporting User copying the role Standard CCMADMIN Administration and renamed to the Standard CCM Reporting User with the description Allows application users to generate reports from various sources.

b. Then we created a new role Standard Alarm Collection and selected an option Cisco Call Manager Serviceability. We configured the description Realtime Trace Collection and enabled an option Grant access to all.

c. After that we created the user group Standard CCM Reporting and added Application User CUCservice to this Group.

d.  As a last step we assigned the roles Standard CCM Reporting and Standard Alarm Collection to the user group Standard CUCM Reporting.

cucservice__user_configuration

Picture 1 - CUCservice Application User Configuration

Explanation: Application user CUCService is a member of  the Standard CCM Admin Users by default. Adding the user to the group Standard CCM Reporting that contains the role Standard CCMADMIN Administration (masked behind the name Standard CCM Reporting User) and the role Standard Alarm Collection (with granted access to all options) we technically allowed anyone logged as cucservice user to change configuration under:

  • Cisco Unified Reporting
  • Cisco Unified CM Administration
  • Cisco Unified Serviceability

Question: How the Blue could distinguish non default roles and user groups from the default ones? First of all, default roles and group have no checking buttons presented in the configuration as it is shown on the picture below. For this reason they cannot be deleted. Similarly, non-default roles and user groups can be selected by clicking on check button.

non-standard_roles

Picture 2 - Non standard Roles Checkbox

 1.2. Configuration steps for privilege escalation of the application user WDSysUser 

We assigned an application user WDSysUser to the user group Standard CCM Super Users hoping that the Blue did not discover that the user had assigned super user privileges.  The account was intended to be a backup account for login to CUCM in case of revealing of CUCservice account.

wdsysuser

Picture 3 - WDSysUser Application User Configuration

 2. CUCM Root Password Recovery

We used standard Linux root recovery procedure to change the password for a user root to get access to the underlying RedHat 4 Linux system. By default root access to CUCM is secured by password known by Cisco TAC only. We change password to the 6 character length dictionary word, containing small letters and one digit.

The password recovery procedure for CUCM is described here.

3. Deleting  Audit logs

We disabled logging and deleted logs in order to prevent the Blue to find out changes we had done in system. If the Blue considered logging useful they could easily enable it by their own.

3.1. Configuration Steps for Deleting Audit Logs

From the Cisco Unified Serviceability we navigate to the Tools-> Audit Log Configuration-> Application Audit Log Settings and uncheck options -> Enable Audit LogEnable Purging, Enable Log Rotation. Then  save configuration clicking on the Save button. Rrestart CUCM from CLI with the command utils system restart. When  CUCM boots up,  check if they are any audit log files presented with the command:

file list activelog audit/AuditApp/*.

Use the the command below to delete logs:

file delete activelog audit/AuditApp/*

disabled_audit_logs

Picture 4 - Disabling Audit Logs

4. Call Restriction not Implemented While Auto Registration Enabled

We configured Blue CUCMs to allow auto registration of Cisco IP phones. On one hand auto registration is very useful feature that helped us to register Cisco IP phones that had not been configured in CUCM database. On the other hand, it can be extremely dangerous specially in case when no call restriction is implemented on CUCM and parking partition configured for auto-registered phones. In our scenario, auto registered phones were automatically put in the default None partition and automatically configured with the default None Calling Search Space (CSS).

This configuration allowed all auto registered phones to match  route and translation patterns configured with the default None partitions. Thanks to this default but insecure configuration, all phones including those that were automatically registered could dial any number, including Tallinn land lines numbers 06XXXXXX and Paid service number 0999.

As we could noticed, the Red VOIP team widely abused this misconfiguration registering their softphones to Blue CUCMs. However these attempts could be easily noticed and detected by the Blue as the red phones were using different IP subnets comparing to legitimate Blue phones. Ii addition, the read soft phones used Skinny protocol instead of SIP protocol.

 End.

One thought on “Blue VOIP Systems Misconfiguration for Locked Shields 2014

Leave a comment

Your email address will not be published. Required fields are marked *