Thanks to everyone who responded. The routine is now compatible with decoder versions 1, 2 and 3. So far it has worked with every passphrase tested from 8.5 up to 12.
You can decode your own passphrases at the following address. This should go without saying, but if you root a production box, TAC can review the logs and refuse to support it. This is meant for lab use. Use at your own risk. www.adhdtech.com/passphraseDecode.php<http://www.adhdtech.com/passphraseDecode.php> ________________________________ From: cisco-voip <cisco-voip-boun...@puck.nether.net> on behalf of Pete Brown <j...@chykn.com> Sent: Wednesday, October 11, 2017 9:01 PM To: Brian Meade Cc: cisco-voip@puck.nether.net Subject: Re: [cisco-voip] Root Access via UCOS Remote Support Good to know, thanks for the tip! ________________________________ From: bmead...@gmail.com <bmead...@gmail.com> on behalf of Brian Meade <bmead...@vt.edu> Sent: Wednesday, October 11, 2017 5:22 PM To: Pete Brown Cc: Chris Ward (chrward); cisco-voip@puck.nether.net Subject: Re: [cisco-voip] Root Access via UCOS Remote Support You can get the platform-config.xml without root. utils create report platform On Wed, Oct 11, 2017 at 6:11 PM, Pete Brown <j...@chykn.com<mailto:j...@chykn.com>> wrote: Chris, I understand and respect your position on this. I agree that allowing root access to any machine is akin to giving someone a loaded gun to kill their system. Obtaining root access not blessed by TAC would invalidate any support agreements for a host. That being said, it's very frustrating when you know TAC has the ability to assist in a situation but policy prevents it. A perfect example is UC admins who work in an environment where the cluster security password has been lost over time. Yes, you're an admin and yes, it's technically possible to actually retrieve the cluster security password. But the official position is no; you have to reset it and take an outage on every host in your cluster. With root access, it takes less than 5 minutes to SSH into a UCOS host, download the platformConfig.xml and decode the cluster security password. It gets worse in DR situations. In the last two months I've received requests for help from a couple UC admins affected by recent hurricanes. One of them was running CUCM 8.6 and it was technically possible to modify the XML and do a DRS restore without knowing the previous cluster security password. TAC's response? Sorry, can't help. Even though Cisco had a backdoor in the backups for years and could have helped restore, they would not use it to assist a customer whose primary datacenter was knocked offline. Besides, anyone with admin level rights to a host (or the hypervisor) has de facto root access. As we've all seen, a quick Google search shows that rooting a UCOS host is a trivial matter if you have access to the hypervisor. The only real difference here is that this method requires rights within the application to enable the root access. Aside from being useful in lab environments, this route provides a last ditch resort where the cluster is out of support or TAC cannot assist due to policy constraints. And I say policy constraints because I know for a fact they have capabilities they don't employ for customers. At one time, nearly 10% my tool downloads (DRS Backup Decrypter, PlatformConfig Decrypter, etc.) came from Cisco's own IP addresses. So while I do agree with you when it comes to the potential harm this could cause, I would respectfully disagree on whether or not the benefit outweighs the risk. -Pete ________________________________ From: Chris Ward (chrward) <chrw...@cisco.com<mailto:chrw...@cisco.com>> Sent: Wednesday, October 11, 2017 1:02 PM To: Pete Brown; cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net> Subject: RE: Root Access via UCOS Remote Support Pete, As a Cisco employee, I would ask that you not publish such a tool. It’s dangerous and will probably create more problems than you are trying to solve. Obviously, I have no authority to stop you but I have forwarded the message to the product team to ask them to re-evaluate the algorithm they are using to make sure this account password process remains a Cisco-only process. [logo_Grey] Chris Ward ENGINEER.TECHNICAL MARKETING chrw...@cisco.com<mailto:chrw...@cisco.com> Tel: +1 408 894 3751<tel:(408)%20894-3751> Cisco Systems, Inc. 500 Beaver Brook Road BOXBOROUGH 01719 United States cisco.com<http://cisco.com> [http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]Think before you print. This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Please click here<http://www.cisco.com/web/about/doing_business/legal/cri/index.html> for Company Registration Information. From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net<mailto:cisco-voip-boun...@puck.nether.net>] On Behalf Of Pete Brown Sent: Wednesday, October 11, 2017 1:54 PM To: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net> Subject: [cisco-voip] Root Access via UCOS Remote Support I'm testing a routine that translates remote support passphrases into account passwords. So far it works on 10.5.2, but I'm guessing it will work with any passphrase ending in '03'. Before I post a web page or utility for this, I'd like to test it out with other versions. If you have lab environment and wouldn't mind helping out, enable remote support and send me the passphrase (along with source product/version) off list. I'll reply back with the decoded password. _______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip