> 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.
> 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.
"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?"
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.
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!
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.
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:
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.
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.
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.
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.
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.
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.
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.
Readit News
Seems like they just picked “5G” as the most relevant keyword in this sentence to maximize attention. This is clearly a config issue.
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.
(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)
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.
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?"
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
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.
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.
https://media.ccc.de/v/camp2015-6785-advanced_interconnect_a...
https://media.ccc.de/v/31c3_-_6122_-_en_-_saal_1_-_201412271...
"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.
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.
This has nothing to do with 5G. What a weird article.