 Hello and welcome, everyone. It's like we've got one viewer so far. Hopefully more people will join. If you are watching this for the first time, welcome to the CNCF Twitch channel. Be sure to follow in order to comment in the chat. It takes a few minutes once you do that. So definitely go ahead so you can chat with us and you definitely wanna chat today. And a few housekeeping items before we get started today. Welcome to Fields Tested. This is an official live stream of the CNCF and as such is subject to the CNCF Code of Conduct. Please do not add anything to the chat or questions that would be in violation of that Code of Conduct. Basically, please be respectful of all your fellow participants and presenters. And I'm not sure what else we have coming up this week on cloudnative.tv. We usually try to have a show every weekday and my notes are not up to date. So I'm not quite sure what's up next. But you can usually find us here on weekdays. Follow us for notifications. And there's something else I was gonna say about shows on CNCF.tv. I don't know what it was. So we'll just go ahead and get started. So today we have a very exciting show. I'm gonna be doing something I've never done before. But first, let's introduce our special guests. We have Tabitha and Brad. I guess... You wanna go first, Brad? Brad, yeah, whoever wants to go first. Hi, hello. My name is Brad Giesman and I'm happy to be here with my wonderful co-presenters. Hi, like it says here, I'm Tabitha Sable. And yeah, I'm happy to be here. Brad and I, along with the wonderful Jimmy Mesta and Peter Benjamin, wrote this workshop and presented it at KubeCon in San Diego. And so today we're gonna be here. We're gonna hang out with Kasselin. We are going to, we're gonna encourage her. If the thing breaks, the three of us will be able to work together to get it running again. And just in total, I'm sure we're gonna have a honking good time. Yeah. I guess I probably should have explained a little bit more about what we're doing first, but welcome to field stuff. We'll get there. I'm Kev, we'll see ya. And today I'm gonna be doing my very first capture the flag. And let's go ahead and, I guess I'll share my screen so that people can get a sense for what we're doing. If you wanna follow along and try it yourself, you'll wanna go to securekubernetes.com and it was originally designed for use with GKE, but what do we think about using it with not GKE? You think that's possible? I did a lot of development work on a local kind cluster. The automation will definitely not work with anything other than GKE. That's good. And certain challenges this setup is like done using some shell script magic that I believe assumes GKE, but the majority of the content is in a couple of gammals and if you make like a kind cluster or a mini cube cluster or whatever you like and cram them in there, then you can definitely go ahead and solve them. That's what I was doing for testing. Any other thoughts on that? I was gonna say, I think we picked GKE for specifically for Cloud Shell during the workshop to sort of make our lives a little bit easier, but the challenges were not designed to be in any way specific to GKE. There was a little bit of helpers here and there, like you said, to have you for the automation, but nothing specific to GKE in terms of flags and challenges and solutions. So we've mentioned capture the flag and that you can find it here. And if you wanna start getting that setup and you're following along, please go ahead. Should we talk a little bit about capture the flag? Exactly, I was gonna ask you, well, do you tell us a little bit about what a capture the flag is? I mean, Brad and I have both run CTFs, played in CTFs, really been around the thing. Do you wanna take it or should I? Please, you go for it. Okay, so there's the game that you can play like in an open field or on a block or whatever with a quantity of hooligans and a couple of items that you declare to be flags and you hide them somewhere in your territory, you divide it in half and you hide your team's flag somewhere in your territory and the goal is to chase each other around and like it says, capture the flag. So that is not what we are going to be doing today, but the name works by analogy. So in like information security, capture the flag, you have some sort of game where you're going to hack things in order to typically reveal some secret information that proves that you hacked the thing. And then if it's something that is scored, then you take this secret information that you have revealed and you insert it into some scorekeeping system so that you get credit for what you've done and whoever hacks the most things the fastest wins but it doesn't have to be a team-based contest to see who can get the most flags as fast as you want. So I guess I would call this like a CTF-style workshop. We aren't competing with each other. Also, the solutions are here in the website. So you don't actually have to determine all of the solutions yourself. You could close your eyes and copy, paste your way through this and say, I won. But if you take the time to think about what you're doing and to understand it, then you'll have a good time and learn something. If you want to not be spoiled, it's certainly possible to click through to each scenario and read the setup and the description and then try it before scrolling down, unspoiled, and go back to the directions if you get stuck or need to move on faster. But yeah, we're essentially going to run across the open field of this Kubernetes cluster in order to get the flags, which are little strings or something hidden therein. Data hidden within the system that I had to hack, acquire. So, Kasselin, correct me if I'm wrong. This will be hopefully the first time you've escaped a container. Yeah, that's right. Very exciting, very exciting. That I think we do in what? In the scenario one attack, correct, Tabby? I think so, yeah. Cause I think in the first scenario, I think you have some more privileges than you really ought to. And so yeah, I think we break out of a container pretty early. That's very exciting. Like in four to five minutes of setup scripts, assuming you have a working G Cloud or a Google account, in four to five minutes, you could be potentially escaping your first container. So I think that's one of the best things about designing this or building this with you. And Peter and Jimmy, we wanted that goal to be very quick and early. We didn't want it to be like the last thing you did. We wanted it to be the first thing you did so that you felt confident and were exploring from there as opposed to just stopping and not continuing on. So I think that was, I really liked that design choice. It was a lot of fun to build. It was definitely a lot of fun to build. It was a lot of fun to help people get through. And honestly, it has been a total joy for the like year and a half or so that has passed, gosh, almost two years now since we gave it live to hear from people who have gone through it on their own or like hear from people that they have added it to the onboarding documentation for their security teams at work or for their ops teams at work. Like it just, oh my gosh, it's so wonderful. That's first I've heard that. That's awesome to hear. Yeah, I've heard it from several different people like at different companies on different teams that like they have taken this and put it in their onboarding procedure. Like go and go and work your way through this. You'll learn a lot. And like people are doing that. Oh my gosh, I feel like I did something good. That's awesome. When I first heard about this at KubeCon 2019, I was like, oh my gosh, I would love to do that because I would love to learn how to do a capture of the flag without the pressure of... I was like trying to win in the game or yeah, trying to win. Cause I don't know what I'm doing. I just want to learn. Well, you know, and that's the thing like if you get through this or if you get through part of it and learn something, then you do win. Like this kind of format is a real joy to me. It reminds me of Rendonering and Cycling which is this like very long distance unsupported kind of like the big worldwide event is a non-stop bike race from Paris to Brest and back to Paris. It's 1200 kilometers. At one point, these were like in the early 1900s like these were officially races and there was like some kind of turf battle between the sanctioning bodies that was solved by the ones who were running the Brevet saying, yeah, well, our events are officially not races. And so since then there's like a success time and if you finish the course in less than the success time, then you succeeded. And if you don't, then you train and use better strategy and whatever and try to get better. But like I love how it's like a challenge but it's a collaborative challenge. There isn't just one winner. And I feel like this kind of workshoppy sort of format is like that as well. And so it warms my heart. Come on, let's hack something. Yeah, and today I learned something new already off to a good start here. All right, so I'm gonna zoom in on this because probably nobody can read it at all. You wanna follow along and you wanna, I don't know if you'll be able to follow along as I actually do the pieces, but if you want to you can go to securekubernetes.com. All of the information about how to set up the cluster for this capture the flag game is there and it walks you through what you need to do. The automation, like we said, is for Google Cloud for using GKE, but the components aren't GKE specific. So if you wanted to get it working on something else you probably couldn't do it and follow along but you could probably do it and then maybe watch the recording of this later if you wanted to. So a little bit about you all on this page. So exciting. Like I said, I heard about this first at KubeCon 2019 but I was volunteering at the conference. We're all wearing conference. It was such a fun conference. Such a fun conference. But I was volunteering and I didn't get to go. So I asked about this later and I think Ian sent me the link and I was like, nice, I'm totally gonna do this later. Didn't. So here we are in 2021, almost at KubeCon North America 2021 and now I'm gonna do it. So we can see in the getting started section, the first thing here, I didn't actually try clicking this. I'm wondering what it'll do because I already have it set up over here. So I have my own Google Cloud account and I just ran the script. I actually, I had a project with a Kubernetes cluster but the script that you all have here creates your project in Google Cloud. It creates the cluster. So you can just delete the project when you're done and the cleanup will be super easy. I didn't want anybody to get a surprise credit card, Bill. Yeah. We also didn't want to deploy into like, say a prod project by accident, you know. Yeah. Somebody just testing something out and forgot that they were on the prod cluster. Yeah, you know, that can happen. Yeah. And like long ago, there was a semi-hard coded project name and then that became a problem when we were iterating on the setup script because projects don't just age out right away. They take quite some time to go away and so yeah, now there's some low quality entropy in there and all sorts of, all sorts of good stuff. Yeah. You can see my lovely auto-generated project name here is SK8's Caslin 27898. There you go. Don't set your password to that. Don't set your password to that. That would be a good call. But don't worry, when we set up the cluster earlier, it asks you to set up a web shell password and I have that set up very securely on a post-it note right here on my desk. So. Perfect. For this purpose, that is exactly the right thing to do. Eat it when you're done, you know, for safety. Eat it when you're done for safety. Thank you. Yeah, that's important. So I have this up and I have lost connection to my cloud shell, which I need to reconnect to. Let's go to the, it's already back up, but I'm gonna go ahead and go to Kubernetes Engine within Google Cloud Platform so that if we wanna look at anything about the cluster from here, we'll already be here. And you can see this is the cluster that was spun up by the setup script. If you go to securekubernetes.com, you're just joining, you'll be able to see what I'm doing here for this capture of the flag. And is this readable? Do you want me to make it bigger? Oops. I'd recommend popping it out into another window and then making it bigger. Never do that, but yeah. I can do that, can't I? No, it's tiny. Zoom in on this a bunch. Or I could not. We need to get you back on the right project. Oh yeah, that's right. That's annoying. Okay. Key cloud, type config, set project. And then I'm gonna have to grab my project ID from over here. Surely there's an easy way for me to copy paste this. No? I would copy paste it out of the terminal window. Oh, it didn't default into there either, never mind. What? Okay. SK8's Kazzlin 27898. We gotta authorize it to make API calls. And now as we're working with our files, we can also open them over here in the editor, I guess, if we want to. Which I like to never use. Cloud Shell's gotten fancier. Yeah, did you know I did that? I mean, I suppose there's a product manager somewhere for Cloud Shell who would be really disappointed if it didn't get fancier over time. So are you in the- Shout out if you're the product manager for Google Cloud Shell. Are you in the Git repo's sub directory in your Cloud Shell? That is a good question. I don't think so. Also, I need to log into the cluster. So I went into the cluster over here and I'm gonna grab the connect string right there. Yes. Cool. Cloud container clusters get credentials with the name of the cluster, the zone that it's in, and the project that it's in, which I didn't need because I have my project set. So now I should have my cube config set. So if I run cube CTL, get power pods dash capital A for all namespaces, I should be able to see. Awesome. So I've got all of my cube system stuff that's running my Kubernetes cluster and all of the other good stuff on it. And then we've got this dev environment namespace and prod environment namespace, which were created by the setup script. And I assume that that's what we're gonna be working with today. Can I suggest taking the browser window and pulling it up a little bit from the bottom of the screen share or hiding the name on the screen share? Name on the screen share. That's a good call. Can I do that? Remove source. I don't think that's it. Sorry, folks. Learning as we go. I'm just gonna edit name there and delete the name. It requires me to have at least a little bit of a name. I guess I'll put in like one letter here. Just put in G. Looks genuine enough to me. Oh, it changed mine too. Oh well. Yeah, we all know you're Caslin. If anybody asks, I'll tell them you're Caslin. Excellent. That sounds good to me. It's most important to be able to actually see what we're typing over here. Cool. So we're set up here. So see if there's a Cloud Shell setup. What was the name of the repo? Oh, I don't remember. Do an LS. This should be right in your home directory. Cloud Shell setup, yeah. CD Cloud Shell setup. Oh, make your browser now that the name is short. Grab your browser and just move it a little. Like make it slightly narrower than the full screen and then the G won't overwrite any of the important bits that we care about. There we go. That's pleasing. Awesome. Good call. I mean, I do like the colors actually. Yeah, it's kind of nice to have the color around it, isn't it? Cool. Is this a big enough font? Hopefully. I think so. Cool. So now we're inside of Cloud Shell setup. So this is the repo that I pulled down from GitHub from securekubernetes.com and we have attack2helper.sh, checkemail.sh, omnibus.yml, readme.md, and setup.sh, which is the only one I've run. I could look at the repeat, but I should probably read more of the instructions first unless you all have other recommendations. No, this is exactly right. You're going to get some free compute. Free compute? Is Google going to get mad at me for this? Well, no, because you're paying for it. Exactly. That's capitalism. You pay for your free compute. Okay. Interesting. Let's see here. Free compute from your own billing account. Since I am running the cluster anyway, okay, I'm going to read aloud so people can follow along with what we're doing. So in these attack scenarios, we're going to be doing a lot of things that can be crimes they've done without permission. Today, you have permission to perform these kinds of attacks against your own assigned training environment, which is what I've spun up. In the real world, probably don't do these things. That's basically what this says. Use good judgment. Don't hurt people. Don't get yourself in trouble. I stand behind all three of those sentences. Yeah. It's very important to point these things out when you're learning security tools and strategies and there's a lot of things that you could do that could hurt real people. So you have to think about that. Okay. So am I playing the part of red here? Yes. Lovely. So you're going to be playing the role of red and red too and then blue. Okay. So there's typically, well, there are four presenters and we wanted things for everybody to do, but we also wanted it to be very specifically mindset driven so that when you're red, you're thinking hunk. When you're blue, you're thinking, how do I get off call and fix this so I can go back to bed? So there was a little bit of character development, very light character development to make it interesting for the folks. And the room, but for here, I think it's important that it's not just an offensive only set of tasks, it's a defensive set of tasks. So whatever you're doing, there's a mirror defensive set of things that you're going to try to do to understand what happened or to prevent it from happening in the future. Cool. Never played the part of a hacker while hacking a system before. It's a mindset. It's a mindset, definitely. It's not a tune. We also have a question in the chat. So running on a container service would get access to not our cluster. So safest is to run on a cluster that we own. It depends what you mean by container service and our, but generally if you're running on a container service, like a managed container service where you set up a config and you just say run this container image and run four copies of it or whatever all the big cloud providers have on. Generally, if you're running on one of those, they take great pains to ensure that you cannot run something that will allow you to break out of that container and then harm the underlying host, harm the other people who are using the underlying host and so on. That doesn't mean that you cannot do it, but it certainly means you can't do it easily. And also it means if you want to do that sort of thing, then you need to look into, are there, is there a bug bounty program that you can join for that particular project or other sorts of things to be able to do those sorts of tests in a way that is doing so with permission. But in general, if you aren't intentionally trying to break things, you're not going to break things. Like in this case, we are intentionally trying to break things. And so that's why we have set up an environment where we know that when we break things, we also own it. And I am using Google Kubernetes Engine. So I don't expect that we're going to be breaking out to a degree that would be. You break out into the VM, but you provisioned the VM. Yeah, you were administrator to the VM to make it. So it's okay. Cool. You grant yourself permission in this case. Yeah. I was also pretty curious how this would do on autopilot mode because this was designed for GK standard mode. Autopilot mode is a little bit different. It doesn't allow privileged containers. Correct. And therefore, you don't have access to the node. Yeah. And scenario one defense would not deploy in that case. Interesting. Good to know. Okay. So I'm playing the part of red. I'm a hacker trying to hack a cluster, basically. That's a good way to describe it. I mean, what's Bitcoin arrow at right now? Sorry, I didn't know. I think it's, I think Bitcoin arrow is at like approximately three feathers per far thing. It's gone up a fair bit since 2019. Good, I got it early. My motivations. Red's intrusion as a service provider. Which is legitimately a thing that exists in the world. Like, you don't, you know, if you want to go and do cyber crime, like just like everything else, it is a business. You don't do all the cyber crime yourself. There's service providers. They compete for who has the best customer service and all sorts of things. It's, it's wild. And, you know, keep away from it, but it does exist. Whole new world out there. So I am playing the role of someone who has an intrusion as a service, which compromises websites and uploads a web shell. So I want to get the URL of the web shell and deploy some crypto miners. So that's why this is called free compute. Gotcha. Because as far as I'm aware, that's still the most common thing that successful attackers into most cloud native environments do because the, you know, the path to value is so short. You know, if you're going to break in, steal some data, unless you actually want the data, if what you want is money, then you have to figure out the next step, how to turn the data into money without getting caught. Well, if you mine cryptocurrency, that turns the access that you've gotten directly into money. So yeah, like reading through, you know, post breach reports and whatever, that's super common. Cool. Not cool, but you know, so the next piece. It helps to understand, like, you know, everything is business, even crime is business. Yeah, that's so weird to think about. In this case, we are trying to run a crypto miner and it looks like we are going to try to find a compromised website. So this would be run on, what would, what would that be? In your cloud shell, run check email because that's how you'll get, that's how you'll get your email. In a hacker scenario, would this be run on their like local machine or? No, this is just a little bit of the story. Okay. We needed to give you a unique URL. Gotcha. That was to your cluster. So that's why there's a little bit of... I see. Now, we are entering the story and we have this email. Yes. Which is, it's pretty great email. Well done. Our system popped another box for, once you've been detected from your account. Your new computer can be accessed at, okay, using your regular creds. All right, so I guess I'll go into this. The world that being the creds that you set up during the setup script. Yeah, I figured that must be, that must be the one that's on this post-it note here. So this is going over some stuff. We'll probably kind of talk through this. That's okay, instead of going through all this information. And... So go ahead and visit that web shell URL. We'll go ahead and go to the web shell. Just making sure we don't need to go over anything else in the tutorial. And I don't know what I set up as my user. Caslin. Probably Caslin. Because the username goes into the, goes into the name of all the other things. So Caslin is definitely your username. Hey, look at that. Okay. You got a shell and it's inside your browser. No, I don't want you to remember that Google. And it's not as good as Google Cloud Shell. It's serviceable. Shells as a service is low cost provider. Having a shell at all is a good thing. Okay, so now I have this shell. What do I want to do with it? So I have access- You've got to figure out what can you do with it? Yeah, what can I do with this? This is an insecure website shell that I'm hacking into, right? And I want to find a way to run my Bitcoin miner on it. Yeah, so like the first thing that you want to do, having gotten access to something, is learn what can I do now? If you scroll back up to there's like a flow chart up there. So like, okay, you have some situation. You're going to study the situation. Based on what you've learned by studying, you're going to formulate a plan. If you plan, if you feel good enough about it, you move on to attack something. If you don't feel good enough about your plan, maybe you go back and study some more. Study plan, study plan until you feel good about your plan. Then you go and attack something. You know, and by attack, I mean like take an action that is meant to advance your goal. You know, that might mean like running some kind of, some kind of magical command that exploits a vulnerability in software. It might mean sending a phishing email to somebody, you know, something that's going to change the world in a way that is to your favor. After you've done that, well, you learn more. So either your attack succeeded or your attack failed, but regardless, you learn something from the outcome of making that attempt. So if making that attempt got you your goal, well then you go directly to win because you just got your goal. If it has gotten you significantly closer to your goal, then perhaps you take some other actions, you know, you backdoor a cloud IAM rule, or you install password stealing software on a server or something, something to like help you to get back to that place without having to go through all the previous steps. Or maybe it does succeed, but it doesn't really help as much as you hoped and you're back to study plan, study plan, study plan, attack something. Like, you know, this is human problem solving. Like this is how you solve every problem in the whole world, but in this particular case, the wording is specialized to offensive security. All right, I'm not used to thinking like a hacker and I'm not sure what types of tools I should study first. So it has some recommendations, right? That's what the walkthrough is going to help you with. Okay, is that where I should go next into the walkthrough instead of continuing with this? This is it, right here. Yeah, perfect. And it also has some suggestions here in the study phase. It looks like looking at NRAP networks. I'm not familiar with a lot of these. Windows and Linux administrative utilities, you name, familiar with that, net step, familiar with that. And those can provide a wealth of information about their host operating systems. So those are some interesting ideas. Yeah, so like all you know right now is you have a shell on something provided to you by some sketchy contact that you have, but you don't know anything else about it. You don't know what you can use it for. You don't know where it is or if it's any good, but you can run some, you know, Unix information gathering kind of commands and see what you can learn. It may suit you to have another copy of this webpage to make it easier to copy and paste into your shell. That is true. I don't know if I duplicate this and bring it over to another screen over here. That way I can copy paste without having to move. And then we can just keep the shell open. Yeah, and then we can just Yeah, that'll be great, I think. All right, so let's go back to our shell of something that our sketchy contact gave us and let's run ID. What kind of information does that give me? There's some kind of dashboard, user ID 1,000. Yeah, so this is your Unix user ID. You know, you're running as a user called dashboard. You're in the group called dashboard. That's the only group you're in. And you're not root. Yeah, that's the most important part here. You're not root. Zero or one. Zero. Zero, that's what I thought. How good it's pretty, I am. If you're zero, that means you probably have one less or one fewer things to do in your attack plan for just goal, but that's okay. Not all is lost. Yeah, so let's learn a little bit more by running uname dash a. What kind of information does this give me? This tells us about the running kernel. Yeah, I'm not familiar with most of these numbers, but I know x8664, so. So like we can tell this is Linux. It is a relatively recent, but not super recent kernel, 5.4. This particular kernel was built in June. And the host name is dashboard, whatever, whatever, whatever, whatever, which is a host name of a type that is probably familiar to those in the audience who have used Kubernetes. That's clue number one. And I know from the security session at the last KubeCon EU that you did tap that. One thing I could do from here would be to look for vulnerabilities in that kernel if that would be useful to me. You could. I do not think that you need to do that at this time, but that is definitely a thing that you could do. Definitely. So the next thing it recommends running is cat, that's LSB release and cat, that's Red Hat release. So these are some files I assume, yeah, that will tell me some information about the operating system that I'm running if they exist. No Red Hat release, so we're not running a Red Hat version of Linux. We're running Ubuntu, it looks like. Indeed. It's 18.04. Now that might be interesting if you were at a different container at a different CTF for its age and given set of potential vulnerabilities. Interesting. Especially since 18.04.3 is definitely not the newest release of 18.04, like nobody has rebuilt this container in two years. Which just means there's more to exploit now. There might be more in interesting ways. There may be another solution available now that was not available in San Diego, I don't know. That may have been available, but people didn't know about it. That's the crux of the fun of it is how age wears on a CTF, changes the dynamic. So the next thing I just ran here was a PS-EF, so I'm looking at some process IDs. Dash go up plus has PID of one. So you're getting a little bit of information that it's not maybe a full process listing from the underlying host. Maybe it's a very contrived contained set of processes. It's not system D or in it, it's dumb in it. And it's basically running justice node application and your bash shell. Yeah. So that doesn't look like a normal virtual machine. No, you'd have a lot more processes in there. Exactly. We're pretty sure that we're in a container at this point, which we may not have known coming into it. And next we're gonna run DF-H, it's been a while since I've done that. So we're looking at the file system underneath. We can see the amount of memory that's allotted to these different areas. We can see there's a Kubernetes service account, which is another giveaway that not only are we in a container, but also we're in a container running on Kubernetes. This kind of makes me think of whether it might be fun to build a CTF challenge sometime of dropping somebody into a shell on a VM that is carefully contrived to look like it's a Kubernetes pod. But it's not. That's mean. But it's not. I love it. Like a honeypot container. Yeah. It's pretending to be Kubernetes, interesting. That'd be pretty fun. It's brilliant because you get them to do a whole bunch of Kubernetes reading and research, but it has no bearing on their success. They just learn about it. The trick is how to do this and make it fun instead of mean. So that's what I'm gonna spin off onto a background thread while we're doing the rest of the stream here. Excellent. And so now I've just run netstat-nl. I don't know that I've ever run netstat before. So here we are. Huzzah! So n means numeric output. Like don't spend time trying to do DNS and Etsy services lookups for the IP addresses and the port numbers. And then l means only show listening sockets. Okay. Otherwise you would see all of the TCP connections on the system. So these are sockets that I could potentially send stuff to. Exactly. Fun fact that in Kubernetes pod specs, you don't necessarily need to specify a port in the pod spec for it to be available to other pods. So there's not a line of defense here of, oh, I only specified 8,000 is the listening container port in my pod spec. 3,000 is still available if you were to hit it from another pod. In this particular case, in this particular case, because we're not listening only on local host, we are listening on the star interface. So yeah, like within this cluster, you can access the service running on port 3,000. You don't get magic service discovery and all the other Kubernetes fun features, but if you guess or some other way detect it's there, you could talk to it. So this is a lot of good information that you would probably potentially automate in a text. In a text scenario. So you just harvest all of this stuff. That way you're not having to type it across maybe tens or hundreds of hosts if you're able to get that amount of access, but this is sort of the early reconnaissance footprint, fingerprinting steps that we're walking through. My first baby steps as a hacker. They're exactly the same as your first baby steps as a sys admin. I've got a system. What do I do? How do I use it? What's running on it? How can I administer it? Like really what is a successful attacker, but a sys admin who doesn't have permission? That makes a lot of sense to me after watching your other security talking. Thank you. So all right then. And I wanted to come back here because it says it has some interesting info here that we kind of went over. Note that the kernel version doesn't match up to the reported operating system and there are very few processes running. So therefore we know it's a container. We went over that. And next we wanna do some basic checking to see if we can get away with shenanigans. Let's look around the file system. So we're gonna do some cat, some Alice, some changing some directories. Let's start checking this stuff out. So our first thing is we're gonna cat shadow. What do you all say? I usually say EPC. I say Etsy. By long habit I say Etsy. Yeah. Maybe that's the way to do it then. I don't have permission to look at that. You're not rude. So time was, UNIX passwords were stored in Etsy password, P-A-S-S-W-D because the keyboards were bad at Bell Labs. And everybody could read them. So like cat Etsy password. Okay. Full word or W-D, right? That's what I thought you said. So like, you can read this. Everybody can read this. And there is an X. Like this is a colon delimit list of information and there's an X everywhere. Because time was, there were password hashes in here because you can't reverse a hash. So when the user types in their password to log in, then the system puts the password into like slap chop and then compares the resulting dog vomit to what's in Etsy password. And if it matches, then hooray, that was the right password and everything's cool, but you don't actually store the password and everything's safe, right? So then it became known that you cannot reverse a hash, but you can guess them. You can hash every word in the dictionary and compare the result to what's in Etsy password. And now like, now I know that your password is love money sex God or whatever. And that's bad. And so like in the, I think in the early 80s, I think like 83, 84, something like that. I think it was like a Unix release six thing. They added the shadow password file, which they moved the password hashes into the shadow password file, which is only readable by root because the password file has to be readable by everybody because it's like how you translate user ID numbers into user names and things like that. So like everybody has to read the password file. So they moved the passwords out of the password file because having the passwords in the password file turned out to be a bad idea. So anyway, that's why you try to cat Etsy shadow because you want to get the password hashes and like feed them to your gaming computer full of GPUs so that you can crack them, but you can't get them because you're not root. I see. I feel like half the battle with security a lot of the time is just obfuscation. It's not in password. It's in shadow. And if you don't know that it's in shadow, then you're out a lot. Well, like the important thing here with shadow is not everybody has to read them. And so therefore we can put greater control over who can read them. All right then. So I can't get to the passwords as they are. I can get to slash password, but that doesn't give me what I need. The next step it suggests is to LS-L home, which doesn't allow me to see anything. There's no user accounts. Nobody has home directories. It's just a boring system. It's a container. There's nothing in it. That would make sense. And think that you would set those kinds of things up on a container and I can't open root because permission is denied. That's to be expected. Time was the root user's home directory was slash and that meant that root had no privacy. And so eventually I can't tell you when eventually root by convention got a home directory and root home directory by convention is slash root. Well, at least they use the, how long will it be before they obfuscate that name? Probably never, I think. Okay. It's been around a long time. How did that really work? So the next thing it recommends, I haven't run this yet. Okay. It's changing directory into temp and we're doing a curl, which is a pretty long curl, pentastmonkey.net tools. So it looks like we're curling down some kind of hacking tool for Unix. And then we're untarring it and running it. So let's see if we can do that. This is a bad idea if you don't trust where you get your curl call from, but like I promise this is legit. I mean, I'm doing this to learn about security. So if it goes horribly wrong, I feel like that's just poetry. Don't breathe. So I'll give you the short of it. If you scroll through all this, like you won't get anywhere. Okay. Like there's not any good output from this thing. If you remember Red's opportunistic, and so Red's goal is to do the quickest win. And sometimes these can bear fruit on older out of date systems. And so you're thinking, oh, is there something very, very low hanging fruit that we can take advantage of? I was about to say, we're testing all of the low hanging fruit first. But now we're gonna do something a little bit more complicated. Gotta ramp it up. So we're doing another curl command. We're pulling down a different tool, genuine tools. So it's probably better. I mean, just for us wrote it, so you know it's good. Oh, well, can't complain about that. Ami container or contained? Am I contained? Am I contained? Okay. Is this like a AWS thing, Ami? No, no, it's just gonna tell you that you're in a container. Okay. Well then, that's good. I mean, we already assumed that we were. And you are. And we are. What else is telling me? So that first line is the key. Container runtime is without a doubt, Kubernetes. Gotcha. Well, I mean, does that count as a container runtime? It's for the sense of like where this container is running, it would say Docker, it would say something else, but it's Kube because it's a little bit more. It might say RKT if we go back in time. Okay. We go back in time. Dial in your time machine. We're gonna use RKT here. I mean, technically we're probably using like container D or something on Kubernetes as the container runtime. The usage of container runtime gets very confusing for me. It's such a complicated word. Because it's like, well, what context are we in? What do you mean container runtime? Oh, do you mean run C? Yeah. So, but it at least tells us that we're in Kubernetes, which is probably the most important thing for us to know right now, I guess. And the next thing we wanna do is take a look at our environment variables and look for anything related to Kubernetes. So we've got a bunch of stuff here that looks like it could be useful. So we are definitely in Kubernetes. Super definite. This can tell you why would you do this? Cause it's a quick way to see the service ranges depending on what services are defined in an A-space and then the pod IP ranges that you can guess based on the starting IPs of what's here. So you know you're in a private address space. You're not a 172, you're in a 10104 something. Okay. So we're in a Kubernetes cluster. We know we're in a private address space. Next thing that we're gonna try to do is to use these IPs it looks like. We're gonna run a curl on the Kubernetes service host to Kubernetes service port, which is 443. Isn't that just the API server? Is that what we're trying to contact? Yes. Cool. So we're trying to learn what the version of Kubernetes we're running is, which is 1.19 plus. Is that what we're getting here? Cool. Yep. This is six Kubernetes releases newer than it was when we did this in San Diego because time flies when you're having fun. Yeah. Credit to your setup script, Tabby. You said release channel stable and therefore we just said give us the latest stable release and everything's still happily chugged along. That's wonderful. In San Diego, it was hard coded to 1.13 because we didn't dare taunt fate by having Google release a new GKE stable version the day before the presentation or anything, but then a couple of months after somebody messaged me on Twitter and they were like, hey, I was trying to run the thing, but I can't deploy a GKE cluster on 1.13 anymore because it's too old now. And so then at that point, I looked into my crystal ball and I saw myself updating that hard coded version over and over for the rest of my life and I was terrified. And so therefore I crossed my fingers and I put it to stable and I said, let's just hope it works a long time. This is actually one of the first things that I learned from some of my mentors who had been CIS admins is about when you put a static version in automation versus when you put something that will update itself like latest or stable. Because neither one of those is perfect. Like there are things that will make you cry about either one of those choices. Yeah. I was wondering if we'd have any interesting issues because of the updated Kubernetes version, but. We'll find out. Yes, probably not, but we'll see. The next thing it recommends that we do is LS var run secrets Kubernetes.io service account. So we're trying to see if we can look at the Kubernetes secret for our service account. Exists. There's information there. We have a mounted service account in this pod. That is a default, but if you don't need it, it is good to turn it off. So we have a typical, I'm reading from this here. Not that I need to probably, you all could explain it, but we have a typical Kubernetes related environment variables or typical Kubernetes related environment variables defined and we have anonymous access to some parts of the Kubernetes API. We can see that the Kubernetes version is modern and supported, but there's still hope if the Kubernetes security configuration is sloppy. Let's check for that next commentary. It's still true. My favorite hacking tool coming up. Yeah. Okay. Elite hacker tool curl. Okay, so I copied and pasted, sorry. I copied and pasted from the tutorial and it already did an export into our path we added slash temp to our path. By the way, this is a terrible idea on a shared system because then any other wing nut on the system can put binaries in slash temp and trick you into running them. Like do not do this at home. Actually only do this at home. Oh, good point. Do not do this at work. Yeah, don't do this at work. Don't do this on any, like don't do this. Don't do this if you care at all about the safety of the system you're using or the data that you're processing through it. In this particular circumstance, we don't care about the system we're using or the integrity of the data that it's processing. So therefore, this bad idea is okay, but don't do this. And I'm using this bad idea to try to get access to Kube CTL. It looks like I'm just like installing it. Put into slash temp because you're in a container. I don't know where else you can write. Sometimes read only root file systems will be pesky, but temp is sometimes available for you. So now let's see what Kube CTL can do. Kube CTL get all. So just tell me everything that you can get, Kube CTL. We did due to client-side throttling, not priority and fairness. So it seems like this is failing. I think this might be an artifact of the latest and greatest Kube CTL being smarter. So try the next commands. Okay, the next thing it recommends is all-a, which I assume won't work. Which would be even worse. Let's just try getting namespaces. Kube CTL get namespaces and s should work, right? Namespaces is forbidden. User system service account cannot list resources. Maybe get pots. Kube CTL get pods. See, we're back to study now. Okay, I can look at pods. Juicy, that's not a default. Yeah, how come this pod can get other pods? Like, that ain't... That's not a good idea. That doesn't seem like a good idea. If you can get them, can you make them? That's not a guarantee, but why not? Yeah, why don't we see what it can do? The next step is exactly that. Kube CTL auth, can I? And just tell me all the things that I can do. Kube CTL was... I think this was pretty new back in 2019, wasn't it? Yeah, it was relatively new. I wanna say 110, 111-ish somewhere. That's... Looks like I can do a lot of stuff with pods. Oh, pods, exec. Pods, attach. We'll scroll up a little bit more. So I could get into other pods running on the system. If you can pods create, that's money. Oh. I can pods create, then I could just create my miner on a pod, right? So I've got a path to success right here. Kubernetes is a system for scheduling and running workloads. Excellent. I knew that joke. I could tell. Okay. I've got my very own... You've got your very own Kubernetes system right here. You do. Borrowed from somebody else without their permission. Borrowed from me without my permission. But that's the way we should practice this. That is the way that we practice. Yes. Keep CTL auth, can I create pods? We already established that I can, but just to give us a quick answer, yeah, I can do that. Somebody put in a cap to make it show the little left bracket, oh, right bracket, like person cheering. Oh, yeah. Only for, that should be like a honk add-on. It's like only for create cluster role binding. It's only for the honks. It's only for the really good stuff. Should there be an opposite, like sad face emoji one for blue team? Yeah. And it's the same set of things. Same set of things, just sad faces instead of you. Yeah, can I? Unfortunately, yes. Ooh. Opinionated, our back auditing tool that cries for you when you've made bad choices, like I could see that. I like it. Now I'm gonna zoom down here because I enjoy this text right here. Happy day. Our service account is admin in our pods namespace. I don't know. I guess that was the case when we can certainly create pods, so. If you scroll up, you'll see a lot of stars. I love that tweet that Ian did a while ago that's like we're all made of stars but your RBAC shouldn't be. Your RBAC shouldn't be. Yeah, that was a good one. This is your goal, right? You wanna run some sweet, sweet Bitcoin arrow miners. So here you go. So this is just a deployment that I can run on Kubernetes to make Kubernetes run my Bitcoin miner for me. Yeah, you're gonna run that binary, money, money, money. So I'm gonna. This is pretty prescient because if I'm not mistaken, this is sort of the playbook that some of the recent, what TNT and something else are basically doing. It really is. They're like, literally, can I create pods? Can I do this? Can I create privileged Docker, privileged escape? If I can't do those things, can I just run the pod and run the miner? Yeah. It's like, yeah, they just automated this scenario one attack. A little bit more sophistication, I will give it. I mean, but yeah, it's just basically like, hey, is the door unlocked? Yes. Okay. I will come in and make myself at home. I'm just gonna go ahead and run this and then I can go over it in a bit. I don't know why there's a sleep there. So that that way the Coup CTL get pods will actually show it. Gotcha. Because the scheduler takes a little while. Yeah. And it looks like, there we go. Bitcoin. All right, we're mining. I should have seen something else. Money should be coming in soon. To my wallet. Thank you for your compute. Yeah. So we have done it. I have successfully run my first Bitcoin miner in a way that I wasn't supposed to on camera. Exactly. Congratulations. Yay. All right. Take your shenanigans hat off and put your, oh my gosh, why is my cluster broken? It's the middle of the night. Why are people calling me hat on? And get ready to kick yourself out of the cluster. But we have been on for an hour. So maybe we should come back to this another time. Do you want to? Yeah, I think so. But I'm really excited that I got to hack something. Thank you so much. Thank you for coming on. So in the next episode, you'll be able to trace back what you just did from a defender's perspective and maybe take some steps to help prevent that in the future or at least be alerted to that if that ever happened in the future. Yeah. And if you all want to join me again for this, you are more than welcome. Yeah, let's look at the calendars. I would love to. Awesome. Sounds good. We'll try to work that out, folks, if you're listening. I hope that you had a good time learning about Capture the Flags. A little thing before we go. Remember, KubeCon North America registration is open, whether you want to attend in person or virtually. So definitely check that out. Don't forget to like and subscribe because that's a thing. It is. You can hear on Twitch. It sure is. Hack the planet. Hack the planet. Definitely follow so that you'll get notifications for the next time when we've run through the defender. Defender route here. Yeah, hack the planet. Cool. Well, I don't know what else there is to say. This has been a lot of fun. Yeah. Thanks for having me. Yeah, thanks for coming on. And I hope that we'll be able to do this again next time for the defense because I really want to do that. And thank you all so much for joining us. It has been a ton of fun to hack this cluster and I hope it's been educational or at least amusing. Yeah, we'll probably be a little bit quicker next time since we've been through a lot of the basics and talked about some of the background of this and we won't have to go through all of that next time. So we'll probably get through a bit more next time if we can. Yep, sounds good. Awesome. All right. Be sure to follow so that you get our next notifications and we'll see you next time. Bye. Bye.