Putting a PAL to work

Voice over IP – VoIP – is inevitable in government. It is the hottest area, and many government departments are exploring how they can take advantage of its benefits – like greater flexibility in service and features and possibly lower costs. This rating is reserved for the most critical problems.

On the dark side, however, is a concern with security. As usual, new security vulnerabilities go hand in hand with new IT services. A lot of work often needs to be done just to achieve the same baseline of security that was available with the previous generation of equipment – if in fact the old level is even achievable any more.

The PAL initiative

In the federal government, Public Safety and Emergency Preparedness Canada (PSEPC), Communications Security Establishment (CSE), Industry Canada and other government departments all have roles to play in VoIP. Industry Canada, for example, established the Protocol Analysis Lab (PAL) within Michael Binder’s organization in 2002 to assist in providing engineering support for telecommunications policy development.

Among other activities, PAL analyses newly discovered vulnerabilities in IP and telecommunications systems and helps formulate a government response in collaboration with industry and other government partners. The work at this lab has recently taken them to the cutting edge in VoIP security, especially in crucial areas such as understanding how to shield vulnerable systems from hacker attacks.

The origins of the PAL team go back to an infamous security issue in communications systems, when the University of Oulu in Finland published the results of a research project in protocol vulnerability testing. The work uncovered problems in the commonly used network management protocol based on ASN.1. The result rendered many IT and telecom systems vulnerable. A later generation of this tool, known as PROTOS, was released in 2004; it was designed explicitly to find vulnerabilities in SIP implementations, a commonly used protocol in VoIP systems.

This was the kick-start the hacker community needed, and a day after the PROTOS release commercial SIP telephones were knocked out. This led to a new focus on VoIP for the PAL team. A good understanding of what this entails can be seen by looking at a day in the life of the lab when a security vulnerability hits the Internet. However, to put this in context, a brief tour of the major VoIP security concerns is required.

VoIP = new technology and new security concerns

The technology newness and flexibility of VoIP is at the heart of the security issue. The technology incorporates new IP-based protocols that are responsible for call-processing signalling, and these run on the same network as the voice communication payload. These open protocols provide for much greater flexibility and application development, which is the key for many higher valued returns promised for the future. However, the openness and greater flexibility represents opportunities for attackers as well.

On top of this, these new call-processing protocols such as Session Initiation Protocol (SIP) were designed with minimal security built in. The standards committee developing the specification at the time believed that security would be “added on later” by running SIP over a secure link. This violates the fundamental security tenant of “build it in” – as opposed to trying to patch later; telecom equipment that faithfully implements the SIP specification could be in for a rough ride from attackers, and special attention must be paid to detect and stop attacks that can compromise service.

So far, VoIP has not experienced many big security issues, but don’t take this as a forecast of the future. VoIP is only starting to reach critical mass as a “target rich environment.” As soon as this happens, the hacking community will turn to it with an eye to making money. The recent VoIP related fraud and arrest last June of Edwin Pena, 23, the owner of two small Miami VoIP companies, is a sign of the times ahead. In this case Pena and his 22-year-old hacker collaborator Robert Moore hacked into third party VoIP services and routed their customer’s calls over those networks. Pena collected the fees from customers, to the tune of $1 million, but did not pay any service provider. The publicity on this case is sure to inspire similar attacks.

There are many threats to VoIP, but attacks that exploit the open nature of the protocol have high potential for damage. There is no difference here when compared to life on the Internet for any other application, such as e-mail. As soon as basic application operation is locked down, the most damaging attacks are those that exploit vulnerabilities in software. However, here is where greater danger lurks for VoIP users. The traditional defence for generic software vulnerabilities is to keep up with patches. The problem is that applications such as VoIP will have vulnerable software embedded into many hardware devices, such as PBXs and telephone handsets, which are more difficult to update. This gives rise to a newer defence strategy of shield first, patch second. It is the shielding aspect, among others, of VoIP vulnerabilities that Industry Canada’s PAL team is exploring.

Top VoIP security Issues – what is a real issue, what is just noise?

It is becoming common to see technical presentations or articles on VoIP security providing a long list of security threats, along with matching security tips. The top three are denial of service, fraud and abuse, and privacy and confidentiality. It is not unusual to see conference demonstrations of interceptions and replay of voice calls. However, many of these threats such as interception are much more theoretical than practical. Think of the attackers; they are motivated by money, and attacks such as the Edwin Pena fraud scheme come quickly to mind. Certainly unauthorized interception is a problem, but it is not the first thing to worry about. However, if you encrypt every single e-mail in your environment, you would be concerned with encrypting VoIP payloads. But for most environments, you want to keep a reliable service operating and not let it become a platform for hackers to launch other attacks. The reason hackers can launch malware is because software has vulnerabilities. VoIP software is no different, and vulnerabilities will be the number one security issue.

In general, VoIP security means dealing with the same security issues as you would around any other application. If you follow best practices, and do well as part of routine IT security audits, you are well positioned to deploy VoIP with confidence. Particular attention must be paid to the continuous process of staying secure by addressing software vulnerabilities and the appropriate shielding/patching/response mechanisms.

Software vulnerabilities

As with any other application exposed to the internet, the root cause of malware is a known vulnerability. Hackers then launch viruses or worms that exploit the vulnerability. Typical mitigation practice has been to update virus scanner signatures and patch vulnerable software. These techniques are simply not enough any more, as zero-day exploits and targeted attacks are becoming common. A zero-day exploit means you are hit before you knew there was a problem. In this case hackers keep information about a vulnerability to themselves until they are ready to launch their attack. As these attacks are motivated by financial gain, they are often designed to take over machines to harvest them as part of a bot-net. When someone controls tens of thousands of machines they are used to launch denial-of-service attacks on, for example, an Internet gambling site in order to extort “protection” money. So rather than create a nuisance by writing a virus, hackers are now individually targeting vulnerable systems to take them over for use as a platform for other attacks. In a VoIP environment, it is easy to see the appeal in compromising a server that will result in infecting all connected soft phones, for example.

The software vulnerability life cycle starts with a newly discovered or published vulnerability and ends when machines are patched. In practice, however, all machines will never be patched, so vulnerabilities are tracked as a half-life, when for example half of vulnerable hosts are patched. According to Qualys, the current half-life for Internet-facing hosts is 19 days, down from 30 days a couple of years ago. However, we lose this race to the hackers as the average latency now is only six days from discovery to attacks. It is important to note that 80 per cent of attacks occur during the first half-life. So if you are a target – and government departments are – you had better be patched or shield for a known vulnerability right away.

VoIP software vulnerabilities

Along with shrinking intervals, the discovery rate for vulnerabilities continues to increase, recently averaging more than 100 a week. While software such as Internet Explorer has been a favourite target for vulnerability researchers, VoIP vulnerabilities are now starting to make it on the lists. For example, July 2006 was a big month for browsers, with HD Moore (the co-founder of the Metasploit Network, a well known vulnerability exploit testing tool) releasing proof-of-concept exploit code for one browser flaw per day for the month of July. However, also in July was the publication of the SIPfoundry sipXtapi Buffer Overflow vulnerability, which garnered the maximum rating of 10 on the common vulnerability scoring system (CVSS). This rating is reserved for the most critical problems.

New VoIP vulnerability and the PAL team

When Dave Gibson, an engineer in the the PAL team, arrived at work on the morning of July 10, he started his day with the usual scan of Internet feeds that report on vulnerability discoveries. The sipXtapi issue caught is attention. He noted the reported maximum severity level, and quickly scanned sources to obtain more details. He learned that it was of the most common variety, a buffer overflow flaw, but this particular one was dangerous because it was remotely exploitable. This means the attacker can get the vulnerable host to run arbitrary code. This exploit code would typically be a small program that would subsequently download more code under remote control. For the hacker to exploit this vulnerability, it is a rather simple matter of sending a specially crafted message to the machine; then the hacker owns it.

The PAL team understood that this vulnerability scored the maximum rating because the software was widely deployed, combined with the ease of carrying out an exploit. In this case, the code was part of the SIPfoundry project, an open source library dedicated to accelerating the adoption of the SIP protocol. As such, this library is used in many SIP products from multiple vendors. Vulnerable systems were any product that used this library that compiled before March 24 2006. At the time it included several common applications, including PingTel products and AOL’s Triton Instant Messaging application. The SIP protocol is finding its way in numerous multimedia applications, including instant messaging applications, and these may have large installed bases that could render potentially millions of PCs vulnerable.

In parallel with understanding the nature of the problem, the team looked at what software used this library, to determine whether the vulnerability affected telecommunications infrastructure.

In an attack, how can you protect vulnerable VoIP systems?

When investigating the sipXtapi problem, the PAL team verified the vulnerability on affected systems by launching exploit code and observing the result. In this case the job was made easier as the Internet postings conveniently included a “proof of concept” example of exploit code.

The team decided to try a test run on a new tool the lab was evaluating as a shielding element for exactly this type of incident. The tool is a host-based intrusion prevention system (HIPS) based on deep packet inspection. This is a relatively new approach in detecting and neutralizing malware, using software that incorporates an inspection firewall with rules for deep packet inspection that only allows correctly formatted protocols through, thus blocking attacks. This software resides at the driver level on various hosts and endpoints that run VoIP software.

Other mitigation approaches were considered. In this case, a firewall rule to block the port could not be used, as the protocol must be allowed though. Patching could be problematic, given the widespread application base that uses this library. Waiting for the anti-virus vendors to update signatures after exploits appear in the wild leaves systems exposed for some time. Along with being slow and reactive, another risk is being hit with a targeted attack that runs with a low enough infection rate to stay off the anti-virus signature radar. A filter update for IPS, on the other hand, is much more proactive, as one shield update provides protection for an unlimited number of future attacks on the same vulnerability. This means your application is protected and you stay ahead of the hacker exploit cycle. When the vulnerable software is finally patched, the particular filter for the IPS system can be removed. 068542

Brian O’Higgins (brian.ohiggins@thirdbrigade.com) is CTO of Third Brigade, an Ottawa-based security company that provides host-based intrusion prevention solutions.

Related Download
Improving the State of Affairs With Analytics Sponsor: SAS
Improving the State of Affairs With Analytics
Download this case study-rich white paper to learn why data management and analytics are so crucial in the public sector, and how to put it to work in your organization.
Register Now