LTE 4G Networks Put Androids At Risk of Overbilling and Phone Number Spoofing

An anonymous reader writes: Carnegie Mellon University's CERT security vulnerabilities database has issued an alert regarding the current status of LTE (Long-Term Evolution) mobile networks, which are plagued by four vulnerabilities that allow attackers to spoof phone numbers, overbill clients, create DoS (Denial of Service) states on the phone and network, and even obtain free data transfers without being charged. The vulnerabilities were discovered by 8 scientists which documented them in their research.

Comments

WAAAAY Overblown!

[wolrahnaes]

Here's a link to a page that actually describes the "vulnerabilities" they found: http://www.kb.cert.org/vuls/id...

All of them only apply to Voice over LTE environments, which are different from traditional mobile phone networks in that the LTE network is purely IP traffic so it's effectively a voice over IP call using standard protocols like SIP the same as an internet-based VoIP service would.

As someone who's been working in VoIP for over a decade I just have to laugh at this crap.

Let's start:

The Android operating system does not have appropriate permissions model for current LTE networks; the CALL_PHONE permission can be overruled with only the INTERNET permission by directly sending SIP/IP packets. A call made in such a manner would not provide any feedback to the user. Continually making such calls may result in overbilling or lead to denial of service.

Translation: A VoIP app doesn't require phone permissions if it's not accessing any of the OS' phone subsystems. No shit, sherlock.

The only way this could result in billing or denial of service is if the carrier was not properly authenticating the SIP traffic and was just assuming that anything from that phone aimed at the right IP address must be a legit call. That's 100% a carrier fault, not any flaw with the system. Do they propose that Android should be specifically watching for SIP traffic and require an app have the phone permission to be able to send it?

Apple reports that iOS is not affected by this issue.

I smell bullshit, but I don't have an iOS device to confirm. I doubt Apple requires that VoIP clients have special permissions over anything else.

Some networks allow two phones to directly establish a session rather than being monitored by a SIP server, thus such communication is not accounted for by the provider. This may be used to either spoof phone numbers or obtain free data usage such as for video calls.

This is carrier logic if I've ever heard it. Using the data service I pay for to send IP traffic (which happens to contain voice or video) directly to another user on the data service they pay for is somehow a vulnerability? Again I'm not sure how this is platform-specific.

Spoofing numbers again would require that the carrier have their network configured in a stupidly open and trusting fashion. None of my customers can spoof numbers unless I allow them to (hint: I don't) and it wasn't rocket science to set things up that way.

Some networks do not properly authenticate every SIP message, allowing spoofing of phone numbers.

Repeating themselves here, while this time acknowledging that it's the network's problem.

Some networks allow a user to attempt to establish multiple SIP sessions simultaneously rather than restricting a user to a single voice session, which may lead to denial of service attacks on the network. An attacker may also use this to establish a peer-to-peer network within the mobile network.

Well at least this time they blame the network from the start. I wouldn't limit users to a single session, that restricts 3/4 way calls, but reasonable limits are good there. Still not sure what would be wrong with endpoints directly contacting each other via the data service they're paying for.

I have no doubt that some carriers' networks are truly insecure enough to allow the spoofing and fraudulent usage described here, but that's entirely down to their own stupidity because none of these things are hard to prevent at the network level, even the ones that aren't actual problems.