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/pdCheckLogin.do?name=undefined


The response contains a reference to the login.do 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/login.do?sid=_sid_value_&userid=_userid_&pin=_PIN_



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: http://portswigger.net/burp/help/options_sessions_macroeditor.html

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!

Comments

  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?

    ReplyDelete
    Replies
    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.

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

    http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/7_0_1/ccmcfg/b08crpol.html#wp1038402

    ReplyDelete
    Replies
    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 ;-).

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

    ReplyDelete
  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/pdCheckLogin.do?name=undefined (to get sid value)
    /ccmpd/login.do?sid=SIDVAL&userid=USERID&pin=12345 (try logging-in; if we get XML w/o error, we're good)
    /ccmpd/pdLogoutPage.do?sid=SIDVAL (initiate logout)
    /ccmpd/logout.do?sid=SIDVAL (confirm logout and close session)

    Cheers, Eric

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

      Delete
  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.

    ReplyDelete
  6. PoC for this :-)

    http://pheneghan.blogspot.be/2015/04/poc-for-cracking-cisco-pins.html

    ReplyDelete

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 authenticate through the c…

Microsoft .NET MVC ReDoS (Denial of Service) Vulnerability - CVE-2015-2526 (MS15-101)

Microsoft released a security bulletin (MS15-101) describing a .NET MVC Denial of Service vulnerability (CVE-2015-2526) that I reported back in April. This blog post analyses the vulnerability in details, starting from the theory and then providing a PoC exploit against a MVC web application developed with Visual Studio 2013.
For those of you who want to see the bug, you can directly skip to the last part of this post or watch the video directly... ;-)

A bit of theory

The .NET framework (4.5 tested version) uses backtracking regular expression matcher when performing a match against an expression. Backtracking is based on the NFA (non-deterministic finite automata) algorithm engine which is designed to validate all input states. By providing an “evil” regex expression – an expression for which the engine can be forced to calculate an exponential number of states - it is possible to force the engine to calculate an exponential number of states, leading to a condition defined such as “ca…

UXSS in McAfee Endpoint Security, www.mcafee.com and some extra goodies...

During the HITB2017AMS talk given in Amsterdam with @Steventseeley, I promised that I would have disclosed vulnerabilities affecting a security vendor product other than Trend Micro.

For those who have come to my blog for the first time and are looking at "insecurities" of security vendors, you might be interested as well on how we found 200+ remote code execution vulnerabilities in Trend Micro software...

But this blog post is dedicated to two McAfee products instead: McAfee Endpoint Security and SiteAdvisor Enterprise (now part of McAfee Endpoint Security). For simplicity, I will just refer to McAfee Endpoint Security for the rest of this post.

First let's demonstrate a particular type of XSS, a UXSS, considering that fact that it only affects the McAfee Endpoint Security plugin and does not depend on a particular web site or web application.

There are two different injection points:

-UXSS when user visits a red labelled web site - the payload is rendered in the BlockP…