Security is always a major topic in communications. It is important for customers, regulatory bodies, vendors and operators. 3GPP is standardizing more and more measures to increase security of theGSM in every new GSM release. Some examples:
- Release 99 – TS 33.102 3G security; Security architecture, TS 35.202 Specification of the 3GPP confidentiality and integrity algorithms; Document 2: Kasumi specification
- Release 4 – TS 33.200 3G Security; Network Domain Security (NDS); Mobile Application Part (MAP) application layer security, TS 35.206 3G Security; Specification of the MILENAGE algorithm set: An example algorithm set for the 3GPP authentication and key generation functions f1, f1*, f2, f3,f4, f5 and f5*; Document 2: Algorithm specification
- Release 5 – TS 33.203 3G security; Access security for IP-based services, TS 33.210 3G security; Network Domain Security (NDS); IP network layer security
- Release 6 – TS 33.310 Network Domain Security (NDS); Authentication Framework (AF), TS 33.234 3G security; Wireless Local Area Network (WLAN) interworking security
- Release 7 – TS 33.204 3G Security; Network Domain Security (NDS); Transaction Capabilities Application Part (TCAP) user security, TS 29.204 Signalling System No. 7 (SS7) security gateway; Architecture, functional description and protocol details
- Release 8 – TS 33.401 3GPP System Architecture Evolution (SAE); Security architecture
Introduction to SS7 and Security
Absence of security in SS7 is identified as a weakness, but not seen as a problem due to the following:
- Existing trust relationships amongst Telcos
- Closed networks
- Only experts are working and monitoring networks
Today networks are changing and protection for SS7 is becoming a necessity due to:
- The opening of the network for various (smaller) interconnect parties and service providers
- IP access to SS7 networks
- Less experts available to monitor networks
- More SMS service providers connecting to network, increasing the possibilty of sending wrong messages without any purpose or trying to abuse the network.
- TCAP and protocols based on TCAP are more vulnerable to fraud.
- Don’t need end to end physical connections
- Used in inter-PLMN communications Preventing SS7-Based Attacks using TCAP Security
SS7 Based Security Threats
Spoofing
Definition:
- Illegal use of HPLMN SMSC by a 3rd party.
- An MO SMS with a manipulated A-MSISDN (real or wrong) is coming into the HPLMN network from a foreign VLR (real or wrong SCCP Address).
- If the billing is made from the SMS-C data, the real subscriber will be invoiced.
Precaution:
- HPLMN can check the originator MSISDN (to verify if it’s a real or not).
- HPLMN can check if the VLR location stored in the HLR is in the same range with the requesting SCCP address.
Faking (MT Spoofing)
Definition:
- A fake SMS is originated from the international SS7 network.
- SCCP/MAP addresses are manipulated.
- SCCP/MAP addresses are wrong or copied from a real existing SMSC.
- SMS can be sent to a real subscriber (recovering IMSI) or to a wrong IMSI (only to generate traffic).
Precaution:
- Controlling access to the SS7 network
- Supervision of foreign SMSC traffic
Spamming
Definition:
- Subscriber receives unwanted SMS.
- Sender can be valid.
- SMS can be billed correctly.
- SMS is submitted by a mobile phone or by a third party connected to the SMSC.
- Only real detection method is customer complaints.
Precaution:
- Repetitive content check
- SMS Firewall / SMS Router
Flooding
Definition:
- Massive load of messages to one or more destinations.
- The only parameter is the number of messages sent.
- May cause denial of service
Precaution:
- Supervision of traffic
Mobile Viruses
Definition:
- Unwanted signaling
- Stolen private information
Example:
- Hatihati
Precaution:
- SMS Defence
TCAP Handshaking
Overview
- Defined in 3GPP TS 33.204 3G Security; Network Domain Security (NDS)
- Transaction Capabilities Application Part (TCAP) user security (Release 7) as an Annex (a short/medium term solution).
- A limited level of authenticity is provided.
- Prevents spamming and spoofing for MO and MT SMS transfer cases.
- MSC/SGSN and SMSC behaviors should be modified.
- Based on using special transaction sequences.
TCAP Handshaking MT SMS
- Receiving node should verify whether received SMSC address (contained in SM-RP-OA field in the 3rd message) is in the same operators range with the SCCP Calling Party address of the 1st message.
- In order to counteract transaction id prediction either receiving node should ensure that the destination transaction ID is not predictable or receiving node should wait for n seconds before processing the 3rd message to ensure that a possible TC_ABORT can be processed before the 3rd message.
- Receiving node should maintain a trusted operators table. If an MT SMS comes from one of those operators without TCAP Handshaking, it should be rejected.
TCAP Handshaking MO SMS
- Receiving node should verify that the VLR address corresponding the MSISDN (contained in SM-RP_OA field of the 3rd message) is in the same operators range with the SCCP Calling Party address of the 1st message. This can be asked from HLR.
- In order to counteract transaction id prediction either receiving node should ensure destination transaction ID is not predictable or receiving node should wait n seconds to ensure there is no aborts following.
- Receiving node should maintain a trusted operators table. If an MO SMS comes from one of those operators without TCAP Handshaking, it should be rejected.
TCAPsec
Overview
- Defined in 3GPP TS 33.204 3G Security; Network Domain Security (NDS); Transaction Capabilities Application Part (TCAP) user security (Release 7).
- To be used for all TCAP transactions.
- Authentication and optional encryption between operators
- Using SS7_SEG (Security Gateway) is necessary.
- Does not validate TCAP user payload content. Additional measures may be needed.
- Benefit of applying TCAPsec will gradually increase as more interconnected operators apply TCAPsec
Network Architecture
- End to end architecture
- Hub and spoke architecture
SS7 Security Gateway
An SS7 Security Gateway (SS7-SEG) is a network node defined in 3GPP TS 29.204 Signalling System No. 7 (SS7) security gateway; Architecture, functional description and protocol details document. it is responsible for:
- protection of leaving (i.e. outbound) messages,
- protection checking of entering (i.e. inbound) messages.
An SEG contains two databases:
- SPD-SEG (policy information)
- SAD-SEG (Security Association information)
An outbound message is protected according to the destination address , the policy information and the existing SA corresponding to that address. An inbound message is unprotected or blocked according to the originating address, the policy information and the existing SA corresponding to that address.
Security Association
Before protection can be applied, at least one Security Association (SA) needs to be established between the respective SS7-SEG. A Security Association consists of:#
- DNI – Destination Network Id (CC+NDC)
- ONI – Origin Network Id (CC+NDC)
- SPI – Security Parameters Index (32 bit value)
A Security Parameters Index (SPI) identifies:
- SEA – Security Gateway Encryption Algorithm Index (f6)
- SEK – Security Gateway Encryption Key
- SIA – Security Gateway Integrity Algorithm Index (f7)
- SIK – Security Gateway Integrity Key
- SA Hard Expiry Time
- SA Soft Expiry Time
Structure of a Protected TCAP Message
A protected TCAP messages is sent as a Unidirectional TCAP message without a dialogue portion, with one invoke component. Operation Code=90 (SecureTransport). ParameterPart (SecureTransportArg) filled with original SCCP Info, original TCAP Info and protected Payload.
Protected payload has 2 sections:
- Security Header Payload
- Each section consists of different parameters according to the protection mode.
Protection Mode 1: Integrity, Authenticity
- Security Header SPI TVP
- Payload Clear Text f7( SH + Clear Text )
Protection Mode 2: Confidentiality, Integrity, and Authenticity
- Security Header SPI TVP SS7-SEG ID PROP
- Payload f6( Clear Text ) f7( SH + f6( Clear Text ) )
Enabling Security On Real Life Applications
SS7-based security attacks were happening before TCAP security measures were decided. Those attacks were tried to be prevented by special (vendor specific) security additions to network elements and applications, SCCP/MAP policy changes specific to the threat and log analysis. Let’s explore some real-life security scenarios.
Sending SM to invalid network nodes
- MO SMS message (MOForwardSM) is sent directly to SM Service Center. Theoretically this message can be sent to any known GT in the network.
- Customers who want to send free SMS usually were trying all consecutive Service Center addresses in the same range with the actual SC address.
- When MOForwardSM is received by a test SMSC, SMS message may be delivered for free.
- When MOForwardSM is received by a different node (e.g. IN), unplanned traffic is generated and the node may crash if designed poorly.
- SMSC address check on the MSCs was initiated. (An MSC feature)
- GT translation in the GMSC were modified so that SMSC nodes cannot be reached by their actual GTs but by virtual numbers.
Basic spam filtering in the SMSC
- Advertorial and spam SMS messages were being sent from the same originator to many customers causing dissatisfaction.
- All MSISDNs in a range were being tried sequentially. This increases undelivered SMS counts.
- SMS messages submitted from the same originator are counted and if the count is bigger than a predefined limit for a predefined amount of time, they are rejected.
Hatihati prevention
- Hatihati virus was sending millions of messages to the same destinations each day with unaware customers being charged.
- SS7 links were being utilized unnecessarily.
- SMS messages destined to the specific numbers were barred to avoid charging.
- SMSCs were modified to send successful delivery reports to the infected phones so that they stop sending more SMS.
MO Spoofing Solutions
- An international node was submitting SMS messages, at first with a valid A-Party MSISDN but a wrong MSC address, then with both a valid A-Party and a valid MSC address (A-Party location is retrieved from the HLR with SRIForSM).
- A modification was made on the SMSCs so that A-Party location is retrieved from the RWM system databases or from the HLR using SRIForSM if the subscriber is roaming and checked with the originating SCCP address of the incoming MOFwdSM message.
- GT translations are modified so that MOFwdSM messages from the international links can be identified. If an MOFwm SM message with an Aparty number located in the HPLMN comes, it is rejected.
SMS Firewall / SMS Router
Our SMS firewall and router solutions contain the following features to help secure your network:
- SMS anti-faking, anti-spoofing, anti-spamming, anti-flooding
- All MT SMS traffic is routed to SMS Firewall by means of HLR, GMSC or STP
- SRIForSM / FSM correlation
- IMSI scrambling
- Validation of SCCP and MAP layer addresses
- Spam filtering (SMS content and volume analysis)
- Filtering rules based on detailed statistics and message layer data
Conclusion
TCAP Handshaking is a short/medium term solution, effective only for some SMS related security threats but easy to apply. TCAPsec is a medium/long term solution, more difficult to apply but useful for different TCAP based attacks. These two TCAP security mechanisms are defined in 3GPP specifications and will show their value as more operators will begin to use them. Therefore operators and vendors should take action to implement these measures as soon as they can. These two are not the only precautions. For specific scenarios, other specific and effective solutions can be found.
For further information on our SMS Firewall and SMS Router solutions, check our “Splutions: Network Protection” or contact us directly.