IP Multimedia Subsystem (IMS) offers many multimedia services to any IP-based access network, such as LTE or DSL. In addition to VoLTE, IMS adds service provider flexibility, better QoS and charging control to the 4th generation of mobile networks. IMS exchanges SIP messages with its users or other IMS and usually these communications are secured by TLS or IPSec. But if an attacker manages to break the confidentiality and the integrity with IMS, he would find it vulnerable to several attacks.
An attacker does not have to overcome transport security to breach confidentiality and integrity with IMS. For example, owning A victim’s User Equipment (UE) could grant an attacker the confidential data he needs to develop many attacks on him. Moreover, motivated attackers, who target IMS itself, can manage to obtain their IPSec ESP Integrity Key (IKESP) from their UE and then manipulate their requests as they like. An example of the latter case is well explained here. This blog post discusses the exploitation of IMS in such cases of integrity and confidentiality loss.
My Master’s thesis “Evaluation of IMS security and developing penetration tests of IMS” discusses the exploitation of IMS vulnerabilities in case its confidentiality and integrity measures are breached. 3GPP specifications and IETF RFCs define how IMS works and therefore can lead us to its vulnerabilities. The attacks to exploit these vulnerabilities are tested and demonstrated on OpenIMS core. Availability attacks on IMS were previously discussed in a previous blog post.
Lab Setup
The test lab consists of two virtual machines, both are hosted on the same host. The first is the OpenIMS virtual machine, which is available to download from the project’s website . It is an Ubuntu machine, with OpenIMS core and two SIP clients installed. Two default users, Alice and Bob already exist on OpenIMS. I added a third user “Evil” to represent an attacker. Although OpenIMS core supports TLS, IPsec and SIP over TCP, I used the default configuration of SIP over UDP. Neither IPsec nor TLS is used.
The second VM is a Kali VM, which represents the attacker. The attacker Evil uses an OpenIC_lite client, in addition to several tools including:
Burp
Due to the similarity between SIP and HTTP, Burp’s Repeater is used as a flexible method to construct and exchange SIP messages with OpenIMS core. As shown below, Repeater is configured to send its messages to the local TCP port 6066.
Socat
It transforms HTTP/TCP messages produced by Burp into SIP/UDP messages that OpenIMS expects, and vice versa. The following command converts TCP traffic coming from port 6066 (output of Burp’s Repeater) into UDP, and forwards it to IMS (192.168.56.102 in this case).
socat -d -d tcp-listen:6066,reuseaddr,fork udp:192.168.56.102
Information Gathering
Before an attacker performs any attack, he goes through a process of collecting as much information as possible about the victim (whether it is a user or the network itself). An attacker can collect much information just by listening to his SIP messages, such as:
Address Discovery
Knowing the IP address of the victim helps the attacker to target a specific node in the network, or spoof the victim’s IP address to steal his identity. When an attacker receives an Invite request, he can find IP addresses, ports and/or FQDN Addresses of the caller or IMS nodes in the following headers:
- Via: a SIP node populates its address in a new Via header field and appends it to a SIP request, in order to guarantee that its response will be routed through this node. Therefore, the Invite request usually includes the address of the initiating user and all the nodes that the SIP request was handled by (PCSCF, I-CSCF and S-CSCF)
- Contact: holds the physical address of the sender of any SIP request. The Contact header usually contains the address of the sender.
- Call-ID: Call-ID should be unique over time and space to identify a specific dialogue. SIP clients might append their IP address to the identifier to ensure uniqueness.
- SDP payload: SDP is carried as a payload of the Invite request, to describe the media session that will later on hold the call. There are two fields that contain information about the IP address of the source of the call, these headers are:
- Connection Data c
- Origin o
In some IMS implementations, users discover the addresses of P-CSCF using DHCP and/or DNS queries. If a user is not prohibited to query for other nodes’ addresses as well, then an attacker can discover the addresses of any FQDN disclosed in any SIP message.
User Enumeration
Like in any telephony network, calling a user will tell you about his status, whether available, busy, unavailable or does not exist. Therefore, the Invite request is an accurate but noisy way to enumerate a user. However, the Options request has the same response codes as of the Invite request [1]. Therefore, an attacker would prefer to use the quiet Options request to know any user’s status without even alerting him. Options requests are not essential to IMS actions such as registration or call initiation. Therefore, it is recommended to not respond to Options requests from users.
Network Enumeration
If any SIP node receives an Options request with Max-Forward header field set to 0, the node may respond to the request regardless the destination URI [1]. Therefore, if CSCF nodes are not well hardened, an attacker can gather information about the nodes using Options requests with incrementing Max-Forward header. This is known as the SIP Traceroute attack [2].
Moreover, any unhardened CSCF node can add a server banner to its SIP responses. Such a header can disclose the manufacturer and the version of the CSCF nodes. OpenIMS core nodes attach the following server banner:
Integrity Breach Attacks
After the attacker gathers enough information about IMS and its users, it is time to put this information into action. An attacker can either focus his attacks on a specific victim, or direct his attacks towards the network itself. The following section discusses examples of attack scenarios, when an attacker manages to manipulate his own SIP messages to IMS:
User Impersonation
Registering as a user might sound the most effective way to impersonate this user. But in that case, the attacker must bypass the strict authentication process or provide secret data such as IMPI and the shared secret. Therefore, if an attacker “Evil” wants to call “Alice” as “Bob”, it would be easier to impersonate Bob in an Invite request directly. This attack can be divided into two steps:
1- Invite Request
At first, Evil has to craft an Invite message that would fool both IMS and the callee. Therefore, the following header fields should be taken into consideration:
- From: it contains the user’s IMPU. It specifies the sender’s identity and does not affect any routing decision.
- P-Asserted-Identity: it confirms the sender’s identity. P-CSCF usually removes any P-Asserted-Identity header in any SIP message received from any user and then it adds its own. But if the sender is a “privileged sender”, P-CSCF keeps the header field as it is [3].
- P-Preferred-Identity This header field is added by a SIP message sender to inform a SIP proxy (such as P-CSCF) about the IMPU that the sender wishes the proxy to assign as P-Asserted-Identity value [4]. This leads P-CSCF to check IMPUs in the request and causes the attack to fail.
After all, the attack success depends on the victim’s client and how it decides the caller’s identity. To demonstrate that, Evil will launch two attacks instead of one. In the first attack, he will impersonate Bob to call Alice as mentioned before, and in the second one he will do the opposite: call Bob as Alice. Alice is registered to OpenIMS core using OpenIC_lite client, while Bob is registered using a Monster IMS client. In both attacks, Evil crafts an Invite message that looks the same as a legitimate Invite message from Evil to Alice or Bob, except for the following:
- Request URI and To header field are set to the victim’s IMPU (whether Alice’s or Bob’s).
- From is set to Bob’s IMPU.
- P-Asserted-Identity is added with a value of Alice’s IMPU.
- P-Preferred-Identity header field is removed.
The above request sets two caller’s identities in two different fields. Request URI is set to Alice’s and Bob’s in the first and the second attack respectively. As an example, the Invite request sent to Alice would look as the following:
2- IP Spoofing
When a user registers to IMS, P-CSCF saves his IP address and port. Then when it receives any further SIP request from this user, it validates the sender’s IP address and port with the data saved during registration [5]. So even if neither TLS nor IPsec is enabled, P-CSCF can still perform some data origin authentication. Therefore, in the second step, Evil has to spoof the caller’s address. Luckily, he can know any user’s IP address as discussed above. Since I use SIP over UDP, it was possible for me to spoof the victim’s IP address and port.
Result
Invite requests from both attacks are delivered successfully to the victims. Alice’s OpenIC_lite client decides the caller ID based on From header field and displays the caller ID as Bob. Bob’s Monster IMS client gets the caller ID from P-Asserted-Identity. The same attack also works with messaging using SIP Message request.
Header Manipulation
This is an example of an attacker targeting the network itself. An attacker can modify some of his headers in order to provide IMS with false information. The impact of such attacks depend on how IMS handles these header fields. For example, it can totally neglect them or make important charging decisions based on them.
Location Manipulation
Many mobile operators offer Location Based Services (LBS), which provide users with special services or charging offers according to their location. P-Access-Network-Info is the header field that defines the user location in the access network as shown in the following example:
If an attacker can set this header field in his SIP messages to any Cell-ID he likes, he can make use of location specific offers that he is not actually eligible to. However, if this header field contains the attribute network-provided or np, P-CSCF will fetch the attacker’s location from the access network and update the header field.
Roaming
Outbound roamers usually pay higher service fees and have access to less services than local network users. Therefore, any attacker would fancy a way to seem to his home network as a local user.
P-Visited-Network-ID is a header field of a Register request that holds the access network that serves the user. Accordingly, it tells if the user is roaming or not. So what would happen if an attacker registers from another network and injects a P-Visited-Network-ID header field with the value of the local network in his Register request?
Normally, OpenIMS’s P-CSCF adds to any Register request a P-Visited-Network-ID header field with a value of the network domain “open-ims.test”. Assuming that a roaming attacker’s network domain is for example open-ims2.test, he sets P-Visited-Network-ID to this value in his Register request. OpenIMS core’s P-CSCF neither removes the field, nor adds a new one. Instead, it just appends the network domain to the attacker’s field as shown in the following figure. Eventually, I-CSCF considers the whole value of P-Visited-Network-ID as the attacker’s network ID . Although the attack failed, it proves that CSCF’s handling of P-Visited-Network-ID field can be tricky and unexpected.
Extra Header Attachment
SIP is a flexible protocol that allows users to add customized headers to their requests. By default, IMS does not discard additional header fields in SIP messages. That means that a user can transfer messages or data to another user over free of charge SIP requests.
Injection Attacks
An attacker can launch other injection attacks on IMS. For example, the header field Authorization of a SIP Register request contains IMPI and password/AKA response of the registering user. This data is usually checked by HSS, which is, at the end of the day, a database. If HSS is not well secured, it could be vulnerable to SQL injection attacks.
Moreover, SIP requests such as Subscribe and Publish contain XML payloads. These XML payloads would tempt any attacker to try some XXE attacks that could impact any IMS node that parses these requests, especially the presence servers.
Integrity and Confidentiality Breach Attacks
The more information an attacker gets about the victim’s SIP traffic, the more powerful his attacks could get. For example, if an attacker manages to:
- Capture the current SIP dialogue and transaction identifiers (From, To, Via, CSeq and Call-ID header fields) from the victim’s SIP messages.
- In addition to his IP spoofing capability that he already demonstrated earlier
and follows the dialogues and transactions rules, then he can inject any SIP message in the middle of any dialogue. He can also impersonate P-CSCF that serves the user and send the victim rogue SIP messages as if they are coming from IMS. The following are some examples of the possible attacks:
Redirect a victim’s establishing call to any destination
If the victim is establishing a call and the other party’s phone/SIP client is ringing, he will receive a 180 Ringing response. At that time, the attacker can impersonate P-CSCF and sends a 302 Move Temporarily response to the victim. The victim’s call will be redirected to the IMPU in the Contact header of the rogue response [5].
The rogue 302 Move Temporary response would look the same as the 180 Ringing response, except for the header response (302 Redirect) and the attacker’s IMPU in the Contact header. All values in the green boxes should be the same as in 180 Ringing message because both messages should belong to the same SIP Transaction.
Terminate an established call
The attacker can impersonate the victim and send a SIP Bye request to terminate the call. A Bye request starts a new transaction within the same dialogue, therefore dialogue fields remain the same as in the initiating Invite request and the CSeq field is incremented.
Cancel an establishing call
If the victim is the caller, an attacker can impersonate P-CSCF and send a rogue 486 Busy SIP response to the victim. This keeps the dialogue and transaction identifiers of the previous provisional 180 Ringing response.
Unregister the victim
In order to simulate a network initiated de-registration, an attacker sends rogue Notify requests as P-CSCF to the user. state and event attributes of this Notify request are set to terminated and rejected respectively [3].
Conclusion
IMS is and will be the target of many attacks, due to its main role in any IP telecommunications network. In order to achieve high security levels, IMS should still be secured even if the transport security is breached. Therefore, the following measures are suggested:
- Information disclosure should be minimized in SIP requests.
- If IMS users discover the IP address of P-CSCF using DHCP/DNS queries, they should not be allowed to discover other nodes.
- SIP Options request should not be accepted by IMS if it is issued by a user, unless it is necessary.
- All CSCF nodes should be well hardened, in order not disclose information such as Server header field.
- SIP header fields that should not be provided by users (such as P-Visited-Network-ID) should be removed by P-CSCF.
- SIP header fields provided by users (such as P-Access-Network-ID) should not be fully trusted, especially if IMS can obtain the same information from another trusted source (such as IP access network).
- Since it does not make sense that a user (privileged or not) confirms his own identity, P-Asserted-Identity header field should be removed by P-CSCF if received from a user.
- Extra headers should be filtered by P-CSCF, unless they are necessary.
- HSS and other databases should be protected against SQL injection attacks, especially in case of user input.
- Nodes that process XML payloads, such as P-CSCF, S-CSCF and presence servers should be well hardened against XXE attacks.
- Last but not least, the use of IPSec or TLS to secure communication between IMS and its users is a must. In addition to IP spoofing prevention techniques.
Finally, I would like to thank Hendrik Schmidt for his support and supervision of my thesis.