SCTPscan - Finding entry

points to SS7 Networks &

Telecommunication
Backbones

Philippe Langlois
Telecom Security Task Force
pl@[Link]
 Agenda
ƒ History of telecommunications security
ƒ Review of digital telephony concepts
ƒ Discovering the backbone
ƒ SIGTRAN: From SS7 to TCP/IP
ƒ Attacking SIGTRAN
ƒ Q&A
ƒ Lab - BYOL
 The origins
ƒ Phreaking is a slang 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.
 But… what is it?
ƒ 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
The Blue Box

Steve Jobs and Steve Wozniak in 1975 with a bluebox

ƒ CCITT#5 in-band signalling sends control messages over

the speech channel, allowing trunks to be controlled
ƒ Seize trunk (2600) / KP1 or KP2 / destination / ST
ƒ Started in mid-60’s, became popular after Esquire 1971
ƒ Sounds produced by whistles, electronics dialers, computer
programs, recorded tones
 The end of the blueboxing era

ƒ Telcos installed filters, changed

frequencies, analyzed patterns, sued
fraudsters
ƒ The new SS7 digital signalling protocol is
out-of-band and defeats blueboxing
ƒ In Europe, boxing was common until the
early nineties and kept on until 1997-1998
ƒ In Asia, boxing can still be done on some
countries.
 Past & current threats on the
telecom backbone
ƒ Fraud
ƒ Blue Box
ƒ Internal Fraud

ƒ Reliability
ƒ US: 911, Europe: 112
ƒ How much lost revenue is one
minute of downtime?
 21st century telecom attacks

ƒ SIP account hacking

ƒ Remember ”Calling Cards” fraud?

ƒ VoIP GW hacking
ƒ Remember ”PBX hacking”?

ƒ Signalling hacking directly on SS7 – SIGTRAN

level
ƒ Back at the good old BlueBox?
ƒ Not nearly but, the closest so far…
 Agenda
ƒ History of telecommunications security
ƒ Review of digital telephony concepts
ƒ Discovering the backbone
ƒ SIGTRAN: From SS7 to TCP/IP
ƒ Attacking SIGTRAN
ƒ Q&A
ƒ Lab - BYOL
 Telephony 101
(recap)

ƒ Fixed line (PSTN): analog, digital (ISDN)

ƒ Mobile: analog (AMPS, NMT), digital (GSM,
CDMA, 3G), private (PMR, Military)
ƒ Telephony switches speak out-of-band SS7 signalling
ƒ Speech and data convergence is increasing
ƒ Services are growing (SMS, MMS, packet data,
WLAN integration, etc.)
ƒ VoIP and related technologies (SIP, IMS,
PacketCable)
Telecom Backbones Organization
 SS7: The walled garden
ƒ From a customer perspective
ƒ Wikipedia: “Walled Garden - Mobile Network
Operators (MNOs). At the start of 2007, probably the
best example. MNOs manage closed networks - very
hard to enter the garden, or leave the garden, especially
as it pertains to Internet, web services, web
applications. Fearful of losing customer and brand
control, the MNOs opt to guard the garden as much as
possible.”
ƒ But also from a technology perspective
ƒ OSI : Open Protocol - Proprietary Stacks
ƒ Closed OSI network, IP management network
 Agenda
ƒ History of telecommunications security
ƒ Review of digital telephony concepts
ƒ Discovering the backbone
ƒ SIGTRAN: From SS7 to TCP/IP
ƒ Attacking SIGTRAN
ƒ Q&A
ƒ Lab - BYOL
Details of an SSP / STP
SS7 Network: Regional & Local
 Opening up
ƒ Deregulation
ƒ Europe / US: CLEC vs ILEC
ƒ New services and new busines partners
ƒ Premium numbers, SMS providers, …
ƒ Push toward an “All IP” infrastructure
ƒ Management network first…
ƒ Cost
ƒ SIGTRAN (SS7 over IP)
Telco Backbone Global Picture

IMS = SS7 SIGTRAN + IP-based Advanced Services

 VoIP and SIGTRAN

ƒ 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.
 A shock of culture:
SS7 vs. IP
ƒ Different set of people
ƒ IT vs Telecom Operations
ƒ New Open Technology
ƒ Open stack
ƒ Open software
ƒ Interconnected Networks
ƒ Habits and induced security problems
ƒ Eiffel, QA, Acceptance tests, …
 Agenda
ƒ History of telecommunications security
ƒ Review of digital telephony concepts
ƒ Discovering the backbone
ƒ SIGTRAN: From SS7 to TCP/IP
ƒ Attacking SIGTRAN
ƒ Q&A
ƒ Lab - BYOL
SIGTRAN in the VoIP big picture
SCTP as SIGTRAN Foundation

SS7 SIGTRAN
 SCTP Specs & Advantages
ƒ RFC2960
ƒ SCTP: Stream Control Transmission
Protocol
ƒ Advantages
ƒ Multi-homing
ƒ DoS resilient (4-way handshake, cookie)
ƒ Multi-stream
ƒ Reliable datagram mode
ƒ Some TCP & UDP, improved
 SCTP in the wild
ƒ Software
ƒ Tons of proprietary implementations
ƒ Open source implementations (Linux, BSD…)
ƒ Network presence
ƒ Stack widespread with Linux 2.6 support
ƒ Scarcity on the open Internet
ƒ Rising in telco backbones / intranet
ƒ Adoption by other worlds: MPI clusters,
high speed transfers, …
 SCTP Ports & Applications
ƒ [Link]
ƒ Common ports from IANA and RFCs
ƒ Augmented with open source package ports
ƒ Updated based on SCTPscan results

ƒ Open to contribution

ƒ Watch out for the application fingerprinting

ƒ Cf. collaborative scanning
 Agenda
ƒ History of telecommunications security
ƒ Review of digital telephony concepts
ƒ Discovering the backbone
ƒ SIGTRAN: From SS7 to TCP/IP
ƒ Attacking SIGTRAN
ƒ Q&A
ƒ Lab - BYOL
 SCTP Association: 4-way
handshake
Client Server
socket(),connect() socket(),bind(),listen(),
accept()

INIT

INIT-ACK

CO O K IE-ECH O

CO O K IE-ACK
Scanning vs. Stealth Scanning
Attacker Servers

INIT

INIT

INIT

INIT-ACK
 Tool Demo: SCTPscan
ƒ Like nmap for SCTP ports (-sS)

root@gate:~/sctp# ./sctpscan-v11 --scan --autoportscan -r

203.151.1
Netscanning with Crc32 checksumed packet
[Link] SCTP present on port2905
[Link] SCTP present on port7102
[Link] SCTP present on port7103
[Link] SCTP present on port7105
[Link] SCTP present on port7551
[Link] SCTP present on port7701
[Link] SCTP present on port7800
[Link] SCTP present on port8001
[Link] SCTP present on port2905
root@gate:~/sctp#
 RFC & Implementation
ƒ Where implementation diverge from RFCs
ƒ RFC says « hosts should never answer to
INIT packets on non-existings ports. »
ƒ RFC: 0, hacker: 1.
ƒ Syn scanning is slow when no RST
ƒ Same here, but thanks to over-helping
implementation
ƒ on scanning, hacker wins
 Below the IDS radar
ƒ How many firewall logs dropped SCTP
packets?
ƒ How many IDSes watch for SCTP
socket evil content?
ƒ Example
ƒ Real life distributed IDS
ƒ Hundreds of thousands of IP scanned
ƒ Not detected / Not 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: […]
ƒ 5) 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 Fingerprinting
ƒ SCTP stack reliability
ƒ Robustness testing (stress testing)
ƒ QA of a few stacks
ƒ Fuzzing built-in SCTPscan
ƒ SCTP stack fingerprinting
ƒ Discrepancies in SCTP answer packets
ƒ Different stack behaviours
ƒ Much more states than TCP
ƒ Much more FP opportunities
Scarce Presence - Distributed
Collaborative Scaning
ƒ SCTP application is rare on the internet
ƒ But common on modern telco backbones
ƒ Research needs collaborative effort
ƒ Built-in collaborative reporting with SCTPscan.
ƒ Going to be expanded for
ƒ Fuzzing results
ƒ Application Fingerprinting
Going up: SIGTRAN & SS7
Going up: upper layer protocols
ƒ Key to the upper level
ƒ M2PA and M3UA
ƒ Vulnerabilities
ƒ Telecom potential
ƒ Technical vulnerability
ƒ The expert way & the automated way
ƒ Ethereal is our friend
ƒ In need of new packet captures: open call!
 Demo: Ethereal Dissection of
Upper Layer Protocols
ƒ Fire up your Ethereal or Wireshark!
ƒ Collect your own examples
ƒ And contribute to the SCTPscan wiki!
ƒ Lots of SS7 specifics in higher level protocols
ƒ DPC/OPC
ƒ BICC, ISUP, TCAP, GSM-MAP protocols
ƒ Less and less IP-related
ƒ IP is only a bearer technology
ƒ Transport only
 Fuzzing upper layer protocols
ƒ Quick way to find vulnerabilities
ƒ Automated inspection
ƒ State fuzzing vs. input fuzzing
ƒ Already some stack vulnerabilities in the wild
ƒ Only found DoS for now
ƒ Input fuzzing for UA layers
ƒ SIGTRAN higher protocols
ƒ User Adaptation layers
ƒ Largest “opportunity” /
work area
© Roger Ballen
 Vulnerability evolution
ƒ Same as with TCP
ƒ First, stack and “daemons” vulnerabilities
ƒ More and more application-level vulnerabilities
ƒ Custom & Application-related
ƒ Requires more knowledge of Telecom
ƒ Same as with web app testing
ƒ “niche”: requires understanding of SS7 world
ƒ Specifics
ƒ Defined Peers make attack difficult
 References & Conclusion

ƒ New realm
ƒ Same Rules
ƒ New fun!
ƒ Lots of references
ƒ RFC 2960, 4166, 4666
ƒ ITU (Now free)
 Q&A
ƒ Thanks a lot!

ƒ First round of questions

ƒ Before hands on
 Agenda
ƒ History of telecommunications security
ƒ Review of digital telephony concepts
ƒ Discovering the backbone
ƒ SIGTRAN: From SS7 to TCP/IP
ƒ Attacking SIGTRAN
ƒ Q&A
ƒ Lab - BYOL
 Lab: Hands-on Agenda
ƒ Setup
ƒ Network Inventory
ƒ Scanner vs. Targets
ƒ Scanning types
ƒ Scanning conflicts & Kernel impact
ƒ Analyze a SCTP exchange
ƒ Ethereal
ƒ Discover a SIGTRAN architecture
ƒ Exploring & Finding vulnerabilities
 Required Skills
ƒ Know how to compile a C program
ƒ Know how TCP protocol works
ƒ Know how to use tcpdump and ethereal
 Hands on requirement
ƒ Laptop with VMware or bootable distribution with
ƒ Ubuntu with Linux 2.6 kernel (scanner and dummy server tested ok) -
Download
ƒ nUbuntu Live CD with Linux 2.6 kernel (scanner and dummy server
tested ok) - Download
ƒ Linux 2.4 distribution (only scanner will work, not the dummy server)
ƒ Solaris 10
ƒ Nexenta OS (GNU/Linux Solaris 10) (dummy server only) - Download
instructions or distrib or VMware image at Distrowatch
ƒ MacOsX (scanner and dummy server tested ok)
ƒ Software
ƒ C Compiler (apt-get install gcc)
ƒ Glib 2.0 development library
ƒ Libpcap development librar
ƒ tcpdump (apt-get install tcpdump)
ƒ ethereal (apt-get install ethereal)
ƒ netstat
 Important workshop notes!
ƒ Your computers / VMware images must be
installed before the workshop.
ƒ OS installation or vmware image setup is not
covered during the workshop.
ƒ We have some ISOs of these Oses available for
download in any case, but beware of the short
time.

ƒ [Link]
 Notes on VMware images
ƒ Make sure to select "Bridged mode" for your
ethernet connector.
 Hands-on Tests
ƒ Who scans who?
ƒ Scanners vs. Targets
ƒ Scanning types
ƒ Scanning conflicts & Kernel impact
ƒ Analyze a SCTP exchange
ƒ Ethereal
 Common problems
Q: I try to run the Dummy SCTP server for testing, and I get: "socket:
Socket type not supported"
A: Your kernel does not support SCTP sockets.
SCTP sockets are supported by Linux Kernel 2.6 or Solaris 10.
For Linux, you may want to try as root something like: modprobe sctp
Then rerun: sctpscan --dummyserver
Note: you only need a SCTP-aware kernel to run dummyserver.
Scanning is ok with 2.4 linux kernels!
For Mac Os X, you may add support for SCTP in Tiger 10.4.8 by
downloading:
[Link]
Install the software package and run as root:
kextload /System/Library/Extensions/[Link]
Then you can run "sctpscan -d" to run the dummy server.
Note that "netstat" won't report the use of the SCTP socket, use
instead:
lsof -n | grep -i '132?'
 Kernel conflicts: Linux 2.6
[root@nubuntu] ./sctpscan -s -r 192.168.0 -p 10000
Netscanning with Crc32 checksumed packet
[Link] SCTP present on port 10000
SCTP packet received from [Link] port 10000 type 1 (Initiation (INIT))
End of scan: duration=5 seconds packet_sent=254 packet_rcvd=205 (SCTP=2,
ICMP=203)
[root@nubuntu] uname -a
Linux nubuntu 2.6.17-10-386 #2 Fri Oct 13 [Link] UTC 2006 i686 GNU/Linux
[root@nubuntu]

ƒ If after this scan, we test the dummy server SCTP daemon built in SCTPscan, we'll notice that further scans from
this host will have different behavior:
[root@nubuntu] ./sctpscan -d
Trying to bind SCTP port
Listening on SCTP port 10000
^C
[root@nubuntu]
[root@nubuntu]
[root@nubuntu] ./sctpscan -s -r 192.168.0 -p 10000
Netscanning with Crc32 checksumed packet
[Link] SCTP present on port 10000
SCTP packet received from [Link] port 10000 type 1 (Initiation (INIT))
SCTP packet received from [Link] port 10000 type 6 (Abort (ABORT))
End of scan: duration=5 seconds packet_sent=254 packet_rcvd=206 (SCTP=3,
ICMP=203)
[root@nubuntu]
 Kernel conflicts: MacOS X
localhost:~/Documents/sctpscan/ root# kextload
/System/Library/Extensions/[Link]
kextload: /System/Library/Extensions/[Link] loaded successfully
localhost:~/Documents/sctpscan/ root# ./sctpscan -s -r 192.168.0 -p 10000
Netscanning with Crc32 checksumed packet
End of scan: duration=9 seconds packet_sent=254 packet_rcvd=3 (SCTP=0, ICMP=3)
localhost:~/Documents/sctpscan/ root# kextunload
/System/Library/Extensions/[Link]
kextunload: unload kext /System/Library/Extensions/[Link] succeeded
localhost:~/Documents/sctpscan/ root# ./sctpscan -s -r 192.168.0 -p 10000
Netscanning with Crc32 checksumed packet
SCTP packet received from [Link] port 10000 type 1 (Initiation (INIT))
[Link] SCTP present on port 10000
End of scan: duration=9 seconds packet_sent=254 packet_rcvd=5 (SCTP=2, ICMP=3)
localhost:~/Documents/sctpscan/ root#

ƒ You saw in this example that loading the SCTP kernel module prevents
SCTPscan to receive the response packets, and thus is not capable to detect
presence of a remote open port.
 Thanks
ƒ Thank you very much!

ƒ Special thanks to Emmanuel Gadaix, Fyodor

Yarochkin, Raoul Chiesa, Inode, Stealth,
Raptor, Job De Haas, Michael M. Kemp, all
TSTF OOB Research Team and all the
community

ƒ Contact / Questions:
ƒ Philippe Langlois - pl@[Link]

Some illustrations on slides are © Sycamore, Cisco, Continous Comp,

Backup slides
Comparison SCTP, TCP, UDP

QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.