SIM Hijack attack

security

asked 2019-09-12 22:51:21 +0300

Linuxovod
191 ●10 ●14 ●22

Is Sailfish vulnerable? https://thehackernews.com/2019/09/simjacker-mobile-hacking.html

edit retag flag offensive close delete

Comments

1

Oh yes

and can be exploited regardless of which handsets victims are using.

And oh, oh: not completely regardless. My N900 would be safe as it does not have this S@T technology :)

peterleinchen ( 2019-09-13 00:58:13 +0300 )edit

3

@peterleinchen, an N900 is just as vulnerable (or safe) as any other device! This attack is completely independent of the operating system, as no code needs to be run on the main CPU.
The attack solely uses the resources of the SIM card, all of which are JavaCards by specification, plus information provided by the cellular modem (location, IMEI etc.).
So ultimately it all depends on your SIM card providing a S@T implementation (or not).
Please use the force and read the source! Feel free to point out misunderstandings by me, accompanied by a pointer to a contradictory statement there.

olf ( 2019-09-13 01:48:23 +0300 )edit

1

I was under the impression that as the N900/Maemo does not have an Implementation of this SIM kit application and this part of source

Once this information is retrieved, the Simjacker code running on the UICC then collates it and sends the combined information to a recipient number via another SMS (we call this the ‘Data Message’), again by triggering logic on the handset.

I may be wrong...

peterleinchen ( 2019-09-13 08:22:19 +0300 )edit

"One important note is that for some specific attacks handset types do matter. Some, such as setting up a call, require user interaction to confirm, but this is not guaranteed and older phones or devices with no keypad or screens (such as IoT device) may not even ask for this." On some CDMA oriented (but GSM compatible) android phones S@T browser is missing too.

Linuxovod ( 2019-09-13 17:03:19 +0300 )edit

2

@peterleinchen, well AFAICS the terms "device" and "handset" are used interchangeably in both of the documents (the high-level one [1] and the bit more detailed one [2]) and addresses the whole device, including cellular modem etc.
The used language is remarkably imprecise, but that "triggering logic on the handset" IMO means nothing more than "let the modem send out the exfiltrated data per SMS", just as the modem was used before that to collect information e.g. location data.

@Linuxovod, S@T is clearly described as a software component deployed with and running on the UICC (i.e. any modern SIM card).

olf ( 2019-09-13 17:48:13 +0300 )edit

7

answered 2019-09-13 00:51:44 +0300

olf
10393 ●104 ●201 ●158

Please read the document, you linked to!
No, SailfishOS is not vulnerable, just as all other operating systems are not. But your SIM card might.

edit flag offensive delete publish link

Comments

1

LOL Why read articles if the headline is shocking enough?

4carlos ( 2019-09-13 07:38:41 +0300 )edit

1

@olf they say: "One important note is that for some specific attacks handset types do matter. Some, such as setting up a call, require user interaction to confirm, but this is not guaranteed and older phones or devices with no keypad or screens (such as IoT device) may not even ask for this." My question meant what will Sailfish do in this case.

Linuxovod ( 2019-09-13 17:00:12 +0300 )edit

1

Question reopened. The attack needs handset support. Does SF support STK? If yes, possible to disable?

Stefanix ( 2019-09-13 18:12:47 +0300 )edit

1

Well that aspect seem to be quite clear: Modern phones will ask the user for confirmation on specific actions initiated by the SIM card and carried out by the modem, such as making a call.
Those actions mentioned for the specific attack example (receiving and sending SMS, retrieving IMEI and location data) are not among those "special actions" (for reasons). Hence the OS is not informed (i.e. asked to obtain a confirmation by the user), thus does not and cannot "do" anything.

olf ( 2019-09-13 18:17:40 +0300 )edit

2

@Stefanix, can you please provide a pointer, why you believe that this "attack needs handset support".
S@T definitely needs no OS support.

IMO it is rather the opposite: Some classes of devices ("handset types") may ask user for a confirmation, if triggered to do so by the UICC (= SIM card), while others either do not (unimplemented, e.g. on old dumb-phones) or cannot (lack of screen and keypads; e.g. (IoT devices etc.).

olf ( 2019-09-13 18:27:46 +0300 )edit

6

answered 2019-09-14 11:37:11 +0300

Nieldk

4562 ●40 ●70 ●76

The attack is dependent on two conditions. 1) UICC SIM, meaning, GSM network 2) The precense of STK application, which is an application that lives on the UICC SIM card, but is not necessarily present for all carrier SIMs, for example, it is not present on my carrier (Denmark) The STK application on SIM card, communicates with the phone, and is communicating via the application present in ofono. This can be disabled, and your phone would not be vulnerable.

edit flag offensive delete publish link

1

answered 2019-09-13 19:37:00 +0300

xneo

1103 ●17 ●33 ●33

http://eric-schmidt.org/

As I understand the vulnerability, disabling SIM-Toolkit should be a workaround...

edit flag offensive delete publish link

Comments

Ist the STK supported at all? If yes, can it be deactivated?

Stefanix ( 2019-09-13 20:06:15 +0300 )edit

2

https://together.jolla.com/question/182073/sim-card-removed-issue-with-sailfishx/

There you can find how-to disable STK...

xneo ( 2019-09-13 20:17:11 +0300 )edit

1

Thanks, neo, for that link! So I would conclude that SF together with STK enabled SIMs has this vulnerability. Disabling the STK as suggested by jovirkku should prevent the described attacks. @Linuxovod: This should answer your question.

Stefanix ( 2019-09-13 20:29:52 +0300 )edit

1

@Neo: +1

@Stefanix,

So I would conclude that SF together with STK enabled SIMs has this vulnerability.

Yes and no, because it is OS independent: "STK enabled SIMs" is the point.

Disabling the STK as suggested by jovirkku should prevent the described attacks.

I am afraid "disabling" the STK for the rild (which configures and serves the cellular modem) just suppresses triggers from the STK to cause actions on the main CPU (e.g. installing icons for starting Java applications on the UICC / SIM card or asking for user confirmations).

olf ( 2019-09-13 21:14:48 +0300 )edit

1

@olf: Actually I am not familiar with the ME SW architectures, But what you write is not consistent. You confirm that it is possible to configure the cellular modem's STK functions (if they exist), i.e triggers. I would call that a OS function. On the other hand you write that the modem function of forwarding SM on STK request is independent of the OS and not changeable. If we can disable triggers, we could also disable the whole STK support. Of course this is implementation dependent. The STK spec require to support all functions of a class ("However, any ME claiming to supportSIM Application Toolkit need not support all toolkit functions, but shall support all functions within a classas given in the table below:"), So a partial support of STK functions would not be compliant. If there is a function to disable the STK (and some MS have that on the UI), the whole STK support would have to be disabled.

Stefanix ( 2019-09-13 22:01:16 +0300 )edit

0

answered 2019-09-14 00:37:48 +0300

onehundredpercentdruken
61 ●3 ●5 ●8

I would be nice to have some kind of script or approach to pen test the SIM card that is in the Jolla phone. Even on the site which reported this error, there were no approaches on how to actually check and test the SIM card, which is somewhat annoying. On a forthcoming event a larger amount of information about this issue will (?) be revealed, but it would be nice to see whether one is vulnerable to this kind of attack or not.

https://simjacker.com/ That is all a bit pointless.

edit flag offensive delete publish link

SIM Hijack attack

Comments

4 Answers

Comments

Comments

Question tools

Stats

Related questions

SIM Hijack attack

Comments

4 Answers

Comments

Comments

Question tools

Public thread

Stats

Related questions