Has anyone experienced security issue related to the features (Call Transfer Rule, kaypad mapping, restriction table) on CUC that could be used to sneak into the PBX and make outbound calls without administrator or end user knowledge and how this gap can be closed? I am looking for additional inputs to secure the voice infrastructure.
Recently we came across with an incident where the outside party dialed into our CUC server via office board number and used the DTMF key combinations ("Telephony user interface") to change the “call transfer rule” parameter to international number on random voice mail boxes of our users. He had also tried to dial directly an international number once the welcome prompt played on CUC. Unfortunately for us, both the options worked for him. I still wonder how the hacker could authenticate the mailbox or got to know the dial out code….??? Anyone has any idea about this, please do share.
We could only react to the issue when we were alerted by the Telcos on unusual calling and took immediate actions by blocking the countries at Telco end where the calls were made and in addition blocking the same countries and some more (where we don’t expect our users to call) as a precaution on PBX using CSS and Partition table configuration. We also cross verified the CUC configuration, we had to undo the changes the hacker had done for some of the voice mail box settings ("Allow user to set personal call transfer rule ") and put additional outbound restrictions (restriction table, keypad mapping etc.) on CUC also. Luckily we could do these validation as we had recently migrated CUC from hardware based server to UCS based. We matched the config on old and new instance which led us to confirm that someone had hacked in to our PBX and made the changes.
Having done the RCA, I felt, these configuration parameters can be exploited by anyone having CUC or PBX knowledge or knowing how to hack the PBX.
I would love to hear from you is anyone has experienced similar issue and what was done to overcome it. I would like to know more ways the hacker could exploit the system.
Sadly, the technical support we got on this incident was limited but I am looking for more such ways so I can fortify the infrastructure accordingly. The engineers mainly kept to the configuration gaps they could find. It took 3 engineers to figure multiple gaps on CUC. Had I not routed the ticket from one engineer to another, probably, we could have missed identifying gaps and still be exposed in some way.
Regards,
