 We're about to start the next talk right here. So I'm very happy to introduce Hanni Miel, who's going to talk a little bit about the struggles you're facing when trying to find the next capture of the flag adventure and how he is proposing to solve them. So please join me in welcoming Miel. Thanks. Yeah, so I'm going to talk about about CTF in a box. It's the story of what problems we found when playing CTFs in terms of the framework, how we tried to solve the problems. We built a prototype, tested it, and the problems that came up after that. So first, who am I? Well, I'm Miel. I am Hanni Miel on most platforms, studying computer science at Düsseldorf, and playing CTF with FlexOrela, or sometimes as a single player. And let's start with the current solutions. Because when playing CTFs, we currently have about three main platforms we play on. The most used framework currently I'm seeing is CTFD. CTFD is the first thing you find when googling for, hey, I want to host a CTF. What do I do? And the second thing is hack the box. That's another case study for another framework for hosting CTFs. But you can't use it because it's actually a closed source, so you can just play with them. And the last solution are custom frameworks. So these are frameworks used by teams. They build them themselves like at this year's CTF. So CTFD looks like this. People who may have played CTF may have seen it, because most CTFs are hosted on using CTFD. And overall, it's pretty basic. It looks a bit bootstrappy. And I'll come to what the problems are later. Hack the box. So the people who have seen it looks like this. This is the machine view. Because hack the box differentiates between machines and challenges. Challenges are like simply files thrown at you where you have to find the flag. And machines are a bit more. It's like you've got an actual machine need to find flags in the actual services running on the machine, so it's a bit more. And custom ones, like this is an image of the current CTF running at 36.3, organized by HXP. It's pretty much a CTFD, but built by their own. So what are the problems with this? Well, let's start with CTFD. There aren't actual problems, in my opinion. It's mostly static hoster for files you want the people to use for the CTF and some custom infrastructure for a scoreboard, for registration and stuff like that. So yeah, you could probably use an NGNX for that. Hack the box is kind of closed sourced. I say kind of because you can actually use it. You see how it's built up, how you spawn things. You could build it yourself. That's what we did. And the problem here we had was when playing Hack the Box, we had some reverse shells in the root of the challenges and other problems, like multiple people writing into some challenges and some files were just there that shouldn't be there. And that was really annoying sometimes, like we started a challenge and saw, oh, there's a reverse shell for getting root in root. We don't have to do anything. And they are shared challenge instances. And a problem we saw with that, that was you have multiple hundred people playing the same instance. We had the problem at Alice CTF during the camp where we also found a little problem where we could see what other people were uploading to the challenge, which kind of helped us. And we found that could be optimized. And the third problem, well, problem, it's not really a problem, are custom frameworks. You might find errors in custom frameworks allowing to get flags that aren't used to without actually solving the challenge. So it's now a ping-pong between finding problems, finding solutions, finding problems, and finding solutions. And we'll start with the solutions. The simplest solution we tried to implement for our CTF at our local hackerspace was generating single challenge instances for every player or team. This means every challenge we built was simply a Docker container, we spawned somewhere, and for everyone who wanted to play it, we spawned a new Docker container. And we first thought that it might bring a lot of overhead, but it actually didn't. We spawned multiple hundred containers and it all worked out fine. The problem with this is, if you put everything into a Docker container, Docker escapes and sandbox escapes get really useful. So it will be fatal if someone could break out of the container. And we've got solutions for the problems, of the possible solutions for the problems. You can just put everything in a VM, so the challenges are bundled in one VM or use NSJL to isolate the processes. And stuff like that is just a measure to stop the people from actually breaking out. Another solution would be to actually make it possible so that people can break out, so actually you don't want to make it possible, but you don't want the people to actually have anything from breaking out, like custom flags for custom teams. We did that by implementing our Docker containers as we implemented the challenges, so the flags get put into the Docker containers via environment variables. So when you're starting your Docker container, you just set an environment variable with your flag. And in the Docker container, you've got a little script pushing the flag to the place you want it to be, and then unsetting the environment variable and deleting everything else so there's no trace of the flag where it shouldn't be. And that worked out pretty well. So that's the Circus prototype we used, a little story for that. We had the 18th anniversary of our Hacker Space this year, and we thought we'd need a CTF for that. And in the week before, we realized, oh, it's in a week, so we quickly started building a prototype for this called it Circus, because it looks like a circus. And that's a graph showing how the containers interact with each other. And the goal with us was we wanted a place where the teams could register and get a known companion. A companion in our system was like a place where people could go and spawn an individual container because the companion spawns a VPN container and packs all the other challenge containers into that network. So people go, get the VPN config, and can access their challenges. It's really similar to how Hacker Box works. A problem with this was we've got one companion container per user or per team. And we've got N challenges that can be spawned. And if we've got N teams with N challenge computers, we get a lot of containers. What you are seeing here is just a listing of all the containers we had spawned. It was like after day one of the CTF, we had like 10 participants or so. But we had like, I think it was about 50 containers at that point, which was quite a bit. And at the end of the CTF, we had like about 120 containers up and running. So you might think, oh, a lot of containers running, people doing stuff in the containers that must cost a lot of computational power. But it actually worked out. We had set up a virtual machine with like eight cores, 16 gigs of RAM. And it always looked like nothing at all was happening. Until someone set up a crypto miner and had fun with that. So we went on a machine and said, oh, whoa, where's the load coming from? And we identified it. It was some Redis container, someone of a team set up, of me. And yeah, we had some people try weird names. We fucked up the sanitation a bit because it was all really quick. And that's a learning for everything. That doesn't work. Also, the XSS you were seeing here, that the person tried wouldn't work. So it was kind of weird. And we set up a super basic scoreboard. So as you can see, we tried building a CTF framework on our own. It kind of worked. It all was built in a few days. And it was like really shitty CTF-D. So what we want to do now is find out what we want to do and what we do not want to do. So what we wanted to do was allow people to spawn containers with their challenges. So we solved the problem of multiple people acting on one instance of a challenge. By doing this, we won't want to allow them to spawn infinite containers. Maybe some of you have played Alice CTF or Camp CTF. That was pretty fun because there was a challenge, the Nexantec DevOps challenge, where it was exactly like this. You could spawn containers or a set up for you to play in. But you had to do a proof of work. So calculate something so you couldn't just spawn challenge instances as much as you like. Another thing you might keep in mind when doing this, we had to keep in mind a lot was mount the Docker socket or don't mount the Docker socket into everything. As fun as it is to spawn Docker containers from Docker containers. It's like a giant security hole. Because if people have access to the Docker socket, they can just literally spawn Docker containers and do shit. Yeah, do's and don'ts allow players to execute stuff in containers. So just having a container with some static files or so is fun. But we were like, we want to have more. And allowing people to exec stuff in containers can be a problem. But you have to limit what the people can do. And that's a thing. Allow people to do stuff but don't allow them to do too much stuff. And that worked out in our case. But as I said before, we tried it with like 10 people at our local CTF, seeing where the problems get when we put really good CTF teams on it. And if they are able to break out, it would be really interesting. So as I said, don't allow people to do stuff. Don't allow them to do too much stuff. And implement techniques so it works out. And one thing I had to keep in mind, keep in mind, keep things simple. Because during the CTF, I realized we built a lot of stuff. It was a bit over complicated and made things a bit too hard to fix. So I'd keep in mind for the future, if you're building a CTF framework, keep it as simple as possible. So if anything breaks, it's like a five-minute job to fix it. Yeah. So if you're too lazy to listen, let's get a recap. Create new platforms. CTF platforms are really interesting. I found a lot of topics I could work into when building this. And not at the end yet. So there are a lot of things I still need to look into. But a lot of players to play the game and limit the bad stuff. And for people thinking, why Docker? I had that in our local hackerspace. People ask me all the time, why are you using Docker? There are so many known exploits for that. Yeah, finding alternatives was like, yes, I could use the alternative, but I'm used to Docker. So I actually wanted to use Docker, and it was kind of nice. So if you know a better solution, find the solution, implement it, and try out the CTF. Another thing I wanted to say here is that while using Docker, it might be insecure if you're doing stuff. You can implement a lot of stuff securing this, like I said, implementing custom flags for teams. So if a team has got a custom flag, it can't break out of the container and just get the flag from another team because it's really team specific. And that was a thing we wanted to do with the environment variable in the challenge containers because we could start the container as we went. Yeah, so that's actually the end. That went quite fast. What I wanted to say now is that sometime next year, we want to play the Circle CTF with the platform we built, just to try it out, but in a larger scale. So if you're an active CTF player, watch CTF time, we're going to be there sometime, probably, and organize a completely new CTF with fun challenges. I've got some challenges we used for the DoF CTF with me, so if you're really interested in how this might look, how this might be different, what can be done, come to my table at Dagnebola, it's right over there, and we can talk about that. Another thing I wanted to do is if you're interested in discussing a bit of how this could be done better, or so, just drop by, that's fun. And if you've got questions, watching the live stream or so, just tweet me at honeymeal, that works out. Yeah, so that was it. So has anyone gotten any direct questions or so? Or any? Yeah, so we have around six minutes of questions left, so if you have a question in the room, come to either the right or the left microphone here, or we also do have a signal angel or relaying questions from the internet. Does the signal angel have any questions? Give me a quick sign. No, it doesn't look like any questions right now. So thanks again, Emil. You're welcome.