 5G hacking just got a lot more interesting by Karsten Nol. So 5G has seen quite some evolutions, at least through telecom, through every of the generations, the 2G, 3G, 4G, and now 5G. And it's changing from an old-school monolithical system to a very open model. And openness and open models is something that we dearly love, at least I do. And now the hacking potential and a lot more interfaces are coming about, and we can actually have some quite new interactions with this. And I know that from myself, from a previous employer, being a telecom company, that it's very interesting to listen here and also see the new technology emerge. Now Karsten Nol, we know from all kinds of CCC talks, cool ones even. And every talk here was actually cool. I call it education to myself. And as a security researcher and cryptographer, he's now also the chief scientist for SR Labs in Berlin. And take it away, please a big applause for Karsten Nol. Thank you. And thanks for entertaining everyone for 10 minutes. I've never seen a Herald work harder. Good to see you all again. Three years of everybody staying at home, hacking on their own things, it's about time to start sharing knowledge again. That's what I'm here for today. We'll be talking about hacking in and taking down critical infrastructure. The irony that this talk was delayed by 10 minutes by the electricity going down isn't lost on me. We'll make the best out of the remaining time. We're talking about OpenRAN today as a case study, basically, of technology developments that are happening in basically every industry. People are going into the cloud. They have virtualizing things. Processes get more and more automated. And nowhere is that shift clearer than in the telco industry. And OpenRAN is a great example of that. So we'll be touching on a lot of technology that you encounter in your industries as well. I'm just particularly fond of telco hacking. So at the end of this presentation, you'll know what OpenRAN is. And the technology is involved around virtualization and automation. You'll know how to find security issues in them. And if you happen to be in the business of building telco networks, or for that matter, any kind of cloud network, you'll take away some advice on how to make those infrastructures more secure. Why am I talking about this? Well, I've experienced telco, basically, from both sides. I've been a hacker of critical infrastructures for well over a decade now. And around halfway through that journey, I've been asked to help secure telco networks. So I've seen both the attacking and the defending side of it. And I can tell you, while hacking telco networks might seem difficult sometimes, defending them is even harder. So if you're up for a challenge, try that sometime. But why anyway are we still talking about telco security? It's been literally 13 years since I was standing here and trying to get all of you to help me compute A51 rainbow tables. Anybody remember that? OK, yeah. That's exactly 13 years ago, this conference. And then you all came together, and we computed those tables. We then released them that year in December at the Chaos Congress. And ever since then, people know that 2G is insecure. And nobody has ever found similar weaknesses in the other protocols. So are we done when we done 13 years ago? Well, it turns out telco networks are more complex than just singular standards, right? The reality is always more complex than the standards written in theory. But let's start at the positives. Let's see what has actually happened in telco network evolution. So with the introduction of 5G, pretty much all the hacking vectors that were identified in previous generations were closed. And not just hacking vectors, also privacy features were added. For instance, 5G is the first standard where the IMSI, basically your identity, isn't submitted in clear text over the air anymore. So it took almost 30 years of network standardization for people to understand that it's a better idea to send identities in clear text. It will probably take another 30 years for all non-5G networks to die out and for us to finally benefit from this progress. But it's a step in the right direction. And there's many others. I won't go into the details here because, of course, you all are only interested in how networks are broken, not how they have been fixed. But overall, of course, we have made good progress. Or the people writing these standards, I should say, have made good progress so that today we can just stick up an antenna and intercept a 5G conversation like we did 13 years ago at the Chaos Congress against 2G. But even though these network generations have gotten more and more secure on paper, we anyway or other researchers have been able to find vulnerabilities in each of those standards, usually digging a little bit deeper, going to less obvious places. And we want to continue that today with 5G and, again, using OpenRAN as a case study. What I'll show you now over the next 20, 25 minutes have the building blocks towards 4 Hex that I'll illustrate. Spying on people's communication, extracting their private data from a mobile network, becoming an admin in that mobile network, controlling all the infrastructure, and ultimately taking down a mobile network. These are not single Hex anymore, like what we discussed, let's say, around 2G, but rather serious of building blocks. So I'll have to do a little bit of a build up to what's that. They are also not easily done within less than one minute for the 2G stuff. We're talking about weeks here, weeks of somebody penetrating a network and moving deeper and deeper and deeper until they can finally take down a network. But I'm sure you can imagine many organizations that would be willing to spend several weeks to then either ransom somebody or do other criminal activities for purely strategic purposes. We're talking state-sponsored actors. So it takes weeks to break into a 5G network. And while that might seem like a long time compared to what hackers usually show at conferences like this, it's definitely worthwhile for too many people in the world for this to be ignored. So why are networks still vulnerable? Of course, they are built from many different technologies, some of them newer, like let's say the 5G standards, some of them older, but still mandatory. If you're building a 5G network from scratch today, you would still have to connect it to an ancient technology called SS7, for instance. Won't be talking much about SS7 today, but there's, of course, previous research from years ago that still today applies to virtually all networks in the world because of the network effect. If you want to be part of this global community, if you want to exchange text messages, if you want to support global roaming, you have to support SS7. Maybe a little bit more. Avangardia supporting diameter, well, tough luck. It has the same security vulnerabilities. So mobile networks are just complex beasts. And today, we're going to talk about none of this stuff, but look one level below to the IT infrastructure. Every telco network, of course, needs to be built on something, right? It's not just software. And this used to be proprietary boxes that you would source from some Scandinavian vendor, or let's say from China. Then with 4G, this moved all onto Linux. Everything became IP in mobile networks. So it already felt a lot more familiar to a pentester or a red team testing mobile networks. And with 5G now, we're going even further down to basically cloudify these networks. And today, we're going to talk about exactly that development, where networks become much more virtualized and much more automated. So all the hacking I'll be talking about today is going to be from the IT domain that mobile networks are built on, right? Very important. We're not going to mess with any of these standards because they're not the weakest link of mobile networks anymore, as far as I can tell, OK? A bit of nomenclature to get that out of the way. So today, we're talking about open-ran. What's open-ran? First of all, ran. What's ran? Radio access network is one of three parts that make up a mobile network. Just the radio access network, which is basically 90% of the mobile network, actually. It's the antenna. It's a cable that connects the antenna to some local switching center, another cable to something more regional, another cable to connect us to a big central data center. And that central data center is then considered the network core. So that's separate. And then different network cores are connected through interconnect, for instance, to connect different companies or different countries, right? But almost everything that you consider as a mobile network is the radio access network part, basically the country-wide infrastructure, right? And even though it's 90% of a mobile network, at least, it hasn't received much attention. So I certainly haven't looked at anything ran related since 13 years ago, the 2G stuff, because I considered it's secure, and it's basically just cables, right? And that was true for most of these 13 years, up until now. With 5G and OpenRAN, there's big changes underway, where the radio access network gets a lot, I guess people call it, smarter, right? So a lot more complex. There's much more technology put into the ran. And that's why, after many years of neglecting it, we revisited it and found really interesting stuff, right? So that's ran. So what is OpenRAN? OpenRAN is basically a movement, you could say, loosely defined as combining three things, only two of which are really relevant for our discussion today. The third thing is that mobile networks are now built on commodity hardware to make them cheaper, right? So instead of getting a box from Scandinavia or China that combines hardware and software, you get your own hardware, and then you put whatever vendor software on it, right? Not so relevant for us. What's more relevant for the security discussion is that everything is virtualized, or I guess containerized is the more appropriate term. We're talking Kubernetes here most of the time. And processes are automated to a very high, in fact, scary degree, right? So that's OpenRAN. Basically, these three things put together, and it's extremely popular among telcos right now, because it's cheaper. The commodity hardware part is what they find interesting. Of course, we find the other two a lot more interesting. So in summary, the changes between kind of how mobile networks used to be built and how they're being built right now. A mobile network used to be built. Okay, you start with an antenna. That part hasn't changed. The future will still have antennas in mobile network. Just everything after that changes. So it used to be you connect this antenna to one of those proprietary boxes, appliances, you could say, that you get from, let's say, Scandinavia. And you connect them throughout the entire country. Somebody manually locks into each of these boxes, configures them, and then basically you have your network that will stay virtually the same for the next, say, 15 to 20 years, until it's replaced by another network generation, right? There's sometimes upgrades that the vendor will ship to you, maybe once a year, at most twice a year. And then you manually install these upgrades on each of the boxes and that's it. It's very static networks with very little interference, right? Now switch over to OpenRAN or really any future mobile network, I would imagine. Instead of getting appliances, again, shipments of software, and you have to install them in your own cloud environment. And it's not gonna be just a few cloud environments. Because of 5G's latency requirements, there'll be, in a country like Germany, several hundred data centers, okay? So in several hundred places, you install Kubernetes clouds, and then on each of those Kubernetes clouds, you have to put dozens of Docker containers, right? Just the complexity of that, the sheer numbers involved, do not allow for anybody to do this manually one by one anymore, right? It needs to be automated to hold deployment. And once it's automated, people think of this as a great benefit, because now we can keep changing the network pretty dynamically. So instead of having people lock into boxes once a year and changing a little bit, now you have scripts running all the time that try to optimize the network, that keep reconfiguring everything. So it's kind of a living organism, almost style network, that is self-optimizing. And to me, that's very scary, right? Knowing that it continuously changes. How are you gonna test it and say, okay, for the next few years, I know it's secure? I mean, you test it and even five minutes later, it has a different state. So security testing becomes a lot more complex, right? Now, maybe silver lining, at least we remove the human error source from operations, right? If everything is software, nobody can fat finger or get fished anymore. But of course, we introduced another, maybe more serious human error source in that many developers are now involved. That through some magical CI CD pipelines, create and push down these scripts. And that's what we wanna focus on today. These two developments, that everything gets virtualized and that everything gets automated, okay? And again, I'm using this as a case study to illustrate developments that you encounter in other industries as well, just nowhere else as quickly as a step function as in the Telco industry, right? Of course, any kind of cloud environment would be built similarly. So let's start with virtualization hacking, or again, to be more specific, containerization hacking. I'm not talking about VMware virtual machines, I'm talking about very scalable cloud scale virtualization. And as I said, Telcos have several hundred clouds distributed throughout the country to host all kinds of functionality. And in theory, because all of everything is virtualized, you actually have a possible security upside. Because once everything is, the software is virtualized, it's nicely segregated, the networks become software defined. So you can basically, through configuration settings, create any kind of segregation that you want on the network level, on the hardware level. Most deployments that we have seen do not make much use of this very fine-grained configurability, and in fact, go the opposite way, creating new areas in which devices share resources, right? And in mobile networks, of course, availability is very important. You need your network to be up, right? And if you have different functional components, share the same hardware, if one of them overloads the system, so to speak, the others can suffer as well, right? So with virtualization, the jury is a little bit out. Is this a security gain or loss? But certainly, if you configure it badly, it's definitely a loss. And now we're gonna look at the cases in which we find these environments to be badly configured. So the assumption is that there are different pieces of software all running in the same cloud, right? Could be an Amazon cloud, could be Google cloud, or in our case, a Telco cloud, and some of them are trusted and really secure and very critical. Other ones are maybe test instance, somebody trying something out, something unimportant, different security levels, okay? Now, the big question is, if something less secure gets hacked, can a hacker break out of that environment and influence something more secure? So can I either hack the Kubernetes underneath or influence some neighboring Docker containers? And it turns out that there's multiple paths for doing this kind of container breakout. And here I'm listing the ones that we find most commonly in Telco environments, right? There's probably other ones, but these are the ones that we encounter and actual assessments. So the way to read this is, on the left you have a property capability basically that you can assign to a Kubernetes as a pot or Docker container. And the dark red ones are the ones that we find all the time. They're kind of pseudo defaults, not really defaults where people love to set those settings. And then the lighter shaded ones, we don't find them quite as often, but still enough to be concerned, right? And so you start from one of these capabilities. The middle then says how the hacker would abuse it. On the right-hand side says the outcome. Could be in a mobile network, anything from running your own code, kind of crypto-minor style. It's probably the least concern to accessing data. So ransomware, of course, would be a relevant threat here. To ultimately, this is certainly the worst for mobile networks taking down the systems, right? Basically disconnecting people from their critical infrastructure. And just to take the first two, perhaps as an example. So if those capabilities are set, how does a hacker do this? So the first two here, privilege container and susetment. So if ISO of those capabilities are assigned to the Docker container, that basically means that from inside the Docker, you can communicate with the Linux kernel of the host machine, right? In less constrained ways than a non-privileged container. And I mean, the Linux hackers in the room, of course, already have a hundred ideas how to abuse this, right? And it's a long list. I'll just give you two examples here. You can abuse a kernel feature around C-groups. C-groups is basically a way to handle processes. You don't have to use it. It's just easier if you execute multiple processes, basically, as one batch. Kubernetes definitely uses this. So if you're inside a Docker container on Kubernetes, you know that the host machine uses C-groups, right? That's important to know. And basically there's a kernel feature where you can tell the kernel, please let me know when a C-group completes. And I wanna execute a little bit of code at the end, right? With root-level permissions. And basically, you see it here. This is basically a PS with root privileges. You can execute any code you want, right? So you just notify the kernel to please execute this snipplet of code at the end of a C-group and you basically have root-level access, right? Very straightforward. And yeah, no surprise, right? However, people don't think about it like this when their sign is privileged to attribute to their containers most of the time. Another way is if you have access to the host PID namespace. Again, that's given if either of those properties is set. You can basically just enter the part of the namespace that gives it the equivalent to root shell, right? So really very straightforward exploits. And these are just two of the examples. The other ones on the list are maybe a little bit more interesting because they're less intuitive. So if you don't have a privileged container, but still this host PID namespace access, this is very commonly found, you can't really access those processes running on the host machine, but you can kill them. And if you can kill everything that's running in the Kubernetes on top of you, you can take down the mobile network, of course, right? Obvious, right? So if you're building Kubernetes environments, look how often the host PID is set for your containers. You'd be surprised, right? And then if you combine the host PID with another benign looking capability, the speed trace, you can not just see those processes, but you can inject code into the process. In any process running on your host, again, that's root level access, right? That's basically root shell equivalent. Two benign looking things are combined to basically full exploit. Access to the file system is pretty dangerous as well. I mean, obviously, if you have right access to the file system, you can just override configuration files. You can add your SSH key, whatnot, but even read only access to the host's file system. Virtually always when we encounter at this game over, because you can find tokens. So tokens are, yeah, as the name would suggest, just strings that are used to access Kubernetes infrastructure. They're found in all kinds of configuration files. So reading them is enough to then access Kubernetes infrastructure. Also very popular finding passwords. A bunch of the utilities that you use to administer environments like this, they take a username and a password as command line arguments. So where do you find it? In Bash history, right? So if you read only access to the file system, often there's a password that you need to go forward, right? The last one is the one that surprised me the most. I don't know if everybody can see it from here. It's basically network access, right? The reason it surprised me the most is, of course, I'm old school. I know virtual machines more than Docker containers, right? And in a virtual machine, if you give it network access, that's not usually considered a security risk, right? I mean, how could you run a virtual machine without network access? It's basically a separate computer popping up on the same network, right? In Docker, it's not like that. If you've signed a host network attribute, it's sharing the same network interface, right? So imagine you have some services tied to local host and local host only, right? If you're sharing a network interface, the guest can now access your local host. And it used to be that even the Kubernetes API, the API to basically configure anything in Kubernetes, was often bound to local host and didn't have authentication switched on, right? So that's game over right there. At least authentication is now switched on in more recent versions, but depending on how old your Kubernetes environment is, this is a big concern. But at the very least, I mean, given that this interface is shared between host and guest now, the guest can TCP dump everything that's coming in and out of the host, right? So that by itself is already a problem unless they use SSL for everything. But now guess how they build Kubernetes classes, right? They say, oh, everything that happens within a Kubernetes cluster is trusted. It never goes over physical cable. We don't need SSL, right? Everything unencrypted. So giving network level access to a guest usually means the host gets hacked, right? So just a whole collection of things that can go wrong. And again, this is just the stuff that we see in real assessments. There's more stuff that can go wrong in theory. So that was a part on virtualization hacking. Let's talk about automation and the implications of basically this development. That instead of having people typing in configuration like old school Linux sysadmin type, right? You have some scripts and an uncountable number of scripts that are created by all kinds of developers that are pushed through all kinds of CRCD tools, right? So what's the implication of that for security? Well, of course that some threads that we had before are amplified, some new threads are introduced and then I guess a third category would be self that should never happen happens anyway because it's becoming so complex now. Let me give you one example of each of those categories. The threat that was already there that's being amplified is phishing or social engineering in general, right? So instead of five Linux sysadmin types, you now can phish hundreds of people across various companies that are all somehow contributing code into the configuration of this mobile network, right? If you get to phish any one of them, there's a good chance that ultimately you can adversely affect a mobile network, right? So that threat is amplified. Threads that are completely new, it's a whole ecosystem of basically software development tools that are now part of the operation of your mobile network, right? Somebody somewhere commits something to GitHub, it goes through all kinds of CRCD, it becomes packaged somewhere, it gets downloaded into an image, that image gets deployed through another CRCD. Any part of that chain gets hacked, your mobile network is at risk, right? And then there's stuff that should never happen, but of course, you know, you have hundreds of people working on this stuff, people posting questions on, let's say, Stack Overflow saying, oh, can you look at this piece of code? What am I doing wrong? And they're leaking internal secrets, right? Hundreds of people involved, one of them will do that for sure, right? But you see how the attack service now becomes really hard to capture, right? Like there's hundreds of people across different companies using all of these tools, all of this in theory would need to be tested now to know whether or not your network is secure. So kind of the pentesting that we used to do doesn't apply anymore. You don't even know what the scope is, right? So instead of course, this needs to be tested through ratting. Everybody knows what ratting is, right? So basically an open invitation to hack a company any way you want, and then explain them how you did it so they can learn from it. And then there's iterations where based on what you find, they get better, and then it's a little bit harder next time or a little bit more fun if you ask my team. And then it's these iterations, right? And what I'll show you next is kind of the best off of the ratting that we've done. So we do dozens of rattings, but a handful of them against 5G telcos. So what have we found in actual 5G telcos that allowed us to achieve all of these hacking goals that I listed in the beginning? And I should say this is the best off kind of a mash-up of different. So one network that's affected by all of these, I wouldn't disclose client information like this, but it's kind of a collage. So the first hacking journey starts from the internet and we find some developer put up a website, something unauthenticated, they're just playing around with something. They probably mean to take it down a day or so later. They know it's probably not secure, which is why it's completely isolated in the network, okay? We get to hack it and it's basically that end, right? This has no access to anything on the internal network, it's just some boring website. However, it's running in a Docker container on the Kubernetes. So if any of those capabilities we looked at earlier is set, we break out of the Docker container and now we're on the Kubernetes layer, right? And sure enough, of course, one of these capabilities was set, so we did break out. And now we're in the Kubernetes layer, which means we're not constrained anymore. The Kubernetes has access to everything that any of the container needs access to, right? So these Kubernetes environments, it's very hard to kind of DMZ them away, right? So we can, we start looking on the internal network, third step, very slowly, right? There's always a blue team that's looking on what's happening on the network. So you do this space out over days, if not weeks. You find different servers, you find different APIs. In fact, you'll find hundreds of APIs. Mobile networks today, a lot of what they do is microservice-based, right? So just just APIs everywhere. And mistakes are being made. So completely by accident, I believe, one of these APIs, if you send wrong stuff to them, it sends you back debug information and in the debug information, there's the credentials of one of the developers. Who knows, right? Mistakes are being made. Those credentials, they allow us to access some systems, not necessarily production system in the sense of mobile network. We're still on the IT side, right? Where the websites live. But there's kind of a data lake equivalent, right? Inelastic search, that includes a lot of information to do statistical analysis. And sure enough, we find the customer text messages in there, right? So this is a multi-week hacking journey to basically achieve the equivalent that in 2G took one minute, right? Sticking up an antenna, capturing the text messages around it. However, now we get the text messages of an entire country, right? So maybe it's worth spending a few weeks on this, certainly for somebody who wants to break two-factor authentication or any of the things that are attached to text messaging today, right? So that's one hacking journey. And you see how none of this actually targeted telco standards, right? It doesn't even matter that this is a 5G network. What matters is that this is a highly virtualized network with lots of automation fragments floating around. And the same will be true for the other hacking journey. So second one. So it shares some of the same steps. So I'm not gonna repeat those. But then basically once we're on the internal network, we look around more and more and more. Of course, we find development fragments, right? In this case, a GitLab. Somebody has basically a shadow file equivalent. So hash passwords that they deploy as part of some configuration update. Who knows, right? One of these passwords is Crackable. We crack it and that password now gives us access to wherever this configuration shadow file was deployed to, right? I mean, that's the whole point, right? Including the database that has all the registration information of all of the customers of this telco, right? So bank accounts, addresses and whatnot, right? Again, we didn't touch anything telco specific to be able to break in very, very thoroughly. Third and last hacking journey. This one is finally getting into the telco domain. So again, we reuse some of the building blocks, especially this credential we found earlier. But we also need one other bit of information. And that is a description of an internal API, which usually an API isn't self-explanatory, right? So you've somehow need to understand how to communicate with these APIs. And in this particular case, this was shared on the internet. And you can argue whether this is a security issue because believers in open source software, of course, say the source code can be opened, that's not a security issue, as long as your credentials are protected. I'm not so sure if this many eyes make bugs go away. Argument applies to software that's really only used in one or two companies. Because you post it on internet, people don't start looking for bugs in it. It's just the hacker will use that information. So some level of obscurity sometimes helps in protecting APIs in an event. This was on the internet leak. We already have the access, so we can finally access something in the Telco network, in the RAN network, right? In fact, not just one, this intelligent controller is kind of an optimization piece of software that's deployed in each one of these hundreds of data centers, okay? So we can access a software component in hundreds of different dockers deployed in hundreds of different Kubernetes. And sure enough, again, they didn't configure the docker sufficiently, so we can break out into all of these hundreds of Kubernetes environments and basically take down the entire mobile network, right? So you see how few steps are actually required to take control of an entire network, or then take it down. Do as the whole network. And again, none of this is Telco specific. And in fact, if this went a presentation on Telco networks, you could explain something very similar about most of the private cloud environments that companies are building. Basically, everybody is working on something similar right now. So let's talk a little bit about how to build those infrastructures better. Telco, Open RAN, whatever infrastructure you have, right? Obviously, configure your Kubernetes better or not your Kubernetes itself. The pods and the docker containers running in your Kubernetes, Kubernetes gives you all of these different configuration settings, make good use of them and be considerate and acknowledge that it's not virtual machines running in VMware anymore, that are much tighter mesh together. I'm not gonna go through this in detail. This is more a take-home list in case you are working on any technology like this. Now, for mobile networks more generally, we've been giving kind of these generic pieces of advice for years now. And again, this traverses Telco networks. All of these are easily set. And in fact, in our community here, we always wonder why do networks not do this by default, right? The whole security by design. I mean, I don't know who coined that term, but it's definitely older than my interest in security. So people 20, 30 years ago would have used that concept. And yet today, it's not yet found everywhere. And I wanted to just alert you to the complexity of acting even on simple advice with two examples to conclude what I'm presenting today. The first example of where the reality is just much more complicated than you would imagine is patching on hardening, right? Kind of the base security processes. If you don't patch yourself, you don't harden your stuff. You might just as well not do any security at all. It's really absolute baseline. And why do mobile networks not get hardened? I mean, for different reasons, in kind of the closed architectures that were deployed up until today, and these open, including open-run architectures that are running on clouds. So traditionally, I mean, there's really no excuse why they don't patch, other than the way that they deploy these networks where they say once we deploy it, we don't touch it anymore. The vendor in China, in Sweden, wherever, they first have to go through months-long test procedures before they can say that a new release is ready and can be deployed. I mean, if the test procedure takes several months and then deployment takes several months, you might just as well not be patching. I mean, you're months behind on the patching, right? So usually you get security patches about once a year. These are standard Linux boxes that are one-year outdated. Every CVE in the world applies to them, right? So it's just an ecosystem breakdown. The way that these things are procured just doesn't allow for patching. That excuse goes away in these cloud environments, right? In a cloud, you control everything. You, in fact, you're changing stuff so often you might just as well redeploy it with new patches. Netflix had an interesting strategy around it. Netflix had basically, in each of their virtual machines or Docker containers, they have a self-destruct timer that runs out at 72 hours. So each Docker destroys itself after 72 hours, then it's rebuilt from a CRCD pipeline and the CRCD pipeline, of course, has all the latest patches built in. So Netflix doesn't have patch management. They only have, basically, suicide of virtual machines, right? But now the complication in mobile networks is who would be able to pull together your patches because each of those dockers is in an individually stripped-down version of Linux? So nobody even knows what packages you would have to apply and how. This is not coming from RedTed or Debian. This is just a custom Linux. And if you run your own custom Linux, you are responsible for patch management and there's dozens of vendors involved. And of course, they don't run Linux distros for business, so patching is just so hard in telcos. And I mean, it breaks my heart, right? Years later, still very little progress. Similar, and this is the final example that I'll leave you with, standard security tools like an EDR system, right? We do a lot of red teaming and when we encounter an EDR, it usually sets us back about a week. Takes like a week to find a way to circumvent it. It's a good slowdown measure for hackers, right? Do we encounter them in mobile networks? No, well, for basically the same reasons because the old-school network vendors do not really allow you to deploy anything on the Linux boxes and they don't come with an EDR, so there is no EDR. Sometimes you can force us onto there. If you sign it, if the EDR breaks the availability of the network, you're actually responsible. So we have seen cases where this is done, but only if it was forced against the vendor in the Kubernetes Docker environment. Again, some question. These are stripped-down versions of Linux. No EDR system will work on this out of the box. These are basically embedded Linux, you could call it, right? EDR just isn't made for that, right? So we're basically in a situation now where telco networks have become cloud environments, but where the standard security processes like patching, hardening, and the standard security tools like EDR do not readily apply there, right? Big protection gap. And I hope you all consider this a challenge, right? Either to become more of a telco hacker. No matter what part of hacking you're coming from, I'm sure you saw some commonality today where basically telco networks have grown into your area of expertise. But also if you're building networks and if you're securing networks, I'd really like to invite you to consider securing telco networks in the future. We all rely on them for our digital lifestyles, right? So it's important to keep those networks secure, like we're already keeping cloud infrastructure secure, right? Yeah, and with that, at the end, I'm always left to miss. Thank you for sitting here and this hot tent with me and bringing back so many good memories to the series of conferences. I'll be around if you have any questions on telco, on cloud, on red teaming. Our red team is in Berlin, so if you ever want to do some project with us, love to do that. And yeah, now over to your questions, please. Thank you. Thank you, Karsten. We have a few minutes for questions. If you have a question, please walk over to the microphone in the middle. There are two microphones in the middle. Please line up. First question, here you go. First of all, thanks a lot. We've had similar situations with industrial devices, with medical devices, and stuff that should be expected, like pack management and everything. That was clearly not a given. And we've seen some certification efforts and some initiatives that were going to the right direction. So I guess my question boils down to do you see a way out, whether through incentives or just we're waiting for a doomsday scenario, how do you see things evolving? Very good question. So certainly, both the industry and different governments are pushing towards more security. The government's more than the industry, very much based on a checklist approach where they say, we want you to prove that your network is secure at one point in time. What happens after that, we're not so concerned with. So certification is good and meaningful to introduce a guideline or baseline rather. I just haven't seen the one certification that would address problems like these. I'm seeing certifications more around you have to prove that you're not from China. That's basically a big part of the certification. Now basically, protecting yourself from political influence, I mean, yeah, that might be important. I don't care. I mean, I wanted this to be secure from hackers from anywhere in the world, not just from China. Other parts of the certification lets you prove that your cryptography is configured correctly, those things. Great, but cryptography hasn't been a problem. Basically, since 3G, people haven't broken the cryptography anymore. So yeah, I wouldn't hold my breath for a certification to solve this. I think it'd be individual companies going forward saying we have an IT history and we make our telco networks as secure as our T-networks. All big telcos have cloud environments, and they make their cloud environments more secure than the telco environments. And that, to me, is a weird situation. Next question, please. Hello. I may have slightly misunderstood this, but what does open-ran mean? Are there open-source platforms or freely available platforms that we can run ourselves if we want to experiment with this kind of thing? Yeah, that's an excellent question. And I think the naming is very unfortunate in open-ran. So basically, what summarizes open-ran is a push from the telcos against the telco vendors to say, we're not going to buy your hardware anymore. We install our own hardware, and you need to ship our software. That's an umbrella. The interface between hardware and software need to be open so that different pieces of software fit on different vendors' hardware in its openness. It does not include open-source. It does not even include open standards. So it's very different from what this community would call open, but baby steps in the right direction. Thank you. Good question. Thank you for your talk. So quick question. So does the lawfully intercept components also run in Kubernetes? Oh, that's a very good question. No, so far not. But that's just because those vendors, they're behind the curve. I'm sure the few vendors, I'm not going to name them, but it's basically monopolies per country. They just say, why do we need to change? We have a monopoly market. You build our appliance into your network no matter how. And they might use just SS7 for that. A quick other yes or no question. Next question, because we have really no time. I'll be around later. Just find me later. So I just wanted to understand how it is moving to cloud infrastructure, the mobile telecom infrastructure. Yeah, I mean, if you have to deploy stuff in hundreds of places around the country and you already know that it's going to change every week, cloud is the only answer, logical answer. So basically, cloudifying telco networks is a consequence of 5G's desire to have low latency. Let's say your car wants to signal to the car behind you that you're breaking. You don't have time to send that signal off to telco network, send it to some central location, get the signal back, get it sent to that other car. The crash will have happened, right? We're looking at single digit milliseconds delays from car to car. And that only happens if each little region, each city basically has their own cloud environment. That's why everything in telcos in the future will be cloud. I hope that answers your question. And we're out of time. No. Sorry. It's actually exactly 10.4, so we have to move over and make space for the next talk, which is also a very interesting talk about how we moved out of the pandemic. But first, please have a great thanks for Karsten.