A new attack uses SMS hijack the phone.
I get this news from the hacker news. I don’t know it’s true or not?
A new attack uses SMS hijack the phone.
From what I remember that was a vulnerability in Android KitKat. Quick fix was disabling auto-retrieve MMS. The actual patch was in Lollipop long ago.
No clue about anything close to it recently on any platform.
This is something new, see https://arstechnica.com/information-technology/2019/09/hackers-are-exploiting-a-platform-agnostic-flaw-to-track-mobile-phone-locations (I’ve only just read about it right now)
In short: yes. It should be possible to mitigate this manually on the base Librem 5 if you have some kind of software which has access to the raw radio messages - and I really do mean manually. You’d need to look for and detect binary SMS messages, the detection software will need some way of distinguishing legitimate from illegitimate messages, and the software needs to then play an extremely loud noise through the ringtone speaker when this happens. At that point, you yank the phone out of your pocket and hit the radio killswitch as fast as you can.
A more elegant solution would be a way of intercepting and filtering messages passed between the SIM card and the modem. This is the main reason why I want many many exposed GPIO pins on the motherboard. I had this idea several months ago that, if such internal connectors were available, of getting some custom-made flexible circuit boards to act as an interposer - wired up such that the modem’s SIM interface is wired to some of the GPIO lines, and that the SIM card is wired to another set. Then you’d need to have some software running on the main CPU which passes the messages along. That way, you could set up a firewall for the SIM card and render yourself immune to crap like this.
I’m assuming this is how that Israeli company was hacking people worldwide for profit.
This seems to be benign issue.
When the article said “hijack” I thought it implied full control of the phone storage. It’s just about location for the most part. And it’s also carrier dependent. I wouldn’t be worried much about this vulnerability. And I don’t doubt that it will be addressed soon and successfully.
What’s more troubling is the “spy towers”, which can fool your phone into fully communicating with it as if it’s your carrier’s. US was caught doing it in Germany and other ally countries years ago and just days ago , FBI caught ISRAEL with planted equipment around the white house.
This stuff is not expensive and can intercept all the calls and data transmission in specific areas
Not just location information (though having the modem and the GPS isolated from one another on the Librem 5 will help us on that aspect), but other details too - such as the IMEI of your phone and, depending on how well the security boundaries inside your SIM card are (not) enforced, some extremely crucial things like the base cryptographic key which uniquely identifies your SIM to the network.
My question would be if those SMS are handled completely by the firmware and the SIM card or if the OS can actually intervene.
Anyhow, it’s weird to realize that the actual vulnerability here is not in the phone, not the OS, not the baseband modem… but in the SIM card
It’s much, much worse than just location data. From the report:
Retrieving a person’s location is one thing, but by using the same technique, and by modifying the attack message, the attacker could instruct the UICC to execute a range of other attacks. This is because using the same method the attacker has access to the complete STK command set, some examples of these STK commands are:
PLAY TONE SEND SHORT MESSAGE SET UP CALL SEND USSD SEND SS PROVIDE LOCAL INFORMATION Location Information, IMEI, Battery, Network, Language, etc POWER OFF CARD RUN AT COMMAND SEND DTMF COMMAND LAUNCH BROWSER OPEN CHANNEL CS BEARER, DATA SERVICE BEARER, LOCAL BEARER, UICC SERVER MODE, etc SEND DATA GET SERVICE INFORMATION SUBMIT MULTIMEDIA MESSAGE GEOGRAPHICAL LOCATION REQUEST
By using these commands in our own tests, we were able to make targeted handsets open up web browsers, ring other phones, send text messages and so on. These attacks could be used to fulfil such purposes as
Mis-information (e.g. by sending SMS/MMS messages with attacker controlled content) Fraud (e.g. by dialling premium rate numbers), Espionage (as well as the location retrieving attack an attacked device it could function as a listening device, by ringing a number), Malware spreading (by forcing a browser to open a web page with malware located on it) Denial of service (e.g by disabling the SIM card) Information retrieval (retrieve other information like language, radio type, battery level etc.)
It even may be possible to go even further - depending on handset type - which we will discuss in our VB2019 presentation. Worryingly, we are not the only people to think of these additional attacks, over the last few weeks and months we have observed the attackers themselves experiment with these different capabilities.
Finally, another benefit of Simjacker from the attacker’s perspective is that many of its attacks seems to work independent of handset types, as the vulnerability is dependent on the software on the UICC and not the device.
It’s worth highlighting according to the Cox of Motherboard that major US telecom (Verizon, ATT, Sprint, Tmobile) are not affected as they don’t use the S@T Browser on their SIM cards.
Nah! It hijacks the SIM card, not the phone! (Muuaaaah, ha, ha, ha, haaaaa!)
So… Ehm… Did anyone already mention the SIM-card kill switches?
well if the sim is not beeing fed ANY power how can it be an issue ?
Some reason compels you to turn on SIM every now and then (you use a SMS messenger that doesn’t support ToIP, etc) Edit: Hopefully Chatty supports ToIP though.
I’m not literate enough on all the commands you shared here.
Where and how does the hacker gains access to to my phone storage/listen in on phone conversation/intercepts messages?
Anyway, all the more reasons to ditch this SMS non sense and standard voice protocols.
Voice Over IP and encrypted messaging is the “future” anyway. Just a matter of time when it becomes a new standard.
They don’t, at least if you’re using a librem5. This attack basically is proof that you can’t trust the cellular modem, even if there are not intentional backdoors put into the modem firmware by the vendors. That’s the whole reason for hooking the modem up over the USB bus and assuming it’s not a trustworthy device.
Basically they use the LAUNCH BROWSER command, to go to a webapge, download and execute a payload that reads storage, messages, turns on microphone, etc. Or they could use SET UP CALL to dial to a recording device, etc.
At least it’s comforting to know that Verizon is not affected
Aye, that’s the core of it. The one attack that looks like it would work on the L5 is the extra charges for ‘premium’ (1-900) numbers. The open-browser command won’t go anywhere, the mic shouldn’t be connected to the modem directly (I plan to route audio through Jack2, and not leave it connected in software when not in use). It can send any AT command, but the L5 can treat those as AT requests, not commands. That does leave the possibility to fake outgoing calls, which could be a problem (either premium calls, or calls to nefarious groups or similar).
That’s already the case AFAIK.
Hard to say… It’s probably disconnected when not in a call, but might auto-connect when a call starts, depends on what audio server (pulseaudio?) is used, and it’s settings. If the auto-connect-on-call is tied to the UI, with the make-call and accept-call commands initiating the connection, we’re good. If it’s connected in response to the AT command by the modem, that should be changed.