A New Attack Allows Intercepting Or Blocking Of Every LTE Phone Call And Text (theregister.co.uk) 80
All LTE networks and devices are vulnerable to a new attack demonstrated at the Ruxon security conference in Melbourne. mask.of.sanity shared this article from The Register:
It exploits LTE fall-back mechanisms designed to ensure continuity of phone services in the event of emergency situations that trigger base station overloads... The attacks work through a series of messages sent between malicious base stations spun up by attackers and targeted phones. It results in attackers gaining a man-in-the-middle position from where they can listen to calls or read SMS, or force phones back to 2G GSM networks where only voice and basic data services are available...
[Researcher Wanqiao] Zhang says the attacks are possible because LTE networks allow users to be handed over to underused base stations in the event of natural disasters to ensure connectivity. "You can create a denial of service attack against cellphones by forcing phones into fake networks with no services," Zhang told the conference. "You can make malicious calls and SMS and...eavesdrop on all voice and data traffic."
[Researcher Wanqiao] Zhang says the attacks are possible because LTE networks allow users to be handed over to underused base stations in the event of natural disasters to ensure connectivity. "You can create a denial of service attack against cellphones by forcing phones into fake networks with no services," Zhang told the conference. "You can make malicious calls and SMS and...eavesdrop on all voice and data traffic."
Re: (Score:2)
No industry reach-out and responsible disclosure after the time needed for them to contemplate and execute a change across a 100K+-node base station network?
This is why we can't have nice things.
I disagree. If people would make their shit secure in the first place, it wouldn't be a problem.
Maybe if we had more exposure of 0-day flaws and associated attacks, people would work a little harder to creating flaws to begin with.
Re:Thanks, *hats (Score:5, Insightful)
Ya'see, I'm getting sick and tired of hearing this goddamn argument over and over again. "Just make it secure in the first place", like technical security is just a magical flip of a switch. "Oh, Yeah, I downloaded and installed the SECURE library into my app, things are PERFECT now!"
Security is an ever evolving moving target. What is deemed secure today may very well become insecure tomorrow. This is true of both software and non-software technical systems. This is true of both open and closed source software. This research that happened is EXACTLY what we need to ensure security, having people willing to disclose vulnerabilities to the general masses, because similar exploits may exist in other implementations. The alternative is selling exploits on the black market. Which would you honestly prefer?
Re: Thanks, *hats (Score:3)
Some software can be proven secure. Look at sel4. It's just that software engineers take shortcuts. If you design an aircraft wing you have to prove that it can take the load with math and physics. When we write software we assume it's good enough because we "tested it thoroughly". I guess it's time to start treating software engineering like real engineerings. Hold them accountable and teach them how to prove things secure before they are allowed to use technology. I feel like most software engineering are
Re: (Score:3)
Well, for a lot of uses, slap-dash is "good enough". I don't really need my $30/month prepay service that I use to get phone calls from my wife telling me to pick up laundry detergent to be bulletproof - it just needs to work well enough that I get by another month without getting too pissed off. If they went all space shuttle control software on my phone and the network, it probably would all drift outside of my price range. I suspect for high-security applications, there are already bolt-on solutions that
Re: (Score:2)
In this case, the solution is already available. When a new tower is spun up, to flag it as "unsafe" until a valid tower says otherwise.
I have a good idea where all the towers are in my city, if a new one was spun up, I'd know about it fairly quickly. And there are projects that have very detailed information on existing towers. The problem with this kind of attack, is that it is very short lived because it would be easy to triangulate where the bad tower/Node actually is.
Re: (Score:2)
Come to think of it, I would notice a new tower as well because of my "Llama" app that uses the towers to trigger actions.
But so long as the CIA/NSA/KGB/Verizon or whatever nefarious agency is willing to forward my conversation about milk to the proper wife, I'm good.
Re: (Score:2)
You cannot *prove* security. Security is not a set of absolute laws, it is a subjective call. There are of course some *limited* facets that are more concrete (buffer overruns are never good, for example), but security is a big thing that encompasses a lot and in fact two different approaches can both rationally call each other insecure and themselves secure, depending on perspective.
Re: (Score:1)
Which would you honestly prefer?
And which would the government prefer?
Re: (Score:1)
Re: (Score:2)
Security is an ever evolving moving target. What is deemed secure today may very well become insecure tomorrow.
While I agree with you on this point, you aren't looking far enough at the problem.
The real problem is the number of these devices that never see updates/patches from the vendor. This plays out in two ways. The first being that the vendor never patches anything and the second is while they do, they don't make it simple for the average user to A) find out about the update and B) install it.
The other problem we have is that security is not a selling point for the average user. They pay attention to the bling,
Re: (Score:3)
If only it were that easy. So much of security is a case of people abusing behavior of a complex system. Its difficult to image how some of these complex interactions might be exploited ahead of time.
This is a case where for the most part the system is working as designed. A high amount of traffic is detected so the system pushes the devices to fall back on legacy resources so the system of call handling over all can continue to function. It just so happens the high traffic isn't a bunch of devices all
Re: (Score:2)
I disagree. If people would make their shit secure in the first place, it wouldn't be a problem.
A typical LTE connection will have multiple levels of security including private encrypted identification tokens, security on SIM cards, Air interface protection, and security in the backhaul. This is protected by no less than 7 different cryptographic keys in the process.
But yes the standard was designed without any security in mind. What were these "experts" thinking and why didn't they consult A.Coward here who has the answer to everything.
Re: (Score:2)
I think the point is despite *trying* to design it 'secure it in the first place', there were failures. It's easy to criticize in hindsight, and claim that if they had just secured it *right* in the first place, this wouldn't be a problem, but it is disingenuous to say they didn't even try.
This is the crux of the problem for security. Even if you *try* to do it right, there is every likelihood that you will mess up. Even if you pull in a 'trusted security company' to audit your design, they'll frequently
Re:Thanks, *hats (Score:5, Insightful)
Greek wiretapping case 2004–05
https://en.wikipedia.org/wiki/... [wikipedia.org]–05
SISMI-Telecom scandal
https://en.wikipedia.org/wiki/... [wikipedia.org]
or why "Fake Mobile Phone Towers Operating In The UK"
http://news.sky.com/story/fake... [sky.com]
Re: (Score:1)
On the other hand, corporations don't give two shits about security until it hits them where it hurts, in the pocket book. Without disclosures like this, security is treated as an add-on insurance expense if it's considered at all.
Re: Thanks, *hats (Score:1)
Re:Thanks, *hats (Score:4, Insightful)
Umm...are you sure? I saw this girl talk in Las Vegas a few months ago at Defcon. This isn't new. This is a known exploit.
Re: (Score:3)
It's worse than this. LTE downgrade attacks have been known about for many years. The lack of mitigation against such attacks is also the reasons stingrays work so well. If devices could authenticate the basestation and prevent downgrades to weak encryption schemes like was suggested in ... I think I heard about this personally 3 years ago the first time... then neither stingrays nor this current attack would be an issue.
Re: (Score:2)
No industry reach-out and responsible disclosure after the time needed for them to contemplate and execute a change across a 100K+-node base station network?
This is why we can't have nice things.
Yeah, let's see if we can get back to analog phones, and back to the era when it would cost gobs of cash to call different area codes, let alone different countries
We need END-to-END security. Now. (Score:1)
We need END-to-END security. Now.
Re: (Score:2)
DNSSEC is 1024-bit (Score:2)
DNSSEC is underused because its root certificate is only 1024-bit RSA. At least that's why DANE support in Chrome is turned off.
Re: (Score:2)
One, doing IPSec and DNSSEC does not unambiguously mean 'ok, things are secure now'. In principle, they can be helpful.
IPSec is a big mess that in practice is redundant with using TLS.
Re: (Score:2)
Re: (Score:2)
The key infrastructure as such is not suited for meaningfully secure communication. Opportunistic encryption is trivially overcome by a man in the middle.
I'm seeing a trend here... (Score:1)
So often it seems that falling back to an older, less secure system or protocol is a method to circumvent newer, safer technologies (POODLE springs to mind as an example)...
Shouldn't there be an accepted practice of NOT being backwards compatible with a system that's known to be insecure? Cuz like, what's the point otherwise? At the very least perhaps new systems like TLS or systems that rely on older hash functions could have a scheduled phase-out of backwards compatibility built-right into the spec.
(ok
Technically unfeasible (Score:3)
This attack breaks multiple laws, and regulations.
As noted in another post. The equipment to do this is expensive.
It's not a targeted attack. There's no way to pin an individual, they might just get lucky and get through on the real cell.
Just alarmist ranting, for now.
Re: Technically unfeasible (Score:1)
Just alarmist ranting, for now.
All of which was said about Stingray devices in an attempt to mollify people. How did that work out?
Re: (Score:2)
Just because it's possible, doesn't mean it can be done.
The Stingray devices already exist. Now here's a better blueprint to help amateurs build their own.
People were apparently fine with this security flaw when only a few proprietary hardware vendors were known to be exploiting it. Now, hopefully it can be taken seriously.
Words mean things (Score:2)
"Just because it's possible, doesn't mean it can be done."
Actually, that is exactly what "possible" means.
...force phones back to 2G GSM networks (Score:3, Funny)
So T-Mobile customers shouldn't notice any interruption in service.
Re: (Score:2)
Is this news? (Score:1)
I'm pretty sure I saw this exact same presentation at DEFCON a few months ago.
Re: (Score:2)
I'm pretty sure I saw this exact same presentation at DEFCON a few months ago.
It's not like they hacked in to it, it was a gimme.
FTA "The 3GPP telco body that oversees LTE standards has known about the security shortcomings since at least 2006 when it issued a document describing Zhang’s forced handover attack, and accepts it as a risk. "
Open Whisper Systems (Score:2, Informative)
This is why using Signal is critically important.
Saw it at Defcon (Score:1)
This is not new - it was at Defcon in august.
On the surface (Score:3)
Isn't this pretty much what a Stingray does? Or does Stingray use weaknesses deliberately built into the networks?
Re: (Score:2)
We have no idea. There's very little data at all on how the Stingray actually works. That's one of the big issues with it.
Re: (Score:1)
Turning on a stingray requires active cooperation with the cell provider. So, there is no back door there.
Re: (Score:3)
Re: (Score:2)
What he said!
At one time (design time of LTE network protocols) conceiving of a "rogue" base station was unthinkable... Tens of thousands just to start. Now, SDR allows almost any kind of radio transmitter for next to nothing and the unthinkable become thinkable.
As the good Dr Oppenheimer had to say "Now I am become Death, the destroyer of worlds.".
Thanks "disruptive" technologists... Another instance of "just because you can doesn't mean you should"
Re: (Score:2)
Not even remotely true. A stringray device simply emulates a base station and overpowers it. It does not require any cooperation with any cell provider.
That said it is a different form of attack.
Re: (Score:1)
Stingray uses the simple fact that at least in GSM and 3G networks, the handset needs to authenticate itself to the network (to make sure that everything is properly paid for), but there is absolutely no authentication mechanism for the network, i.e. the cellphone cannot verify that it's actually talking to the real network. In addition to that, at least with GSM, the network can request that data is trasmitted in clear text without even the weak encryption, e.g. for countries where encryption is/was illega
Stringrays (Score:2)
I'd guess this is how the stingray cell phone snooping devices have been working all along.
Now, at least we understand the technical means by how they work.
Re: (Score:2)
Re: (Score:1)
LTE takes after GSM on the insecurity tree (Score:2)
GSM was full of holes and worthless and now its direct descendant LTE has similar holes. WHAT A SURPRISE.
And of course the industry rubbed their hands about the GSM issues and they will do so again about LTE. Everyone has spent too much money on this shit to go back now and fix it.
Apple had some major issues with their early iPhone security because they were of course GSM-only for a long time and any competitor who wanted to listen in on test calls or record everything only needed to setup a GSM eavesdrop
Shit summary (Score:2)
This isn't something that can eavesdrop on LTE calls, it just forces the phone off of LTE back onto older more insecure air interfaces. But it does make sense now why no phone I've ever owned allows me to force LTE-only mode (without resorting to rooting, jailbreaking, or other hacking), they need to make sure the TLAs can backdoor us onto their stingrays at any given moment.
Re: (Score:2)
I'm not talking about 3rd party ROMs like Cyanogenmod. That's why I said it can't be done "without rooting, etc.". Sure I can run a 3rd party ROM but then I lose VoLTE, that's the point.
The last 3 Andoids I've used are VoLTE capable and enabled running stock ROMs, and my last 2 iPhones (6 and 7) are as well (both capable and enabled). Let me select the mode I wish to use and be done with it. All I get as a benefit from allowing legacy air interfaces to be an option is decreased battery life as the phone mon
Re: (Score:2)
I'm not talking about 3rd party ROMs like Cyanogenmod. That's why I said it can't be done "without rooting, etc.". Sure I can run a 3rd party ROM but then I lose VoLTE, that's the point.
The last 3 Andoids I've used are VoLTE capable and enabled running stock ROMs, and my last 2 iPhones (6 and 7) are as well (both capable and enabled). Let me select the mode I wish to use and be done with it. All I get as a benefit from allowing legacy air interfaces to be an option is decreased battery life as the phone monitors a network I have no interest in using (and if I do need/want it, I'll select it manually).
The only reason I want a rooted phone is to add a hosts file, ADB will allow this without the phone being rooted, and any other file (application) you want installed.
A note I keep handy, this is in reference to cell phones: I do believe in Linux systems, the real hosts file is in root/data/data/
>The system/etc/ hosts file is empty, aka a decoy of some sorts....? -XDA-Developers.com