2.4.

ATAQUES EN ORACLE
2.4.1. SQL INJECTION
El SQL Injection es un ataque simple y conocido, pero no por eso deja de representar
una amenaza para cualquier base de datos trtese de Oracle, MySQL o cualquier otra.
De hecho, contrario a lo que se pensara al hablar de un ataque del cual se tiene tanta
informacin en la actualidad, tras varias encuestas y estudios realizados en el ao 2010
por OWASP (Open Web Application Security Project) se determino que entre las
mayores brechas de seguridad que terminan comprometiendo datos, los ataques de este
tipo predominan con un 60% del total si contamos los casos en que este ataque es
combinado con malware [1].

Ilustracin 1: Vulnerabilidad usada para comprometer el sistema [1]

Muchos desarrolladores de aplicaciones subestiman el riesgo de ataques SQL Injection

a aplicaciones web que usen Oracle como base de datos de respaldo final [2], aunque
Oracle represente una alternativa muy confiable, ningn desarrollador o analista de
seguridad debe bajar sus defensas frente a los ataques de SQL Injection. Debemos
percatarnos de que por su amplia divulgacin y su alto porcentaje de efectividad, la
sofisticacin de estos ataques se encuentra en aumento y as mismo deberan aumentar
los esfuerzos por detectar vulnerabilidades, corregir fallas y proteger las aplicaciones e
interfaces con el fin de garantizar la seguridad e integridad de la informacin [1]. Entre
el 2007 y el 2010 los ataques de inyeccin, entre los cuales encontramos el SQL
Injection como el principal representante, pasaron del segundo lugar al primero en el
Top 10 presentado por OWASP anualmente en el cual se clasifican los principales
ataques y vulnerabilidades en aplicaciones web, en el segundo lugar actualmente se

encuentra el Cross Site Scripting (XSS), que como veremos mas adelante tambin
representa una amenaza para Oracle [3] [4].
OWASp califica los ataques de inyeccin de fcil uso, frecuencia comn, detectabilidad
promedio e impacto severo; pueden ser realizados por cualquier persona que pueda
enviar datos no confiables al sistema, incluyendo usuarios externos, usuarios internos, y
administradores del sistema. Entre las principales consecuencias podemos encontrar
perdida de informacin, falta de responsabilidad, denegacin de servicios y en algunos
casos pueden llevar a la toma de posesin total del servidor por parte del atacante [3].
Los ataques de SQL Injection se aprovechan principalmente, de las malas prcticas de
desarrollo de aplicaciones, explotando la falta de un manejo adecuado de la entrada de
datos por parte del usuario que posteriormente sern usados en sentencias SQL [2]. Los
atacantes engaan al motor de la base de datos para que este ejecute comandos no
deseados, suministrando cadenas de texto hechas especialmente para este fin,
consiguiendo as acceso no autorizado a la base de datos para visualizar o manipular
informacin restringida [4].
La mayora de estos ataques se presentan en interfaces web, por el hecho de que en una
aplicacin web el atacante puede realizar ataques de SQL Injection sin ninguna
autenticacin en la base de datos o la aplicacin, dicho esto, es claro que estas
representan una vulnerabilidad para las organizaciones y por ende debe realizarse un
anlisis cuidadoso del beneficio de proveer acceso web frente al costo de la posible
perdida de informacin [2] [4].
Los tcnicas de SQL Injection pueden variar, pero todas explotan una misma
vulnerabilidad: Cadenas de texto validadas o no validadas que son concatenadas en
una sentencia SQL dinmica, e interpretadas como cdigo por el motor SQL [4].
Oracle se ha manejado bien frente a los ataques de SQL Injection por varias
caractersticas entre las cuales es de destacar el uso de bind arguments (variables de
enlace) que si bien fueron diseadas principalmente para mejorar el desempeo,
proveen tambin una fuerte proteccin contra dichos ataques cuando se programa SQL
dinmico pues obligan a la base de datos a utilizar exclusivamente el valor de la
variable y no interpretar su contenido de ningn modo [4] [2] [5]. Aunque Oracle puede
proveer mayor proteccin frente a estas tcnicas, que otras bases de datos, aplicaciones
sin las defensas apropiadas pueden ser vulnerables [2].
Para inmunizar cualquier cdigo contra ataques SQL Injection, deben usarse bind
arguments, bien sea automticamente en SQL esttico o explcitamente en SQL
dinmico, y adicionalmente validar y desinfectar cada entrada concatenada a SQL
dinmico. La validacin comprueba que la entrada cumpla ciertos criterios (Ej. que no
contenga comillas simples independientes) y la desinfeccin modifica la entrada para
asegurar que es vlida (Ej. doblar las comillas simples) [4]. Oracle provee un paquete
PL/SQL llamado DBMS_ASSERT, el cual contiene funciones que permiten validar y
desinfectar cadenas de entrada [4].
A continuacin se presenta un diagrama de flujo que expone los pasos para medir la
vulnerabilidad de cualquier cdigo SQL:

Ilustracin 2 : Diagrama de flujo para detectar vulnerabilidades de SQL Injection [4]

Para detalles mas especficos sobre como protegerse frente a tcnicas de SQL Injection
al programar en PL/SQL, se recomienda revisar el tutorial provisto por Oracle titulado
SQL Injection Tutorial el cual es gratuito, descargable y contiene lecciones por
captulos con evaluaciones interactivas al final de capa seccin [4].

2.4.2. Tipos de ataques SQL Injection

Los ataques de inyeccin son comnmente divididos en:
2.4.2.1.

Ataques de primer orden

El atacante simplemente ingresa una cadena de texto maliciosa y
provoca que el cdigo modificado sea ejecutado inmediatamente. El
ejemplo mas comn consiste en modificar la clausula WHERE de una
consulta de autenticacin para que siempre retorne verdadero [4].

2.4.2.2.

Ataques de segundo orden

El atacante inyecta en datos almacenados permanentemente que son
considerados una fuente confiable (Ej. una fila de una tabla) y
posteriormente otra actividad ejecuta el ataque indirectamente [4]. Este
tipo de ataques requieren un mayor conocimiento de la aplicacin
objetivo y aprovechan la naturaleza stateless de muchas aplicaciones
web que acostumbran pasar informacin entre pginas almacenando
valores en la base de datos, generando as una vulnerabilidad [2].

2.4.2.3.

Inyeccin lateral

El atacante puede explotar procedimientos PL/SQL que ni siquiera reciben

entrada de usuario. Contrario a lo que se puede pensar, cuando una variable
cuyo tipo es de fecha o numrico, y est concatenada en el texto de una
sentencia SQL, puede existir una vulnerabilidad [4].
Adicionalmente podemos dividir los ataques de SQL Injection a Oracle en las siguientes
categoras [2]:
1.
2.
3.
4.

SQL Manipulation
Code Injection
Function Call Injection
Buffer Overflows

Las dos primeras categoras pueden incluirse dentro de los ataques de primer orden
mencionados anteriormente, son las ms comunes, y se aplican a todos los tipos de
bases de datos. Aunque la segunda sea menos comn en Oracle que en otras bases de
datos, por el hecho de no soportar peticiones de mltiples sentencias SQL por base de
datos, se pueden presentar casos de Code Injection en Oracle cuando se trabaja con SQL
dinmico en PL/SQL [2] [4] [5].
Las ultimas dos categoras contienen ataques ms especficos a Oracle, son menos
comunes que las primeras y por ende se encuentra menos documentacin disponible
sobre estas, lo cual incrementa su aparicin como vulnerabilidades en la mayora de
auditorias de seguridad realizadas a aplicaciones web [2]. A continuacin se expone con
mayor detalle cada uno de los tipos de Inyeccin en Oracle, pero se har nfasis en los
ltimos dos tipos por las razones mencionadas anteriormente.

2.4.3. SQL MANIPULATION

SQL Manipulation representa el tipo mas comn de ataque de SQL Injection. El
atacante intenta modificar la sentencia SQL adicionando elementos a la clausula
WHERE o extendiendo la consulta con operadores como UNION, INTERSECT o
MINUS [2]. El ejemplo clsico de este ataque se presenta en la autenticacin de
usuarios de una aplicacin donde se ejecuta una consulta como la siguiente:

SELECT * FROM usuarios

WHERE nombreusuario= miusuario and contrasea = micontrasea
El atacante podra manipular la sentencia SQL con una consulta como esta:
SELECT * FROM usuarios
WHERE nombreusuario= miusuario and contrasea = micontrasea or 1 = 1
Si no se tienen las medidas adecuadas de verificacin en la aplicacin, la consulta
anterior retornara verdadero para todas las filas basndose en la precedencia de
operadores [2].
Tambin suele ser comn el uso del operador UNION para retornar filas de otra tabla,
por ejemplo se puede intentar listar todos los productos disponibles de una tienda y
usando este operador hacer que se listen tambin todos los usuarios de la base de datos
[2].

2.4.4. CODE INJECTION

Este ataque consiste en inyectar comandos o sentencias dentro de una sentencia SQL,
este tipo de ataque no es tan comn en Oracle como en otras bases de datos debido a
que Oracle no proporciona ninguna sentencia correspondiente a la sentencia
EXECUTE (SQL Server), ni permite la solicitud de ejecucin de varias sentencias por
base de datos [2].
Sin embargo algunas APIs permiten la ejecutar dinmicamente bloques annimos de
PL/SQL los cuales son vulnerables ante un ataque de Code Injection.
Por ejemplo, un atacante puede manipular el bloque PL/SQL, que ejecuta un proceso
almacenado de la base de datos que cifra y almacena una contrasea de usuario [2]:
BEGIN ENCRYPT PASSWORD ('Javeriana', 'micontrasea'); END;
Y convertirlo en el siguiente [2]:
BEGIN ENCRYPT PASSWORD('Javeriana', 'micontrasea'); DELETE FROM users WHERE
upper(username) = upper('admin'); END;

2.4.5. FUNCTION CALL INJECTION

Los ataques de Function Call Injection insertan funciones Oracle o funciones

tradicionales dentro de sentencias SQL vulnerables con el fin de invocar llamadas de
sistema operativo o manipular informacin almacenada en la base de datos [2].
Oracle permite ejecutar funciones como parte de sentencias SQL, adicionalmente,
provee mas de 1000 funciones contenidas en aproximadamente 175 paquetes, de las
cuales solo algunas pocas son tiles para ataques de SQL Injection. Cualquier funcin
tradicional o que est almacenada en un paquete tradicional puede ser invocada desde
unas sentencia SQL [2].
Principalmente, solo las funciones ejecutadas dentro de sentencias INSERT, UPDATE o
DELETE pueden modificar informacin almacenada en la base de datos. Usando las
funciones estndar de Oracle, un atacante puede enviar informacin a otras maquinas o
ejecutar nuevos ataques desde el servidor de la base de datos. Muchas aplicaciones
basadas en Oracle, incluyen paquetes que pueden ser explotados por un atacante, dichos
paquetes pueden contener funciones que cambien contraseas o realicen actividades
sensibles de transacciones [2].
El principal asunto a tener en cuenta cuando tratamos Function Call Injection, es que
cualquier sentencia SQL generada dinmicamente es vulnerable, incluso las sentencias
ms sencillas [2].

Este ejemplo puede ser ntido para ver como se mezclan los atques pero primero toca
explicar de uno en uno
Un claro ejemplo del uso este ataque fue presentado el presente ao por David Litchfield en
la conferencia de seguridad BlackHat DC 2010, en su ataque, Litchfield combina Lateral
Injection, Function Call Injection y Pl/SQL Injection para aprovechar la implementacin
implcita de Java en Oracle, que ha sido denominada Aurora, y as tomar control total de la
base de datos [7].
El ataque comienza obteniendo privilegios arbitrarios de Java desde una sesin con pocos
privilegios, haciendo uso del paquete DBMS_JVM_EXP_PERMS, el cual usualmente
permite importar o exportar las polticas de java entre distintos servidores de la base de
datos, este paquete, puede ser ejecutado por el rol PUBLIC, es decir, por cualquier usuario
comn e incluye un procedimiento llamado IMPORT_JVM_PERMS que recibe como
argumento una Java Policy. Un atacante puede crear su propia Policy y enviarla como
argumento a esta funcin, al hacer esto, como el procedimiento se ejecuta con privilegios de
SYS, la Policy creada por el atacante es adicionada a la tabla JAVA$POLICY$,
permitindole al atacante concederse a s mismo permisos Java arbitrarios como por
ejemplo el permiso Java execute para todos los archivos [7] [6].

No se si hacer una seccin nicamente para explicar los permisos de java , como se
manejan en Oracle y como pueden afectar las fallas en la arquitectura de Aurora la
seguridad de la base de datos

Trabajos citados
[1]

Carsten Maple and Alan Phillips. (2010, Enero) 7Safe. [Online].

www.7safe.com/breach_report

[2]

Stephen Kost. (2007, Marzo) Integrigy Coprporation. [Online].

www.integrigy.com/securityresources/whitepapers/Integrigy_Oracle_SQL_Injection_Attacks.pdf

[3]

Vicente Daz. (2010, Febrero) OWASP Top 10 2010: Riesgos de seguridad

en las Aplicaciones Web. Presentacion de diapositivas.

[4]

Oracle. (2009) SQL Injection Tutorial. Manual Electronico.

[5]

Lance Ashdown and Oracle, Oracle Database Application Developer's

Guide - Fundamentals 10g Release 2., 2005.

[6]

David Litchfield. (2010, Febrero) BlackHat DC 2010: Hacking Oracle 11g.

Conferencia Grabada.

[7]

David Litchfield. (2009, Octubre) Database Security. [Online].

www.databasesecurity.com/HackingAurora.pdf