Root Canal A new class of SS7 vulnerabilities Agenda SS7 - - PowerPoint PPT Presentation

root canal
SMART_READER_LITE
LIVE PREVIEW

Root Canal A new class of SS7 vulnerabilities Agenda SS7 - - PowerPoint PPT Presentation

Outstanding Communications Solutions Root Canal A new class of SS7 vulnerabilities Agenda SS7 Vulnerable by design Acknowledged signalling vulnerabilities The root problem Mitigation The signaling band-aid A new class


slide-1
SLIDE 1

Outstanding Communications Solutions

Root Canal

A new class of SS7 vulnerabilities

slide-2
SLIDE 2
  • SS7 – Vulnerable by design
  • Acknowledged signalling vulnerabilities
  • The root problem
  • Mitigation – The signaling band-aid
  • A new class of SS7 vulnerabilities
  • Malformed Packets
  • Prerequisites
  • Attacking and Tunneling
  • Multi stage exploit
  • Proposed mitigation and limits

Agenda

2

slide-3
SLIDE 3
  • Presenter – Fredrik Söderlund
  • Symsoft – Software and Systems Security Advisor
  • Background in
  • Reverse engineering
  • Debug tools development
  • Telecom security
  • Security researcher and contributor to the GSMA CVD program
  • Worked on multiple SS7 firewall designs both for SMS and full

spectrum SS7

Introduction

3

slide-4
SLIDE 4
  • Symsoft – CLX Communications
  • Communications Solutions for Operators
  • 75+ Mobile Operator Customers
  • 1000+ Enterprise Customers
  • IoT and MVNO Platforms
  • Fraud & Security
  • Real-Time BSS
  • Value Added Services

Introduction

4

slide-5
SLIDE 5

SS7 – Vulnerable by design

5

Signaling Vulnerabilities

slide-6
SLIDE 6
  • Signaling based attacks
  • Location tracking – ATI, PSI
  • Spying on subscribers or VIPs
  • Profile manipulation – ISD, registerSS
  • Fraud, call redirection or denial of service
  • Subscriber hijacking, DoS – UL, DSD
  • Eavesdropping, fraud or denial of service

Acknowledged vulnerabilities

6

slide-7
SLIDE 7
  • Yes they are dangerous, costly and indicates

the network is vulnerable

  • But they are also perfectly normal and the

expected functionality of an SS7 network

  • The network is doing exactly what is intended
  • Attacks or misuse? These attacks have been

known for a long time and were easy to predict.

Acknowledged vulnerabilities

7

slide-8
SLIDE 8
  • The root problem is always the same…
  • Subscriber tracking
  • Lack of authentication (who is reading?)
  • Profile manipulation
  • Lack of authentication (who is writing?)
  • Location update
  • Lack of authentication (who is moving?)

Acknowledged vulnerabilities

8

slide-9
SLIDE 9
  • Everyone trusts everyone
  • If you’re on the network you’re a friend
  • Anyone can impersonate anyone
  • If you’re on the network we assume you are who you

say you are

The root problem

9

slide-10
SLIDE 10
  • The obvious answer to signaling problems:
  • Introduce authentication!
  • Let’s not do that…
  • Instead we will:
  • Cat 1 - Filter network edge for unexpected or unwanted
  • perations
  • Cat 2 - Verify fields across stack layers without 1:1 match of

components (CC+NNGT : MCC+MNC)

  • Cat 3 - Verify subscriber location by last known location or

plausibility of movement

Mitigation - The signaling band-aid

10

slide-11
SLIDE 11
  • In addition to filtering we can also configure
  • ur networks better
  • Whitelist roaming partners, known nodes/peers
  • Introduce home routing
  • Whitelist exceptions based on origin and opcode
  • The result is a reasonably secure network
  • The Signaling band-aid works pretty good

Mitigation - The signaling band-aid

11

slide-12
SLIDE 12
  • So what is the problem?

Mitigation - The signaling band-aid

12

slide-13
SLIDE 13

A new class of SS7 vulnerabilities

13

Malformed Packets

slide-14
SLIDE 14

Well formed Packet

14

slide-15
SLIDE 15

Malformed Packet

15

slide-16
SLIDE 16

Non signaling based attacks in malformed packets

  • Routable attacks using malformed ASN.1 or

SCCP layer data

  • Crafted payloads targeting known firmware

vulnerable to encoding based attacks

  • Sophisticated attacks most likely using hijacked

infrastructure

  • Potential attackers include APTs such as nation

states or criminal networks

Malformed Packets

16

slide-17
SLIDE 17

▪ Denial of Service

Aim is to crash the targeted network element either to influence network performance or steer traffic to alternative links where attacker may have better visibility

  • Methods include for example: buffer overflows, null pointers, stack depletion,

memory corruption, infinite nesting

▪ Remote Code Execution

Aims to take control of the targeted network element in order to exfiltrate data, scan network, generate traffic, commit fraud or eavesdrop on network traffic or subscribers

  • Methods include the same as Denial of Service attacks but with

the goal of executing code via controllable crash.

  • Once code execution has been achieved the attacker is likely to

proceed with privilege escalation and full compromise of the network element

Malformed Packets

17

slide-18
SLIDE 18

18

  • Compare a normal packet to a letter
  • A letter flows by country, city, street and finally

reaches a person

  • In a malformed packet the attacker attempts

to interrupt this flow or even trap it in an infinite loop & ultimately crash the application

Malformed Packets

slide-19
SLIDE 19

19

  • Malformed data can also point to sections
  • f code or data outside the actual packet
  • Such pointers can redirect the flow and

introduce a predictable and reproduceable crash of the application

Malformed Packets

slide-20
SLIDE 20

20

  • Most dangerous is Remote Code Execution
  • The predictable crash is exploited to run code
  • The code installs a Command & Control server
  • Attacker can scan and control the network
  • Worst case - The attack is totally transparent

Malformed Packets

slide-21
SLIDE 21

A new class of SS7 vulnerabilities

21

Prerequisites

slide-22
SLIDE 22

Prerequisites

22

  • What we need to launch this attack
  • A vulnerable ASN.1 parser in the target node
  • Some type of UE registered in the target

network

  • To act as a known recipient in the target network
  • The ability to send a routable SCCP packet

carrying a 500 byte payload

slide-23
SLIDE 23

Prerequisites

23

  • A vulnerable ASN.1 parser, does it exist?
slide-24
SLIDE 24

Prerequisites

24

  • Get a handset into the target network

should be doable

slide-25
SLIDE 25
  • Sending a 500 byte payload over SS7
  • Over M3UA it seems that most nodes accept

payloads above 500 byte size without question

  • Over MTP3 there is a physical limit of 272 bytes
  • This limitation may carry over to M2PA
  • This could be a bottleneck...

Prerequisites

25

slide-26
SLIDE 26

Prerequisites

26

  • Full length or concatenated SMS are larger

than 272 bytes

  • They usually consist of an empty TCAP Begin

followed by the payload in a TCAP Continue

  • Payloads larger than 272 bytes can be sent

divided into multiple parts

  • This means that also SS7 has ways of passing

larger packets to the application layer

slide-27
SLIDE 27

Prerequisites

27

  • SCCP UDT (Unitdata) has a size limitation (still

however well above what an attacker needs)

  • If a packet however exceeds the size limit of 272

bytes it may be transported over XUDT to accommodate the legacy size limit

  • SCCP XUDT (Extended Unitdata) offers

fragmentation and can therefore encapsulate larger packets also over MTP3 and M2PA

  • Fragmented packets are reassembled on arrival and

passed in original form to the application

slide-28
SLIDE 28

Prerequisites

28

  • We have a method of delivery
  • Regular SCCP UDT over M3UA appears to be

widely accepted with larger packets sizes

  • XUDT over MTP3/M2PA offers a fragmented

alternative to overcome physical barrier of legacy technology

slide-29
SLIDE 29

A new class of SS7 vulnerabilities

29

Attacking and Tunneling

slide-30
SLIDE 30

Attacking and Tunneling

30

  • Crafting the attack
  • We are still subject to some limits with regards to size
  • f the attacks. No hard cap, but an attacker needs to

limit size of initial infection for better chance of success

  • This means crafting a multi stage attack
  • Characteristics of the ideal MAP operation for initial

infection:

  • Spoofable (we don’t need the returnResult)
  • Variable size
  • Optional parameters
slide-31
SLIDE 31

Attacking and Tunneling

31

  • MAP reset – Fits the description
  • Spoofable and contains a variable size hlr-List of

IMSI:s as optional parameter…

slide-32
SLIDE 32

Multi stage exploit

32

  • Primary infection: 500 bytes carried in the optional list

parameter of MAP reset

  • Trigger vulnerability, start execution
  • Allocate space for hook procedures
  • Adjust memory protection of 1 page of code
  • Patch recv function and install hook 1
  • Hook 1 filters all incoming SMS traffic towards the attacker

UE registered in the target network

  • Chunks of executable code are delivered and assembled into

second stage of infection

  • When all chunks have been delivered, hook 1 is replaced by

hook 2

slide-33
SLIDE 33

Multi stage exploit

33

  • Secondary infection: 2000 bytes of PoC code
  • Does not need to connect back to original attacker GT
  • The Primary infection may be spoofed
  • Offers the ability to execute commands on target
  • Has the ability to report back to attacker
  • Data is tunneled to target using MT SMS
  • Data is tunneled from target using MO SMS
  • Infection is transparent to target node and leaves no stains
  • n the file system.
slide-34
SLIDE 34

Call Flow

34

  • Multiple stage attack using MAP reset and MT SMS
  • Delivers exploit, installs Command & Control (C2)
  • Attacker can proceed to control network remotely
  • Scan, cross infect, commit fraud, deny service
slide-35
SLIDE 35

Call Flow

35

  • First stage attacks encoding at ASN.1 or SCCP
  • Crashes the MSC in a predictable way
  • Installs hook procedure to filter incoming MT SMS
  • Returns control to application and starts filtering
slide-36
SLIDE 36

Call Flow

36

  • Second Stage is built using MT SMS
  • MT SMS contain code for C2 in TPDU User-Data
  • Hook detects incoming MT SMS by known UE IMSI
  • Reassembles MT SMS chunks to build C2 server
slide-37
SLIDE 37

Call Flow

37

  • C2 server acts as attacker inside network
  • Attacker send commands using MT SMS
  • C2 executes attacker commands
  • C2 functionality can be extended if required
slide-38
SLIDE 38

Multi stage exploit

38

  • Alternative methods
  • Using SMS leaves CDR records…
  • Is it possible to build a stealth version to avoid or

limit CDR records?

  • And what about evading SS7 Firewalls?
slide-39
SLIDE 39

Multi stage exploit (stealth ver)

39

  • extensionContainers
  • privateExtensionList
  • Encoding can be vendor specific
slide-40
SLIDE 40

Multi stage exploit (stealth ver)

40

  • A sophisticated attacker could use

extensionContainers both for primary attack and tunneling

  • Could use fake UL from hook to trigger stream of

ISD from attacker

  • ISD can carry extensionContainers
  • This could be very difficult to detect
  • Vendor specific encoding must either be ignored by

SS7 Firewall or blocked by default. So extensions may actually pass through firewalls unfiltered

slide-41
SLIDE 41

Multi stage exploit (stealth ver)

41

  • An attacker could also create virtual

subscribers on the hijacked MSC to

  • bfuscate and hide tunneled data further
  • Generate UL to simulate an inbound roamer

registering with the network

  • This could also leave limited or no information

in CDRs especially if virtual subscribers are created at random by the attacker

slide-42
SLIDE 42

Multi stage exploit (SMS vs PE)

42

  • MT SMS
  • +Easy tunneling, simple encoding and exchange
  • +Control network node without SS7 connectivity (after initial hook

all other things can be done from a phone)

  • All communications logged in CDRs
  • Unless attacker wipes them, if possible
  • Private Extensions
  • +Possibly better stealth capability
  • +May pass through SS7 Firewalls as it relies on propriety data

structures

  • More complex encoding and exchange
  • Less bandwidth than SMS tunneling
slide-43
SLIDE 43

A new class of SS7 vulnerabilities

43

Proposed Mitigation and Limits

slide-44
SLIDE 44

Denial of Service – Protection Mechanisms

  • Validation of encoding and packet structure
  • ASN.1 Validation for TCAP, MAP, CAP layers

Validation of packet size, pointers, nesting levels, adherence to specification

  • Parameter validation for SCCP

Parameter size/position Flags, bitmasks and format of data, such as invalid structure of parameters or pointers reaching outside the SCCP packet

44

Proposed mitigation and limits

slide-45
SLIDE 45

Remote Code Execution - Protection Mechanisms

  • Payload size monitoring
  • For an attacker to successfully perform an encoding based attack

the initial attack must contain both an exploit part and actual code. Some specific SS7 Operations, such as MAP reset, can be monitored specifically for abnormal size

  • Fragmentation checks – XUDT/XUDTS
  • Generally fragmented traffic is very rare and occur if traffic has

passed through E1/TDM type networks or potentially M2PA links

  • Monitor fragmented traffic, if there are spikes it could be an

indication that attack testing is being conducted towards receiving network

45

Proposed mitigation and limits

slide-46
SLIDE 46

Proposed mitigation and limits

46

  • There are limits to what can be protected
  • The initial attack could be delivered over any

interface that accept packets above 500 bytes in size

  • That could be almost any interface…
  • Initial attack could arrive over OAM, SIP, HTTP,

Charging or any proprietary interface on the target SS7 node. As long as the vulnerability is known it can switch to SS7 tunneling after hook 1 is installed.

slide-47
SLIDE 47

Proposed mitigation and limits

47

  • Reasonable protection can be achieved
  • Main responsibility sits with vendors
  • Encourage development of secure parsers
  • Ask the right questions
  • Don’t assume another node will deal with the
  • problem. The edge/firewall/security GW needs

to handle it.

slide-48
SLIDE 48
  • Enforcing ASLR – While not a perfectly reliable protection, Address

Space Layout Randomization does make certain attacks more difficult

  • Process privilege levels – Ensure only required privileges are granted
  • Vendors should be required to perform fuzz tests of critical code
  • Fuzz any code that manage data generated either directly or indirectly from

processing signaling traffic

  • Fuzz network stack and parsers at any routable layer (SCCP and above).
  • Monitoring of outbound traffic can help detect if a network element has

been compromised

  • Consider blocking of private extension containers since they can contain

vendor specific proprietary data structures that an SS7 Firewall may be unable to inspect

General Recommendations

48

slide-49
SLIDE 49

Proof of Concept – Demo attack

49

Vulnerable MSC attack simulation

slide-50
SLIDE 50

Real World Bonus Content

50

Please memset

slide-51
SLIDE 51
  • The following capture is from a production environment
  • Network specific details have been blacked out
  • Illustrates how poorly written encoders can leak information

SS7 vs ASLR

51

slide-52
SLIDE 52

THREE SLIDES FROM THE ORIGINAL PRESENTATION HAVE INTENTIONALLY BEEN REMOVED. THEY ILLUSTRATE BROKEN ENCODER LEAKING STACK INFORMATION VIA BADLY IMPLEMENTED PADDING OF SCCP LAYER

SS7 vs ASLR

52

slide-53
SLIDE 53
  • Poorly written encoder
  • Leaves scraps from local variables in the padding
  • Can give hints about where modules are loaded
  • Can expose base address of stack
  • Attacker can simply “ask” for ASLR details
  • Send an invoke to get returnResult or trigger ISD
  • Answer contains fragments of local variables
  • Suddenly ASLR isn’t R at all

SS7 vs ASLR

53

slide-54
SLIDE 54

Questions

54