Skip to main content

Cisco Unified Communications Manager (Call Manager) PIN brute force attack

During a security review, I have found a quick way to perform PIN brute force attack against accounts registered with a Cisco Unified Communications Manager (CallManager). A quick google "callmanager brute force" didn't bring any relevant results, so I thought to share the simple technique I have used.

When looking at the phone handset configuration, some URLs are set to allow the handset to retrieve Personal Address Book details or access the Fast Dials. That caught my attention and I immediately pointed my web proxy to those URLs, forgetting about the handset interface.

What happens when using the handset is that the handset itself performs HTTP requests to the CallManager.

A simple HTTP GET request is performed by the handset to initiate the login sequence with a request as the one below:

1) GET - https://x.x.x.x/ccmpd/

The response contains a reference to the page along with a "sid" token, which is used in the subsequent requests, as shown in the response below:

The sid token is required to perform the PIN brute force attack.

Also, the response provides some clues on which parameters to include in the login request, such as userID and PIN. The following GET request can then be used to perform a PIN brute force account.

2) GET - https://x.x.x.x/ccmpd/

At this stage, it is possible to perform a PIN brute force attack, as a valid SID token needs to be passed when authenticating the user.

In case the userid/PIN are wrong, the following response is returned:

It seems not possible to perform userID enumeration. In such case, it is recommended to have a large username dictionary file and then try against the same PIN (e.g. common value 1234, 12345). This can be easily done using the Burp intruder tab, as shown below:

If the correct userID/PIN are found, the response will contain links for each service, as shown below:

The above sequence of requests can be trivially automated with a web proxy, such as Burp, by setting a macro for instance.

More information on how to configure macros in Burp, can be found here:

If a valid userID/PIN is found, it is recommended to stop the brute force attack, generate a new sid token and then restart the brute force attack.

Happy hacking!


  1. Interseting find thanks for sharing Roberto. Was the scope of this test limited to personal dicectory and speed dial URIs or did you have the opportunity to test against something more significant such as Extension Mobility Login service?
    What versions of UCM have you reviewed for this vulnerability?

    1. Unfortunately, once discovered the right credentials via the brute force attack I haven't checked if I could login with the same credentials using the Mobility login service, but I suspect it might be the case ;-) if such service is permitted.

  2. This is not a vulnerability. Just turn on lock out policy.

    1. Agreed - it is not a vulnerability per se and I never wrote the word "vulnerability" in the post ;-) It is just a simple technique to brute force credentials of registered accounts (nothing more, nothing less).

      At the opposite, as you know, journalists like to play with words and the word "vulnerability" was used improperly in some of the articles linking to this blog post.

      Regarding the link you pasted, I have a question - would the account policy block brute force attacks, such as one PIN (e.g. 12345) against multiple userID (horizontal approach)? I suspect it doesn't but I might be wrong ;-).

  3. This hack doesn't work on 7941 IP Phone who seem not included the handset function configuration

  4. Thanks for your post. I intend to use this for default PIN auditing.
    My initial testing revealed that the clean sequence required looks like this:
    /ccmpd/ (to get sid value)
    /ccmpd/ (try logging-in; if we get XML w/o error, we're good)
    /ccmpd/ (initiate logout)
    /ccmpd/ (confirm logout and close session)

    Cheers, Eric

    1. Yes, that's the exact sequence you might want to script or automate with a macro, e.g. using Burp.

  5. This technique assumes the call manager administrator is negligent enough to skip lock out policy. Anyone reading your blog is probably smart enough to know better. So, I guess it's something to check for on a pentest, but if someone is running a production call manager without lockout policy they are asking to be hacked.

    However, I do not know if the lockout policy would prevent horizontal brute force. Probably not. It's a good thing to test.

  6. PoC for this :-)


Post a comment

Popular posts from this blog

Pwning a thin client in less than two minutes

Have you ever encountered a zero client or a thin client? It looks something like this... If yes, keep reading below, if not, then if you encounter one, you know what you can do if you read below... The model above is a T520, produced by HP - this model and other similar models are typically employed to support a medium/large VDI (Virtual Desktop Infrastructure) enterprise. These clients run a Linux-based HP ThinPro OS by default and I had a chance to play with image version T6X44017 in particular, which is fun to play with it, since you can get a root shell in a very short time without knowing any password... Normally, HP ThinPro OS interface is configured in a kiosk mode, as the concept of a thin/zero client is based on using a thick client to connect to another resource. For this purpose, a standard user does not need to authenticate to the thin client per se and would just need to perform a connection - e.g. VMware Horizon View. The user will eventually authenticat

Alcatel Lucent Omnivista or: How I learned GIOP and gained Unauthenticated Remote Code Execution (CVE-2016-9796)

It is time for another advisory or better a blog post about Alcatel Lucent Omnivista  and its vulnerabilities. Omnivista is a central management network tool and it is typically used in medium/large organisation with a complex VoIP/SIP infrastructure. Interestingly enough, this software belongs to the niche of "undownloadable" software and it requires a license to work as well. My "luck" came during an engagement where it was already installed and this post documents one of the many 0days discovered during such audit. The reasons why I wanted to dedicate a single blog post on this vulnerability are several. First, remote code execution (RCE) is always a sweet bug to show. Second, I strongly believe that documenting vulnerabilities in applications using old protocols and standards, respectively GIOP and CORBA, can be beneficial for the infosec community, since no many examples of vulnerabilities in such applications are available or published on the Interne

Trend Micro Threat Discovery Appliance - Session Generation Authentication Bypass (CVE-2016-8584)

In the last few months, I have been testing several Trend Micro products with Steven Seeley ( @steventseeley ). Together, we have found more than 200+ RCE (Remote Code Execution) vulnerabilities and for the first time we presented the outcome of our research at Hack In The Box 2017 Amsterdam  in April. The presentation is available as a PDF or as a Slideshare . Since it was not possible to cover all discovered vulnerabilities with a single presentation, this blog post will cover and analyze a further vulnerability that did not make it to the slides, and which affects the Trend Micro Threat Discovery Appliance (TDA) product. CVE-2016-8584 - TDA Session Generation Authentication Bypass This was an interesting vulnerability, discovered after observing that two consecutive login attempts against the web interface returned the same session_id token. Following this observation, our inference was that time factor played a role. After further analysis and reversing of the TDA libra