root canal - ernw insight...•ss7 –vulnerable by design •acknowledged signalling...
Post on 19-Apr-2020
5 Views
Preview:
TRANSCRIPT
Outstanding Communications Solutions
Root CanalA new class of SS7 vulnerabilities
• 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
• 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
• 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
SS7 – Vulnerable by design
5
Signaling Vulnerabilities
• 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
• 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
• 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
• 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
• 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
operations
• 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
• In addition to filtering we can also configure
our 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
• So what is the problem?
Mitigation - The signaling band-aid
12
A new class of SS7 vulnerabilities
13
Malformed Packets
Well formed Packet
14
Malformed Packet
15
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
▪ Denial of ServiceAim 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 ExecutionAims 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
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
19
• Malformed data can also point to sections
of 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
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
A new class of SS7 vulnerabilities
21
Prerequisites
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
Prerequisites
23
• A vulnerable ASN.1 parser, does it exist?
Prerequisites
24
• Get a handset into the target network
should be doable
• 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
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
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
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
A new class of SS7 vulnerabilities
29
Attacking and Tunneling
Attacking and Tunneling
30
• Crafting the attack• We are still subject to some limits with regards to size
of 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
Attacking and Tunneling
31
• MAP reset – Fits the description
• Spoofable and contains a variable size hlr-List of
IMSI:s as optional parameter…
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
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 on the file system.
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
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
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
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
•
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?
Multi stage exploit (stealth ver)
39
• extensionContainers
• privateExtensionList
• Encoding can be vendor specific
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
Multi stage exploit (stealth ver)
41
• An attacker could also create virtual subscribers on the hijacked MSC to obfuscate 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
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
A new class of SS7 vulnerabilities
43
Proposed Mitigation and Limits
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
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
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.
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.
• 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
Proof of Concept – Demo attack
49
Vulnerable MSC attack simulation
Real World Bonus Content
50
Please memset
• 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
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
• 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
Questions
54
top related