Poorly configured cloud technology makes 5G networks worryingly hackable | Hacker News Reader

Poorly configured cloud technology makes 5G networks worryingly hackable

spectrum.ieee.org

89 pointspseudolus48 comments

> The hacks, revealed at the May Contain Hackers 2022 event (a.k.a. MCH2022), were made possible thanks to poorly configured cloud technology, which is playing an increasingly important role in 5G networks

Seems like they just picked “5G” as the most relevant keyword in this sentence to maximize attention. This is clearly a config issue.

Ok, we've added poorly configured cloud technology to the title above. Thanks!

Yes, config issues part of basically every contemporary 5g infra rollout.

> The push toward Open RAN, virtualization, and “cloudifcation” unlocks more choice and functionality for 5G operators. It has also thrust them into the unfamiliar role of system integrator, suddenly responsible for securing the entire supply chain.

I've worked with mobile operators before... most of them don't do any virtualization and cloudification, or any-fication... directly at all. They just buy a whole solution from ericsson/nsn/huawei, and configure it exactly as the vendor tells them to (in most cases, by sitting down and watching the vendor representative do it themselves). Sometimes it even comes in a prebuilt rack, that they just set up and connect and wait for the representative to configure.

Are they hackable? Probably. But telcos being unfamiliar with 'cloud' (which is not true) is not the reason why.

Traditionally, that was the case. However, telcos are now moving toward Open RAN as an alternative to building their RAN networks on purpose-built hardware such as baseband units for 5G, and instead moving to a disaggregated, open radio access network. These ORAN networks are built on containerized platforms, primarily. So, we're moving away from traditional, dedicated NEP hardware to x86 machines running Kubernetes - something a lot more people than 4G/5G phreakers are familiar with.

Yeah, sure, but they don't set up those services themselves, but they buy the whole solution from a vendor, usualy together with hardware provided by the vendor. So they still get a all-in-one solution from eg. NSN or huawei, and the vendor sets up and does the initial configuration for the operator.

(what I wanted to say is, that they don't take an empty server, install some linux on it, install kubernetes, and deploy each service one by one, but they buy it "all-in-one" from the vendor, so if there are security issues, they're usually because the vendor fucked something up)

> “I think the telco industry is very much aware that this can be a big issue,” he says. “It’s critical for survival, so I don’t think it’s taken lightly at all.”

It's always been critical but telco's history of preventing security issues in the design stages doesn't inspire confidence. Wasn't SS7 notoriously insecure for decades? I should probably say "isn't" because I'm still finding articles written in 2022 on the topic. LTE too was called out some years ago IIRC.

i'd recommend to watch the presentation https://media.ccc.de/v/mch2022-273-openran-5g-hacking-just-g... in which it's made clearer, that the telco part wasn't the issue. 5G systems can be operated rather secure, but operators or subcontractors that build these cloud installation have strange ideas about trust and config.

On the topic of 'telcos don't take security seriously', CoryD recently wrote some wise words in https://pluralistic.net/2022/08/12/regulatory-uncapture/#con...

"The public-private surveillance partnership is very old, and it's key to monopolists' strategy. It took 69 years to break up AT&T, because every time trustbusters came close, America's cops and spies and military would spring into action, insisting that the Bell System was America's "national champion," needed to defend it from foreign enemies. The Pentagon rescued Ma Bell from breakup in the 50s by claiming that the Korean War couldn't be won without AT&T's help"

I know some people in designing 5G, that were rather frustrated by outside influence on "can we have another unsafe option also, just in case we need it?"

I think the researcher is very much aware of these dynamics, so if he says they are doing something this time, I'm inclined he has reasons to believe that. Karsten Nohl was involved with and gave a number of talks on SS7 hacks over the years:

https://media.ccc.de/v/camp2015-6785-advanced_interconnect_a...

https://media.ccc.de/v/31c3_-_6122_-_en_-_saal_1_-_201412271...

You don't need to go as far as govt. conspiring for telcos to be insecure (note: I'm not challenging that).

Your average telco:

1 - Is just a commodity dumb pipe with a shitty margin and no honest way of getting more money from customers.

2 - Outsources almost all engineering work to Nokia, Huawei, Cisco, etc...and smaller contractors.

A consequence of (2) is that most have no strong engineering or long term thinking culture. I can guarantee you most telcos around the world don`t have basic security shit like having a password manager for router secrets solved correctly.

Yes, I personally agree with you. I worked a bit for one of those many years ago, and I'd say ignorance of security concepts were the biggest risks for security.

> Wasn't SS7 notoriously insecure for decades?

Are you implying that someone has recently fixed SS7? Last I checked it was as vulnerable as ever, and is still basically at the core of all global telecom.

Wasn't implying that. I have only passing knowledge of the tech nowadays but knew it better many years ago. I wasn't certain whether SS7 is even used nowadays or it's obsolete, hence the subsequent sentence. I'm actually shocked it's still used and still as vulnerable!

Last I dealt with it SS7 is worse than ever.

When SS7 was designed and first implemented the assumption was it would be a physically closed off network run by telecom clergy. It was usually implemented between licensed ILECs and CLECs on dedicated physical data links (from what I remember an ISDN data channel). In addition to the physical requirements there was a lot of regulatory (licensing) and legal (contracts) work required to begin to get access in the first place. Even getting your hands on the hardware and software that implemented SS7 wasn't an easy task and was gated a variety of ways (principally cost).

Once you jumped through all of these hoops you were provided with an SS7 circuit that's essentially wide open to the entire telecom network with no security whatsoever. As deregulation pushed further and further it was realized that unscrupulous ILECs and CLECs would often look the other way on bad behavior as long as you kept paying your bills but at this point it was already too late.

Interesting because the impetus for SS7 in the first place was to completely separate call control and signaling from the end user accessible data (voice) portions of the network. This came out of the issues with prior inband signaling systems and their vulnerability to tools used by the "phreaking" community such as the blue box[0].

SS7 over IP and various API driven cloud providers, etc have resulted in essentially opening up access to what was once a closed and sacred network to anyone with a few dollars and an internet connection. Meanwhile the SS7 network on the other side of these gateways has been left essentially defenseless.

[0] - https://en.wikipedia.org/wiki/Blue_box

Thanks for the insight! And that's just plain scary.

All mobile networks should be assumed hacked, the data is too valuable to not be a target of highly sophisticated hackers, especially nation states. Infrastructure layer can’t be trusted and everything should be encrypted on top of it.

The metadata of who and where I am can't be encrypted away, unfortunately, it's available on the physical layer and obviously unavoidably a target of hacks.

Both informations are abstract identifiers and are decoded in a database to 'real' values only, PHY doesn't care about your decrypted ID. If the operator keeps that database closed, a reasonable privacy of who and where can be done.

> If the operator keeps that database closed

Serious question, how much would you stake on that happening?

Serious answer: I have seen operators taking this serious. It's also a european trend not to blindly accept law enforcement requests to open data anymore.

For US companies: read something on the recent twitter example.

No, you have not understood. I'm not asking your opinion about seriousness.

I'm asking how much. So far you've shown a willingness to stake absolutely nothing, which is fair. Is that your response?

If not, how much?

i still don't understand. Should i put a bet (like €50), i can find an operator that closes such databases, or that you find an operator that doesn't?

I'm part of the mobile communication industry (while being in research) and part of my job is interacting with operators.

It's one thing to say "Oh yes, it's taken very seriously" when you have nothing riding on it.

It's another to pledge you will donate $100,000 to the FSF or whatever if data gets out in the next 5 years.

The first is worth nothing. The second claim is possible to have some weight.

The stuff gonna get hacked and we both know it. Why pretend otherwise?

Yeah, so I can blend into that huge crowd of people who both (a) sleep in the same bedroom as me and (b) work at the same office as me.

Great anonymity set you've got there.

So you have ID41323 and ID53242 over night (or at daytime) in the same location, how do you map this back to names?

It's not impossible, but you need data that exists (like house-to-name mapping) from databases outside of the reach of the operators.

And the location information in the network is only as precise as needed. Most of the time this is a cell area, so 100s of m2.

Your assumption is that a phone must present a permanent identifier to the network on the physical layer but I don't think that is true. You could have temporary identifiers instead. If you have multiple concurrent ones and stagger their renewals, and proxy all traffic over tor then it seems like goal would be accomplished.

You just explained the TMSI - something that was used since GSM networks in the early 90s

Good guess, but tmsi is to protect you from eavesdroppers, not from the mobile tower.

Well, you're invited to join research on network ... because it's impossible to hide your ID from your access network. Tor and similar can hide your ID in transport, but that's no option in RAN.

Well, the operator has to be able to link that temporary physical layer ID to some permanent billing ID, otherwise they will refuse your connection to their network.

I can see two ways around it. If you have a free data/calls/texts, you could use a zero knowledge proof of having a free-data secret. If you have pay-as-you-go you could spend tokens each of which are unique and anonymous.

Edit: I think the first approach may not work, as the secret could be duplicated..

That's something which requires cooperation from the operator, and they have zero interest in it at best, and more likely a strong negative interest on allowing anonymous devices on their phone network, in some countries even a legal prohibition to do so.

Actually in 5G network there is almost nothing that isn't encrypted. What Karsten decribes is that cloud installations very often trust the infrastructure, but that's no special 5G problem.

If you're not doing the encryption, it isn't being done to solve your problems, it's being done to solve someone else's. That's not a bad thing and it may still help you on the net, but if you want to protect your own interests fully you need to be doing the encryption yourself.

"Doing the encryption yourself" doesn't mean you have to write the code personally... HTTPS in the browser (assuming correct implementation) counts as "doing it yourself" for this purpose. You just can't count on the infrastructure alone to do it for you.

I agree. I've experience with CDR data, and I've never worked for a telco

I'm no 5G expert or network expert either. My understanding of all this should be considered n00b level.

From the article:

>His team found it was worryingly easy to move deeper into the networks they tested, thanks primarily to poorly configured “containers.” These are self-contained packages of software that bundle up an application and everything needed to run it—code, software libraries, and configuration files—so that it can be run on any hardware. Containers are a critical part of the cloud, because they allow different applications from different companies or departments to run alongside one another on the same servers. Containers are supposed to be isolated from one another, but if they are poorly configured it’s possible to break out and gain access to other containers or even to take control of the host system. In multiple instances Nohl and his team found misconfigured containers that allowed them to do just this.

This looks like a big problem to me since unsecured or poorly secured cloud data is increasingly a fat target for bad actors.

Can't you just point your installs to multiple containers with the actual useful container being tagged with one encrypted key and the other(s) poisoned with trojans, worms, crypto-jackers, bitcoin miners, etc to throw it back in their faces?

Alright, I'm dumb about this. I know it wouldn't work or they would do something similar. It would be funny though to send a pack of problems their way every time they messed with your system.

I just got my first 5G capable phone last week. Just in time for the fun stuff.

> His team found it was worryingly easy to move deeper into the networks they tested, thanks primarily to poorly configured “containers.”

This has nothing to do with 5G. What a weird article.

It shocked some managers in telco, something we consider a good thing ...

Telco vendors have been using Openstack for 6-8 years already, and virtualization (and even containerisation, mainly with LXC, or Solaris zones earlier) was a thing back then. Kubernetes is also used for the last couple of years, mainly inside their VNF-s, so the transition to CNF-s is not a "sudden" thing, most modern VNF-s were running a Kubernetes cluster inside virtual machines already.

All the hassle to keep Huawei hardware out and then the botched the software part in the cloud.

I loved the talk:

https://media.ccc.de/v/mch2022-273-openran-5g-hacking-just-g...

Inspirational.

What about banks that run 'containers'.

Serious note.. many containers are not production-ready. They're made for ease of use... no passwords, listen on all addresses, etc. Like mysql and mongodb in the early days

Not sure why this is relevant, but here goes: I was working on a greenfield project where containers were at the core of it. The amount of due dilligence that was happening was great. Containers were scanned. Configuration was sanity checked. Generally security standards were pretty high. Surprisingly there were very few security folks who didn't know what they were talking about. Contrary to other banks I've been at who don't run on containers.

Comparing that with a neobank that runs K8s, successfully might I add, who has outdated software, and only recently started investigating upgraded.

The same configuration issues you mention has nothing to do with containers, as doing an apt-get install often has the same issues. It has everything to do with people using tools they have little understanding of. I'm talking about mysql, and mongodb, not docker.

You used containers you built yourselves though, right? As opposed to generic ones, eg from Docker Hub?

Probably they built their containers, wrote the containerisation sysstem, wrote all the libraries they were using, wrote the operating system, the CPU microcode, designed and built all hardware parts they were using.

You're missing the point. The official docker containers can be configured secure or insecure. Same with in house built containers. Same with installing an application via apt/yum/pacman/what-have-you.

You’re missing the point. That flag doesn’t matter; what does matter is whether the team understood what’s happening inside the container, or didn’t.

Reply on news.ycombinator.com