[cisco-voip] CUCM and Auto Fill Credentials

[Lelio Fulgenzi]

But, it’s not that the “endpoint is vulnerable to security breach” – it’s the whole system!

---
Lelio Fulgenzi, B.A. | Senior Analyst
Computing and Communications Services | University of Guelph
Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON | N1G 2W1
519-824-4120 Ext. 56354 | lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>

www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs> | @UofGCCS on Instagram, Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

From: cisco-voip <cisco-voip-bounces at puck.nether.net> On Behalf Of Anthony Holloway
Sent: Monday, April 30, 2018 9:11 AM
To: Cisco VoIP Group <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] CUCM and Auto Fill Credentials

UPDATE

I just upgraded a system to CUCM 11.5(1)SU4 (11.5.1.14900-11) and when I went to change the Device Pool on this phone, I saw this message at the top:

[image.png]

And when I scrolled down to the Secure Shell section, sure enough, my administrator credentials were in there.

[image.png]

So, the problem still persists, but Cisco is trying to make you aware that it happened.  Of course, if you don't see it, or don't understand it, you're not going to correct it.  Also, who wants to scroll down and erase the credentials every time they make a change?  Not many, I'd wager.

I did not test all of the pages where this can happen, to see if Cisco caught them all, but this was the major offender in my opinion.

On Wed, Mar 14, 2018 at 8:49 PM Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway%2Bcisco-voip at gmail.com>> wrote:
I'm working on something, and was wondering if you could check something for me, so I can better understand why and how often this is happening.

So, I was looking at phone config file today, and I noticed the ccmadmin username and password was in the XML, and in plain text nonetheless.

I found out that the browser, when told to remember your credentials, will treat the SSH username/password fields as login fields whenever you modify a phone, and you might be unknowingly save your credentials for clear text view by unauthenticated users.

Is anyone already aware of this?

You could you run the following command on your clusters:

run sql select name, sshuserid from device where sshuserid is not null and sshuserid <> ""

Then in the output, if there are any hits, look at the config XML file for the phone and see if the passwords are there.

E.g.,

output might be:

SEP6899CD84B710 aholloway

So then you would navigate your browser to:

http://<tftpserver>:6970/SEP6899CD84B710.cnf.xml<http://%3ctftpserver%3e:6970/SEP6899CD84B710.cnf.xml>

You then might have to view the HTML source of the page, because the browser might mess up the output.

You're then looking for the following two fields, your results will vary:

<sshUserId>aholloway</sshUserId>
<sshPassword>MyP at ssw0rd</sshPassword>

Then, since we now know it's happening, get list of how many different usernames you have with this command:

run sql select distinct sshuserid from device where sshuserid is not null and sshuserid <> "" order by sshuserid

This could also be happening with Energy Wise settings, albeit not on the same web pages.

I'm curious about two things:

1) Is it even happening outside of my limited testing scenarios?
2) How many different usernames and passwords were there?

If the answers are yes, and 1 or more, then this is an issue Cisco should address.

The reason it's happening is because the way in which browsers identify login forms, is different from the way in which web developers understand it to work.  Cisco uses the element attribute on these fields "autocomplete = false" and unfortunately, most browser ignore that directive.

I have noticed that this does not happen, if you have more than 1 saved password for the same site, rather it will only happen if you use the same login for the entire site.  Our highest chance of seeing this happen are for operations teams where they login with their own accounts, and do not use DRS or OS Admin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180430/20b080f3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 1297 bytes
Desc: image001.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180430/20b080f3/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 98237 bytes
Desc: image002.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180430/20b080f3/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 37386 bytes
Desc: image003.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180430/20b080f3/attachment-0002.png>