Enabling Security On Real Life Applications - Cellusys

Back to TCAP Handshaking and SS7 Security

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

Back to TCAP Handshaking and SS7 Security