 All right, welcome to the game of hacks. Amit Ashbel is here and he will be taking over. Hi, everyone. Hi, guys. So this is my first talk at DEF CON. So go easy on me, okay? All right. So we're going to talk about something called game of hacks. Some of you may know it. Others may not. We're going to dig into some more details about game of hacks and the platform. In terms of the agenda, we're going to really first of all start by understanding what game of hacks is, what we made it to be, so what's behind it, actually. We're going to have a type of t-shirt contest. It's not really going to be a wet t-shirt contest, so no need for water. After that, we're going to talk a bit about Node.js, which is the platform is based on, the game of hacks based on Node.js, and just a few takeaways. Regarding the game, anyone who has internet connection, don't worry, we're not going to hack you. We just want to have you participate in the game. The ten first places are going to win a cool t-shirt, so hope you'll join. Okay, so game of hacks initially was born by a few of my colleagues at check marks when we were walking around a conference and we saw a few guys just standing in front of a wall. We came closer and we saw that they were looking at a wall with code on it, and it said spot the vulnerability. There was no prize, no anything, but people were just standing there and trying to figure out the vulnerability, so we thought, hey, that's interesting. On top of that, OWASP has published a kind of research that showed that one of their top concerns or priorities is awareness for training of developers, so secure training for developers. In addition to that, their challenges, as I said, are also related to the education and awareness of developers. So we looked at all of these facts, so the CISO facts and the people standing in front of a wall reading code, and we said, okay, let's put one in one together and make something out of it. So we built a game. The game is actually a challenge either against yourself or you can challenge a colleague to spot a vulnerability in code. The idea was initially, you know, just to get people interested. It was kind of a marketing campaign. And within the first 24 hours, we had 35,000 participants play the game, so to our surprise. I'm going to quickly go into the game, so hopefully internet is going to work properly. Yeah, it's working. So this is the game. You get to choose single player or challenge a friend. Once you choose, you have three levels of difficulty, so the beginner, the intermediate, and the advanced. And we'll go for beginner. It starts up. You have the different sections of the game. We'll dig into those in a few minutes. It gives you a vulnerability on the screen, a code with a vulnerability on the screen. If anyone wants to guess the answer, I'll be happy to hear. Out of the four? No? That's a beginner. Come on, guys. You can't read it? Let me zoom it in for you. Too much. Better? I can't hear you. We got 20 seconds left. Command injection. All right. Nice. Okay. So that's the idea. You get five questions. You have a timer, a minute per question. After five questions, there's a leader board. You can, you know, the faster you are, the more points you get. And of course the more answers correct, you get the more points you get as well. But that was not it. So we said okay, this is interesting. We can do more than just a marketing campaign with it. And we thought why not get some more information out of it? We're going to publish this online. And why not gain some honeypot data and understand what hackers are really doing or really trying to do with these types of web applications based on note. And we'll talk about note in a second. So as you can see, immediately our assumptions were found to be correct. And these are some screenshots from some discussion boards. So some of them said, I don't know if you guys can read it, but it says something like game itself was harder than to hack it. Tries to teach security but fails at it. So we actually failed on purpose. We wanted to have vulnerabilities in the game. We wanted people to try and hack the game along the line. We fixed the vulnerabilities, of course, to see if people get more out of it. The architecture of the game. As I said, it's based on Node.js. Client side is either web browser, Chrome web browser, or other web browser. Or mobile device. And then you have the Heroku server with the Node.js server side and MongoDB running. We see that Node.js and MongoDB work perfectly together. We'll talk about that as well. So Node.js, single threaded architecture, event driven. And I just want to quickly go over the idea of Node.js because it's relevant for the rest of the talk. As you can see on the left side, you have the event queue. The event queue actually is what's waiting to be processed. So tasks that are waiting to be processed. In the middle you have the event loop which is actually the brain. So the event loop has the ability to use CPU as much as it wants. However, it will try to send all the tasks to its event handlers to spare time. So every time the event loop gets something, it will pass it on to the event handlers as fast as possible freeing up the next event and the next event. That way the single thread can work very fast and very efficiently. Just to make this a bit clearer, this is kind of an analogy to Node.js. You have the single thread who's the cashier here. He's getting the orders from the crowd, from the queue. And then you have the event handler who's constantly doing the tasks that he's getting from the single thread, the event loop. Going back to Game of Hacks, you have different entities. We have different entities which we based the application on. There are the questions, the difficulty level, the score, the answers, the question number of course, 60 second timer and the code snippet itself. Where the effect on the score is based on the time as I mentioned, the correct answer of course and the speed which was the answer was answered at. Okay guys, I want you to experience a bit of Game of Hacks. It's not going to be only vulnerabilities. I'm going to open up the screen now and I need you guys to either join via your laptop or your phones. I'll give you a few seconds to do that. Just go into kahoot.it, punch in that pin that you see on the screen right now. I see people joining already. Cool. Okay, nice. Remember, top ten will get a t-shirt. Maybe even like mine. All right, that's going better than expected. All right, I'm going to start. You still have some time to join. I think the first question doesn't have any points to it. So let's go. Why don't I have any sound? It doesn't matter. There's no points in this one. Let's move on. Second question, last chance to join. Okay. Okay, from now on it's serious, a bit more serious. So concentrate. That's current, the current leader. Okay, we're going to have three vulnerability questions. Okay, that was beginner level. Can you see the code? That makes sense then. I'll try and zoom in for you. Who's DKS? Raise your hand. Come on. Way to go. That was intermediate level. Let's see how that went. DKS. Nice. All right, last one, last game of hacks question. After that we're moving on. See the results for this one. It is confusing. DKS, what happened? Okay, now these are a bit more relevant to the platform that we're talking about. Not very well done. Okay. Okay, actually the server won't know the answer if the client is doing the random. There's no way for the server to, just a second. There is a way for the server to know the answer but most cases the server won't know the answer. Yeah, go ahead. I can hardly hear you. Pseudo random. We use the Pseudo random. We use the Pseudo random which has its other issues with no JS. You can discuss that offline later but, yeah. All right, I'm moving on. Another question related to, oh, gave you free points. Shall I ask who the three were that were wrong? No, no, no. Stay seated. It's okay. All right, nine out of ten. Very well done. So yeah, the client actually, if there's no validation on the server side, the client can answer the same question multiple times. The solution for that is actually to write a flag saying answer question answered. Sorry. Okay, and the last one before we move on with our talk. So the calculation is on the calculator screen here. 60 minus time to answer times difficulty. If you put in a negative number, your score is going to go very, very high. Okay, so let's finish this off. We have the top five on here. Actually, I don't think I can see the top ten. We'll trust you then. Nah, I don't think Zuma will help. Yeah, I know. That's why I said we'll trust you. All right, so let's move on with the talk. Okay, so these are just a few items related to the questions that we had. So initially, the app send answers allowed hackers or developers or script kiddies to just answer the same question over and over again. And you can see a snapshot. I don't know if you can read that, but it says more or less that you can post the answer for the same question multiple times. And that was obviously resolved by putting up a flag on the server side saying that the question was already answered. The next one was the timer. The timer initially was handled by the client on purpose, of course. We wanted to see if people are going to abuse it. And the timer was there to force the user to go on to the next question when the time ends. So once the timer is on the client side, actually the user can halt the timer and gain time to answer the question. And what you see here is someone who said here's how to hack the hacking game. Pretty simple. In your console, app.send answers answer one time minus 9999999999. And that actually gained a huge number of points which brought this guy to the top of the leader page. And obviously after that we patched that and that was it. The time now was calculated on the server side. We have, it does create a small latency, but not effective enough to modify the scores. There was also one guy who found a nice trick on iPhone, on iOS. He found that if you hold your finger on the timer on the iPhone screen, it actually stops the time. So that's another trick that was circumvented using the server side time validation. Okay. A few more Node.js points to remember. Now these are related more to coding. Node.js is very, very popular. However, it does have its upsides and downsides. The upsides is the single threaded, quick response. Very good for IO intensive tasks. However, it's less good for CPU intensive tasks. So let's see, try and see that in action. I mean, we're going back to this image here. Imagine the guy who has the single thread on his head over there having to do a lot more work before he moves on to the event handler. That would create a huge queue and a huge delay in people getting their food. So same thing goes for Node.js. I'm going to show you a quick sample of denial of service. I hope it's going to work. What you see at the bottom is a small script that we've created that actually sums up the number between one and P where the number can be, the P can be anything you put in. Which is a CPU intensive operation, the more the number, the calculated number is high. So if we put in five, for example, we'll get 15. So one plus two plus three. So on. We get to 15. And let's try and see this in action. Okay. I hope you can see the screens on there. So this is actually going to run the script. I'm going to put the number, I don't know, 50, for example, in here. And you'll see that within a second we'll get a response. That's the calculation. Quick CPU calculation. And that's it. Now we're talking about single thread. So the Node.js can only run a single CPU intensive task at once. So what we'll do now, I'm going to put a large number on this screen here. I hope I'm not going to make it too large because then I might create myself a denial of service. But how many zeros do I have on here? Let's make it like that. Okay. At the same time, I'm going to calculate this for, let's say, five. We'll start this one. And after that I'll start the second one. And what you'll see is that this one, as long as it works, as long as it's calculating, the other one won't be calculated. So it's going to have to wait for the event loop to complete the job. That was too fast. Another zero. Okay. Now you see the one on the right is still calculating and the one on the left is not able to perform its task as long as the right window has not completed the calculation. And that's very simply a single thread problem. And there it is. So once the large number completed, the small number went immediately after that. All right? Everyone clear? Cool. Okay. Another thing with Node.js is that it's very popular to work with MongoDB because of the JSON based functionality that it has. It has the ability actually to take objects, to take JSON values and put them in the request or in the database. What happens in this case is that a user can actually, when you're trying to log in to an application, a user can use these Node.js values or these JSON values to play around with the log in. So this is kind of an SQL injection without SQL. I'm going to try and demo that as well. So we have this login application here. So this is just the login screen. If I punch in, it lets me in, which is great. And if I take this in the URL, it's the same thing actually. I'll just do this admin, admin again. So you see that it works the same way. Okay. So that works. But what happens if I use the greater than tag? So I'm going to use the greater than A, which means that any user on the system, registered on the system, is going to be able to log any user that's greater than A, which is probably all of them, and password that's greater than A is going to be able to log in. So I don't have the admin password in here. Once I click enter, it's going to let me in. You can't see that because there's no difference. So let's try a different letter. Let's try B. And it logs me in as a different user. So what I've actually done is I've used a JSON parameter, a greater than parameter to overcome the validation, which is kind of a JSON injection. All right. One more thing regarding to JSON. Because of that ability to use the JSON values, you can actually use a lot of JSON values. One of them is regular expression. Regular expression is highly CPU intensive. And as you can see, or as you can remember, the Node.js is very, very sensitive to CPU, heavy CPU tasks. So if we take this line, for example, and we're going to go again, we're going to go again to that login page, we're going to see that we can cause a denial of service or a regular expression denial of service to the login process, to the application, by just giving it a huge number of regular expression cards, wild cards. So let's see that in action. What we're going to see now, if I'm going to try and open my task manager here, hopefully it'll work. Okay. If I load this, where is my task manager? There it is. So okay, my computer is already stuck. My browser is already stuck because of that. But the idea is that what you would see in this case, and you just saw that the MongoDB here is using 25% of my CPU, which is a single core out of my four cores. So very easily I could enforce the application to use up all my CPU and by that actually causing a denial of service. All right. Some takeaways. Gamification of education, we really believe in educating developers to write correct code, to write secure code. We think that one of the best ways, and it's not only us, I think the industry understands that one of the best ways to educate is via gamification. It works for everyone at all ages. So anytime you have an opportunity to make learning experience fun, highly recommended, we saw that with Game of Hacks, we saw that with the number of users who have been using it, developers of all types and kinds. Regarding the code that you're using, when you're using new code, in this case, Node.js, you want to make sure that you know what its pitfalls are. In this case, what we could have done to avoid the denial of service and the redenial of service and the JSON SQL injection is to actually validate completely the length of the fields and the validity of the field completely. And last point, Node.js, highly sensitive to CPU. So important to watch out for that. And that's it. It's time for questions. So in this online version of the game, it doesn't. It just tells you wrong. But there are other versions that we could integrate within our product and that allows you some more information once you get something wrong. Any more questions? Okay. Thank you very much, everyone.