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!
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?
ReplyDeleteWhat versions of UCM have you reviewed for this vulnerability?
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.
DeleteThis is not a vulnerability. Just turn on lock out policy.
ReplyDeletehttp://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/7_0_1/ccmcfg/b08crpol.html#wp1038402
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).
DeleteAt 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 ;-).
This hack doesn't work on 7941 IP Phone who seem not included the handset function configuration
ReplyDeleteThanks for your post. I intend to use this for default PIN auditing.
ReplyDeleteMy 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
Yes, that's the exact sequence you might want to script or automate with a macro, e.g. using Burp.
DeleteThis 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.
ReplyDeleteHowever, I do not know if the lockout policy would prevent horizontal brute force. Probably not. It's a good thing to test.
PoC for this :-)
ReplyDeletehttp://pheneghan.blogspot.be/2015/04/poc-for-cracking-cisco-pins.html