Grasp and Escape Docker | Bug Bounty Containerization Explained transcript

In the last number of years, containerization has become an absolute must for any company that wants to scale their web application to a large number of users. And with technologies like Docker and Kubernetes coming around, it has actually become a lot easier to do this even for small to mediumsized enterprises. However, as with all new technologies, it always carries a security risk around with it. And that's why in this video I want to talk about containerization.

Talk about some of the recent developments in this topic. And I'm going to show you all this on a live example where I'm going to demonstrate some of the ways that you can escalate from a container and find vulnerabilities that way. And this is the first part of a two-part series that I'm going to do on containerization. And this part is going to cover docker which is the way of actually deploying containers. The next part is going to focus on kubernetes which is a way of managing containers.

So docker deploys the container and kubernetes is like whole management system for using. Okay. But first of all what is containerization? So what is docker? Docker is a way of basically running applications in like a small little contained environment, kind of like a virtual machine. But don't get these two things confused because they're actually very different under the hood, but they kind of act the same way. Imagine we have this main host, main server running, and this is our server.

And we want to have two applications running at the same time. So we have two web applications, and they're running under two virtual hosts. And there's like a reverse proxy between them, right? Pretty standard configuration. Now, what we don't want to do is we don't want to run them in the same environment. And the reason is they might start overriding each other. Like if you want to run them on port 80 or we want to run them, you know, on their own dedicated port, we don't want to have to change that every time we deploy it, you know, we could uh have like conflicts between them writing the same files or having problems accessing the database or whatever.

So we ideally want to run them in the same environment with the exact same, you know, tools and interpreters. So say these are like Python apps. We don't want to, you know, run it on a server here where Python 3.12 is installed and this is running on different versions of Python, right? So we want to have the same interpreter set up and we want to have like a fresh Linux directory. Want to have, you know, files that are not going to get tampered with while the app is running.

So the way we want to achieve this is with containerization and before Docker there was really only there's only a few options but one of them was a virtual machine but the issue with virtual machines is they have very high overhead and Docker has much less overhead. Now some more of the advantages of using Docker as well is as I mentioned before these apps won't you know conflict with each other but there's also a certain degree of isolation between apps which is good for security because you know if you can imagine that there's an RC on this red app on the left if it was running all on the same host container well then the attacker would be able to access the other app as well and also the files on the host which is much more severe than just accessing this app.

So because of the way Docker is set up and the way it kind of restrict files, it's going to basically prevent this uh red app from accessing files on the host and files on the uh other app. So what we kind of call this in cyber security terms is that the call the lateral escalation is limited and so is vertical escalations. vertical is going up, lateral is like flat, right? And then again, docker when you run dockers each container has its basically its own file system, right?

And this is not actually like a real file system. It's not again it's not a virtual machine. This is actually stored inside like the host somewhere on like files. through like Linux features like croups and stuff they are basically able to kind of mimic a fake fake file system which has its own like user groups right so there like a root directory there's a var temp home and stuff like that and when you have root access on one of these containers that doesn't necessarily mean you have root access on the host which is also an important security element of docker so if I write with this app to the var directory Then and if I also do that on this app then it's like two different directories.

So that's pretty good from a from a you know isolation perspective as well. And of course what are the ways of escaping this these containers. Let's say we are inside of container and we have managed to achieve remote code execution. Then how can we think about actually accessing these other containers like this one here? Or ideally we could take over the host container which is really what we want to do in some kind of privilege access.

And there's a few ways of doing that. The first kind of main way and the way that I've seen the most is misconfigured permissions. So if a developer gives the container the privilege flag or allows it you know to access some file that it shouldn't be able to access then in some ways that the container can escalate privileges either by spawning another container that mounts the entire host system or by just you know executing commands on the host.

And this honestly this way is less seen nowadays just because of Kubernetes and kind of the ways that you know permissions are managed these tend to pop up in security audits where you're not supposed to do this you know and it's pretty obvious when a container is misconfigured. I'm going to talk about this more relating to the the Kubernetes episode because there's a lot more ways to misconfigure a container in Kubernetes than there is in Docker, especially when it comes to service accounts and API.

I'm going to talk more about that there. And the second way is kernel exploits. Linux has a long history of exploits that allow escalation whether writing to read only files and other privilege escalation methods. there's, you know, a lot in a lot of kernel versions. I think right now we're on like 6.3 or something like that. I think something like that. Either way, if the host machine is using an outdated kernel, then there could be a chance that you could leverage some of these kernel exploits to escalate privileges in the container.

Now, remember, Docker reuses the same kernel because it's not a virtual machine. It doesn't spawn the new kernel in. So whatever kernel the host is using, it's also being used by the containers as well. So if it's vulnerable, well then the container will be vulnerable to it as well. Now there was one exploit here where for example in Kubernetes through a outdated kernel they could write to a binary that was exposed by default and when that binary was run by some kind of developer through like a command then they could get RC on the host.

This is one of the main ways. The reason this is kind of limited though is because most of these kernel exploits, they kind of go about they're kind of focused on writing to files that you're not supposed to write on, but that you can already read. But in Docker, you can't read most of the files on the host by default. So that makes kernel exploits a little bit harder and also requires a little bit of misconfigurations like being able to look at some of the files in the host.

So that's something that you kind of need as well with this kernel exploits, but also a very good avenue for attack. And then I think honestly the best way to escape containers, which is some kind of SSRF chain. So I mentioned before that there's a certain degree of isolation between apps in terms of getting files, right? However, in terms of the network, so the way we can send like HTTP requests or TCP requests, there's actually not that much isolation unless it's specifically coded in by the developer or like configured by the developer.

Generally, by default, all these things can actually talk to each other, which is a great thing to leverage, especially if there's a neighboring app and we want to escalate to him. But then if it's vulnerable to some kind of attack or there's an exposed port, which there actually often is, then maybe we can, you know, jump to that one and see if there's any other things that we can try there. Maybe that container has more privileges.

Maybe it has more user data on it. I think this is also a very good way. And this is the way I'm going to focus on in this video. Um, and in these these two I'm going to focus on in the Kubernetes video. Now I'm going to jump into the live example. This is our live example. I'm down here. By the way, I'm in the bottom right corner this time just because when I have the camera in the left corner, it just blocks the entire shell.

And I definitely didn't record the whole video like that. So anyway, when I just the camera here, it feels a bit awkward, I know, but anyway, this is the Docker file. So this is the way that the application is built. And this is the application that we're going to be looking at today for the container. And this is the actual container itself. And this is the way it's built. Docker takes this docker file from the beginning.

And it just simply executes the commands that we wanted to and kind of prepares the container. This ensures that every container is the same, right? It's running the same version of Python. Each of the files is in the exact same place. The user groups are the same. There's the same stuff installed and those kind of things. Just install. Just make sure that you can basically copy the container over anywhere. Pretty nice.

And you can just see the way I've just kind of set it up here. It's just going to be running Python. There's a Python app. I've installed some things that are going to make it a bit easier to to to navigate around the container later on and show you a few other things. And then there's some binaries running and stuff like that. It's just a classic Python app. And the way you deploy it is you run docker build and you build it into an image.

So if I go docker image ls I have the docker engine installed on the server. You can see the images on the server here. And these images are these this image was actually pulled from the docker registry but these images are my own. So they're for lo and this computer. There's like other supply chain attacks you can do here, images, but we're not going to get into that anyway. But yeah, with these images, once you build this image, the image is like a more like compact version of it, like a set of instructions, then you can run the image and you can run it on whatever computer you want by just typing in docker run.

And once you run the image, you'll be able to do docker container ls. And you can see that container here is running. Now important thing is that when you're starting the container, maybe I'll actually show you. Oh, let me see if I can spawn in the command in. Okay. Yeah, this this was the command to run this server. Yeah, I think it was. Yes, this is the command. When the developer is deploying this container, they have to specify what port on the host they want to expose.

In this case, my port is 13712. And that port gets forwarded to another port inside the container. Port in this case 880. In this way, we can have two containers using the same port 880 no matter, you know, what service they're on. But we can have different ports on the host being forwarded. That's really good for that kind of separation. Now apart from this the developer can also forward environment variables into the container by doing enables and passing in usually an environment file.

That's quite useful for containers that need something like AWS access azure or you know Google cloud or something like that for storage. So that often happens as well. And then the container simply runs in the background here. the container runs in the background of the server and it basically keeps running until you get stopped or until it crashes. So that's basically how that works in Docker. It works a little bit different in Kubernetes, but I'm going to talk about in the next video with like stuff like health checks and stuff like that.

That's also quite interesting. But yeah, once the container is running, it's going to be accessible on this port and whatever traffic gets sent to that port will be forwarded to the port in the container and then we'll be able to access the container that way. Now I mentioned about the networks, right? So these containers are you know isolated from each other and they generally can't access files. Well, what's interesting is if you deploy oops right if you deploy the container to by with the default settings so like I just did there without specifying a network it'll get added to this bridge network by default and this bridge network won't allows internet access so the container can basically use your router to access the internet which is important for uh you know stuff like reverse shells if you're looking that as well.

And this bridge driver or this uh bridge network basically once all the containers that are on that network they can talk to each other and they can send TCP requests to each other including the host. So the host is also by default on this network. And the way we can figure out what container is on the is on the network is I think we can go container or decopy it. So, and then we can say describe. Okay, maybe not. Maybe it's describe.

Okay, we can do docker container inspect. Okay, docker container inspect. You can inspect the container and you can see here that it's just on the bridge network, right? Here you go. And if we inspected, you know, the rest of the containers, they'd be on the same bridge or whatever. And in this bridge, each docker container has its own IP address. So if you're on a Docker container and you do 1.127.01 or you try and access local host, it'll by default access the actual container itself, right?

So it's not going to access the host. But if you type in this IP address, that's the same as the local host on on the thing. But each Docker container also has it IP address. So if you type in the IP address of another Docker container, then it's going to try and access that container as well. So there's kind of like, you know, a little bit of networking stuff going on here and it can get a little bit confusing, but you just have to remember that each docker container will have its own IP address and then depending on where your request is coming from, local host is usually the container itself.

The host is actually usually this IP address here. So it's usually 01. to the first kind of entry inside the network and that's what's going to allow us to access the host as well. And then generally it's just going to be incremental where each container added is just going to be you know 2 3 4 5 but we're going to be able to check that later inside the container. So we're going to stay tuned for that. And now we're I think ready to actually hop inside the application itself which is right here.

This is my example app here. Just come in here. I'm going to see what the story is. Obviously, I'm going to refresh the page here. And we're going to see this nice little image request here. We're going to send that to the the replay tab here. Got some nice things going on. And obviously the first step to trying to get privilege escalation on a container is to actually get into that container by itself. So we're going to need some kind of uh command injection.

Basically, we're going to need to find some kind of command injection. Good news is that it seems like we're going to have command injection here. I mean, it doesn't really seem like it, but okay, you have to believe me. There just is command injection here, right? So if we type in like okay I don't know that's going to show anyway what we need to get is a reverse shell and you know from my previous research here I've actually learned that this container uses an an unsafe string concatenation.

So we're going to be able to hopefully go here and we're going to be able to get a reverse shell. Going to go to this generator online and then we're going to be able to put that into the command run. Now get a reverse shell. You need to go into your terminal. Try not to do this from your home computer, right? So when you're getting a reverse shell, you want to use a virtual private server because that's t generally going to have an exposed port at some point.

Your home router is probably not going to have that. Anyway, once you have your virtual private server set up and you're ready to start the reverse shell, you're going to need to have a reverse shell listener. The standard one is called netcap, but I'm going to use something called pawn cat, which I just copy paste over here. This is just like pretty much the same thing, just it has a few more functionalities, but we're going to run that there.

And then we're going to get the command from this website called revshells.com. And this is really nice because it's going to basically allow us to configure it exactly. So what you're going to do is you're going to put your IP address in here, the port that you want to listen on, and then you're just going to copy it here. In my case, it's URL encoded because you know it's um it's here in the query parameters. So URL encoded and once we paste this in, see it's the instructions right there.

And then we send it. If we go back to our shell, you should see that it is actually running right here. Now, you don't have to do this. This is kind of optional, but I'm going to make this shell just look a little bit nicer for that. If we do ls here, you can see we have Python setup. Be able to test that running like a command like like printer or something like that. And yeah, you can see that ran. So that's kind of confirms that Python's running, which is nice because we have an interpreted language and Python gives us a few kind of opportunities to make our shell a little bit better.

Going to take this command right here, which I've just uh tested before. And what this is going to do is just download like a permanent shell. Going to press this. We're going to put this in the background. And hopefully this is going to work. This is a little bit buggy, not going to lie, because I'm running it from my computer. Then I'm, you know, bashing into like this uh this virtual private server and I'm trying to do a reverse shell into this other thing.

So, the terminal can get a little bit confused. Anyway, if we type in FG, oh, what happened there? If we type in FG, hopefully that happens. And then we should be inside the actual shell again. So this should have came back and then now we should have a much more stable shell. As you can see when I do ls now it actually shows it normally. And then the one last thing we need to do is just to fix the clear command to just do this which is hopefully going to allow us to clear the terminal.

And now our shell is going to be a lot more stable and we're going to be able to use tools like nano. That's kind of nice. If you have the ability to do that then I would to be honest do it. Pretty nice. Let's have a look at what's going on here. We have a few things going on. So we have we're in this app server right now and we have you know app.pies running. So this is imagine the front the actual HTML stuff that we can see and then we have the two binaries.

So one of them is called health check. I'll be checking whether the app is running correctly. Main which we're going to investigate what that does in a second. And then requirements.ext. text requirement.ext is usually what's actually installed. So what installs the Python dependencies. That's not very interesting. But anyway, if you do get an RC, the first thing I would do is type in env. And this is literally just going to show you like the environment variables and it just very likely a chance that something nice will show up here like an AWS key or some kind of GitHub API key or something like that will come up here.

And I'd be surprised if you'd managed to get a reverse shell like an actual server and you didn't find something here. Anyway, once you do that, you're on this uh environment variables. I don't find anything here, unfortunately. Like most of this is kind of useless. So nothing here right now. If that doesn't work for some reason, if like the command isn't there, you can try this other command which is available on more minimal builds.

And if that still doesn't work, then you can do cat proc self/inviron. And then this will give you this um this thing, but it's not like deliminated. So, it's going to give you this here. And this should literally be available on every single Linux version. This isn't really a Linux privilege escalation tutorial, but I'm going to show you a quick way on, you know, how maybe to would elevate your privileges from currently we see we are app user to potentially elevating our privileges to so the way we're going to do that is go terminal.

I'm going to have a look and this is very specific based on what container is running and what things are inside of it. But for privilege escalation, we're going to generally have to basically have have to find some kind of file that's running as root at the moment. And hopefully we're going to be able to copy over the shell with root privileges so that we can run it. And so we're going to have a look at main right now.

Just going to I'm going to stop. I'm going to at that. We're going to see what's happening here. This is running standard shebang with bins/shell. And there so while true loop is running health check every 10 seconds and that's running in the background this asterisk here and then is executing with gou as app user this python app. Well, that explains why we're running as app user. Because when we did the remote code execution, we were running in this context of Python, which is running as app user, we've been limited to basically only running as the app user.

And if we try and do something like ls/root, see, we don't have permission to do that. Hopefully, we're going to be able to elevate our privileges. Let's have a look at health check then and see what health check is doing. And you can see all this is doing is just checking if unicorn is running and then it's just echoing healthy or unhealthy. But what a lot of developers do is the mistake that they sometimes do is if you remember the docker file inside a docker file the app was actually getting permissions for this entire app folder.

Right? So read and write permissions. This is very common because apps you know they tend to write stuff in the app folder like temporary data and stuff like that. So a lot of developers will give it read write access but they've put binaries in here that are running as a root. What that means is that if we edit one of these binaries and it's going to keep running and running him then it's going to execute as root and it's going to actually allow us to elevate our privileges.

They're going to just check that is if we go to something like health check. You can see we have read and write access on health check but docker by default always runs as root unless specified. This this main application is actually running as root which is really good for us because if we go back into it you're going to see it's running health check. If we're able to override health check, which we can because we have the privileges to do so, then we can elevate our privileges by copying over the bash shell and then executing it as our user.

Now, how do we do that? Let's hop into nano and let's nano health check like so. And we have it right here. Now, I have a few commands. We can keep this here if you want. Actually, doesn't really matter. What we want to do is we want to take this command, right? and then copy over the bash shell and simply put it inside this root direct inside this app directory where we can actually use it. And then basically second thing we want to do is we want to actually allow our user to that shell like so.

And this is going to basically let us use that shell with root privileges with a special command. If we save that here and we should just have to wait a little bit for health check to run and then once we able to yeah you can see it right here root bash has come up. Now what we do is we do app/root bash and then importantly we specify p. The reason we want to specify this P flag is because currently the shell root bash is owned by root.

And if we run it like so, it will actually convert to our privileges, which we don't want to do. We wanted to keep those root privileges. We specify this P flag and bash. If we go here, now we're inside root bash. And now if I type in who am I, we're root. But we've just escalated privileges just by overriding a binary that was running in the background. Is really nice. This is something that I've seen in like a CTF, so I don't know how like realistic it is, but anyway, I just wanted to show you that cuz I thought it was pretty cool.

Now that we're root, we can obviously do ls root uh and cd root. So weird and like ls this thing, you know, we can basically search the whole folder. I don't know why that doesn't work. Actually, that's good. Does that not work and see root? I'm not I'm not sure why that doesn't work. Anyway, that's not really that important. Anyway, that's how we just manage to escalate. And this is good for trying to get like kernel kernel vulnerabilities because sometimes you need a root to do stuff like mount things which is kind of nice.

Maybe if we do environment, there's like more environment variables here. Maybe we can like you know do other things. So escalating privileges even if it's inside a container can still be useful for getting more information. And this one we'll try to do. But now we're going to actually go into how to break out of this container. For this example, I have a tool called IP address setup which is just going to show us how to it's going to show us some of the IP addresses inside a server.

This might not be installed on a minimal container. So if it's running like just the Python slim, it's probably not going to have this installed. But I'm going to show you other ways to get around that. If this two is installed, then you know, happy days. We can run something like IP address and we can see what's happening here. Right. So first of all, we have this loop back address whatever local host not really that useful.

But the second one is more interesting because you can see it's showing us this IP address. So 1271702 that should show you like 100% tell that this is a docker container because it's you know this IP address is always used for docker containers. This /16 means that we're inside of like a container group inside of the network which goes from 01 to 0 to 06. So there's 16 possible containers there which is basically the whole network.

Right? So that's how many containers there possibly is. And each of them would contain an actual an actual container as well. And that's going to be very useful for when we want to fuzz this, which is nice. So now we know that there's those IP bands. So we're going to have to check them. And then we have to check all the ports inside that. Now one more thing you can do is run IP neighbor. And this might show you some more containers here.

Now in this case, it's only going to show me 01, which as we know from before is actually the host. We can potentially check if this is the host by doing something like this. Curling dot like this and then seeing if that port that we're actually accessing is going to lead us to that to our IP address, which right now, for some reason, I don't think it's going to. That's weird. Anyway, that's something that we could do and what we want to do now is try and find those vulnerable containers.

I mentioned that containers generally incrementally go up in the server. So, the next you know possible thing to check is going to be let me check the IP address again is going to be the container right above it which is 03. So if we go to something like curl http and then we go this port right here, it's not going to connect to port 80. This is this is our one actually. This is uh here. And in this case, it's also not going to connect.

But you know, that's only port 80. There's a lot more ports than just 80. Basically, we're going to have to look at it. You can actually check like I think you can actually check like this. This is probably a better way to check it. And yeah, this is in this case going to give us back our server. You can see that this is connecting to our actual Docker container. Now, the way you would have to do this is unfortunately you would have to scan this.

I don't think there's any better way to check what ports are visible. And in this case, I know that port 2197 is open. So, what what I would do in this situation is just write a bash script that just basically runs through 10,000 ports. I just don't have time for that. So, we're going to just go like this. And this case, all right, it's port 2173. All right. So, we're on port 2173. And you can see we have access to this container here.

Now, interesting. It says specify a path. Now, sometimes in curl, it just gives you these kind of stupid results. So, I always like to give a verbose info cuz it's actually going to give me back the responses as well. You see, it's trying it connected to it. It sent a get request and these are the responses and it's running as well. So this is a Python server running. You see it's running veto which is the unicorn server usually and it's running Python 3.1.14 which is nice information.

And let's just come back with the HTTP request and it says to specify a path. Specify a path. Let's see what happens if you specify the path that it wants us to. And oh seems like it's actually gotten back with the path. So now we have a local file inclusion vulnerability on this container. So we've managed to pivot from one container to the other. Really nice. What a lot of times you'll see here is you know like exposed admin containers is a big one just because a lot of them are running on local host or like on the behind the firewall.

So, what I would do is if you do manage to find like a container with HTTP, Google what the default admin port is and then try and fetch him. It'll work a surprising amount of times, trust me. And once you do that, you can basically start looking to escalate, try and take over the container, which is nice. Anyway, we have a local file inclusion here. And we're trying to read. Let's see if it reads directories. Is it directory?

It does not seem like it reads directories for me. probably this app directory maybe we can read like environment a not found in this case I know that there's a flag text here which we'll be able to read so if we read that hopefully it should give me the flag text somewhere reading it maybe it's empty maybe it's flag oh no I think it did actually print yeah I'm pretty This is the flag actually. Yeah. So, it did indeed print the flag.

So, it managed to escalate via SSRF there. Now, if the IP command isn't available, which a lot of the times it won't be, there's other ways to see if the container is actually has other containers on it. One of the things you can do is you can run this command which was available on every single Linux container, no matter how minimal it is. this cat/et-hosts. This should show you at the very least what IP address you are.

So in terms of the Docker container, it should show you the IP of your Docker container and it'll show you a few other nonsensical things. Then once you have this, you can check using something like curl or net. You can just check an exposed port on the server and check if that actually check if that actually works. And if it works, then it's good. Now generally it's going to go from like 1 to 16 and then 16 to 32. There's generally like standard brackets and it's generally going to be the same if a developer configures a different network but then it might not be good.

But there's other things that you can check. So you can check things like the AWS metadata which since the server is sitting behind a firewall it could have access to. There's other metadata servers like the Google cloud one as well and you know the Azure ones as well. So you can have a look at them and then you can also try and hit the host which is going to be generally open and you can try and pivot to the host from there if you can't find any more Docker containers and yeah that's kind of most of what I wanted to show you today with Docker containers.

So I showed you this showed how developers deploy Docker containers and then I showed how you can do a bit of privilege escalation on Docker containers and then some of the SSRF gadgets that you can use to first. Yeah, I hope you enjoyed this video on containerization. The first part of the two-part series, this part covering Docker containers and the next part covering Kubernetes. I think this is actually a very interesting area particularly in software engineering at the moment because it feels very structured and it's I think quite intuitive to understand the kind of concept of containerizations.

So you can still see that it does leave the door open for security vulnerabilities and it is particularly easy misconfigure some of these things especially when you have these Docker containers you know running in conjunction with other containers and then the network and stuff and then you know you left a port open and there's like an RC on that port and like you know that can definitely happen and it can lead to these kind of chains of attacks that allow an attacker to escalate which is very good for us obviously as bug bounty hunters So definitely look out for these vulnerabilities.

And stay tuned for the next video on communities which is going to get super interesting and I'm going to show you how I'm going to try and keep these cluster. I'm definitely looking forward to stay tuned for that episode. And anyways, if you have any feedback on this video, if you would like me to do something differently or if I, you know, explain something too fast or if you think that hex was too small, then please leave it in the comments below as I, you know, I really enjoy reading your feedback and I want to provide the best content for you and for the, you know, people that are trying to get good at book bounty as well.

Yeah, that's it for me. Thanks for watching and happy hunting.