Short Message Service is a relatively straightforward
system designed for one mobile subscriber to be able to send a short
message to another mobile subscriber. The SMS system itself operates as a
“store and forward” system within the carrier. This means that when
mobile subscriber Bob wants to send a message to mobile subscriber
Alice, the process involves a few (slightly simplified) steps. First,
Bob composes the message on his mobile phone and then submits it to the
carrier network. The server in the carrier network that handles the
message is referred to as the short message service center, or SMSC.
The SMSC receives the message from Bob and then checks to see if Alice
is on the network and able to receive messages. If she is, the SMSC then
forwards the message to Alice, who sees a new message appear on her
mobile phone from Bob. The SMSC both stores incoming messages and
determines when the messages can be forwarded on. This is what gives the
system its name. This example has been slightly simplified, of course.
In a real carrier deployment, more components are involved, such as
billing equipment; however, they have been left out here because they do
not play a role in the attacks we will discuss throughout this chapter.
Figure 1 illustrates a basic SMS message being sent from Bob to Alice inside the same carrier.
From a high level, this process only changes slightly when Bob and Alice are on different carrier networks. Figure 2 illustrates a basic SMS message being sent from Bob to Alice when they use separate carriers.
However, in practice the
process of a message being sent from a user on one carrier to a user on
another carrier can have a huge impact on determining whether or
not an attack will be successful. Each carrier tends to use different
protocols internally to transport SMS messages, and as such cannot
communicate directly with other carriers in order to hand off SMS
messages. Typically, the first carrier will convert the message into an
agreed upon format (such as e-mail) before handing the message over to
the other carrier for processing. In practice, this means that although
the contents of the message tend to remain the same, other information
such as bitmask values in the headers of the message may be stripped
out.
References to the contents
of a message and bitmask header fields bring up an important question:
What exactly does a raw SMS message look like? A raw SMS message is
typically referred to as a protocol data unit, or PDU.
A basic SMS PDU contains several header fields as well as the message
contents. The header fields define a number of values that are essential
in successfully delivering and understanding the message being sent.
For example, one such value is the destination phone number of the
message being sent. This value is what the SMSC uses to determine whom
the message is being sent to. Another value is the message encoding
type. SMS messages can typically be encoded in one of three encoding
types: GSM 7-bit, 8-bit ASCII, and 16-bit UCS2. The GSM 7-bit encoding
method is predominantly used in English language text messages. This
encoding uses only seven bits per character instead of the normal ASCII
eight bits. Because a bit is shaved off from each character, a message
can store extra characters, allowing the user to type more into a single
message. The ASCII 8-bit encoding is the normal ASCII 8-bit encoding
that has been used in computing for quite some time—no modifications
were made for its use in SMS. The last encoding type, UCS2, is a 16-bit
encoding type that was developed as the predecessor to the UTF-16
encoding type. It allows the use of extended characters and is
predominantly used for non-English language text messages such as
Mandarin Chinese and Arabic.
Figure 3 illustrates a basic SMS messages received from “1-555-555-1212” using GSM 7-bit encoding and containing the message “AAA.”
Arguably the most important field in an SMS PDU is the User Data Header, or UDH.
The UDH allows an additional set of headers to be defined in the
message contents portion of the SMS PDU. This is what has allowed such
extensive functionality, such as multimedia messages, to be built on top
of SMS. The ability for additional headers
to be defined inside a message allows any amount of additional
functionality can be built on top of SMS messages. This functionality
does not always have to be as advanced as graphical messages, however.
For example, one extremely common use of the User Data Header is to
allow multipart SMS messages. When a user wishes to send a message that
contains more characters than can be held by a single message, a User
Data Header is defined that tells the receiving mobile phone that this
message will be delivered in multiple parts. This multipart message UDH
then contains all the information the receiving mobile phone needs to
successfully reconstruct the different parts of the message into the one
large message the user originally sent.
Figure 4 illustrates a UDH inside an SMS PDU.
