-Phreaking is a term for the action of making a telephone system do something that it normally should not allow.
-Telecommunications security problems started in the 1960’s when the hackers of the time started to discover ways to abuse the telephone company.
-Discovery and exploration of features of telecommunications systems.
-Controlling Network Elements (NE) in a way that was not planned by its designers.
-Abusing weaknesses of protocols, systems and applications in telephone networks.
Fraud Implanted by
-Blue Box
-Internal Fraud
Reliability
-US: 911, Europe: 112
-How much lost revenue is one minute of downtime?
Today's View
-SIP account hacking, remind the "Calling Cards" fraud?
-VoIP GW hacking, remind the "PBX hacking"?
-Signaling hacking directly on SS7 – SIGTRAN level
SS7 Attacks Scenarios
-Theft of service, interception of calling cards numbers, privacy concerns
-Introduce harmful packets into the national and global SS7 networks
-Get control of call processing, get control of accounting reports
-Obtain credit card numbers, non-listed numbers, etc.
-Messages can be read, altered, injected or deleted
-Denial of service, security triplet replay to compromise authentication
-Annoyance calls, free calls, disruption of emergency services
-Capture of gateways, rerouting of call traffic
-Disruption of service to large parts of the network
-Call processing exposed through Signaling Control Protocol
-Announcement service exposed to IP through RTP
-Disclosure of bearer channel traffic
Telecom Backbone
Discovering The Backbone
Deregulation
-Europe / US: CLEC vs ILEC
New services and new business partners
-Premium numbers, SMS providers, etc.
Push toward an “All IP” infrastructure
-Management network
-Cost
-SIGTRAN (SS7 over IP)
SS7 & SIGTRAN
-Core
-Formerly, the walled garden
VoIP
-Edge
-Hard to make it reliable (QoS, SBCs)
SS7 and IP
-There is also exponential growth in the use of interconnection between the telecommunication networks and the Internet, for example with VoIP protocols (e.g. SIP, SCTP, M3UA, etc.)
-The IT community now has many protocol converters for conversion of SS7 data to IP, primarily for the transportation of voice and data over the IP networks. In addition new services such as those based on IN will lead to a growing use of the SS7 network for general data transfers.
-There have been a number of incidents from accidental action on SS7, which have damaged a network. To date, there have been very few deliberate actions. Far from VoIP here.
Attacking SIGTRAN with SCTPscan (http://sctp.tstf.net/)
Where implementation diverge from RFCs
-RFC says "hosts should never answer to INIT packets on non-existings ports".
-Syn scanning is slow when no RST
Below the IDS
-How many firewall logs dropped SCTP packets?
-How many IDS(s) watch for SCTP socket evil content?
-Example: Dshield.org - Real life distributed IDS, Hundreds of thousands of IP scanned, nor detected neither reported as scanner.
INIT vs SHUTDOWN_ACK Packet Scanning
From RFC 2960
-8.4 Handle "Out of the blue" Packets
-An SCTP packet is called an "out of the blue" (OOTB) packet if it is correctly formed, i.e., passed the receiver's Adler-32 / CRC-32 check (see Section 6.8), but the receiver is not able to identify the association to which this packet belongs.
-The receiver of an OOTB packet MUST do the following:
"If the packet contains a SHUTDOWN ACK chunk, the receiver should respond to the sender of the OOTB packet with a SHUTDOWN COMPLETE."
-New way to elicit answers even if not answering ABORTs to INITs targeted at not-opened port.
SCTP ports (-sS) Stealth Scanning
root@bt:~/sctp# ./sctpscan-v11 --scan --autoportscan -r
203.151.1
Netscanning with Crc32 checksumed packet
203.151.1.4 SCTP present on port 2905
203.151.1.4 SCTP present on port 7102
203.151.1.4 SCTP present on port 7103
203.151.1.4 SCTP present on port 7105
203.151.1.4 SCTP present on port 7551
203.151.1.4 SCTP present on port 7701
203.151.1.4 SCTP present on port 7800
203.151.1.4 SCTP present on port 8001
203.151.1.4 SCTP present on port 2905
root@bt:~/sctp#
SCTP Stack Fingerprinting
-SCTP stack reliability
-Robustness testing (stress testing)
-QA of a few stacks
-Fuzzing built-in SCTPscan
-Discrepancies in SCTP answer packets
-Different stack behaviours
-Much more states than TCP=opportunities
-Cookie randomness
Credits: Philippe Langlois, P1 Security (p1security.com)
