 Welcome, and we are live. Welcome, everyone, to our CTF live stream session for the Cloud Native SecurityCon North America. I hope you're enjoying the CTF challenges so far, and we have two sessions and a set of great speakers and fabulous co-hosts that will join me today for a session of some Q&A, some questions and answers, and then we'll go through some of the CTF challenges. Okay, so let me introduce you to co-hosts for this first session. Welcome, Alyssa Miller and Gab Smash. Hello, it's great to be here. Hey there, good to see you, good to see everybody. Awesome, great, and the floor is yours. I'll let you run the show. I'll be here as backup if needed. Good deal. Awesome, so do we wanna bring in our guests? We have a couple of awesome guests today, Gab. We do, yeah, so who do we wanna pick first? So can we just start bringing them in because I wanna make sure we get the names right, but I know we got Allie's hanging out out there and there's Mark has joined us. Yes, we have Mark Manning here. Anders has joined, Andy's popping in and Lewis is here. Yes, this is Lewis. I love it. This is the real Lewis, not the fake Lewis. I can see both. It was exciting. So I don't know, we wanna round the horn this thing and see what's going on with y'all. I think you should probably introduce yourselves. We start, maybe we'll just start next to meet this side there, I can do the same, Mark. Hey, how's it going? Tell us about yourself. Yeah, I'm Mark, I'm a security jerk. I'm a person with an InfoSec background. I used to work for NCC Group, doing a lot of source code reviews, doing a lot of Kubernetes security stuff. And yeah, I'm getting into a lot more cloud lately and now I work for Snowflake as a security architect. Nice, nice. We can Anders next? Yeah, I'm Anders. I work as a developer advocate for Styra, which is the creators of the Open Policy Agent Project, or OPA, which I'm gonna refer to for the next hour or so. Yeah, I come from a background in identity, primarily. So I worked for the last three years or so with OPA and Access Control. Before that, it was all about identity, identity of workloads, identity of users, and clients and so on. So a lot of OAuth, OpenID Connect. So it kind of came as a natural next step, like once you've established identity, like what do you use that for? Like, and so I got into authorization and yeah, here I am. Awesome, I have former DevRel myself, so I have a special place in my heart for the Dev Advocates, you know? Love it, love it. So Allie, tell us about you. Yeah, hi. I'm also a developer relations engineer and developer advocate. I work at New Relic, and I specifically focus in security and making security more digestible for beginners and newbies. And I actually live stream here on Twitch, so if you wanna follow me on Twitch, I'm at ending with Allie, where I do a lot of learning in public of teaching myself security, most of my practical knowledge, I've actually learned live here on Twitch. So I do a lot of different lessons and education on Twitch, so. We need more people like you in the industry for sure. Yeah. All right, Andy, do you wanna go next? Hello, hello, I'm Andy. I'm a founder and CEO at Control Plane, where we do cloud native security stuff. I'm a little bit dev, a little bit of ops, a little bit of security in there as well. Very proud to say I've just finished writing a book. Shout out to Mark, some awesome review work there as well. And of course, to Lewis, who's over there. And James, we were both instrumental in making that thing more polished, fixing the bug bounces up, all that kind of good stuff. I'm a Santa structure as well, Sansec584, again, with the Morden capable, yes, this is Lewis aiding and vetting in that. And yeah, like a zealous CTF maker and player and enjoyer. So yeah, super pleased to be here and really looking forward to today. Congrats on the book. You'll have to drop the title for us so we can get it. Oh, okay. It's called Hacking Kubernetes, perhaps predictably. Perfect. Very straightforward title. I love it. I have no idea what it's about. Yeah, I know. It's impossible to tell, isn't it? My word and I begin to. Yeah, I suppose one more thing is like, I'm super stoked as well. I'm actually at Kupon in person. So yeah, this is the conference center wall. People can be contained for the moment. So yeah, if you need me to go and like high five anybody or like respectfully wave at them from a distance, I'm your man. I mean, there's a few if you could find Ian and Kat, Castro, you know, those two, they might, you might know them. Yeah, just maybe. Just maybe it was contained in intentional pun because I like it if it was. Yeah. Well done. Well done. So Louis, other than editing books for Andy, I'm betting there's probably a little more you do. I help select covers for books. So I'm very proud to say that the book has got a duck on it. So I think that's a highlight of my year, possibly last 10 years to be honest. And I'm not in Kupon. I'm back at home in Wales, which is, well, England is the sidecar of Wales, but hey, I'll deal with that next week. Yeah, so day to day within control plane, I do lots of training. I used to go to lots of different places but I pretty much give training in here now. So this is my training dungeon. No, no, it's, it's, it's lovely. It's been great. We've had to change our ways over the last, however many months. And it's, I just got to meet lots of people to get to help them out and it's super awesome. And I get, I'm going to point that one and point that one. I get to work with these every day and it's phenomenal. They've really helped me push my career and super awesome people. And thank you for having me. Don't follow me on the internet. There's nothing that interesting to find. Yeah, that's pretty much it. Colleen, no, no, this is not Louis from now on. I should change my name to that. That would be perfect. Absolutely. So James is hanging out with us too. And James seems like he doesn't necessarily want to admit association with Louis and Andy, but you know, we'll see. James, tell us a little bit more about yourself. Hi everyone. I'm a security engineer at control plane with these two. And I sort of deliver security consulting-y type services for these guys. I was previously a security consultant. So that's very much my wheelhouse, what I'm not helping Andy with books or help building these awesome CTFs. So as people love the CTF, they should thank you is what I just heard. Well, there's a huge team of us at control plane that have all put in lots of efforts. So I'd be wrong in them just saying it was me, but it's been a lot of fun contributing to it. Anything positive goes his way. Anything positive his way, anything that's not so great, I'm here for that. All the hate mail goes to Louis. I got a special service for it. It's not the first time. We'll put his email in chat. Make sure you all know where to send that stuff. So Andy mentioned the cloud native security stuff. So I'm curious how you guys got into cloud native security. I mean, what does it even mean to say cloud native security? I mean, I think everybody kind of has their own idea of what cloud native is. And then, okay, on the top of that, we put security and then sometimes on top of that, we put cloud native application security and then there's gonna be cloud application security brokers. I don't know, it keeps going, right? But how did you guys get here? I mean, Allie, let's start with you. How did you get involved in this area of the world? Yeah, so I was thinking about the right way to say this. I'm going to reverse age myself. I'm gonna baby myself in a way that I can't do. Baby myself in a way, because to me, it's only been cloud. There's never been on-prem. So when I get, okay, I'm sorry, like I'm baby, I know. So to me, yeah, I know I'm making myself be baby. But to me, whenever I am doing anything, it's always been cloud first. So to me, they are synonymous. I am now actually learning more about how it used to be done back then as I dive more into Kubernetes and how servers are still somewhere in the world, still being hosted. But to me, it's always been cloud first and I've always had an interest in security and I've always had an interest. I've always thought people who work in security are the smartest people in the world and people that I've always looked up to, like Alyssa and Gabby, I follow you both on Twitter. Fan girling just a little bit. But I've always thought people that work in security were such amazing people and just thought in such a different way. And so I was like, how can I learn to be like that? And to me, that first step was figuring out just how everything works from a security aspect to a technical aspect. I feel like security is a great way to learn just bits and bobs of everything. So that's how I ended up here. So for the record, I am now following you on Twitter. Yeah, I need to do that. I need to make sure I am too. Even though it doesn't say that you're following me. So I'm on- I'm on lists. I'm on lists. So you're both on the security list. I can definitely understand that. I just give you a hard time. There we go. Yay, cool. So let, I'm not gonna say it that way. That would be cool. So Anders, I'm guessing that you like me probably didn't start in cloud native but I could be wrong, so correct me. No, you're definitely right. I remember my first job as a developer when we were done coding, we would deploy our code to a USB stick and we would walk across the office building to the operations people who would then take that and actually install it on our servers. So yeah, that's, so I'm that many years old. So how did you end up in a cloud native world after that? Yeah, that's a good question. I think eventually that same organization where I stayed for a couple of years, they eventually understood that things had to change. There was like that whole gap between development and operations was, it just wasn't a viable model. And of course, so like slowly, but still we tried and adopt like DevOps practices, try to be more agile and so on. And then eventually I ended up working more in identity systems. And of course in those like those standards around for something like 20 years. So once you learn something like OAuth, you can kind of work on that for the next decade or two. But yeah, and then coming into authorization and OAuth or in OAuth powers, there's really no standards and there's really a lot of ideas on how to best do that. That was kind of a shock for me coming from the identity world where there's all these like very strict boundaries on what you're allowed to do and not do. So yeah, and to answer like how I got involved in the cloud-native space, I guess this crew OPA which is of course one of the graduated products in the CNCF. Awesome. And props to that organization for creating the antithesis to DevOps at like extreme levels. I mean, talk about creating silos. That is amazing. USB sticks to deploy. I'm speechless. Gabby, have you ever worked in an organization that did that? No. Nope. Think of the security though. There's so many. There's no way your USB stick is going to get hacked in that 40 yards it takes to upload it to the other server. You were before your time. All right. So who wants to go next? How did we get into cloud-native? We have porn at Mark. Oh, is it? Hi. I think Mark's being volunteered. Yeah. Mark's being volunteered. That's fine. I think, let's see, you know, it's hard to go like, you know, Ali's saying she's a baby. So I want to go all the way back and describe myself as like a great, great grandfather of technology or something. But I was a pen tester doing network penetration stuff and when virtualization was just starting. So it was kind of like, that was the first revolution that I saw in the industry. And somehow I migrated to an application security background doing Android and mobile stuff. And I swear I'm going to get to, like, where we get to cloud-native because it doesn't make any sense how these are related yet. But I saw Android and iOS that were doing, like, sandboxed processes. They were doing, like, isolated kind of container processes. And I was like, oh, this is awesome. And when containers started becoming adopted, Kubernetes was around. I was like, this is the future of all servers. We're going to have, like, containerized processes. We're going to be isolated. So I started adapting what I was doing for, like, application security stuff and looking more towards what's Kubernetes doing. Like, let's help secure this thing. And of course, that didn't really flesh out what I wanted it to this thing. And we don't have full sandbox per se. But we've got some level of isolation. It's cool. So I think I was just pushed into cloud. I had a whole bunch of customers. And it was just the industries moving into cloud. Like, who's doing on-prem stuff? In fact, earlier on in my career, I was flying everywhere because everything was on-prem. I had to go to, like, data centers. And I had to go to physical servers and stuff. And then it just stopped. You say, oh, it's all remote. We'll just give you a shell. We'll just give you access to anything you need. So I had customers that were just in the cloud. You need to adapt or die in the security industry. So I was doing a lot of Kubernetes stuff. And I built a team at NCC Group. That was just doing containers and sandboxes and Kubernetes security assessments. And we kind of built some staff around that. So now here I am working at Snowflake. And they're like a cloud company and full cloud native. We don't have anything on-prem. We can't even imagine what an on-prem server would be at this point. So here I am. I fell into it, I guess. Mark, that was kind of like a choose-your-and-adventure novel. Yeah. It was exciting, right? Definitely. It's exciting for me. And I'm living it. That's awesome. Yeah. I mean, it's kind of interesting the way that it, I mean, some of the stories already, just like it sort of happened, you know? It's crazy awesome. That seems to be like the way of things with tech careers. But Eddie, how'd you end up here? That is a fine question. I was very privileged in that my first job out of uni, I ended up doing something that I was perhaps under-qualified for at the time. So there was a small startup in Bristol, which is out on the west coast of England close to Lewis's proximity. And it was a software-as-a-service back when that was actually a definition of something, business-to-business management system. I was the first employee, so I had the incredibly fortuitous position of doing operations, doing the development, doing PCI compliance, back when we still stored numbers of people. That very quickly failed to be the case. And everything was rack-based. So everything was like you were buying space in a colo. At that point, you weren't actually stacking them and racking them yourself, but still renting servers. He does this occasionally. He does this just freeze frame for a moment just to get us all on our toes. Go on, Andy. You got us again, mate. Historically, I was saying we had availability issues, and then everything froze. So there's some sort of resonant-inductive coupling with silicon. I'll be careful what I say. And yeah. So Amazon opened EU West 1 in, like, someone will probably call me out, 2008 maybe. And we just jumped on it. So going from that position where I'm just kind of the de facto, this thing needs to be done. There's a cloud over there. Why don't you try and unify our approach to the way we deliver services? And that was it, kind of steamroller from there. And then after that role, I started to be a consultant. And I just found that regulated industries had more interesting problems. Everything in engineering is a compromise, and often it's trying to, like, fit something into a shape that doesn't really naturally fit. And yeah, slowly escalating through different organizations. And then finally cloud native turns up, and everything just makes sense. You can kind of take the big multi-talented Linux system, squeeze it into a microcosm, and then run, or bin pack them, kind of add in an item. And it was pretty clear from early musings with Docker that there were lots of security opportunities. And yeah, it's just all kind of steamroller from there. So yeah, again, very fortunate to have that luxury. And I often wonder for people joining the train or getting on the ride at this point, what must it be like to have all these foundational layers before you even get to the containers and Kubernetes at the top? So I think all the way down through. So yeah, big up alley doing it all in public. Definitely the best way to learn. Yeah, there's a lot that I'm, there's so much that I feel like I'm always learning. And it's, especially as I've been digging more into Kubernetes, it's just been like, so much to break down and just be like, oh yeah, like this is, this is how it's done. And this is like why I feel like I've been like missing in my education as I am continuously learning. So yeah. Yeah, it's a super nice thing that kind of, at some point for me, like, I've learned so many different concepts and suddenly they just all seem to kind of amalgamate and make sense and like a cross reference. But yeah, certainly it's just like perseverance and making mistakes is how I learn. You mentioned the regulatory environments. I think Gabby and I can both kind of identify with that. Me from the financials and Gabby and her industry. Yeah, I love regulations. Yeah, but Cloud helps us address some of those regulations, things like data localization and all that fun stuff. Yeah. So, Louis, how did you end up? You're with Andy now. You're doing this cloud native thing. Did you just kind of like drag you, kicking and screaming or was this voluntary? Oh, I don't know what I'm allowed to say on that point. I think we're exclusively, I'm just with control plane now. And it's, I'm not anywhere else. It's with control plane. Yeah. My career, it's been very, you can look on LinkedIn and if you can figure it all out as how I got there. Congratulations. I don't have a clue. Please tell me that the main point for me was about five, six years ago now, I just hit this like lull in my career where I was a developer. I got into it off a level of developing. I just, for me, it's puzzles. Everything that I see is the case of how do I fix it? How do I make this? How do I solve that problem? And I got into this position where I wasn't solving any problems whatsoever. And, and it was last Sunday, it was World Mental Health Day. And at the time I was also suffering from depression, which I wasn't aware of because it was a biological thing. But it absolutely sucked. And so, but then having solved my depression made me realize it was like, I like solving problems. So I kind of jacked in my career of being a developer. And then it was like, what's interesting. And at the same time I was starting a family and then containers and it was like, stop, stop containers. That's that's going to help me because I need to be like, I'm going to have a child and they're going to be screaming in the night. I can't work till like 4 a.m. So I started that way. But then for me, it's always conferences as well. It's events like this. You get to meet people who are like minded. Sometimes you feel like you're in a bit of a hole on your own and no one else can really understand you. Then you bump into all these amazing people in these conferences and you're like, oh no, actually, we're kind of alike. It's kind of okay. It's a nice place. And so from that I saw Andy on stage hacking containers and it was just like, hello. Hello. Security always scared me because I never felt like it was a defined line that I could achieve. Whereas actually then I realized this is the perfect puzzle for me because it's something else constantly evolving. It's always something which I can work further on. And so from that point, I've worked my something off to get to this position where I could work within control plane and it appears that I get to work with. So I thought like, you know, Andy and you're going to hear more about James. But we've got some of the people behind the scenes as well helping us today, which I need to mention, such as Michael, Steve and Carl. And every day you just have like phenomenal people who just try to make you a better person. And it isn't just career is about being a better person as well. And so that's just what we do. And yeah, so probably in a year's time, I guess I'll still be in this kind of branded top. But that's where I am. And I just think I thought that's the main thing I just say to people is this like whatever position you're in, especially with the CTF and that's that's a puzzle that we've made for you. It might feel tough at times, but don't worry because it is supposed to be really tough. And we're here to help. But at least by the end of the day, you're going to learn another way as to how to break something which is always fun. We do like breaking things. All right. To finish off that trifecta, I guess, James, you're the last one. Hello. So, yeah, as I mentioned earlier, I sort of started starting my career off as a security consultant. So I guess I was quite fortunate, I think, to have that as my first sort of grad job. Because I don't think I appreciated it when I applied for it at the time, it exposed me to a huge variety of orgs and environments and ways some places do things. Some places do things badly. Some places do things well. And sort of early in my career it was invaluable already because it sort of it exposed me to all those different things that perhaps would have taken me many more years to to witness and learn from had it been like a normal job-cycling scenario. I sort of started off in, I guess, what you might call a more traditional security kind of penetration testing thing, where I was looking at, like, windows and Linux boxes and maybe a bit of mobile here and sort of you're expected to sort of know a little bit of everything and also largely based on premise environments. And the more, as sort of the years went on in that role, this newfangled thing called cloud or probably not so newfangled by the time I was looking at it, but more and more places were using it. I guess it appealed to me just, I think, partly due to the elegance, but yeah, I became part of the team that looked after a lot of the cloud and especially the containerization element of those bits and pieces and just their exposure of looking at how different orgs built things in different ways and how they screwed things up in different ways. I think really is how I learned. And then sort of fast forward a little bit today at Control Plane where I sort of still to a degree look at various orgs and how they screwed things up, but also sort of giving back that advice and contributing to the security process. Awesome. Those are some insightful answers. I think it's really interesting how everyone's kind of got a different, a really wildly different career path, but we all end up in the same industry. So a few of you mentioned that you really enjoy working on the CTFs and also solving CTFs. So my question for you is if you could use one tool and one tool only to do a Kubernetes CTF, what would that be? I know. I was waiting for that answer, but come on, we can get more creative than that. I know, right? I mean, that was the answer I was going to say was just terminal. Terminal. That's hacking right there because then you get everything. You got to be more creative. Play with the API. Crew, right? Like the plug-ins for KubeCuddle, like Crew have a bunch of like scripts that are baking and that like to me is kind of like the metasploit of Kubernetes or just got a bunch of scripts that they aren't necessarily like new things you got to compile and build. They're just these dependencies you can yank into your box really quickly and start attacking different stuff. I like that. The metasploit of Kubernetes. DJ, Yuffie says they would use Splunk. I saw that. It's interesting. Other thoughts? I mean, because I kind of, you know, I knew we were going to kind of go into this path and I was thinking about it myself. I mean, kind of along the same lines, Mark, but I was just thinking like Perl, like, you know, I'd be out there when my thought was just, yeah, how do I, you know, probe and abuse the API because I mean, that would have been my first thought. So, but yes, I did also think about the console. Well, I think it is right. Or is it like everyone's saying bash because that's you don't know the environment you're going to get. Are you going to get remote cut execution? What kind of shell? What kind of environment are you in? Like, what if it's Windows? Like, everything's out the window. You don't know what to do. So I think like the core Unix tools, running Netstat, LSOF, you know, like bash. What can you do? Like the find command, running strings. Like, these are all simple tools that are on most boxes, but they're so important for the CTS. So is that like a statement on, like the types of issues that people have, typically in their cloud-native environments? Or I mean, what are your thoughts? Is that, because I feel like, okay, if I'm going to go hack a web app, you know, it's probably Burp Suite or something like that is going to be like the universal tool everybody says they want, right? But when it comes to, you know, things like a case cluster, we don't really have like that, that tool set that necessarily stands out other than, yeah, the terminal windows. So do you think that that kind of says something about common mistakes that people make? From my perspective, yeah. I mean, we are not dropping O-Days on people, right? We are exploiting misconfigurations. We are taking bash scripts and weaponizing them. We're just doing kind of script kitty stuff because that's what we're targeting and that's the most common configuration problems that we see in cloud environments. It's not, you know, I'm not going into Amazon and having some crazy vulnerability that I've just been sitting on, you know, for the past two years in these environments. It's like, let's write some tools to speed up, you know, common misconfigurations and stuff like that. I wonder what other people think. It also shows just how new this all is because having a tool like Burp Suite, web apps have been around from day one. So a tool like Burp Suite has come out of it that allows for that extrapolation and easier interpretation of data and information you get, but with how new cloud native is and even a tool like Kubernetes, you don't have that time period to be able to create an extrapolation because if things are moving so fast that you just have to keep pushing forward, you don't have that break point where you just be like, oh yeah, like I can actually build something around this, but I just have to keep going and figure out what's wrong and you're going to do it on the one thing you know, as we all said, bash terminal command line. Yeah. I think Alyssa mentioned that before, just like the idea that things need to be statically compiled and maybe we can curl bash them down into the pods when we're exploiting stuff. Like we're not voting up Burp Suite and jars and Metasploit interpreters into a pod. We probably don't have the time and we probably don't have the execution environment to do that. I'm kind of curious for Andy's thoughts because Andy, you literally wrote the book on this. Yeah, I suppose, yes. It actually goes to print today, so it doesn't exist for another month or so. Yeah. I think, yeah, I mean, it's a really strong point. We're not searching for vulnerabilities in the code base itself. There are huge buzzing projects going on against Kubernetes which kind of deal with that for us. Obviously, because it's a purely declarative system, then best practice is easy to statically analyze and we've got a lot of tooling and this makes the whole pipeline story into the defensive DevOps build out really effective. But then as a kind of emergent property of that, there's so much complexity in the number of permutations that we can have set up that even though we can statically analyze for like a known good baseline on various different parts of the system, it becomes misconfiguration, as Mark said, and just the interplay between two things that are not correctly configured. Maybe that's on a kind of per name space basis. Maybe that's the way that the cluster sits in the sort of wider topology of the cloud account because, I mean, there's something in Kubernetes docs which is like the four Cs of Kubernetes. You've got the code, the container, the cluster and the cloud, I think that's right. And we model the applications already compromised because we say the application is compromised. What about the topology and the network policy around it? What about the node isolation? What about the services and the workload identity that that can hit up in the cloud? And all those things kind of inform how the architect is built. So the question there becomes like, not only do we have misconfigurations in the file system, can we escalate to root really easily within the pod, and then all the container breakouts generally require root or cap or some capabilities. So that's kind of the first line of defense because the security context is hard enough. Then, again, assuming that that's broken out of what identities can be integrated with in the cloud based upon what the service account has. To some extent, again, you can statically analyze those kind of things. But then, of course, if somebody can just exploit like a metadata API and security where you can hit your cloud provider's metadata API, pull back the instance role with like an old school, well, an old school token service, and then just escalate to the cloud account, well, you can just go and image all the disks and it doesn't really matter about your configuration of the cluster itself. So having everything to clarity is super useful, but then the way that we kind of work our way out and around those, it is just a standard set of tools that we want to... The difficulty is doing it contextually and understanding the developers' intent and trying to figure out where the holes would be rather than just kind of like spraying scans across the whole thing. But yes, a meandering way of saying, I agree. Awesome, yeah. So as someone who's never done a Kubernetes CTF, I'm super curious. How would you go about solving this CTF challenge? So without giving too much away, where would you start and what would you look for first? That's an excellent question. It kind of depends. Speaking generically, like old school enumeration and discovery techniques are still completely relevant. Cloud native doesn't throw away the baby with bathwater kind of thing. It just brings in some other abstractions and allows us a more fine grained model to hang policy around processes, basically. So I love Nmap, actually. I suppose that's another tool with a decent scripting engine to it as well. So yeah, starting off with an Nmap enumeration is often a useful thing to do against cluster. In this case, in the first thing we're going into, there's some application level injection that we've got to play with. Again, as Ali says, it's been around since the dawn of time. This is the way that stuff gets pwned. Remote code execution, foot in the door, and then what's my privilege? Can I escalate? Can I enumerate? Can I attack the visible horizon? All that good stuff. So I haven't really said anything that I hope. Well, so why don't we take this? This seems like the perfect segue into. We're actually going to do one of the challenges live here. So James, I think is that you that's taking control here? Yeah, I haven't heard James yet though. So if you could just check it's Mike. Otherwise, I will speak on behalf. Yes, it is. I'm so thankful for that. James, just really quickly, if you can increase the size of your terminal, it seems like you're opening a bigger one. Yeah, absolutely. Sorry, I'm just prepping a couple of windows. So whilst you prep that just for today's CDF, if you are looking for a cluster, if you could DM the Taskmaster, Taskmaster has a load of clusters ready to go. They're on the other side of that door over there. We'll send them across your way. If you need any help, reach out to Goose. Other than that, just make some noise on the channel. Someone will find you soon enough, and we'll definitely be there to help you out. And Lewis, if someone who's watching now wants to get started, where should they go? So you need to sign up for the security days, and then you should have had an email with credentials. That's where they need to go. We will promote this at the end. There's an open source version of Simulator where we've already got scenarios out there. And then if you are interested in this, well, we're always running game days anyway. And for us, it's always just about letting people in and just playing about. So if you are interested, just reach out to us. Again, I put myself down on the Internet there, but you can find me on the Internet. I've got a double barrel surname. There's only one of me, which is a terrible, terrible thing for me. I'm always more than happy to help out. On Twitter or on Slack? On Twitter. Yeah, you can get me on Twitter. You can get me on Slack. I'll put all my details in Slack as well later on today. But again... Drop them in the chat also. I'll do it. It's my Twitch streamer. I'm sorry. I'm trying to get everyone information. It's bringing me out. I'm trying to get answers. I'm just going to let you down. Nothing. There's no interest in my streamer. It's just a contact. Just a contact. I know. We'll take a soft line on it. We'll discuss it. It's okay. Cool. Sorry, Andy. I was going to say, we've got a theme permeating the CTF today. The conference is in LA. And so we have a Hollywood theme going through. And the first film from which we have taken inspiration is Inside Out. And yes, more will become apparent. Over to you, James. Thank you, Andy. So we can see in front of us, we have the memory CICD build system, which is the entry point to our first challenge today. I'm hoping you can all see my screen and it's blown up enough. But just shout if you can't, I'd love a little bit more. So we've got two sort of web pages that are exposed here. And the reason we sort of started through a web application is we wanted to simulate a little bit more realistically how an attacker might gain access to a container or might exploit an application. So if we explore the web pages available we can see we have a status page, which just tells us some information about the system. Just tell us it's down, nothing too interesting at the moment. Then we can also see we have like a utilities diagnostic page. So of interest, initially we can see this ping box which if any of you have any kind of hack the box or traditional CTF experience, you might recognize this as a potential command injection issue. So what I'm going to do is open my network tools and firebox just so I'm recording network traffic. And let's have a look at what happens if I try and use the functionality legitimately. Zoom in the screen please. Yeah, I'm not sure if it resets every time I refresh that's all I know. So you can see through entering an IP address here we have the output of the ping utility. Is anyone from the room has a bit of a guess at what's happening here? I'd say it looks like developments come out for retirement for a couple of days. And I think it's something that we could do with this potentially. I've been inclined to agree with you, Liz. So what I'm going to do next is copy in my network tab I can see this is the most recent post request apologies if it's a bit small, I can blow this bit up. I'm just going to copy the request out as curl. So that will allow me to over on the other side here. Hopefully, even if there's loads of junk in here this is this will be the authentication token. But essentially we have the same request that we made when we press the submit button in the web application on the left hand side. So if we enter we hopefully get the result. Excellent. This proves we can duplicate what we're doing in the terminal. So hopefully in the stream you can see the last part of this command or last part of this curl request, sorry. Looks a little bit suspicious. So we're seeing there's a JavaScript function we should note that it's appending ping-c3 and then the the input which is an IP variable, right? So starting to think about how can I break out of that how can I change the IP to something more fun? Mm-hmm. Yeah, exactly. So not only can we specify the IP because we're passing that c3 that looks like we're passing the whole command in as the request. So if we try that again but we can edit say get rid of all of that and maybe just say if we try replacing it with ID we'll see that we can specify the whole command here which is great news for us. So we have a command ejection, command execution floor in this website. We can see that we're running as the engine X user. So that kind of tracks given that we potentially might be using engine X to serve our website over on the left here. The next thing I'm going to do is throw a reverse shell. This might be more familiar to some of the sort of classical pen testers or security folk amongst you. So this is where we will be connecting a bash shell to an IP under our control. So for this purpose I'm using a service called ngrok and what this does is it allows us to basically listen on a public IP on the internet and get that connection proxy back to our local machine. So the command I'm going to use to do that is going to be netcat in the container here. So I should say there are a few different ways to achieve this. For example we don't, without doing a little bit of further enumeration, we don't know that we might not have the netcat binary installed in the container but for sake of argument we'll assume we know that. So so we can run a command that looks a little bit like this and then talks to our ngrok endpoint. Here's the following interesting. So getting a DNS error here so this indicates that there might be a DNS problem in the cluster so we can work around that by resolving the ngrok URL to its IP address and then using that in the command. Cool, whilst you're doing that James I'll just mention as well that if you've done our CTF challenges before we'll come straight into Shell and so this time around we wanted you to have to do it this way to say like we haven't given you credentials to start with and the next couple of scenarios you've got credentials but we're just trying to show you this is how it can start so if you're always wondering well as an attacker someone sends me credentials it is in the case, that's what we wanted to show with the start of this. Back on our ngrok screen we can see that we've got the ngrok tunnel spun up and in this middle panel here we have our reverse shell and prove it's alive so this is essentially the same command we run before but now we have our reverse shell which gives us a little bit more flexibility so I'm now going to start enumerating around the cluster to see what kind of container it is see what's available to us so we're inside of a pod we can do anything that we want here what are some other tactics other people are interested in exploring here what would you do when you first get into a pod? Being British I'd wipe my feet first and take my shoes off before I go into someone else's pod so one of our favourites is Am I Contained by Jesse Frazell if you can get that running it shows you a lot of what you can do from that point so big shout out to Jesse as ever I'm pretty much, this is what Andy would say anyway so I'm just saying what Andy would say we've got some really done I'll leave Shari from chat says capsh-print nice so what that is is it's going to be listing all the capabilities that are available to the pod implying that maybe there's some overprivileged access to this pod can I break it out of the container what can I possibly leverage also Jay Beale says Am I Contained I'd be a good check too so this will live as you say will list us our current set of capabilities a wild pop appeared which you may recognise as the default set of Docker capabilities so no privileged container so there's not a trivial breakout so you've got a couple of links floating around no go I was going to say the mounts, I'd like to see what volumes are mounted inside the container good chat so I think we've been meeting and we don't have the mount binary so now we start looking at the proc file system can we get the information from the mount command without running mount we've got a request for another zoom is it possible to get a zoom in please yeah absolutely try to maximise without wrapping too much but hopefully that's a little bit better definitely so yeah that's a good suggestion on the proc file system we could look at proc one mounts and this will give us a good indication of what's mounted in the system there's our favourite path Run Secrets Kubernetes service account come back to that later maybe is anything else standing out what was the movie again that we're basing this one on emotional status seems a bit unlinuxy inside out this is a really great call out there looks sus definitely says alright so that's aggressive it's like we went for inside out rather than 7 because I would just be precious right now so at least we did that as you say not very Kubernetes well these are terrible negative feelings so I automatically want to replace them with something positive after a little bit of sadness though so if you were to search the movie inside out do you see the core characters cool so what do we reckon is there a list I was just going to say for searching on IMDB quickly I was just going to mention if you have a character that we're potentially missing and I say it's any big inside out fans on this but we got sadness and joy missing from these emotions okay so what do you reckon we should do about it if they're missing maybe we should find them what do you reckon another files or maybe um someone in chat says find or add it's JBL says find or add kubectlc if there's a service account token and run secrets okay let's have a look J's taking us in another direction I like it well we can always come back to the old emotional status another point grep for sad I feel like that's yeah I feel like that would be fruitful okay wait where do you think we should grep slash yeah it's just everything we could stay here for a little bit alright how long is this I was going to say we got like three minutes left maybe underslash I can't allow that one I'm going to save us the weight on that one and tell you it's not going to come back with anything let's get to now but we also see it also says emotional status here okay well I suggest we maybe follow what J was saying and have a look at kubectl so okay so as probably no surprise given the earlier mount entry we can see that we've got a service account mounted in so we could try and talk to the kube api server with it just to make you aware james we've got about five minutes left and we've got like one minute left we've got one minute left I was going to ask if we can tie it up here okay yeah we can absolutely just run through the rest of it if that's yep cool so if we use the service account token and the dns address of the kubernetes api server verify that we can talk to the api server like so so we might then want to start poking around a little bit maybe get pods for example which reveals that we have a limited service account but it does tell us the namespace and the name of the service account can i and who can do just the secrets so so for example we could do something like that see we can't get secrets so we could if we had a little more time maybe download something like rack s which would allow us which is a crew plugin it was just a standalone binary beforehand but allow us to enumerate through the access the api calls that we are allowed to run and which ones we want but we might also realize that given that the emotional status was mounted under var run there might be some form of config map that we are able to look at yeah jb will just put in chat to look at config maps uh-huh so we can and lo and behold we can see there is a config map so let's jump into it dash oh yaml so let's have a little look at what it is looks familiar so next step is we might want to update that to something that has the values we want in it so as Lewis mentioned there's another couple of um another couple of character promotions in the movie Lois you remind me what those are please for your dreams certainly oh Ali you go I just know one sad so um and you need to see the movie it's a great movie sadness and joy I know I need to see the movie cool so uh what I'm going to do is move into a temp directory and then paste in a pre-written yaml file with the with the um with the new emotions in them then if we look at the yaml file we can see the is that's the full range that are in the movie so we can look at if we can apply those cool so that looks like it was successful now go back to and give it a minute it might update so in standing with this config map why can't we have just appended to it why can't we have just appended sadness and joy to the file I'm going to assume it's mounted read only swing and a hit so now if we go and look at the build status we might notice that it has changed and the system believes or is happy with the config that we've provided it and potentially has given us a bit of a hit as to what might have happened next sockets make me hope that there is some kind of local socket unique socket exposed somehow in the pod now let's have a look so in our testing it sometimes takes a minute for the sockets to align properly because of course the CI system is never instant are you going to be passing the Docker socket into this path potentially that would be cool or exciting yeah so the concept of this scenario we've inside out was in the movie and without giving too many spoilers the memories are changed and altered causing different effects to happen and so within this scenario you've had to go in and change the memories accordingly which is then causing change in effect to happen from the cluster which is allowing us to go on to that next level so within a couple of minutes we might see that within far run our friend proper mounts do we need to drop this connection potentially and see because when we set up initially we could rerun that potentially spin up into another pod or anything to that effect so I believe it will kill our connection for us but as the demo gods appear to be against us perhaps we will have to force it so I can just re-spin up my connection through rerunning the is engine X doing the actual socket opening to be reloaded from the configuration like if you kill engine X it will kill the pod so there is a deployment modification so it waits for the Kubernetes deployment to be redeployed so we're waiting on waiting on Kubernetes scheduler and controller at this stage there's some good chat in the chat right now um blogful certainly it's all good Eureka is best yeah blogful has pointed out that they reverse engineered the status stock PHP page to identify what these things were which is a great shout and it's a question do pods have a concept of hostname of bash history well yes if they're baked in if somebody's done something dynamic at build time but once the pod restarts then no, that's a bad rule and it's lost so we can wow so Docker is in this pod next to your engine X service is that what this is we uh yes so Docker CLI is installed but equally you could curl it from somewhere given this pod has internet access so if we run this command we'll see that we can talk to a host Docker Zeeman I would say uh just a reference to anybody that's interested BOTB like the static binary go line tool can interface with the Docker socket to do a bunch of these workouts so if you didn't want a full Docker binary to interface with it you could use BOTB so unfortunately I got bad news because this has been awesome and I know all of yours are really enjoying it too but we do have to wrap up so lots more to be learned obviously James thank you for running through this and thank you everybody for all the great suggestions the ideas and it's cool too to see in this CTF how maybe there's different ways to go about finding the same information same as when you're pen testing something like this or trying to define those volumes in your own environment so but yeah unfortunately we got to wrap up so thank you everybody Mark, Lewis, Anders Allie, James Andy, Gaby it's been a lot of fun yes thank you all thank you thanks all quick reminder we'll have another session at 3pm pacific time where we'll go through and we'll talk to some more questions and you'll have a new set of hosts and we'll dig further into what's available in the CTF until then good luck good luck good luck everyone