"Calma, calma, que no panda el cúnico", "Chanfle, chanfle" "Todos mis movimientos están fríamente calculados" .Si amigos, en ocasiones, parece que ni el "Chapulín Colorado", nos puede salvar de una situación, sin embargo, en esta, al parecer, ni será necesario invocarlo, para que venga en nuestra ayuda.
En relación a la publicación de nuestro compañero Enrique Obergozo, del " domingo 7 de febrero de 2010, Peligro inminente, ¡Dios nos coja confesados! , hay que hacer algunas pequeñas observaciones.
Primero que todo, hay una serie de aspectos que se deben tomar en cuenta. En seguridad, los problemas se dividen en "Exposiciones" y "Vulnerabilidades". Cuando aparece algún problema, como el que Enrique nos cuenta, estamos hablando de una "exposición", ya que existe algún procedimiento o método para evitar que la situación sea explotada, por un atacante. En este caso, existen dos paquetes que pueden ser utilizados para causar algún tipo de problema en relación con la disponibilidad de servicios ( DoS ) de la base de datos o bien como lo comentó Enrique, incluso llegar a borrar archivos físicos relacionados con el motor de la base de datos tales como datafiles, controlfiles, redologs, etc,los paquetes son
Aquí lo importante es lo siguiente, cuando hablamos de seguridad informática, hablamos de varios niveles y anillos periféricos de rangos de riesgo.
Por lo general, todo el equipo altamente sensible, para las actividades del negocio o de la organización, se encuentra en un centro de cómputo o DataCenter especializado. Si es un centro de cómputo, la puerta de ingreso al departamento, representa el primer nivel periférico de seguridad. Ninguna persona, que no tenga que ver con el departamento de cómputo, debe estar dentro él, al menos, que haya sido previamente autorizado. Este es el anillo de color naranja. Fuera del departamento de cómputo el anillo es de color verde. El segundo nivel, corresponde al área de servidores, esta área es de color rojo. Aquí debe existir una puerta con cerradura, en un ambiente adaptado, a las necesidades del hardware existente en el lugar. Sólo algunas pocas personas, deben tener acceso a este sitio. El color rojo indica, que cualquier acción que se desarrolle en este sector, puede causar daños severos a la infraestructura de TI.
Cuando ingresamos al lugar de los servidores, nos topamos con el siguiente nivel de seguridad, el cuál corresponde a los accesos de usuarios al sistema. Ahora bien, si fueramos alguién que quisiera hacer un daño, para que nos preocuparíamos de conocer la clave del superusuario o el administrador del software de Oracle.? Bastaría, con desconectar los cables de AC, para apagar el equipo, levantarlo en el aire y tirarlo contra el suelo, ó simplemente, encendiar el lugar.
Los problemas de seguridad a los que se hacen referencia en el documento de Enrique, para poder ser explotadas, el usuario debe tener acceso a nivel de sistema operativo a la herramienta SQL*Plus en el servidor, ya que el ejecutar un comando, requiere de privilegios administrativos, a los cuáles no puedes accesar, sino estas logeado localmente, ya sea en la consola del servidor o a través de un utilitario o emulador de ambiente gráfico de Windows ó Linux, o un utilitario de acceso de terminal remota.
El utilitario SQL*Plus de tu máquina remota, no puede accesar los binarios del servidor remoto, por tanto, no puedes reproducir, la exposición.
Si hay que hacer una excepción a la regla, con la herramienta iSQL*Plus. Esta herramienta, que se instala con el software de RDBMS y que debe ser levantada en el servidor para poder se accesada, permite ingresar en una consola web, en el servidor de base de datos o sea localmente, a la instancia de base de datos. Desde aquí, si se podría atacar a la base de datos.
El sitio THE H SECURITY, le da el rango de bajo nivel de riesgo, por la gran cantidad de factores, que deberían descuidarse, para poder hacer uso de esta exposición. Un usuario no deseado, con login en el servidor a nivel de sistema operativo, login en la base de datos y con acceso físico o remoto al equipo y con preparación académica en el tema.
Estaríamos hablando de muchas fallas de seguridad o de un servidor, que no es de nivel crítico.
Así que como les dije al principio, "que no panda el cúnico", no hay mucho de que alarmarnos. Y para terminar, que la "Fuerza los acompañe".
DBMS_JVM_EXP_PERMS y DBMS_JAVA.SET_OUTPUT_TO_JAVA.
Existe en el sitio de THE H SECURITY, una descripción amplia de esta exposición con la base de datos y de otras más, que incluye unos ppts y hasta un video realizado por el analista de riesgos David Litchfield.Aquí lo importante es lo siguiente, cuando hablamos de seguridad informática, hablamos de varios niveles y anillos periféricos de rangos de riesgo.
Por lo general, todo el equipo altamente sensible, para las actividades del negocio o de la organización, se encuentra en un centro de cómputo o DataCenter especializado. Si es un centro de cómputo, la puerta de ingreso al departamento, representa el primer nivel periférico de seguridad. Ninguna persona, que no tenga que ver con el departamento de cómputo, debe estar dentro él, al menos, que haya sido previamente autorizado. Este es el anillo de color naranja. Fuera del departamento de cómputo el anillo es de color verde. El segundo nivel, corresponde al área de servidores, esta área es de color rojo. Aquí debe existir una puerta con cerradura, en un ambiente adaptado, a las necesidades del hardware existente en el lugar. Sólo algunas pocas personas, deben tener acceso a este sitio. El color rojo indica, que cualquier acción que se desarrolle en este sector, puede causar daños severos a la infraestructura de TI.
Cuando ingresamos al lugar de los servidores, nos topamos con el siguiente nivel de seguridad, el cuál corresponde a los accesos de usuarios al sistema. Ahora bien, si fueramos alguién que quisiera hacer un daño, para que nos preocuparíamos de conocer la clave del superusuario o el administrador del software de Oracle.? Bastaría, con desconectar los cables de AC, para apagar el equipo, levantarlo en el aire y tirarlo contra el suelo, ó simplemente, encendiar el lugar.
Los problemas de seguridad a los que se hacen referencia en el documento de Enrique, para poder ser explotadas, el usuario debe tener acceso a nivel de sistema operativo a la herramienta SQL*Plus en el servidor, ya que el ejecutar un comando, requiere de privilegios administrativos, a los cuáles no puedes accesar, sino estas logeado localmente, ya sea en la consola del servidor o a través de un utilitario o emulador de ambiente gráfico de Windows ó Linux, o un utilitario de acceso de terminal remota.
El utilitario SQL*Plus de tu máquina remota, no puede accesar los binarios del servidor remoto, por tanto, no puedes reproducir, la exposición.
Si hay que hacer una excepción a la regla, con la herramienta iSQL*Plus. Esta herramienta, que se instala con el software de RDBMS y que debe ser levantada en el servidor para poder se accesada, permite ingresar en una consola web, en el servidor de base de datos o sea localmente, a la instancia de base de datos. Desde aquí, si se podría atacar a la base de datos.
El sitio THE H SECURITY, le da el rango de bajo nivel de riesgo, por la gran cantidad de factores, que deberían descuidarse, para poder hacer uso de esta exposición. Un usuario no deseado, con login en el servidor a nivel de sistema operativo, login en la base de datos y con acceso físico o remoto al equipo y con preparación académica en el tema.
Estaríamos hablando de muchas fallas de seguridad o de un servidor, que no es de nivel crítico.
Así que como les dije al principio, "que no panda el cúnico", no hay mucho de que alarmarnos. Y para terminar, que la "Fuerza los acompañe".
Hola Ronald, sobre el tema, debo hacer la precision de que no es necesario estar conectado al servidor de base de datos para explotar esta vulnerabilidad, basta con que tengas como conectarte, ya sea sql*plus, sqldeveloper, toad, un programa en Java, cualquier medio, y una cuenta con privilegio de create session como mínimo, eso es todo, yo lo he probado y puedo dar fe:
ResponderEliminarDesde el server linux:
[oracle@serverXXX ~]$ ls -lt
total 12
-rw-r--r-- 1 oracle oinstall 45 Feb 9 09:26 afiedt.buf
drwxr-xr-x 4 oracle oinstall 4096 Jan 12 10:13 scripts
drwxr----- 3 oracle oinstall 4096 Dec 30 09:58 oradiag_oracle
Desde un sql*plus en Windows Vista:
TEST@bdXXX > select dbms_java.runjava('oracle/aurora/util/Wrapper /bin/mv /ho
me/oracle/afiedt.buf /home/oracle/afiedt.BUF') from dual;
DBMS_JAVA.RUNJAVA('ORACLE/AURORA/UTIL/WRAPP
-------------------------------------------
Nuevamente en el server Linux:
[oracle@serverXXX ~]$ ls -lt
total 12
-rw-r--r-- 1 oracle oinstall 45 Feb 9 09:26 afiedt.BUF
drwxr-xr-x 4 oracle oinstall 4096 Jan 12 10:13 scripts
drwxr----- 3 oracle oinstall 4096 Dec 30 09:58 oradiag_oracle
Con esta consideracion, realmente cualquier instalacion esta abierta a la explotacion de esta vulnerabilidad, al menos de mi experiencia hay muchas instalaciones donde sencillamente se instala todo por defecto y nunca se instala patch alguno, ni siquiera los CPU, asi que es probable que esten expuestos por mucho tiempo, hasta que alguien los ataque.
Saludos desde Lima!
Si, Enrique tiene razon
ResponderEliminardesde una aplicacion java puedo ejecutar dichos comandos del Sistema operativo si ningun problema
mucho mas, usando una herramienta como sqldeveloper.
Y tambien lo digo con conocimiento de causa.
;)