Some weeks ago Hendrik explained in his blogpost Security Analysis of VoLTE, Part 1 some attack vectors for Voice over LTE (VoLTE). One attack vector introduced was Denial of Service (DoS), which I also discussed in my Masterthesis “Evaluation of IMS security and Developing penetration tests of IMS”.
In general, DoS attacks aim to prevent a system or a network from efficiently providing its service to legitimate users . The impact of such attacks can vary from a big degradation of quality to total blockage. DoS can occur on users level, where a user or a group of users cannot use the service. But the common conception of DoS is on the service level, where the whole service is broken, unstable or totally down. This blog post is about targeting DoS of the whole VoLTE service by attacking IMS.
Flooding
Flooding is the first attack that comes to mind when DoS is mentioned. As its name implies, it is basically subjecting a system or a network to tons of messages, which consume its resources until it is overloaded and perhaps crashes. As any other IP based protocol, SIP is vulnerable to classic Layer 4 (TCP and UDP) flooding attacks. In addition, overloading IMS with legitimate SIP requests could also have dangerous impacts.
TCP/UDP flooding
SIP can be transported over TCP or UDP. Although UDP is the default protocol, it is up to the network to decide which transport protocol is supported, if not both. TCP and UDP flooding attacks usually threaten the first entry node of IMS (In most cases: P-CSCF that serves the attacker). TCP flooding attacks aim to consume the target’s resources so it cannot establish any other TCP connection with other legitimate users. For example, TCP SYN flooding attacks establish a lot of “half-opened” TCP connections with P-CSCF. This prevents any legitimate user from establishing TCP sessions with P-CSCF to register to IMS. The impact might end when the attack stops or it might lead to application crash. UDP flooding attacks can only consume the bandwidth of P-CSCF so that it cannot communicate with other users, which is unlikely given the huge bandwidth of these nodes. However, the impact of UDP flooding might be significant over a congested node. There are several free or open source tools to execute flooding attacks, such as:
- UDPFlood
- UDP Unicorn
- Mausezahn
SIP flooding
Flooding at SIP layer does not target the first contact element only, but aims to overload the whole IMS with a huge number of SIP messages to process. Therefore, any node that takes part in handling these requests can be impacted even if it is the last one in the request handling order. To achieve that, all messages should be correct in order to be accepted by all nodes and forwarded until the last node or the end user (depending on the request’s method).
Register flooding is a relatively simple SIP flooding attack because IMS accepts Register requests from any IP address within the IMS users’ subnet, whether they are subscribed or not. Register flooding can impact P-CSCF, I-CSCF, S-CSCF or even HSS. SIP Invite is a bit more complicated attack due to the following reasons:
- The sender must be a subscribed user, so the attacker must either subscribe with a legitimate account or spoof other subscribed users’ identity.
- Every Invite request initiates a new SIP dialogue (unless it is a re-Invite request). So if IMS receives several identical Invite requests, it might consider them as duplicates and drop most of them. Therefore the parameters that define SIP dialogue (Call-ID header field and tag parameters) should differ in each Invite request to achieve maximum impact.
Other SIP methods such as Options, Subscribe and Publish can also be used to flood IMS. Flooding using methods such as Update and Cancel might seem ineffective because they must be sent within a dialogue and preceded by an Invite request. On the other hand, those messages trigger some internal actions and consume some of the network resources. So do not underestimate any request.
There are open source or free tools that can perform SIP flooding such as SIPp and “Invite Flooder”, but these tools are not flexible enough to customize the generated SIP messages in order to be accepted and processed by any network. Therefore it is recommended to write your own SIP flooder in any programming language, such as C++, Java or Python. Scapy is an easy Python tool to transport SIP requests over UDP. Building your own flooder has two advantages:
- Flexibility of creating any SIP request in a format that the target IMS requires.
- Ability to change SIP dialogue identifiers in each Invite request.
Fuzzing
Fuzzing is subjecting the target to a large number of intentionally malformed messages to test its tolerance to unexpected input. This type of attacks target implementation mistakes of service applications, such as coding bugs. Therefore, successful attacks differ from an application to another. Malformed messages can be crafted in any way that might impact or crash any node of IMS, for example:
- Changing the order of SIP message header fields might expose a bug in SIP parser implemented in any node.
- Adding SQL injection vectors in the parameters handled by HSS or any other database, such as IMPI in Authorize header field or IMPU of the callee in Invite header URI.
- Setting fields and parameters with malicious payloads to target coding bugs.
- Any other payload that you think would lead to resource consumption of any of IMS nodes.
Fuzzing IMS takes a very long time. IMS, as any other SIP network usually accepts at least 6 different SIP methods, let’s say: Register, Invite, Subscribe, Message, Options and ACK. Each of these methods’ requests contains at least 8 header fields, which in turn might include more than one parameter, which could be injected by a lot of malicious payloads. If you want to speed the process up, the priority is given to the parameters that are usually processed by IMS nodes, such as:
- Request method and URI.
- Call-ID and “tag” parameters in “From” and “To” header fields.
- Cseq: sequence number and the method.
- Authorize header field of Register request.
There are some checks that indicate if a header field or a parameter is worth attacking. For example, examining SIP traffic of the network might reveal a strange customized header field or parameter. This probably means that it is processed by the nodes. Also if the pentester removes a header field or a parameter from a SIP request and it was accepted by IMS, this probably means that it is not worth wasting time on.
There are several tools for SIP fuzzing, such as PROTOS SIP fuzzer and VoIPER. But Dizzy provides the most flexibility to build SIP messages and also set the malicious payloads injected anywhere in the message. The following files are .dizz files of the frequently used SIP requests: Register, Invite, Message and Subscribe. The SIP messages are built according to SIP requests of OpenIMS project.
Register dizz file
Invite dizz file
Message dizz file
Subscribe dizz file
Other supporting files:
Number list
Methods list
Faulty IP list