August 2013 - DrVoIP - AWS Cloud Solutions

I though I had seen it all!

When you have been involved with the design, deployment and management of customer premise telephone systems for as long as we have, you think you have seen it all. Over the years as we learn from our mistakes we improve our “best practice” list to assure others gain from our experience. When I was barely a teenager, I learned how to assemble a string of MF tones using a Hammond organ keyboard. Recording two keys at a time, you could create toll call routing instructions that could be played back after making a 1-800 toll call before the terminating end answered! That, along with the famous Captain Crunch 2600Hz cereal box whistle, kept me and my friends entertained for years, stacking toll tandem switches and meeting other hackers in far away phone booths! Things have changed as in-band signaling has long ago been replaced with out of band signaling and whistles no longer work. Toll fraud however, continues to be a major source of unanticipated costs for business and the toll bandit syndrome is still alive and well in the Internet age.

Just like a web sever which uses well know port 8080 to serve up web pages, SIP phone systems use a common port. Scanning ports for open port 5060, then banging away for a user login and password to create a registration was child’s play and most companies now have this locked down. The fact that most Voice Mail systems used a common password was also a source of hacking entertainment, but now most manufacturers do not create mailboxes until someone needs one, eliminating a source of illegal phone calls though remote access. Direct Inward System Access or DISA used to be a favorite tool for making fraudulent toll calls. Users would call into the system, put in a pin and then be granted access to make phone calls. It did not take long to figure out how to abuse that feature!

Kevin Mitnick needs my help?

Like I said, just when you think you have seen it all, something new shows up. You have to laugh at how obvious and simple it was. I was recently contacted by a guy who you would think has seen it all, Kevin Mitnick. If that name does not immediately “ring a bell,” then maybe you might remember a couple of his books: The Art of Intrusion, The Art of Deception and most recently Ghost in the Wires. Kevin has not only seen it all, he has done it all! Anyway, Kevin was researching a compromised ShoreTel system for a client and wanted to compare notes with DrVoIP. Apparently someone had gained unauthorized access to the system and was making toll calls that were costing the target company a small fortune. If you have ever experienced toll fraud you know that your vulnerability is broadcast all of the Internet in just a matter of minutes.You will find yourself explaining to Homeland Security why you are making so many phone calls to Dubai!

Kevin had a sheet of CDR records that showed the date and time of the calls. Unfortunately the calls seemed to be originating from the Automated Attendant so they could not be traced to a particular extension number within the system. We brain stormed some possibilities. I thought for sure this had to be an inside job! Maybe someone was using the “find me follow me” feature, but that would only send the call to a single number. These calls were all over the map! Literally all over the globe! ShoreTel does not have a DISA feature and VM boxes do not exist unless they are assigned to a user. The password must be changed as a part of the setup process. So how was this system hacked?

Well, I could tell you but that would take all the fun out of hearing from you as to your thoughts on how this was done. I will promise you that it takes one to know one and Kevin, genius that he is, figured this out, not I! Even DrVoIP was taken in by this clever ruse! Post your comments below with your thoughts on how this was accomplished and we will send you the puzzle answer Kevin uncovered. My thinking is that all we can ever hope to do is to raise the bar, keeping out the less sophisticated mice. There will always be someone smarter, someone more dedicated and focused, who will make it his mission to crack your safe!

Updated with Answer September 1, 2013

– Well a couple of people actually broke the code (excuse the pun)! What Kevin learned was that one of the great flaws in VoIP is the complete lack of control when it comes to secure Caller ID! Simply stated, there is no security or verification of Caller ID! Using any number of readily available tools, it is possible to spoof your caller ID. You can make your phone display any number you want! ShoreTel has a voice mail feature that enables you to listen to a voice message and then return the call by pushing a voice mail menu option key! This is a very handy feature, especially if you are calling into your voice mail from you car, just hit the “return call” option and provided the system was able to capture the inbound Caller ID, the ShoreTel will place an outgoing call to that number and conference you in! So lets put this simple ShoreTel hack together – the hackers gained control of a voice mail box, then called into the ShoreTel Voice Mail system with a spoofed Caller ID and the left a brief message. Calling back into the system, this time to check their voice messages and then hit the “return call” option key, which then placed a call to an International Middle East location all billed to the the ShoreTel system owner and showing up only as a Call Detail Record owned by the Automated Attendant. Great feature, but we would recommend that you don’t allow the VM system to place International phone calls! Thanks to all who took time to write and special thanks to Kevin Mitnick for a really fun Service Call!

The “Killer UCCX Contact Center Script”

After your first 100 or so Contact Center Scripts, you begin to wonder if it would be possible to generate a “killer script”! No matter how many hours you sit with clients and do your very best to extract their call handling requirements, it just never seems to be enough! Generally, you have some block of professional hours to complete the script, test, train and turn up before “go live”. You ask the client for their requirements and “wish list”, then prioritize the list toward the goal of getting as much done as possible within the budget allocated to the project. You no sooner get the script up and operational and the client is asking for six options that never came up during the time you were discussing requirements. They were never even on the “wish list”! Last time this happened to me, I determined to write a script which would have run time options for the various script extensions I have seen over the years. Starting with a basic Generic script which had modules you could switch in and out to achieve not only increase functionality, but efficiency in both cost and time.

Route Type? Prompt and Collect!

Most call flow scripts can be reduced to answering an incoming call, playing a menu of options, navigating to a Contact Service Queue, finding the most appropriate human resource or managing queue handling while the caller waits for service. Sometimes there is no menu after the call is answered, and the call is sent directly to the Queue. At other times, we need to provide some “prompt and collect” for database look up prior to call routing. We are always looking at operational alternatives for time of day, day of week and holiday or emergency closings. This sounds like something we could develop into a general purpose call flow script, complete with generic record prompts in the language of choice. So the Killer Script contains a library of professionally recorded prompts and prompt segments for enabling you to assemble your own prompt!

Where are the IVR Prompts and professionally voice WAV files?

We long ago learned never to start coding a project until we had the actual recorded prompts and wav files in hand! How many hours of development time have been squandered because an attempt was made to code without the scripts. When the client finally delivered the actual recordings to be used in the script, they were different than the call flow we all signed off on during the requirements meeting! Don’t do it! Get the recordings done first. Then and only then code your call flow! This thinking gave way to a concept of numbered prompts! Again, you no sooner get the project on line and “go live” and the client is back asking if they can change a recording! Why not create a module that would allow the client to call into an IVR script, select the prompt they want to record, play it to confirm that it is the correct one, and then let them record it themselves! I started thinking about this after the first experiences in which the client asked for special closing recordings. The client would say something like this: “Sometimes we have a staff meeting and we need to close the queue. We want to play a special greeting to the caller letting them know we are in a meeting.”

CCAdmin to allow supervisors to Open and Close Queue with custom Closed prompt!

So we now have a Generic Call Flow Script that has an option for a Contact Center Administration and prompt management! The Generic Call handler offers some run time options that can be set at run time. They include a ROUTE TYPE (i.e., Menu, Direct, IVR or Transfer) that dictate how to handle the incoming caller. In fact, we can change the route type based on the DNIS or ANI, so the script actually changes its call flow to play a Menu or send the caller direct to Queue with each new call. We then created a Contact Center Administration module that would allow an authorized user to open and close a queue on demand by dialing into an IVR script. If you closed the Queue, you were offered the option to record a new closed greeting. Optionally, you could record any existing prompt by entering the prompt number. All of this done by an authorized user with a PIN number and not requiring the System administrator.

Queue management was another area in which a modular approach to scripting could enable a range of options. Do we play “your estimated wait time” or “your position in queue is” or just play music on hold? If they are in Queue awaiting an agent resource, do we offer them options like, “Press 1 to leave a message, 2 to schedule a call back, or continue to hold and your call will be answered…?” Not every client wants these options, but many want the choice. How do you make that option available without burdening the project with more develop hours? In fact you might want these options to change based on who called or what number the caller dialed. We determined to add a third module to our script library. We can now offer the call back option on module basis.

Clearly every call center is different. You will always need to modify your scripts. It is possible however, to create a flexible, reusable script that has configuration options or modules. It is also possible to make these options available at run time based on DNIS or ANI. There is no need to launch a separate script when you can reconfigure the same script on the fly to address the various call handling options required to manage a caller through a successful contact center interaction. Ask us about our generic scripts and save yourself a ton of money while paving the way for self-managed call center flexibility as you move through your business process! DrVoIPGeneric, DrVoIPCCAdmin and DrVoIPCallBack are all available for CISCO UCCX and come with professionally recorded generic voice prompts that can be easily branded. We also include supporting XML documents for Scheduling, Holidays and a Queue options template for changing call flow based on DNIS!

Killer Script Overview – Updated for 2019 Version!

The Core Root script is a single thread that enables both application level run time variables as well as “variables on the fly” through the QueueOptions.XML file. Typically the script will be trigger by one of the DNIS numbers attached to the script. This DNIS become strDNIS in our application and it is used to index the XML file to pull back all the variables for that specific CSQ. One of the variables that is returned is the strApprefix value. For example we have “CSQ_SandBox” for testing and it has a strApprefix of “SBOX”. This variable is prepended to objects like Queue Message Wave Files. In this way SBOX_QueueMessage1.wav and PTAC_QueueMessage1.wav can both be represented by strApprefix+”_QueueMessage.wav” in the same script! This also makes it possible to create Layouts that are pushed out to the agents.

The QueueOptions file contains all of the variables that you want configured for a specific CSQ. It sets options for offering Estimated Wait Time and Position In Queue. We offer the option of a call back without losing your place in queue. This has a variable that can be set to enable “record a short message to be played to the Agent before you call is returned” or to disable that option and move directly to collecting the target call back number.

Route Types (Direct, Menu, IVR, Debug)

Some CSQ’s require that the caller be sent directly to the Call Center. Others require the caller to navigate an IVR or MENU and the option strRouteType defines these options. If the caller is to be offered a Menu of choices the script loads the correct menu, again using strApprefix to bring back SBOX_Menu.aef at the appropriate point in the call flow. Likewise the caller can be directed to an IVR platform before the call moves to the call center.

The Killer Script is actually a series of scripts, documents, professionally recorded voice prompts and sample XML documents that you can copy, modify or edit to suit your call center CSQ configuration goals. All this for $295? What a deal, your average professional service company is billing scripting engineers out a $275-$350 and hour! If you have any scripting experience at all, you should be able to configure this script! Optionally, we can quote a fixed project fee to install and configure it for you!

Text Us at 929-292-8100 for details!

Month: August 2013

Hacking ShoreTel!