Monitoring, and hardening-ish IMS

tV0gr

First before I ask I'd like to specify that I have not reached any conclusions and it might be caused by a carrier misconfiguration, weak signal or else. I am curious about figuring out what may be the cause, I see this more as a learning opportunity and as a form of troubleshooting than problem-reporting (at least for now).

I have been getting notifications (beep) every now in then in the same physical location. Without any notification to read. I know that the signal tend to be weak and suspect that I might be roaming, but I have been routinely getting spam call in the past in the same area and disabling 2G reduced that significantly. Looking at statuses and sometimes logs, I can see that my phone carrier has some tower operates in ipv4, while other use ipv6.

Doing some google searches returned post like this one, this one, or that one. Spending the two months reading the nitty-gritty of IMS and all its technical standard would be undesirable as I would likely forget it all shortly thereafter. If this is the only way then so be it. Instead I think it would be a great opportunity to better develop my skills at crunching logs, or getting familiar with tools that can do this efficiently.

I can see in the ImsService logs that the emergency number is being updated, with the proper phone number but with an mcc of null. My limited understanding is that this is happening while it is roaming, and that null mcc might be caused by weak signal or interference for example; not something that I would want to interfere with or disable but I think it can provide some context. Then in the main system logs, I can see a notification_alert with beep=1 which would be the notification I had. Just above that are sysui_multi_cation with a multiple numbers and com.android.phone.

What would be the best way to delve deeper and aim to understand the relationship between the two, is there an easy way to do this (e.g. some database to query) or is cross-matching various logs the way to go? While I might use this as the perfect reason to learn how to use ed and awk, is there any program to recommend that run on linux?

For hardening(-ish), I am wondering what can be customized without potentially causing issues with my phone carrier. It's possible that all my concerns have been quite well addressed and/or mitigated some times ago. Can writing a custom APN prevent some features from being used, or something similar? Any settings that can prevent any roaming tower from overriding settings, if this is even a thing? I'd be ok with missing features while roaming since I am merely in a zone with spotty signals.

If none of that is possible due to the nature of cellular network, any suggestion on how to best monitor IMS?

de0u

tV0gr For hardening(-ish), I am wondering what can be customized without potentially causing issues with my phone carrier.

Hardening against what/whom?

Turning the cellular modem off presumably reduces attack surface like mad, also turning off Wi-Fi calling.

tV0gr

de0u I don't have a specific threat model to rely on. I think the most likely scenario would be someone that want to compromise my device for various nefarious purposes (e.g. attack my employer or a large enterprise unrelated to my work). The second most likely would be side-channel attack, for which its scope seem to be ever expending. Third would be a misconfigured cell tower that could be abused by an attacker to deliver malware. I doubt that I'd be the direct target of an APT any anything similar. But I certainly find the capability of commercial spyware concerning and I find the prospect of it falling in the wrong hands concerning. Yet another tool that could tamper with my devices, nothing more.

The goal with possible hardening would be to protect against potential IMS abuse, or abuse via IMS I might say. Turning the modem off would undoubtedly reduce the attack surface but would be excessive to be done all the times. I certainly do that when those pings happens. Followed by a reboot.

I only had a quick look at those IMS standards I am under the impression that there are complexities in IMS, complexity that I simply don't need. It looks complex enough that I could end up breaking basics features that will be more of an hindrance for my cell provider than increasing my security for example. It might just be the way that this tower is configured; as a precaution I opted to disable roaming data, and automatic network selection.

I good example of a feature that I don't need or want is video call. But yeah, I suspect that more in-depth monitoring might be the way to go. I figured I would ask just in case I missed something obvious or simple.

de0u

tV0gr I only had a quick look at those IMS standards I am under the impression that there are complexities in IMS, complexity that I simply don't need.

Complexity leads to attack surface. My understanding is that most or all IMS implementations are closed-source. This makes it difficult in practice to harden or even inspect the system.

tV0gr Turning the modem off would undoubtedly reduce the attack surface but would be excessive to be done all the times.

If (as is true for many users) having a "regular phone call" presence on a cellular network is important, it is probably also important to acknowledge that this places one into roughly the same risk pool as the other users of the same IMS stack. GrapheneOS deploys a variety of system-wide structural attack mitigations, but IMS probably remains a significant attack surface.

tV0gr I certainly [turn the cellular modem off] when those pings happens. Followed by a reboot.

Though I don't track IMS or other cellular vulnerabilities in any organized way, my sense is that attacks using previous noteworthy vulnerabilities have not been detectable in terms of odd behavior readily observable by the user. Until somebody attempts a detailed analysis of logs from your device it's hard to say what's going on.

Most odd behavior indicates misconfiguration or bugs rather than attacks; whenever possible, an attacker chooses avenues that do not have odd behavior as a side effect. If the only available attack does have observable odd-behavior side effects, attackers are likely to deploy the attack against only high-value targets, not as part of a general fishing expedition.

Overall, it's not clear what you're observing. Meanwhile, it's also not clear there are plausible ways to harden IMS.

tV0gr

de0u Complexity leads to attack surface. My understanding is that most or all IMS implementations are closed-source. This makes it difficult in practice to harden or even inspect the system.

Once I make sense of the available logs I'd be curious to see how much info can be gathered from a userdebug build.

de0u If (as is true for many users) having a "regular phone call" presence on a cellular network is important, it is probably also important to acknowledge that this places one into roughly the same risk pool as the other users of the same IMS stack. GrapheneOS deploys a variety of system-wide structural attack mitigations, but IMS probably remains a significant attack surface.

I needed to read this, something that I should reconsider as my needs evolve.

de0u Though I don't track IMS or other cellular vulnerabilities in any organized way, my sense is that attacks using previous noteworthy vulnerabilities have not been detectable in terms of odd behavior readily observable by the user. Until somebody attempts a detailed analysis of logs from your device it's hard to say what's going on.

Most odd behavior indicates misconfiguration or bugs rather than attacks; whenever possible, an attacker chooses avenues that do not have odd behavior as a side effect. If the only available attack does have observable odd-behavior side effects, attackers are likely to deploy the attack against only high-value targets, not as part of a general fishing expedition.

Then it would most likely be a misconfiguration or bug of some kind. The few logs I saved are unlikely to be sufficient to explain or trace anything for what I can understand. Something I need to improve upon.

de0u Overall, it's not clear what you're observing. Meanwhile, it's also not clear there are plausible ways to harden IMS.

Thank you for the replies.