Comment by jeroenhd
8 hours ago
Google has clearly flagged this as "not a security issue", repeatedly. It's a weird bug for sure, but what's the scenario here?
Correct me if I'm wrong, but the carrier configuration messages can normally only come from carriers. The demo APK sends a message to the phone itself, but sending SMS messages requires special confirmation.
Practically speaking, what's the risk?
> The demo APK sends a message to the phone itself
That's not what the readme on the repo says.
"Install on a sender device, enter (or auto-fill from an active SIM) the target number, pick the sending SIM, and tap SEND CRASH SMS. Observe on the target..."
Load apk, select which sim you want to use, enter Android victims phone number, hit send, it will crash telephony app and it’ll restart.. carrier will resend the text message as there was no acknowledgment crashing it again in a loop.
Only “fix” for this attack is to place SIM card in a non-Android phone to ack the inbound messages, or wait a few days of constant disconnects.
Huh, but then it's neither remote nor zero click if you need to locally install malware?
Or did I misunderstand you and can you input any phone number to cause this issue? If so that would sound more like a carrier issue then a android issue to me
> Huh, but then it's neither remote nor zero click if you need to locally install malware?
The software is installed on the _sender_ device.
Huh, Yes victims phone number, bug is in android. Carriers just send messages.
> Practically speaking, what's the risk?
1. Revenge on an ex.
2. Send someone the packet, set up a situation where they need to call 911.
I'm not sure the details but there have been vulnerabilities in the past that involve sending invisible SMSes to people. I believe the usual "text message" is just one format of an SMS, SMS itself is more akin to ICMP with subtypes, and networks don't always filter them.
Even if you are correct on the technical point, it’s still a security issue.
1. A carrier should not be able to render my device unusable in a manner that persists after I remove the SIM.
2. Dual SIM is a thing. One carrier should not be able to disable the other one.
(You do appear to be incorrect on the technical point as well.)
Where does it say that it's carrier configuration? Looking through the page it mentions WAP and PDU, seems PDU from my skimming is just a part of encoding WAP messages, so basically anyone being able to send WAP messages onto the network will have the carrier happily retransmitting it unless carriers starts blocking them/filtering these incorrect ones?
It's not clear, which makes me skeptical that this is all that serious of an issue.
I'd like to know - can any devices actually put such a malformed message onto the carrier network? It probably requires at least a custom app that would never be allowed on an app store, if it's possible at all. And do any carriers actually let it go through their network and to a device like a normal message? It's entirely possible the malformed message would crash some software in the carrier's processing stack first and so never be delivered. And if it doesn't, they could easily add a check to block such messages. It's difficult to believe they don't already have some sort of protection against spamming tons of messages to any device. It's also entirely possible it works differently on different carriers, and some but not others might add blocks for this but not make a press release about it or anything.
This seems more like meh, minor bug, fix it quietly in the next Android release, not OMG the world is on fire to me.
You sound like android triage team.
Apk provided can be installed on an attackers phone, you specify the msisdn (phone number) of victims phone, click send and it crashes telephony app of the victim.
Multiple messages may create a race condition that corrupts an SQLite database that stores message which stops telephony from functioning as a phone. WiFi will still work so I guess you can use it as a tablet as long as you don’t mind the constant dialogs popping up.
Tested in AU, US, DE and UK with 100% success rate.
> can any devices actually put such a malformed message onto the carrier network? It probably requires at least a custom app that would never be allowed on an app store, if it's possible at all.
The author has provided an APK that claims to do just that. Hacking tools aren't allowed on app stores, no, but that has no bearing on the severity of vulnerabilities they exploit.
> And do any carriers actually let it go through their network and to a device like a normal message? It's entirely possible the malformed message would crash some software in the carrier's processing stack first and so never be delivered.
Apparently, unless you're accusing the author of lying.
> And if it doesn't, they could easily add a check to block such messages.
Your ISP could block RDP but that doesn't lessen the severity of RDP vulnerabilities, shift responsibility, or lessen the need for the vendor to respond in any way, that's not how this works.
This is an Android vulnerability and it should be assumed that the carrier is indifferent, actively hostile, cooperating with law enforcement to carry out this attack, or someone might carry out this attack using an IMSI catcher.
> It's difficult to believe they don't already have some sort of protection against spamming tons of messages to any device.
20? I doubt it. Do you think the author is lying?
> It's also entirely possible it works differently on different carriers, and some but not others might add blocks for this
Indeed. What's indefensible is Google's classification that this isn't a security vulnerability.
If the carrier is compromised an attacker could destroy millions of phones and cause humongous economic losses no?
Why would they do that when they could use that access to harvest tons of valuable data?
Bless your heart but the world is full of evil people, my friend.
In a war scenario, Russia would could destroy Ukranian phones for example.
For the lulz.
3 replies →
So you can allways trust the carriers. So then it's maybe a feature.
I don't think carriers can be trusted per se, but if a carrier wants to interrupt your call, they can just kill the connection.
I trust mine not to brick my smartphone on purpose, at least. Especially not using methods that leave traces of what was done.
a bad actor can hack the carrier and brick the phones the same way the fridges were hacked and bricked few weeks ago
perhaps even a rogue employee
3 replies →
The carrier? You mean the company that actually routes and controls the emergency calls and other calls this DDoSes? And routes and controls all your data transfer and owns the cell towers?
How do you make calls without trusting them?
wap-push is a legacy protocol, it predates mms's, android can send it fine, ios just ignores them.
It seems to me that the scenario is that someone spoofing a cell tower can disable your phone practically forever and recovery requires expert interference. Maybe I'm mistaken, though, it's not clear from the description whether a spoofed cell tower would suffice and whether it needs to remain in the vicinity to repeat the attack often enough or whether sending 200 corrupt SMS messages in one go would suffice.