Some of you might have noticed the articles, or the leaked manual itself, about a tool called ULIN. ULIN is a “bleeding-edge spy tool” for mobile communication networks. According to the manual, it is aimed to be a surveillance software for agencies (or others with enough money) for tracking and intercepting the Voice Calls and SMS of arbitrary phones. They call this “remote recording and geolocation of mobile handsets using 2G/3G/4G networks”.
Technically, the tool is based on access to the SS7 network, which is used for interconnection of mobile providers. How the services are implemented is not described, but there are some indications on how this could work.
Assuming that the tool is not based on completely unknown vulnerabilities, the interception seem to use well-known SS7 features/vulnerabilities as described previously.
The insecurity of SS7 is well known, but still, providers have their problems in finding mitigating controls not affecting operations.
Avoiding being observed by such a tool as a normal customer is really not possible, as you only can use end-to-end encryption via 3rd party applications.
Does LTE help?
Let’s come to the chapter on how to avoid being observed by this tool. Unfortunately, there is not much you can do as a customer. It is the provider who has to take action. Using LTE could help because it is using DIAMETER/IPX instead of SS7; but this is not really working in practice because of a fallback from DIAMETER to SS7. And of course, even if using DIAMETER only network, there are similar functionalities in place which can be abused by the attacker. If this is supported by ULIN is not clear yet.
What operators can do
There is a great paper from SANS describing mitigating controls for an operator. The paper describes various attacks and is breaking it down to a couple of SS7 messages. These messages should be blocked and are split up into three categories:
- Category 1: Messages that have no legitimate use case for external exposures.
- Category 2: Messages that have no legitimate need to be exposed externally for the operator’s own subscribers, but can be received for other operator’s roaming subscribers.
- Category 3: Messages that have legitimate need for external exposure
Because there is no need for such messages from an external connection, the first category can be blocked in any case if coming from external sources. Categories 2 and 3 need some more effort to identify if they are malicious or not. To distinguish between internal and external subscribers sounds easy, but may require additional technical features/equipment. The identification of malicious messages in category 3 definitely requires additional equipment and interworking with other operators.
Anyhow, here are the messages, including the category which might be used by ULIN:
| Call Interception | ||
|---|---|---|
| Message | Description | Category |
| insertSubscriberData | Re-writing the outbound dialed number | 2 |
| registerSS | configure call-forwarding service | 3 |
| SMS Interception | ||
|---|---|---|
| Message | Description | Category |
| updateLocation | Claim that the victims MS is connected to a different MSC | 3 |
| Geolocation | ||
|---|---|---|
| Message | Description | Category |
| provideSubscriberInfo | Sending back the current CellID | 2 |
| provideSubscriberLocation | Same as above | 1 |
As you can see, most of the messages are classified as category 2 or higher and therefore will not be blocked by a lot of operators.
It is well known what to do and there is equipment on the market to implement these controls. One example could also be GSMK Oversight, which is an IDS for SS7 networks. Such tools can easily detect such attacks/surveillance software because of a wrong matching of IMSI and Global Title.
Many operators are working on implementing these controls but still, it takes time and requires a dialogue between all involved parties (which is even harder 😉 ).
Best,
Hendrik