miércoles, 13 de julio de 2011

Contraseñas o Password de usuarios, seguros en 11gR2 ?

En Oracle, tenemos una gama importante de productos, que permiten de manera eficiente y efectiva, brindar un nivel de seguridad de alto nivel, acorde con las necesidades y estándares internacionales, solicitados por entidades regulatorias.

Dentro de la base de datos, podemos realizar una gran cantidad de acciones, que nos permite de alguna forma, sentirnos seguros cada noche a la hora de irnos a descansar.

Sin embargo, como en ennumeradas ocasiones lo he dicho en mis charlas de productos de seguridad de Oracle, debemos tener en claro, que el DBA, siempre ha sido tratado como un dios y no debe porque ser un dios, en el tema de la base de datos.

Con Oracle Database Vault, un producto, licenciable sólamente en la versión Enterprise Edition de la base de datos Oracle, podemos hacer una separación de roles, de tal manera, que el DBA, no realice funciones, que no son de su competencia.

Qué debe estar haciendo un DBA a media noche del día sábado ( día no laboral ), pegado a la base de datos de producción, consultando la tabla de salarios del esquema de planillas.?

Oracle Database Vault, entre muchas otras cosas, puede filtrar e impedir este tipo de acciones, aún, cuando el usuario sea SYS o SYSTEM.

Pero para los simples mortales que cuentan con la versión One Edition o Standard Edition, que podemos hacer.?

Como hago yo, para impedir, el fraude más común, que un DBA puede hacer en una base de datos, como lo es el "ROBO DE IDENTIDAD".?

Es posible, realizar esta acción en una base de datos Oracle 11gR2, a pesar, que en la nueva versión en la tabla del diccionario de la base de datos DBA_USERS, en la columna de "Password", esta encriptada y no se pueden ver, aún codificados, los valores almacenados, aunque sea SYS o SYSTEM, los que estan consultando la tabla.?

La respuesta es: SI, si se puede hacer "Robo de Identidad" en una base de datos 11gR2, contando con los permisos adecuados en una cuenta común de usuario, o por parte de la persona que maneja las cuentas con privilegios SYSDBA, como SYS o SYSTEM.

Veamos como:
Vamos a crear un usuario en nuestra base de datos.
SQL> create user demo2 identified by demo2;
User created.

Le vamos a dar privilegios de poderse logear y crear una sesión de trabajo en la base de datos.

SQL> grant create session to demo2;
Grant succeeded.

Ahora veamos el contenido de la tabla DBA_USERS y que es lo que guarda en la columna de "PASSWORD".

SQL> desc dba_users
Name                           Null?    Type
------------------------------ -------- --------------
USERNAME                       NOT NULL VARCHAR2(30)
USER_ID                        NOT NULL NUMBER
PASSWORD                                VARCHAR2(30)
ACCOUNT_STATUS                 NOT NULL VARCHAR2(32)
LOCK_DATE                               DATE
EXPIRY_DATE                             DATE
DEFAULT_TABLESPACE             NOT NULL VARCHAR2(30)
TEMPORARY_TABLESPACE           NOT NULL VARCHAR2(30)
CREATED                        NOT NULL DATE
PROFILE                        NOT NULL VARCHAR2(30)
INITIAL_RSRC_CONSUMER_GROUP             VARCHAR2(30)
EXTERNAL_NAME                           VARCHAR2(4000)
PASSWORD_VERSIONS                       VARCHAR2(8)
EDITIONS_ENABLED                        VARCHAR2(1)
AUTHENTICATION_TYPE                     VARCHAR2(8)


SQL> select username, account_status, password_versions, password from dba_users
  2  where username='DEMO2';

USERNAME              ACCOUNT_STATUS     PASSWORD
--------------------- ------------------ --------
PASSWORD
-------------
DEMO2                          OPEN      10G 11G


SQL> column username format a10;
SQL> column account_status format a10;
SQL> /

USERNAME   ACCOUNT_ST PASSWORD PASSWORD
---------- ---------- -------- ----------
DEMO2      OPEN       10G 11G


Como pueden observar, la columna de "Password", se muestra en blanco, evitando que aquellas personas que tengan acceso a la tabla del diccionario de la base de datos, puedan conocer, en formato encriptado, el valor guardado para el usuario respectivo, como palabra clave.

SQL> select * from v$version;
BANNER
-------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE    11.2.0.1.0      Production
TNS for 32-bit Windows: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production


Sin embargo, veamos, como conectado con el usuario SYS a la base de datos, tengo acceso a la vista USER$, en la cuál, también se encuentra la columna "Password".

SQL> show user
USER is "SYS"
SQL> desc sys.user$
 Name           Null?    Type
 -------------- -------- --------------
 USER#          NOT NULL NUMBER
 NAME           NOT NULL VARCHAR2(30)
 TYPE#          NOT NULL NUMBER
 PASSWORD                VARCHAR2(30)
 DATATS#        NOT NULL NUMBER
 TEMPTS#        NOT NULL NUMBER
 CTIME          NOT NULL DATE
 PTIME                   DATE
 EXPTIME                 DATE
 LTIME                   DATE
 RESOURCE$      NOT NULL NUMBER
 AUDIT$                  VARCHAR2(38)
 DEFROLE        NOT NULL NUMBER
 DEFGRP#                 NUMBER
 DEFGRP_SEQ#             NUMBER
 ASTATUS        NOT NULL NUMBER
 LCOUNT         NOT NULL NUMBER
 DEFSCHCLASS             VARCHAR2(30)
 EXT_USERNAME            VARCHAR2(4000)
 SPARE1                  NUMBER
 SPARE2                  NUMBER
 SPARE3                  NUMBER
 SPARE4                  VARCHAR2(1000)
 SPARE5                  VARCHAR2(1000)
 SPARE6                  DATE


A la hora de realizar la consulta a la vista, ahora si tengo acceso al código almacenado y encriptado del usuario, en la base de datos, correspondiente al usuario respectivo.

SQL> select name, password from sys.user$ where name='DEMO2';
NAME         PASSWORD
------------ -----------------
DEMO2        1175C8499AEA4DEC


Conociendo este dato, ahora el asunto es meramente, un juego de niños.  Yo podría cambiar el password al usuario "demo2", logearme en la base de datos a través de SQL o el aplicativo, teniendo así, acceso al grupo de privilegios asignados por aplicación; correr un proceso "X" y luego, simplemente, volver a cambiar la clave, al valor original, sin que el usuario dueño de la cuenta, se entere, de que su cuenta y seguridad, ha sido "HACKEADA".

SQL> alter user demo2 identified by oracle;
User altered.
SQL> connect demo2/oracle
Connected.
SQL> alter user demo2 identified by values '1175C8499AEA4DEC';

User altered.
SQL> connect demo2/demo2;
Connected.
SQL>

Recuerde que estadísticamente hablando, la mayor cantidad de ataques a los sistemas, se originan dentro de la organización y no fuera de ella.

Conozca al personal que tiene a su cargo y determine, cuál es el papel protagonista que puede jugar en el engranaje de la seguridad de su información y establezca mecanismos, que le permita mitigar, una acción indebida.

La clave de los usuarios SYS y SYSTEM, deben estar en manos de un grupo mínimo de personas. Si al menos confía en su DBA, no permita que personas ajenas a él, conozcan las claves de tan potenciales usuarios dentro de la base de datos.

Busque como asegurar sus sistemas ahora y no espere, a que la edad de retiro le alcance, para empezar a hacer algo.

La seguridad no es un juego de niños; tampoco lo es la información de su organización. Si usted se empeña en asegurar algo, habrán 10 o más, pensando y analizando, en como romper ese cerco.

Algunos cuentan con mucha suerte y nunca sufren ningún tipo de problema, otros sin embargo, no son tan suertudos en el tema. Sino que lo digan CITI y SONY, en los últimos días.

Todos los Sábados a las 8:00PM

Optimismo para una vida Mejor

Optimismo para una vida Mejor
Noticias buenas que comentar