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

Reply via email to