The SIM Application Toolkit is fairly low-level, so has access to a few other functions, like making calls or opening applications or updating firmware. Whether these functions are permitted by the phone depends on the manufacturer, but they claim that the Cell ID & IMEI functions are widely-supported.
A better title IMHO; SIM Vulnerability leads to information disclosure via malicious SMS.
> 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 REQUESTEdit: The following is incorrect. SIM cards are self-contained computers. Among other things, they're responsible for encrypting and decrypting communications between your phone and your carrier. This means that a SIM card will see the contents of a message before your OS or other hardware in your phone does. These exploits should work just as well against "dumb" phones as smartphones because they're not attacking the actual phones.
This API exists because SIM cards are self-contained computers; they need a way to communicate with everything else.
I explain to my clients when they express astonishment at my low-tech phone that I am protecting their security, as I have the PDA sync with my Exchange Server, where I keep sensitive info to provide them support and I do not allow the low-tech phone to access my Exchange Server.
I also tell them that I had based my decision on the track records of Google, Apple, Verizon, etc. in regards to security.
Nothing is perfect, but at least my attack surface is lessened.
It still calls home, it's still online. Lock down Microsoft and Google's IPs permanently, outbound, on all networks you use or this won't work.
Google is not involved, my DNS is my own server with the base servers as their lookups, not Google DNS. My PDA only connects over WiFi, since there is no SIM.
So unless Google is purposely getting involved with a WiFi connection to a local, private server, they are not involved, either.
I stripped off all of the other apps as well.
I’ve also heard that Apple doesn’t allow the baseband direct access to the application processor’s memory, but I don’t know how true that is. There doesn’t seem to be much thought given to this on Android phones.
The scarier they can make it, the more $$ ... they even have the domain name.
1 or 2 binary sms sent and you have someones phone depending on your flavor of attack.
sim card runs java. with sim pin you can even just send apdu requests to read its filesystem...
don't know why now all of a sudden this is a hot topic. it's the whole design of the mobile infrastructure to be able to do this...
just think about it: if you clone someones phone via such method, and they get called, you get called. if you then pickup within ~1 second of them picking up, your speaker is enabled but microphone is disabled so they can't hear you snooping in on them.... that is by design.
between carriers everything is unauthenticated, to enable this at global scale... by design.
* Read Memory
> On two different phones it was possible to read out (part of) the phone memory. The most interesting of these phones was the Nokia 2600, where a text message would get stored that shows a seemingly random part of the phone memory upon opening. Closing and reopening of the same message would display a different part of the memory, sometimes also causing a reboot of the phone.
> On the Samsung SGH-D500 certain messages would show a strange sequence of characters when opened, but it was unclear to us where it came from. The same message would show up differently when sent multiple times, so we expect it came somewhere from memory.
* Reboot
> Seven of the sixteen phones could be forced to reboot remotely. When rebooting the network connection would be lost temporarily.
> In all but two cases reboots were caused by a discrepancy between a length field and the actual length of that field in the message, making it likely that the behaviour is caused by a buffer overflow.
* Long time DoS
> For the iPhone 4 and HTC Legend the attack with the highest impact was found. By sending a carefully crafted SMS message the phone would not display anything and also stop receiving any SMS messages altogether. In addition on the iPhone it was impossible to change network after the attack.
* Icons
> SMS offers the ability to notify a user that a voice, fax or email message is waiting to be retrieved. According to the specifications every cell phone has to show an icon on the screen when this happens. Problem is that these icons are hard to remove when they were activated illegitimately. Even though this is not an actual security risk it can be quite annoying.
(lol!)
* Unable to delete messages
> A rather annoying bug manifested itself on two cell phones, the Sony Ericsson T630 and Samsung SGH-D500. [...] They could not be viewed or deleted in any way, but they still occupied space on the SIM. The only way to delete these messages was to put the SIM in a different phone and delete them there.
> Problems like these can be quite dangerous.
Nowadays, it's an extremely dangerous problem in the age of smartphones, when the baseband processor contains proprietary, unauditable code, with no isolation between the baseband processor and the main system.
This happened to me. Any experiences or thoughts? Is it worth the risk? How do you prevent this scenario besides not using 2FA from happening? Personally I would choose to not use it though.
I used to have Ting for phone service, you can require mfa/lock number porting, disable or activate or change a device/sim, toggle voice sms and data and forward calls from their multi factor authenticated dashboard. Requested an extra sim and kept a dumb cdma phone lying around in case I broke lost or someone stole my phone. Also used an app to sync texts in case of broken scren. Now I use verizon and keep a spare cdma device, you can change devices from their web portal in combination with a message syncing app. You could also port your # to google voice for similar features but I assumed google will scrap it with little notice so I have not.
This way, the company using SMS 2FA has effectively outsourced this recovery path to the phone companies. Instead of handling recovery (and potentially liability for getting it wrong) themselves, they can just tell you to go recover the phone number. And when the phone company gets it wrong, you get stuck in a nightmare of finger-pointing instead of having a clear culprit to hold responsible.
Nah, you just have to wait till you order a new SIM from your carrier.
Some companies also offer offline, 1 time passwords. 2FA SMS can be a pain in such cases, but it's not that bad.
There’s barely any connection between the baseband processor and the application processor on a smartphone.
Notice for all your examples, it’s denial of service for the functions of the baseband processor by a bug in the code run by the baseband processor. It doesn’t get access to the data available to the application processor. Except for the oldschool feature phones, where there is no separate application processor so a bug in the software run by its processor can cause the phone to reboot or reveal the memory accessible by that processor.
Some attacks: https://www.fsf.org/blogs/community/replicant-developers-fin...
But from what I gathered from cursory search, RUN AT COMMAND isn't supported by most devices. (ETSI TS 102 223 states "This clause applies if class "b" is supported by the terminal and enabled by the subscriber through the terminal. ")
I have run my own Exchange Server(s) since 1995. And DNS, DHCP, etc.
(I'm talking about win CE and symbian phones being early smartphones here)
If your computer runs a backdoor that grants access to anyone who can access it over the network, the problem that someone from China can now control your computer is not the fault of the Internet. It’s the fault of that program.
And also ‘most of phones’ in the article is ‘Android phones’ and then it’s watered down even more to ‘Samsung Galaxy phones’. ‘In most devices, for all we know, [...]’. No.