CompTIA Pentest+ PT0-002 – Section 12: Application Attacks Part 3

116. SQL Injections (OBJ 3.3)

In this lesson, we’re going to discuss SQL injection attacks. Now, before we dive into SQL injection attacks though, we need to talk a little bit about SQL in general and provide some background. Now, when you’re dealing with databases, you have to have a way to talk to the database in order to read, write or search for data within that database. This is done using statements in the structured query language more commonly referred to as SQL. Now there are four main actions in SQL that are used to manipulate data within a database. These four actions are select, insert, delete or update.

Now, to select something means that we want to read data from the database. To insert something means we want to write that data into the database. To delete something means we want to remove that data from the database and to update something means I want to overwrite data that’s already in the database with a newer version. Now let’s take a quick look at how SQL works in the real world. When you try to log into a website, you may encounter a basic login form asking you for your username and password.

Let’s pretend I enter jason as my username and pass123 as my password and then click login. Next, the website will send my username and password over to the database and make a query to determine if my username and password match what’s already stored in the database. To do this, we’re going to use an SQL statement. For example, it might say, select * from User where user_id = jason and password = pass123.

Now, this information goes over to the database and the database is going to compare it to determine if we have a match. If we do, we’re going to get access granted and everything is wonderful, but if we don’t, we’re going to get access denied and then we can’t log into the server. Now, this is a very basic and major oversimplification of how SQL really works. If you’re data database engineer, I know, I made this much simpler than it really is, but this is really the baseline knowledge that everybody watching this video needs to have before we can move forward and talk about SQL injections. So please don’t send me a bunch of hate mail over my oversimplification here. All right, now let’s move into a code injection. Now, a code injection is the insertion of additional information or code through a data input form that a client takes and then sends it to an application. Code injection is really a generic form but what really want to focus on here is an SQL injection in this lesson because that’s how an attacker is going to insert malicious SQL statements into our application and cause a lot of havoc for us. Now an SQL injection attack consists of the injection of SQL query through the input form that a client uses to send data to a web application. When you’re conducting an SQL injection, the attacker is going to be trying to insert parameters or code into the SQL statement that’s going to be used to query that database. To do this, the attacker can inject their input as a URL parameter by entering data into form fields, modifying cookies, changing post data or even using HTTP headers to find an SQL injection vulnerability.

While this sounds like a lot of work, it really is easy to automate this process as an attacker because there are many great tools out there that focus on SQL injections and exploits. So, as a defender, it is our job to protect our databases from SQL injections. And to do that, we have to understand how SQL injections actually work. So, let’s go back to our example of logging into a website and see how the SQL injection could exploit our site. First, we have the login form used by our clients to enter their username and password. As an attacker, I’m going to put in the user that I want to log in as, in this case, jason and then I’m going to insert the password. But, I don’t know the password of pass123 because I don’t know Jason’s password. So, I’m simply going to put in an apostrophe or one equals one, semicolon. or one equals one, semicolon. Now, I know that looks a bit weird, right? But what I’m doing here is actually going to be injecting that code when I hit the login button. That takes the data from the form and it starts it into the SQL statement on the backend. So, now, we have the command that says select star from users where user ID equals Jason and password equals apostrophe apostrophe or one equals one semicolon apostrophe. Notice, when I sent that to the system, I’m going to get that into the system and it’s going to say access granted. Now, why is that? Well, the reason is because I just performed an SQL injection. What actually ended up happening here is that we inserted something like an apostrophe that served as an escape character. So, what I did was actually injected everything after the apostrophe into the SQL statement that the system was going to evaluate. And so, instead of saying, entering the password, pass123, I’m saying, tell me does the password for Jason match the password for Jason or does one equal one? Now, let me ask you a quick question. Does one equal one? Yes, one equals one, right? Every single day. It’s going to be a true statement. So, anytime we run this command, we’re doing bully and logic to find out is it a true or false statement?

And the true statement is always going to be returned as true when checking this password because even if we don’t have the right password for Jason, one always equals one and this was an or statement using bully and logic. So even if the password was wrong, we still have it. And in this case, we entered a blank password or one equals one. And therefore, we are able to see that our password even though it doesn’t match the database, still gets a true statement because the or condition has one equals one which is always true. This way, the SQL statement overall returns a true and we get access into the system. This is why preventing SQL injections is so important. Because anytime you can create a true statement, you’re going to be able to log right into the database. So, what is the best way to prevent an SQL injection? Well, the single best way to prevent an SQL injection is to use input validation and sanitize any input received from your users. Now for the exam, anytime you see something with an apostrophe and a something equals something, I want you to instantly think that the answer has to do with an SQL injection attempt. Every single time. Be aware. The log entry they show you doesn’t have to be one equals one, though. It can be anything that has a true statement.

7 equals 7 , 15 equals 15, A equals A, whatever, it doesn’t matter. As long as the statement will always return true, this is a form of SQL injection. I guarantee you on the exam, you’re going to get at least a few questions on identifying SQL injections. This is a common topic they love to ask about because it’s really important. So, if you’re asked about an SQL injection and how to prevent it, what is the right answer? Input validation. If you can validate or sanitize the input, you can prevent an SQL injection from occurring because you can simply filter out those apostrophes or something equals something statements from the input the user gave you. Another great way to prevent an SQL injection is to place a web application firewall between the client and the server. Since the web application firewall can perform input sanitization for you if you can’t rewrite the application code yourself because you don’t own the application. Another clue to a question asking about SQL injections is if the question involves a database. Because the most common attack against a database is going to be an SQL injection. Remember all these tricks when you get to exam day, they’re really going to come in handy, I promise.

117. Conducting SQL Injections (OBJ 3.3)

In this lesson, we’re going to go through and do a little bit of analysis on the impact of web application vulnerabilities. Now, as we do this we’re going to take a look at a sample e-commerce website. That’s going to involve a front end and a database backend. So we’re first going to assess the database functionality. Then we’re going to look at the website functionality. After that, we’re going to test some injection vulnerabilities and then test some authentication vulnerabilities. First, I need to test my database and my web server. So to do this, I need to make sure they’re running. So I’m going to type in service mysql start and hit enter. Then I’m going to type in service apache2 start and hit enter. This is going to start both the database server and the web server on my staging environment. Now, from here, I’m going to open up the database administration using Firefox. To do this, I’ll type in firefox http://localhost/phpmyadmin and then enter. At this point, Firefox will load up and I’ll be brought to the login screen for phpMyAdmin. This is a web front end to interact with the backend database. From here we’ll be able to look at the tables inside the database and even run SQL queries.

So all I’m going to do here is log in. Now that I’m in the backend, I can click on devtech_store which is the database that I want to look at. In here, you can see there is new, categories, products and users. And under categories, products and users, those are my different tables. If I click on categories, I can see here the different rows that I’m going to have inside that table. Essentially, inside this table is a list of different product categories. Inside the ID column, that’s going to be our primary key and then the name column is going to list the name of each of the different product categories. There are a total of nine different categories here. Notice you can see the SQL statement at the top. It says select star from categories. That is what we’re doing here. We’re selecting everything from the categories table. Next, let’s select the products table and review that data. Again, this is another table and it lists all the different products. Instead of looking at the categories, we’re looking at the individual products here, though. Each product has its own product code, description, price and whether or not it’s going to be in stock and what category it belongs to.

If we go and look at the user’s table, we can look at that data. Inside of here we have a list of all the users who can sign into our website. Each user has a username, a password, a first name, a last name and a level of permission. Now notice one major vulnerability here, we are storing our username and passwords in plain text. So if you look in the password column you can see each person’s password. This is a very dangerous practice. Instead, those passwords should have been hashed and then the hash should have been stored inside the database. Now look at the URL that’s used to access this data. Notice it calls sql.php and that’s a script that we’re going to use, it’s a PHP script. Now, when it does this, it actually gives you parameters from the database. This is going to be something like the database, the table and the position within the table. So if we look under the SQL statement again here, we can click the edit link. And from here we can change this SQL statement to say whatever we want. For example, if I want to see who has admin permissions, I can type in select* from users where permissions equals admin. And this will actually return just one record for us.

This website is going to go into that database using scripting languages like PHP to pass those SQL statements in a secure way so that the user can’t inject additional parameters. Now, as we see this phpMyAdmin, this is an admin tool. This is not where our users are going to be inputting data. Instead, they’re going to do it from the website. So let’s go ahead and take a look at the website itself. First, we’re going to open the browser and go to http://devtech which is a sample e-commerce website here inside my lab environment. Now this is the website for the store and it’s running on my local Apache web server that I started up at the beginning of this video. If you select the catalog tab, you’re going to be able to see all the products inside the monitors category. They’re all listed here from a table. Note that the URL here that’s used serve this webpage. It doesn’t have that SQL query anymore. Instead it says catalog.php:category=1, which is selecting the first category, which was monitors.

Now there are better ways of doing this and this isn’t necessarily the most secure way or the least secure way. It’s just one way of doing things. Now here we’re actually passing in a parameter directly by saying category equals one. That means if this was something that was behind a secure paywall for instance, we wouldn’t want to do this because somebody could easily change that one to a two and that would select a different category directly. Next, I want to go ahead and try testing injection vulnerabilities. To do this, I’m going to put the website on the right side of my screen and the phpMyAdmin on the left side of my screen. Now from here, what we’re going to do is we’re going to verify the URL that’s passing the parameters. In this case, category equals N, in this case it was category equals one, to make sure that we’re viewing the right category. So what I’m going to do is I’m actually go to the insertion point at the end of the URL and I’m going to add a space and then I’m going to type or one equals one, which as you remember from our lessons, one equals one is a very common way of doing an SQL injection. Now, once we do this, we’re going to see what happens. Notice here that the listing page still says we’re in the monitors category. But we’re not seeing just monitors, we’re seeing every single product that this company has. That’s because we just injected this or one equals one making every statement true and not just to display category one. This is a basic SQL injection. Now notice in the SQL query section we can verify the query that we executed based on the URL we inserted from the webpage. Notice the query is selecting four columns from the products table. Anytime it finds the product category is N, in our case one or where one equals one. And because one equals one every single time, guess what? It’s going to dump at every single category all at once to the screen. Now that we’ve tested injection vulnerabilities, let’s go ahead and test an authentication vulnerability. We’re going to go into the sign-in tab and we’re going to attempt to sign in as Kevin. Now, wouldn’t we try to sign in, if we don’t know his password, we’re going to get an error and it’s not going to let us sign in. Now, we don’t have the ability to crack his password at this point. So instead, let’s try an SQL injection.

Now, here, we’re going to put Kevin as the username and try to put something in the password field to cause a malicious SQL statement to be formed. This is an SQL injection. So if I do something like X and then a quote, space or, space quote, X quote equals quote X, that will be able to do an SQL injection for us because the quote is going to break apart from that password and then test the second half of the statement or something equals something. And so let’s see how this looks. Now to see what I actually typed in, we’re going to go and right click on the field and do inspect element. This allow us to see what was there inside of the field. In HTML, when it’s a password field it’s going to show up with stars or dots instead of the text. So I’m going to change that password field to text and that will allow us to see what I actually put in. So now we’ll go ahead and click on the sign-in button and you’ll see that it sends that to the mySQL database and we get back an error inside the database giving us a warning, saying that there was a perimeter of one to be expected but instead we got the results of /var/www/devtech_ store/html/signin.php on line 37. Essentially, we caused an error in the program by doing this injection but we were still able to successfully sign in. Now notice we are logged in but we’re not logged in as Kevin. It says “Welcome, .” It doesn’t say “Welcome, Kevin.” Why is that? Well, because our malicious query took advantage of the default apostrophe formatting.

And because there was no sanitized input because they didn’t do input validation, I was able to do an SQL injection. By doing that, it’s going to go and look for the first authentication in the table. In our a case that first person is actually going to be Laura Anderson. And that’s the person who has administrative privileges. So we are now logged in as Laura Anderson, the database administrator. So you can see how powerful SQL injections can be and how easy they are to conduct when somebody doesn’t do the right protections on their website either on the front end using input validation through the website or on the backend when they don’t have things configured quite right. It’s not your job to figure out how to fix all these things but it is your job to figure out if they’re vulnerable to these types of attacks. And so you need to understand what an SQL injection is. And usually when you see something like one equals one or X equals X, that’s a dead giveaway. Now on the exam, if you’re asked how to fix something like this, the best answer is going to be input validation. If they had done input validation on the website and took away my ability to insert that apostrophe, it would’ve prevented this SQL injection from occurring in the first place.

118. Burp Suite and SQLmap (OBJ 3.3)

In this lesson, we’re going to talk about Burp Suite. And Burp Suite is a proprietary interception proxy and web application assessment tool. Now that probably brings up the question, what is an interception proxy? Now an interception proxy is essentially a piece of software that sets between the client and the server. So essentially, it becomes a man-in-the-middle, and this allows the request from the call client to go through and stop at that proxy and then the responses from the server can also be stopped by that proxy. By doing this, it can analyze and modify those things before they’re going from the client to the server or from the server to the client. And we use this a lot in security testing. Now, Burp Suite is a great tool for this because it allows for the automated scanning of vulnerabilities and crawling of an application to discover content while providing the tools for automating the modification of requests and insertion of exploits, all wellbeing this interception proxy. Now, when you use Burp Suite, it is a graphical user interface. Burp Suite has a commercially available paid version that has a lot of features or a free community version. It runs on most operating systems including Windows, Linux, and Mac. If you have something like Kali Linux or Parrot OS, which are both penetration testing suites, they come with Burp Suite already built-in.

Now Burp Suite, because of this, is often used by penetration testers and security analysts to test the different web applications. Now, for the exam, you do not need to know how to use Burp Suite, but I want to jump into my lab environment here for a second and show you a little bit about how to use Burp Suite and what I mean by it being this interception proxy right between your client, the web browser, and the server you’re trying to talk to. Now for the exam, again, you do not need to be able to perform the actions that I’m going to in this demonstration, but I wanted to give you an idea of how to get started with a tool like Burp Suite. Now, in this demonstration, you’re going to notice that I’m using Burp Suite’s interception proxy function and it’s going to be used to capture information going between my web browser and a web application. This web application is connected to a database to be able to get information from it and then display it back to the user. Now I’m going to use the information that I capture to be able to connect to that SQL database directly using another tool called SQLmap. And I’m going to use SQLmap to perform an SQL injection. So this demonstration I’m really going to show you how we kind of put some of these concepts together.

As an analyst, you need to understand how these attacks are performed so you can defend against them. And that’s why I’m showing it to you here as well, because all the things that attacker might do against your web apps, you’re responsible for doing the security testing and designing and protecting those web applications too. Now, if you want to learn more about how to use Burp Suite or SQLmap in the real world, there are thousands of great videos on YouTube, Udemy and other learning sites that will give you that in-depth training. Again, I’m just going to scratch the surface here, and for the exam, you do not need to know how to use Burp Suite. You just need to know what it is and why it would be used. So with that said, let’s jump into my lab environment. In this lesson, I’m going to show you how we use something like Burp Suite, which is a web proxy to grab cookie and session data to be able to feed it into ans SQL injection. So to begin this SQL injection, we first need an SQL injection vulnerable website or database. And so on the left of my screen, you can see the Damn Vulnerable Web App version 1.0.7, which is being run inside the Metasploitable 2 virtual machine.

My Kali machine is going to make a connection to it, which I’ve done here to be able to access this website. Now, the way this form works is if you put in a user ID, for instance, record number two and hit Submit, that will pop-up the first and last name of the person. That’s all this database interaction is doing for us. Now, what I would want to do is I want to be able to grab that information, stop it from being sent to the web server from my browser by using my web proxy, and then I can capture the data from it that I need. To do that, I have to go to my proxy setting inside of Burp Suite. And right now you can see my intercept is on. Now, I need to configure my web browser to actually use that proxy. So I’m going to go down to my Preferences. And from Preferences, we’re going to go to Advanced, click on Network and then click on Settings under Connection. From here, we can set up the manual proxy and I’m going to use the local host 127.0.0.1 on port 8080. This will tell it to use my Burp Suite tool. So if I go ahead and close that, now, if I go in and say, I want to get record number three, notice when I submit it, I don’t get the answer back in my web browser because my web browser hasn’t actually made a connection to the web server that’s going to give that information. Instead, it’s sent it to the right over to Burp Suite, which has captured it.

And notice that Burp Suite now has that cookie information that I need. It tells me the security level. It tells me the PHP session ID. And I’m going to be able to use that as part of my attack against this web server. So the first thing I want to do is I want to capture some of this information. First, I need to note the website that we were trying to go to. So I’m going to go ahead and copy that. And I’m going to go ahead and go into my terminal. And so what we’re going to do is we’re going to use sqlmap -u and we’re going to provide the website that we’re going to. So I’m just going to paste that in. And then I’m going to use –cookie= and I’m going to copy the information from my cookie. So I’m going to go ahead and bring that back over to Burp Suite, and we will copy this cookie information. And then we will paste that in. And from there, we’re going to go ahead and hit Enter. So at this point, it’s going to start querying the database. The first thing you notice is, is that this is an MySQL database. So it’s asking, do I want to skip all the test payloads for other databases? And in this case, we’re going to just use the default of Yes. And it’s going to say, do you want to include all of the tests from MySQL? And we’ll go ahead and say, Yes. And it’s going to go through and start querying that database and trying to do different injections. So you’ll notice here that it is trying to do different testing based on the version of MySQL, trying to do things that are stack queries and other errors to figure out what this is vulnerable to. So now it finds that it found an ID parameter that was vulnerable, that said id=2 or Id=3. Do we want to keep testing others? We’ll go ahead and say, No, ’cause we already found a way into this database. And now we’re going to see everything that it found. So if I go ahead and scroll up a little bit, we find that the GET ID is vulnerable. We also found that it was vulnerable based on a boolean-based blind.

It was vulnerable based on an AND/OR time-based blind. And it was vulnerable based on a UNION query. We also were able to find out that the web server was Linux Ubuntu 8.04. We found the version of Apache, the version of PHP and the version of this database. And all that information in is now saved to this file as shown in green on the screen. But that really didn’t give me a lot of details yet that I want to use. It just tells me information about our target. And so now what I want to do is I want to enumerate the databases. So I’m going to add a –dbs at the end and hit Enter. This is going to go through and find what databases are on that server. Notice it found seven databases, DVWA, Information Schema, Metasploit, MySQL, OWASP10, TikiWiki, and Tikiwiki 1.9.5. Now the one we want to target here is the DVWA, the Damn Vulnerable Web App. And so now that we know what database we want to target, which is the DVWA, I want to select that database with my command. So I’m going to go arrow up again, go backspace, put a -D, which stands for database and the database I want to select. And then I want to enumerate it for the tables to figure out what tables exist inside that database. So I’m going to put –tables, and that will tell me what tables are associated with it. Go ahead and hit Enter. And it goes through in scans and it finds two tables, guestbook, and users. So now I want to be able to dump the columns from those tables.

Again, I went from the database down to the table. Now I want to dig in a little bit further and get those columns. So to do that, we’re going to arrow up. We’re going two backspace out of tables and do -T and give it the table we want, which is users, and then –columns. And off we go, we now have six columns, the user, avatar, first name, last name, password, and user ID. Wouldn’t it be great if we can get those passwords for those users? I think it would. So let’s go a little bit further here. And what to do is arrow up, take out the word columns and put in the word dump. And here we go. Do we want to save this hashes to a temporary file? We’ll say, No. And what it’s doing is it’s grabbing any password hashes from the password column, and it’s going to attempt to do a dictionary attack to crack them. And then we’re just going to go ahead and use the standard default dictionary of number one. And do we want to use common suffixes? No, we’re just going to use the default things and it’s grab the those hashes. And it’s already starting to crack those passwords. Notice that I already have a password for charley and abc1 and password and letmein. And here it is on the screen.

And so you could see that the first user ID is admin and their password in parentheses is password. The second user is Gordon B and his password was abc123. The third username was 1337 and their password was charley. The fourth was Pablo with, letmein. And the fifth was Smithy with password. Again, these were all very simple passwords and easy to crack, but you can see the power of an SQL injection. We can interact directly with that database because we’ve been able to break through the PHP front end and be able to inject into the database and get information back that we shouldn’t be able to get back. And because SQLmap is such an easy to use program, it makes our injections very automated and very easy to use.

• Category: Uncategorized