[cisco-voip] CUCM and Auto Fill Credentials

Thu Mar 15 12:02:55 EDT 2018

Curious to what the fix is Ryan?

Modifying the attributes in the form?
Not storing these passwords in the phone config?

---
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 [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ryan Ratliff (rratliff)
Sent: Thursday, March 15, 2018 11:36 AM
To: Anthony Holloway <avholloway+cisco-voip at gmail.com>
Cc: Cisco VoIP Group <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] CUCM and Auto Fill Credentials

There’s an internal defect on this that cites CSCvb33351 as the source of the fix for this problem, fixed in 12.0.

Interestingly enough for me in Firefox (on 12.0) I don’t get ccmadmin passwords auto-populated in ssh fields, but I do get saved ssh username/passwords auto-populated in the ccmadmin login fields.

Thanks for raising this issue everyone.

-Ryan

On Mar 15, 2018, at 7:54 AM, Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway+cisco-voip at gmail.com>> wrote:

I didn't actually check the file contents before replying.  What I meant to say was, the ConfigFileCacheList.txt is the file I was wondering if existed.  Since it does, then one could write a scraping tool to search for and confirm credentials in one fell swoop.

Thanks for the information, Stephen.

I should also mention, some members of this group are replying to me directly, off the list, and the results are confirming that this is indeed an issue worth Cisco's time and attention.  One member of the list confirmed that passwords stored with 3rd party password tools, such as LastPass, protect you from this behavior.

Like I said earlier, it's the browser/user causing the autocomplete to happen, but Cisco's attempt to have these fields NOT auto filled, is faulty.

You can read more below on why that might be.

https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#The_autocomplete_attribute_and_login_fields

<image.png>

On Thu, Mar 15, 2018 at 7:46 AM Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway%2Bcisco-voip at gmail.com>> wrote:
I don't know about any of those additional files, and the FileList one was something I was looking for.

Today's goal will be to write a Python script to: grab that file, then grab all phone configs, then auth against CUCM, and finally, store the credentials that worked.

It might even be worth looking at the credentials which don't work, because it might tell you something about password habits, allowing you to predict future passwords. Eg Summer2010

On Mar 15, 2018 2:34 AM, "Stephen Welsh" <stephen.welsh at unifiedfx.com<mailto:stephen.welsh at unifiedfx.com>> wrote:
While we are on the subject here are some other non encrypted TFTP server items:

  *   ConfigFileCacheList.txt
  *   FileList.txt
  *   BinFileCacheList.txt
  *   PerfMon.txt
  *   ParamList.txt
  *   lddefault.cfg
So you could use the following to get a list of all the device MAC addresses anonymously from the TFTP server:

http://TFTPServer:6970/FileList.txt<http://tftpserver:6970/FileList.txt>

So with the scenario you describe and just the TFTP Server IP Address you could scan all the device configs on the cluster to see if even just one of them has the admin credentials saved accidentally on the SSH User/Password field.

I suspect this may apply to most clusters....

Kind Regards

Stephen Welsh
CTO
UnifiedFX

On 15 Mar 2018, at 07:25, Stephen Welsh <stephen.welsh at unifiedfx.com<mailto:stephen.welsh at unifiedfx.com>> wrote:
Hi Anthony,

Yes, the SSH credentials saved on the device page are available in clear text in the phone XML config, it’s not just your environment unfortunately. Also I believe the same thing applies for the Telepresence endpoints (anything running CE including the DX) for the web page admin credentials that are saved in the vendor config section.

We noticed this a little while ago but given most people did not populate it did not consider as a serious issue, however the auto-population of credentials is not something we considered. So yes this does look like a serious problem when you combine those two together.

Kind Regards

Stephen Welsh
CTO
UnifiedFX

On 15 Mar 2018, at 01:50, Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway+cisco-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.
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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/20180315/f67735f0/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/20180315/f67735f0/attachment.png>