[cisco-voip] DRS Backup Decrypter Workaround - Need Input

Pete Brown jpb at chykn.com
Wed Sep 27 11:01:00 EDT 2017


Thanks for the feedback everyone, I really appreciate it.


Anthony - Great idea, will keep that one in mind.


Brian - You mentioned using it to verify the cluster security passwords on backups.  Given that the workaround has changed from a webservice to a local Java app, the Java app could be used via command line under Windows and Linux.  Maybe have a switch on it to verify the password for a backup set.  Feed it the cluster security password and backup set location and it will kick back a pass or fail.  That way you could do one off checks or run nightly scripts to make sure the cluster security passwords for your backups haven't changed.


________________________________
From: bmeade90 at gmail.com <bmeade90 at gmail.com> on behalf of Brian Meade <bmeade90 at vt.edu>
Sent: Tuesday, September 26, 2017 3:51 PM
To: Anthony Holloway
Cc: Pete Brown; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] DRS Backup Decrypter Workaround - Need Input

Definitely a good tip.

That does assume you can guess the password.  I've had a bunch of customers have some random cluster security password they had never heard of.

On Tue, Sep 26, 2017 at 4:24 PM, Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway+cisco-voip at gmail.com>> wrote:
There's an easier (IMO) way to check cluster security passwords.

1) Enter the change password CLI command, and enter the password you have

admin:set password user security
Please enter the old password: My$3cuR1tyW0rd1

2) Enter the new password as a dictionary word (I like to use banana):

   Please enter the new password: banana
Reenter new password to confirm: banana

3) Say yes to the big scary warning:

WARNING:
You're handing in your resignation letter at 2:00pm today.  Cool?

Continue (y/n)? y

4) Get nervous for a minute and second guess your choice to follow some sketchy advice from some stranger online

Please wait...

5) Observe the outcome

One of two things will now have happened:

1) "The old password did not match."  This means that you do not have the cluster security password correct, and you can try again with some other guesses.
2) "BAD PASSWORD: it does not contain enough DIFFERENT characters" This means that your password was correct, and the "banana" you fed it was rotten.

There you go.  No need to have 3rd party software (not counting an SSH client) to help you anymore.


On Tue, Sep 26, 2017 at 9:43 AM Brian Meade <bmeade90 at vt.edu<mailto:bmeade90 at vt.edu>> wrote:
I'd probably use it less.  Right now, I use it for almost every project to verify cluster security passwords.

I'd probably have to make this more of a last resort in that case and make sure to get sign-off from the customer.

On Tue, Sep 26, 2017 at 10:38 AM, Pete Brown <jpb at chykn.com<mailto:jpb at chykn.com>> wrote:
I could use some public input regarding the next release of the DRS Backup Decrypter.  In a nutshell, the application will have to be online in order to decrypt backup sets from newer UCOS versions.

Last year Cisco started patching DRS with a new algorithm (PBEWithHmacSHA1AndDESede) to encrypt the random backup passwords.  I haven't been able to find a .NET implementation of this algorithm.  The only workaround I've come up with is to have the DRS Backup Decrypter make a call to a Java webservice that can perform the decryption.

The problems with this approach are pretty obvious.  Aside from having to be online, the encrypted cluster security password and 'EncryptKey' from a backup set will need to be submitted to a web service that I've written for decryption.  I can publish a public copy of this webservice, but for those behind corporate proxies (myself included), the code could be made available to run the service within their own networks.  In that case the DRS Backup Decrypter would be pointed to the internal copy of the webservice.

I personally detest utilities that can't operate offline, but it's the only workaround I can come up with at this point.  So my question is this - would anyone actually use it given the webservice dependency?

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip


_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20170927/89029c42/attachment.html>


More information about the cisco-voip mailing list