1.1      Intro

I spent my early IT career working for a Cisco partner that specialized in Cisco phone systems. My work wasn’t directly with the phone systems, but it was usually in an adjacent field like route/switch and security. I did, however, get to see my share of networks that used Cisco phone systems.

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.

In this post, I’m going to discuss common misconfigurations that I’ve seen in environments that deployed Cisco phones. Exploiting these issues usually results in the successful compromise of the phone systems and allows for an initial foothold within the Active Directory environment. TrustedSec has released a tool SeeYouCM-Thief that makes exploiting this common mistake trivial.

A client followed up after an Internal Penetration Test and said that they had discovered plaintext credentials within some of their Cisco phone configurations. They wanted to know if we had ever seen this before. While reviewing their findings, I realized that plaintext credentials stored in the phone's configuration were configured for the SSH service of the phone. This setting is used if an administrator wants to connect to a phone, which is not a required or commonly used feature. It occurred to me that this username and password field was filled out in error by the individual adding the phone. Not only did this individual make this same mistake, but as it turns out, it’s a very common mistake overall.

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 .

1.2      Manual Hack Walkthrough

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.

tcpdump -nnvi eno1 -s 1500 -c 1 'ether[20:2] == 0x2000'

For example, if using VLAN 19, on Ubuntu you can create a sub-interface using the following commands.

modprobe 8021q
vconfig add eno1.19 19
ifconfig eno1.19 up

Here, I create the sub-interface and use tcpdump to identify ARP traffic.

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<Mac address of the phone>.

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: https://www.cisco.com/c/en/us/support/docs/unified-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.

Once I have access to the CUCM web interface, I go to the LDAP Authentication settings and update one of the servers to be my IP address and click save.

By using Responder, I'm able to capture the plaintext password for the pre-configured Active Directory service account. Now we have a foothold within Active Directory.

1.3      SeeYouCM-Thief

I developed a tool called SeeYouCM-Thief that automatically detects any usernames or plaintext passwords in Cisco phone configurations stored on a CUCM.

python3 thief.py -p <phone ip>

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.

If the ConfigFileCacheList.txt does not exist, an error message will be displayed. Don’t worry, this isn’t the end of the world! The script has also been configured to enumerate phones using reverse DNS and forced browsing against a subnet.

1.4      Conclusion

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:

• Do a bulk update to all phones and use a Honeycred, or a fake user account that is used for monitoring.
• Configure your SIEM to monitor for anyone trying to use that account.
• Monitor the usage of the service account configured for the LDAP process in CUCM.
• Use a dedicated account and make sure the account does not contain any administrative privileges in AD.

SeeYouCM-Thief can be found on github at the following URL: https://github.com/trustedsec/SeeYouCM-Thief