Since the 28C3, there has been at least one capture the flag every year, so the next

three speakers that we have are always organizing a capture the flag. They are here representing all their team. Please welcome with a huge round of applause, Andy, Zaelu and Malo.

Hi everybody. So yeah, again, welcome from our side to our talk. What the Flag is CTF. This talk is going to be a foundation talk, and we want to tell you what a CTF is, how to play it, what game modes there are. This is the first part of the talk, a bit of an introduction, and after that, we're

going to show you three challenges that we prepared for this year's CTF. So should you actually decide that you want to play a CTF in the future, you know what to expect when you actually play it. Yeah, so a few words about us.

Our team is called Eat, Sleep, Pwn, Repeat, or ESPR for short. We are a CTF team, and I don't know how long we even exist. It must have been like three or four years now, maybe even five, and we are all just people who in our free time were interested in IT security, and we got together in hackerspaces

or the university, and we just started playing CTF, and everybody participated, and that's, well, how a group formed, and now we are Eat, Sleep, Pwn, Repeat. Yeah, that's all there is to it. I'm always talking about a CTF, but you actually don't know, maybe you actually don't

know what a CTF actually is, so CTF stands for Capture the Flag, and for the older ones of you, this has nothing to do with the Unreal Tournament game mode, except for the name, and that there are flags. A CTF is a contest between different teams where all the teams solve different challenges

that are somehow related to the IT security domain. A CTF usually can be played in two main game modes. Of course, there are variations to them, but these are the two modes that you generally have. The first one is the attack and defense style, and the second one is the jeopardy style. So you see in the next slides what I mean by that.

Over the years, it's absolutely crazy how the community grew. When we started playing, there were just a handful of CTFs per year. Now if you check out how many CTFs there are, you can actually play a CTF every weekend, and all these CTFs are usually organized by other CTF teams, so there's a lot of

work also done by other teams to organize these CTFs, and it's essentially all completely community-driven, and if you want, you can relatively easily be part of that as well, and that's what the goal of this talk is, essentially. Now I mentioned the jeopardy style CTF that is the easiest game mode that you have, and

it's also the easiest to organize, because it resembles a Jeopardy game, the American game show, where you have different categories of puzzles with different difficulties, and

according to the difficulty, you're awarded a certain amount of points when you solve that challenge, and either the amount of points is fixed, so you get, I don't know, 100, 200, 300, 400, 500 points for a challenge, according to the difficulty, or nowadays

often we have dynamic scoring, so the more people challenge, the more often a challenge is solved by people, the less points you're going to get, because it's actually relatively hard to define what your challenge should be worth.

And to play that game, it's actually really easy. You just pick a challenge, you look at it, you try to solve it, you submit the flag on a web interface somewhere, you get points, and you just repeat that until you solved everything or you are in the first place. And of course, the winner is the team with the most points.

If there is a tie, the team that got first to that amount of points wins. The typical categories that you have on a Japanese-style CTF are stuff like, for example, Pwn, where you have classic binary exploitation, you get some network service somewhere and

you need to connect to that service and do some weird stuff to it to get code execution and run your own programs on that machine that you're owning. Crypto, custom crypto algorithms that are implemented or crypto algorithms that are used in a wrong way that you need to find out why that is, and then you can use that

to usually decrypt something or recreate a key or whatever. Web, the usual stuff, that's normally just web applications in all kinds of different frameworks, and server-side, and client-side, and whatever that all is.

Or if you're ESPR, we had a joke category once, I think, where we put browser exploits in there. So it's not really web, but that was just a joke. And then stuff like reversing, for example, we have to reverse engineer some executable and try to find out what it does, and reverse engineer some mathematic calculations

and whatever. The next game mode is attack and defence, and that's the more classic mode. There are just a few per year because it's very hard to organise, because you hack, in quote marks, real services on real servers, on real networks, because every team

gets a virtual machine image which essentially is a server which contains services that are specifically crafted for that CTF, where somebody placed bugs in there. And all these machines are connected over a VPN, and the teams can reach each other. And the goal is that everybody hacks the services of everybody else and steals data

from these vulnerable machines, and then you can submit that to a game server, and then you are awarded scores. And of course, if you have full control over the machine, your task is also not only to exploit the other teams, but also to fix your own stuff so that you don't get exploited

anymore. Also, you need to make sure that your services stay up, because if they are down, usually you don't get any points awarded for flags you steal and stuff like that. So there are three main things you need to do. You need to fix your stuff and remove the bugs.

You need to find the bugs and exploit them on other people's machines, and you need to keep everything online. As I said, the main scores there are usually offense, defense, and SLA. That's what I mentioned. Either attack other people's services, defend your own services, and keep them online.

This is usually played in rounds. Every round starts from scratch, and you get points awarded per round. And after that, all the points are added, and the team with the most points wins. There are a few things that are different in every attack and defense CTF in terms of

the rules, but that's the general stuff that always happens. This is what a typical scoreboard looks like when you play an attack and defense CTF. This for example was from Roo CTFE. And yeah, I took the one where we were in the first place. And you see in the different columns, you see all the services that are available, like

for example, a crash, the bin weather, cartographer, and so on. And the red and blue boxes mean the service is up or is down. It can see how many flags we scored, what the SLA was in percent, so how many uptime versus downtime did we have, how many flags we lost.

That's the number in the bottom right corner in every box, like minus 32 for crash. So we lost 32 flags there, and we stole 15,000 flags. And then the FP is just the flag points. You add everything together, and you get your main score and a ranking of the teams.

So now that you know how to play a CTF, why even do it? I mean, yeah. So it's relatively obvious. It's pretty cool to play, because you can actually hack stuff completely legally, because well, that's part of the game.

It's fun to learn new stuff, and you learn a lot of new stuff during the CTF, but also after the CTF when you talk to other teams and try to find out what the solution was and everything. And yeah, you make friends during that.

For example, one of our friends is the Polish team Dragon Sector. And every time we meet, we have some beers, and we chat about the CTF and everything. And we actually made some good friends there. And also, you may be able to travel around the world. So CTFs are held locally sometimes.

You need to qualify for it. And then you can fly around the world and play locally a CTF and maybe even win something. So yeah, our CTF that we organized, we do this, as already announced, every year since

28C3. I can see a few logos there from the past years. We always try to match the Congress theme. And this year, in the main CTF, we had 636 teams that at least submitted one flag. We had a small task that we call sanity check, where you just needed to paste a string

into the flag box just to see how many teams were online. And yeah, that was 636 teams. We had 30 challenges, and these 636 teams solved them 1,457 times. 1,457 flags were submitted by all the teams on all the tasks.

We also had a few guest challenges this year. So not all challenges were made by us. So we would like to thank Kokuyo, Titties, Jay Voisin, Kubaza, and Yuanshin for ideas or even complete challenges that we were able to deploy and had the people solve. And the three winners are KGC and Macaroni, Pastan on the second place, and Dragon

Sector on the third. So yeah, congratulations again to them. And because every year these CTFs got more and more complicated and very hard to solve

for beginners, last year we introduced a junior CTF with easier challenges that more closely matches the difficulty level when we started, actually, when we started playing CTF. And there we have the same staff. We had 520 teams, so not that much teams, but 33 challenges that we deployed and 2,761

solves in total. So they solved actually more stuff than the main CTFs in terms of raw numbers of challenges. And again, we had some guest challenges by Gehaksel, Dominuk, Prom and Troldemortet,

so thank you. And the winners are Made in MIM, the second place is SnO, and the third one is Zenhag. And so now that you know what is going on during a CTF, what do you need if you really

want to play? So the first one you need is actually, you need a CTF. There is a cool website that's called ctftime.org. You can check it out and get a listing of all upcoming CTFs, and you can just register on that CTF, and then once it goes live, you can play. In terms of skills, you don't need that much.

You actually need to be able to program. You need to know a scripting language to do all your dirty work, like if you need to parse a file, or if you, I don't know, dissect some network traffic, stuff like that. For reverse engineering and binary exploitation, you absolutely unfortunately need to know assembly language and a bit of reverse engineering skills.

To tie all that together, you need the basic Linux shell skills because the tools on the Linux are just, well, better suited than on Windows. Of course, you can just use the Linux subsystem nowadays. It works the same. To learn pwning and binary exploitation, you can play so-called war games. On the last slide, there are a few links.

You can check them out. There's one up there. So the war game is essentially a CTF that's always online, and you can go through it at your own pace without any time restrictions. You can check out older CTF challenges. There are archives on the internet. You can just download them and run them locally and try to exploit them.

And it has been, so there are so-called write-ups by other CTF teams. Sometimes, when another CTF team solved a challenge and they thought it was a cool challenge, somebody's going to do a write-up on that and explain in a blog post or whatever how it was solved. So you can read that and learn stuff.

If you're more of a video person, there's somebody on YouTube called Life Overflow from the CTF scene, and he's doing awesome videos on different CTF tasks, and he goes through it like how he solved it and what the idea behind the challenge was and so on. And of course, you don't want to play this alone because it's more fun to do this with other people.

And just use the internet, try to find groups, try to find like-minded people, or just go to a hacker space and ask around if somebody's interested. And every now and then, you can play a CTF or do the war game stuff and so on, just like we did. Okay. Now that we explained to you what is going on during a CTF, I'd like to hand over to

Male, who's going to show you some challenges we had. Okay, hi. I'm going to give you an idea of how to approach such CTF challenges, and I can highly recommend this book from G. Paulier on how to solve problems.

And as an example, I took a challenge from the junior CTF called Blind, and this is the description, hacking blind and an URL with the path to the flag, and it's estimated as a medium difficulty challenge, at least in the junior CTF.

And it's based on a bug found by Ripstech in 2017. And approaching a challenge, to approach a challenge, it is needed to understand the

problem first, right? So when you go to this URL, you are presented with this source code. It's PHP source code, and we're going to walk through it. The first part of the source code is actually a hint. It's not needed to exploit the challenge, but it's hinting to a vulnerability called

PHP object injection. And this actually was a bug where you could include local files until PHP 5.3, but we use PHP 7.2.

And the next block is a bit of boilerplate code. So we have two classes called black and green, and what they do is only setting the colors of the syntax highlighting, and if you provide a store URL parameter, you can save

the theme in a cookie, which comes, which is important for later. So the next section was an interesting part because it hints already at the path to exploitation. The first one you get in the first step, you get the theme URL get parameter and store

it in this variable. In the next slide, in the next line, you check if it's either the black class name or the green class name. Then you check if this class actually exists.

You set the variables, depending on the input from the URL parameters, and this is the interesting part. Now you instantiate an object of the given class, which could either be black or green, and you have full control over the parameters you give to the constructor of this class.

The next part of the code was also storing the theme, but this time from the cookie, and then you check if the first part of the cookie is an existing class.

Then, sorry, then you pass the parameters which are stored in the cookie to the constructor of the class, and you instantiate an object of that class.

And the last part is just giving you some info what modules are loaded. So the bug was simply that you could instantiate an arbitrary PHP object, and you control the arguments for its constructor. So the next step is to make a plan.

So we try to get together all the things we have given and what we want to do. So we have fully control over the data in the cookie, and we can instantiate a PHP object of an existing class, and we control the arguments.

So what we have to do now is we have to find a class which does nice things like reading a file when giving specific arguments. And there's this handy class called simple XML element,

which is able to read files, XML files, from a remote source if you set the option to two. It will even substitute entities in the XML file, so this will be important later.

And now we have to carry out the plan. This is the easy exploit. We set a cookie called theme. The first part of the cookie is our class name, simple XML element,

and the second part is the path to the flag. And as you can see, the flag is printed in the warnings right there. So this only works because warnings were enabled. So the next thing you do when solving problems is looking back and

how could we approach the challenge in a different way or with different constraints. And if the warnings weren't enabled, we were kind of blind. That's where the challenge name comes from, and we don't get output.

And with XML, you can include external entities, and it works like that. You declare an entity and give it a path name, and then you yeah, you include it in the XML, and this is how you could exploit it.

So you get a second XML file from your own server, which is at the bottom of the slides, and it gets the flag and sends its contents to your own server.

So when you execute a simple exploit like this, you start a PHP server, and then you call this URL with cURL. You get presented with a request that looks like that.

And because we encoded the flag with base64, we have to decode it, and then you get the flag this way. So next part is for the main CTF by Saelo. Yeah, thank you.

Okay, yeah, thanks. So now you just saw an example of a rather typical web CTF challenge. Now I know we have a lot of teams that are really, really skilled. They have been playing CTF for many years.

They do computer security as their day-to-day job, and so of course we also want to make very challenging and interesting CTF for these teams, right? And so one thing we do is we try to make somewhat realistic challenges based on real-world software and vulnerabilities.

So yeah, on this slide you see some logos of software that we base challenges on in some way for this CTF here. Now one fun fact, we actually this time had three different teams use zero days to, instead of solving the challenge in the intended way, they use zero days for the software, which is fair game.

Yeah, I don't know what that says about our CTF, but it's pretty interesting. And so what I want to do now is just, we'll present two of these challenges. I'm going to present a browser exploitation challenge a little bit and talk a bit about the setup, how to host such a challenge, etc.

Yeah, so we had browser exploitation challenges the last two years already. For some years now, a browser, they come with a sandbox, right? So if you just have one vulnerability in the rendering stuff

where it renders the HTML, that's not enough to fully compromise the browser. For the last years, we only had the rendering exploit part, so the real browser stuff, but no sandbox. Now this year, we decided we should do a full, like a real browser exploit challenge with two parts.

One part is the rendering exploit, the webkit in this time, and the other part is the sandbox escape. And we based that off of real exploit chains that were presented this year or last year. So how do you make such a browser challenge?

What we did is we took webkit this time. Last year, we had Chrome and the year before Firefox. So this year, we used webkit, which is the browser engine powering Safari, for example. And we changed, we implemented some buggy optimization somewhere in the JavaScript part.

So this is the first thing, that there's one vulnerability there in the webkit. The next thing we did, we wrote some Mac OS system services, again, kind of based on real vulnerabilities that were presented this year. And so they were, of course, also buggy in some way.

They had some vulnerabilities. And then we deployed both the modified Safari and those system services to a Mac OS virtual machine. And so then what users can do is they get, on the top right here, you see that they get a website where they can submit a URL to their exploit. So it's a browser exploit.

So the exploit is going to be some web page. They can type in the URL for the exploit. And then what happens is on our servers, it will boot up this virtual machine, open Safari with that URL, and then the users will get back a video

of that virtual machine booting up. And then the goal of the task here is to read slash flag or slash flag.txt. So some file on the file system. And so what they could do is they could display it on the screen. And so then they would see it in the video. So yeah, here's pretty much how it looked like

from a player's perspective. What they would do for this challenge is they would get from us a webkit patch and those Mac OS services as binary. So they would have to reverse engineer them. So then they go and audit for vulnerabilities, hopefully find some, and they would write exploits.

So in this case, it's a malicious website. They will host that on some server that they control with a public IP address, and then submit this URL to our scoreboard server thing. And then again, that boots up this virtual machine, records the video, and shows the video to the players.

So here's how it looks like. I hope it works. Yes. So this is exactly what the players would get after typing in the URL into the scoreboard. So they would get this video feed. So let's see what happened here. Yeah, in the background, you see the modified Safari,

which is opening the player's URL. And it's printing some stuff from the exploit, blah, blah, blah. And then it does a WebKit exploit, so it can now run attackers code in the WebKit process. And then it's exploiting these system services that we wrote,

which are running outside of the sandbox. And so then it can open or run any commands outside of the sandbox on the system. So in this case, the exploit starts this text editor app and lets it open slash flag dot txt. And it's probably pretty small, but in the top left, you can see there, it's showing you the flag,

and now you have to type this into the scoreboard, and then you get your points. Yeah, so why do we think this is a nice challenge? Or why do you want to solve this? Of course, I mean, this gives you lots of points for the CTF. This is actually not one challenge, but three challenges.

So we made it so that you could solve the sandbox escape part, regardless of whether you had this WebKit exploit working. So there was one flag that you got, if you only had the WebKit, the Safari part, there was one other flag that you get if you only have the sandbox escape. And then there's a third flag, if you have both

and you combine them into a single exploit, yeah, then you get the third flag. But yeah, apart from CTF, so we try to also make these challenges so that you are able to learn something new maybe, right? So the WebKit part, it could hopefully teach you,

or hopefully you would learn a little bit more about JavaScript or just-in-time compiler vulnerabilities on the path to solving that, or the macOS services. Yeah, we made them so that it gives you an easy entry into macOS security, right? So this is something to keep in mind.

We will release source code. So for this challenge here, it's gonna be up in some hours probably on my GitHub. And then, yeah, it tries to make it easy to transition from the CTF and maybe go to the real-world security scene

with challenges like these that give, yeah, with source code, give you a nice entry. Yeah, and that's it from me. And next up is Andy again. I also did a challenge or two, and those of you who are old enough,

you're going to remember this phone, right? So the story behind my challenge was that I privately was interested in GSM stuff, and I just wanted to know how stuff works and so on. So I set up a GSM network at home with a software-defined radio and everything, and used old Nokia phones and so on, and then I got an idea.

I built my own phone. What you can see here is part of the challenge. You can see that I re-implemented the UI of a Nokia phone essentially, and it logs onto a GSM network, which is not using radio waves, but the GSM traffic is sent over UDP multicast traffic

in the core network, and then I also have my SDR on there so that my own phone can talk to the real phone. That's what you just saw. And I found this feature of that challenge where you don't have radio waves

for communication with the GSM network. It's usually used for unit tests by the developers of the network services to run your own GSM network, because they don't want to mess with radios and everything just to test their software. So they implemented this Ethernet layer to do GSM,

and that was perfect for a CTF challenge, because we don't only have local players. So in theory, I could just set up a few SDRs and transmit my own GSM network if you have the right licenses, and so to do so in the RF spectrum,

that being another issue. But in theory, you could do that. But somebody from the US or wherever else is not able to participate in the challenge, and we always want to have the capability for remote players to play as well. So I set up an open VPN tunnel, essentially, where the network lives in,

and your own phone, this target phone that you could exploit, just then join the network using this UDP multicast stuff. So that was absolutely perfect for that. So what I implemented actually is a bucking concatenated SMS. The phone only has two features.

It can send SMS and it can receive SMS. And your task was to have a phone somewhere on the network that you can only interact with over in the network. So you can only send it SMS, essentially. But you can send it arbitrary SMS. You can send whatever you want.

You can adhere to the standard, but you can also send whatever you want and not adhere to the standard, and two weird stuff. And on the old Nokia phones, on the later ones, SMS only had 160 characters. And on the later Nokia phones, you had this thing on the right where it told you how many characters you have left for the SMS,

and then a slash, and then how many SMS you already wrote, essentially. Because what it would do, it would split the SMS message apart every few hundred characters, and then put a header in front of the SMS, send one, two, or three SMS to the other phone, and then the other phone would start to reassemble these SMS

once they all arrive. And yeah, so in this case, the SMS can be split up into up to three parts, but the standard allows up to 254 SMS, actually. So, and all these SMS contain some data, as I said, in front in the header,

and they also contain an index, what part that actually is. It starts from one and it goes up to 254. In this case, you can use one, two, or three. And the SMS content that I'm going to reassemble is somewhere in a local stack buffer. And the location where the decoded text

from that one SMS part is copied to when reassembled is based on the number of the part of that SMS. And in my challenge, I'm never checking if that number is actually one, two, or three. So you can set it to four, five, six, seven, eight, whatever, and you would write outside of that buffer.

And because that buffer is on a stack, the way how processes work is they save some information on the stack to keep track of where they were before they called a function to return that location once they are done with certain tasks. And you can override that value and hijack the control flow,

and then use a technique called ROP to gain code execution on the phone and execute some code there, much like Zaylo showed with the browser where you open the text editor, you can connect to another host

and get a Linux shell essentially on the phone, and then you can open the flag. With that, that was the talk. I would like to thank the whole CTF community, the players that played our CTF, other teams that organized the CTFs, and everybody in the CTF community for being that cool

and putting that much effort into not only playing our CTF but also organizing CTFs for us to play. And I also want to thank the assembly team here at the C3 because we got our own area this year where all the CTF teams that were locally could gather around,

and it was absolutely perfect. It looked so cool seeing like 200 hackers sitting on the tables in a space together and just solving our challenges. It was absolutely amazing. And thanks again to our guest authors for the challenges, and we would be open for questions and answers now.

Oh, and one other thing. If you are interested in playing CTF, here are a few links with the resources that I mentioned earlier. Check them out. This is Wargaming's CTF time, and it's Live Overflow's YouTube channel.

Check it out if you're interested. And yeah, we hope that you're a part of the CTF community soon, maybe. I can already see that there are some questions in the audience, so I would like to start with microphone number two. Thanks for the talk.

Actually, my university security course was a graded CTF. We got the grades based on our points on the CTF. What are your opinions about this kind of grading? How do you feel about university learning places

doing CTFs for grades? I mean, for us, it's a hobby, and also for us, it was a great way to learn new things. So I'm personally not completely opposed to that. I don't know if I would maybe make the grading dependent on the points,

but I think it's a great thing to do just as a learning experience. So no matter if that's on a university or if you do it in a private life, if you just play, you're always, like we also, when we solve some challenges from other teams, we are always learning new tricks, new stuff, and so on.

So I don't think it's a bad idea. Thank you for that question. The next question is coming from microphone three over there. What do you do when you are stuck on the task? Oh, good question. Often, it helps to get somebody else from the team.

Just take a break. And go with somebody who is completely unaware of what the challenge looked like through your findings, and just talk about the challenge. Either the other person still has some more ideas to try, even though that person might have never looked at the challenge, or you are reiterating everything that you have done over the last few hours

by just explaining it to somebody else. And maybe then you get another idea where to look out, or I don't know, just start googling stuff. Maybe there was a similar bug in some other software. There are multiple things to do, but it also happens a lot of times that we are not able to solve a challenge.

So playing CTF can actually also be frustrating, because you're sitting for 12 hours on a challenge, and you just can't make this thing work. And you have no idea how to solve it. That happens as well, because you're just missing a trick. But what you then do afterwards is you ask other teams, you ask in the IRC channels of the CTF how that was solved,

you ask for write-ups, you read the write-ups, you ask other people from the team when you see each other next time in person, for example, here at the congress, and so on. And that's how you gain more and more knowledge and experience over time, and learn new stuff. We can take one more question.

There is someone waiting at microphone number two again. First of all, I think, is this working? Okay, sorry. First of all, thank you very much for hosting the CTF. It's highly appreciated also that you're doing browser exploitation challenges, given that it's really hard to set them up and host them for everyone. My question is, what's your take on having people solve challenges

in real-world software that you didn't modify, as in, like, implicitly disclosing bugs in software? I'm not sure if I got the question. So you mean people using zero days for solving our challenges? No, we're not.

I mean, all the challenges had modifications that... So they had an intended solution that's not in ODA. It's real-world challenges, right? So it doesn't really get more real-world than using in ODA, so we are not against that, except if it's against challenge infrastructure, which is not the case here.

So it's fair game for us. I guess the players, they trust us, and they trust that nothing happens to their ODA's, so that's why they do it. Or some of them, but... Yeah, so also I think we can all agree that even if we have an ODA, it's still the right thing to do, would still be to responsibly disclose

and not put it out on the internet to put other people in danger. I mean, that's just... I mean, I never saw that actually happen during a CTF, that there was some leaked ODA that suddenly got in the wild and endangered like normal users. That so far this never happened,

and let's hope it stays that way. I mean, it would be bad if it would happen, you're right. Thank you very much. Unfortunately, the time for question and answer is over, but I'm pretty sure the speakers will answer all your other questions after the talk. Please give a large round of applause for Andy, Male and Sayelu. Thank you.