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

TrendMicro ScanMail for Microsoft Exchange (SMEX) predictable session token - CVE-2015-3326

It's time for another advisory ( CVE-2015-3326 ), a simple one, for a vulnerability which can be found quickly and trivially. For those of you who just want to give a glance at the post, I suggest to directly watch the picture which says it all! The following vulnerability was discovered on TrendMicro SMEX (ScanMail for Microsoft Exchange) 10 SP2 but it affects other versions as well. While surfing the SMEX web administrative interface using a web proxy, I have noticed something in the HTTP request - the session token itself and its format, a number. After observing a significant number of logins, the session token was always represented with an number composed of minimum 4 digits and maximum 5 digits, as shown in the screen shot below:   Although the observed session tokens were never generated sequentially, the lack of a cryptographically strong PRNG for the session identifier, allows a malicious user to trivially guess the token. This attack can be easily automated.

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

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 su