Web for Pentester: Practica las vulnerabilidades web más comunes

De entre los muchos ejercicios que nos podemos encontrar en el interesante proyecto de PentesterLab (del que os hablamos en los enlaces de la SECmana 141) creado por Louis Nyffenegger (@snyff), se acaba de publicar un conjunto de ejercicios llamado "Web for Pentester".

Estos ejercicios repasan las vulnerabilidades más comunes que nos podremos encontrar a la hora de analizar y realizar pruebas sobre aplicaciones web. El enfoque de estas prácticas no es sólo el de realizar las pruebas web como tal, si no todo lo relacionado a procesos de test de intrusión, como el reconocimiento de la arquitectura, sistema, servicios, etc.

Se proponen varios ejemplos para cada una de las siguientes tipos de vulnerabilidades:

• Pruebas básicas de reconocimiento (fingerprinting)
• Cross-Site Scripting
• Inclusión de ficheros
• Ataques LDAP
• Inyecciones SQL
• Inyección de código
• Subida de ficheros
• Pruebas de ruta transversal
• Inyección de comandos
• Ataques XML

Esta vez no se trata de ejercicios online, si no que el creador del proyecto ha preparado una pequeña imagen .iso, en la cual, bajo el sistema operativo Debian, se ha creado un entorno en el que se incluyen  diferentes scripts vulnerables:

Descarga de imagen .iso con entorno vulnerable

Con la imagen, en la sección de descargas de estos ejercicios se encuentra un documento en .PDF web_for_pentester.pdf en el que se explican todas y cada una de las pruebas con sus correspondientes ejemplos, aunque obviamente, recomendamos consultar este documento después de, por lo menos, haberle dedicado un buen rato a resolverlos por cuenta propia.

Índice del documento PDF que acompaña al ejercicio

Dicho informe recoge el análisis realizado desde las fases iniciales del test de intrusión (reconocimiento del servicio web, búsqueda de recursos interesantes, puntos de entrada a la aplicación, análisis de respuestas del servidor web, etc), así como conceptos básicos y requeridos para completar las pruebas posteriores.

Documentación de Web For Pentesters, incluyendo ejemplos y how-to's

Ejemplo 1 de Cross-Site Scripting

Ejemplo 1 de File Inclusion

Si bien el nivel de dificultad se ha determinado como para principiantes, es un buen repaso, además de completo, para cualquier interesado en este campo de la seguridad informática sobre aplicaciones web.

[+] Proyecto Web For Pentester - Pentesterlab.com

Leer más...

Revisando las últimas vulnerabilidades en pfsense 2.0.1

pfSense es una distribución libre, de código abierto, y personalizada de FreeBSD, adaptada para ser utilizada como firewall y router. Incluye una larga lista de funcionalidades incorporadas, y otras tantas que se pueden agregar fácilmente a través de componentes instalables.

Como su rendimiento es muy elevado, pfSense es utilizado en muchísimas organizaciones como firewall perimetral, como terminador de VPNs, y como servidor interno multipropósito (dhcp, proxy, etc.).

El filtrado de paquetes de pfSense se basa en reglas de pfctl; digamos, el "iptables" de freeBSD. El proyecto se inció en el año 2004, basándose en la distribución m0n0wall; pero si bien pfSense puede instalarse en algunos sistemas embebidos, apunta a instalaciones en computadoras personales de 32 y 64 bits.

pfSense tuvo un cambio de versión grande hace poco más de un año. La última versión estable anterior era la 1.2.3, y si bien no tenía tantas funcionalidades como la rama 2.x.x, era un producto robusto, fiable, y no le faltaba nada para reemplazar a muchos UTMs y firewalls comerciales.

La historia de las últimas versiones:

• 1.2.3 -> 6/12/2009
• 2.0.0 -> 17/9/2011
• 2.0.1 -> 20/12/2011
• 2.0.2 -> 21/12/2012

Nuevas vulnerabilidades

El 4 de enero se hicieron públicas 3 vulnerabilidades presentes en la versión 2.0.1, junto con pruebas de concepto y demo en video: http://www.exploit-db.com/exploits/23901/

Vamos a ver de qué se tratan.

1) La primera es un XSS en el archivo /usr/local/www/progress.php

En primera medida hay que comentar que este archivo no es utilizado realmente, según se puede ver al evaluar el código PHP, y según lo que se indica en :
http://www.freshbsd.org/commit/pfsense/aca65de524027e9aedfa38f83665907b41abce58

Se puede ver en la línea 24, que si el parámetro HTTP GET "e" es enviado (no importa con qué valor), entonces PHP devuelve en la línea 25 el valor del parámetro GET "UPLOAD_IDENTIFIER" que proviene del usuario, sin darle ningún tratamiento.

En la línea 28, se devuelve una variable llamada $url, la cual contiene también al parámetro "UPLOAD_IDENTIFIER", pero en este caso es sanitizado con CSRFMagic (http://csrf.htmlpurifier.org/)

De todos modos, esta debilidad no es explotable, ya que si se invoca al archivo de manera directa, la ejecución falla en la línea 21 debido a que la función "upload_progress_meter_get_info" no se encuentra definida en ninguna parte. De esta manera PHP arroja un FATAL ERROR, y el código inseguro no llega a ejecutarse.

Si cambiamos la asignación en la línea 21 de la siguiente manera:

$X = 0; // upload_progress_meter_get_info( $_GET["UPLOAD_IDENTIFIER"] );

podemos ver que el XSS sí sería explotable.

2) La segunda es un XSS en la línea 166 del archivo /usr/local/www/pkg_mgr_install.php

Nuevamente, el parámetro GET "pkg" es devuelto por PHP tal como es enviado por el navegador, sin ningún tratamiento.

Nada que agregar.


3) La tercera es una vulnerabilidad en la línea 118 del archivo /usr/local/www/system_firmware.php que permite la ejecución remota de código.

Esta vulnerabilidad es muy importante, ya que permitiría a un atacante ejecutar código con permisos totales en el sistema operativo.
El uso correcto que espera darle pfsense a este código es ejecutar:

echo SMP > /boot/kernel/pfsense_kernel.txt

pero un atacante podría enviar una petición POST con el parámetro "kerneltype" modificado, y lograr que la sentencia que se ejecuta sea otra, por ejemplo:

echo lo_que_el_atacante_desee > /boot/kernel/pfsense_kernel.txt

Vamos a modificar lo_que_el_atacante_desee por algo que nos convenga más, por ejemplo:

cualquiercosa ; echo "Me parece haber visto un lindo gatito" > /root/Evidencia_CSRF.txt ; echo SMP

Así, la sentencia completa que se ejecutaría sería:

echo cualquiercosa ; echo "Me parece haber visto un lindo gatito" > /root/Evidencia_CSRF.txt ; echo SMP > /boot/kernel/pfsense_kernel.txt

Creamos un archivo html que contenga el formulario con el valor que queremos, y que al cargarse haga la petición POST

Listamos el directorio /root del pfsense para ver qué hay:

En en navegador abrimos el archivo HTML que creamos, y luego vemos qué pasó en el directorio /root:

Como se puede ver, se creó el archivo que queríamos, en el directorio /root, y su dueño también es root. De mas está mencionar la potencialidad de explotar esta vulnerabilidad.

Estas debilidades se solucionaron en la versión 2.0.2 del producto, y en el detalle de cambio, se mencionan estos (y quizás otros?) fixes:

• Fix a few potential XSS/CSRF vectors.

Es necesario mencionar que estas debilidades sólo podrían ser explotadas con una sesión iniciada en la consola de administración; Si no hay sesión abierta, no hay exposición.

Adicionalmente, esta última versión se basa en la versión 8.1-RELEASE-p13, que corrige algunas cuestiones de seguridad inherentes al mismo FreeBSD.

Soy un fanático de pfSense, sé que tiene algunas cuantas cosas por mejorar y refinar; personalmente me encontré con algunos casos más de validación de entrada del lado del cliente (por javascript), que no eran chequeados del lado del servidor. Pese a todo esto, creo que es un producto noble, y en muchos casos es la mejor opción.

Contribución por cortesía de Leonardo Brugues (@lbrug)

Leer más...

Centro de Servicio de Vulnerabilidades - VulnerabilityChaser

Somos Ibrahim Peraza y María Ángeles Caballero,  dos alumnos del Máster Universitario de las Tecnologías de la Información y la Comunicación de la UEM trabajando en el Proyecto de Fin de Máster “Centro de Servicio de Vulnerabilidades - VulnerabilityChaser”. Los profesores del Máster ofertan proyectos relacionados con el mundo de la seguridad y éstos, se desarrollan por varios alumnos. Los proyectos requieren un trabajo previo de investigación, abordando un análisis en profundidad de la problemática concreta y un desarrollo posterior, siempre tutelado por el director del proyecto, en nuestro caso Alejandro Ramos.

En concreto, nuestro proyecto va enfocado a la gestión de vulnerabilidades de los activos de una compañía. Al realizar un estudio previo pudimos observar varias deficiencias en la información que proporcionan los escáneres de vulnerabilidades como pueden ser Nessus o GFI LANguard. Son herramientas muy potentes en cuanto al análisis de vulnerabilidades, pero la información que se muestra acerca de la severidad de las vulnerabilidades no es del todo realista, ya que la puntuación se basa en valores estándar como el CVSS Base sin tener en cuenta factores concretos del sistema afectado como puede ser si es un equipo en producción o simplemente se utiliza para pruebas de desarrollo. Otra deficiencia observada, es que no es posible ver la evolución del estado de las vulnerabilidades a lo largo del tiempo (abierta, cerrada, asumida o planificada), ya que los escáneres de vulnerabilidades nos entregan un informe sobre el estado de nuestros activos en un instante de tiempo concreto, no guardan los datos para ser comparados frente a futuros escaneos.

Nessus usa el CVSS base score para clasificar la severidad de una vulnerabilidad pudiendo ser info, medium, high o critical. El CVSS base score no es suficiente para determinar la severidad de una vulnerabilidad ya que entran en juego otros factores, como por ejemplo, la existencia o no de un exploit para dicha vulnerabilidad, el tipo de información que almacena el sistema, tipo de entorno (integración, preproducción o producción) , etc.

Lo ideal sería calcular para cada vulnerabilidad el CVSS final. El CVSS se calcula en función de 3 vectores: base, temporal y environmental:

-    Base: representa las características intrínsecas y fundamentales de una vulnerabilidad que son constantes en el tiempo y en los entornos de usuario.
Las métricas de éste vector comprenden:

• Access Vector (AV): refleja como la vulnerabilidad es explotada.
• Local (L); Adjacent Network (A); Network Access (N).
• Access Complexity (AC): mide la complejidad del ataque para explotar la vulnerabilidad.
• High (H); Medium (M); Low (L).
• Authentication (Au): mide el número de veces que un atacante debe de autenticarse para explotar la vulnerabilidad.
• Multiple (M); Single (S); None (N).
• Confidentiality Impact (C): este indicador mide el impacto sobre la confidencialidad de una vulnerabilidad al explotarla.
• None (N); Partial (P); Complete (C).
• Integrity Impact (I): este indicador mide el impacto a la integridad de una vulnerabilidad.
• None (N); Partial (P); Complete (C).
• Availability Impact (A): este indicador mide el impacto a la disponibilidad de una vulnerabilidad.
• None (N); Partial (P); Complete (C).

-    Temporal: representa las características de una vulnerabilidad que cambian con el tiempo pero no entre los entornos de usuario.
Las métricas de éste vector comprenden:

• Exploitability (E): esta métrica mide el estado actual de las técnicas de exploit o disponibilidad de código.
• Unproven (U); Proof-of-Concept (POC); Functional (F); High (H); Not Defined (ND).
• Remediation Level (RL): mide el nivel de corrección de la vulnerabilidad, si existe parche, soluciones provisionales, etc.
• Official Fix (OF); Temporary Fix (TF); Workaround (W); Unavailable (U); Not Defined (ND).
• Report Confidence (RC): esta métrica mide el grado de existencia de confianza en la vulnerabilidad.
• Unconfirmed (UC); Uncorroborated (UR); Confirmed (C); Not Defined (ND)

-    Environmental: representa las características de una vulnerabilidad que son relevantes y únicas para el entorno de cada usuario concreto.
Las métricas de éste vector comprenden:

• Collateral Damage Potential (CDP): éste indicador mida la potencia de pérdida de vidas o bienes físicos a través del daño de equipos o robo de éstos.
• None (N); Low (L); Low-Medium (LM); Medium-High (MH); High (H); Not Defined (ND)
• Target Distribution (TD): éste indicador mide la proporción de los sistemas vulnerables, número de sistemas que podrían verse afectados por la vulnerabilidad.
• None (N); Low (L); Medium (LM); High (H); Not Defined (ND)
• Security Requirements (CR, IR, AR): éstas medidas permiten personalizar la puntuación del CVSS dependiendo de la importancia de los activos afectados medido en términos de Confidencilidad, Integradidad y Disponibilidad.   
• None (N); Low (L); Medium (LM); High (H); Not Defined (ND)

Finalmente, cada métrica tendrá un valor asociado, lo que formará los 3 vectores:
   
Base    AV:[L,A,N]/AC:[H,M,L]/Au:[M,S,N]/C:[N,P,C]/I:[N,P,C]/A:[N,P,C]
Temporal    E:[U,POC,F,H,ND]/RL:[OF,TF,W,U,ND]/RC:[UC,UR,C,ND]
Environmental
    CDP:[N,L,LM,MH,H,ND]/TD:[N,L,M,H,ND]/CR:[L,M,H,ND]/ IR:[L,M,H,ND]/AR:[L,M,H,ND]

Podemos consultar en FIRST el cálculo del score de cada uno de los vectores y el CVSS final.

VulnerabilityChaser, la herramienta que hemos desarrollado, gestiona el ciclo completo de vida de la vulnerabilidad. La aplicación permite la introducción del resultado de un microanálisis de riesgos por cada activo del sistema utilizándolo (el resultado) para calcular el valor del CVSS. Los valores base y temporal vienen dados en el escaneo de Nessus y el environmental es el resultado del microanálisis de modo que con estos tres parámetros se realiza el nuevo cálculo de la criticidad de la vulnerabilidad quedando ésta adaptada de forma real al entorno en que se encuentra.

VulnerabilityChaser, hace las funciones de centro de servicio de vulnerabilidades para una empresa, facilitando la vida al administrador de seguridad. Esta herramienta es gratuita y opensource pudiendo ser descargada de GitHub. A día de hoy la aplicación aún se encuentra en un estado alfa de desarrollo.

La aplicación recoge la información de las vulnerabilidades de los escaneos de Nessus y la muestra de manera ordenada; permite cambiar el estatus de una vulnerabilidad, por ejemplo, de abierta a planificarla en una fecha para solucionarla más adelante si se quisiera, gestionar toda la parte de activos previamente comentada, mostrar estadísticas de manera gráfica y otras muchas funcionalidades.

Artículo escrito por Ibrahim Peraza y María Ángeles Caballero.
Twitter: @vul_chaser

Leer más...

Analizando las vulnerabilidades remotas de versiones anteriores a Wordpress 3.3.2

Hace unas semanas se anunciaba la versión 3.3.2 de Wordpress, que incluía entre otras cosas, 6 correcciones de seguridad, referentes a varias vulnerabilidades remotas encontradas, y de varios tipos. Ayer en el twitter de Daboblog nos recomendaba parchear nuestros blogs a su última versión debido a estas vulnerabilidades:

Tres de ellas (CVE-2012-2399, CVE-2012-2400 y CVE-2012-2401) fueron detectadas en librerías externas que utiliza Wordpress para subir ficheros en la sección de Multimedia, mediante Plupload, SWFUpload (librería anterior) y SWFObject (esta última se encuentra incluída dentro de muchos themes, y se utiliza para incrustar contenido Flash).

Para estas tres vulnerabilidades, podemos obtener detalles más técnicos referentes a ellas, simplemente revisando los diff de archivos entre ramas de versiones:

Como ejemplo, en el caso de la librería SWFObject (utilizada no sólo en Wordpress), el fallo radica en que no se codificaba previamente el valor de MMredirectURL, O.location, variable Flash utilizada en su instanciación. En la actualización del fichero Javascript, se realiza una codificación de la URL mediante la función encodeURI:

De las otras 3 vulnerabilidades (CVE-2012-2402, CVE-2012-2403 y CVE-2012-2404) se dispone de más información, tratándose de Cross-Site Scriptings y una evasión limitada de restricciones.

• CVE-2012-2402 - Se actualiza el fichero plugins.php, habiéndose descubierto la posibilidad de desactivar plugins por parte de usuarios administradores, para toda una red creada de blogs bajo una misma instalación, aun teniendo dicha restricción activada. Esta vulnerabilidad se ha categorizado como baja. A continuación podremos ver los cambios realizados, referentes a una comprobación utilizada para verificar que no se desactivaban plugins que ya estaban desactivados:

• CVE-2012-2403 - Se actualiza el fichero wp-includes/formatting.php, cuya función vulnerable era aquella que intentaba habilitar enlaces clicables (make_clickable) dentro de atributos, permitiendo la realización de ataques Cross-Site Scripting. Dicha función se ha re-escrito completamente:

• CVE-2012-2404 - Se actualiza el fichero wp-comments-post.php, que incluía una redirección a una variable $location de forma insegura, mediante una función propia de wordpress wp_redirect(). Como actualización, se sustituye el uso de dicha función por otra, llamada wp_safe_redirect(), que incluye comprobaciones y realiza la redirección local de forma más segura.

Si bien no se trata de vulnerabilidades muy críticas, debido a su posible explotación remota se recomienda actualizar Wordpress a su versión 3.3.2 ya disponible.

Leer más...

Liberado Nessus v5.0

La popular herramienta para el análisis de vulnerabilidades se ha actualizado a su versión 5, pese a que hay algunos cambios importantes, en general no hay grandes modificaciones, salvo la modificación de criticidades, que quedan en: Info, Low, Medium, High y Critical.

Una de las características nuevas es el cambio de instalación y configuración, donde ahora no es necesario en ningún caso editar ficheros de configuración y todo podrá ser realizado desde el panel de administración, incluida la actualización de plugins o el registro del escáner. Esta es una magnífica noticia, ya que estoy convencido que a todos los usuarios les encanta el diseño y usabilidad en Flash del GUI... *suspiro*

Donde posiblemente hayan metido un número mayor de mejoras sea en la parte de generación de reportes, añadiendo granularidad mediante el uso de filtros y permitiendo eliminar o añadir vulnerabilidades según criterios anidados.

Tal vez lo que más me ha gustado es la posibilidad de crear políticas usando filtros. Por ejemplo la siguiente captura tan solo analizará aquellas vulnerabilidades para las que haya exploit:

Otros cambios a tener en cuenta incluyen la modificación del XML con los resultados, algunos aspectos de diseño del interfaz y mejoras para visualizar resultados durante la ejecución de un análisis.

Podéis consultar un documento de Tenable con algún detalle más en la siguiente URL: http://static.tenable.com/documentation/WhatIsNewNessus5.pdf

Leer más...

Configurar OpenVAS en Backtrack 5 R1

OpenVas es framework para el análisis de vulnerabilidades que nace con el cambio de licencia de Nessus.

Viene integrado en Backtrack y pese a que es sencillo configurarlo hay que seguir algunos pasos un poco engorrosos.

Lo más importante es recordar que el script: /pentest/miscellaneous/openvas/openvas-check-setup.sh se puede ejecutar para identificar problemas hasta que la instalación este completa.

root@bt:~# /pentest/miscellaneous/openvas/openvas-check-setup.sh 
openvas-check-setup 2.0.6
  Test completeness and readiness of OpenVAS-4

  Please report us any non-detected problems and
  help us to improve this check routine:
  http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

  Send us the log-file (/tmp/openvas-check-setup.log) to help analyze the problem.

  Use the parameter --server to skip checks for client tools
  like GSD and OpenVAS-CLI.

Step 1: Checking OpenVAS Scanner ... 
        OK: OpenVAS Scanner is present in version 3.2.3.
        ERROR: No CA certificate file of OpenVAS Scanner found.
        FIX: Run 'openvas-mkcert'.

 ERROR: Your OpenVAS-4 installation is not yet complete!

Please follow the instructions marked with FIX above and run this
script again.

If you think this result is wrong, please report your observation
and help us to improve this check routine:
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss
Please attach the log-file (/tmp/openvas-check-setup.log) to help us analyze the problem.

Así que tal y como dice el error, hay que crear el certificado para el scanner de openvas:

root@bt:~# openvas-mkcert
/usr/local/var/lib/openvas/private/CA created
/usr/local/var/lib/openvas/CA created
-------------------------------------------------------------------------------
   Creation of the OpenVAS SSL Certificate
-------------------------------------------------------------------------------
This script will now ask you the relevant information to create the SSL certificate 
of OpenVAS. Note that this information will *NOT* be sent to anybody (everything stays
local), but anyone with the ability to connect to your OpenVAS daemon will be able to
 retrieve this information.

CA certificate life time in days [1460]: 
Server certificate life time in days [365]: 
Your country (two letter code) [DE]: ES
Your state or province name [none]: 
Your location (e.g. town) [Berlin]: Madrid
Your organization [OpenVAS Users United]: 
-------------------------------------------------------------------------------
   Creation of the OpenVAS SSL Certificate
-------------------------------------------------------------------------------
Congratulations. Your server certificate was properly created.

The following files were created:
. Certification authority:
   Certificate = /usr/local/var/lib/openvas/CA/cacert.pem
   Private key = /usr/local/var/lib/openvas/private/CA/cakey.pem
. OpenVAS Server : 
    Certificate = /usr/local/var/lib/openvas/CA/servercert.pem
    Private key = /usr/local/var/lib/openvas/private/CA/serverkey.pem
Press [ENTER] to exit

Si se vuelve a ejecutar el script de chequeo, mostrará otro error:

root@bt:~# /pentest/miscellaneous/openvas/openvas-check-setup.sh 
[...skip...]
Step 1: Checking OpenVAS Scanner ... 
  OK: OpenVAS Scanner is present in version 3.2.3.
  OK: OpenVAS Scanner CA Certificate is present as /usr/local/var/lib/openvas/CA/cacert.pem
  ERROR: The NVT collection is very small.
  FIX: Run a synchronization script like openvas-nvt-sync or greenbone-nvt-sync.

 ERROR: Your OpenVAS-4 installation is not yet complete!

[...skip...]

Por lo que hay que actualizar los plugins NVT de Openvas con el comando:

root@bt:~# openvas-nvt-sync
[i] This script synchronizes an NVT collection with the 'OpenVAS NVT Feed'.
[i] The 'OpenVAS NVT Feed' is provided by 'The OpenVAS Project'.
[i] Online information about this feed: 'http://www.openvas.org/openvas-nvt-feed.html'.
[i] NVT dir: /usr/local/var/lib/openvas/plugins
[i] rsync not is recommended for the initial sync. Falling back on http.
[i] Will use wget
[i] Using GNU wget: /usr/bin/wget
[i] Configured NVT http feed: http://www.openvas.org/openvas-nvt-feed-current.tar.bz2
[i] Downloading to: /tmp/openvas-nvt-sync.n8O2kCls0R/openvas-feed-2011-11-19-1796.tar.bz2
--2011-11-19 12:01:13--  http://www.openvas.org/openvas-nvt-feed-current.tar.bz2
Resolving www.openvas.org... 78.47.251.62
Connecting to www.openvas.org|78.47.251.62|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9769693 (9.3M) [application/x-tar]
[...skip...]

Para evitar seguir copiando errores, lo siguiente es crear un certificado de cliente:

root@bt:~# openvas-mkcert-client -n om –i
Generating RSA private key, 1024 bit long modulus
......................................++++++
................++++++
e is 65537 (0x10001)
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [DE]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:
Email Address []:
Using configuration from /tmp/openvas-mkcert-client.2185/stdC.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'DE'
localityName          :PRINTABLE:'Berlin'
commonName            :PRINTABLE:'om'
Certificate is to be certified until Nov 18 16:46:51 2012 GMT (365 days)

Write out database with 1 new entries
Data Base Updated
User om added to OpenVAS.
Your client certificates are in /tmp/openvas-mkcert-client.2185 .
You will have to copy them by hand.

Crear nuevamente la base de datos del manager:

root@bt:~# openvasmd –-rebuild

Arrancar el servicio, que carga los plugins y tarda bastante:

root@bt:~# openvassd
All plugins loaded                                   

Volver a recrear la base de datos:

root@bt:~#  touch /usr/local/var/lib/openvas/mgr/tasks.db
root@bt:~# openvasmd –-backup
root@bt:~# openvasmd –-rebuild

Crear el usuario administrador con nombre de usuario "openvasadmin" y un usuario normal.

root@bt:~# openvasad -c ‘add_user’ -n openvasadmin -r Admin
Enter password: 
ad   main:MESSAGE:32334:2011-11-19 12h14.10 EST: No rules file provided, the new user 
will have no restrictions.
ad   main:MESSAGE:32334:2011-11-19 12h14.10 EST: User openvasadm has been successfully
created.
root@bt:~# openvas-adduser
Using /var/tmp as a temporary file holder.
Add a new openvassd user
---------------------------------
Login : openvas
Authentication (pass/cert) [pass] : 
Login password : 
Login password (again) : 

User rules
---------------
openvassd has a rules system which allows you to restrict the hosts that openvas 
has the right to test.
For instance, you may want him to be able to scan his own host only.
Please see the openvas-adduser(8) man page for the rules syntax.
Enter the rules for this user, and hit ctrl-D once you are done:
(the user can have an empty rules set)

Login             : openvas
Password          : ***********
Rules             : 
Is that ok? (y/n) [y] y
user added.

Arrancar el manager, administrador, y el servicio web para el cliente:

root@bt:~# openvasmd -p 9390 -a 127.0.0.1
root@bt:~# openvasad -a 127.0.0.1 -p 9393
root@bt:~# gsad -–http-only -–listen=127.0.0.1 -p 9392

Para que finalmente el servicio sea accedido mediante web en la dirección: http://localhost:9302

En resumen:

openvas-mkcert
openvas-nvt-sync
openvas-mkcert-client -n om –i
openvasmd –-rebuild
openvassd
touch /usr/local/var/lib/openvas/mgr/tasks.db
openvasmd –-backup
openvasmd –-rebuild
openvasad -c ‘add_user’ -n openvasadmin -r Admin
openvas-adduser
openvasmd -p 9390 -a 127.0.0.1
openvasad -a 127.0.0.1 -p 9393
gsad -–http-only -–listen=127.0.0.1 -p 9392

Leer más...