SQL Injection Attacks and Defense - 2009

272 Chapter 6 • Exploiting the Operating System
Introduction
One of the things mentioned in the introduction to Chapter 1 was the concept of utilizing
functionality within the database to access portions of the operating system. Most databases
ship with a wealth of useful functionality for database programmers, including interfaces for
interacting with the database, or for extending the database with user-defined functionality.
In some cases, such as for Microsoft SQL Server and Oracle, this functionality has provided
a rich hunting ground for security researchers looking for bugs in these two database servers.
In addition, a lot of this functionality can also be employed as exploit vectors in SQL injections
ranging from the useful (reading and writing files) to the fun but useless (making the database
server speak).
In this chapter, we will discuss how to access the file system to perform useful tasks such
as reading data and uploading files. We will also discuss a number of techniques for executing
arbitrary commands on the underlying operating system, which could allow someone to
extend his reach from the database and conduct an attack with a much wider scope.
Before we begin, it is a good idea to discuss why someone would be interested in going
down this rabbit hole at all. The ostensible answer, of course, is the universal one: because
it is there. Beyond the trite sound byte, however, there a several reasons why someone would
want to use SQL injection to attack the host.
For instance, attacking the base host may allow the attacker to extend his reach. This means
that a single application compromise can be extended to target other hosts in the vicinity of
the database server. This ability to use the target database server as the pivot host bears promise,
especially since the database server has traditionally resided deep within the network in what is
most often a “target-rich” environment.
Using SQL injection attacks to target the underlying host is also attractive because it
presents an attacker with the somewhat rare opportunity to slide into a crevice where the lines
between traditional unauthenticated and authenticated attacks reside. Overburdened system
administrators and database administrators (DBAs) will often prioritize patching based on
whether a vulnerability can be exploited by an anonymous user. In addition, exploits that
require an authenticated user are sometimes put on the back burner while other, more urgent
fires receive attention. An attacker exploiting an SQL injection bug effectively transforms his
role from that of the unauthenticated anonymous user to the authenticated user being used
by the application for the database connection. We will examine all of these cases both in this
chapter and in Chapter 7.