Re: [cisco-voip] CUBE DTMF

[GR]

Thanks Anthony. So no need to configure digit drop ? Even if I am doing RFC2833 
on one leg and advertise both Inband and OOB on second leg. 


Sent from my iPhone

> On 16 Mar 2018, at 2:10 am, Anthony Holloway 
>  wrote:
> 
> I was going to mention that CUBE doesn't support rtp-nte to sip-kpml 
> interworking.  Weird, I know.  But that's how it was.  However, when I went 
> to grab the link for my source, the table has been updated, and I see that 
> this is now supported.
> 
> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html#concept_264617919921874995299551391601561
> 
> Therefore, I see no gotchas with enablingwell...maybe one gotcha.  If you 
> enable both RTP-NTE and SIP-KPML on a dial-peer, note that CUBE will 
> advertise both, and the offer answer model dictates that CUBE will then not 
> be able to choose or control the DTMF relay selected.  However, when CUBE 
> receives an offer with multiple relays in it, it will choose which to use 
> based on ordermaybe.
> 
> Citations from that link:
> 
> "If multiple DTMF relay mechanisms are enabled on a SIP dial peer and are 
> negotiated successfully, NOTIFY-based out-of-band DTMF relay takes 
> precedence."
> 
> "If you configure more than one out-of-band DTMF method, preference goes from 
> highest to lowest in the order of configuration."
> 
> "CUBE negotiates both rtp-nte and sip-kpml if both are supported and 
> advertised in the incoming INVITE. However, CUBE relies on the rtp-nte DTMF 
> method to receive digits and a SUBSCRIBE if sip-kpml is not initiated. CUBE 
> still accepts SUBSCRIBEs for KPML. This prevents double-digit reporting 
> problems at CUBE."
> 
> "CUBE selects DTMF relay mechanisms using the following priority:
> sip-notify or sip-kpml (highest priority)
> rtp-nte
> None—Send DTMF in-band"
> I recommend to read that entire document, or at least the chapter I linked, 
> because it has some good info on it.  Of course, you'll want to test 
> everything, because it's not out of reason to have to file a documentation 
> defect.
> 
>> On Thu, Mar 15, 2018 at 8:44 AM GR  wrote:
>> Hi Guys,
>> 
>> I am having an issue with SIP provider only supporting rfc2833. The CUBEs 
>> are configured only for rtp-nte on all dial-peers facing both the provider 
>> and the CUCM internal network (multiple clusters)
>> 
>> Randomly one of the MGCP/h323 gateway is having issues, where it only 
>> supports OOB and then further complications trying to resolve the problem.
>> 
>> I am planning to add sip kpml as well on top of rtp-nte to advertise both 
>> inband and outofband DTMF methods towards our internal CUCM network and let 
>> CUBE do inter-working in case where one leg is rfc2833 (carrier side) and 
>> other is kpml(internal network lets say MGCP gateway). Trying to stay away 
>> from MTPs.
>> 
>> Any gotchas if I just go ahead and add kpml on top of existing rtp-nte 
>> method (on CUBE dial-peers facing our internal network) as I don’t want to 
>> break the setup where only inband is supported, hard to check in a global 
>> deployment.
>> 
>> Any need to use digit-drop in case both inband and out of band digits are 
>> sent? If required it will be only on dial-peers facing CUCM side? Or this is 
>> not required as the provider only supports rfc2833.
>> 
>> Thanks
>> GR
>> 
>> 
>> 
>> 
>> Sent from my iPhone
>> ___
>> cisco-voip mailing list
>> 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

Re: [cisco-voip] CUCM and Auto Fill Credentials

[Benjamin Turner]

Running 11.5 and I tested on a few admin users and got clear txt using the tftp 
address and SEPMac address.cnf.xml

Dang!!!

Get Outlook for Android


From: cisco-voip  on behalf of Anthony 
Holloway 
Sent: Thursday, March 15, 2018 9:38:11 PM
To: Charles Goldsmith
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] CUCM and Auto Fill Credentials

Charles,  Sounds good, and thank you for the input.

As for clearing the SSH stuff, you could run:

run sql update device set (sshuserid, sshpassword) = ('', '') where sshuserid 
is not null and sshuserid <> ''

On Thu, Mar 15, 2018 at 6:50 PM Charles Goldsmith 
mailto:wo...@justfamily.org>> wrote:
Anthony, pertaining to this tidbit about 3rd party password tools, I've found 
at least with LastPass this is not the case.  In testing this, I'm using 
Firefox ESR latest, on Windows 7 fully patched and the latest Lastpass update 
that it's still allowing firefox to insert the credentials if you have that 
enabled.  Of course, if you disable firefox saving of credentials, it shouldn't 
do this.

Obviously I'm nitpicking here, but wanted to clarify this a bit for posterities 
sake, since we are obviously getting into some best practices here.

Turn off browser auto-complete of passwords and use a 3rd party password 
management tool.

Lastly, once the fields are filled out, I cannot find an easy way to clear 
them.  You can replace with something else, but not clear.

Thanks for the info on all of this!


On Thu, Mar 15, 2018 at 9:54 AM Anthony Holloway 
mailto:avholloway%2bcisco-v...@gmail.com>> 
wrote:
One member of the list confirmed that passwords stored with 3rd party password 
tools, such as LastPass, protect you from this behavior.


___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] CUCM and Auto Fill Credentials

[Anthony Holloway]

Charles,  Sounds good, and thank you for the input.

As for clearing the SSH stuff, you could run:

*run sql update device set (sshuserid, sshpassword) = ('', '') where
sshuserid is not null and sshuserid <> ''*

On Thu, Mar 15, 2018 at 6:50 PM Charles Goldsmith 
wrote:

> Anthony, pertaining to this tidbit about 3rd party password tools, I've
> found at least with LastPass this is not the case.  In testing this, I'm
> using Firefox ESR latest, on Windows 7 fully patched and the latest
> Lastpass update that it's still allowing firefox to insert the credentials
> if you have that enabled.  Of course, if you disable firefox saving of
> credentials, it shouldn't do this.
>
> Obviously I'm nitpicking here, but wanted to clarify this a bit for
> posterities sake, since we are obviously getting into some best practices
> here.
>
> Turn off browser auto-complete of passwords and use a 3rd party password
> management tool.
>
> Lastly, once the fields are filled out, I cannot find an easy way to clear
> them.  You can replace with something else, but not clear.
>
> Thanks for the info on all of this!
>
>
> On Thu, Mar 15, 2018 at 9:54 AM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> One member of the list confirmed that passwords stored with 3rd party
>> password tools, such as LastPass, protect you from this behavior.
>>
>>
>>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] CUCM and Auto Fill Credentials

[Charles Goldsmith]

Anthony, pertaining to this tidbit about 3rd party password tools, I've
found at least with LastPass this is not the case.  In testing this, I'm
using Firefox ESR latest, on Windows 7 fully patched and the latest
Lastpass update that it's still allowing firefox to insert the credentials
if you have that enabled.  Of course, if you disable firefox saving of
credentials, it shouldn't do this.

Obviously I'm nitpicking here, but wanted to clarify this a bit for
posterities sake, since we are obviously getting into some best practices
here.

Turn off browser auto-complete of passwords and use a 3rd party password
management tool.

Lastly, once the fields are filled out, I cannot find an easy way to clear
them.  You can replace with something else, but not clear.

Thanks for the info on all of this!


On Thu, Mar 15, 2018 at 9:54 AM Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

> One member of the list confirmed that passwords stored with 3rd party
> password tools, such as LastPass, protect you from this behavior.
>
>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] CUCM and Auto Fill Credentials

[Charles Goldsmith]

Interestingly, none of these files come up for me on a 11.5.1.13902
system.  I can pull an XML file as Anthony showed previously, but not these
files.  On 9.1.2 and 11.0.1.2000 systems, I can view them just fine.  Did
something change in 11.5.1 or so to now allow these files?

I don't receive an error, just a blank page, and source is nil.

On Thu, Mar 15, 2018 at 2:35 AM Stephen Welsh 
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 
>
> 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 
> 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-v...@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://: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:
>
> *aholloway*
> *MyP@ssw0rd*
>
> 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@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
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
__

[cisco-voip] Wireless Phones

[Natambu Obleton]

What are people using for wireless phones? Any good experiences?

TIA

--

Natambu Obleton
CISSP #370414 CCIE #38491
Director of Network Engineering and Operations
FastTrack Communications, Inc.
970.828.1009

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] CUCM and Auto Fill Credentials

[Ryan Ratliff (rratliff)]

With respect to storing passwords the intent for the ssh username/password 
field for IP phones is something that was generally not considered very 
sensitive info. The separation of ssh credentials from enabling SSH was also 
done to help mitigate the fact that this info is available to anyone by default.

For TP endpoints while their admin credentials can be configured in UCM the 
endpoint ignores that setting unless the TFTP config file is encrypted, for 
just this reason.

With respect to the fix in 12.0 I haven’t figured that out just yet. The id and 
name attributes on the HTML inputs are different, but both have type 
“password”. Personally I can’t imagine why the browser would think a stored 
credential from one html element should be autofilled into an entirely 
different field, but I guess the browser is trying to be helpful.

The only big difference I can see in 12.0 is the proper use of tags in the 
input and labels associated with them.
10.5

Secure Shell Password 





12.x

Secure Shell Password 


Password







I’m not an expert in HTML autocomplete so it’s going to take some more testing 
to figure out exactly why the login credentials aren’t auto-filled in this 
field any longer.


-Ryan

On Mar 15, 2018, at 9:38 AM, Anthony Holloway 
mailto:avholloway+cisco-v...@gmail.com>> wrote:

It's certainly a complicated problem: .  Also, Cisco is storing the password in 
the DB encrypted, as you could see by modifying the SQL query to:

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

Which is what the defect Ryan posted is talking about, the stored encrypted 
password length.

However, the TFTP files do contain the plain text credentials.  You could 
encrypt your TFTP config files to protect yourself completely, but who's doing 
that these days?

And lastly, like I said before, this is also happening with the Energy Wise 
fields, albeit on other web pages, and those are stored in the DB in plain text.

E.g.,

run sql select xml from enterprisephoneconfigxml where xml like '%energy%'

Output will contain the following if impacted 
"theuserthepassword"
 which is also transmitted in plain text to phones via the phone XML config 
file.

There may be others too.

On Thu, Mar 15, 2018 at 11:02 AM Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:

Thank you very much for bring this to the group’s attention. And for providing 
some great troubleshooting steps to see whether we might be affected. Thanks to 
others for providing other information as well.


On the one hand, I see it being a browser issue – autocompleting when it 
shouldn’t (although you’re asked at least once, are you not?) and ignoring the 
autocomplete=false…. But…

Should Cisco really be storing passwords in clear text anywhere?




---
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 | 
le...@uoguelph.ca

www.uoguelph.ca/ccs | @UofGCCS on Instagram, 
Twitter and Facebook






From: cisco-voip 
[mailto:cisco-voip-boun...@puck.nether.net]
 On Behalf Of Anthony Holloway
Sent: Wednesday, March 14, 2018 9:50 PM

To: Cisco VoIP Group 
mailto:cisco-voip@puck.nether.net>>
Subject: [cisco-voip] CUCM and Auto Fill Credentials


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://: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:

aholloway
MyP@ssw0rd

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

Re: [cisco-voip] session target dns

[Ed Leatherman]

I'm not going to explicitly call them out but its in debug snippet from
previous post :)

It's a regional SP, in their defense they have been willing to work with me
on it.

On Thu, Mar 15, 2018 at 12:41 PM, Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

> Will the SIP provider remain nameless in this thread?  ;)
>
> On Thu, Mar 15, 2018 at 10:58 AM Ed Leatherman 
> wrote:
>
>> I get the impression that im the first customer on these new sbc's.
>>
>> On Thu, Mar 15, 2018, 11:12 AM Anthony Holloway <
>> avholloway+cisco-v...@gmail.com> wrote:
>>
>>> Wow.  So you pointed out a flaw in the provider network.  Presumably,
>>> they were hosting other customers with the same setup; so how in the world
>>> was it working for the others?  Or maybe you are the beta tester?
>>>
>>> On Thu, Mar 15, 2018 at 9:54 AM Ed Leatherman 
>>> wrote:
>>>
 Follow-up for posterity..

 I had a feeling this was the case but got some confirmation from TAC:
 "This is working as designed when this is an incoming call, the reason
 why it works that way is because on the incoming leg the call comes from 1
 specific IP address, and if CUBE does a DNS query for SRV it might resolve
 a different IP address than the one where INVITE is coming from and might
 cause inbound calls to fail. Instead, if CUBE does DNS query for A record
 it will resolve one specific IP address."


 The service provider changed their SBC to send an IP address in the
 Contact field URI which resolved the issue.


 Ed

 On Thu, Mar 8, 2018 at 2:16 PM, Ed Leatherman 
 wrote:

>
> Follow-up to this SRV/CUBE topic..
>
> Outbound calls work fine with this setup (after I enabled ip
> domain-lookup ;-) )
>
> For inbound calls, the service provider is using the hostname for the
> SRV record (peer.isc.lumos.net) in the contact field of the invite.
> Apparently, CUBE only does an A record lookup on that field?
>
> 022206: Mar  8 13:44:04 est: //25051/829EEEDD9B28/SIP/Info/
> verbose/4608/sipSPIProcessContactInfo: Previous Hop
> peer.isc.lumos.net:5060
> ...
> 022210: Mar  8 13:44:04 est: //-1//SIP/Info/
> info/8192/sip_dns_type_a__query: DNS query for peer.isc.lumos.net
> and type:1
> 022211: Mar  8 13:44:04 est: //-1//SIP/Error/
> sip_dns_type_a_query:
>  TYPE A query failed for peer.isc.lumos.net
> 022212: Mar  8 13:44:04 est: //-1//SIP/Error/_
> send_dns_fail:
>  DNS Query for peer.isc.lumos.net failed
>
> CUBE is basically shutting down the call saying it can't resolve the
> contact field. If I put a local host entry for that name using their
> currently active SBC, inbound calls work. Shouldn't CUBE be doing a SRV
> lookup here, or should the service provider send me an hostname instead of
> an SRV in this field?
>
>
>
>
> On Tue, Mar 6, 2018 at 2:25 PM, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> Just so you know, they're not going to know if you use SRV records or
>> not, or host records for that matter.  They probably only care about two
>> things:
>>
>> 1) They control which peers you send traffic to via DNS updates
>>
>> 2) They receive the proper/expected host portion in your traffic to
>> them
>>
>> For all intents and purposes, the inclusion of a name in the host
>> portion of a SIP URI is separate from the DNS query.
>>
>> The fact that you point your system at a name (or IP for that matter)
>> and that it then becomes the RHS of the URI is nice, but not required.
>>
>> Therefore, if you ask them to commit to telling you about IP address
>> changes completely negates their desire to use SRV records.  Just say'n.
>>
>> On Tue, Mar 6, 2018 at 6:30 AM Ed Leatherman 
>> wrote:
>>
>>> Thanks Anthony, That was spot on what I was trying to figure out.
>>> I've been using server-groups up until now (and will continue on the 
>>> CUCM
>>> facing side), the service provider is forcing the change on the side 
>>> facing
>>> them.
>>>
>>> Loren: That's an interesting idea to lock in the host resolution on
>>> the CUBE itself, but in this case I think it might set me up for an 
>>> outage
>>> if the service provider changes their IP Addressing. Maybe I can get 
>>> them
>>> to commit to telling me before they change those..
>>>
>>> On Mon, Mar 5, 2018 at 2:31 PM, Anthony Holloway <
>>> avholloway+cisco-v...@gmail.com> wrote:
>>>
 Loren,

 Just out of curiosity, why didn't you just use session server
 groups?  Based on the config you shared, it looks like it would 
 achieve the
 same thing, but with less config, and not adding in the DNS stack 
 within
 IOS.

>>>

Re: [cisco-voip] CUCM and Auto Fill Credentials

[Anthony Holloway]

It's certainly a complicated problem: .  Also, Cisco is storing the
password in the DB encrypted, as you could see by modifying the SQL query
to:

*run sql select name, sshuserid, sshpassword from device where sshuserid is
not null and sshuserid <> ''*

Which is what the defect Ryan posted is talking about, the stored encrypted
password length.

However, the TFTP files do contain the plain text credentials.  You could
encrypt your TFTP config files to protect yourself completely, but who's
doing that these days?

And lastly, like I said before, this is also happening with the Energy Wise
fields, albeit on other web pages, and those are stored in the DB in plain
text.

E.g.,

*run sql select xml from enterprisephoneconfigxml** where xml like
'%energy%'*

Output will contain the following if impacted "
theuserthepassword"
which is also transmitted in plain text to phones via the phone XML config
file.

There may be others too.

On Thu, Mar 15, 2018 at 11:02 AM Lelio Fulgenzi  wrote:

>
>
> Thank you very much for bring this to the group’s attention. And for
> providing some great troubleshooting steps to see whether we might be
> affected. Thanks to others for providing other information as well.
>
>
>
>
>
> On the one hand, I see it being a browser issue – autocompleting when it
> shouldn’t (although you’re asked at least once, are you not?) and ignoring
> the autocomplete=false…. But…
>
>
>
> Should Cisco really be storing passwords in clear text anywhere?
>
>
>
>
>
>
>
>
>
> ---
>
> *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 <(519)%20824-4120> | le...@uoguelph.ca
>
>
>
> www.uoguelph.ca/ccs | @UofGCCS on Instagram, Twitter and Facebook
>
>
>
> [image: image001.png]
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] *On Behalf
> Of *Anthony Holloway
>
> *Sent:* Wednesday, March 14, 2018 9:50 PM
>
>
> *To:* Cisco VoIP Group 
> *Subject:* [cisco-voip] CUCM and Auto Fill Credentials
>
>
>
> 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://: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:
>
>
>
> *aholloway*
>
> *MyP@ssw0rd*
>
>
>
> 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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https:

Re: [cisco-voip] session target dns

[Anthony Holloway]

Will the SIP provider remain nameless in this thread?  ;)

On Thu, Mar 15, 2018 at 10:58 AM Ed Leatherman 
wrote:

> I get the impression that im the first customer on these new sbc's.
>
> On Thu, Mar 15, 2018, 11:12 AM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> Wow.  So you pointed out a flaw in the provider network.  Presumably,
>> they were hosting other customers with the same setup; so how in the world
>> was it working for the others?  Or maybe you are the beta tester?
>>
>> On Thu, Mar 15, 2018 at 9:54 AM Ed Leatherman 
>> wrote:
>>
>>> Follow-up for posterity..
>>>
>>> I had a feeling this was the case but got some confirmation from TAC:
>>> "This is working as designed when this is an incoming call, the reason
>>> why it works that way is because on the incoming leg the call comes from 1
>>> specific IP address, and if CUBE does a DNS query for SRV it might resolve
>>> a different IP address than the one where INVITE is coming from and might
>>> cause inbound calls to fail. Instead, if CUBE does DNS query for A record
>>> it will resolve one specific IP address."
>>>
>>>
>>> The service provider changed their SBC to send an IP address in the
>>> Contact field URI which resolved the issue.
>>>
>>>
>>> Ed
>>>
>>> On Thu, Mar 8, 2018 at 2:16 PM, Ed Leatherman 
>>> wrote:
>>>

 Follow-up to this SRV/CUBE topic..

 Outbound calls work fine with this setup (after I enabled ip
 domain-lookup ;-) )

 For inbound calls, the service provider is using the hostname for the
 SRV record (peer.isc.lumos.net) in the contact field of the invite.
 Apparently, CUBE only does an A record lookup on that field?

 022206: Mar  8 13:44:04 est:
 //25051/829EEEDD9B28/SIP/Info/verbose/4608/sipSPIProcessContactInfo:
 Previous Hop peer.isc.lumos.net:5060
 ...
 022210: Mar  8 13:44:04 est:
 //-1//SIP/Info/info/8192/sip_dns_type_a__query: DNS query
 for peer.isc.lumos.net and type:1
 022211: Mar  8 13:44:04 est:
 //-1//SIP/Error/sip_dns_type_a_query:
  TYPE A query failed for peer.isc.lumos.net
 022212: Mar  8 13:44:04 est:
 //-1//SIP/Error/_send_dns_fail:
  DNS Query for peer.isc.lumos.net failed

 CUBE is basically shutting down the call saying it can't resolve the
 contact field. If I put a local host entry for that name using their
 currently active SBC, inbound calls work. Shouldn't CUBE be doing a SRV
 lookup here, or should the service provider send me an hostname instead of
 an SRV in this field?




 On Tue, Mar 6, 2018 at 2:25 PM, Anthony Holloway <
 avholloway+cisco-v...@gmail.com> wrote:

> Just so you know, they're not going to know if you use SRV records or
> not, or host records for that matter.  They probably only care about two
> things:
>
> 1) They control which peers you send traffic to via DNS updates
>
> 2) They receive the proper/expected host portion in your traffic to
> them
>
> For all intents and purposes, the inclusion of a name in the host
> portion of a SIP URI is separate from the DNS query.
>
> The fact that you point your system at a name (or IP for that matter)
> and that it then becomes the RHS of the URI is nice, but not required.
>
> Therefore, if you ask them to commit to telling you about IP address
> changes completely negates their desire to use SRV records.  Just say'n.
>
> On Tue, Mar 6, 2018 at 6:30 AM Ed Leatherman 
> wrote:
>
>> Thanks Anthony, That was spot on what I was trying to figure out.
>> I've been using server-groups up until now (and will continue on the CUCM
>> facing side), the service provider is forcing the change on the side 
>> facing
>> them.
>>
>> Loren: That's an interesting idea to lock in the host resolution on
>> the CUBE itself, but in this case I think it might set me up for an 
>> outage
>> if the service provider changes their IP Addressing. Maybe I can get them
>> to commit to telling me before they change those..
>>
>> On Mon, Mar 5, 2018 at 2:31 PM, Anthony Holloway <
>> avholloway+cisco-v...@gmail.com> wrote:
>>
>>> Loren,
>>>
>>> Just out of curiosity, why didn't you just use session server
>>> groups?  Based on the config you shared, it looks like it would achieve 
>>> the
>>> same thing, but with less config, and not adding in the DNS stack within
>>> IOS.
>>>
>>> Ed,
>>>
>>> *Note, you cannot use DNS in server groups, so it's one or the other.
>>>
>>> I also think it's important to know that the IOS code is written
>>> such that it will look for SRV records first, and then fallback to 
>>> looking
>>> for an A (host) record once the DNS timeouts.
>>>
>>> E.g.,
>>>
>>> You enter "session target dns:collab.domain.com"
>>>
>>>

Re: [cisco-voip] CUCM and Auto Fill Credentials

[Lelio Fulgenzi]

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 | le...@uoguelph.ca

www.uoguelph.ca/ccs | @UofGCCS on Instagram, 
Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ryan 
Ratliff (rratliff)
Sent: Thursday, March 15, 2018 11:36 AM
To: Anthony Holloway 
Cc: Cisco VoIP Group 
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 
mailto:avholloway+cisco-v...@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



On Thu, Mar 15, 2018 at 7:46 AM Anthony Holloway 
mailto:avholloway%2bcisco-v...@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" 
mailto:stephen.we...@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

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 
mailto:stephen.we...@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 
mailto:avholloway+cisco-v...@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.

Re: [cisco-voip] CUCM and Auto Fill Credentials

[Lelio Fulgenzi]

Thank you very much for bring this to the group’s attention. And for providing 
some great troubleshooting steps to see whether we might be affected. Thanks to 
others for providing other information as well.


On the one hand, I see it being a browser issue – autocompleting when it 
shouldn’t (although you’re asked at least once, are you not?) and ignoring the 
autocomplete=false…. But…

Should Cisco really be storing passwords in clear text anywhere?




---
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 | le...@uoguelph.ca

www.uoguelph.ca/ccs | @UofGCCS on Instagram, 
Twitter and Facebook

[University of Guelph Cornerstone with Improve Life tagline]

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Anthony Holloway
Sent: Wednesday, March 14, 2018 9:50 PM
To: Cisco VoIP Group 
Subject: [cisco-voip] CUCM and Auto Fill Credentials

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://: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:

aholloway
MyP@ssw0rd

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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] session target dns

[Ed Leatherman]

I get the impression that im the first customer on these new sbc's.

On Thu, Mar 15, 2018, 11:12 AM Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

> Wow.  So you pointed out a flaw in the provider network.  Presumably, they
> were hosting other customers with the same setup; so how in the world was
> it working for the others?  Or maybe you are the beta tester?
>
> On Thu, Mar 15, 2018 at 9:54 AM Ed Leatherman 
> wrote:
>
>> Follow-up for posterity..
>>
>> I had a feeling this was the case but got some confirmation from TAC:
>> "This is working as designed when this is an incoming call, the reason
>> why it works that way is because on the incoming leg the call comes from 1
>> specific IP address, and if CUBE does a DNS query for SRV it might resolve
>> a different IP address than the one where INVITE is coming from and might
>> cause inbound calls to fail. Instead, if CUBE does DNS query for A record
>> it will resolve one specific IP address."
>>
>>
>> The service provider changed their SBC to send an IP address in the
>> Contact field URI which resolved the issue.
>>
>>
>> Ed
>>
>> On Thu, Mar 8, 2018 at 2:16 PM, Ed Leatherman 
>> wrote:
>>
>>>
>>> Follow-up to this SRV/CUBE topic..
>>>
>>> Outbound calls work fine with this setup (after I enabled ip
>>> domain-lookup ;-) )
>>>
>>> For inbound calls, the service provider is using the hostname for the
>>> SRV record (peer.isc.lumos.net) in the contact field of the invite.
>>> Apparently, CUBE only does an A record lookup on that field?
>>>
>>> 022206: Mar  8 13:44:04 est:
>>> //25051/829EEEDD9B28/SIP/Info/verbose/4608/sipSPIProcessContactInfo:
>>> Previous Hop peer.isc.lumos.net:5060
>>> ...
>>> 022210: Mar  8 13:44:04 est:
>>> //-1//SIP/Info/info/8192/sip_dns_type_a__query: DNS query
>>> for peer.isc.lumos.net and type:1
>>> 022211: Mar  8 13:44:04 est:
>>> //-1//SIP/Error/sip_dns_type_a_query:
>>>  TYPE A query failed for peer.isc.lumos.net
>>> 022212: Mar  8 13:44:04 est: //-1//SIP/Error/_send_dns_fail:
>>>  DNS Query for peer.isc.lumos.net failed
>>>
>>> CUBE is basically shutting down the call saying it can't resolve the
>>> contact field. If I put a local host entry for that name using their
>>> currently active SBC, inbound calls work. Shouldn't CUBE be doing a SRV
>>> lookup here, or should the service provider send me an hostname instead of
>>> an SRV in this field?
>>>
>>>
>>>
>>>
>>> On Tue, Mar 6, 2018 at 2:25 PM, Anthony Holloway <
>>> avholloway+cisco-v...@gmail.com> wrote:
>>>
 Just so you know, they're not going to know if you use SRV records or
 not, or host records for that matter.  They probably only care about two
 things:

 1) They control which peers you send traffic to via DNS updates

 2) They receive the proper/expected host portion in your traffic to them

 For all intents and purposes, the inclusion of a name in the host
 portion of a SIP URI is separate from the DNS query.

 The fact that you point your system at a name (or IP for that matter)
 and that it then becomes the RHS of the URI is nice, but not required.

 Therefore, if you ask them to commit to telling you about IP address
 changes completely negates their desire to use SRV records.  Just say'n.

 On Tue, Mar 6, 2018 at 6:30 AM Ed Leatherman 
 wrote:

> Thanks Anthony, That was spot on what I was trying to figure out. I've
> been using server-groups up until now (and will continue on the CUCM 
> facing
> side), the service provider is forcing the change on the side facing them.
>
> Loren: That's an interesting idea to lock in the host resolution on
> the CUBE itself, but in this case I think it might set me up for an outage
> if the service provider changes their IP Addressing. Maybe I can get them
> to commit to telling me before they change those..
>
> On Mon, Mar 5, 2018 at 2:31 PM, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> Loren,
>>
>> Just out of curiosity, why didn't you just use session server
>> groups?  Based on the config you shared, it looks like it would achieve 
>> the
>> same thing, but with less config, and not adding in the DNS stack within
>> IOS.
>>
>> Ed,
>>
>> *Note, you cannot use DNS in server groups, so it's one or the other.
>>
>> I also think it's important to know that the IOS code is written such
>> that it will look for SRV records first, and then fallback to looking for
>> an A (host) record once the DNS timeouts.
>>
>> E.g.,
>>
>> You enter "session target dns:collab.domain.com"
>>
>> IOS looks for _sip._udp.collab.domain.com SRV record first,
>> timesout, then looks for collab.domain.com host record second.
>>
>> *Note that the outgoing session transport on IOS is UDP by default,
>> unless you change it to TCP with the command "sess

Re: [cisco-voip] CUCM and Auto Fill Credentials

[Anthony Holloway]

For the record, per request via a private reply from a Cisco employee (not
Ryan), I emailed the Cisco PSIRT team about this issue.

On Thu, Mar 15, 2018 at 10:36 AM Ryan Ratliff (rratliff) 
wrote:

> 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-v...@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
>
> 
>
> On Thu, Mar 15, 2018 at 7:46 AM Anthony Holloway <
> avholloway+cisco-v...@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" 
>> 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
>>> 
>>>
>>> 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 
>>> 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-v...@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.,
>>

Re: [cisco-voip] CUCM and Auto Fill Credentials

[Ryan Ratliff (rratliff)]

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 
mailto:avholloway+cisco-v...@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



On Thu, Mar 15, 2018 at 7:46 AM Anthony Holloway 
mailto:avholloway%2bcisco-v...@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" 
mailto:stephen.we...@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

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 
mailto:stephen.we...@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 
mailto:avholloway+cisco-v...@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://: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:

aholloway
MyP@ssw0rd

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

run sql select d

Re: [cisco-voip] session target dns

[Anthony Holloway]

Wow.  So you pointed out a flaw in the provider network.  Presumably, they
were hosting other customers with the same setup; so how in the world was
it working for the others?  Or maybe you are the beta tester?

On Thu, Mar 15, 2018 at 9:54 AM Ed Leatherman 
wrote:

> Follow-up for posterity..
>
> I had a feeling this was the case but got some confirmation from TAC:
> "This is working as designed when this is an incoming call, the reason
> why it works that way is because on the incoming leg the call comes from 1
> specific IP address, and if CUBE does a DNS query for SRV it might resolve
> a different IP address than the one where INVITE is coming from and might
> cause inbound calls to fail. Instead, if CUBE does DNS query for A record
> it will resolve one specific IP address."
>
>
> The service provider changed their SBC to send an IP address in the
> Contact field URI which resolved the issue.
>
>
> Ed
>
> On Thu, Mar 8, 2018 at 2:16 PM, Ed Leatherman 
> wrote:
>
>>
>> Follow-up to this SRV/CUBE topic..
>>
>> Outbound calls work fine with this setup (after I enabled ip
>> domain-lookup ;-) )
>>
>> For inbound calls, the service provider is using the hostname for the SRV
>> record (peer.isc.lumos.net) in the contact field of the invite.
>> Apparently, CUBE only does an A record lookup on that field?
>>
>> 022206: Mar  8 13:44:04 est:
>> //25051/829EEEDD9B28/SIP/Info/verbose/4608/sipSPIProcessContactInfo:
>> Previous Hop peer.isc.lumos.net:5060
>> ...
>> 022210: Mar  8 13:44:04 est:
>> //-1//SIP/Info/info/8192/sip_dns_type_a__query: DNS query
>> for peer.isc.lumos.net and type:1
>> 022211: Mar  8 13:44:04 est:
>> //-1//SIP/Error/sip_dns_type_a_query:
>>  TYPE A query failed for peer.isc.lumos.net
>> 022212: Mar  8 13:44:04 est: //-1//SIP/Error/_send_dns_fail:
>>  DNS Query for peer.isc.lumos.net failed
>>
>> CUBE is basically shutting down the call saying it can't resolve the
>> contact field. If I put a local host entry for that name using their
>> currently active SBC, inbound calls work. Shouldn't CUBE be doing a SRV
>> lookup here, or should the service provider send me an hostname instead of
>> an SRV in this field?
>>
>>
>>
>>
>> On Tue, Mar 6, 2018 at 2:25 PM, Anthony Holloway <
>> avholloway+cisco-v...@gmail.com> wrote:
>>
>>> Just so you know, they're not going to know if you use SRV records or
>>> not, or host records for that matter.  They probably only care about two
>>> things:
>>>
>>> 1) They control which peers you send traffic to via DNS updates
>>>
>>> 2) They receive the proper/expected host portion in your traffic to them
>>>
>>> For all intents and purposes, the inclusion of a name in the host
>>> portion of a SIP URI is separate from the DNS query.
>>>
>>> The fact that you point your system at a name (or IP for that matter)
>>> and that it then becomes the RHS of the URI is nice, but not required.
>>>
>>> Therefore, if you ask them to commit to telling you about IP address
>>> changes completely negates their desire to use SRV records.  Just say'n.
>>>
>>> On Tue, Mar 6, 2018 at 6:30 AM Ed Leatherman 
>>> wrote:
>>>
 Thanks Anthony, That was spot on what I was trying to figure out. I've
 been using server-groups up until now (and will continue on the CUCM facing
 side), the service provider is forcing the change on the side facing them.

 Loren: That's an interesting idea to lock in the host resolution on the
 CUBE itself, but in this case I think it might set me up for an outage if
 the service provider changes their IP Addressing. Maybe I can get them to
 commit to telling me before they change those..

 On Mon, Mar 5, 2018 at 2:31 PM, Anthony Holloway <
 avholloway+cisco-v...@gmail.com> wrote:

> Loren,
>
> Just out of curiosity, why didn't you just use session server groups?
> Based on the config you shared, it looks like it would achieve the same
> thing, but with less config, and not adding in the DNS stack within IOS.
>
> Ed,
>
> *Note, you cannot use DNS in server groups, so it's one or the other.
>
> I also think it's important to know that the IOS code is written such
> that it will look for SRV records first, and then fallback to looking for
> an A (host) record once the DNS timeouts.
>
> E.g.,
>
> You enter "session target dns:collab.domain.com"
>
> IOS looks for _sip._udp.collab.domain.com SRV record first, timesout,
> then looks for collab.domain.com host record second.
>
> *Note that the outgoing session transport on IOS is UDP by default,
> unless you change it to TCP with the command "session transport tcp" at 
> the
> "voice service voip" level, or at the dial-peer level.  So, having a
> _sip._tcp SRV record on your CUBE would create a confusing scenario.
> Contrast this with the incoming connection, which can be either.  However,
> SRV records, like Loren is showing,

Re: [cisco-voip] CUBE DTMF

[Anthony Holloway]

I was going to mention that CUBE doesn't support rtp-nte to sip-kpml
interworking.  Weird, I know.  But that's how it was.  However, when I went
to grab the link for my source, the table has been updated, and I see that
this is now supported.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html#concept_264617919921874995299551391601561

Therefore, I see no gotchas with enablingwell...maybe one gotcha.  If
you enable both RTP-NTE and SIP-KPML on a dial-peer, note that CUBE will
advertise both, and the offer answer model dictates that CUBE will then not
be able to choose or control the DTMF relay selected.  However, when CUBE
receives an offer with multiple relays in it, it will choose which to use
based on ordermaybe.

Citations from that link:

"If multiple DTMF relay mechanisms are enabled on a SIP dial peer and are
negotiated successfully, NOTIFY-based out-of-band DTMF relay takes
precedence."

"If you configure more than one out-of-band DTMF method, preference goes
from highest to lowest in the order of configuration."

"CUBE negotiates both rtp-nte and sip-kpml if both are supported and
advertised in the incoming INVITE. However, CUBE relies on the rtp-nte DTMF
method to receive digits and a SUBSCRIBE if sip-kpml is not initiated. CUBE
still accepts SUBSCRIBEs for KPML. This prevents double-digit reporting
problems at CUBE."

"CUBE selects DTMF relay mechanisms using the following priority:


   - sip-notify or sip-kpml (highest priority)
  - rtp-nte
  - None—Send DTMF in-band"

I recommend to read that entire document, or at least the chapter I linked,
because it has some good info on it.  Of course, you'll want to test
everything, because it's not out of reason to have to file a documentation
defect.

On Thu, Mar 15, 2018 at 8:44 AM GR  wrote:

> Hi Guys,
>
> I am having an issue with SIP provider only supporting rfc2833. The CUBEs
> are configured only for rtp-nte on all dial-peers facing both the provider
> and the CUCM internal network (multiple clusters)
>
> Randomly one of the MGCP/h323 gateway is having issues, where it only
> supports OOB and then further complications trying to resolve the problem.
>
> I am planning to add sip kpml as well on top of rtp-nte to advertise both
> inband and outofband DTMF methods towards our internal CUCM network and let
> CUBE do inter-working in case where one leg is rfc2833 (carrier side) and
> other is kpml(internal network lets say MGCP gateway). Trying to stay away
> from MTPs.
>
> Any gotchas if I just go ahead and add kpml on top of existing rtp-nte
> method (on CUBE dial-peers facing our internal network) as I don’t want to
> break the setup where only inband is supported, hard to check in a global
> deployment.
>
> Any need to use digit-drop in case both inband and out of band digits are
> sent? If required it will be only on dial-peers facing CUCM side? Or this
> is not required as the provider only supports rfc2833.
>
> Thanks
> GR
>
>
>
>
> Sent from my iPhone
> ___
> cisco-voip mailing list
> 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

Re: [cisco-voip] CUCM and Auto Fill Credentials

[Anthony Holloway]

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: image.png]

On Thu, Mar 15, 2018 at 7:46 AM Anthony Holloway <
avholloway+cisco-v...@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" 
> 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 
>>
>> 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 
>> 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-v...@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://: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:
>>
>> *aholloway*
>> *MyP@ssw0rd*
>>
>> 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 o

Re: [cisco-voip] session target dns

[Ed Leatherman]

Follow-up for posterity..

I had a feeling this was the case but got some confirmation from TAC:
"This is working as designed when this is an incoming call, the reason why
it works that way is because on the incoming leg the call comes from 1
specific IP address, and if CUBE does a DNS query for SRV it might resolve
a different IP address than the one where INVITE is coming from and might
cause inbound calls to fail. Instead, if CUBE does DNS query for A record
it will resolve one specific IP address."


The service provider changed their SBC to send an IP address in the Contact
field URI which resolved the issue.


Ed

On Thu, Mar 8, 2018 at 2:16 PM, Ed Leatherman 
wrote:

>
> Follow-up to this SRV/CUBE topic..
>
> Outbound calls work fine with this setup (after I enabled ip domain-lookup
> ;-) )
>
> For inbound calls, the service provider is using the hostname for the SRV
> record (peer.isc.lumos.net) in the contact field of the invite.
> Apparently, CUBE only does an A record lookup on that field?
>
> 022206: Mar  8 13:44:04 est: 
> //25051/829EEEDD9B28/SIP/Info/verbose/4608/sipSPIProcessContactInfo:
> Previous Hop peer.isc.lumos.net:5060
> ...
> 022210: Mar  8 13:44:04 est: //-1//SIP/Info/
> info/8192/sip_dns_type_a__query: DNS query for peer.isc.lumos.net and
> type:1
> 022211: Mar  8 13:44:04 est: //-1//SIP/Error/
> sip_dns_type_a_query:
>  TYPE A query failed for peer.isc.lumos.net
> 022212: Mar  8 13:44:04 est: //-1//SIP/Error/_send_dns_fail:
>  DNS Query for peer.isc.lumos.net failed
>
> CUBE is basically shutting down the call saying it can't resolve the
> contact field. If I put a local host entry for that name using their
> currently active SBC, inbound calls work. Shouldn't CUBE be doing a SRV
> lookup here, or should the service provider send me an hostname instead of
> an SRV in this field?
>
>
>
>
> On Tue, Mar 6, 2018 at 2:25 PM, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> Just so you know, they're not going to know if you use SRV records or
>> not, or host records for that matter.  They probably only care about two
>> things:
>>
>> 1) They control which peers you send traffic to via DNS updates
>>
>> 2) They receive the proper/expected host portion in your traffic to them
>>
>> For all intents and purposes, the inclusion of a name in the host portion
>> of a SIP URI is separate from the DNS query.
>>
>> The fact that you point your system at a name (or IP for that matter) and
>> that it then becomes the RHS of the URI is nice, but not required.
>>
>> Therefore, if you ask them to commit to telling you about IP address
>> changes completely negates their desire to use SRV records.  Just say'n.
>>
>> On Tue, Mar 6, 2018 at 6:30 AM Ed Leatherman 
>> wrote:
>>
>>> Thanks Anthony, That was spot on what I was trying to figure out. I've
>>> been using server-groups up until now (and will continue on the CUCM facing
>>> side), the service provider is forcing the change on the side facing them.
>>>
>>> Loren: That's an interesting idea to lock in the host resolution on the
>>> CUBE itself, but in this case I think it might set me up for an outage if
>>> the service provider changes their IP Addressing. Maybe I can get them to
>>> commit to telling me before they change those..
>>>
>>> On Mon, Mar 5, 2018 at 2:31 PM, Anthony Holloway <
>>> avholloway+cisco-v...@gmail.com> wrote:
>>>
 Loren,

 Just out of curiosity, why didn't you just use session server groups?
 Based on the config you shared, it looks like it would achieve the same
 thing, but with less config, and not adding in the DNS stack within IOS.

 Ed,

 *Note, you cannot use DNS in server groups, so it's one or the other.

 I also think it's important to know that the IOS code is written such
 that it will look for SRV records first, and then fallback to looking for
 an A (host) record once the DNS timeouts.

 E.g.,

 You enter "session target dns:collab.domain.com"

 IOS looks for _sip._udp.collab.domain.com SRV record first, timesout,
 then looks for collab.domain.com host record second.

 *Note that the outgoing session transport on IOS is UDP by default,
 unless you change it to TCP with the command "session transport tcp" at the
 "voice service voip" level, or at the dial-peer level.  So, having a
 _sip._tcp SRV record on your CUBE would create a confusing scenario.
 Contrast this with the incoming connection, which can be either.  However,
 SRV records, like Loren is showing, are for outbound connection
 establishments.

 I have not done an extensive amount of testing here, but I would be
 curious to know if IOS handles the TTL for the DNS record correctly, or if
 it queries DNS for every setup like how that one defect was hitting CUCM
 SIP trunks for a while there.  I looked for "TTL" in the CVP Config guide,
 but it didn't say.

>>>

Re: [cisco-voip] CUBE DTMF

[Prashanthi Velpula (prvelpul)]

Hi GR, 

Can you give an example of the call flow you having issues with ? 
For example: IP phone(SCCP) -- > CUCM -- > MGCP/H323 -- > CUBE -- > SIP -- > 
Provider ? 

Regards 
Prashanthi 

-Original Message-
From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of GR
Sent: 15 March 2018 19:13
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] CUBE DTMF

Hi Guys,

I am having an issue with SIP provider only supporting rfc2833. The CUBEs are 
configured only for rtp-nte on all dial-peers facing both the provider and the 
CUCM internal network (multiple clusters)

Randomly one of the MGCP/h323 gateway is having issues, where it only supports 
OOB and then further complications trying to resolve the problem. 

I am planning to add sip kpml as well on top of rtp-nte to advertise both 
inband and outofband DTMF methods towards our internal CUCM network and let 
CUBE do inter-working in case where one leg is rfc2833 (carrier side) and other 
is kpml(internal network lets say MGCP gateway). Trying to stay away from MTPs.

Any gotchas if I just go ahead and add kpml on top of existing rtp-nte method 
(on CUBE dial-peers facing our internal network) as I don’t want to break the 
setup where only inband is supported, hard to check in a global deployment. 

Any need to use digit-drop in case both inband and out of band digits are sent? 
If required it will be only on dial-peers facing CUCM side? Or this is not 
required as the provider only supports rfc2833. 

Thanks
GR




Sent from my iPhone
___
cisco-voip mailing list
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

[cisco-voip] CUBE DTMF

[GR]

Hi Guys,

I am having an issue with SIP provider only supporting rfc2833. The CUBEs are 
configured only for rtp-nte on all dial-peers facing both the provider and the 
CUCM internal network (multiple clusters)

Randomly one of the MGCP/h323 gateway is having issues, where it only supports 
OOB and then further complications trying to resolve the problem. 

I am planning to add sip kpml as well on top of rtp-nte to advertise both 
inband and outofband DTMF methods towards our internal CUCM network and let 
CUBE do inter-working in case where one leg is rfc2833 (carrier side) and other 
is kpml(internal network lets say MGCP gateway). Trying to stay away from MTPs.

Any gotchas if I just go ahead and add kpml on top of existing rtp-nte method 
(on CUBE dial-peers facing our internal network) as I don’t want to break the 
setup where only inband is supported, hard to check in a global deployment. 

Any need to use digit-drop in case both inband and out of band digits are sent? 
If required it will be only on dial-peers facing CUCM side? Or this is not 
required as the provider only supports rfc2833. 

Thanks
GR




Sent from my iPhone
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] CUCM and Auto Fill Credentials

[Charles Goldsmith]

It's interesting, and scary, if you are on a system's network, wouldn't be
hard to get people's passwords.

I did confirm that I have access to about 20 different AD passwords from
just 1 cluster.

Thanks for the info Anthony

On Thu, Mar 15, 2018 at 7:46 AM Anthony Holloway <
avholloway+cisco-v...@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" 
> 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 
>>
>> 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 
>> 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-v...@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://: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:
>>
>> *aholloway*
>> *MyP@ssw0rd*
>>
>> 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 th

Re: [cisco-voip] CUCM and Auto Fill Credentials

[Anthony Holloway]

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" 
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 
>
> 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 
> 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  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://: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:
>
> *aholloway*
> *MyP@ssw0rd*
>
> 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@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
>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.net

Re: [cisco-voip] CUCM and Auto Fill Credentials

[Stephen Welsh]

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

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 
mailto:stephen.we...@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 
mailto:avholloway+cisco-v...@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://: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:

aholloway
MyP@ssw0rd

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@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
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] CUCM and Auto Fill Credentials

[Stephen Welsh]

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 
mailto:avholloway+cisco-v...@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://: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:

aholloway
MyP@ssw0rd

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@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