Technologies are often created with good intent, to make our life easier, to solve problems in a convenient way. The Management Engine in Intel’s CPUs, for instance, was intended to make the life of admins easier. It allowed for remote access on a very low level, so they could even do complete remote reinstalls of a machine. And if you have to manage a large fleet of machines, distributed within a larger enterprise, this can save huge amounts of effort, time–and thus money.

Implementation details matter

Sadly, many of these technologies that were meant as good are implemented in a way that bears more harm than advantages. The ME, for example, is fully proprietary and closed. It is even undocumented in most parts, so it can not be publicly reviewed and audited. It is a piece of software, software has bugs and so has the ME implementation; the news are full of it lately.

The same is true for something that many mobile phone users are totally unaware of–the SIM Application Toolkit, also called SIM Toolkit, SAT/USAT or STK.

The SIM Application Toolkit

Its name already points to the origin: the SIM card. It is the tiny chip card you insert into your phone, to get access to the cellular network of an operator. The SIM card used to be a fairly simple device, which you can imagine as the key to unlock the access to the network: i.e., it stores a secret (a cryptographic key) along with an ID (the IMSI) and some details about the issuing operator, etc. This data set grants you access to the operator’s network.

But phones [also called handset, or ‘terminal equipment’ (TE), in mobile terms] have become more and more powerful. And setting up these cards has become more and more complicated; you need an SMS center number, details for the MMS server, mailbox dial-in number… and a lot more. All this needs to be properly set up in the mobile, to make full use of both the mobile and the network. To make this even more complicated, these details (and the way to set them up) are different from operator to operator. The process for this initial setup is (also) called provisioning. It was to make this (and other things) as convenient and least painful as possible for users that SAT was invented.

The name SAT tells us not only that it is SIM-related, but also that it contains the term application: SIM cards can, and today they usually do, indeed contain small applications or applets. They are small computers on their own, they run code, and they can indeed be programmed. Most are based on the JavaCard standard and can be programmed with small Java applets. The SAT defines a standard way to interface the SAT applets with the modem and the phone.

Here comes the tricky part

SAT applets can have access to modem traffic, especially to SMS. They can execute on the SIM card–pretty much without any knowledge from the user. SAT applets can even initiate unsolicited communication (e.g. sending SMS) and can get updated and/or changed by the operator, over the air. All this is part of the 3GPP standards. SAT applets can also interact with the user, if the handset implements the user interface parts of SAT with simple menus, limited icon display and reading input from the ‘dial pad’.

SAT applets are an important part of the provisioning by the operators, when new SIM cards get activated. But their implementation details are not public. Their code is not public, and is thus likely to contain security flaws.

The SIM Jacker and the S@T Browser

One of these flaws has just surfaced: it is called SIM Jacker, and it exploits the S@T Browser component, found in many SIM cards. It allows for exposing critical user data, like the currently connected cell tower ID. The cell tower ID can easily be matched against databases, and is pretty much equal to having a geographical position. An attacker would thus be able to locate a user–accurately enough to determine, for example, if someone is at home or not. And it must be assumed that more information about the user can very well be extracted in a similar way.

This is possible when attackers send a specially crafted SMS to a mobile. It is not visible to the user and will initiate, again without the user knowing, an automated response by the mobile. The mobile then sends it back to the attacker, exposing for example what the user cell tower ID is.

Protecting the Librem 5

Purism is actively working with its modem manufacturers in order to protect Librem 5 users from such exploits. We are also investigating how to have a configuration option: how to opt-in to SAT, if you really need it (e.g. for initial provisioning), and disable it again afterwards–in order to avoid any such forms of exploitation.