SQL Injection on Sybase: The Defensible Attacks

Research Paper

CS674

Thanavit Cheevaprabhanant (U2376885) Boston University Metropolitan College

Table of Contents

Abstract......................................................................................................................................................................... 1 Overview ...................................................................................................................................................................... 1 Information Security versus SQL Injection Attacks................................................................................... 2 SQL Injection Attacks and Prevention Techniques on Sybase .............................................................. 4 SQL Injection Attacks on Sybase .................................................................................................................. 4 SQL Injection Issues in Sybase ...................................................................................................................... 6 Prevention Techniques for SQL Injection Attacks on Sybase .......................................................... 6 Use of Prepared Statements (Parameterized Queries) ...................................................................... 7 Escaping All User Supplied Input ................................................................................................................ 9 Enforcing Least Privilege............................................................................................................................. 10 Pitfalls and Recommendations ........................................................................................................................ 11 Performing White List Input Validation ............................................................................................... 10 Conclusion ................................................................................................................................................................ 12 References ................................................................................................................................................................ 13 Possible Vulnerabilities to SQL Injection Attacks on Sybase and Recommendations ....... 11 Research Limitation and Recommendations ....................................................................................... 11 Use of Stored Procedures ................................................................................................................................ 8

Abstract

Considering that the injection has been a major threat on web application during recent years (OWASP, 2010), all the safeguards on network components including the database management systems must be well-established to maximize protection to the most valuable asset of the organizationdata.

Although it is known that no such tool can stop SQL injection attacks, appropriate database configuration significantly mitigate the impact (Clarke, 2009). However, the effectiveness and efficiency that the information systems and its database to protect data and vary with implementation of security countermeasures. By focusing on a specific database product, the research will provide examples of known SQL injection attacks on Sybase and propose prevention techniques to defense against them. Therefore, the more the security countermeasures are equipped, the better safeguard against the attacks for information systems is armed.

This research paper will firstly introduce SQL injection attacks and the affect of them on information security. Then, the paper will describe the characteristics of SQL injection attacks by providing a set of examples in Sybase. Prevention techniques will be proposed in the next section based on the effectiveness and the efficiency to defense against those attacks. This research paper will also provide information of possible vulnerabilities to SQL injection attacks in Sybase including recommendations for the known vulnerabilities. The paper will also describe limitation and further recommendations.

Overview

Information Security versus SQL Injection Attacks

The National Security Telecommunications and Information Systems Security Committee (NSTISSC) (Afyouni, 2005, p. 9) suggests that the concept of information security is based on the C.I.A. triangle as a framework for protecting information where each aspect represents an attribute of the information security. Confidentiality is the avoidance of disclosure of information to unauthorized users or systems. Integrity is the avoidance of malicious or other inadvertent modification or destruction of information assets by unauthorized users, programs or systems. Availability is the readiness of the information for usage.

The information security refers to processes, procedures, methodologies, and measures that are designed and implemented to protect the components of information systems (e.g. data, hardware, software, networks, procedures, and people) involved in producing any form of confidential, private, or sensitive information or data from unauthorized access, use, misuse, disclosure, destruction, modification, or disruption. (SANS, 2012)

As a component in the information systems, database management systems (DBMS) are used to store data. The security within the DBMS protects the integrity of the data, records, and databases providing encryption protection at the data level and allows 2

(Kumarbi Consultant, 2011)

organizations to have another layer at which to manage and control the access to the data and information. Major elements of DBMS security include AAAA framework that controls user authentication, user authorization, the auditing of user actions and data changes, and the accounting which measures the resources a user consumes during access. (TechTarget, 2001)(State of Missouri, 2005)

Obviously, the information systems that are vulnerable to SQL injection do not have adequate security measures implemented, enforced, and audited around those security access points. Sybase is one of the database management systems that is widely used in many organizations and has properties that are vulnerable to SQL injection attacks (e.g. batched query, full sub-select support, exceptionally helpful error messages). In order to have effective countermeasures for SQL injection attacks on Sybase, this paper will provide examples of various types of SQL injection attacks on Sybase and also propose prevention techniques for those attacks on it.

SQL injection attacks are a form of threat that exploits security vulnerabilities on database, in which SQL commands are inserted or injected into data-plane input at the application layer in order to effect the execution of predefined SQL commands or SQL query at the database layer. By this approach, SQL injection attacks could happen to any applications that are available for user supplied input (e.g. search application or log in application on website) and also to any databases that the applications are using their data (e.g. Oracle, Sybase, Microsoft SQL Server, etc.). When successful, a SQL injection exploit can access sensitive data on the database, modify data, or execute administration operations on the database, and in some cases issue commands to the operating system. (OWASP, 2012)

Unfortunately, security violations or attacks come in many forms of threat and can happen any time if the database management systems expose vulnerabilities. Afyouni (2005) suggests that the security access points within a database environment which make database vulnerable. The database security access points are people, applications, network, operating system, DBMS, data files, and data. They are the places where security measures must be applied, enforced, and audited.

SQL Injection Attacks and Prevention Techniques on Sybase

This section will firstly discuss an example of SQL injections in Sybase on an online store that sell textbooks. This Java-based website provides a search application (a servlet) for customers to search for titles of textbook they need. The code portion is shown below.
out.println("<html><head><title>Book Title Search Results</title></head>"); out.println("<body><h1>Search results</h1>"); Class.forName("com.sybase.jdbc2.jdbc.SybDriver"); Connection con = DriverManager.getConnection("jdbc:_sybase:Tds:sybtest:5000","sa", "sapassword"); Statement stmt = con.createStatement(); String search = request.getParameter("booktitlesearch"); ResultSet rs = stmt.executeQuery("select * from pubs2..titles where UPPER(title) like UPPER('%" + booktitlesearch + "%')"); rs.next();

The above code portion of the search application will get booktitlesearch parameter, then concatenate for a complete query string that look up for a title under title column in titles table under pubs2 database (pubs2..titles). If the booktitlesearch parameter does not contain special characters, the result page will show its search results for books founds (or not found). Now lets take a look at the vulnerable code snippet

String search = request.getParameter("booktitlesearch"); ResultSet rs = stmt.executeQuery("select * from pubs2..titles where UPPER(title) like UPPER('%" + booktitlesearch + "%')");

If an attacker wants the search application to return the names of the user in the master..syslogins table (syslogins table contains one row for each valid Sybase user account), he may modify the query by entering search string with
dontcare') union select name,null,null,null,null,null,null,null,null,0 from master..syslogins--

so that the above vulnerable code will parse and generate SQL query statement dynamically which will looks like
select * from pubs2..titles where UPPER(title) like UPPER('%dontcare') union select name,null,null,null,null,null,null,null,null,0 from master..syslogins--%')

Another example is the attacker can also put DDL or DML operations and construct SQL statement that looks like below
dontcare') union drop table pubs..titles--

Without a proper handling, the attacker will be able to exploit the search application and the database so that the search result returns the names of the users in syslogins table.

As shown above, SQL injections are security issues since they allow attackers to submit their tailored SQL query, including Data Manipulation Language statements (DML) and Data Definition Language statements (DDL). The attacker is using a pre-authenticated channel that is provided by the application to access information on behalf of the application itself. In this above example, the application is authenticating as "sa" (System 5

Because SQL injection on the Microsoft platform has been so intensely studied, and because Sybase shares many of the same properties that make Microsoft SQL Server particularly vulnerable to SQL injection (for example, batched queries, full sub-select support, exceptionally helpful error messages), it is much possible that attackers could find their way to observe and learn Sybase characteristics based on the vulnerabilities it exposes. Additionally, Sybase provides a whole new set of functionality that could be used by an attacker in the context of a SQL injection attack, the Java integration being one highly significant example. (Litchfield et al, 2005) Prevention Techniques for SQL Injection Attacks on Sybase

Sybase and Microsoft SQL Server share some vulnerability to SQL injection attacks. Sybase sold its code base to Microsoft in the development of Microsoft SQL Server. Until version 4.9, Sybase and Microsoft SQL Server were virtually identical (Wikipedia, 2012). With this reason, Sybase SQL Server and Microsoft SQL Server have identical feature sets in different platforms (Sybase, 1992).

SQL Injection Issues in Sybase

Administrator) so the attacker will also have all privileges that sa user have (which are full privileges) and can take control of the server running Sybase. However, the account that the application uses to connect database normally not sa user and also has privileges lower than sa user.

The more attractive the target information systems are, the more threats attract to them. SQL injection attack is one of those threats and it is very prevalent caused from inappropriate software development.

Because SQL injections look completely legitimate to a database server, most of the preventive measures for SQL injection attacks heavily rely and implement on the application layer and also the approaches that the application invokes SQL execution from the database. 6

The bottom line for prevention SQL injections is to stop writing dynamic queries and/or prevent user supplied input that may contain malicious SQL which could affect the logic of the executed query. (OWASP, 2012)

To prevent your valuable data on Sybase from SQL injection attacks, OWASP (2012) and iAnywhere Solutions (2006) suggest following techniques: Use of Prepared Statements (Parameterized Queries), Use of Stored Procedures, Escaping All User Supplied Input, Enforcing Least Privilege, and Performing White List Input Validation. Using parameterized queries is the technique to avoid generating SQL statement dynamically with the use of concept of value placeholder. When building query, the input value is accepted from the placeholder (bind variable), interpreted as expected data type, and pass parameterized query together with its parameters to DBMS for later execution. The statements that use this technique with the help of parameters are called prepared statements. Different databases have different syntax for bind variables. Oracle bind variables are names preceeded by a colon [:]. In MySQL, DB2 and Firebird, bind variables are represented by question marks [?]. In Sybase and MS SQL Server, bind variables are names preceeded by an @ sign [@]. In PostgreSQL, bind variables are numbers preceeded by a $ sign [$]. (SQLRelay) The following is a C# code sample on a web page that search for a country name Use of Prepared Statements (Parameterized Queries)

Parameterized queries force the developer to first define all the SQL code, and then pass in each parameter to the query later. This coding style allows the database to distinguish between code and data, regardless of what user input is supplied.
string commandText = "SELECT * FROM Customers WHERE Country=@CountryName"; SqlCommand cmd = new SqlCommand(commandText, conn); cmd.Parameters.Add("@CountryName",countryName);

In this case, if the web server provides strong type checking (e.g. ADO.NET), it will return an error if the input string for countryName is invalid. For example, input string for countryName contains just one character or contains any number. Placeholder availability depends on the provision of such features from the DBMS itself or from the data access API used (such as ADO.NET in the above example). Use of Stored Procedures One of the most effective methods for combating injection attacks is by using database stored procedures. Stored procedures require the developer to define the SQL code first, and then pass the parameters to the database later. Although this mechanism seems similar to the prepared statement approach, the difference between them is that the SQL code for a stored procedure is defined and stored in the database itself, and then called from the application. Please note that stored procedures require access rights (e.g. EXECUTE privilege) The following is an example of stored procedure in Sybase for simple query

create proc inoutproc @id int, @newname varchar(50), @newhome Address, @oldname varchar(50) output, @oldhome Address output as select @oldname = name, @oldhome = home from xmp where id=@id update xmp set name=@newname, home = @newhome where id=@id

Another advantage is stored procedures enforce type checking. If an INTEGER variable is expected, everything else will cause errors. If a VARCHAR variable of size 10 is expected, everything else will cause errors. This creates more difficulties to the attackers for those attempts to inject any code into it without causing database server errors. 8

One advantageous difference of using stored procedures is stored procedures are contained within the database and are only invoked by the application code with the necessary parameters passed in. When stored procedure fails, internal working processes will not be exposed.

Moreover, using stored procedures also has performance benefit with the concept of the execution context where the execution context data structures are reused. This means, for example, if a numerous query statements share the same pattern, DBMS (e.g. Sybase)

will share execution context which is a query that complied once but replace only predicates that changed by each statement. However, this paper will not discuss about performance benefit in details.

In addition, there is a note for using stored procedures. As described above, dynamic SQL generation must be avoided. If the stored procedure generates SQL dynamically inside itself, the stored procedure is still vulnerable to SQL injections. Escaping All User Supplied Input

This technique is to escape user input or sanitizing them before putting it in a query, which is done mainly at the application layer. One operation is to rewrite the query statements with the escape character as the character mark to inform database sql parser to treat those special characters as normal plaintext, not as a special character. Another operation is to use replace or rewrite function that, for example, detect all single quotes and prefix them with an escape character or replace them with double quote.

Escaping characters can also be utilized at the database layer with the help of ESCAPE clause, for example, Oracle and Sybase. The following table shows the escape character is predefined to inform the database parser that any one character right behind the escape character will treat as a normal plaintext.

There are many encoders (as APIs) that perform sanitizing characters available for download for free as well. For example, OWASP Enterprise Security API (ESAPI) (OWASP, 2012)

Escaping user-provided input is done at the application. Some languages provide specific functions (such as Perl DBI::quote) that accept a string value and check it to see if it contains special escape characters. Although such methods do not detect SQL code, they can remove escape characters (such as ones that terminate a string), causing the database server to return a SQL syntax error, so it does not execute the statement. (iAnywhere Solutions, 2006)

Enforcing Least Privilege

One of the best practices on database security is to have users rights on the least privilege concept. This concept is also a defense to SQL injection attacks on the database layer. To minimize the potential damage of a successful SQL injection attack, the privileges should be assigned to every database account in an environment on a least-privilege basis.

(Sybase, 2005)

The least privilege concept is the minimal set of operations that users are able to perform their tasks based on the segregation of duties. For example, a user can only have execution privilege to the SQL functions that would need during normal operations or only have access to the tables that contain necessary information. It is recommended that DBA or admin type access rights are not assigned to any application user account. Moreover, if stored procedures are used, the application user should only be given permissions to execute the ones it needs. Performing White List Input Validation

Input validation can be performed in many ways. In case a set of input is known beforehand, one may consider providing a fixed list of data for user, for example, dropdown box for U.S. State selection (AA|AE|AP|ALWI|WY). Another approach is to allow only

The application can be enforced to perform input validation in order to detect unexpected input that user provides before the input is passed to the SQL query. 10

specific set of characters (e.g. only numbers, letters, whitespace, etc.). The other approach is, if patterns of input are known beforehand, one may consider validate with pattern, for example, Zip Code (5 digits plus optional -4) ^\d{5}(-\d{4})?$

Pitfalls and Recommendations

There existed a vulnerability report for SQL injection attacks possible on Sybase that an authenticated database user could execute arbitrary commands with the privileges of the database server process. If the server hosts any web applications which are vulnerable to SQL injection, the vulnerability could also be exploited by unauthenticated users.

Possible Vulnerabilities to SQL Injection Attacks on Sybase and Recommendations

Sybase Adaptive Server Enterprise (ASE) 12.5.3 and earlier are affected by these vulnerabilities. It is recommended to upgrade to Sybase ASE 12.5.3 ESD#1 or higher. (ControlScan, 2010) Research Limitation and Recommendations The scope of the research is limit and based on known SQL injection attacks. However, there will be more advance and sophisticated SQL injection attacks and other types of threat occur every day. Organizations are recommended to perform all proposed techniques and should also keep themselves updated on new attacks and other types of threats. Moreover, all controls over computer and network components must also be in place effectively and efficiently to cover most vulnerabilities, to mitigate risks and lost, and also to maximize level of protection for organizations information systems. For example, information security policies and procedures, database hardening, inclusion of SQL injection checklist in SDLC, using tools such as SQL injection scanner, and also, in some circumstance, using professional services.

11

SQL injection attacks are the threats to information systems that significantly affect information security to all C.I.A aspects. Although the attacks cannot be completely stopped, organizations should be well-prepared by having all security countermeasures in place to cover most vulnerabilities that may expose and also keep updated of new threats for a full defense against SQL injection attacks.

Conclusion

12

References

Afyouni, A. H. (2005). Database Security and Auditing: Protecting Data Integrity and Accessibility (1st ed.). Boston, MA, USA: Course Technology. Clarke, J. (2009). SQL Injection Attacks and Defense (1st ed.). Syngress.

ControlScan. (2010, July 23). Possible vulnerabilities in Sybase ASE 12.5. Retrieved from ControlScan: https://my.controlscan.com/threats/details.cgi?id=504957

iAnywhere Solutions, Inc. (2006). Securing SQL Anywhere Server 10. Dublin, CA, United States of America.

Kumarbi Consultant. (2011, July 12). Introduction to Information Security. Retrieved from Scribd: http://www.scribd.com/doc/59881078/12/NSTISSC-Security-Model

Litchfield, D., Anley, C., Heasman, J., & Grindlay, B. (2005). Attacking Sybase. In D. Litchfield, C. Anley, J. Heasman, & B. Grindlay, The Database Hacker's Handbook: Defending Database Servers (1st ed., p. 88). Wiley. OWASP. (2012, January 18). Category:OWASP Top Ten Project. Retrieved from OWASP The Open Web Application Security Project: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project OWASP. (2012, February 19). SQL Injection. Retrieved from OWASP The Open Web Application Security Project: https://www.owasp.org/index.php/SQL_Injection OWASP. (2012, March 29). SQL Injection Prevention Cheat Sheet. Retrieved from OWASP The Open Web Application Security Project: https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

SANS Institute. (2000-2012). SANS Information Security Resources. Retrieved from SANS: http://www.sans.org/information_security.php

SQL Relay. (n.d.). Substitution and Bind Variables. Retrieved May 6, 2012, from SQL Relay: http://sqlrelay.sourceforge.net/sqlrelay/programming/binds.html 13

State of Missouri. (2005, August 3). Compliance Component. Retrieved from Office of Administration: http://oa.mo.gov/itsd/cio/architecture/domains/information/CCDBMS_Security080305.pdf Sybase Inc. (1992, September 15). Sybase SQL Server for Netware. PC Magazine, 11(15), 413. Sybase Inc. (2005). Using the escape clause. Retrieved from Sybase Adaptive Server Enterprise 15.0: http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.ase_15.0.bloc ks/html/blocks/blocks291.htm Sybase Inc. (2012). SQL Anywhere for Linux. Retrieved from Sybase: http://www.sybase.com/linux/sqlanywhere TechTarget. (2001, January). Authentication, Authorization, and Accounting (AAA). Retrieved from SearchSecurity: http://searchsecurity.techtarget.com/definition/authentication-authorization-andaccounting

Wikipedia. (2012, April 30). Sybase. Retrieved from Wikipedia: http://en.wikipedia.org/wiki/Sybase

14