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

[Pete Brown]

Brian,


We're still okay there.  Cisco hasn't changed the algorithm used to store passwords in platformConfig.xml, so the UCOS Password Decrypter still works.


I know you're familiar with this next part, but I'll include it for the public.  When backups are generated, the encrypted security password is copied directly from platformConfig.xml and hashed.  The results of that hash are used as a key to encrypt the random backup password which then gets stuffed into the backup set XML.  The algorithm used for the hash in this process is what they changed.


One option would be to roll the UCOS Password Decrypter functions into the new command line Java app.  That way you could run it directly on a rooted UCOS VM to dump the platformConfig.xml passwords.


Thanks,

Pete


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

Pete,

I'm assuming we won't be able to decrypt the password from the platformConfig.xml anymore?

Thanks,
Brian

On Wed, Sep 27, 2017 at 11:01 AM, Pete Brown <jpb at chykn.com<mailto:jpb at chykn.com>> wrote:

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<mailto:bmeade90 at gmail.com> <bmeade90 at gmail.com<mailto:bmeade90 at gmail.com>> on behalf of Brian Meade <bmeade90 at vt.edu<mailto:bmeade90 at vt.edu>>
Sent: Tuesday, September 26, 2017 3:51 PM
To: Anthony Holloway
Cc: Pete Brown; cisco-voip at puck.nether.net<mailto: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/d8012cf5/attachment.html>