ADMIN per SQL INJECTION werden (OWASP Juice Shop, IT-Security Einführung Deutsch, Gamescom Vortrag)

Hello and welcome, my name is Florian. I am here at the booth of Germany's Best Hacker and I will show you how you can test web applications. Based on the Obersuch Shop, which is an extra-vulnerable website that has a lot of security bugs. And I will show you a few of these security bugs today and explain how you can act as a hacker. Well, then I'll take you straight to my workplace and we'll start hacking. Before the video starts, a short disclaimer. This video is intended exclusively for educational purposes. Hacking without permission is a crime. In this video, I show based on a webshop called Obersuch Shop, which you can legally hack and which was specially designed to learn how to hack, which security problems there can be in web applications. The webshop does not run on the Internet, but locally on my computer. What I show in this video can only be used on this Obersuch Shop, not on other websites on the Internet, except you have the author's permission of the website's operator. Do not commit any crimes. Thank you very much. So, the first challenge we're going to do today is, of course, becoming an admin. Yes, that's always the best thing when you have direct access to the system. I'm going to do this with the help of a so-called SQL injection. I'll show you how it works. So, I'm here in the Obersuch Shop on the homepage. And up here I have the option to sign up, for example, as an admin. Let's just type in admin at juice-sh.op. That's the administrator's email address. You can find it if you look around a bit on the website. Okay, now I'll enter a password. I could enter something like admin, send it off, and then I'll see here, invalid email or password. That was nothing. Okay, let's try something else. You know that when you log in somewhere, there is an SQL command. So, some database command that is sent to the backend. And then it is checked whether what you have entered in the credentials is actually valid. So, username, does it match the password? And vice versa, of course. And to check whether a web application is susceptible to a so-called SQL injection attack, i.e. an attack where you try to enter special characters, for example, into an input field to trigger a harmful behavior in the backend, we can enter a semicolon. That's the classic first test you do. And then you can already see here, you have solved a challenge, the so-called Error Handling Challenge. And it is triggered when you trigger an error somewhere in the web application that should not be visible to the normal user. Error management is always good. So, you always get told in school, document your code, write down exactly where the error could possibly be located, because this later ensures as an application developer that you can easily fix the found error. But in the context of web applications, this is of course problematic, because it can happen that a hacker, i.e. someone from outside who is now trying to infiltrate the website, comes on top of it and then realizes, oh, hopla, there may be a threat. Exactly. And we have now obviously found something like this here, namely through this error message. Object, object. Sounds kind of weird. Can we take a closer look at where the problem is? How do you do that? With the help of a tool called Burp Suite. I can make it a little bigger. I have now started the terminal with CTRL-ALT-T and there I now enter the command Burp Suite. Press Enter and then the Burp Suite starts. This is basically nothing more than a proxy that is between you and the website. So it should mean that everything that is now in traffic, if I intercept it, goes from me to the website and vice versa, is intercepted. Well, how do I do that? I click here on Next to start the Burp Suite. Start the Burp Suite. And here in this window I have now several options. I go to Proxy, because I want to intercept what is happening between me and the attacker and now open the Burp Browser here. It has already integrated the proxy. If that were not the case, I would not use the Burp Browser now, then I would first have to configure it in Firefox, for example, so that it can work as a proxy. Okay, I'm going to call the Overstreetshop now. It is located under 127.0.0.1 Port 3000, so the localhost. I hosted the whole thing on my computer. It's on there and I'll just call it now. So, that takes a few seconds. Then I'm in the Overstreetshop, just like I did before. But I now have the opportunity here in the Burp Suite to intercept what happens when I somehow interact with the website. And of course I can also show myself here what has been exchanged so far. Yes, to set up a website, I have to download and get various documents first. And that's exactly what happened here now, the individual Get Requests, which we want to take a closer look at down here in the window. But first we want to see what happens with this object object, this strange error message that we saw there. How do we do that? Very simple. We go to Account, Login and now enter the semicolon up here again. Any password down here and click on Login. So, now we have this object object error message again. What we do now, we go to the Burp Suite and take a look at what came down here as the answer. And there we already see, Ha! Here at this request, at this post request, so where we sent something to the application, to the database in the background, there is an error. You can see the error down here. And here it says SQLite Error. So, and that's already a hint, okay, an SQLite database is being used. But if we look further down, then we also see which SQL statement, i.e. which database request is actually sent to the backend, how it is set up. And here we see Select star from users, where email is the same. And then we suddenly have three semicolons here. Why three semicolons? Very simple. Because we have just entered this one semicolon ourselves in our Burp browser. Yes, at this point. There we have entered the semicolon. And that is the semicolon that we see here in the application now. So, and now there is a trick that is often used in SQL Injection. You try to provoke a true statement. With this simple semicolon, no user is selected, no email address from a user, then it is not selected. That's why the first entry is taken in the database. And the first entry in the database is often the admin. It starts with A. That's why the admin account is selected here at this point. So, and if I now, because this semicolon that we have entered here ends this value of the variable email, I can now enter my own code afterwards. Like, for example, OR 1 is equal to 1. What does that mean? Very simple. The OR is a logical operator. It now says, so to speak, either one is true or the other. Because this is a true statement here, 1 is equal to 1, that means that the application now thinks I want to select the admin account. And since the overall statement is true, in which it is checked whether there is actually a user name and a password that was entered to the user pass, it is automatically sent through. But now I have to do something else. If I were to enter the whole thing here, then there would be a syntax error here. Because then I would have something like OR and then somehow 1 is equal to 1, but then another semicolon is written somewhere in between. There is a trick. You can, with the help of two dashes, if you use an SQL database, enter a comment. Then everything that is behind these two dashes just disappears. It is no longer interpreted by SQL. So that's a comment, no longer visible. If I click on Login now, then I did it. I actually hacked into the web application. We can check that by going to Account now. admin.adjust-shop and then I see I'm actually an administrator because I just selected this first account above. And that's a big problem. That's why you should, when you build a web application in which there is somehow a login field or query database, always make sure that you know the special characters. And that's what a semicolon is for.