In part 1 we went through the basics of how SIMs and SMS work, as well as the concepts of SMS-Submit, SMS-Deliver and how to send APDU messages through an USB Modem. Here, we will discuss the concept of Over The Air (OTA) messages.
OTA messages, also known as binary messages, are specific APDU messages that contains a set of (U)SIM Application Toolkit (USAT) commands, these are messages directed to specific applications within the SIM Card which, in turn, execute the USAT commands provided in the message itself, these commands include, for instance: setting up calls, sending short messages, updating SIM information, editing SIM files, etc.
OTA messages are usually designed to be sent from the operator to the subscriber; a service provider can introduce new SIM services, modify the contents of the SIM, perform software updates, configuration settings and even update the encryption keys to mobile devices.
OTA messages are essential for exploiting the SIM Jacker vulnerability, since it is one of these binary messages that we need to craft in order to be able to exploit the it. Of course, it is also a requirement that the provider’s infrastructure allows for these kind of messages to be relayed by the SMS Center.
An OTA message (binary message with a specific configuration) can be constructed into an SMS-PP Data Download from an SMS-Deliver which, in turn, is constructed from an SMS-Submit (sent from an USB Modem for instance), below we will discuss SMS-PP Data Download in depth, but, the process, at a very high level, is shown in the next image:
An SMS-Submit is sent from the USB modem to the SMS Center, which then transforms it into an SMS-Deliver. If the message conforms with certain specific configurations regarding Protocol Identifier (PID) and Data Coding Scheme (DCS) (as we will see below), then the SMS-Deliver will be transformed into an SMS-PP Data Download.
An example of an SMS-Submit for an OTA message is shown in the image below:
Besides PID and DCS, one very important field is the Security Parameter Indicator (SPI), which defines what protections are applied for incoming messages sent to a SIM application and these protections are defined by the Ciphering Key Identifier (KIc) and Key Identifier (KID) fields.
The TAR is the Target Application Reference; an identifier that determines which SIM application the message is directed to. The CNTR and PCNTR are protocol level counters that can be set to zeros.
The Secured Data contains the commands that are to be executed, these commands are constructed using the USAT and, according to the technical specification: “The USAT provides mechanisms which allow applications, existing in the UICC, to interact and operate with any ME which supports the specific mechanism(s) required by the application“, where UICC is Universal Integrated Circuit Card and ME means Mobile Equipment.
There are 11 different mechanisms defined for USAT which are dependent upon the commands and protocols relevant to it, these mechanisms are:
- Profile Download.
- Proactive UICC.
- Data Download to UICC.
- Menu Selection.
- And 7 more…
From which, we are mostly interested in 2 of them: Proactive UICC and Data Download to UICC:
Proactive UICC
Proactive UICC provides a mechanism by which the UICC can initiate some actions to be taken by the mobile equipment, these actions include: displaying text to the mobile equipment, sending short messages, setting up a voice call, running AT commands and more.
This mechanism (Proactive UICC) is used in conjunction with the Data Download to UICC mechanism when exploiting the SIM Jacker vulnerability and, for the purpose of demonstration, setting up a call through a proactive command will be a good proof of concept to determine if the vulnerability was exploited or not.
Data Download to UICC
The Data Download is part of the Envelope Commands and there are 2 different types: the SMS-PP Data Download and the Cell Broadcast Data Download, we will be focusing on the first one; based on the technical specification, if the Data Download via Poin-to-Point service is allocated and activated in the UICC Service Table, the mobile equipment shall follow the next procedure:
When the mobile equipment receives a short message with:
- Protocol Identifier = SIM Data Download and
- Data Coding Scheme = Class 2
Then the mobile equipment shall pass the message transparently to the UICC using the ENVELOPE (SMS-PP DOWNLOAD) and the mobile equipment shall not display the message or alert the user of a short message waiting.
The format on an SMS-PP Data Download Envelope is as shown below (do note that the Tag-Length-Value notation is heavily used to construct these kind of messages, for example, in the below image for Device Identities: Tag=0x82, Length=0x2 and Value=0x8381):
The Received SMS PDU (in the bottom right of the above image) is constructed from the SMS-Deliver and thus from the initial SMS-Submit as well. The initial SMS-Submit is constructed in a manner such that the SMS-PP Data Download Envelope will be generated from it, that is, with a specific Protocol Identifier (PID) and Data Coding Scheme (DCS). These values need to be set as follows:
- Protocol Identifier = 0x7F (SIM Data Download)
- Data Coding Scheme = 0xF6 (Class 2)
As clearly stated in the technical specification (and this is very important), the SMS-PP Data Download is transparently passed to the UICC and the mobile equipment does not display an alert to the user, this is very helpful from the attacker’s point of view, since the user will not notice that he/she has received the binary SMS message.
S@T Browser
Each application within the SIM Card uses the fields SPI, KIc and KID to define a Minimum Security Level (MSL), which specify the level of security that is applied to messages sent to each specific application.
The particular USAT technology exploited by the SIM Jacker is known as the S@T Browser and the security for it’s incoming messages is defined in the technical specification 3GPP TS 23.048, there are 2 supported security levels:
By default, the S@T Browser is configured with the first MSL, that is No security applied (SPI=0x0000, KIc=0x00 and KID=0x00), meaning that it does not require any authentication or encryption, which also means that an attacker would be able to execute functionality in the SIM Card through the vulnerable S@T Browser without the user noticing (functionality like placing a call or sending an SMS text message). In fact, the S@T Browser is the SIM Card application targeted by the SIM Jacker.
TAR
The Target Application Reference (TAR) indicates the target protocol or application that the message is directed to. For the S@T protocols, the following TARs are defined (do note that the TAR being targeted by the SIM Jacker is the Low Priority Push 0x505348):
In part 3 of these series we will see how to use the SIM Tester tool to identify the SIM Jacker vulnerability within a SIM Card using PCSC-enabled SIM Card reader.
References
[1] ETSI TS 131 111
Recent Comments