Attacking Sybase

This section covers techniques for attacking Sybase servers. These techniques are applicable in a number of situations; for example several of the techniques listed under "SQL Injection" are relevant to any situation in which the attacker can issue arbitrary SQL queries.

SQL Injection in Sybase

Sybase has a particular problem when it comes to SQL Injection, which is partly because of its shared "ancestral" code base with Microsoft SQL Server. 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 (batched queries, full sub-select support, exceptionally helpful error messages), it is quite likely that an attacker will be able to "find his way around" even if he doesn't know Sybase that well. 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.

This section offers a brief SQL Injection refresher, evaluates the effectiveness of well-publicized Microsoft SQL Server attack techniques in a Sybase environment, and then explores some Sybase-specific techniques such as Java-In-SQL and filesystem interaction via proxy tables.

Before we get too deeply involved in the mechanics of SQL injection, we should briefly discuss severity and workarounds. If your Sybase server (and XP service) are running as low-privileged users, and the Sybase user that the web application is using to connect is low-privileged, and you're fully patched up to date, the practical impact of SQL injection is radically reduced. It is still a serious issue, since the attacker can still do everything to the data that the application can do, but it reduces the possibility of the attacker using your database server as a beachhead into your internal network.

We will talk about defense in general later in this chapter.

SQL Injection Basics

In order to properly discuss SQL Injection we need a sample application that adequately demonstrates the problem. Normally people are most concerned about SQL injection in web applications, so we will use a very simple web app as an example. There is a difficulty in deciding on a technology platform for the sample application because Sybase supports so many mechanisms. Because Java is a key part of Sybase's strategy, a small Java Servlet-based web application is probably appropriate.

The following is the source code for a small sample Java Servlet that queries the default pubs2 database in Sybase for books with a title that contains a specified search string. This can be installed in any Servlet-enabled web server, for example Tomcat.

 import java.io.*; import java.lang.*; import java.net.*; import java.sql.*; import javax.servlet.*; import javax.servlet.http.*; import com.sybase.jdbc2.jdbc.*; public class BookQuery extends HttpServlet  {     public void init(ServletConfig config) throws ServletException      {         super.init(config);     }          public void destroy(){}          protected void processRequest( HttpServletRequest request,  HttpServletResponse response)     throws ServletException, IOException     {         PrintWriter out = response.getWriter();         try         {             response.setContentType("text/html");             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("search");             ResultSet rs = stmt.executeQuery("select * from  pubs2..titles where UPPER(title) like UPPER('%" + search + "%')");             int numberOfColumns = rs.getMetaData().getColumnCount();                         rs.next();             out.println("<TABLE border=1>");             while( !rs.isAfterLast())             {                     out.print("<TR>");                     for( int i = 1; i <= numberOfColumns; i++ )                     {                         out.print("<TD>");                         out.print(rs.getString(i));                         out.print("</TD>");                     }                     out.print("</TR>");                     rs.next();             }             rs.close();             out.println("</TABLE>");             out.println("</body>");             out.println("</html>");         }         catch( SQLException e )         {             while( e != null )             {                 out.println(e);                    e = e.getNextException();             }         }         catch( Exception e )         {                 out.println("Exception:" + e);            }     }          protected void doGet(HttpServletRequest request, HttpServletResponse response)     throws ServletException, IOException     {         processRequest(request, response);     }          protected void doPost(HttpServletRequest request, HttpServletResponse response)     throws ServletException, IOException      {         processRequest(request, response);     }          public String getServletInfo()      {         return "SQL Injection Servlet Sample";     }      } 

Once installed, the Servlet can be queried directly via a GET request like this:

 http://sybase.example.com/servlet/BookQuery?search=database 

This returns the record for "The Busy Executive's Database Guide."

If we search for the single-quote character ( ' ), we get an error message:

 com.sybase.jdbc2.jdbc.SybSQLException: Unclosed quote before the  character string ')'. com.sybase.jdbc2.jdbc.SybSQLException: Incorrect syntax near ')'. 

The problem here is that the Servlet is composing a SQL query in a string, and isn't validating the user's input. Because the input can contain a single-quote character ( ' ), the attacker can modify the query to do subtly different things.

Here is the vulnerable code snippet:

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

So let's say we want to return the names of the users in the master..syslogins table. We can modify the query so that it looks like this:

 select * from pubs2..titles where UPPER(title) like UPPER('%1234') union  select name,null,null,null,null,null,null,null,null,0 from  master..syslogins--%') 

Submitting the following URL:

 http://sybase.example.com/servlet/BookQuery?search=1234')+union+select+ name,null,null,null,null,null,null,null,null,0+from+master..syslogins-- 

will return the names of all users in the syslogins table.

In fact, if we're not interested in the results, we can submit any SQL we like, by using Transact-SQL's query batching feature:

 http://sybase.example.com/servlet/BookQuery?search=')+create+table+foo(a+integer)-- 

Obviously this is a serious security problem, for several reasons:

  1. The attacker can submit the SQL query of his choice, including Data Manipulation Language statements (DML) and Data Definition Language statements (DDL).

  2. The attacker is using a pre-authenticated channel that is provided by the application; therefore he can do anything the application can do. In the contrived example above, the application is authenticating as "sa" ”so the attacker can easily take control of the server running Sybase ”but normally the account would be a lower-privileged user account.

Because in this specific case, the attack is based on the attacker being able to insert a single quote, a quick way to prevent this would be to insert the line

 search = search.replaceAll( "'", "''"); 

after the call to getParameter, to "double up" single quotes. Of course, this won't work for numeric data since numbers are not delimited in Transact SQL. If our search was for pub_id or price, the attacker could simply inject SQL directly after the number, without needing single quotes.

Now that you've had a (very) brief look at SQL injection, the next section takes a deeper look at which Microsoft SQL Server SQL injection techniques work, and which don't.



Database Hacker's Handbook. Defending Database Servers
The Database Hackers Handbook: Defending Database Servers
ISBN: 0764578014
EAN: 2147483647
Year: 2003
Pages: 156

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net