StreamIO
Última actualización
¿Te fue útil?
Última actualización
¿Te fue útil?
StreamIO es una máquina mediana que cubre la enumeración de subdominios que conduce a una inyección SQL para recuperar las credenciales de usuario almacenadas, que se descifran para obtener acceso a un panel de administración. El panel de administración es vulnerable a LFI, lo que nos permite recuperar el código fuente de las páginas de administración y conduce a la identificación de una vulnerabilidad de inclusión de archivos remotos, cuyo abuso nos permite obtener acceso al sistema.
Después del shell inicial, aprovechamos la utilidad de línea de comandos SQLCMD para enumerar las bases de datos y obtener más credenciales utilizadas en el movimiento lateral. Como usuario secundario, usamos WinPEAS para enumerar el sistema y encontrar bases de datos guardadas del navegador, que se decodifican para exponer nuevas credenciales. Usando las nuevas credenciales dentro de BloodHound, descubrimos que el usuario tiene la capacidad de agregarse a un grupo específico en el que puede leer secretos LDAP. Sin acceso directo a la cuenta, usamos PowerShell para abusar de esta función y agregarnos al grupo Core Staff, luego accedemos a LDAP para revelar la contraseña LAPS del administrador.
Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina StreamIO.
Lanzaremos una serie de scripts básicos para intentar buscar vulnerabilidades en los puertos que hemos encotrado expuestos.
Comprobaremos el nombre del dominio con el cual nos enfrentamos a través del siguiente comando.
Comprobaremos a qué tipo de máquina nos enfrentamos a través de netexec.
Procederemos a añadir la entrada en nuestro archivo /etc/hosts
Enumerando los puertos expuestos de los sitios webs, nos encontramos con que el puerto 80 corresponde a un IIS de Windows Server, sin contenido ninguno.
Con la herramienta de wfuzz procederemos a listar posibles páginas PHP que disponga elo sitio web, encontramos las siguientes páginas.
Enumerando posibles directorios encontramos uno que nos llama la atención, "Admin". Pero aparece que la respuesta es un 403 Forbidden, por lo cual podemos pensar que es un directorio que se encuentra pero necesitas un acceso previo, login, etc.
Probararemos de enumerar a posibles usuarios del dominio a través de Kerbrute y un diccionario especializado en nombres, sin exito.
También probamos con el listado de los nombres que aparecían en el sitio web, sin exito tampoco.
En el sitio web aparentemente no vemos ningún tipo de directorio ni contenido, enumerando nuevamente con wfuzz, pudimos enumerar las siguientes paginas PHP.
Probamos de buscar por "test" y nos aparecía un resultdo que contenía dicho contenido de la palabra, lo que nos hizo pensar que por detrás en la BBDD se aplicaba la siguiente QUERY: SELECT movie FROM movies WHERE movie_name LIKE "%test%"
Probamos de realizar inyecciones SQL para intentar con ORDER BY o NULL listar el total de columnas que disponía la BBD, pero aparecía un mensaje de un supuesto WAF bloqueando la sesión debido que había detectado actividad maliciosa por la QUERY lanzada.
Debido que con ORDER BY no podíamos saber el total de columnas, probamos con UNION SELECT. En este caso si obtuvimos el resultado del total de columnas que eran 6.
Versión de MSSQL.
Enumerar la BBDD que se está utilizando actualmente.
Listar todas las BBDDs que dispone.
Intentando listar las tablas de la BBDD "streamio_backups", sin resultado ninguno, parece que no tenemos acceso.
Revisando las tablas de la BBDD nombrada "STREAMIO". Nos encontramos con una tabla "users".
A través de la siguiente SQLI, obtuvimos el ID de la tabla, ya que lo necesitaremos para seguir dumpeando su información.
Enumerando las columnas de la tabla "users" de la BBDD "STREAMIO".
Extrayendo la información de las columnas "username" y "password" de la tabla "users". Nos encontramos con nombres de usuarios y sus contraseñas hasheadas.
Nos copiaremos los datos de los usuarios y sus hashes. Lo modificaremos para que aparezca el output más limpio
Eliminaremos los espacios que sobren, y guardaremos el contenido en "hashes".
Pasaremos un hash de ellos a la herramienta de hash-identifier para identificar que tipo de hash es.
La herramienta nos ha indicado que el hash es MD5. Por lo tanto, con John procederemos a intentar crackear las contraseñas especificando el formato MD5.
Separaremos en dos archivos diferentes, en uno guardaremos los nombres de usuarios y en el otro las contraseñas crackeadas.
A través de la herramienta de netexec procederemos a probar las credenciales de los usuarios correspondientes, nos damos cuenta que ninguno es válido (al menos a nivel de cuenta de dominio).
Del archivo original "hashes", primero de todo nos quedaremos con los nombres de usuarios totales (crackeados y no crackeados) y a través de awk filtraremos y enviaremos la data al archivo "usernames.txt".
A través de Kerbrute procederemos a enumerar todo el listado de usuarios que disponemos, para saber si alguno es válido a nivel cuenta de usuario del dominio, y encontramos que el usuario "yoshidi" es válido.
Recordando que enumerando páginas PHP del sitio web al principio en la fase de enumeración había una página llamada "login.php" probaremos de intentar realizar un ataque de fuerza bruta con la herramienta de Hydra para probar si algunas credenciales son válidas o no.
Para ello del archivo "hashes" original nos lo guardaremos el contenido en "valid_credentials.txt".
A través de la herramienta de hydra haremos un ataque mediante fuerza bruta contra el panel de inicio de sesión de la página, le indicaremos el archivo donde disponemos el usuario y contraseña, el sitio web y donde se tramitará la data.
Además, deberemos especificar el username, password y el mensaje de error cuando se intenta iniciar sesión un usuario/contraseña incorrectos.
Comprobamos que las credenciales para el usuario "yoshide" son válidas.
Con la herramienta de Cookie-Editor nos copiaremos la cookie de sesión que disponemos para ejecutar la siguiente enumeración.
Debido que en el sitio web que nos encontramos, hay una variable llamada "staff", probaremos de enumerar si existe algúna variable más para ver si podemos acceder a esa página web.
Finalmente con wfuzz nos reporta que hay una variable nombrada "debug" que investigaremos de qué trata.
Debido que nos estamos enfrentando a una máquina Windows, probaremos de ver si somos capaces de listar el contenido de "/etc/hosts" de Windows.
Comprobaremos que hemos sido capaces de realizar el LFI con éxito.
En este punto, lo que realizaremos es una combinación entre LFI y la utilización de wrappers.
Un LFI con wrappers Base64 permite leer archivos en Base64 en lugar de texto plano. Con php://filter/convert.base64-encode/resource=index.php, accedemos a index.php y obtenemos su contenido codificado, evitando su ejecución directa. Esto es útil para leer código sensible, ya que un LFI normal podría no mostrar el contenido del archivo PHP.
En nuestra Kali, procederemos a descodificar el contenido del archivo "index.php" encodeado en base64 para que lo muestre de manera normal.
Revisando el archivo "index.php" nos encontrasmos con un usuario y una contraseña de la BBDD "STREAMIO". Nos guardaremos estas credenciales, por si más adelante las necesitamos.
Probaremos de enumerar páginas PHP dentro del directorio "admin" con wfuzz. Nos encontramos que hay una página llamada "master.php"
Probaremos de obtener el contenido de "master.php" utilizando LFI + Wrapper para que nos lo muestre encodeado en Base64.
Descodificaremos el contenido de "master.php" encodeado en Base64 para que nos lo muestre en texto plano.
Revisando el contenido de "master.php", nos damos cuenta que hay un código PHP.
Este código recibe un archivo por POST. Si el archivo no es index.php, entonces lee su contenido y lo ejecuta. Si intentamos usar index.php, solo muestra un error. Esto permite que, con el archivo adecuado, se pueda ejecutar cualquier código en el servidor, lo cual es peligroso porque permite que cualquiera suba y ejecute código malicioso.
Para comprobar si podemos realizar un RFI (Remote File Inclusion), nos levantaremos un servidor web con python3.
Capturaremos la solicitud que se tramita por POST con BurpSuite y en el "include" que es lo que se espera recibir el código PHP, pondremos nuestro servidor web que estamos alojando.
Volviendo a la consola donde hemos levantado el servidor web, comprobamos que se ha recibido una solicitud, por lo tanto, el servidor parece que es vulnerable al RFI.
Procederemos a realizar un RFI (Remote File Inclusion) combinado con un RCE (Remote Code Execution) para ejecutar código e intentar ganarnos una Reverse Shell.
Para ello lo primero que haremos es crear un archivo llamado "rce.php" que lo que hará es ejecutar a través de la función system el comando ipconfig para ver si en la solicitud vemos si es ejecutado también el RCE y logramos poder ejecutar comandos en el servidor.
Levantaremos de nuevo un servidor web con python.
Des de BurpSuite procederemos a realizar el RFI para que el servidor incluya el contenido de "rce.php", al enviar la solicitud, comprobamos en la respuesta de que se ha ejecutado correctamente el comando "ipconfig".
Por lo tanto, comprobamos que tenemos una vía potencial de realizar un RCE para ejecutar comandos en el servidor.
Confirmada la ejecución de comandos. Procederemos a intentar ver si podemos lograr establecernos una Reverse Shell a nuestra Kali.
Para ello, primero nos copiaremos el binario de "nc.exe" en nuestro directorio actual de trabajo.
Modificaremos el contenido de "rce.php" y estableceremos que a través de la utilidad de certutil.exe nos descargue el archivo "nc.exe" que tendremos nosotros alojados en nuestro servidor web y lo almacene en un directorio que no tengamos problemas de ejecución.
Volveremos a enviar la solicitud para que el RFI actúe y se incluya en el directorio especifiado el binario de nc.exe
A continuación, como ya disponemos de la herramienta de "nc.exe" en la máquina del servidor, lo que realizaremos es modificar el contenido de "rce.php" y indicarle que ejecute una Reverse Shell a nuestra Kali por el puerto 443 que es donde estarmeos escuchando con nc.
Volveremos a tramitar de nuevo otra solicitud con BurpSuite
Comprobaremos que hemos ganado acceso al equipo a través de un RFI + RCE.
Nos encontramos enla máquina de streamio.htb y no disponemos de ningún privilegio especial.
Probaremos a ver si podmeos acceder al servicio de MSSQL a través de consola a través de sqlcmd. Comprobamos que si se encuentra instalado.
Recr
Recordando que disponemos supuestamente la contraseña del usuario "Administrador" para acceder a la MSSQL, esta información la habíamos encontrado en el archivo "index.php".
Probamos de revisar el contenido de la tabla "users" de la BBDD "streamio_backup" que al principio con SQLI no pudimos obtener los datos, y encontrasmos que hay hashes y usuarios, comparamos con la tabla "users" de la BBDD "streamio" y hay un usuario llamado "nikk37" en esta de "streamio_backup" que antes no disponíamos.
Añadiremos este nuevo hash en el archivo "hashes" que disponemos.
Procederemos a intentar crackear el hash con John. Finalmente obtenemos la contraseña correcta para ese hash.
Nos guardaremos estas nuevas credenciales en el archivo "valid_credentials.txt"
Debido que tenemos acceso a la terminal de la máquina de STREAMIO, comprobaremos si este usuario es válido a nivel de dominio y de si forma parte del grupo "Remote Managment Users" para así intentar conectarnos al WinRM a través de evil-winrm
Probaremos de acceder con las nuevas credenciales encontradas, y comprobamos la flag de user.txt
A continuación, explicaremos lo que hemos realizado para escalar privilegios.
Primero de todo, procedimos a importar el binario de winPEAS para realizar una enumeración y ver posibles vectores para realizar un PrivEsc.
Comprobamos que ha encontrado lo ha encontrado posibles contraseñas almacenadas de perfiles de Firefox.
Procederemos a acceder a esa ruta y descargarnos los archivoss "key4.db" y "logins.json" que son necesarios para obtener las contraseñas en texto claro.
A través de la herramienta de firepwd.py dumpearemos las contraseñas de perfiles de usuarios que se han almacenado en Firefox.
Copiaremos el contenido y procederemos afiltrar para que el output sea más limpio. Nos guardaremos a los usuarios en "users.txt" y sus contraseñas en "passwords.txt".
Con netexec procederemos a realizar una comprobación de los usuarios y contraseñas para que se intenten autenticar al SMB y comprobar si alguna credencial es válida o no.
Comprobaremos que hemos añadido las nuevas credenciales obtenidas en "credentials.txt".
Como tenemos acceso al WinRM des de otro usuario, comprobaremos si este usuario forma parte del grupo de "Remote Management Users" para así lograr conectarnos con dicho usario, comprobamos que no es miembro del grupo, por lo tanto no podemos conectarnos con ese usuario al WinRM.
Debido que disponemos de unas credenciales que son válidas a nivel de dominio (nikk37), procederemos a realiar una enumeración con BloodHound para buscar vectores y descubrir como pode escalar nuestros privilegios.
Marcaremosque el usuario JDgodd se encuentra como "Owned" ya que disponemos de sus credenciales y son válidas.
Revisando a este usuario, nos fijamos que el usuario tiene permisos de WriteOwner sobre el grupo "CORE STAFF". Y además que el grupo "CORE STAFF" tiene permisos de "ReadLAPSPassword" sobre el DC.
Esto lo que significa es que el usuario puede añadir miembros, cambiar el propietario del grupo mencionado, por lo cual si añadimos al usuario a ese grupo tendremos permisos de getLAPSPassword sobre el DC y obtener su contraseña.
BloodHound nos da una serie de pautas de como agregarnos al grupo, cambiar propietario, etc.
Para poder realiar la explotación, será necesario hacer uso de PoweView.ps1 debido que sino, no podremos ejecutar los comandos que necesitamos.
Procederemos a pasarnos el PowerView y a import el módulo.
Este script convierte una contraseña a un formato seguro, crea un objeto de credenciales para el usuario JDgodd, y luego le otorga permisos y lo agrega al grupo "Core Staff" en Active Directory.
Comprobarmeos que se ha añadido correctamente el usuario JDgodd al grupo "CORE STAFF".
Haciendo uso de la herramienta de ldapsearch y con credenciales que tenemos del usuario que tiene permisos de getLAPSPassword, procederemos a mostrar la contraseña del usuario "Administrator".
Comprobaremos a través de netexec de las credenciales para revisar que son válidas, nos conectaremos con evil-winrm y obtendremos la flag de root.txt.
Enumerando el sitio web comprobamos que aparecen los nombres de 3 miembros del equipo, esto nos puede ser útil para intentar enumerar usuarios.
Con el escaneo de Nmap, uno de los DNS que resolvía era el de , por lo cual procederemos de acceder y revisar qué tecnologías utiliza.
Accedimos al sitio web y nos encontramos la siguiente página web que tenía un buscador al parecer de peliculas. Revisando la sintaxis de cómo funcionaba el buscador, pensamos que se trataría de una BBDD de MSSQL debido que nos enfrentamos a una máquina Windows Server.
Revisamos la página de , en la cual te dan diferentes payloads para intentar realizar una inyección SQL a MSSQL.
Accederemos a y probaremos de autenticarnos con un usuario random para comprobar el mensaje de error que nos muestra, nos copiaremos este mensaje de error a la clipboard ya que lo necesitaremos para utilizar Hydra.
Accederemos a (recordemos que habíamos enumerado el directorio "admin" y nos daba un Forbidden 443), pero ahora si podemos acceder debido que disponemos de unas credenciales válidas.
Accediendo a comprobamos que es una página de desarollo enla cual está mal modificado y se puede realizar un LFI (Local File Intrusion).
Comprobamos que obtenemos todo el contenido del "index.php" en formato base64
Probaremos de acceder a y comprobamos que no podemos ver el contenido de la página.
Para el tema de los directorios donde podemos guardar el archivo, hemos buscado alguno de
