Análisis básico de ficheros PCAP

Hola chicos!! Como tal vez sabréis, unos cuantos autores el blog estamos participando en el curso online de hacking ético organizado por Mondragon Unibersitatea.

Aunque es un curso de nivel básico, sirve para cubrir algunos aspectos fundamentales en el proceso del pentesting, y estamos disfrutándolo a tope. Además, la última parte, en la que estamos ya metidos de lleno, consiste en un wargame en el que los equipos securizan un servidor y posteriormente tratan de atacar los del resto. ¡Promete!

Este ejercicio que os traigo hoy está sacado del propio curso. Dado que de momento por aquí no hemos tocado demasiado el tema de análisis de ficheros pcap, que contienen los paquetes recogidos en una captura, me parece muy interesante presentároslo.

Os dejo aquí el proceso con explicaciones y cada uno de los ficheros que necesitáis para los ejercicios. Enjoy!!

Primera parte: analizando un protocolo inseguro - Telnet

Fichero de la escucha 

A partir de una captura de paquetes de red recogida en un archivo .pcap realizaremos un análisis de las operaciones realizadas mediante el protocolo Telnet. Este protocolo, al carecer de cifrado, permite que la escucha de red revele todo lo intercambiado en la conexión. 

Podemos abrir el fichero con cualquier analizador de paquetes, como puede ser Wireshark, el cual utilizaremos. 

Lectura del fichero con Wireshark

Como puede verse en la imagen, es muy fácil filtrar el protocolo a mostrar escribiendo simplemente telnet en el campo de filtros del programa.

Podemos ver en texto plano en los campos de análisis de cada paquete los datos intercambiados entre los dos hosts, desplegando la pestaña Telnet. Podemos responder asíl fácilmente a varias preguntas:

• ¿Qué usuario y contraseña se ha utilizado para acceder al servidor de Telnet?
• El usuario es fake, y la contraseña user. 
• ¿Qué sistema operativo corre en la máquina?
• Utiliza un OpenBSD 2.6-beta.
• ¿Qué comandos se ejecutan en esta sesión?
• Se ejecutaron cuatro comandos en la sesión:

ls

ls -a

/sbin/ping www.yahoo.com
(ctrl-c)

exit

Segunda parte: analizando SSL

Fichero de la escucha

En la siguiente parte, realizaremos un análisis muy similar con una traza que ha recogido una sesión SSH. A diferencia de Telnet, el protocolo SSH realiza un cifrado de la conexión, de forma que hace imposible que apreciemos a primera vista los datos que se intercambian. 

Lectura del fichero con Wireshark (2)

Aunque no podemos discernir las operaciones realizadas en la sesión, podemos responder a algunas preguntas: 

• ¿Puedes identificar en qué paquete de la trama el servidor envía el certificado?
• Sí. Los certificados se envían en los paquetes enviados por el servidor y que contienen la información marcada como Certificate. Si abrimos dicha información, se puede ver el certificado. 

Certificado encontrado en la sesión

• ¿El certificado va en claro o está cifrado? ¿Puedes ver, por ejemplo, qué autoridad ha emitido el certificado?
• Para que el cliente pueda ver el certificado antes de realizar una conexión completa mediante SSH y así verificar la identidad del servidor a priori, el certificado se envía en plano, sin cifrar. 

Información del certificado en Wireshark

• Si queremos ver la información algo más clara, podemos exportar el certificado clicando con el botón derecho en la pestaña del certificado y en Export Packet Bytes..., para entonces guardarlo como un fichero .der. Podemos ver este certificado entonces haciendo doble clic sobre él. Entre otras cosas, podemos ver los datos acerca de la autoridad de certificación. 

Visualización de datos del certificado

• ¿Qué asegura el certificado, la identidad del servidor o del cliente?
• El certificado asegura la identidad del servidor. 

Tercera parte: analizando SSH

Fichero de la escucha

Por último para esta tarea, analizaremos otra captura del protocolo SSH para responder a otra serie de preguntas respecto a la misma. 

• ¿Puedes ver a partir de qué paquete comienza el tráfico cifrado?
• Sí. Aunque en la captura solamente se muestran los paquetes enviados desde el lado cliente, puede apreciarse que el tráfico cifrado comienza en el paquete marcado como 13, después de haber intercambiado las claves. 

Primer paquete cifrado de la sesión

• ¿Qué protocolos viajan cifrados, todos (IP, TCP...) o alguno en particular?
• Algunos protocolos viajan cifrados, otros no. Tanto TCP como IP son protocolos de capas inferiores a la de aplicación, la cual es la que suele ofrecer funciones de cifrado. Por ejemplo, el protocolo FTP viaja sobre TCP/IP, pero no está cifrado; su derivado seguro, FTPS, también viaja sobre TCP/IP, pero está cifrado.
• ¿Es posible ver alguna información de usuario como contraseñas de acceso?
• No es posible (al menos de forma matemáticamente rentable) recuperar ningún tipo de dato de la sesión una vez pactadas las claves de cifrado. 

Hasta aquí el ejercicio, hackers. Espero que os sirva para practicar un poco y disfrutar!!

Securizar SSH mediante Latch en Raspbian.

Hola amantes de la seguridad!!

En esta entrada vamos a ver como instalar Raspbian en la Raspberry Pi y securizar el servicio ssh para evitar posibles ataques mediante Latch y Fail2Ban.

Para quien no conozca la Raspberry Pi dejo unos enlaces con información:

• Web Oficial: https://www.raspberrypi.org/
• Info e historia: https://es.wikipedia.org/wiki/Raspberry_Pi
• Proyectos: http://www.omicrono.com/tag/raspberry-pi/
• Sistemas Operativos: https://raspberryparatorpes.net/raspberry-pi-sistemas-operativos/

Tenemos dos opciones para la instalación de Raspbian:

• NOOBS: se trata de un instalador de sistemas operativos para Raspberry.

• Descargamos la imagen desde este enlace.
• Lo descomprimimos en la raíz de una tarjeta SD previamente formateada.
• Introducimos la tarjeta en la Raspberry y la arrancamos (enchufamos).

• Basta con elegir el/los sistema/s operativo/s que queramos instalar y pinchar en Install.
• Cuando termine el proceso, nos mostrará un grub donde elegir el sistema operativo.

• RASPBIAN: descargar la imagen directamente.
• Descargamos la imagen del siguiente enlace. 
• A continuación tenemos que "copiar" la imagen en una tarjeta SD de forma que sea booteable. En Windows podemos usar Win32DiskImage, en Linux Startup Disk Creator.

LATCH

Con Raspbian ya instalado, vamos a securizar el servicio SSH con Latch.

Lo primero que necesitamos es crear una cuenta de Desarrollador en la web de Latch. Con la cuenta ya creada y logueados, añadiremos una nueva aplicación indicando un nombre, obtendremos esta pantalla con los datos de la misma.

• Nombre: nombre de la aplicación.
• Id Aplicación: número que identifica la aplicación.
• Secreto: clave secreta, podemos renovarla si creemos que está comprometida.
• Imagen: icono de la aplicación, no debe superar 1Mb de tamaño y se recomienda que esté en formato png de 24 bits sin canal alfa, con unas proporciones 1:1.
• Las opciones OTP y Bloquear tras consultar, solo están disponibles en las cuentas de pago.
• Operaciones: cada una de las acciones incluidas en el servicio y que se quieren proteger.

Añadiremos una operación para proteger el login del servicio SSH. Pinchamos en añadir y le ponemos un nombre. Dejamos la web abierta para copiar algunos datos que necesitaremos para la configuración de Latch.

A continuación descargamos el plugin de Latch para Unix del Github de Eleven Paths. Descomprimimos y nos situamos en la raiz de la carpeta resultante.

Ejecutamos el siguiente comando para instalar el plugin:

./configure prefix=/usr sysconfdir=/etc && make && sudo make install

Tras la instalación, tendremos el módulo pam_latch.so en el directorio /usr/lib. Debemos mover dicho módulo al directorio PAM del sistema operativo, en el caso de Raspbian se encuentra en /lib/arm-linux-gnueabihf/security/.

El siguiente paso es modificar la configuración PAM del servicio SSH, para ello modificamos el archivo /etc/pam.d/sshd añadiendo la siguiente linea:

auth required pam_latch.so config=/etc/latch/latch.conf accounts=/etc/latch/latch.accounts operation=<NOMBRE OPERACION> otp=no

Donde NOMBRE OPERACION es el nombre que pusimos al crear la operación (sshd-login) en la web de Latch.

En la carpeta del plugin de Latch que descargamos anteriormente, hay una carpeta "examples" con ejemplos de los archivos a modificar para cada servicio, echarles un vistazo en caso de tener problemas.

A continuación configuramos el plugin editando el archivo /etc/latch/latch.conf.

• app_id: id de la aplicación.
• secret_key: clave secreta ("Secreto" en la web).
• sshd-login: este es el nombre que le dimos a la operación anteriormente, aquí introducimos el número id de la misma.

Por último configuramos SSH para uso del plugin, esto lo haremos editando el archivo /etc/ssh/sshd_config, añadiendo o modificando las siguientes lineas:

• UserPAM yes
• ChallengeResponseAuthentication yes
• PasswordAuthentication no

Reiniciamos el servicio (sudo service sshd restart) para cargar la nueva configuración.


Con Latch configurado, solo nos falta parear un usuario para así activar o desactivar el acceso a SSH desde nuestro móvil, además recibiremos notificaciones de bloqueo, accesos, etc.
 Instalamos Latch en el móvil desde Google Play, abrimos la aplicación y nos logueamos con la cuenta creada en la web. Añadimos un nuevo servicio y Generamos nuevo código.

Como podéis ver en la captura anterior, tenemos un tiempo para usar el código, usamos el siguiente comando en la terminal de la Raspberry para parear el servicio:  latch -p <CODIGO>

Recibiremos un aviso en el móvil confirmando que el servicio ha sido pareado. Ahora nos aparecerá el nuevo servicio creado en la pantalla principal de la aplicación, desde aquí podemos bloquear o permitir el login SSH.

Ya disponemos de un segundo factor de autenticación mediante Latch. Ni que decir tiene que esto mismo se puede realizar para el login de una máquina, comando sudo, servicio vnc y un largo etc.


FAIL2BAN

Como complemento tenemos Fail2Ban, una aplicación escrita en Python para la prevención de intrusos penalizando las ips que intentan el acceso por fuerza bruta en servidores SSH, FTP, HTTP, etc.

Fail2Ban bloquea las ips que intenten loguearse un determinado número de veces (indicado por el usuario) por un tiempo determinado (indicado por el usuario), evitando así ataques por diccionario.

Su instalación es muy sencilla, descargamos el paquete correspondiente a nuestra distribución Linux desde la web oficial y lo instalamos.

Para configurarlo tenemos que editar dos archivos.

• /etc/fail2ban/fail2ban.conf

 

• loglevel: elegimos los datos que mostrará el archivo log.
• logtarget: ruta y nombre del archivo log.
• pidfile: podemos elegir el número de proceso de fail2ban-server.

•  /etc/fail2ban/jail.conf

• bantime: tiempo en segundos que estará baneada la ip.
• maxretry: número de intentos antes de ser baneado.
• ignoreip: lista de ips que serán ignoradas y por tanto no baneadas.
• protocol: protocolo por defecto (TCP/UDP).

 Éstas son algunas de las opciones disponibles, recomiendo echar un vistazo a todas detenidamente.

Reiniciamos el servicio (sudo service fail2ban restart) y ya lo tenemos todo listo. Para ver el log en tiempo real, podemos hacer uso del comando less +F /var/log/fail2ban.log para ver el archivo completo o tail -f /var/log/fail2ban.log para ver solo las últimas lineas.

Como véis ya he recibido algunos ataques...


Hasta aquí la entrada de hoy, espero os haya gustado y que sea de utilidad.

Un saludo, vasco.

Pentestit.ru - Test lab v.9 (Parte I)

Buenas hackers! Bienvenidos al lab.pentestit.ru

Me ha costado hacerlo en una semana más o menos y es el tiempo que me puse para hacerlo. No lo he terminado debido a su dificultad, y aún con ayuda me quede de momento en el 63%. Tengo que dar agradecimientos al compañero belane que me resolvió un token, ya que andaba bastante perdido y también a una persona del canal de telegram en inglés del lab, que me ha ayudado en el transurso de él. Gracias.

Una vez dicho esto, hay que conectarse mediante VPN al servidor. Para ello podemos hacerlo de dos formas, bajarnos la iso que tienen disponible para hacer el lab o bajarse el archivo de configuracion de la VPN y usar openvpn con dicho archivo. Usare esta ultima para poder usar parrotOS.

Por tanto solo basta con descargarnos ese arhivo e irnos luego a network connections y añadir una nueva conexion VPN, importando una configuracion VPN previamente guardada. Una vez elegido esto simplemente hay que poner el user y la pass que nos proporciona la web.

Es muy aconsejable que miremos el esquema de la red interna del lab, ya que es la estructura principal por donde nos moveremos en el pentesting. Vemos que hay dos subredes bien diferenciadas y distintos servidores con software y sistemas diferenciados, al giaul que los servicios que prestan.

De primeras solo podemos hacer un descubrimiento de red a la ip del gateway. Una vez conectado a la VPN necesitamos nmap para ver que puertos del gateway estan abiertos.

Atención Spoiler!!

Nmap para realizar un escaneo Con la opción -sV permite ver la versión de los servicios, con -A permite la deteción de OS, la versión, script scanning, y traceroute. Con -T4 indica el tiempo de envió de los paquetes, es decir desde 0-6, la más baja es la más lenta, y también mejor ya que podría evadir algunos firewall.

 Haciendo pruebas en el navegador, no resuelve el dominio por el protocolo http. Con https nos dice que es inseguro y en el puerto 8100 vemos que es un servidor de correo.

"El archivo hosts de un ordenador es usado por el sistema operativo para guardar la correspondencia entre dominios de Internet y direcciones IP. Este es uno de los diferentes métodos que usa el sistema operativo para resolver nombres de dominios."Wikipedia.

Así añadimos la dirección del gateway con su nombre del dominio y guardamos. Vemos dos email que pueden ser usados como nombres de usuario dentro de la red, así que es importante tenerlo en cuenta para mas adeltante.

Vemos su código fuente y no se ve nada de interés, unicamente contenido de wordpress. Si es un wordpress ¿Por qué no probamos el wp-login? Bien vemos que hay detras un WAF, detector de intrusos. Probamos dirb para hacer fuzzing de los directorios (Sin resultados positivos).

Sabiendo que es un wordpress, vamos a usar wpscan, para poder enumerar diferentes usuarios y las vulnerabilidades de los plugins.

 Probe buscar en searchsploit symposium para ver algún tipo de exploit para poder ganar algun tipo de acceso al servidor. En uno de ellos usaremos un SQLi en donde se aprecia una PoC, por tanto que mejor que usarla. Permite de una forma muy sencilla usando wget, obtener la base de datos incluyendo datos e informacion sensinble de usuarios y hashes de las contraseñas. Sin exito, error 403 Forbbiden. Creo que no se puede explotar ninguna vulnerabilidad por el puerto 80 debido al WAF. Así que probemos el puerto 443 https.

Segun Nmap esta abierto el puerto y la version de nginx esta obsoleta. Vamos a ver que tipo de SSL se esta usando con sslscan.

Esta herramienta permite realizar un escaneo para la busca de vulnerabilidad del SSL, y así poder subsanarla.

Según el resultado nos indica que es vulnerable a heartbleed. Podemos usar los scripts de Nmap para poder ver la vulnerabilidad del SSL tambien. Recomiendo usar la documentación en la web de Nmap en la seccion de NSE para ver todos los scripts disponibles que tenemos para poder hacer una buena auditoría de seguridad y pentesting.

Obtenemos un resultado positivo con un riesgo alto.

Vamos a usar metasploit, un auxiliar para poder explotar dicha vulnerabilidad en busca de información. La recoleccion de información es un proceso muy importante para poder encontrar información sensible como por ejemplo usuarios.

Seleccionamos la versión del TLS, rhost y en verbose para poder ver la salida de la ejecucción del auxiliar.

Encontramos un backup de usuarios....

Es una dirección web, como podemos observar en /var/html/_old.....

Lo introduccimos en el navegador y nos lo descargamos.

Bien tenemos unos usuarios con sus hashes.

Usaremos hashcat y el parametro -m

Y el resultado es la obtención del token bypass y conttraseñas utiles que nos van a servir para hacer lo que vendrá a continuación.

Una vez obtenido los usuarios del proxy, ya que vimos el resultado del nmap con un puerto abierto y su servicio proxy, vamos a usar sqlmap para explotar la vulnerabilidad anterior con el proxy y con las credenciales de un usuario.

Usamos esta parte del exploit que encontramos:

/wp-content/plugins/wp-symposium/get_album_item.php?size=

Como hay un WAF y en los intentos no nos ha dado resultado, ponemos el como proxy la url de la web:

--proxy="http://192.168.101.8:3128"

 y usamos una de las credenciales antes obtenidas

--proxy-cred="b.muncy:rabbit"

que nos dé un user-agent aleatorio:

--random-agent

le indica número de intentos o de carga:

--level="4"

sqlmap -u "http://cybear32c.lab/wp-content/plugins/wp-symposium/get_album_item.php?size=1" --dbs --proxy="http://192.168.101.8:3128" --proxy-cred="b.muncy:rabbit" --random-agent --level="4" 

Despues de un tiempo, nos devuelve dos bases de datos, concretamente MySQL.

Ahora usamos una base de datos, y obtenemos las tablas de ella

Seguidamente las columnas, y luego un dump.

Y bien, de esta forma obtenemos el token.

Una vez analizado el puerto 80 y 443, y mediante el uso del proxy pudimos obtener el token, nos conectaremos mediante el puerto 22 el servicio SSH al servidor. Es muy importante intentar conseguir acceso mediante este servicio ya que una vez conseguido podemos hacer pivoting dentro de la red interna, y a su vez crear un tunel hacia nuestro localhost y auditar o realizar un test de intrusión en dicho server interno. Por lo visto la versión del openssh no es vulnerable así que vamos a realizar la conexion para a ver si podemos obtener iunformacion del banner al conectarnos. Hice una consulta en el canal de telegram ya que no sabía por donde tirar y me dijeron que me fijase justamente en el banner. Podríamos buscar en google el nombre y saber que es. Aun así probamos contraseñas por defecto y nada. Por lo visto en github tiene un codigo en C, y podemos ver justamente el string The password en él y bueno no se programar en C, pero interpretando el código vemos lo siguiente:

En el código de la aplicación estaba la clave para pasar.

En la primera parte veíamos esto:

// disallow root logins
 if (strcmp(pUsername, "root") == 0) {
  return PAM_AUTH_ERR;
 }

Tiene deshabilitado el login de usuario " root "

En la segunda parte del código:

time_t now = time(NULL);
 struct tm *now_tm = localtime(&now);
 int hour = now_tm->tm_hour;
 int day = now_tm->tm_mday;

 char correctPass[11];
 sprintf(correctPass, "daypass%d%d", day, hour);

Nos dice time_t now = time(NULL) ----> hora actual

struct tm *now_tm = localtime(&now); ---> hora del lugar,(sabemos que el CTF está en Rusia, por lo tanto horario Ruso)

Aquí la manera de proceder con la clave:

sprintf(correctPass, "daypass%d%d", day, hour); ---->para que la pass sea correcta tenemos que poner daypass+el-día+la-hora (de Rusia)

Ejemplo:

Si en rusia son las 21:30, y hoy es el 7 de Agosto del 2016, la password sería ----> daypass721

Una vez deducida la password, usaremos usuarios comunes de linux, tal como daemon o www-data para el login en SSH.

Vemos que hay 3 users, probamos con el primero para loguearnos con él:

daemon@tl9-ssh:/etc$ su d.nash

The password: daypass723

d.nash@tl9-ssh:/etc$ cd /home

d.nash@tl9-ssh:/home$ ls -la

total 20

drwxr-xr-x 5 root root 4096 May 17 14:32 .

drwxr-xr-x 23 root root 4096 Aug 18 2013 ..

drwxr-x--- 3 root d.nash 4096 May 19 17:07 d.nash

drwxr-x--- 2 root e.grant 4096 May 17 14:54 e.grant

drwxr-x--- 2 root t.alvarez 4096 May 17 14:30 t.alvarez

Accedemos al directorio de d.nash :

d.nash@tl9-ssh:/home$ cd d.nash

d.nash@tl9-ssh:~$ ls -la

total 24

drwxr-x--- 3 root d.nash 4096 May 19 17:07 .

drwxr-xr-x 5 root root 4096 May 17 14:32 ..

-rw-r----- 1 root d.nash 220 Dec 30 2012 .bash_logout

-rw-r----- 1 root d.nash 3392 Dec 30 2012 .bashrc

-rw-r----- 1 root d.nash 675 Dec 30 2012 .profile

drwxr-x--- 2 root d.nash 4096 May 19 17:11 .ssh ------> directorio oculto

Accedemos al directorio oculto .ssh

d.nash@tl9-ssh:~$ cd .ssh

d.nash@tl9-ssh:~/.ssh$ ls -la

total 24

drwxr-x--- 2 root d.nash 4096 May 19 17:11 .

drwxr-x--- 3 root d.nash 4096 May 19 17:07 ..

-rw-r----- 1 root d.nash 1675 May 19 16:52 id_rsa

-rw-r----- 1 root d.nash 396 May 19 16:52 id_rsa.pub

-rw-r----- 1 root d.nash 222 May 19 17:11 known_hosts

-rw-r----- 1 root d.nash 10 May 19 16:57 token.txt ----> flag

Ahora vemos con cat que hay dentro del token.txt:

d.nash@tl9-ssh:~/.ssh$ cat token.txt

******ah

Un saludo, Naivenom

Tr0ll 1 trolleando a Fwhibbit

Buenas hackers! CTF de Vulnhub

Si queréis hacer el CTF, a partir de aquí os recomiendo que no leais nada, simplemente como guía si os veis atascados, como muchas veces me sucede ami cuando resuelvo un CTF, que necesito echarle un ojo jijiji

Atención Spoiler!!

Ejecutamos el netdiscover:

A continuacion usamos nmap, para descubrir las direcciones IP dentro de una subred:

Ahora ya descubierto la direccion IP en la misma red, realizamos un reconocimiento para ver que
puertos tiene abiertos y sus servicios.
Con la opción -sV permite ver la versión de los servicios, con -sS permite TCP SYN, con -A permite la deteción de OS, la versión, script scanning, y traceroute. Con -T4 indica el tiempo de envió de los paquetes, es decir desde 0-6, la más baja es la más lenta, y también mejor ya que podría evadir algunos firewall.

Al ejecutar con -A los scripts por defecto de nmap, como el http-enum.nse, hemos descubierto un archivo llamado robots.txt muy interesante.
Y como se puede apreciar tiene el puerto 21 FTP, con el login anonymous habilitado!!
EL 22 SSH
El 80 HTTP
Ahora con curl, realizamos una petición HTTP con la siguiente dirección del servidor:

Curl: Herramienta muy útil para hacer peticiones HTTP, que nos permite usar distintos protocolos
para dichas peticiones.
Introducimos la dirección del servidor en el navegador y WTF!!!

Usaremos nikto y el CLI de dirb:

También podemos usar wfuzz:

En robots.txt tenemos esto:

Hacemos Curl, y vemos que hay una imagen en la página HTML:

Vamos con el FTP:
Usaremos un auxiliar, para saber la versión aunque ya el Nmap nos lo pudo mostrar anteriormente

Conectamos mediante FTP, y antes de ver el archivo que existe, capturamos trafico para ver lo
vulnerable que es el servicio FTP, dandonos el user y pass en texto claro.

Analizamos a su vez el tráfico capturando paquetes con Wireshark:

Ahora abrimos el archivo lol.pcap:

Y vemos que existe un archivo .txt:

Y leemos su significado, dando a analizar y follow:

También podemos ver el acrhivo lol.pcap con strings:

Probamos el directorio que nos menciona el archivo,en el navegador:

Vemos que existe un binario en el servidor, nos lo descargamos con wget:

Damos permisos de ejecución al binario y ejecutamos:

Bien esta dirección nose en cuanto nos puede ayudar, pero ¿qué podría significar?
Probamos con file para ver el tipo de fichero y strings:

Nos devuelve algo más de información... Siendo una dirección de memoria podríamos usar gdb pero sin resultados positivos. Así que vamos hacer algo más sencillo poniendo esa dirección en el navegador:

Bien pues encontramos dos directorios en la cual podemos encontrar información valiosa, en uno de ellos encontramos un .txt donde contiene usernames, mientras que en el otro directorio tenemos las password.
Por tanto que mejor que descargarnos los archivos con wget y montarnos el diccionario, ya que esto es una vía de acceso en uno de los servicios ya sea ftp o ssh.

Con nano users.txt:

Nos descargamos el archivo pass y creamos el diccionario:

Si visualizas Pass.txt solo viene una linea en el archivo, "buen trabajo", por tanto nose esta maquina tengo la sensación de que me esta troleando jjj, leyendo algún walkthroughs, haré lo siguiente:

Usamos hydra para realizar un ataque de fuerza bruta:

Sin resultados....Probemos con el servicio SSH:

Y si esa era la pass.... :(
Por tanto, vamos a conectarnos por SSH al servidor:

Bien obtuvimos una shell, pero se me cerro la conexion THIS F*** MACHINE IS TROLLING ME?
Si estamos conectados cierto tiempo, nos cierra la conexión...
Bueno nos conectamos de nuevo, y vamos a ver los ficheros con permisos de escritura y redirijimos los errores a /dev/null:

Existe un fichero en Python donde tenemos permisos de escritura, lo visualizamos:

Este script lo que hace es borrar de forma recursiva todo lo contenido en /tmp
En esta carpeta es donde podemos siempre ejecutar algún exploit o scripts para poder realizar una escalada de privilegios.
Seguidamente nos dirijimos a var/log ya que es interesante ver el cron, debido a que quizás haya una tarea programada de ejecutar el script cleaner.py.
Antes veremos los permisos:

Tenemos permisos para escritura, lectura y ejecución con el usuario actual...
Visualizamos:

Efectivamente cada 2 minutos se ejecuta todos los dias este script. Coincide con el tiempo que se nos desconecta la conexión al servidor. Así que si editamos este script y en vez de que borre todo lo que existe en /tmp, copiamos lo que hay en /bin/sh a /tmp/sh y cambiamos a permisos de setuid y ejecutables para cualquier usuario, podremos ser root.

Bien una vez editado el script vamos a esperar a que se nos desconecte, para que el cron haga su trabajo ejecutando el cleaner.py. Nos logueamos y ejecutamos /tmp/sh

Ahora nos dirijimos a /root y alli esta la bandera!:

Espero que os sirva esta posible solución al CTF
Un saludo Naivenom