The Problem
If you wanted to hard code a username and password into your script, for use with the Authenticate User step, you might be surprised to find out, that anyone with access to your network (more specifically to your UCCX), can see this password.
I have written about how this works in the following post:
https://supportforums.cisco.com/message/3856104#3856104
To summarize that post for your convenience, logging in to the CRS Script Editor by clicking the Login Anonymously button, while pointing the IP Address at a valid UCCX server, allows you to open the scripts from within the repository. If you were to hard code a username and password into script, this information becomes available to the anonymous user.
Current Solutions
Up until I discovered the feature of masking passwords within UCCX, I believed there to be three main ways to protect yourself from this type of unwanted access.
- Use PIN numbers instead of passwords. You can either hard code the PIN into the script, or you can ask the caller for the PIN. Either way, outside of gaining access to your telephony application, your system administration remains secured. However, hard coding the PIN, versus asking the caller to enter it, does allow the anonymous user to call in to the IVR, and make changes to your environment from there. I would pick asking the caller for the PIN over hard coding the PIN, but hard coding the PIN is still better than hard coding a password.
- Embed your credentials into a text file, which is stored in the repository, and then read by the script. Because the only access an anonymous user has to your system at this point is viewing scripts in read only mode, the repository documents remain secure.
An example script for this can be found here: https://supportforums.cisco.com/message/3856257#3856257 - Mark the password variable as a Parameter, and set it in the AppAdmin Application page. Again, because the only access an anonymous user has to your system at this point is viewing scripts in read only mode, the Application settings remain secure.
The Protect Solution (aka Masking)
While helping a fellow UCCX administrator on the CSC Contact Center Discussion forum, he brought to my attention a feature called Reduce. This could be another document/discussion on its own, but what I would like to focus on, is the context menu option just below it: Protect.
That discussion can be read here: https://supportforums.cisco.com/message/4005461#4005461
Once you select protect, shortcut keys CTRL+O, a pop up dialog box will prompt you for a password to protect this piece of data.
Upon supplying a password, you will be asked to confirm the password in order to satisfy this requirement of protecting your sensitive data.
You will now see that your data becomes a series of asterisks in an arbitrary length; protecting the data as well as the length of the data.
Your original Authenticate User step is now properly protected from anonymous users.
A Caveat on Usage
I should note that there is a caveat here: you can only protect literal values in the script, you cannot protect variable values in the variables pane.
What this means is that, you cannot have a String variable for storing your password in, and then try to protect the variable's value. For whatever reason this does not work. If you try it, it will look like it's about to work, but the value ends up not protected, nor masked; it remains vulnerable plain text viewable to the anonymous user.
This caveat is hard to explain, and capture in a screenshot. Go ahead and create a new script, and a new String variable, name it whatever you want, and then try to protect its value. You should learn rather quickly that it doesn't work.
An Additional Benefit of the Protect Solution
You don't have to save the Protect feature for passwords only. Yes, it does mask the value, but it does one more thing: it prevents changes to the value, unless you have this extra password. So, in a way, you could protect very mission critical values, which should never be changed. I'm thinking about the famous Two Man Rule we often see in spy movies, where the villain needs to steal two keys to arm a missile.
http://en.wikipedia.org/wiki/Two-man_rule
An example of this could be threshold metrics you do not want changed, or outside third party phone numbers you transfer to and you need them to remain static an protected.
Security Concerns
If the anonymous user can read the scripts from the repository, it's only a step away to save them locally to his/her PC. At this point, could the anonymous user extract the Protect password from the binary file? I'm not sure. I did open the script in a plain text editor, and I did not see the password in plain text. I also opened the script in a binary hex editor, and did not find the hex values in sequence for my password. This maybe due to my lack of security skills, or perhaps Cisco has used an encryption method in the Java bean to protect this data.
I would be nice to know the fact on this one, because as of right now, I'm only working off of the results of my limited security vulnerability scanning skill set. Say that ten times fast!
The Conclusion
We now have several secure ways to use a single service account, within a script, for accessing and modifying Documents and Prompts in the repository. However, it would be nice if this anonymous user access to our script repository wasn't even an issue. In fact, Cisco has taken this very seriously and have a defect for us to track:
https://tools.cisco.com/bugsearch/bug/CSCuf77546
As well as having published a public security notice about the vulnerability:
http://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2013-1214
The Challenge
I would like to challenge anyone to find out and post what storage mechanism is being used in this Protect feature. This way everyone knows just how protected the information is. This challenge is for Cisco employees and the public alike.