Auditoria en DB2

Ramón Pinuaga Cascales

rpinuaga@s21sec.com
 Índice

1. Introducción
2. Cuentas de usuario
3. Roles y privilegios
4. DB2 SQL
5. Vías de acceso
6. Inyección de SQL
7. Registro
8. Sistema operativo
 1. Introducción

El tema central de esta ponencia es la auditoria de seguridad en

bases de datos DB2, desde un enfoque practico.

¿A que nos referimos con “enfoque practico”? Pues al enfoque que

analiza la seguridad desde el punto de vista del atacante que
pretende acceder a información sensible o utilizar la base de datos
para atacar otros sistemas. (Basado en pentest)

Pero no olvidaremos al defensor. Daremos consejos a los

administradores para defender sus sistemas frente a posibles
ataques.
 Historia

DB2 es la marca tras la que IBM comercializa una de sus familias

de productos de gestión de la información.

Aunque tradicionalmente cuando se habla de DB2 se habla del

producto estrella de esta serie, la base de datos relacional DB2
UDB (Universal DataBase).

En esta ponencia cuando hablamos de DB2 nos referiremos

únicamente a la base de datos UDB.

DB2 como base de datos tiene una larga historia, y algunos la

consideran la primera base de datos comercial en soportar SQL.
 Diferencias entre plataformas

Las versiones actuales de DB2 corren sobre multitud de

plataformas, que según sus características podemos agrupar en 3
grandes grupos:
DB2 para z/OS (antiguamente OS/390)
DB2 para iSeries (AS/400)
DB2 para sistemas Unix/Windows

Aunque el núcleo común es muy similar, el comportamiento de la

base de datos en las distintas plataformas presenta algunas
peculiaridades en el aspecto que mas nos interesa: la seguridad.
 DB2 para z/OS

Para una lista completa de diferencias podemos consultar la tabla

que aparece en la siguiente pagina:
http://www-03.ibm.com/servers/enable/site/db2/db2common.html

Las peculiaridades en cuanto a la seguridad de DB2 en esta

plataforma respecto a las otras, se deben principalmente a las
características del propio sistema operativo. (Sistema
comparticionado, pocas herramientas de red, sistema de ficheros
especial)
 DB2 para AS/400

En los AS/400 la base de datos DB2 viene integrada fuertemente

en el propio sistema operativo constituyendo uno de los pilares del
mismo.

La base de datos cuenta con un catalogo propio que se compone

de una serie de vistas y tablas que contienen información sobre
todos los elementos de la base de datos y contiene incluso
entradas para objetos de la base de datos creados usando
métodos tradicionales de AS/400, no-SQL.

El catalogo se encuentra en los esquemas: QSYS y QSYS2

 Catalogo DB2 para AS/400

Se incluye una capa de compatibilidad con los catálogos ISO a

través del esquema “SYSCAT” que funciona como sinónimo de
“INFORMATION_SCHEMA” y con los catálogos DB2 para otras
plataformas a través del esquema “SYSIBM”.

Estas 3 sentencias serian equivalentes:

SELECT * FROM QSYS2.TABLES WHERE TABLE_SCHEMA =
'WORK'

SELECT * FROM SYCAT.TABLES WHERE TABSCHEMA = ‘WORK’

SELECT * FROM SYSIBM.TABLES WHERE TABLE_SCHEMA =

'WORK‘
 Llamada a programas AS/400

DB2 para AS/400 también cuenta con otra peculiaridad respecto a

las demás plataformas.

Existe de serie un procedimiento almacenado llamado “qcmdexc”

que permite activar cualquier programa iSeries desde SQL si
recibe los parámetros adecuados.

Ejemplo:
CALL QSYS.QCMDEXC('CALL PGM (MYLIB/MYPGM)',
0000000022.00000)
 DB2 para Unix/Windows

Es habitual referirse a esta variante como DB2 LUW: Linux-Unix-

Windows.

En estas plataformas la base de datos DB2 se instala como un

componente mas.

La mayoría de ejemplos de esta ponencia se basan en esta

variante de DB2.
 Índice

1. Introducción
2. Cuentas de usuario
3. Roles y privilegios
4. DB2 SQL
5. Vías de acceso
6. Inyección de SQL
7. Registro
8. Sistema operativo
 2. Cuentas de usuario

Uno de los factores más característicos de DB2 en contraste con

otras bases de datos es su forma de gestionar las cuentas de
usuario.

DB2 no cuenta con un sistema de autenticación propio, tiene que

basarse en uno externo.

Esto limita los ataques posibles. No es posible consultar y/o crear

usuarios directamente desde la propia base de datos.
 Autenticación de clientes

DB2 soporta multitud de mecanismos para autenticar a los clientes

que intentan acceder a la base de datos:
SERVER (“default” para conexiones remotas)
SERVER_ENCRYPT
CLIENT
KERBEROS
KRB_SERVER_ENCRYPT
DCS
DCS_ENCRYPT
DCE
DCE_SERVER_ENCRYPT

En la mayoría de los casos, se utiliza el método “SERVER”, que se

basa en utilizar la autenticación del sistema operativo del servidor.
 Usuarios habituales

Como hemos comentado, los usuarios normalmente son gestionados por

el sistema operativo del servidor.

Esto hace que durante el proceso de instalación de la base de datos, sea

necesario crear una serie de usuarios en el sistema.

No podemos por lo tanto hablar de “usuarios por defecto”, aunque los

nombres que se suele asignar a estos usuarios suelen repetirse:
db2admin (Windows)
db2inst1, dasusr1, db2as, db2fenc1 (Unix)

Las contraseñas suelen ser también bastante predecibles si el

administrador no se ha preocupado en exceso:
Contraseña = usuario
db2
ibmdb2
 Puntos a revisar

Eliminar los usuarios no utilizados a nivel del sistema operativo.

Comprobar que las contraseñas utilizadas son robustas (Y la

política de contraseñas del sistema operativo).

Ajustar la seguridad del mecanismo de autenticación del sistema

operativo a la criticidad de la información contenida en la base de
datos.

Utilizar SERVER_ENCRYPT en lugar de SERVER en la medida de

lo posible.
 Índice

1. Introducción
2. Cuentas de usuario
3. Roles y privilegios
4. DB2 SQL
5. Vías de acceso
6. Inyección de SQL
7. Registro
8. Sistema operativo
 3. Roles y privilegios

Una vez el usuario ha sido autenticado, es ya el “security manager” de la

propia base de datos el que asigna los privilegios con los que cuenta en
el sistema.

La autorización se controla según distintos parámetros:

Autorización explicita, según los privilegios se le hayan asignado
específicamente a ese usuario.
Según los privilegios del grupo al que pertenezca.
Autorización implícita, que se le asigna automáticamente al creador de un
objeto.
Privilegios indirectos asociados a un package.

Todos los usuarios pertenecen al grupo “PUBLIC”.

Cuando la autenticación la gestiona el sistema operativo, cualquier

usuario del equipo cuenta con acceso a la base de datos (como public).
 Niveles de autoridad

DB2 emplea varios niveles de autoridad para las tareas

administrativas:
Asignados a nivel de instancia:
SYSADM / System Administrator: Nivel de mayor autoridad. Sin
limitaciones.
SYSCTRL / System Control: Primer nivel de control.
SYSMAINT / System Maintenance
SYSMON / System Monitor
Asignados a nivel de la base de datos:
DBADM / Database Administrator: Es el segundo nivel de mayor
autoridad.
LOAD / Load
IMPLICIT_SCHEMA: Permite crear un esquema nuevo y objetos
dentro de el.
CREATE_EXTERNAL_RUOTINE: Permite crear procedimientos
almacenados, métodos y funciones definidas por el usuario. (Nuevo
en UDB v8.1)
Niveles de autoridad
 Elementos con privilegios

Elementos a los que se les puede asignar privilegios de

acceso:
Database
Object
Schema
Tablespace
Table
Index
View
Package
Routine
Sequence
Server
Nickname
 Privilegios de acceso

Privilegios de acceso a Tablas:

CONTROL
ALTER
SELECT
INSERT
UPDATE
DELETE
INDEX
REFERENCES

Ejemplo:
GRANT SELECT ON EMPLOYEE TO USER DEMO
GRANT SELECT ON EMPLOYEE TO GROUP DEMO

REVOKE SELECT ON EMPLOYEE FROM USER DEMO

Privilegios de acceso
 Niveles de acceso

Para asignar los privilegios de acceso a la mayoría de elementos

de una base de datos, el usuario debe tener autoridad SYSADM,
DBADM; o contar con los privilegios de CONTROL sobre el
elemento.

Los privilegios solo pueden ser asignados a elementos existentes.

Para asignar el privilegio de CONTROL, el usuario debe tener

autoridad SYSADM o DBADM.

Por defecto, el creador de un elemento recibe el privilegio de

CONTROL sobre el mismo.
 Consultar la configuración de acceso

La configuración de los privilegios de acceso puede ser consultada

a través de una serie de vistas del sistema disponibles en el
catalogo “SYSCAT”.

Los privilegios asignados por el sistema tienen a “SYSIBM” como

otorgante. Las autoridades SYSADM, SYSMAINT, SYSCTRL y
SYSMON no aparecen en estas vistas.

Ejemplos:
SELECT * FROM SYSCAT.DBAUTH WHERE GRANTEE = 'PUBLIC'
SELECT * FROM SYSCAT.TABAUTH WHERE GRANTEE =
'PUBLIC'
 Tablas de privilegios

Las siguientes vistas contienen toda la información sobre

privilegios de acceso:
SYSCAT.DBAUTH: Privilegios de base de datos
SYSCAT.TABAUTH: Privilegios de tablas y vistas
SYSCAT.COLAUTH: Privilegios de columnas
SYSCAT.PACKAGEAUTH: Privilegios de paquetes.
SYSCAT.INDEXAUTH: Privilegios de índices
SYSCAT.SCHEMAAUTH: Privilegios de esquemas
SYSCAT.PASSTHRUAUTH: Privilegios de servidores
SYSCAT.ROUTINEAUTH: Privilegios de funciones, métodos y
procedimientos almacenados
 Privilegios de instancia

Como hemos visto los privilegios de instancia se definen

externamente y no pueden ser consultados desde la propia base
de datos.

Para obtener acceso a ellos tenemos que utilizar un comandos

especifico:
db2 get dbm cfg
SYSADM group name (SYSADM_GROUP) =
SYSCTRL group name (SYSCTRL_GROUP) =
SYSMAINT group name (SYSMAINT_GROUP) = DEMO
SYSMON group name (SYSMON_GROUP) =

Para modificar alguno de estos valores utilizaremos:

db2 update dbm cfg using SYSADM_GROUP DEMO
 Privilegios de PUBLIC por defecto

En una instalación por defecto de DB2, el grupo PUBLIC (o sea

cualquier usuario) puede:
Hacer SELECT en el catalogo del sistema.
Crear un nuevo esquema (gracias a la autoridad
IMPLICIT_SCHEMA) y objetos dentro de este.
No puede hacer IMPORT ni LOAD de ficheros.
No puede crear funciones ni procedimientos
almacenados, ya que no cuenta con la autoridad
CREATE_EXTERNAL_ROUTINE (En versiones
anteriores a la 8.1 si, ya que no existe esta autoridad).
No cuenta con acceso a la tabla “sysibm.sysdummy1”.
Privilegios de PUBLIC por defecto
 Puntos a revisar

Privilegios de autoridad a nivel de instancia.

Privilegios de autoridad a nivel de base de datos. (DBAUTH)
Privilegios de acceso a las tablas del sistema.
Privilegios de modificación de tablas.
Privilegios de creación de funciones y procedimientos
almacenados.
Privilegios del grupo “PUBLIC”.
 Hardening de usuarios

Además de las medidas anteriores, si nuestras necesidades de seguridad

son altas, podemos realizar un paso mas y restringir al máximo el acceso
de los usuarios no autorizados.

Para ellos vamos a configurar la base de datos para que impida el acceso
a los usuarios del grupo “PUBLIC”, es decir todos aquellos que no han
sido explícitamente autorizados.
revoke connect,createtab,bindadd,implict_schema on database from public

A partir de ahora, cualquier usuario que quiera acceder a la base de datos

deberá ser autorizado expresamente por el administrador.

Como ultima medida podemos revocar el acceso de los usuarios a las

vistas y tablas del catalogo del sistema. (SYSCAT.*)
 Índice

1. Introducción
2. Cuentas de usuario
3. Roles y privilegios
4. DB2 SQL
5. Vías de acceso
6. Inyección de SQL
7. Registro
8. Sistema operativo
 4. DB2 SQL

El lenguaje SQL a pesar de estar definido como un estándar es

implementado por cada fabricante con una serie de características
particulares.

Estas características van a modificar en gran medida la forma de

atacar la base de datos, especialmente cuando se hace mediante
inyección de SQL.

Estas peculiaridades también van a ser útiles a la hora de hacer

fingerprinting de la base de datos cuando el ataque se realice a
ciegas.
 Características

Permite subSELECT.
No permite subquery (excepto select).
Permite UNION.
No permite mas de una sentencia SQL por línea.
Los mensajes de error no muestran información detallada (en
algunas configuraciones si).
No permite SELECT sin FROM.
Cuenta con Procedimientos Almacenados y con Funciones
definidas por el usuario.
Fin de sentencia con "--".
No permite valor de campo NULL en UNIONes.
Concatenación con “||”.
 Operaciones básicas

Listar las bases de datos:

list database directory

Listar las tablas:

list tables (usuario)
list tables for all (todas)
select tabname from syscat.tables (todas)
select table_name from sysibm.tables (usuario)
select name from sysibm.systables (todas)

Listar las columnas de una tabla:

describe select * from sysibm.sysversions
select colname from syscat.columns where
tabname='SYSVERSIONS'
 Operaciones básicas

Obtener la versión de la base de datos:

select versionnumber from sysibm.sysversions

Obtener una respuesta prefijada:

select 'loquesea' from sysibm.sysdummy1
select 'loquesea' from sysibm.sysversions
 Estructura de la base de datos

Como hemos visto en la sección anterior, DB2 cuenta con una

jerarquía de elementos que componen la base de datos.

Los elementos mas importantes a analizar de cara a la seguridad

son:
Base de datos
Tablas
Funciones y procedimientos almacenados.
 Tablas importantes

sysibm.sysdummy1 -> Tabla dummy (equivalente a la tabla "dual"

de oracle)

sysibm.systables -> Tablas (name)

sysibm.syscolumns -> Columnas (name, tbname)

sysibm.views -> Vistas (table_name, table_schema, table_catalog)

sysibm.usernames -> Usuarios para conexiones Outbound (puede

no existir)

sysibm.sysversions -> Versión

 Conversión de tipos

TIPO DESCRIPCION CONVERSION EJEMPLO

varchar texto - ‘xxxx’

integer numérico - 1

date fecha DATE(CADENA_FECH DATE('2004-10-10')

A)

time hora TIME(CADENA_HORA TIME('10.10.10')

)

timestamp fecha/hora TIMESTAMP(CADENA TIMESTAMP('2004-10-

_FECHA, 10', '10.10.10')
CADENA_HORA)
 Índice

1. Introducción
2. Cuentas de usuario
3. Roles y privilegios
4. DB2 SQL
5. Vías de acceso
6. Inyección de SQL
7. Registro
8. Sistema operativo
 5. Vías de acceso

Las formas en las que un posible atacante puede acceder a la

base de datos son limitadas y necesitamos tenerlas bien
controladas para proteger convenientemente cualquier punto de
entrada en la base de datos.

Entre las posibles vías de acceso tendríamos:

Una shell en el equipo
DB2 wire protocol
ODBC directo
ODBC indirecto
Inyección de SQL
 Shell en el equipo

Si tenemos acceso a una shell en el equipo donde se encuentra

instalada la base de datos DB2 a auditar, acceder a la misma es
automático.

El acceso a la base de datos puede realizarse a través de la

herramienta CLP (Command Line Processor) que suele estar
localizada en:
/home/db2inst1/sqllib/bin/db2 (Unix)
"C:\Archivos de programa\IBM\SQLLIB\BIN\DB2CMD.exe"
DB2SETCP.BAT DB2.EXE (Windows)

La conexión a la base de datos mediante esta herramienta se

realiza sin la necesidad de introducir las credenciales de usuario.
 DB2 wire protocol

También podemos obtener acceso a la base de datos DB2 de

forma remota a través de un equipo que tenga instaladas las
librerías cliente. (Se pueden obtener en la web de IBM)
http://www-306.ibm.com/software/data/db2/runtime.html

La conexión se realiza normalmente a través del puerto

50000/TCP. (Si este se encuentra reservado puede realizarse en
el 50001/TCP y adelante.)

Aquí si es necesario introducir unas credenciales validas. Aunque

como hemos visto valen las de cualquier usuario del equipo.
 ODBC directo

Si disponemos de acceso a un equipo que tenga configurada una

conexión ODBC con la base de datos a auditar, podemos utilizarla
para acceder a la misma.

Si el DSN no se ha configurado con las credenciales necesarias,

tendremos que conocer unas para establecer la conexión. (Aunque
en la mayoría de casos si se encuentran preconfiguradas)
 ODBC indirecto

Si conocemos un equipo con conexión ODBC a nuestra base de

datos y no disponemos de acceso directo al mismo pero podemos
instalar algún tipo de aplicación web en el, es posible crear nuestra
propia pasarela SQL.

VBS/ASP:
<%
Set conn=server.createobject("ADODB.connection")
conn.open "DRIVER=IBM DB2 ODBC DRIVER; DBALIAS=SAMPLE; UID=db2admin; PWD=db2admin"
…

JAVA/JSP:
try {
String dbURL="jdbc:db2://server:50000/books:user=db2admin;password=db2admin";
String dbDriver = "com.ibm.db2.jcc.DB2BaseDataSource";
…
 Inyección de SQL

Si detectamos alguna vulnerabilidad de inyección de SQL en una

aplicación que trabaja contra nuestra base de datos DB2, podemos
utilizarla para obtener acceso parcial a la misma.

El acceso es parcial porque el contexto en el que se trabaja es

mucho mas limitado que los anteriores, ya que partimos de una
sentencia SQL previa que debemos modificar y que nos impedirá
realizar algunas acciones.
 Puntos a revisar

Restringir en el servidor el acceso de los usuarios no privilegiados

a las herramientas y librerías DB2.
Proteger mediante algún tipo de filtrado los puertos TCP utilizados
para conexiones remotas en DB2.
Revisar el almacenamiento de las credenciales de acceso
mediante ODBC.
Impedir que se instale código externo en los servidores conectados
mediante ODBC a la base de datos.
Auditar el código de las aplicaciones que utilizan la base de datos
mediante SQL.
 Índice

1. Introducción
2. Cuentas de usuario
3. Roles y privilegios
4. DB2 SQL
5. Vías de acceso
6. Inyección de SQL
7. Registro
8. Sistema operativo
 6. Inyección de SQL

DB2 no es una base de datos fácil de atacar a través de inyección

de SQL.

Como hemos visto en el apartado “características” del SQL de

DB2, contamos con una serie de limitaciones importantes:
No se permiten subquerys ni mas de una query por sentencia.
No es posible extraer información de la base de datos a través de los
mensajes de error.
El juego de funciones que podemos llamar desde un SELECT es muy
pequeño por defecto, y no se conocen vulnerabilidades en ellas.
Se permite utilizar UNION, pero no se permite utilizar el valor de
campo “NULL” en las UNIONes, de forma que se complica el
encontrar el tipo de campos validos.
 Inyección de SQL

Después de tantas limitaciones, el mejor ataque que nos queda

por lo tanto es el intentar extraer información de la base de datos
mediante la creación de una sentencia UNION valida.

Si tampoco es posible obtener un UNION valido, solo nos queda

extraer algo de información mediante un ataque a ciegas.

Para hacer esto podemos usar la función “substr”, por ejemplo:

AND substr((select USER from sysibm.sysversions),1,1)=chr(68)
 Fingerprinting

El primer paso para explotar una inyección de SQL, una vez

comprobada que la aplicación es realmente vulnerable, será
averiguar el tipo y si es posible, la versión de la base de datos.

Si el error no es ciego, y vemos los mensajes de error que genera

la base de datos, será fácil averiguar el tipo de la base de datos.

Si el error es ciego, deberemos someter la inyección a una serie

de sencillas pruebas lógicas. Por ejemplo:
value(1,1)=1
USER=USER
length(1)=4
Mensajes de error DB2
 Errores descriptivos

Como he comentado, normalmente los mensajes de DB2 apenas

muestran información útil sobre el error producido y no permiten extraer
información de la base de datos.

Sin embargo en algunas configuraciones, los mensajes son mas

explícitos y nos facilitan lograr una inyección útil.

Para lograr una UNION valida en estos casos:

1. Hacemos UNION con 1 campo.
2. Si nos muestra un error de "SQL0415: Operandos UNION no compatibles"
es que el tipo del campo no es correcto.
3. Probamos otro tipo de datos en el campo.
4. Si da un error de "SQL0421: Numero de operandos UNION no igual" es que
el tipo esta bien, y tenemos que añadir otro elemento a la unión.
5. Repetimos la operación hasta que demos con todas las columnas necesarias
para hacer el UNION y los tipos de datos de cada una de ellas coincidan.
 Inyección ciega

En el caso de que los mensajes de error no sean descriptivos o

que la inyección sea ciega (no vemos ningún tipo de mensaje)
debemos proceder a un ataque por fuerza bruta.

Tenemos que probar todas las combinaciones posibles de tipo de

datos y de numero de campos hasta lograr una UNION correcta.

Para simplificar usaremos 2 valores:

1 para campos de tipo numérico.
'2005-01-28-16.09.04.00‘ para campos de tipo cadena y de tipo fecha.
 Puntos a mirar

Revisar el código de las aplicaciones que realicen peticiones SQL

contra la base de datos para evitar que se produzcan puntos de
inyección.

En aplicaciones que se utilicen desde entornos de riesgo

expuestos a Internet, limitar al máximo los privilegios del usuario
utilizado para acceder a la base de datos.

Hacer que la aplicación en producción no muestre al usuario los

posibles errores generados por la base de datos.
 Índice

1. Introducción
2. Cuentas de usuario
3. Roles y privilegios
4. DB2 SQL
5. Vías de acceso
6. Inyección de SQL
7. Registro
8. Sistema operativo
 7. Registro

Dentro del directorio base de la instancia DB2 se encuentran una

serie de ficheros de log que es necesario revisar para detectar
posibles usos irregulares de la base de datos.

Los ficheros mas destacables son:

db2diag.log: Contiene todos los mensajes de error y de warning.
jdbcerr.log: Errores en conexiones JDBC.
instance_name.nfy: Notificaciones de administración. (Solo Unix, en
Windows estos mensajes de manejan por el event log del sistema)
 Logs

La localización de estos ficheros viene determinada por el

parámetro de configuración DIAGPATH, aunque por defecto en
suele ser:
/opt/db2/db2inst1/sqllib/db2dump/* (Unix)
C:\Archivos de programa\IBM\SQLLIB\DB2\* (Windows)

El nivel de registro viene determinado por los parámetros de

configuración DIAGLEVEL y NOTIFYLEVEL, que toman valores
entre 0 y 4. Siendo normalmente 3 el valor por defecto.

Es recomendable elevarlos a 4 de la siguiente forma:

db2 update dbm cfg using DIAGLEVEL 4
 Puntos a revisar

Comprobar que el nivel de registro (DIAGLEVEL y NOTIFYLEVEL)

es suficiente (>=3).

Comprobar que los ficheros de registro no han sido borrados o

alterados.

Comprobar en los registros que no existen eventos “anomalos” que

puedan indicar una actividad ilegal en el sistema.
 Índice

1. Introducción
2. Cuentas de usuario
3. Roles y privilegios
4. DB2 SQL
5. Vías de acceso
6. Inyección de SQL
7. Registro
8. Sistema operativo
 8. Acceso al Sistema operativo

Una vez hemos comprobado la seguridad de los datos

almacenados en la base de datos, podemos comprobar si es
posible atacar otros sistemas a partir de este.

La configuración por defecto de DB2, impide a los usuarios con

pocos privilegios el acceso a funciones del sistema operativo, pero
si conseguimos acceso a una cuenta con autoridad suficiente o los
privilegios de acceso se encuentran mal configurados, podemos
intentar atacar el sistema operativo.
 Ejecución de comandos

DB2 permite mapear llamadas a librerías del sistema en una

función o en un procedimiento almacenado. De esta forma
podemos realizar cualquier operación que nos permitan las
librerías estándar. Por ejemplo ejecutar comandos a través de la
llamada system():
create function cmdfunc(varchar(200)) returns integer language C
parameter style sql external name 'msvcrt.dll!system'
select cmdfunc('dir > c:\test.txt') from sysibm.sysdummy1

En Unix:
create function linfunc(varchar(200)) returns integer language C
parameter style sql external name '/lib/libc.so.6!system'
select linfunc('ls > /tmp/(test.txt') from sysibm.sysdummy1
 Cambio de contraseña

Aunque hemos comentado que no se podía modificar la

configuración de los usuarios desde la base de datos, si existe una
operación que podemos realizar. Es posible cambiar la contraseña
de un usuario del que conocemos sus credenciales a través del
comando “connect” de la base de datos:
connect to <database> user <uid> using <password> new
<newpassword> confirm <again newpw>
 Lectura de ficheros

Por ultimo tenemos la función “import” que nos permite leer

ficheros del sistema.
create table mytable (data varchar(100));
import from 'c:\boot.ini' of del insert into mytable;
select * from mytable;

Aunque no puede ser invocada desde ODBC y requiere privilegios

altos.
 Puntos a revisar

Quitarle la autoridad CREATE_EXTERNAL_ROUTINE a todos los

usuarios. Si es necesario crear alguna función o procedimiento se
utilizara un usuario DBADM.

Quitarle la autoridad CONNECT a aquellos usuarios que no

queremos que modifiquen su contraseña. (Ojo con esto porque
tampoco podrán conectar a la base de datos)

Quitarle la autoridad LOAD a todos los usuarios.

 Conclusiones

A pesar de no ser un sistema de base de datos demasiado popular

y no haber sufrido análisis de vulnerabilidades tan intensivos como
otras bases de datos, DB2 da una buena impresión en cuanto a
seguridad y robustez.

Como se ha podido ver, auditar y securizar esta base de datos no

es tan difícil como parecía inicialmente.

Espero que no os hayáis aburrido mucho y que estos

conocimientos os sean útiles en el futuro… ☺