Similar to Email or web services, SIP components can use DNS and ENUM servers to find out how to route a SIP message. Using DNS has the great advantage that the operator does not need maintain local routing tables. DNS enables the operator to support load balancing and geographical redundancy, as well as change the IP addresses of some destination only by using DNS servers without the need to provision each SIP server separately with the needed routing information.

However, using DNS is not without costs both in terms of reliability and security. DNS servers can fail. In this case, SIP servers that contact the failed DNS server will not get a reply and will timeout. This introduces significant delays to the call establishment. In order to avoid these delays, multiple DNS servers must be used and the SIP servers should proactively monitor the status of these servers to avoid contacting a failed server. Additionally, SIP servers should implement a DNS cache so the results of DNS queries are saved locally and can be used to serve requests for destinations that were already resolved – even if no DNS server is available. This way, the cache can help keep the VoIP functioning –at least partially – even if no DNS servers are reachable.

Attacks that affect the DNS service will also have negative effects on the VoIP service as well. Here we can distinguish between two types of attacks, redirection and overloading attacks. The goal of redirection attacks is to forward SIP requests to a malicious site. This is achieved by providing a SIP server with manipulated responses for its DNS queries. Hence, a SIP server that tries to locate the IP address of the VoIP server of example.com ends up at a server belonging to the attacker. This can be achieved by intercepting the DNS queries, guessing the content of a DNS query and blindly answering it, DNS cache poisoning or hijacking a DNS server. By forwarding a SIP request to a manipulated server, the attacker can implement a man in the middle attack and either reply to the call himself –pretty bad if the call was going to the bank for example- or manipulate the SIP requests so as to reduce the security level so that the call ends up being established without any encryption allowing the attacker to eavesdrop on the communication.

Overloading attacks are based on misusing the query/response nature of DNS. When a SIP server issues a DNS query then it will block some memory and processing capacity while waiting for the response. On average it takes 1.3 DNS queries to receive an answer with the mean resolution latency less than 100 msec. The resolution latency is considerably increased in the following cases:

• Irresolvable names
• Congested networks and overloaded servers

With Overloading attacks the attacker aims at misusing and increasing the processing resources needed for resolving domain names which can lead to memory depletion or blocking of the entire server. This can be achieved by causing the SIP server to resolve domain names that are either irresolvable or are served by overloaded servers.

This kind of attacks can be mounted by sending SIP requests to the SIP server with an irresolvable domain name included in a header that used by the SIP server for routing the messages, e.g. Via or route headers or in the Request-URI. Such requests are otherwise well formatted SIP requests that comply with the SIP standard in every respect.

An attacker can ensure that a domain name is irresolvable by launching a denial of server attack on the authoritative server of this domain. Another approach is to actually register a number of domain names and set the addresses of the authoritative servers of these domains to hosts that do not reply to DNS queries or do not exist at all. For registering a domain name the attacker is supposed to provide his name, address and payment information for a domain name registration company. However, as the name and address information are usually not verified and stolen credit cards can be used for payment the attacker can falsify this information and hide his identity.

Using DNSSec (RFC2137) or secured links, e.g., TLS or IPSEC, between DNS servers and SIP servers can minimize the possibility of eavesdropping, guessing and cache poisoning and hence the chance of a redirection attack. However, using these approaches increases the complexity of using DNS, increases the processing and bandwidth needs for using the DNS server and some cooperation between the different entities marinating the different DNS servers. Also, in case an attacker manages to hijack a DNS server then at least the domains for which the hijacked servers acts as the authoritative server will still be unprotected.

The effects of overloading attacks can be reduced by implementing a DNS cache at the SIP servers. By caching not only the positive but also negative responses to a DNS query, a SIP server will not query a malicious address more than once. This will greatly reduce the number of DNS queries issued by the SIP server. Additionally SIP servers should include “receive” tags to their own Via headers. In the “receive” tag the SIP server includes the IP address from which a request was received. This way, when receiving the response, the SIP server will not have to resolve any DNS entry in the Via headers. 

No related posts.