[cisco-voip] Root Access via UCOS Remote Support

Wed Oct 11 22:01:46 EDT 2017

Good to know, thanks for the tip!

________________________________
From: bmeade90 at gmail.com <bmeade90 at gmail.com> on behalf of Brian Meade <bmeade90 at vt.edu>
Sent: Wednesday, October 11, 2017 5:22 PM
To: Pete Brown
Cc: Chris Ward (chrward); cisco-voip at 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 <jpb at chykn.com<mailto:jpb at 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) <chrward at cisco.com<mailto:chrward at cisco.com>>
Sent: Wednesday, October 11, 2017 1:02 PM
To: Pete Brown; cisco-voip at puck.nether.net<mailto:cisco-voip at 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

chrward at cisco.com<mailto:chrward at 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-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net>] On Behalf Of Pete Brown
Sent: Wednesday, October 11, 2017 1:54 PM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at 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 at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20171012/5d9165e0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2530 bytes
Desc: image001.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20171012/5d9165e0/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 134 bytes
Desc: image002.gif
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20171012/5d9165e0/attachment.gif>