SQL INJECTION

Web application security SQL injection attacks

David Morgan In the world of web application security the assessor will attempt numerous means of compromising the application. However, the holy grail of the assessor means obtaining the ability to execute arbitrary SQL commands, should such a back-end database exist. Every self respecting organization has an Internet presence and the majority often provide complicated data driven applications. Even a comparatively simple web site may well be driven by a database backend. At the other extreme, it is immediately apparent that the majority of shopping cart and transaction sites will be driven by a database backend. In this article, the second on web application security, we will introduce the concepts of SQL injection the ability to insert your own code into the backend database. Once we have covered some fundamentals we will move to some more interesting attack vectors to give a feel for the true scope of this class of attack. The article will conclude with a few examples of preventative best practice and where to find further information. unexpected and usually of benefit to the attacker. A typical SQL query will specify which data you want returned; in this case id, firstname and surname and from which table, in this case, users:
select id, firstname, surname from users

For example
It is common to come across web sites that require authentication in order to access particular content, and it is also common that the necessary authentication details are stored in a database. Within the application layer code you may well have a SQL query along the lines of:
var sql = select * from users where username = + username + and password = + password + ;

If you wished to have only results for a specific user as opposed to the entire table such as David Morgan returned, you would be able to restrict the results with a query such as:
select id, firstname, surname from users where firstname = david and surname = morgan

This may appear to fulfil the login requirements perfectly at first glance. However with the use of single quote, the command delimiter (;) and the single line comment command (), it becomes trivial to exploit. Below I present three different usernames, each of which abuses the database in a different manner. Should the username submitted be or 1=1 the subsequent SQL would allow you login as the first user in the table without knowing their username or password:
select * from users where username = or 1=1 and password =

The submitting of single quotes as seemingly random test inputs is very popular

Note that the search parameters in this query have been delimited with single quotes, this becomes significant for our subsequent attacks. If the two search parameters were user-supplied data, and assuming they were not being sanity checked it would be possible to submit a firstname of david and surname of morgan and have the following query:
select id, firstname, surname from users where firstname = david and surname = morgan

Should the username submitted be admin the subsequent SQL would allow you login as the admin user in the table without knowing their password:
select * from users where username = admin and password =

Should the username submitted be ; drop table users the subsequent SQL would allow you to delete the table users:
select * from users where username = ; drop table users and password =

General concepts
Applications and developers interact with databases using Structured Query Language, there are many varieties of SQL. However the majority are based upon SQL-92, an ANSI standard. The examples given within this article will be based on Transact-SQL, the version used by Microsoft SQL Server. As mentioned, applications will communicate with the backend database with SQL queries. Typically the database will respond with a result set which would then be appropriately formatted at the application tier for presentation back to the user. SQL injection attacks are so called, because what attackers are attempting to do is to insert their own code into a pre-existing query (for example a product search) to get the application to perform an action that is
4

This query would likely result in the database returning an error complaining about incorrect syntax near vid. It is for this reason the submitting of single quotes as seemingly random test inputs is so popular. It very quickly identifies if there is any likelihood of performing successful SQL injection attack. After all, you are directly influencing the query which the back database is performing. It is for this reason NGS recommends disabling any form of helpful error messages. There would be no indication of where the error occurred and it may well be down to correct data validation.

As can be seen from these trivial examples without the necessary sanity checking of data and appreciation of the power of SQL it is possible to perform some scary actions with minimal ability.

Taking SQL injection further

In the previous example it was possible to login in as any user registered with the application. However once successfully logged in you are only a user of the application though admittedly one with elevated permissions. The goal of an attacker may well be to utilise the application as the

Network Security

April 2006

SQL INJECTION
compromised user. However it is likely they may wish to compromise the host which the database resides upon, escalate permissions if the database account is low-privileged, or indeed find further databases internally. Should this attack vector be available it is likely an attacker would automate this process with multiple password attempts via a script. This very same attack method could be utilised to connect to other databases via the compromised database:
select * from OPENROWSET(SQLOLEDB,10.1.1.1;sa;t est,select @@version)

Stored procedures
Stored procedures are compiled code with predefined interfaces and were designed to extend the functionality available to SQL server applications. Several stored procedures come as standard on databases with varying functionality such as interacting with the registry and network services, one such procedure is xp_cmdshell. xp_cmdshell is standard stored procedure on Microsoft SQL servers and allows the running of command line code, for example directory listings or user manipulation dependent upon permissions the SQL service is running as:
exec master..xp_cmdshell dir exec master..xp_cmdshell net user add username password

Using time delays

Previously in this article it was recommended that error messages should not be presented to the user of a database-driven application. This, however is not the full solution. Whilst the attacker may be unsure of the databases reaction based upon messages received, there is a method of determining its success. SQL server provides a command which results in a processing pause, the waitfor delay command will allow the convert reporting of the success or lack of when executing a particular command.

www.sqlsecurity.com. [[Web links are not live]] Implement effective network level access control both upon the servers themselves and at the network perimeter. This filtering should address egress in addition to more obvious ingress traffic. Implement effective parameter validation within the application, this can take many forms rejecting any input known to be bad. However whilst more difficult to implement, it is recommended you always adopt the approach that you only accept data known to be good. Allow web applications to only perform actions upon the database via stored procedures. These procedures in turn operate with least privilege and utilise a parameterised API which greatly helps with the sanity checking of user data.

Conclusions
If the content in this article has piqued your interest, it is recommended that you visit the white papers section of our website (www.ngssoftware.com) for several in-depth papers on these and other SQL injection techniques. Further information on securing web and database-driven applications may be found at the Open Web Application Security Project (www.owasp.org). Web application security remains one of the more dynamic and on occasions more frustrating areas to work with, should your task be to secure the environment. The continual release of new vulnerabilities within the respective products, as well as advances in attack techniques, ensure this area of security will remain a challenge in the immediate future. It is however possible through application of best practice, effective application assessments, and maintenance of secure systems to keep the malevolent hacker away. It just requires more effort than before.

This stored procedure is considered very dangerous and it is likely if you have it remotely accessible your SQL server will be compromised. From an attackers point of view (and in some cases the databases administrators) there are several stored procedures found within Microsoft SQL Server that prove very useful, some key examples are given below: xp_availablemedia - displays local drives xp_loginconfig - displays the security mode of the server xp_ntsec_enumdomains - enumeration of domains the system can access xp_terminate_process - kills a process

If this stored procedure is remotely accessible it is likely your SQL server will be compromised
In the following example, if we are connected as the SA user, there will be a noticeable pause for ten seconds, if not the request will return immediately:
if (select user) = sa waitfor delay 0:0:10

Privilege escalation
Should an attacker discover they have compromised a SQL server via an application but the account used to connect is low-privileged it is likely they would wish to elevate there permissions to a further account. Upon Microsoft SQL the most probable account is that of SA. To escalate permissions upon the local host the following could be attempted to connect with a user of SA and password of test:
select * from OPENROWSET(SQLOLEDB,;sa;test,sele ct @@version)

The use of this technique can answer many true/false questions. However it is possible to enumerate entire rows, tables and databases with this technique given the correct syntax.

Preventative measures
Securing SQL driven applications is by no means an easy task. There are however a number of steps that can be taken to reduce your exposure with minimal effort: Ensure the SQL server is running with minimal privileges i.e. not SYSTEM or any form of administration account. Where possible restrict the SQL servers access to the file system and interactive commands such as cmd.exe. Take efforts to lock down the SQL server itself, there are many resources for this, one such is

About the author

David Morgan CISSP is Principal Security Consultant, Next Generation Security Software Ltd. He has ten years hands-on experience designing and managing secure high availability network environments, and six years experience in providing security consultancy advice from the offensive perspective. At NGS he is responsible for the delivery of security consultancy services, backed by NGSs research team, bug hunters, and penetration testers. Formerly a Senior Consultant of ISS X-Force Security Assessment Services, David is also co-author of the ISS Ethical Hacking course.
5

April 2006

Network Security