2.4. ATAQUES EN ORACLE 2.4.1. SQL INJECTION

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 trátese de Oracle, MySQL o cualquier otra.
De hecho, contrario a lo que se pensaría al hablar de un ataque del cual se tiene tanta
información en la actualidad, tras varias encuestas y estudios realizados en el año 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].
Ilustración 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, ningún desarrollador o analista de
seguridad debe bajar sus defensas frente a los ataques de SQL Injection. Debemos
percatarnos de que por su amplia divulgación y su alto porcentaje de efectividad, la
sofisticación de estos ataques se encuentra en aumento y así mismo deberían 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 información [1]. Entre
el 2007 y el 2010 los ataques de inyección, 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 también
representa una amenaza para Oracle [3] [4].
OWASp califica los ataques de inyección de fácil uso, frecuencia común, 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 información, falta de responsabilidad, denegación de servicios y en algunos
casos pueden llevar a la toma de posesión total del servidor por parte del atacante [3].
Los ataques de SQL Injection se aprovechan principalmente, de las malas prácticas de
desarrollo de aplicaciones, explotando la falta de un manejo adecuado de la entrada de
datos por parte del usuario que posteriormente serán usados en sentencias SQL [2]. Los
atacantes engañan 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
información restringida [4].
La mayoría de estos ataques se presentan en interfaces web, por el hecho de que en una
aplicación web el atacante puede realizar ataques de SQL Injection sin ninguna
autenticación en la base de datos o la aplicación, dicho esto, es claro que estas
representan una vulnerabilidad para las organizaciones y por ende debe realizarse un
análisis cuidadoso del beneficio de proveer acceso web frente al costo de la posible
perdida de información [2] [4].
Los técnicas 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 dinámica, e interpretadas como código por el motor SQL” [4].
Oracle se ha manejado bien frente a los ataques de SQL Injection por varias
características entre las cuales es de destacar el uso de bind arguments (variables de
enlace) que si bien fueron diseñadas principalmente para mejorar el desempeño,
proveen también una fuerte protección contra dichos ataques cuando se programa SQL
dinámico pues obligan a la base de datos a utilizar exclusivamente el valor de la
variable y no interpretar su contenido de ningún modo [4] [2] [5]. Aunque Oracle puede
proveer mayor protección frente a estas técnicas, que otras bases de datos, aplicaciones
sin las defensas apropiadas pueden ser vulnerables [2].
Para inmunizar cualquier código contra ataques SQL Injection, deben usarse bind
arguments, bien sea automáticamente en SQL estático o explícitamente en SQL
dinámico, y adicionalmente validar y desinfectar cada entrada concatenada a SQL
dinámico. La validación comprueba que la entrada cumpla ciertos criterios (Ej. que no
contenga comillas simples independientes) y la desinfección modifica la entrada para
asegurar que es válida (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 continuación se presenta un diagrama de flujo que expone los pasos para medir la
vulnerabilidad de cualquier código SQL:
Ilustración 2 : Diagrama de flujo para detectar vulnerabilidades de SQL Injection [4]
Para detalles mas específicos sobre como protegerse frente a técnicas 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
capítulos con evaluaciones interactivas al final de capa sección [4].
2.4.2. Tipos de ataques SQL Injection
Los ataques de inyección son comúnmente divididos en:
2.4.2.1.
Ataques de primer orden
El atacante simplemente ingresa una cadena de texto maliciosa y
provoca que el código modificado sea ejecutado inmediatamente. El
ejemplo mas común consiste en modificar la clausula WHERE de una
consulta de autenticación 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 aplicación
objetivo y aprovechan la naturaleza stateless de muchas aplicaciones
web que acostumbran pasar información entre páginas almacenando
valores en la base de datos, generando así una vulnerabilidad [2].
2.4.2.3.
Inyección 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 numérico, 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
categorías [2]:
1.
2.
3.
4.
SQL Manipulation
Code Injection
Function Call Injection
Buffer Overflows
Las dos primeras categorías pueden incluirse dentro de los ataques de primer orden
mencionados anteriormente, son las más comunes, y se aplican a todos los tipos de
bases de datos. Aunque la segunda sea menos común en Oracle que en otras bases de
datos, por el hecho de no soportar peticiones de múltiples sentencias SQL por base de
datos, se pueden presentar casos de Code Injection en Oracle cuando se trabaja con SQL
dinámico en PL/SQL [2] [4] [5].
Las ultimas dos categorías contienen ataques más específicos a Oracle, son menos
comunes que las primeras y por ende se encuentra menos documentación disponible
sobre estas, lo cual incrementa su aparición como vulnerabilidades en la mayoría de
auditorias de seguridad realizadas a aplicaciones web [2]. A continuación se expone con
mayor detalle cada uno de los tipos de Inyección 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 común 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 clásico de este ataque se presenta en la autenticación de
usuarios de una aplicación donde se ejecuta una consulta como la siguiente:
SELECT * FROM usuarios
WHERE nombreusuario= ‘miusuario’ and contraseña = ‘micontraseña’
El atacante podría manipular la sentencia SQL con una consulta como esta:
SELECT * FROM usuarios
WHERE nombreusuario= ‘miusuario’ and contraseña = ‘micontraseña’ or ‘1’ = ‘1’
Si no se tienen las medidas adecuadas de verificación en la aplicación, la consulta
anterior retornaría verdadero para todas las filas basándose en la precedencia de
operadores [2].
También suele ser común 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 también 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 común 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 ejecución de varias sentencias por
base de datos [2].
Sin embargo algunas API’s permiten la ejecutar dinámicamente bloques anónimos 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 contraseña de usuario [2]:
BEGIN ENCRYPT PASSWORD ('Javeriana', 'micontraseña'); END;
Y convertirlo en el siguiente [2]:
BEGIN ENCRYPT PASSWORD('Javeriana',
upper(username) = upper('admin'); END;
'micontraseña'); DELETE FROM users WHERE
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 información 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 función
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 información almacenada en la base de datos. Usando las
funciones estándar de Oracle, un atacante puede enviar información 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 contraseñas 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 dinámicamente es vulnerable, incluso las sentencias
más sencillas [2].
Este ejemplo puede ser nítido para ver como se mezclñan los atques pero primero toca
explicar de uno en uno
Un claro ejemplo del uso este ataque fue presentado el presente año 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 implementación
implícita 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 sesión con pocos
privilegios, haciendo uso del paquete DBMS_JVM_EXP_PERMS, el cual usualmente
permite importar o exportar las políticas de java entre distintos servidores de la base de
datos, este paquete, puede ser ejecutado por el rol PUBLIC, es decir, por cualquier usuario
común 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 función, 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$,
permitiéndole 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 sección ú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 Díaz. (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