ISUP and QSIG Security

Automatic Number Identification (ANI)-based security mechanisms can be spoofed
in both directions, although some carriers claim to have clamped down on this practice
(I'm not convinced this can be done).This can be used to create false Caller-ID
data to subscribers. If your organization uses ANI to verify identity (as a very large
credit card user has been known to do), you are asking for trouble. It’s only slightly
more difficult than spoofing an e-mail address if you know what you’re doing, so
tread carefully here.
Other ISUP and QSIG fields have similar problems, so be very careful with any
trust assumptions you make with these protocols. Always assume that CLASS services
like distinctive ringing, selective call acceptance, selective call forward, and so on will
be fooled by ANI spoofing and similar ISUP or SSIG attacks.

PSTN Protocol Security

If you thought that PSTN protocols are more secure than the IP protocols riding on
PSTN access circuits, then prepare to be shocked. In some respects, one of the
greatest threats to the Internet is the PSTN itself.
SS7 and Other ITU-T Signaling Security
Despite the fact that ITU-T signaling protocols prior to SS7 are notoriously insecure
(see the sidebar on Blueboxing and the Phone Phreaking community earlier in
the chapter), they continue to be deployed around the world along with older
switching equipment that is vulnerable to toll fraud, eavesdropping, and other risks.
If your VoIP system will be interfacing with such equipment, take countermeasures
to reduce potential exposure and liability, set alarms, and review logs.
That is not to suggest that SS7 is particularly secure, but it is much harder for a
subscriber to inject signaling into an SS7 network.That being said, the primary threat
for SS7 networks are the peering arrangements (particularly among CLEC partners)
for injection of false and/or fraudulent signaling and other messaging information.
SS7 as currently defined does not have policy controls built in to address this issue.
The risks and countermeasures were summarized quite well by the 3GPP SA WG3
Technical Specification Group in January 2000 for 3G TR 33.900 V1.2.0:
The security of the global SS7 network as a transport system for
signaling messages e.g. authentication and supplementary services
such as call forwarding is open to major compromise.
The problem with the current SS7 system is that messages can be
altered, injected or deleted into the global SS7 networks in an
uncontrolled manner. In the past, SS7 traffic was passed between
major PTOs covered under treaty organization and the number of
operators was relatively small and the risk of compromise was low
Networks are getting smaller and more numerous. Opportunities
for unintentional mishaps will increase, as will the opportunities for
hackers and other abusers of networks. With the increase in different
types of operators and the increase in the number of interconnection
circuits there is an ever-growing loss of control of
security of the signaling networks.
There is also exponential growth in the use of interconnection
between the telecommunication networks and the Internet. 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,
which have damaged a network. To date, there have been very few
deliberate actions. The availability of cheap PC based equipment
that can be used to access networks and the ready availability of
access gateways on the Internet will lead to compromise of SS7
signaling and this will affect mobile operators.
The risk of attack has been recognized in the USA at the highest
level of the President’s office indicating concern on SS7. It is understood
that the T1, an American group is seriously considering the
issue. For the network operator there is some policing of incoming
signaling on most switches already, but this is dependent on the
make of switch as well as on the way the switch is configured by
operators.
Some engineering equipment is not substantially different from
other advanced protocol analyzers in terms of its fraud potential,
but is more intelligent and can be programmed more easily. The
SS7 network as presently engineered is insecure. It is vitally important
that network operators ensure that signaling screening of SS7
incoming messages takes place at the entry points to their networks
and that operations and maintenance systems alert against
unusual SS7 messages. There are a number of messages that can
have a significant effect on the operation of the network and inappropriate
messages should be controlled at entry point.
Network operators or network security engineers should on a regular
basis carry out monitoring of signaling links for these inappropriate
messages. In signing agreements with roaming partners and
carrying out roaming testing, review of messages and also to seek
appropriate confirmation that network operators are also screening
incoming SS7 messages their networks to ensure that no rogue
messages appear.
In summary there is no adequate security left in SS7. Mobile operators
need to protect themselves from attack from hackers and inadvertent
action that could stop a network or networks operating
correctly.
Bottom line: Just because SS7 is harder for subscribers to crack doesn’t mean it is
secure overall. SS7 peering in the PSTN is not nearly as robust as its BGP equivalent
on the Internet, and this has the potential for dire consequences if it were to be
exploited maliciously. It’s not yet clear if or how the ITU-T plans to address these
concerns directly in a revision to SS7, although a T1S1 SS7 Security Standard was
proposed at one time as part of an overall Study Group 17 (SG-17) effort. RFC
3788, Security Considerations for SIGTRAN protocols, was published by the
Internet Engineering Task Force (IETF) in June 2004, and suggests the use of specific
TLS and IPSEC profiles when using SS7 over IP, though it also notes that the
“Peer To Peer” challenge still exists with SS7.The Network Interconnection
Interoperability Forum (NIIF) within the Alliance for Telecommunications Industry
Solutions (ATIS) has published many guidelines on the topic of secure interconnections
(available to members or to the public for a fee).The good news is that unlike
the Internet’s in-band signaling model, which is vulnerable to direct attack, the SS7
signaling network is out of band to the voice and data communication it carries.

PSTN Call Flow

Now that we have discussed what makes up the PSTN, let’s put it all together and
walk through a messaging sequence. Here we will start from a caller picking up the
phone attempting to make a call.The flow will be broken down into off-hook, digit
receipt, ring down, conversation, and on-hook sections.We will start by imagining
someone (Party B) picking up the phone to make the call (to Party A, on the same
CO switch).The following list outlines, in order, the actions performed by the
network:
Party B picks up the phone, and the off-hook sequence begins:
1.The off-hook state is detected by the switch (loop or ground start).
2.The switch establishes the time slot and sends a dial tone on the voice path.
3.The switch awaits digits pressed by Party B.
The digit receipt sequence is as follows:
1. Party B dials digits on the touch pad.
2. Each digit is received by the switch and sends a silence tone and starts Inter
Digit Timer (IDT).
3. IDT starts when the switch is awaiting a dialed digit and stops when the
digit is pressed.
After Party B dials the last number, the ring down sequence begins:
1. When the digit receipt stops (or when the maximum dialed digits are
pressed), the switch sends the request to the called number to allocate a
time slot.
2. When the called switch allocates a time slot the path is switched to the call
handler.
3. Party A’s phone rings (unless it is already off-hook).
Parties A and B can begin their conversation after the following sequence of
steps is completed:
1. Party A picks up the phone.
2.The switch receives an answered call indication (off-hook).
3.The ring-down signals stop.
4. Parties A and B are able to speak on the established voice path.
After the two parties finish their conversation, the on-hook sequence of steps
begins:
1.The conversation ends with either party hanging up the phone.
2.The on-hook indication is received by switches on access networks.
3.The switches release established paths (termination).
4.The call is ended.
During each of these sections there is traffic traveling in both directions to keep
the signal alive.There are numerous acknowledgement requests between the caller
and their access network, and the two access networks and the called party and their
network, to keep this communication path alive. Most of this traffic is happening
along the voice path.
This book is about securing voice over Internet networks, so later in the book
you will be introduced to a protocol called Session Initiation Protocol (SIP).Though
it is early on in the text we will now walk through a SIP to PSTN call. Remember
that PSTN is a voice network and the SIP is originating from a data-only network.
We will follow the sections of off-hook, digit receipt, ring down, conversation, and
on-hook.To better visualize this call sequence we will use the