A colleague of mine, just tipped me off on a fantastic article written by Vassilis Prevelakis and Diomidis Spinellis over at the IEEE Spectrum Online. It is an absolutely enthralling read about a real life example of voice systems espionage, and I highly recommend it.

Voice security is increasingly being associated with VoIP and Unified Communications. What is being called the “Greek Watergate” shows us quite clearly that legacy TDM systems are just as much at risk, and always have been. But it also shows us that there are individuals that are capable of attacks at level of sophistication we may find surprising, alarming and downright frightening.

Let’s review some of the facts from the incident, which occurred around the 2004 summer Olympics in Athens:

• Malicious software was implanted in 4 TDM voice core switches in a Greek Telecom’s network.
• This software activated the Lawful Intercept (LI) feature on the switch for the attacker’s benefit. This is a fully legal feature, usually required by law so that telephone conversations of any kind can be lawfully eavesdropped upon. It is activated on specific DNs only, when those DNs are of interest to law enforcement officials. It works by ‘duplicating’ the 2-way speech path between the targeted parties, and redirecting it to a law enforcement center for monitoring and recording.
• The switches had the LI feature installed, but it was not licensed and therefore was not actively executing. This is a very normal telecom practice, and allows for tiered levels of service. It also served to further obfuscate the attack.
• The cell phone calls were actually encrypted for the final mile to the handsets, but not within the voice core.
• The software was installed without detection using the software patching system on the switch, and subsequently hidden from it.
• The perpetrators frequently re-configured the numbers being monitored without detection.
• The software bypassed both the logging system and the user interface.
• What tipped them off to the intrusion was a bug caused by the rogue software, introduced after the attackers upgraded it. The new code interfered with the systems ability to forward text messages – and that generated logs.
• The perpetrator(s) are not yet apprehended. Hindering the investigation is the mis-handling of some critical log files that were erased over an upgrade – and contrary to policy – no backups were created. Additionally, the software was removed almost immediately upon detection, instead of being monitored for activity, and tracing back to the attackers.
• The telecom operator was held liable for a €76 million fine ($113 million US) for illegally wiretapping 106 cell phones and impeding the investigation, as well as an additional €19 million fine ($28 million US) for violating privacy regulations.

Was this intrusion preventable? Of course. There was a single point of entry that afforded the attackers access to the voice core switches – once they had access, they obviously had the technical prowess to do whatever they pleased. They clearly had the capability to write compatible software for the system, including interfacing with the APIs for several of its key software functions in a format that was deployable by the vendor’s own patching system. It remains speculation whether they came in through the network, or had physical access to the equipment. It is also being debated over whether or not this was an inside job or not.

How could such an intrusion be prevented in the future? What else can we learn? The answers are surprisingly simple, and we have heard them all before:

1. Physical Security. Tightly control all access to critical equipment, and ensure that only trusted individuals have access rights. Enforcement, monitoring, and logging of all individuals coming and going is key here. Policy does not make reality unless it is enforced. Even the most sophisticated attacks start with access. Cut them off there, and they have nothing.
2. Network Security. A full analysis and audit of every conceivable way into the equipment is required – and on a regular basis. Doing it once is only the beginning. Penetration testing, vulnerability assessments are just some of the tools available to help with this. If you must have access ports open to the network – they had better be monitored, traced, logged, and protected with strong AAA-like techniques.
3. Intrusion detection and response. Legacy voice core TDM switches are large, proprietary platforms, that vary immensely from vendor to vendor. Detection of an intrusion in one system may be dramatically different in another. As a result, an IDS may be a set of policies, activities, or specialized h/w and software tailored to that specific vendor, product class, and release version. At the very least, an in-situ verification system is warranted that looks for anything out of the ordinary, such as additional processes, files, system logs, logins, network activity, software CRC checks, memory profile and CPU usage. Above all, be diligent. Work with your vendor to identify what you should be doing to detect intrusions and have a planned response so that any security incident is handled in a systematic way thus limiting any damage to evidence.
4. Perform a Threat and Risk Assessment. Know what’s important, and what actions to take. That includes defining an Intrusion Handling Policy. How you deal with an attack will greatly influence the consequences. You could be fined, or face even more serious legal repercussions. Check your policies before you hit the delete key.

I think its worth noting that “end to end” encryption of the speech path would effectively stop this kind of eavesdropping, but it would also break the Lawful Intercept feature, and add some very serious complications to the way legacy TDM calls are routed. In fact, this is one of those situations where encryption cannot and should not be utilized to secure the entire voice path. Having said that, encrypting the final mile is still an excellent security control.

I’ll re-iterate again the level of sophistication behind this attack. The attackers were both highly motivated and very capable of executing this attack and it is a strong possibility that this intrusion was an inside job, although that is speculation and has not been proven. It’s a hard learned lesson about what can go wrong if you fail to define and follow your own security and operational policies. It’s also a demonstration that the right attackers with the right skills can wreak utter havoc if you fail to adequately control and monitor access to your systems. The “Greek Watergate” incident proves that voice security threats are very real, even in tried, tested and true legacy TDM systems. The important thing to remember is that these networks are still very much defensible.

Jeff Lewis
Security Architect
Nortel

I often read in the blogosphere about how Voice over IP is so much less secure than traditional TDM based technologies. There certainly seems to be enough compelling reasons for such thinking, but I frequently wonder how much truth there really is to it. Is it really that dangerous? Is it really that different from the old way of doing things? Keeping the scope to the telephone lines and sets themselves, I think the answer is probably yes – but it certainly doesn’t have to be.

I recently joined a tech trial at the office to help test out a new VoIP call server. Installation was easy enough – I just plugged the phone into my ethernet jack and I was making calls in seconds. The problem was, I was making calls as if I was someone else! As it turns out, I was given a phone to use for the trial that had previously been assigned to another employee. I could have made calls to just about anyone as if I were that person. Fortunately I’m an ethical guy and swatting/vishing isn’t my thing. OK, that’s fine, it’s a tech trial right? These sorts of things happen, but it got me thinking.

Physical security aside, even if this phone had been deployed with my own identity assigned to the caller ID, what’s to stop a would be thief from taking the phone off my desk, plugging it in at another quiet location and making calls to whom ever they wanted? If that same thief grabbed my TDM phone off my desk and plugged it in elsewhere, my identity would not follow it. Well that’s a pretty big difference right? Perhaps the jack they plugged the stolen TDM phone into is their own, with their own CLID, or perhaps the line card for that jack is offline altogether. In this case, there is an inherent extra level of physical and network security in TDM because the caller’s identity is tied to the line card, not the terminal. More often than not, VoIP reverses this relationship and places the identity in the terminal.

How likely is it that someone is going to steal my phone off my desk, and make impersonated telephone calls at the office? I’d say the odds are against it, so I’m not losing sleep over this. After all, anyone can make calls from my TDM set at my desk when I’m not here and I would notice if my IP set went missing.

The situation is a little more interesting if you consider how this problem scales. What about a massive enterprise roll out of thousands of VoIP lines. Companies that large always have churn and turnaround in the employee ranks. It would only be a matter of time before a phone previously used by one employee ended up in the hands of another without having been reprogrammed. What then? I just hope they are honest. It may be some time before the administrators figure out the mistake.

Now, granted, not all VoIP systems behave in this manner. Your identity does not have to be tied permanently to the phone. One would hope that your redeployment process would include a reset of the phone’s memory, and then re-configuration. But all it takes is one phone to slip through by mistake with the old data. Instead, a simple tweak to make the user log in each time they boot up the phone would solve the problem rather nicely. Most people are used to signing into their PCs everyday, but not their phones – so this might seem a little strange at first. Having had my IP phone for a few weeks now, its never rebooted. I’d say the bigger problem would be remembering the user id and password if it ever did.

Another way to level the playing field between these technologies is through 802.1x authentication. By only specifically allowing certain devices on certain ports, you very much achieve a similar level of security that TDM phones inherently had. Now if the thief grabs my phone and tries to plug it in at his desk, he might have limited network access – but he certainly won’t be making any calls. However, this strategy only works if the policy was deployed everywhere on the network. All they would need to do to circumvent the restriction is find a port that doesn’t require 802.1x authentication and they are back in business.

Yet another method to even the score between TDM and VoIP would be to VLAN all your VoIP traffic. In the past, we all expected a phone jack and a computer jack to be separate. Why change that? If the thief grabs your IP phone and plugs it into a regular data jack elsewhere, they get nothing. This of course assumes you do not leave ports on your VoIP VLAN enabled when they are not in use. If you did that – it’s all for naught.

I will agree this is all a bit of a crooked case study. If you have thieves willing to steal phones from within the office, you probably have much bigger concerns, like what they might be doing to the integrity of your entire network. But it does serve as a very good example of some key differences between the inherent security in a TDM based system, and the newer VoIP systems.

A proper defense in depth strategy that deploys all of the above controls would go a long way towards leveling the playing field between the two technologies. If you compare apples to apples within the context of this example, a default VoIP installation without any security controls in place is probably less secure than that of a TDM system. However, if you’ve performed a proper threat and risk assessment, you may be better off spending your security dollars elsewhere if you deem the risk of insider abuse is minimal. Of course this argument does not take into account remote access, multiple branch locations and the like, but that’s a topic for another day…

Let’s look at what has to happen before a vulnerability can be successfully exploited. I am reminded of the consecutive steps in the Three-mile Island Accident of 1978 that all had to happen for the accident to occur – breaking any of the steps would have mitigated the accident. Despite diligent efforts to discover and eradicate IT vulnerabilities some may still exist – as system complexity grows so does the possibility of vulnerabilities being present. Even with a very mature software development process vulnerabilities will exist. How they get into systems is the subject of a future post.

So we now have a vulnerability in our voice system. What needs to happen for it to be exploitable – so that the system can be successfully compromised? A suitable threat vector must exist. A threat vector is a path or a tool that a malicious agent uses to attack the system and exploit the vulnerability. As was discussed on this blog by a recent post by Stephan Varty of Nortel, just because a vulnerability and threat vector are present does not mean a viable method of compromising the system exists. So a vulnerability by itself does not result in a compromised system – it provides a target if a viable threat vector exists. If the threat vector succeeds we then can have a compromised system.

So how do we mitigate this vulnerability/threat vector pair? We can either eliminate the vulnerability or remove the threat vector. This is why we assign a probability to the success of the threat vector – we determine the risk. Once we know the risk we can select appropriate controls and risk mitigation strategies. This is why it is important for vulnerabilities to be appropriately reviewed, a determination made on the corresponding risk of compromise, and an appropriate measured response made.

Best practice is very important in the deployment of voice systems, whether VoIP or TDM. It is even more important as we merge data and voice in Unified Communications (UC) systems. Best practice security is not new to UC or VoIP – we all should remember the stories of companies that did not change their PBX configurations so that “phone phreakers” that where able to be authenticated to the system for voice mail could easily get an outside line and make toll calls. A vulnerability, not really; a miss configured feature yes; a threat vector yes; the solution – proper installation, configuration and best practice.

Let’s look at the example discussed in the article: Analysis: Hacking VoIP, As Easy As 1-2-3. Without having a detailed architectural diagram of the system compromise I can only comment in generalities. It is stated that they attacked the target system outside the firewall. Hmm…how was the firewall treating VoIP? Were pinholes punched through it – allowing all traffic on a specific port, with a specific protocol to transition the firewall without inspection? Or was an application level gateway for VoIP running, an application gateway understands the specific protocols allowed through and ensures that the protocol requests are appropriate, coming from specific end-points? The example further states that a laptop was used to monitor the exchange between the call server and the soft client. Why is this exchange not encrypted? SSL for signaling and SRTP for VoIP is one approach, an SSL or IPSec VPN is another. To successfully exploit the vulnerability as explained two threat vectors had to exist. Both vectors could have been mitigated by the use of standard VoIP best practice installations; coupling these with additional best practices in the VoIP deployment (ex. Session Border Controller) would have further lowered the risk; and ensuring the vulnerabilities are patched in a timely manner would have completed the mitigation. Just like in the Three Mile Island Accident example it is not one vulnerability that results in the compromise, but a vulnerability and bad risk management decisions.

In a series of upcoming posts we will discuss current best practices for voice system deployments including UC solutions – and how with an appropriate risk management approach you can put controls in place to mitigate many potential vulnerabilities and threat vectors. In the mean time remember that media buzz surrounding voice system vulnerabilities may sound worrisome, but it you have a proper risk management system in place with appropriate controls and best practices you can respond in an appropriate manner. Vulnerability identification is important, managing the risk is critical.

Lawrence

Over the past 10 years, SecureLogix has conducted many voice security assessments for enterprise customers. A proper voice security assessment will include two parts. First the TDM or VoIP trunks connecting one or more enterprise sites to the public network must be instrumented. All the voice traffic into and out of the site(s) is monitored and any security issues are identified. For customers with VoIP, a VoIP security vulnerability assessment/penetration test should be included. In this case the internal network is accessed and the IP PBX, network, and VoIP phones are tested for vulnerabilities.

Interestingly, while we always find vulnerabilities on VoIP systems, we have only seen one real world attack, and that attack involved good-old-fashioned toll fraud. However, we also find voice application security issues. These security issues are present whether the enterprise is using VoIP or not. Some of the issues we find include:

• Unauthorized modems used to access the Internet – most users know that if they access inappropriate sites on the Internet through the primary connection, that the access will be detected, logged, and possibly blocked. Some users bypass this security by connecting an analog phone line to a modem in their PC/laptop and dial their Internet Service Provider (ISP). While this isn’t a fast connection, it is fine to check personal mail, check stocks, look at sport sites, etc. We have seen as many as 100 simultaneous unauthorized modem connections at large sites. These connections are unmonitored and can allow the user to accidentally download malware or leak confidential information. Plus, the connection is also not protected by a network firewall and an attacker who finds the user’s IP address can hack in, attack the PC/laptop, and/or jump off onto other systems.
• Poorly secured authorized modems – many critical infrastructure systems, including PBXs and other equipment, use modems for remote access. These modems can be easily found by simple “war dialing” of numbers at an enterprise site. Many of these modems are poorly protected and once found, can be exploited. These attacks can be very serious, because the systems connected to the modems are often critical.
• Toll fraud – while VoIP has made some long distance calling a lot cheaper, some long distance, especially international calls, can be still be expensive. Toll fraud is still a serious issue for the enterprise. It can range from a few international calls made over fax lines to a hacked Direct Inward System Access (DISA) or VoIP interface, where the attacker sells numbers/access and can rack up $100,000s of charges in a short amount of time.
• Harassing calls – this includes a variety of irritating and even dangerous calls and call patterns, to include fax SPAM, harassing executives, bomb threats, and other attacks.
• Social engineering – includes calling into enterprises and call centers looking for inexperienced users who give out confidential information.

So while VoIP vulnerabilities get a lot of the hype, don’t forget about basic application voice security issues. They are virtually always present at enterprise sites, whether VoIP is used or not.

Mark Collier
Chief Technology Officer/Vice President Engineering
SecureLogix Corporation
13750 San Pedro
San Antonio, Texas 78232
www.securelogix.com
www.voipsecurityblog.com

]]> http://blogs.nortel.com/voicesecurity/2008/06/30/traditional-voice-security-threats/feed/