 We are live. Welcome everyone to our second CTF live stream session for the Cloud Native SecurityCon North America 2021. We hope you're enjoying the CTF challenges so far. This is our second session and last session for today and we also have another set of great speakers for you. So let me introduce you first my fabulous co-host Ashish. Hello, hello, hello, hello, welcome, welcome, welcome. I see already people are coming online as well. There's someone first, Ibrahim and good notches. I think if I pronounce correctly, welcome, welcome. Looking forward to hosting this with you, Magnil and looking forward to other awesome CTF. Nice, that's awesome. Do you want to introduce our guests for today? Sure, who do we start with first? I think once we come by one by one, are we gonna bring them one by one? I think we're gonna bring them one by one. Let's do that. Hey, how's it going, Lewis? Yes, it's going great. Welcome to the Capture the Flag. How's it going? I'm tired, but it's good tired. It's been a long day and lots of people are capturing flags now and it seems like everyone's having a fun time. They better be having a fun time. Please say you're having a fun time. But yeah, no, you can send me. The crowd definitely seems to feel like so folks who are commenting, they're definitely feeling it. It's like yes, it's awesome. Nice. So for people who are watching this, please give some cheers for Lewis because it's like what, 11 p.m. at your time? Yeah, yeah, but we're just getting started, but it isn't just me. So I'm taking the role of Taskmaster and Goose today, but there's some other people there. So again, shout out to Michael, shout out to Steve. You're gonna see someone else who is on there as well. So yeah, but no, it's awesome and it's lovely just to be part of it again. So thanks for having us. Welcome, welcome. I was gonna say, Jonathan, introduce a bit about tell everyone about yourself, Louise. Yes, this is Louise. Yeah, I know this is still me. If you want to know more about me, you can look at the last stream. My favorite color is blue. I think that's pretty much it for now, but it's I think it's a lot more interesting people who are coming up our way next. So I'll pass the floor to them. Awesome. Sounds good. Welcome. Hey, how's everyone doing? Good. Good. Good to see you. And I was well, I think the way we're doing this is we're telling our favorite color as for what Louise did and about a bit about yourself. Favorite color, I don't know. I guess I would say it's blue. It's a lot of blue. Yeah, I don't know. I always wonder what you get out of this question. All right, here's another one. I like the color white, which I know is not a color, but it's just a really great thing. Yep, yep, it is definitely a great thing as it looks really nice in summer as well on people just for people who may be interested in fashion. But welcome, Nikki. And well, if you can tell us a bit about yourself as well, that'll be awesome. Yeah, so I am the host of the OS DevSlop show. And I think I've met a lot of you via that weekly live stream. In my day job, I work, you know, in the security space like everyone else here. So yeah, that's me. How did more than cloud native security out of curiosity? Well, you know, maybe about three years ago, somebody was like, Oh, we're going to build this whole new productionized Kubernetes app, Kubernetes based situation with like dozens of apps on it. What do you think about security? What do we need to do? And I was like, huh, so that led me down this journey of learning Kubernetes and getting involved more in the cloud native computing foundation. So out of necessity. So thankfully, everyone was here to help. Oh, it wasn't made by choice, but by necessity, like, Oh, I guess I have to make friends with Louise and Magnus as well, though. Yeah, could somebody help me secure my Kubernetes clusters? Anyone ever? Yeah, I'm glad I'm so glad to have you here, Nikki, but I'm looking forward to having hanging out with you as well, along with other guests who are coming in as well. Let's bring the next person in. Hey, Jaffee, it's like, you know, you're not surprised. You're not surprised to the cloud security, sorry, cloud native security community. But do I still take a moment to introduce yourself to people who may not know you, who may be in the live audience, and maybe in person and saying hello to you there as well. Yeah, definitely. I'm Duffy Cooley on the Field CTO at Isle of Alent. I'm also a member of a somewhat notorious crew called SIG HUNK. And we've done a number of talks to try and get security sort of more in the front light of things and get people more engaged and make people feel welcome into that space. I will definitely echo exactly what Nikki said I think is that I think his take is a perfect one, you know, like, I think I think of my job is actually helping kind of develop that community spirit, make sure everybody feels welcome, make sure everybody feels like they can ask any question any time, and that you can actually get help doing pretty much anything you want to do here in this space. And so I love that you said, you know, I reached out and I had help immediately. That's great. Yeah, it's great. Yeah. My favorite color lately, are all six of these colors, you know, I've been Oh, yeah, so pick your favorite. Is that what we're going with? Awesome. I think I'll go with you. We've got a few fans in the live chat as well for you, Duffy, someone just saying, Hey, Duffy over there as well. For folks who are watching this live, feel free to drop in your favorite color as well. Consider your love to hear what other people have their favorite color. If there's a few honks coming as well for you, man. Alright, the next guest as well. Hey, Jim, welcome man, welcome to the show. Hey, everyone. Nice to be here. Oh, welcome. So the way we're doing this is very short intro. How do you got involved in cloud native and your favorite color? So yeah, the quick intro, I'm co founder at Nermota, and we are the folks behind Kiverno, which is a admission controller and policy engine in the community space. My background is more, you know, software development on the operations and management side. And of course, you know, as we, the more software that gets developed on Kubernetes, one of the challenges we're trying to solve is how do we make security a bit easier and automate as much as possible. So that's sort of my foray into the security space. In terms of favorite color, any of the solids, right, depending on, I guess, time of day or day of the week. But yeah, mostly like the blues and other, you know, solid shades. Oh, cool. I'm just realizing blue has a very popular for popular color today. I wonder whoever's listening in if they have blue as well as a favorite color. So feel free to drop that in people. We have another guest as well, I believe. Thanks for that, Jim. Hey, Andy. How's it going? Another? Are you are you at 11pm time as well? Or are you actually at home? I have invagaled my way into the United States of America. Yeah, you sound like you're not a contest, smuggling your way into US there. But as you may have heard, maybe doing this short intro by yourself and a bit of favorite color as well, man. Sure. Well, hi, I'm Andy, CEO and co founder of control plane. I'm basically I suppose these days, cloud native security engineer, but I've done lots of development and operations and like databases, all sorts of all sorts of things. My favorite color, it's probably probably got to be like, I don't ever do that. But sure, she just realized, Lewis, Andy and me, all of us are wearing some kind of jumper. And so is Jaffee. So clearly, we have our favorite colors there, like it's got the blue. And someone said just called out that you got a hulk mord going on over there with dripping a shirt jersey off. But now welcome, man. Well, welcome. Good to have you here. How do you get involved with cloud native security? That's a good question. Um, broadly, I was lucky to be in a team of like one of the best teams I've ever worked in just delivering, delivering what was basically like an ETL and machine learning system back in like 2014. And Docker turned up. And just it was obviously the next thing to do the next computing revelation revolution. Because there were a lot of bodges and hacks in order to get stuff working around the early versions, especially looking at some of the security challenges that were inherent in the thing. It just became an interesting journey to to embark upon. And that was seven years ago. Oh, you look so young, man, for seven years ago. Thank you. But I'm glad you are with us for the past seven years. We've got one more person joining us. So just not wait for the individual to come in. Hey, hey, James. Welcome, man. Welcome. Welcome to the show. Hey, good evening. Thank you very much. Or good afternoon. I guess it is your time. Yeah, where was are you based out of James? Like what's your time? I don't know. I'm also UK. So it is 11. Oh, we have three British folks over here going to just go into a tea party now suddenly. Yeah, rocking the late night party. Fair enough. I'm from Australia. So I guess I can definitely join the tea party there for sure. So don't mind me with that. So James, the way we're doing is a bit of short intro by yourself, favorite color. And yeah, how did you get involved with the community? Sure. So I am a security engineer at control plane. And it's part of my job. I contribute to CTF and community events like these, but also sort of breaking and fixing security issues with clients and advising really on ways they could improve. I guess, how do you get involved with the community? Or was cloud native? So that would be at a previous role, working as a consultant. So I had a lot of exposure to different clients and technologies that they worked with and just slowly as companies became more and more or adopted more and more cloud technologies. We sort of had to cater to the security needs there. And that that's where I was. In terms of favorite, in terms of favorite color, arguably not a color, but I think I'm going to go with black. Funny how many people actually have black here in this group as well. It's not even funny. So clearly someone someone somewhere loves black quite a bit as well. So you definitely not in the majority there as well, my friend. But I think that's all our guests so far. So looking forward to kind of talking about the capture the flag and how we kind of find other people saw challenges, maybe help them find some hints, hopefully, and get to get to the next step. What's the next step? Well, Magno, I'm all to you, man. Sure. Thank you. I think that was great introduction. Yeah, I think I'll start with one question here. And for anyone feel free to pick it up. But maybe before we go into the CTF challenge, like, what do you think are the most common mistakes organizations are making when deploying their cloud native technologies and services? Like, if there was one kind of advice or one kind of recommendation from any of you, what would you suggest there? Any volunteers? I would say, you know, like it becomes it frequently comes to like insecure defaults and things like that. And I think that kicks off like an important point about like, you know, just even beginning to understand like threat modeling in general, like if you're going to deploy applications that are going to be in any way exposed to the outside world, figuring out because hopefully you're the one that developed that application, or at least evaluated that application for its purpose, you know, figuring figuring out like a reasonable security model around that. And like, you know, but and how you will, how you will respond to that, like how you're going to configure that thing in a more secure way than than the two minute tutorial on, you know, wherever you found, wherever you found it is probably a thing I wish I saw more. I agree. I think, you know, things out of the box aren't exactly how you want them to be in production. You know, is it a great idea to put 37 apps on a Kubernetes cluster with no network network segregation? Did you know that you could actually do network segregation on Kubernetes? You know, and a lot of these concepts are the same things, like these are the same concepts as they were 20 years ago. But you know, kind of, I think people make this mistake of like, Oh, I don't have to worry about that anymore. That's like old time problems, the new time problems are like something different, but it's like the same problem. I think the bigger curses, I don't have to worry about that yet. Yeah, so certainly that's all right, no problem. I was also going to probably code Nikki what you said earlier, we're reaching out to people in the community as well, because it's a great Slack community for cloud native as well. If you if when in doubt, just reach out to people. Yeah, one thing I was going to add on the previous question and just to kind of echo what you know, Duffy and Nikki are saying is certainly Kubernetes, the power of it is all that you know, the declarative configuration, all of the details that it allows you to configure, but knowing want to get what to configure can seem dauntingly complex, right? So just starting with, you know, kind of learning the configurations and those great references out there, but it takes some time to understand how to configure things like a pod security context, what all of those settings mean and just following best practices there. For sure. Yeah, I agree. It's a steep learning curve until you have, it's like, okay, maybe it would be kind of easy to deploy a cluster, but then to secure it and have it properly protected with all the kinds of security tools that you have available, then it's a next step, right? So yeah. Yeah. Andy, Louis, yep. I'll jump in for a moment and then I'll just from my perspective, though, is and that's for me, the beauty of cloud native is everybody's different and so everybody's got different ways of learning. Everyone's coming with different experience, whether it's been 20 years in the industry or you're brand new to this, like within our company, we've got people with masters and adopters and we've got people who left school with nothing because they hacked the network and then they broke out. It's, I think it's more about what you need to do for yourself as well. It's a case of you can just look, you've got to figure out what it is for you. Like for me, when I started, I was trying to go for all these like dazzling bits, but for me, it was about the fundamentals. And when I understood the fundamentals, rather than having all these abstractions, I could understand what those abstractions were doing. And to me, that's the most powerful thing that I've ever done within Kubernetes is fully understand for core components. So start on, just understand Linux and it's always like another thing I can read about or go deeper into and that's the beauty of this. And if your glass is half empty, then it's sometimes you know what you don't know. But then being half full, it's like you get an opportunity to learn something new. And for me, that's the best bit about what I do for everything. Yeah, that's awesome. I think to your point also, one of the other big ones that I see companies make in general, regardless of whether they're deploying cloud-native or deploying software or doing any of that stuff, is that a lot of cultures lack a learning culture, right? Like, and that I think is a big one. Like if you can, if you come at pretty much anything as a company and you have a learning culture, like it's actually rewarded to explore and experiment and iterate and you know, be open with that stuff, then you're going to be in such so much a better place out of the box, you know, really like out of the gate, you'd be a better place. I definitely agree on that last point. I think with cloud-native, you're forced to have, you're almost forced to have that learning culture because of the pace of development, especially projects like Kubernetes and many other in the space that they move forward at such a pace. If you don't, if you don't have that learning, you're left behind essentially. Awesome. I was a great insight there as well, but I was going to slightly twist this a bit more. I was going to ask one about for people who may be coming in for the first time, may have kind of found out about all of us just now hit this thing called Qcon. So for people who are coming from that perspective, I guess what resources do you recommend for them to start learning about Kubernetes security? Because clearly sounds like we all agree that defaults are probably not the best, but is there a resource that we've normally pointed them to for saying, hey, this is where you should go or reach out to any of the folks over here, but just this is where you should go. But why would you send people? Whoever. I'll just go like around the clock. Take the pic. Yeah, it'd be super tempting to say, do a CTF, because that's what we're going to do. But I mean, in reality, that is a great way to get started. I mean, you're going to meet people, you're going to explore problems that make you think about things in different ways. Another one is that events like the cloud native security day is another good one, like getting in here and actually understanding what's happening in the space, understanding what solutions are out there to solve security problems for Kubernetes and why those problems require those solutions. You know what I mean? Like really taking it apart. I will say it's a very big complex ecosystem. It's a lot to learn and there's a lot to do, and I will also say that I think it's important that you figure out whatever approach works for you to approach it. Like it could be that you're like, you know what, I'm going to study admission controllers for a month and I'm only going to look at that, and then I'm going to look at pod security context for a month and really get to know that, study the API, understand what's in there. I mean like just take it by chapters. Nobody expects, nobody expects everyone to know everything. That was a great answer Duffy. Anyone else wants to add on to it? I mean I guess in true hacker form, experimenting, right? Spinning up your own clusters, deploying things, figuring out how to put it on the internet, how these load balances work, how the whole network is structured inside Kubernetes. I mean just sort of that normal hackery kind of thing, and there's there's even cheap ways like I experimented with Kops, which is like a cheap way to run Kubernetes clusters, because if you spin up like an EKS or GKS, you can get a pretty serious bill if you forget about that, like I mean not serious, but enough, right? So with Kops, you could actually just run them on EC2s or just regular compute nodes that aren't special, and you can kind of keep that really trim, and you can just play around, and I think that's a really great way to try to learn the security model, I think by pretending to be a developer and then pretending to be a security person, kind of where those things overlap is generally good security. So we're down to just to realize someone on the comments section said basically PENTA is their own infrastructure application, that's one way to learn just PENTA shouldn't find out, oh what's that? Oh, it's a chip container, oh right, okay, so I got it. That's for the kind project, which is even cheaper because it runs your Kubernetes in Docker containers. That is cheaper. Kind is a really good one because to your point, it's just perfect for setting up, and it's also very extensible, you can configure clusters to be insecure, in fact there are whole projects around that, you can also attempt to make a Kubernetes cluster very secure and see how that's going to work out for you, and try your different security models and stuff. I agree with the hacker thing though, that's the way. Yeah, people always talk about Kubernetes container breakouts as like a big deal, right? So you can figure out how to get that to work if you build out your own clusters, what would it take to break out of this container? And so, I don't know. So that's a great question because I think that's hammering on that point. No, I think it's a good one because I think that's what was the unless you can break yourself and some talking about breaking ourselves, someone just basically said breaking production forces you to learn. So that definitely would make you learn. So I guess that question is coming in for folks over here as well, so feel free to drop them in as well and we'll try and answer them. But I love the idea, anyone else wants to contribute in terms of, I know Magno has his own GitHub repository which we have posted as a link over there as well. It's an awesome resource. I think Cloud Security podcast ran a whole month of Kubernetes security where Magno was there as a guest as well. But this seems like a lot of resources but it doesn't feel like if you go reach out to the community, sounds like there's plenty of good information out there for you to learn the right way. Otherwise, without breaking production, try and hack your own Kubernetes cluster. That's the summary of it. Yeah, there's also some pretty good tools out there. Like there's a site which lists a bunch of pods with insecure and bad configurations. I think it's called bad pods. So you can see what types of exploits can be performed on those. There's another Kubernetes simulator which shows different other thing, misconfigurations that can be done. There's also, if you're looking for a very, I guess, a high-level resource to get started with, there's a good paper from Tag Security and Cloud Native Security which gives a great overview of the different topics. Awesome. Actually, that reminds me. Another Cloud Native member, Madhu, has like a thing called CubeGuard. That's right. For Kubernetes as well. Yeah, so that's another one. I think there's so much resources in the community that just worthwhile just looking around and there you go. There's the security white paper as well. You can just keep going about this. But so many resources that you can reach out to and at least find out about this. I think the CubeGuard is a different resource. I'll admit the resource in a second. I probably just sat to that as well just with the CTF that we've set up for today. The basis of this is like, how do you start with trying to figure out how do you build a class of us misconfigured? How do you start this? And this year is based on movies. And so instead of trying to find that creativity from looking within Kubernetes, you look for something else. So whether that be movies, music or something. So and that allows you to think about your infrastructure a little bit differently. Then you make it a little bit more creative and fun because I don't know if you all remember LAN parties and such, but that's effectively what we're doing with CTFs. We're trying to bring people together. We're just in that room. And part of it is to learn on that challenge. Yes, but part of it is to connect with other people. Ask someone for help as well. All these things. And I think that's that point as well. Even if you don't capture flag, you'll gain through so many things that you haven't done before. And these are brand new and you might not even know what you're doing, essentially. But in two weeks time, go back, try it again. And then all of a sudden, you've upskilled. And before you know it, then you're just getting so much better at what you do. I was going to say, Louis, what LAN party are you talking about? I was born on the internet, man. Like, I don't know. I know I look that old, but I don't know what LAN parties are. I just always been on the internet playing online games. This is the beauty of being virtual is the amount of filters I've got on my face right now. It's just like, yeah. Yeah. You can't tell. Like, you might have pain I've been through. So, yeah. Yeah. I totally agree with Louis there. Like with the CTS, I even started in InfoSec. I come as a developer background there and was because of CTS, where I started hacking web applications and everything. And also with the Kubernetes one, there was a workshop that they did on, I think was KubeCon North America 2019, which is the securekubernetes.com website that really helped me a lot on understanding the basics and some of the attacks there and how to protect your cluster. So, yeah. I think that's a great segue into the CTF challenge. And I think we can, if everyone agrees, we can move on to try to solve one of the challenges live. No pressure. No pressure. Yes, indeed. Okay. So, the generous and benevolent taskmaster overlord has allocated me a cluster and a channel screen and get involved. It would also be remiss of me not to mention there is a book coming out on O'Reilly called Hacking Kubernetes that the great folks at Control Plane contributed a huge amount to. And Amazon tells me, because I've pre-ordered my own book, that should be out at the end of the month, potentially. Looking forward to it. Yes, with a lot of trepidation, so am I. Okay. How does that look? Whenever you're writing a book, I wonder how that errata section is already looking. You know, like it's one of those things like you're going to miss that, but it's always that. Yeah, exactly. Someone told me the other day, James Strong and someone else of, is it Valerie? I can't remember, I found. Published a book and people just came back to them straight away with typos. So I've been frantically doing the final scans in the last couple of days. Yeah, that was Valerie and James, and they just dropped the Kubernetes networking. Yep. Yeah. Cool. Okay. So, put a trust bundle in we go. All right. So what I've done here is I've just taken the trust bundle that the Taskmaster gave to me. That just gave me some configuration, an SSH key, and in we go. So I'm now into a pod in a cluster, and the goal of the scenario is to pivot out of the initial foothold, ultimately find the flag, and yes, there may be orthogonal references to the prestige. I will be your hands if people would like to suggest. Oh, that. Could you, could you increase the font size a little bit more, Andy, as well, just a slight, that's it. Thank you, mate. I need to bring my next one. Should we start with... Yeah, can we also do PS1? PS1 is, yep. Oh. Okay. Find croc or find slash croc. Can you check the environment variables? So it looks like croc numerically goes up to about 14, so there are probably a number of processes running in this container. I might be tempted to grep for the command line, the command line file from each of the croc with a number. Sorry, Andy, just to save a bottom line as well is taken with your name. So either if you could just change your name by depot, so you can make it a little bit smaller or either way, but that's better. Thank you. Oh, thanks, man. Yeah. Someone's also referenced using kubectl within the chat as well. So, well, depending on how you get with this now. Did we check BF to see if there's a secret in here? Sorry, I'll get this visible. What is the name of the movie that this challenge is based again? This is based on a movie called The Prestige, which is a movie by Christopher Nolan. Well, great, great, great movie, great movie. And there is not a prompt insight in that movie. But in that movie, if you have seen it, it's more about the ending, which I cannot, I can't come on Twitch and ruin the movie, but if you think about the twist at the end, then that's something that we're trying to align to do with our cluster today. Did we test whether we can actually run kubectl? Jim mentioned the secrets there. Maybe are we able to get the token? We can kind of cut to the chase on that one pretty good. kubectl, off, can, off, can, dash, i, dash, dash, list. One of my favorite commands in the world. It's your metal name, isn't it, Taffy? Whenever you receive your streams, that's what you say. One of my favorite. So that's actually pretty cut down. It looks like a default service account. Although you can delete same spaces, that's kind of surprising. And you can delete deployments and you can get deployments and pods. So there's, I guess it's not quite the default. There's a little bit more to it, but it's not a wild card. Well, you can create deployments and pods, right? Or is that not lining up right? I don't know. There's like some spillover. Yeah, maybe we write some YAML and try to mount the host file system. Let's see what's already there though. Like, let's do kubectl get deployments, kubectl get pods. Looks like this might be an interesting CRD there as well. Yeah, the open ID ones. Oh, get all namespaces. Can we see them all? Yeah, sure. Yeah. And we do kubectl get pods.a or kubectl a? Kyverno. Yeah. I'm going to Google Kyverno. I don't know what that is. So that's the policy engine. Oh, it's a policy engine. Yeah. All right. That's okay because we have a ringer room, you know, when it comes to Kverno. I've never used Kverno. This is why we lined up the CTF because we had a problem. So we're just trying to figure it out. So we've got Jim here to help us out now. So we're going to gather in the end. So can we look in the Kverno namespace and see or we can even do try to get all the policies? The prestige namespace is rolling. What was that? Come on. Sorry. So there is a them prestige namespace. That's for them. Yeah, is there anything running in there? Deployments and prestige? Oh, no, none. What about pods or anything running in anything in there? So should we go into that? Let's check it logs and tell it to see if it wants it to tell us it's very quick and then log back in. That was the log output. We know about me. Okay. So did we have access to get the cluster policies or any of the configured policies? How does Kverno work? Is it like OPA? There's like CRDs and stuff? There are CRDs. There's one called policy and there's a cluster policy. You can do kubectl API resources and see all of the CRDs that are defined. Although it might not work because I'm not sure we have a credential for it. Yeah, if we were to look in the fourth can I response earlier, there was a bit of a hint as to what we can get with regards to Kverno. So one interesting output in the previous output when it said that server account wasn't allowed to do logs. What that also says is that we're in the prestige name space. The pod we're in is in the prestige name space. Yeah, okay. It's funny. What about is there any network anything in this namespace services or sorry, SVC? I think we're in there. I don't know if we have to write it every time, but yeah, what you are. Oh, we can't list that. Got it. All right. But we do have like what what what access do we have to that CRD? We can do and get in a list of CRDs. Yeah, it looked like we could do for cluster policies. So you could just do get C Paul. Okay. Can we just do minus or YAML on those? There's a message in between something about production. No, I was having some trouble when I was seeing this. Is that the only one installed or is there more? Oh, yeah, there's a few. I'll leave them individually. Is there a disallow host file system one? Can you can you try to type NSM here just randomly for me to see if you can come in. Excellent. All right. So what was that little hint we just saw? I think we have to. Anywhere else to deploy an image? Yeah, we like cron jobs or some other. I think we have create privileges and maybe we should pull what we can do again. Because I think we could just maybe write a YAML file to. So what is what is this policy restricting? Is it just cron? I was trying to read that but my screen is being weird. What the result is? I think it's container or origin. Yeah, maybe we just need it is kind of small. I'm like, you're going to see my eyeball in a second on the camera. For fame. There are two policies. One restricts where you can or the name of the image you can deploy and the other one restricts the privileges that you can use when you run it. The name or the location of the image. Container image must match. The image reference, sorry. It's only certain namespaces. So I have two questions. My first question is of the pods that are running in the cluster right now, including the one that we are in. Can we see what the image name of that is and is it part of the batch? So it'd be like dash O YAML or dash A dash O YAML. And then grab for image. So we can create new pods on that namespace, right? Because of the policies. Someone mentioned that on the Twitch chat, create a new pod that's privileged. That's not going to work, right? What about the developer namespace? There was a developer namespace as well? Can we do the same kind of list but inside of that namespace? So we should be able to deploy over there. So the policies seem to be restricting in three namespaces, but we could try and create a pod and a privilege pod and maybe Coop system or one of the other namespaces, which is not blocking. Yeah, we could iterate through the other namespaces and see if we have any permissions than any of them. That's true. Dash O name, you wild man. Yeah, before I, I'm going to say before I do this, I've actually got all the things in source. Yeah, that's not the right way. On the fly, that's working. Because of the way the name X puts the namespace in, that's going to give you a hard time, you can't really, but at least you could like split on the, you could split on the slash, do it probably that way. But we can't see which namespace we're in. Sorry, that's not the clearest output. Let's just, let's just grab for pods and deployments or something. I was going to say for sake of time, we'll assume that you could, you could work this out eventually. We will, we know that we can deploy or all of the things that we could do in the prestige namespace, we can also do in the development namespace. Is there anything running in the development namespace now? I think there's a point raised earlier on in this, in this panel though, about like different things about what we can do in namespaces and so forth. So some policies and such to prevent things from talking. I should probably prevent myself from. We have 15 minutes. What does the other, what does the other terminal get to us? Does the other terminal have like another cube kettle or is it the same, like what's happening with that other terminal? Do you mean this one here? Yeah, that one thing. What is that? I just popped that so that I could space out the top terminal because of my name blocking it. Oh, okay. All we're doing is inside the container. Okay, got it. Okay, so looking at the permissions that we have and the namespaces that we have, we need to figure out effectively what we can deploy where that gives us more permission. So based on those policy rules, like I think we saw one that was like more permissive of privileged containers. That was the development namespace, is that right? Yeah, yeah. So we can do something sneaky like run and then give it the image and possibly, I guess we'd have to figure out like, maybe one of the image names that is already in the allow list for namespace and then see if we can get something happen in there. Then the question is how would we access that other container? We'd have to probably go over the network or something. Can you pull the restrict images policy? Can you just put it back up on the screen? Super secure org. What's in there? Did we look in there? Is that a little public repo? Let's go look. I got an oops. So it's probably private, but let's look. Oh, wait a minute. Look at the match. Wait, hold on. What was that? The pattern is two greater than. It's any word, any word tab, call in production. Wait, it says, there's like a good hint there. I was having trouble when I was testing this up with my personal typo Docker hub account, but it works now. So somebody removed Docker IO super secure org, it seems like. Yeah, exactly. Now we just see the container that has the production tag. We can redag any container, right? Well, wait, hold up. If Docker hub was 404 ring, is that like GitHub will 404 if you don't have the permissions? Is that true about Docker hub, or it just means it doesn't exist? I think you will get a, I think you'll get does not exist if the repo doesn't matter. But in this case, it mattered at all, because the way the match works, the match could be any Docker hub repo, right? It just has the important part is that the tag is production. So if we have something with the production tag, and it could be, I mean, it could be alpine. It could be like, yeah, you're right. You're right. Yeah, forget my super secure org. Yeah, yeah. So seems like somebody edited this policy and made it work for them by just wild carding. So let's find like a shady Docker image, or... I'm tempted here to ask our wonderful hosts if they have already created one available. I could alpine tag production, because I can make one. Yeah, you said one. Oh, that's handy. We could pull down rolling Cali. I had totally forgot about the next week. I've been trying to remember the name of that thing forever. And this is the cool project because it takes like the next up and you can basically give it like with flashes, the packages that you want to have installed and it will just like deploy that. I love that. So freaking cool. Oh, yes. Yeah. So here is one we created on the fly earlier. So let's do Qtittle run dash dash or dash in development dash dash or give it a name like knock knock or something, you know. Oh, you don't need it. You don't need the dash dash name part. All right. Get rid of the dash dash. Oh, yeah, right. Yeah. Yeah. And then dash dash image equals... And then let's try dash dash privilege because that's how we roll around here. So if it were me, what I would do is I'd grab this template spec. Maybe like dump a drive run and back kick it to YAML. And then I would add a host pit access to the YAML. And then at that point, we should be able, like if we're able to deploy this, then we should be able to get all the way into the host file system. You might want to check that that's deployed properly. It hurts us, you know. Dang it. Can we see the events? Okay. Can someone explain for the audience what's going on right now? Like I know that we're trying to deploy a container. Yeah. Yes. So we had figured out that through a union of permissions that we see, and because of the way that image matching is working, it's going to allow us to deploy any old image into the development namespace, which is great for us. And then we had an image that was provided that gives us the ability to define like what we want to have kind of pre-installed in that image. We tried to deploy that into the development namespace. And I was using a dash dash privilege flag, which is a new flag in I think 120 or something like that, where you can basically make that container a privilege container, which is a kind of a pretty good asset test to see like, how much privilege can I give that container so that I can do things like exploit things and other fun stuff. That didn't work though. What ended up happening was that we were, when we tried to make the deployment, it does create container error. And that create container error could be pretty much anything. So, oh wait. Yeah, it could be pretty much anything. And I was trying to see the events then, to see if maybe it would tell us like, you know, no such image as that address or, you know, it's Friday and I, in puberty this hates me, or, you know, whatever it is. Right, but. Awesome. So, what's next? Any other options? So, should we try to mount the host file system in the image, in our YAML, is that like, what, aren't we trying to break out? Yeah, exactly. I can't remember if that was like our original target, was to get into the actual host file system or not. Like, can we run via that? Yeah, what's our objective? It should be related to the movie, but. Oh no, that movie came out in 2006. It's been a while. So, we're on the right track again. We probably don't need host files, so we probably just need you to deploy something in that other namespace and then pivot to it. So, based on the URL of the image that we have, shell bash, concat, notar, dig, gzip and perl. This is really missing things like netcat, although that might already be in there. What if we try to ditch the dash size privilege? And it's going to complain at you because you've already defined it, I suppose. So, you're going to have to do like, knock knock neo2 or something, or delete it. Yeah, without a fancy error message. Let's have this one. Can you describe the pod and then down at the bottom? There was a helpful error message on screen a moment ago. Oh, sorry. Someone is mentioning, try adding a command to the deployment. Not sure from the chat there. Mm-hmm. Yeah, like sleep or something. Dash dash command. Get long. Infinity. Sweet. Okay. Can we try the privileged again, although that was the kubectl version? Nice. That worked. So, we are kind of an interesting place where we could go out to the host file system. I guess what I'm trying to understand is whether the foothold is in the root. Like, do we need to take over a node, or do we just need to have access to another container? Like, if we were going to go into another container, what we might do is like, set up a net server or something on, and the one that we've just spun up somehow. Probably that would be our command, right? Like, NC minus L, some port, and then try to get there from the one we're in, and then see what we can do to like, then further dig around. That sounds incredibly sensible. Here's one I created earlier. Let's try and shave a minute or two off. Oh, let's save one more time to those, excuse me. Oh, ngrok. Okay. So, we're going to make it into the next container. I can't really tell what's happening in the screen right now. So, I have just spun up an ngrok tunnel here, and then here, here I'm going to create, I'm going to do this as a deployment, because I've set it up. I'm testing in the development namespace. I mean, it's exactly what Duffy just suggested. Set up a reverse shell, using that cunning mixery, sort of dynamically created image. It's obviously cash now, we've used it a few times. It's been up PwnCats. Yeah, which binds back to this shell, which is not yet connected to anything, but it's set up through this tunnel here. Fingers crossed. There we go. So, now this shell is connected to this deployment that we've just created here. Notably, I didn't create that as privileged. Nice. Okay, so let me just reverse out and do that again. If we're going to go down that path, then hold on a second, because what we should do is also throw in the hostpid to see if we can get away with that. Because if we can get away with that, then we basically just end a century into the root file system out of where we go. That's an inner center. Somebody in the chat is saying, shouldn't we just exec into it? That's a good point. Exec isn't one of our commands, unfortunately. So, I wonder if we can create purpose deployments. Does it work that way as well, or is that specifically on the pod? I think it's a run command. It's kubectl get run, or kubectl create, or kubectl run, and then you get privileged in there. Otherwise, what you could do is just kubectl create the deployment dash o yaml dash dash rai run, and then we could throw stuff in there, like add the privilege, add the hostpid. Hi, Prokratri. So, at this point, what we're trying to do is we're trying to figure out how to get into the... So, our goal is to get another foothold into the cluster. And so, what we've got so far is we've determined that we can deploy a container or a pod or a deployment that will have you in another name space and give it privilege and give it, like, you know, a bit more privilege than it should have. And then if we can get to that, and by some means, then we would then also be able to use that as a jumping point to get to maybe another jumping point, which might be the underlying nodes file system where we can put things like our SSH keys or another ngrux server, or all kinds of other fun stuff. So, at the moment, that's kind of what we're tackling. And what we've got so far is that Andy was helpful in speaking us up by basically setting up an ngrux endpoint on the outside world and then using our deployment into the development name space to connect to it. And so, in this screen, we can actually interact with... It's as though we had kubectl exec into the container, although the echo is a little weird, but, like, we can still interact with that container now. So, the question then is, like, what can we do from in there? Like, we can see, like... Maybe we can see if we can get to the root... to the underlying nodes files with them or, you know, escape to the node with sufficient privileges, and let's see what we can check out from there. Yeah. So, we're in this position where we need to insert a security context into this deployment file. And rather than trying to do it on a node, which I was just about to set myself up for the world of pain, I'm just going to take it off and do it locally. Do it locally. And what do we want to do? Does that look right? I guess we should do it. Hostbin's in the spec. Yes. Excellent catch. It's my favorite press method as well, so... Hostbin is all by itself in the spec. It's, like, up there with... Oh, yeah, I like your stuff. Yeah. I'm just plant-side validation. I can't think of how I'm doing that. There's a question in the chat about whether we're allowed to edit in the enter. I think, yes, we could edit. No! The policy, we could have just deleted them. Okay, how should we proceed? Shall I try and deploy what we've just done or do you want to take a different route? I think we need to wrap up. We're up pretty much out of time. Do you have any kind of... Anyone has any recommendations there? I can tell you where I was thinking about next. So my next trick was going to be to, once we actually get into the container, I was going to do nsenter-t for target, and nsenter-a for all namespaces, minus t for target, and then PID1 and then bash. And what that does is it's an nsenter command that basically opens up a new bash shell in the same namespace context that PID1 resides. So if you were to SSH into the node using normal SSH methods, you would also be in that same context. You'd be able to see all the network interfaces. PS-CF would be full of processes. You'd effectively be in that space. And since this is a privileged container, you'd be operating as routes. So when you make the transition, you're as route on the underlying file system of the node. That was my next goal. And if we could accomplish that, then that node belongs to us and we could do all kinds of other fun stuff. Like we could see if there are other credentials just laying around on the node that are going to make themselves friendly. We could throw another server on there like another ngrok and give us route access to the node that is now something that we have access to. We could do all kinds of fun stuff with the container runtime, all of those things. So that policy which blocked the privileges though, wasn't that also namespace that I think it had like a filter of it through our three namespaces? So we could, if we run this privilege pod maybe in one of the other namespaces that will get us through. Yeah, I think we figured out that the privilege was just, we could get away with a lot more inside the development namespace which is pretty common. And that we were deployed inside the prestige namespace. What I'm curious about is like what the twist would have been. I don't know that one. So I think you would find that the privilege container would have been blocked. But you're certainly right in saying that there were- That's the privilege container started. We have two privilege containers currently running inside of the development namespace. Interesting. To be explored then. Maybe we found a non-conventional way to solve this. Did someone say default misconfiguration? There is at least one other advantage of being in the development namespace. Yeah, perhaps can leave for people to find. Yeah, I think this is great. We had a great walkthrough of that challenge and without giving too much away, people are still going to have a hard time to solve it. I think before we move on, and I'm sure there will be probably some walkthroughs and some guidance for solving the challenges after the CTF is done. But any kind of last words, there are any last recommendations for our audience here. Have fun. Great stuff. Right. Hard to plan it. I think it highlights one of the things about IDS and policy configuration. We've got access to so much declarative policy now, which is amazing. But as soon as you introduce regexes, there is potentially a rod for one's own back. There's no other way to really do this. I mean, you don't just want a simple wildcard. Regexes make a lot of sense. I know that was a wildcard in that case as well. But yeah, it really re-use open-source policy is my short learning from that one. Awesome. Nice. Anyone else? Jim? Louis? I think just one tip for the remainder of it is just enumerate, enumerate, enumerate. There are still things to find. Yeah, exactly. Keep digging. If all else fails, go and make a cup of tea. Have a biscuit. And it's not the end of the world. Just keep going. You guys are new. Well, actually, you're ahead of us, aren't you? So it's now tomorrow to-day for us in the UK. It's just gone midnight. That's great. I'm having coffee over here. Yeah, I know what you cannot be said about just get up and walk around. You don't talk about your problem out loud. You know, get your brain working in a way that it's not currently- Exactly, yeah. That's awesome. So yeah, thanks everyone for joining. I think this was great. Our second session for today and it was great to have everyone here. And yeah, hope to see you soon. Thanks, everyone. Thanks. Very good. Thank you, everyone.