Unlock Cucm Account

[Mateos Weinzapfel]

Forthe sake of anyone who comes across this post and wants to know what the resolution was for the above thread, the problem was that you do not enter the password at the end of the command. Just enter the command and then the CLI will prompt you to enter the new password twice (2nd time is for verification).

The below command will require you to enter a new password for the UI admin account. If you want to keep the same password you'll need to run this command twice because it will not allow you to use your previous password. First time you run it, enter a new password. The next time you run it, you can reuse your desired password (essentially unlocking the account).

This reply is very useful, and I found that you must keep in mind the last password.

It's important and it could be typing error when you modify the password.

This command can set new password directly.

If you must use the same password, you must modify one and modify the same one, again.

System also prompt the result you modified.

After all, It's more danger that forget the password for cli, and good thing that I don't forget the cli password.

I just typing error for three time and the account locked, like the original post.

This blog is about something I found recently regarding Cisco Unified Call Manager (CUCM). While playing around with SeeYouCM Thief, which is designed to download parse configuration files from Cisco phone systems, I noticed something interesting within a configuration file. There was an XML element in the configuration files named . The value pointed to _server:8443/cucm-uds/users and to my surprise upon navigating there it returned an XML document containing a bunch of Active Directory users. Curious, I wanted to learn more.

The users resource provides search functions to locate users stored in the Cisco Unified CM database. Often times, and as was the case for my client, this database is linked directly to Active Directory via LDAP/LDAPS.

Pulling data from the API was simple, but it did have some constraints. By default, this API call only returns a maximum of 64 results. If the user search result exceeds the number specified, it returns only partial results up to the specified search limit. To enumerate beyond the first 64 entries in database, it was possible to make multiple queries with query string parameters to filter the data.

Today, I work as a Penetration Tester. Instead of designing and troubleshooting networks, now I get to break into them to test their strength. Usually, the first task of an Internal Penetration Test is to try and gain access to a low-privileged account. Since the pandemic made us shift to working from home, many of our common man-in-the-middle (MitM) attacks were neutralized due to a lack of adjacent clients.

Typically, the SSH credentials we identify in the phone configuration files are not Active Directory passwords but instead are valid authentication credentials for the Cisco Unified Communications Manager (CUCM) web interface. From within the CUCM, we can perform an authentication pass back attack and capture the Active Directory credentials configured for the LDAP protocol. Occasionally, the accounts you discover in the configurations are domain credentials. Sometimes the credentials are even members of the Domain Admins group! This post will walk through the hack step by step and explain .

The first step is to find a Cisco phone on the network. One trick I like to use is monitoring for Cisco Discovery Protocol (CDP) packets that come across the wire. Within these packets, you can find information regarding the voice VLAN. Once we identify what the voice VLAN is, we can configure our network interface to communicate on that VLAN along with any devices on it. This almost always allows me to quickly and quietly identify a phone's network.

After the phone subnet has been identified, a quick Nmap scan of port 80 will indicate which systems are active. Once you identify the web interface of a phone, you can glean valuable information from the phone including where the CUCM server is located. Additionally, you can identify the filename of the phone's configuration file by appending .cnf.xml.sgnto the phone's hostname, which is always SEP.

Now I can manually download the phone's configuration files just like the phone does at boot using TFTP. Unlike FTP, the TFTP service does not allow for directory listings. Therefore, identifying the configuration name of a valid phone is important. In some rare instances, there is a file labeled ConfigFileCacheList.txt. If this file exists, it will contain all the filenames located in the TFTP directory. This file does not always exist on the CUCM, and I'm still unsure why.

Additionally, the CUCM server has an HTTP service on port TCP/6970 that shares the same root directory. Since the HTTP protocol is much easier to interface with programmatically, this interface works perfectly for automating configuration discovery and downloading.

More information about ConfigFileCacheList.txt and the HTTP service can be found at the following cisco address: -communications/unified-communications-manager-callmanager/200408-Retrieve-Phone-Configuration-File-from-T.html

Once all of the configurations are downloaded, I parse each one looking for Plaintext passwords. After the plaintext passwords are discovered, the first thing I do is try to log in to the CUCM web interface.

Using the -p parameter, I can specify a phone's IP address. The webpage of the phone is scraped to identify the CUCM IP address. If the ConfigFileCacheList.txt exists on the CUCM, then all the filenames are parsed and each configuration is automatically downloaded.

Ok, so now what? How can you stop me from doing this attack? Modern CUCM systems do support a way of encrypting the phone configurations. This feature would effectively stop this attack path. I find, in my experience, this feature is not widely deployed. My personal recommendations are to:

If you want to ensure your employees stay in touch and productive, empowering them to make minor changes to their unified communications (UC) accounts without involving the IT or UC teams is a great way to start.

Self-service user provisioning refers to a process in which users within an organization are empowered to create, modify, or delete their own accounts and access to various systems, applications, and resources.

Instead of relying on IT or UC administrators to handle these tasks manually, self-service user provisioning allows individuals to make those changes on their own in the applications themselves or, more preferably, within a user-friendly interface or portal.

The Cisco collaboration suite contains several different UC applications, including Voice-over-IP (VOIP) communication (i.e. a Cisco IP phone), Jabber instant messaging, Unity Connection voicemail, Webex Meetings, Webex Teams and various call center products.

Within those applications, different users will have varying levels of access to make changes to the information within those accounts. Usually, self-provisioning in CUCM lets any user make changes to these functions:

In many cases, enterprises restrict all access to provisioning functions to admin-level IT or UC engineers. This leaves end-users with little control over their accounts. While this may sound unnecessary, there are reasons why enterprises choose to restrict that access at the expense of efficiency and productivity.

Some enterprises restrict provisioning access to IT or UC admins, no matter how simple the task, for security reasons. Without the proper solutions and protocols in place, there are security risks associated with self-service UC provisioning.

Additionally, users might inadvertently (or intentionally) grant themselves excessive permissions when provisioning accounts. This can lead to data leaks, breaches, or accidental system changes with potentially serious consequences.

If self-service UC provisioning is not integrated with centralized access control systems, it can result in inconsistent permissions and access policies. Not only does this make it harder to manage security effectively, but it also makes user account setup and CUCM management inconsistent.

Configuration portals allow end users to log into a separate application where they can securely change the information they need without accessing the UC application information directly.

An automated solution for provisioning can help you grant better role-based access to critical systems within these applications by taking the ability to change and manipulate user data out of the hands of regular employees.

With the right automated provisioning solution, you can empower your users to regain full control over their UC accounts without the risks of malicious intent or accidental outages. This will unlock several benefits for your organization.

Many organizations also run more than just Cisco for UC. As remote and hybrid work takes over, many organizations are turning to Microsoft Teams and Zoom. This leads to complex, hybrid UC environments that become even more of a challenge to provision and manage end-users.

The right automated UC provisioning solution allows you to integrate your entire UC provisioning onto one platform, whether through native integrations, API or even API triggers. This allows for simple self-service provisioning in those applications too.

Once connected, an automated UC provisioning solution can act as a hub connecting user information across much of your corporate tech stack. User information can flow without any manual work from the UC team or a service desk.

In terms of consistency, automation ensures that user provision jobs will be done the same every time. Removing manual intervention in UC account provisioning eliminates variability in how different provisioners might configure accounts.

3a8082e126