Messing About with SQL Injections (In-Band)

 Structured Query Language injection (SQLi) attacks are very dangerous as they allow attackers to gain access to backend databases from which they can dump sensitive data. SQLi vulnerabilities can also be exploited as soon as they are found. It is well worth knowing more about this attack vector.


First of all, we need to know a little about SQL and how web applications can use it to interact with database servers. Essentially, SQL is a language which lets us work with datasets stored in databases. There are different implementations of SQL, such as MySQL, Microsoft SQL Server and Oracle. These work off a server / client model, so we need to establish a connection to the server from our client in order to interact with the databases. A web application can use PHP code to establish a connection to a SQL server and then make queries to it using that connection.


In order to better understand this, we can look at an example of a web application which uses PHP to establish a connection to a MySQL server and submit a GET request to it. The PHP code in this example is vulnerable to an SQLi attack.




As we can see, the PHP code will store the parameter passed to it as name in a variable called $name


The content of $name is then used in a query to the MySQL server. It is this part of the code which makes this web application vulnerable to SQLi attacks.




The vulnerability exists in the query which is submitted:


"SELECT name, message FROM Messages WHERE name='$name';"


In ordinary usage, this is not a problem, and the user can retrieve their message from the database using their username. However, the on account of the user input in the name parameter being passed directly to the MySQL server as a command, attackers can use specially crafted input to enumerate the backend database and retrieve potentially sensitive data from it. This is shown in the following picture:




The single apostrophe at the beginning of the input closes the first single apostrophe in the query which is being submitted by the web application. This is then followed by an always True condition. Finally, a SQL comment is used to comment out any following code which would cause errors. There is a trailing - after the -- comment because lots of browsers remove blank spaces from queries and we need the blank space after -- in order for the commenting out of trailing code to work.


The following pictures show how this simple trick can allow an attacker to dump all the data from the backend database - at least for the two fields (name and message) which the PHP code selects from. I use wget for lots of SQLi attacks as I find it too easy to mess up the syntax if I work directly into a URL bar!





Now that the attacker knows that the name parameter in this web application is vulnerable to SQLi attacks, the next logical step for them is to exploit this to see if they can get hold of any more interesting data. In this example, the web application only retrieves data from the name and message fields of the backend database. What if there are other fields present? What if those fields contain sensitive data such as password hashes, credit card numbers or other such things?


From an attacker's point of view, we don't know how many columns are selected from by the web application's SELECT command. Our first job is to find out, as later we will want to try to use the SQL UNION syntax in order to execute further SELECT commands. When we use UNION, we need to balance the SELECT command which follows it with the original SELECT command which has been undertaken. This means we need to know how many columns are selected from. To achieve this, we can start using the ORDER BY command. We increment from 1 until we get an error or a different response from the web application.





As we can see, in this example, the web application gives us a different response when we try ordering the columns by column number 3. This suggests to us that 2 columns are being selected from in the original SELECT command.


As an attacker, our next job is to find out if the returned results from either of these columns is displayed on the webpage. If they are, we can use this to our advantage, as we will be able to see the results of our attacks displayed in the same channel (i.e. the webpage contents itself) as we are using to attack the backend database. This type of SQLi attack is known as an in-band attack. We should be able to use the UNION syntax if this is the case. This has given rise to in-band attacks also being known as UNION attacks. If we cannot see any results displayed, we will have to use a different method to enumerate the backend database. I will cover this scenario later in this post. For now, let's see if any results are displayed, and if so, which ones.





Excellent - the results from both columns are being displayed in the response to our query! We can now use this, along with MySQL functions, to enumerate the backend database. We will want to know which version of MySQL is being used and what the name of the database we are connected to is. We can use the version() and database() functions to find this out. We could also use the user() function in order to find out which user we are connecting to the SQL server as.





Now that we know that we are connecting to a database called users we can use the information_schema table to enumerate the database. The information_schema table is automatically created by MySQL when a new database is set up. It contains lots of useful data for us as hackers.


We will begin by finding out the names of any tables connected to the database called users We will then look for the column names of a table of our choice. We may well find some interesting columns! If we do so, we can then dump the contents of them, and because this web application is displaying the results of our queries to us, we can immediately see the sensitive data we are after. This means that we have successfully exploited the discovered SQLi vulnerability to extract data from the backend database which we were not supposed to be able to see.









So far, we have been performing our SQLi attacks manually. This is good to do, but we can also use a tool called SQLMap to automate the process. The following pictures should be self-explanatory about how to use SQLMap along with some of its switches in order to achieve the same results as we have achieved manually. It is worth noting that we should manually find the SQLi vulnerabilities before firing up SQLMap so that we don't overload our target and so that we are not as easily detected. In the following examples, I have already established by manual methods that the name parameter in the targeted web application is vulnerable to in-band (UNION) attacks. This is why I have set the -p switch as name and the --technique= switch as U I start by grabbing the banner as this is a good way to prove to a client that they have a SQLi vulnerability in their web application.











In order to see these in-band SQLi attacks being used in a different context, both manually and with SQLMap, please see the following pictures. If the above points have been understood, it should be clear what I am doing as I attack the web application. The one difference is that I need to set the --cookie flag when I use SQLMap as the targeted web application is in a password protected area, and the cookies stored in my browser's cookie jar are not accessible by SQLMap. I have used Burpsuite to find the correct cookie to send with my SQLMap requests.



















At this point, we would of course need to crack the hashes. I won't be covering that step in this post as it is focused on in-band SQLi attacks.


I hope the contents of this post made sense. It is well worth experimenting with these attacks and perhaps setting up your own vulnerable web applications and / or MySQL databases in order to understand UNION SQLi attacks more. The bWAPP applications are good to mess around with, as are the Mutillidae ones.


Soon, I will continue exploring SQLi attacks in a new post. I hope to show how we can use POST requests for SQLi along with how we can exploit SQLi vulnerabilities in order to gain reverse shells :-)


Thanks for reading - puzz00

 

Popular posts from this blog

Hacking Reset (thm)

Image
  NOTE: I am currently migrating my writeups and notes regarding hacking aka pentesting to  my github - my reset writeup can be found here     Reset is a fun active directory based box on thm   We start with an nmap scan which shows us that the target machine is probably a domain controller as it has port 88 open. Domain controllers typically have this port open since they are involved in kerberos based authentication. We also find some useful data regarding the domain and machine we are attacking. In addition, we find port 5985 is open - this is of interest as it is a port which is used by winrm which in turn is a service which could potentially give us a remote session on the target machine if we find valid credentials.    Since smb is being used, we start our enumeration of the haystack machine by taking a look at it - can we get a null session and thereby enumerate useful data? We find that we can. The IPC$ share has read access to non-authentica...
Read more

Hacking Year of the Owl (thm)

Image
NOTE: I am currently migrating my writeups and cybersecurity notes to  my github This writeup can be found in a new and shiny form at puzz00 year of the owl writeup  --- The Year of the Owl is a machine by MuirlandOracle on tryhackme   We start by using nmap to scan the TCP ports. The results show us that this appears to be a windows machine because we see netbios on port 139, SMB on 445 and winrm on its default port of 5985. We take a closer look but don't find much of interest. Since SMB is running, we can try a null session attack, but this does not work. We cannot connect using rpcclient without valid creds, either. Web app enumeration does not reveal anything of interest, so I have not included it in this post. We need to find another way to enumerate usernames and potential passwords. We can try common UDP ports using nmap. The results come back in the open|filtered state which is not very useful. We do not know if the ports are open or if the UDP datagrams are bei...
Read more

Simple CTF (tryhackme)

Image
  I started with a quick SYN scan of all ports on the target machine. The -T4 flag speeds up the scan from the default -T3 and the -p- flag specifies all ports to be scanned. As can be seen from the results, ports 21, 80 and 2222 had services listening on them. It was now time to take a closer look at those three ports, so I used the -A flag with nmap to find out more. The anonymous login allowed using FTP on port 21 seemed interesting, so I connected to it in passive mode using the username anonymous and no password ftp -p 10.10.179.144 The connection was successful, but I could not get any listing of the directories or files using ls so I turned my attention to port 80 by navigating to the home page in my browser. I was greeted with a default Apache "It Works!" page. I then checked the robots.txt file and fired up a directory buster. I used gobuster as it is fast, but dirb, dirbuster or a home-grown one would also do. The /simple directory stood out as interesting, so I na...
Read more