Urgent -Security issue - CTS - Pwrecovery thru GUI

[Saurabh Gupta]

Hi Experts,

Ou

• Our client’s security group recently probed the  Cisco Telepresence units we have deployed on their premises/ network for  vulnerabilities.  They found that using a web browser and navigating to the IP  address of the Telepresence unit, they were able to log in to the device with   username = pwrecovery   password = pwreset.    This is unexpected behavior.     It essentially means that despite the fact that we have set a separate private  username/password for the device for our support purposes …… anyone can log into  the unit with the username = pwrecovery   password = pwreset …which is publicly  available info (published in Cisco guides etc).    Once logged in via that  method…..the web user has full access to the Telepresence device to change  parameters etc ….this is unacceptable froma security standpoint.

• In a Cisco guide, cts_troubleshooting …in the section “Resetting Your Codec  Password” the procedure using username pwrecovery is described.   That document  describes that resetting password is using ssh access and requires reading a  randomly generated password off the CTS screen and then entering it during the  ssh session.   There is no mention that using the pwrecovery username and pswd  via the web grants full access to the device.   This seems like a defect as it  negates other security measures.

So the question is,  how do we  prevent login via web browser using the publicly available pwrecovery  username/pswd combination.

Any thoughts would be much appreciated!

Thanks,

Saurabh Gupta

[Paulo Souza]

I just tested in a CTS 1.9.6 and it is really true. I can have full access to web interface by using recovery credentials.

Is that a bug? Does Cisco have plans to fix that in the new versions?

My customers are not aware about this issue, but if they were told about it, it is gonna be a problem for us as well.

Regards

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

[Saurabh Gupta]

Look forward to get the solution of this problem asap.

I have also opened TAC case for it, but so far TAC engineer seems to be very little help.

[srasovic]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

Saurabh:

Hi there. This is Sasa Rasovic from the Cisco PSIRT - Product Security Incident Response Team.

This is to inform you that we have received your report about this problem, and we are currently investigating it.

There is a Sev1 DDTS opened since last night with Telepresence engineering group: CSCui43128.

You can rest assured, Cisco is giving this issue a due priority and we should see some progress reported very soon.

Although no workarounds are available at this point, we continue investigating possible paths. We strongly recommend you to filter all the incoming HTTP/HTTPS traffic to the Telepresence IP address on your edge devices. This would mean your edge router or firewalls deployed in front of Telepresence devices, as part of security best practices.

Also, if my understanding is correct, you filed a TAC request?

I haven't been able to find the SR you referred to, but if you feel as though your case is not being addressed urgently enough, you can call the TAC at any time, referencing your case number, to have the priority raised or the case escalated further.

In the future, if you believe you've run into a Cisco security related issue, you can contact psirt@cisco.com or security-alert@cisco.com

If needed, you can find additional ways to contact TAC here:

http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html

Best regards,

Sasa Rasovic

Incident Manager, PSIRT

Security Research and Operations

Cisco Systems

srasovic@cisco.com

PGP Key ID: 02E64791

http://www.cisco.com/go/psirt

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2.0.17

iJwEAQECAAYFAlH7frAACgkQOpzZGgLmR5FJRQQAnr865a7UGSr6tSVWi27W4iBQ

4NWUdy8gRgssnpg1muMjn2ap03Iz8l3bVNiUbVvCqD7x0ucpeYmDf4DednkWqgoy

SKz/fG9CBhN5LXbGartyQ687IticgoZg+r4s9WYw/PPP9RwweTfD/CiHcXZo3heh

u7tb2nltTQEHXkpzglg=

=fe07

-----END PGP SIGNATURE-----

[jballari]

Hi Sasa,

A customer of mine who was suggested this workaround has come back to us with the following question and reasoning: "after the workaround is applied, the helpdesk account is no longer valid, right? This poses a problem for us as we were using the helpdesk account for our 1st line support team to do some tasks. If the workaround removes this account, then we need to update all our operational procedures. On the other hand, if the workaround is applied a second time but this time putting back the helpdesk account, is the pwrecovery password set to "pwreset" again or does it keep the one typed in the workaround (the first time it got applied).

Thanks much,

Jose

[srasovic]

Hello Jose,

To answer your question directly: yes, in case you are using helpdesk account for a workaround, it will cease to exist as an account that you would normally use for purposes of 1st line support team.

However, this vulnerability is fixed in CiscoTelePresence System Software Releases version 1.10.2 and above for Cisco TelePresence System Series 500-37, 1300, 1X00, 3X00, and 30X0.

Also, we've just recently published CTS Release TX6.0.4(11) for Cisco TelePresence Series TX 9X00, TX 1300, and CTS 500-32, and that release also has a fix.

I hope this helps.

Best regards,

Sasa Rasovic

Incident Manager, PSIRT

Security Research and Operations

Cisco Systems

srasovic@cisco.com

PGP Key ID: 02E64791

http://www.cisco.com/go/psirt

[srasovic]

-----BEGIN PGP SIGNED MESSAGE-----

Saurabh:

Hi again. This is Sasa Rasovic from the Cisco PSIRT.

Our efforts in finding a suitable workaround have yielded the following possibility for CUCM registered codecs:

Step 1 - Configure the CUCM Device config user section as in the screenshot; namely changing the ssh helpdesk user name from the default “helpdesk” to “pwrecovery”, and then forcing a password of your choosing.

This will overwrite the pwrecovery account stored on the TP itself, and thus allow for changing it's password from the default one to the one forced by CUCM admin.

Note: Password recovery will continue to function through ssh as designed, but the user needs to be in the same room as a Telepresence unit in order to accomplish the recovery.

Step 2 - Reboot the codec to download the updated CUCM configuration.

This workaround survives a reboot as the codec re-downloads it’s configuration after every reboot.

As a result, the GUI access would require you to know either the admin/ or pwrecovery/ combination as configured in CUCM; default pwrecovery/pwreset will not work anymore.

If you have a non-CUCM registered codec, the only viable option is to contact TAC.

TAC will assist you in changing the password on the pwrecovery account or completely disable it.

Cisco is dedicated to receipt, investigation, and public reporting of security vulnerability information that is related to Cisco products and networks as described on Cisco Vulnerability Policy: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

Please note that any further update on this matter will be communicated by standard means through Security Intelligence Operations portal, available at http://tools.cisco.com/security/center/publicationListing.x.

Best regards,

Sasa Rasovic

Incident Manager, PSIRT

Security Research and Operations

Cisco Systems

srasovic@cisco.com

PGP Key ID: 02E64791

http://www.cisco.com/go/psirt

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2.0.17

iJwEAQECAAYFAlH78HAACgkQOpzZGgLmR5GFOwP/cmamO9dJmstJojqpMpywV8wD

aZoyBOOhMXlzmaUtRS6e+eJ2eolHV2/5rIEwX8v0cXRv32Q2HHAjUy1nUOBUwSCS

P1Jz/iqqt2x1dD9JH5QKtgukSAF4IIFUKf5nxjw6yAwiMwTSH9MXQDkgHBsxNkOg

SP3HubYOSqQwxV7qlp4=

=z63+

-----END PGP SIGNATURE-----

[Saurabh Gupta]

Thanks Sasa... Let me go back to office tomorrow and try this.

I will update you with the results soon!

Regards,

Saurabh Gupta

[srasovic]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

Hello,

This is Sasa Rasovic from Cisco PSIRT again with a final update:

Cisco PSIRT has published a Security Advisory for this matter at:

http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130807-tp

Please continue to monitor CSCui43128 for any further changes in regards

to  software fixes for this vulnerability.

Cisco is dedicated to receipt, investigation, and public reporting of

security vulnerability information that is related to Cisco products and

networks as described on Cisco Vulnerability Policy:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

Please note that any further update on this matter will be communicated

by standard means through Security Intelligence Operations portal,

available at

http://tools.cisco.com/security/center/publicationListing.x

Best regards,

Sasa Rasovic

Incident Manager, PSIRT

Security Research and Operations

Cisco Systems

srasovic@cisco.com

PGP Key ID: 02E64791

http://www.cisco.com/go/psirt

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2.0.17 (MingW32)

iJwEAQECAAYFAlIChWoACgkQOpzZGgLmR5H8YwP/WIzm6TV0qUoHUC/YSONV7ZMo

IIcB6HtQRTc4bv2M5COEV0e0/FHGWdAGCUUaARbDs0Mf9DSJFSgA6clgXWnO/4SY

KSB7TTmSUh8XNH6bWV7eMtj9IDpflVKZ5JMgzQysXf7DsAWSQ18z2n0eYDzBzEll

KkzBBx/pIN0CBhKT/ys=

=472f

-----END PGP SIGNATURE-----

[Saurabh Gupta]

Hey Sasa,

The method which you suggested worked for us. We were able to set the pwrecovery username and password on UCM. We did this for one unit initially and are going to implement the same for the rest of units.

We would like to know the root cause of this behaviour and what caused this issue? Why this issue was never exposed and checked by Cisco Internally or any other customer?

Thanks,

Saurabh

[srasovic]

Saurabh,

A public forum posting is hardly the right place to discuss those details.

Please open a TAC case for more details.

In the meantime, you can refer the security advisory from my previous post.

Best regards,

Sasa Rasovic

Incident Manager, PSIRT

Security Research and Operations

Cisco Systems

srasovic@cisco.com

PGP Key ID: 02E64791

http://www.cisco.com/go/psirt

[Saurabh Gupta]

Ok, thanks I will ask the same from TAC engineer.

Thanks,

Saurabh