VoIP Threat Taxonomy
- Threats Against Availability
- Threats Against Confidentiality
- Threats Against Integrity
- Threats Against Social Context
- Summary
- References
This chapter is from the book
This chapter is from the book
This chapter is from the book
This chapter covers the taxonomy of VoIP threats based on the following categories:
- Threats against availability
- Threats against confidentiality
- Threats against integrity
- Threats against social context
The VoIP vulnerabilities that were introduced in Chapter 1, "Working with VoIP," can be exploited to create many different kinds of threats. Attackers may disrupt media service by flooding traffic, collect privacy information by intercepting call signaling or call content, hijack calls by impersonating servers or impersonating users, make fraudulent calls by spoofing identities, and so on.
Spammers may utilize VoIP networks to deliver spam calls, instant messages, or presence information, which are more effective than email spams because it is very difficult to filter VoIP spam.
This chapter is not intended to provide exhaustive lists of current and potential threats, but to define the taxonomy for the following purposes:
- To identify the threat in the first place
- To measure the current impact and potential future impact of the threat
- To help develop the protection method and design a secure service architecture
There are many possible ways to categorize the threats. This book uses the following four categories that most VoIP threats can belong to:
- Threats against availability
- Threats against confidentiality
- Threats against integrity
- Threats against social context
Each section in this chapter covers each category with typical threat examples. To give you a better understanding, each section uses figures and protocol examples with Session Initiation Protocol (SIP).
The following section introduces the most critical threats that impact service availability.
Threats Against Availability
Threats against availability are actually a group of threats against service availability that is supposed to be running 24/7 (24 hours, 7 days a week). That is, these threats aim at VoIP service interruption, typically in the form of Denial of Service (DoS).
The typical threats against availability are as follows:
- Call flooding
- Malformed messages (protocol fuzzing)
- Spoofed messages (call teardown, toll fraud)
- Call hijacking (registration or media session hijacking)
- Server impersonating
- Quality of Service (QoS) abuse
The following subsections describe the threats with examples, which show you how they impact service availability.
Call Flooding
The typical example of DoS is intentional call flooding; an attacker floods valid or invalid heavy traffic (signals or media) to a target system (for example, VoIP server, client, and underlying infrastructure), and drops the performance significantly or breaks down the system. The typical methods of flooding are as follows:
- Valid or invalid registration flooding—An attacker uses this method commonly because most registration servers accept the request from any endpoints in the public Internet as an initial step of authentication. Regardless of whether the messages are valid or invalid, the large number of request messages in a short period of time (for example, 10,000 SIP REGISTER messages per second) severely impacts the performance of the server.
- Valid or invalid call request flooding—Most VoIP servers have a security feature that blocks flooded call requests from unregistered endpoints. So, an attacker registers first after spoofing a legitimate user, and then sends flooded call requests in a short period of time (for example, 10,000 SIP INVITE messages per second). This impacts the performance or functionality of the server regardless of whether the request message is valid or not.
- Call control flooding after call setup—An attacker may flood valid or invalid call control messages (for example, SIP INFO, NOTIFY, Re-INVITE) after call setup. Most proxy servers are vulnerable because they do not have a security feature to ignore and drop those messages.
- Ping flooding—Like Internet Control Message Protocol (ICMP) ping, VoIP protocols use ping messages in the application layer to check out the availability of a server or keep the pinhole open in the local Network Address Translation (NAT) server, such as SIP OPTIONS message. Most IP network devices (for example, a router or firewall) in the production network do not allow ICMP pings for security reasons. However, many VoIP servers should allow the application-layer ping for proper serviceability, which could be a critical security hole.
Figure 2-1 illustrates the example of distributed flooding with zombies; an attacker compromises other computers with malware (for example, a virus) and uses them as zombies flooding registration messages. Each zombie sends 1,000 SIP REGISTER messages per second with different credentials that are randomly generated.
)
Figure 2-1 Call Flooding Example
In Figure 2-1, the flooded messages will impact the registration server (SIP Registrar) severely as long as the server processes and replies with any error codes, such as "401 Unauthorized," "404 Not Found," "400 Bad Request," and so on. The impact can be high resource consumption (for example, CPU, memory, network bandwidth), system malfunction, or service outage. Whether the server responds or not, flooding the SIP registrar with sufficient registration messages will result in the degradation of service to the legitimate endpoints.
Not only the intentional flooding just mentioned, but also unintentional flooding exists in VoIP networks, so-called "self-attack," because of incorrect configuration of devices, architectural service design problems, or unique circumstances. Here are some examples:
- Regional power outage and restoration—When the power is backed up after a regional outage, all endpoints (for example, 10,000 IP phones) will boot up and send registration messages to the server almost at the same time, which are unintentional flooded messages. Because those phones are legitimate and distributed over a wide area, it is hard to control the flooding traffic proactively.
- Incorrect configuration of device—The most common incorrect configuration is setting endpoint devices (for example, IP phones) to send too many unnecessary messages, such as a registration interval that is too short.
- Misbehaving endpoints—Problematic software (firmware) or hardware could create unexpected flooding, especially when multiple or anonymous types of endpoints are involved in the VoIP service network.
- Legitimate call flooding—There are unusual days or moments when many legitimate calls are made almost at the same time. One example is Mother's Day, when a lot of calls are placed in the United States. Another example is natural disasters (for example, earthquakes), when people within the area make a lot of calls to emergency numbers (for example, 911) and their family and friends make calls to the affected area at the same time.
Those types of intentional and unintentional call flooding are common and most critical threats to VoIP service providers, who have to maintain service availability continually.
The next type is another form of threat against service availability, by means of malformed messages.
Malformed Messages (Protocol Fuzzing)
An attacker may create and send malformed messages to the target server or client for the purpose of service interruption. A malformed message is a protocol message with wrong syntax. Example 2-1 shows an example with a SIP INVITE message.
Example 2-1. Malformed SIP INVITE Message
Request-URI: aaaaaaaaa sip:1001@192.168.10.10 SIP/2.0
Message Header
Via: SIP/2.0/UDP CAL-D600-5814.cc-
ntd1.example.com:5060;branch=z9hG4bK00002000005
From::::::::: 2 <sip:user@CAL-D600-5814.cc-ntd1.example.com>;tag=2
To: Receiver <sip:1001@192.168.10.10>
Call-Id: 555555555555555555555-5555555555555555555555555555-55555555555555555-
5555555-55555555555555555555-5555555555555-55555555555555555-555555555-
555555555@CAL-D600-5814.cc-ntd1.example.com
CSeq: 1 INVITE
Contact: 2 <sip:user@CAL-D600-5814.cc-ntd1.example.com>
Expires: 1200
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 143
Message body
Session Description Protocol
Session Description Protocol Version (v): = = = = = = 0
Owner/Creator, Session Id (o): 2 2 2 IN IP4 CAL-D600-5814.cc-ntd1.example.com
Session Name (s): Session SDP
Connection Information (c): IN IP4 192.168.10.10
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 9876 RTP/AVP 0
Media Attribute (a): rtpmap:0 PCMU/8000
Note that the comments (bold letters) in Example 2-1 are not shown in the actual SIP INVITE message. You can find something wrong in the example of an INVITE message. Three SIP headers (Request-URI, From, and Call-Id) and one version in Session Description Protocol (SDP) have the wrong format.
The server receiving this kind of unexpected message could be confused (fuzzed) and react in many different ways depending on the implementation. The typical impacts are as follows:
- Infinite loop of parsing
- Buffer overflow, which may permit execution of arbitrary code
- Break state machine
- Unable to process other normal messages
- System crash
This vulnerability comes from the following sources in general:
-
Weakness of protocol specification
Most VoIP protocols are open to the public and don't strictly define every single line. Attackers could find where the weakness of syntax is. Additionally, there are many customizable fields or tags.
-
Ease of creating the malformed message
Creating a message like that in Example 2-1 is easy for regular programmers. Even for nonprogrammers, many tools are available to make customized messages.
-
Lack of exception handling in the implementation
Because of time restrictions, most implementers are apt to focus on product features and interfaces, rather than create exception handling for massive negative cases.
-
Difficulty of testing all malformed cases
It is very difficult to test all the negative cases, even though sophisticated testing tools covering more cases are coming out these days.
The threat of malformed messages should be preventable as long as the parsing algorithm handles them properly.
The next threat is spoofed messages that are not malformed but still impact service availability.
Spoofed Messages
An attacker may insert fake (spoofed) messages into a certain VoIP session to interrupt the service, or insert them to steal the session. The typical examples are "call teardown" and "toll fraud."
Call Teardown
The method of malicious call teardown is that an attacker monitors a SIP dialog and obtains session information (Call-ID, From tag, and To tag), and sends a call termination message (for example, SIP BYE) to the communication device while the users are talking. The device receiving the termination message will close the call session immediately. Figure 2-2 illustrates the example with SIP messages.
)
Figure 2-2 Malicious Call Teardown
Figure 2-2 assumes that the attacker already monitored call signals between User A and B, and knew the session information (SIP dialog). The attacker injects the session information to the BYE message. The IP phone of user A receives the BYE and disconnects the media channel.
Another method of attack is that an attacker sends the termination messages to random devices (especially, proxy server) without knowing session information, which may affect current call sessions.
Compared to previous threats in this section, the malicious call teardown is not a common attack because the attacker should monitor the target call session before sending a termination message (BYE).
The next type of attack, toll fraud, also requires preliminary information like credentials before making fraud calls, but it happens commonly because of monetary benefit.
Toll Fraud
A fraudulent toll call is one of the common threats these days, especially for long distance or international calls. Because most mediation devices (for example, public switched telephone network [PSTN] media gateway, proxy server) require valid credentials (for example, ID and password) before setting up the toll call, an attacker collects the credentials first in many different ways. Typically, an attacker creates spoofed messages for brute-force password assault on the server until he receives authorization. If the clients use default passwords or easy-to-guess passwords, it is much easier to find them, especially when an attacker uses a password dictionary (see Note).
In some cases, the server does not require the credentials, but checks out the source IP address or subnet of the client to control the access. Especially when call trunking (for example, SIP trunking) is set up between a VoIP service provider and an enterprise customer, access control based on the source IP or subnet is commonly used. An attacker may be able to access the server by spoofing the source IP address.
Call Hijacking
Hijacking occurs when some transactions between a VoIP endpoint and the network are taken over by an attacker.
The transactions can be registration, call setup, media flow, and so on. This hijacking can make serious service interruption by disabling legitimate users to use the VoIP service. It is similar to call teardown in terms of stealing session information as a preliminary, but the actual form of attack and impact are different.
The typical cases are registration hijacking, media session hijacking, and server impersonating. The next few sections describe each of these cases.
Registration Hijacking
The registration process allows an endpoint to identify itself to the server (for example, SIP Registrar) as a device that a user is located.
An attacker monitors this transaction and sends spoofed messages to the server in order to hijack the session. When a legitimate user has been compromised, that user cannot receive inbound calls. Figure 2-3 illustrates the example with SIP messages.
)
Figure 2-3 Registration Hijacking
In Figure 2-3, an attacker impersonates a user agent by modifying the "From" header and adding the attacker's address to the "To" header when it sends a REGISTER message, which updates the address-of-record of the target user. All inbound calls to User A will be routed to the attacker.
This threat happens when the user agent server (Registrar) is relying on only SIP headers to identify the user agent.
Media Session Hijacking
When a media session is being negotiated between VoIP endpoints, an attacker may send spoofed messages to either one of them to redirect the media to another endpoint such as the attacker's phone or voicemail box. The victim will only be able to talk with the attacker's endpoint. Figure 2-4 illustrates the example with SIP messages.
)
Figure 2-4 Media Session Hijacking
In Figure 2-4, User A tries to make a call to User B and the IP phone of User B is ringing. Having monitored call requests to User B, an attacker detects the call and sends 200 OK messages to User A with the IP/port address of the attacker's voicemail server. User A leaves a voice message for User B in the attacker's voicemail box. This hijacking happens before the media session is established between User A and (the intended) user B.
Even after the media session is established between A and B, an attacker can still hijack an active session by sending a Re-Invite message to User A.
Server Impersonating
A VoIP client sends a request message to a server in the target domain for registration, call setup or routing, and so on. It is possible for an attacker to impersonate the server, receive the request message, and then manipulate it for malicious purposes.
The typical method of impersonating a server is attacking the local TFTP server or Domain Name Service (DNS) server as the initial step. An attacker may intrude into the TFTP server and replace the configuration file for IP phones with his file having an IP address of a malicious server (for example, SIP Registrar).
The IP phones downloading the malicious file will send a request message to the wrong server.
An attacker may also compromise the DNS server and replace the entry of current VoIP server with an IP address of a malicious server. The IP phones looking up the server IP will receive a wrong one. Figure 2-5 illustrates an example based on SIP transactions with a Redirect server.
)
Figure 2-5 Server Impersonating
In Figure 2-5, the attacker compromised the local DNS server first by replacing the IP address (10.1.1.10) of original.redirect.com with 10.10.10.10, which is the attacker's redirect server.
When User A tries to make a call to User B, the IP phone looks up the IP address of the redirect server (original.redirect.com) and receives the IP (10.10.10.10) of the impersonated server. The INVITE message is sent to the impersonated server, and it replies "302 Moved Temporarily" with wrong contact information that could be a dummy address or attacker's proxy server for further threat. The original redirect server (10.1.1.10) cannot receive any call request in this situation.
QoS Abuse
The elements of a media session are negotiated between VoIP endpoints during call setup time, such as media type, coder-decoder (codec) bit rate, and payload type. For example, it may be necessary or desirable to use G.729 when leaving a network (to conserve bandwidth) but to use G.711 when calls are staying inside a network (to keep call quality higher). An attacker may intervene in this negotiation and abuse the Quality of Service (QoS), by replacing, deleting, or modifying codecs or payload type.
Another method of QoS abuse is exhausting the limited bandwidth with a malicious tool so that legitimate users cannot use bandwidth for their service. Some VoIP service providers or hosting companies limit the bandwidth for certain groups of hosts to protect the network. An attacker may know the rate limit and generate excessive media traffic through the channel, so voice quality between users may be degraded.
In this section so far, you have learned about threats against availability, such as call flooding, malformed messages, spoofed messages (call teardown, toll fraud), call hijacking (registration and media session hijacking, server impersonating), and QoS abuse. The next section covers another type of threat: attacks against call data and media confidentiality.