Subscribe Now

* You will receive the latest news and updates on the Canadian IT marketplace.

Trending News

Blog Post

Let’s talk security
SECURITY SHELF

Let’s talk security 

VoIP delivers flexible and inexpensive phone service. Unlike traditional telephone company offerings and proprietary PBXs, open source products such as Asterisk make sophisticated phone systems readily available to individuals and small businesses. An old PC or small virtual machine can handle the needs of a small office. Software distributions such as AsteriskNow and FreePBX make it easy to install and configure a phone system.

Unfortunately, the developers of these open source products have paid little attention to security, even though commercial products rely on the same underlying code. For example, the FreePBX front-end uses HTTP for administration with no option for HTTPS. By default Fail2Ban is installed — an application that attempts to limit intrusions by monitoring log files and using the operating system firewall to block users who appear to be trying to break in — but this package is largely ineffective and may just as likely be leveraged by attackers to commit a denial of service attack.

From a security perspective, Asterisk is plagued by poor design. By default, many security-related events, such as a SIP device successfully registering to the PBX, are not logged. Other log entries contain incomplete information. If an attacker without credentials attempts to place a call through the PBX, Asterisk fails to log the attacker’s IP address. While this information may be found on the console or in debug logs, the lack of a proper audit log is inexcusable in 2014.

Asterisk is not alone in this regard; a lot of work has obviously been done to make it perform as well as it does. Those who are technically inclined can download it for free, or it can be purchased from several vendors pre-installed on appropriately-sized hardware and commercial support is available. But if a security conscious administrator were to monitor log files or connect it to a SIEM, many attacks would go unnoticed…until the organization’s bill for VoIP call termination services suddenly shoots up. It is frustrating that otherwise terrific software is incapable of detecting and preventing attacks and fails to provide sufficient information for external systems to do so.

Asterisk and other software must face today’s hostile Internet environment and the reality of internal attacks. Compromising a company’s PBX will provide valuable information to those involved in economic espionage, and such attacks may originate from either side of the corporate perimeter.

SIP-based systems on the Internet are exposed to a constant barrage of attacks. A newly commissioned virtual machine in a UK datacenter recorded SIP probes from 12 different IP addresses within the first 24 hours of operation. Similar results are being observed on servers worldwide. Initial probes often leverage the SIP options mechanism, which was included in the protocol to allow peers to obtain required technical information such as a list of available CODECs.

Some attackers attempt brute force registrations, literally starting with extension 1 and working their way up. These attacks, while simplistic, have evolved somewhat to defeat common countermeasures. For example, some attackers wait more than 10 minutes between attempts to prevent being blocked by Fail2Ban. These slow and persistent attacks can last weeks and are seldom noticed.

Other attacks are more direct and attempt to place calls through the PBX using a variety of sequences. Some common attack tools automatically increment digits in front of the destination number in hopes of finding a working dial prefix on a poorly configured system.

These attacks are widespread and frequent because they work. There are so many VoIP PBXs connected to the Internet that unsophisticated persistent scanning is able to locate vulnerable systems and exploit them.

In addition, most VoIP traffic travels unencrypted across the Internet, making it easy for sophisticated adversaries to monitor and intercept metadata and voice traffic.

VoIP product developers must add security throughout their products to combat attacks. Products require safeguards to help users avoid insecure configurations. Security features, such as intrusion prevention, belong in the core product where events can be considered in context. Audit logs must provide complete information on all events for SIEM integration and forensic use. Strong cryptography is required to protect signalling and voice data.

Related posts