Post on 31-Dec-2015
OpenVAS es un sistema de software
libre con licencia GPL para la com-
probación de vulnerabilidades, con
diversos servicios y componentes que
podemos desplegar de varios modos para
lograr un entorno adaptado a nuestra red.
OpenVAS Manager es un servicio central
para controlar el framework OpenVAS que
se comunica con los componentes de esca-
neo mediante el protocolo OMP (OpenVAS
Management Protocol), basado en XML, y
almacena los resultados de los escaneos en
una base de datos SQLite.
OpenVAS [1] está actualmente siendo
modificado y acaba de llegar a la versión 4.
En este artículo presentamos el escáner y
echamos un ojo al sistema de clientes y sus
vulnerabilidades. También veremos algu-
nos consejos para la implantación de
OpenVAS e incluso cómo escribir nuestros
propios plugins.
Nuevas FuncionalidadesEl framework OpenVAS ha cambiado bas-
tante con respecto a la versión 3, pero sigue
siendo compatible con las herramientas y
protocolos de la versión 2. Aparte del
nuevo OMP, que ayuda a gestionar los pro-
cesos de escaneo, se ha añadido el proto-
colo OAP (OpenVAS Administration Proto-
col) para la administración de clientes y
nuevos servicios. OpenVAS Manager ges-
tiona la comunicación dentro del frame-
work y almacena los datos relativos a los
escaneos en su base de datos SQLite
interna, descargando así los nuevos clien-
tes OMP y ayudando a organizar el acceso
a los datos de escaneo almacenados. La
comunicación con el escáner, openvassd,
aún se apoya en el protocolo OTP (Open-
VAS Transfer Protocol). El servicio Open-
VAS Administrator proporciona al adminis-
trador un medio con el que gestionar usua-
rios y certificados.
Ahora también existen nuevos clientes
de escaneo, aparte del cliente de OpenVAS
basado en Gtk que ya había. La aplicación
de servidor Greenbone Security Assistant
(GSA) [2] se ejecuta en el navegador. Por
otro lado, Greenbone Security Desktop
(GSD, Figura 1) [3], que se ejecuta en Win-
dows (gracias a Qt), o la herramienta de
línea de comandos omp, completan la
selección de opciones libres.
Los clientes de escritorio, que estaban
incompletos en la versión 3, cubren actual-
mente la totalidad de las funcionalidades
de OpenVAS. En producción, el clásico
cliente de OpenVAS sigue siendo más sen-
cillo y rápido. La estructura jerárquica del
cliente, así como su capacidad para organi-
zar los objetivos del escaneo en Targets y
Scopes son sus puntos más fuertes. Tras
definir las propiedades estándar del esca-
neo, se pueden asignar las propiedades
desde el objetivo a un scope para modifi-
carlas luego según se necesite.
Esta característica simplifica y agiliza el
proceso de diseño y ejecución de nuevos
escaneos, siendo tan sencillo como alternar
entre los distintos objetivos y resultados.
Definir un escaneo en los clientes web o de
escritorio es bastante menos fluido en com-
paración. El proceso comienza por la defi-
nición de Scan Configs, Credentials, Scan
Targets y Tasks.
Lo que en principio promete ser un con-
junto de módulos reusables, acaba convir-
tiéndose en un obstáculo a la hora de
modificar las configuraciones más tarde.
Por ejemplo, no se pueden modificar los
objetivos del escaneo retrospectivamente,
ni tampoco se pueden reemplazar los obje-
tivos de las tareas de escaneo, siendo nece-
sario crear nuevas entradas. Los nuevos
clientes no soportan actualmente el uso de
listados basados en archivos para definir
DESARROLLO • OpenVAS 4
44 Número 79 W W W . L I N U X - M A G A Z I N E . E S
Nos ponemos manos a la obra con OpenVAS 4
MisiónOpenVAS
El proyecto OpenVAS ya ha publicado la versión 4 del sistema OpenVAS de comprobación de vulnerabilida-
des. Razón de más para ver qué hay de nuevo eliminarlo y cómo podemos crear nuestra propia solución de
escaneo. POR STEFAN SCHWARZ
No
reb
bo
, 123rf.c
om
los objetivos. Dicho de otro modo, si desea-
mos escanear cientos de hosts virtuales
con el fin de determinar la ubicación de un
servidor web vulnerable, lo mejor es usar
el cliente clásico, al que sólo tenemos que
pasarle un archivo de texto con la lista de
hosts.
ComencemosAntes de empezar a usar VAS, conviene
familiarizarse con los formatos de los datos
de OpenVAS y limpiar las ubicaciones
donde se almacenarán los datos para estar
seguros de tener la configuración correcta
para las preferencias más importantes. Así
también se evitan errores a la hora de
almacenar información confidencial. Si se
está utilizando el cliente de OpenVAS clá-
sico, la estructura jerarquizada de los obje-
tivos resulta de gran ayuda, ya que se
puede aplicar parte de la configuración a
otros objetivos.
Podemos modificar la jerarquía de objeti-
vos a posteriori simplemente moviendo los
directorios desde el sistema de archivos. El
archivo .openvasrc es particularmente inte-
resante para cada objetivo del escaneo, ya
que todas las configuraciones del mismo
residen allí, incluidas aquellas opciones
que no se pueden definir en los clientes.
Por ejemplo, con log_whole_attack = no
deshabilitamos todos los registros de logs
en el servidor de escaneo centralizado.
En las Figuras 2 y 3 se muestran las pre-
ferencias globales, que conviene compro-
bar antes de pasar a escanear. Por ejemplo,
si se están evaluando servidores web con-
viene habilitar las peticiones inversas para
evitar que se agrupen todos los resultados
bajo una misma dirección IP compartida.
Inicialmente, la opción Safe checks es
imprescindible, puesto que los escaneos de
DoS no deberían estar entre las primeras
pruebas a realizar; por desgracia, esta
opción viene deshabilitada por defecto.
También querremos reducir el número de
hosts a escanear en paralelo, así como el
número de pruebas a completar para evitar
cargas innecesarias en la red y en los obje-
tivos.
Si nos ponemos de acuerdo con el admi-
nistrador de la red, podemos evitar que
algún cortafuegos o algún sistema de IDP
provoque resultados no válidos. Inicial-
mente al menos, el OpenVAS TCP scanner
no es mala opción; si usamos nmap como
escáner de red, debemos hacer la prueba
en un proceso aparte para luego aplicar los
resultados.
Comenzamos comprobando la informa-
ción general en general/ tcp, especialmente
los parámetros añadidos para el escaneo,
como la configuración, la duración, etc.
VulnerabilidadesAunque el sistema objetivo esté completa-
mente actualizado, el primer escaneo suele
revelar decenas de vulnerabilidades críticas,
casi siempre debidas a un uso incorrecto o a
programas de los plugins de escaneo que no
toleran bien los fallos. Por ejemplo, los esca-
neos de IT-Grundschutz [9] sólo devuelven
resultados significativos si pueden acceder
al sistema objetivo internamente, siendo
necesario acreditarse. Si no hacemos login,
los tests fallan y, por desgracia, devuelven
un estado que se refleja en la cantidad de
agujeros de seguridad críticos encontrados.
Dicho de otro modo, debemos deshabili-
tar estos plugins o proporcionar las creden-
ciales de acceso antes de ejecutar la
prueba. Las estadísticas nos pueden llevar
a engaño, ya que OpenVAS aún no está
preparado para la realización de pruebas
completamente automatizadas.
Falsos PositivosOtro problema recurrente es que los plu-
gins suelen identificar los que ellos creen
que son números de versión obsoletos, casi
siempre en sistemas con backports [11]. En
este tipo de servicios se suelen incorporar
las soluciones para vulnerabilidades descu-
biertas en versiones antiguas pero soporta-
das oficialmente. Pero el backport, a pesar
de estar al día en materia de parches de
seguridad, no tiene por qué incrementar el
número de versión, lo que puede confundir
a OpenVAS. Un escáner de seguridad no
comprueba las vulnerabilidades, sino que
busca las versiones que se sabe que son
vulnerables.
Ubuntu 8.04 server es un buen ejemplo:
OpenVAS clasifica como crítica la versión
Los plugins definen la interfaz cliente de
OpenVAS y se establecen en Prefs, bajo la
opción Options. Conviene comprobarlas
después de actualizar o cargar plugins. Por
ejemplo, podemos habilitar las comproba-
ciones en línea con la German Federal
Office for Information Security standards
for IT security (BSI IT-Grundschutz) [9] con
Compliance Tests (Figura 3). Esta forma de
configurar los plugins hace que al final aca-
bemos desarrollando los nuestros propios.
Un Objetivo AdecuadoEl objetivo más obvio para empezar (la
selección de Target) tras instalar el cliente o
el servidor es localhost. Ya se conoce la
configuración de la máquina y se dispone
de los permisos necesarios para verificar
las vulnerabilidades encontradas y repetir
la prueba. Si el cliente y el servidor se eje-
cutan en sistemas diferentes, podemos
coger como objetivo el sistema cliente pro-
pio. Aquí es preciso tener en cuenta la red
que conecta las dos máquinas. También se
puede instalar una máquina virtual para
las pruebas (por ejemplo con VirtualBox
[10]), que permita modificarla fácilmente y
guardar capturas de sus distintos estados.
Después de escoger los plugins (hay más
de 21000 en estos momentos), ya podemos
empezar con el primer escaneo. Comenza-
remos simulando ser completamente extra-
ños al sistema, es decir, sin proporcionar
las credenciales de acceso para el sistema
objetivo, igual que si fuéramos unos extra-
ños. Dependiendo de los puertos abiertos y
los servicios activos, el escaneo puede lle-
var desde un par de minutos hasta varias
horas, aunque podemos interrumpir el pro-
ceso en cualquier momento. Una vez com-
pletado o cancelado, se nos presenta un
informe con los detalles del objetivo en
base a los puertos o servicios detectados.
Bajo la pestaña Report del cliente de
OpenVAS se muestran tres tipos de datos
(Figura 4): Security
Hole indica las poten-
ciales vulnerabilida-
des halladas durante
el escaneo; Security
Note contiene infor-
mación útil sobre el
puerto para la eva-
luación del sistema;
y por último, Log
Message muestra la
información devuelta
por el plugin, que
puede ser muy útil.
OpenVAS 4 • DESARROLLO
45Número 79W W W . L I N U X - M A G A Z I N E . E S
Figura 1: El cliente de escritorio Greenbone Security Desktop está
hecho con Qt.
y False Posi-
tive. Los
valores se
almacenan
globalmente
en el archivo
severity_ove-
rrides.xml (Tabla 1), desde donde podre-
mos modificarlos más tarde (Listado 2 y
Figura 5) y aplicarlos a los resultados de los
informes.
Los overrides normalmente tienen que
ver con el host mostrado en el informe
(192.168.178.46 en este ejemplo). Para
ampliar a un grupo de hosts, o a todos los
hosts, sólo hay que cambiar la entrada
host= a 192.168.178.*. Pero debemos
tener cuidado: el cambio afectará a la regla
al completo y hará que OpenVAS clasifique
como falsos positivos incluso las vulnerabi-
lides verdaderas. Es decir, que se deben
comprobar las reglas de override frecuente-
mente.
VistasOpenVAS distingue varias vistas de un
objetivo de escaneo:
1. Desde Internet.
2. Desde la red corporativa interna, posi-
blemente desde varias zonas de seguri-
dad diferenciadas.
3. Desde el interior del propio objetivo tras
la debida acreditación.
Las vistas 1 y 2 sólo difieren con respecto
a la posición ocupada por el escáner de
OpenVAS; desde el punto de vista del
cliente del escaneo no hay ninguna diferen-
cia. El cliente de OpenVAS puede abrir
conexiones con un número determinado
de escáneres y usarlos en paralelo. Aquí
entran en juego las políticas de seguridad
de cada red implicada. Incluso cuando
escaneamos nuestro propio servidor, si lo
hacemos a través de una zona pública
puede que estemos infringiendo las nor-
mas.
Dentro del ObjetivoLos escaneos de OpenVAS que tienen la
capacidad de acreditarse en el host objetivo
y analizar el host desde el interior devuel-
ven resultados más precisos. Nunca se
debe acceder como root; con una cuenta
sin privilegios es suficiente para revelar
información acerca del sistema y sus vul-
nerabilidades.
Debemos proteger los pares de usuario/
contraseña de los sistemas objetivo, pero
por desgracia, OpenVAS no lo hace muy
bien; guarda las contraseñas en texto plano
en su base de datos SQLite, pudiendo acce-
der a ellas al menos el administrador del
servidor de escaneos, que no tiene por qué
ser necesariamente el administrador de
todos los sistemas objetivo. Con un simple
comando SQL, cualquiera que tenga
acceso a la base de datos podrá ver la infor-
mación confidencial:
sqlite3 tasks.db U
‘select * from lsc_credentials;’
No bastaría con cifrar las credenciales
antes de almacenarlas, porque los datos
de OpenSSH que utiliza, pero si investiga-
mos un poco sobre la versión y el estado de
los parches, podremos comprobar que ssh-
2.0-openssh_4.7p1debian-8ubuntu1.2 está
actualizado y cuenta con todos los parches
de seguridad [12]. Los plugins sacan con-
clusiones erróneas por pequeños detalles
como éste, obligándonos a borrar estos
mensajes a mano.
Para reducir el número de falsos positi-
vos en general tenemos la opción Report
paranoia en Global variable settings,
donde podemos escoger desde Normal
hasta Avoid false alarms. Pero claro, esta
opción sólo tiene efecto sobre los plugins
que efectivamente la evalúan, que son
sólo 130 de los más de 21000 existentes.
Por este motivo, quizá sea mejor no arries-
garse a pasar por alto alguna vulnerabili-
dad real.
Para modificar el grado de criticidad de
las vulnerabilidades identificadas por
OpenVAS podemos usar el mecanismo de
severity override, reclasificando el mensaje
generado por el escáner entre Security Hole
DESARROLLO • OpenVAS 4
46 Número 79 W W W . L I N U X - M A G A Z I N E . E S
Los nombres de los componentes en OpenVAS 4 pueden resul-
tar confusos en cierto grado. Por ejemplo, el número de ver-
sión sólo tiene relación con las librerías (actualmente la 4.0.5);
el escáner (3.2.4) y el manager (2.0.4) usan otros números [4].
Los repositorios ofrecidos por la mayoría de las distribuciones
de Linux actuales parece que tienen todos binarios antiguos;
Ubuntu 11.04 aún ofrece OpenVAS 2. Sin embargo, la comuni-
dad ofrece paquetes más recientes; por ejemplo, el servicio
openSUSE Build Service [5] tiene paquetes para Debian y
Ubuntu.
Los paquetes de OpenVAS 4 ya no incluyen el cliente nativo
para OpenVAS, que muchos usuarios apreciaban porque era
fácil de usar y sus datos de configuración eran locales. Si se
usa el gestor de paquetes para la instalación, probablemente
se acabe con una versión obsoleta. Además de adquiriendo un
dispositivo de escaneo con soporte completo desde Green-
bone [6] con la versión más actual, los usuarios interesados
pueden descargar los últimos fuentes desde el repositorio
Subversion del proyecto [7] y compilar las herramientas que
necesiten.
Quien opte por trabajar con la última versión, deberá obtener
el código a través de Subversion. La compilación del paquete
completo es bastante sencilla. Incluso he escrito un Makefile
para ello y lo he probado en Ubuntu [8]. El archivo se encarga
de la descarga y las actualizaciones, instala los paquetes nece-
sarios y crea e instala las versiones actuales y las actualizacio-
nes (Listado 1). Una vez llevados a cabo estos pasos, make upactualizará el software cuando queramos.
Versiones, Paquetes y Componentes
01 make depend # instala los paquetes necesarios02 make # crea e instala OpenVAS03 make initial # crea los certificados, la base de datos, etc.04 make start # inicia en segundo plano los procesos necesarios
Listado 1: Compilación y Ejecución deOpenVAS
Figura 2: Configuraciones globales importan-
tes en el cliente de OpenVAS.
Figura 3: Preferencias para plugins indivi-
duales.
47Número 79W W W . L I N U X - M A G A Z I N E . E S
hay que descrifrarlos durante el escaneo y,
para ello, hay que guardar la clave en
alguna parte de la aplicación.
El cliente clásico de OpenVAS presenta
cierta debilidad aquí, ya que guarda las cre-
denciales de acceso en plano en su archivo
de configuración local, .openvasrc (Tabla
1). Aunque no es nada recomendable, la
alternativa, que es almacenar la clave pri-
vada, es igual de aterradora. Una solución
factible sería guardar los datos cifrados con
una clave que no se guarde en la aplica-
ción, o incluso añadir soporte para smart-
card. Esta debilidad supone un importante
vector para el desarrollo de posteriores ver-
siones de OpenVAS.
Claves de SeguridadEl uso de claves asimétricas proporciona
una solución para la distribución de cre-
denciales sobre múltiples sistemas, al
tiempo que se mitiga el problema de un
repositorio centralizado. La clave pública
residiría en el sistema objetivo. La cuenta
debería tener deshabilitado el acceso
mediante contraseña para que la única
forma de acceder a ella sea usando la clave
privada. Como sólo es posible almacenar la
frase de paso en texto plano, la mayoría de
los administradores querrán evitar este
método. Sólo se puede proteger la clave
privada almacenándola en un medio
seguro (como por ejemplo un pendrive
USB) o cifrándola a su vez con TrueCrypt,
PGP o Encrypt-FS.
Lo importante aquí es que el cliente de
OpenVAS sólo modifique la configuración
de las credenciales de acceso al escanear el
objetivo. Incluso cuando el cliente elimina
las credenciales de acceso antes de cerrar el
programa, éstas siguen estando disponibles
en el archivo de configuración. El adminis-
trador del sistema podrá acceder, por tanto,
a pesar de almacenarse la clave central-
mente
Dado que la correspondiente clave
pública se encuentra en el sistema obje-
tivo, en ~./ .ssh/ authorized_keys en el caso
de Linux, el administrador puede hacerse
cargo del proceso él mismo, ya que aunque
se esté en posesión tanto de la clave pri-
vada como de la pública, el acceso al sis-
tema objetivo sigue estando restringido. Un
plugin especial de OpenVAS podría restrin-
gir el acceso a un scan determinado
moviendo de sitio el archivo de claves des-
pués del escaneo con este comando:
pread(cmd: “/bin/mv”, U
argv: make_list (“mv”,U
“~/.ssh/authorized_keys”, U
“~/.ssh/authorized_keys.bak”));
que viene a ser un acceso de un solo uso
para el escaneo.
El proceso de creación de los pares de
claves es similar al que se lleva a cabo con
OpenSSH [14]. Sin embargo, al contrario
de lo que se dice en la documentación de
OpenVAS, actualmente sólo funciona con
claves DSA, pero no con RSA [15]. Es decir,
que no es buena idea usar las herramientas
de creación del paquete interno (en Extras
| LSC Credentials Manager). El método sólo
necesita la clave pública de la cuenta de
destino (por ejemplo sshovas) en ~/ .ssh/
authorized_keys. Una vez añadida, se
debería poder acceder a los sistemas que se
escanearán internamente haciendo:
ssh -i U
directorio-con-las-claves/U
sshovas_dsa.p8 U
sshovas@objetivo
Figura 4: Informes de escaneos.
Figura 5: Override para un falso positivo.
01 <severity_override name=”ITGrundschutz M5.064:Secure Shell”
02 host=”192.168.178.46”03 port=”general/IT Grund-
schutz”04 OID=”1.3.6.1.4.1.25623.1.0.
895064”05 severity_from=”Security
Hole”06 severity_to=”False Positive”07 active=”true”>08 <reason>09 Backport10 </reason>11 </severity_override>
Listado 2: Override para Nivel de Criticidad
Tabla 1: Rutas a los Archivos de Configuración
Algunos proveedores de servicios de
hosting, conscientes de los proble-
mas derivados de los escaneos por
red, han desarrollado estrategias pre-
ventivas (a veces muy diferentes).
Los principales proveedores identifi-
can los típicos patrones de escaneo
en el tráfico de red de manera bas-
tante fiable y desconectan automáti-
camente el objetivo del escaneo
durante un breve espacio de tiempo.
La experiencia nos dice que estas
populares herramientas aún arrojan
buenos resultados al desplegarlas en
Internet [13]. OpenVAS da a elegir
entre varios escáneres de puertos,
configurables desde las preferencias
de la aplicación. También se puede
usar cualquier escáner de puertos
externo para pasarle los resultados a
OpenVAS. De este modo se consigue
que los escaneos de puertos conoci-
dos sobre los servidores web de
nuestras empresas sean superfluos,
además de que es posible deshabili-
tarlos definiendo opciones estáticas
predeterminadas en OpenVAS.
Escaneos a Proveedores
Expediente Significado
~/ .openvas Directorio para los archivos de configuración de los obje-
tivos de los escaneos.
~/ .openvasrc Configuración global.
~/ .openvas/ Scope/ Target Todas las configuraciones (.openvasrc) específicas de este
objetivo del escaneo y los resultados de los escaneos
(Report_date). La primera vez que creamos un objetivo,
OpenVAS copia la configuración de Scope a Target.
~/ .openvas/ severity_overrides.xml El archivo XML con las definiciones de los overrides, que
inluyan sobre los resultados del escaneo al evaluar el
efecto.
OpenVAS 4 • DESARROLLO
bales de Subversion en /etc/ subversion en
busca de directivas store-passwords = no o
store-plain-text-passwords = no. Estas
directivas no deberían estar deshabilitadas,
como por desgracia ocurre con la instala-
ción predeterminada.
Los detalles del plugin en la cabecera
son de carácter obligatorio (la descripción),
y se pueden buscar desde los clientes (Lis-
tado 3), permitiendo al usuario seleccionar
los plugins relevantes para el escaneo y
configurar las preferencias. Las instruccio-
nes en script_dependencies garantizan que
OpenVAS ejecute los plugins necesarios y
acceda a los resultados y las tareas previas
(en este caso, un login de SSH y el listado
de paquetes instalados).
El especificar un ID único (script_id) pro-
vocará problemas inicialmente, ya que
OpenVAS no cuenta actualmente con nin-
gún esquema de numeración única. Nin-
gún plugin hace uso en estos momentos
del nuevo OpenVAS ID, script_oid, introdu-
cido en la versión 1.0.3; en vez de eso,
siguen usando una numeración simple con
script_id. Aún así, OpenVAS convierte
internamente el antiguo esquema al nuevo
(Figura 6).
Podemos usar Awk para encontrar un
rango numérico válido para nuestros pro-
pios plugins:
find . -type f U
-print | xargs U
fgrep script_id | U
awk -F ‘[()]’ U
‘{print $2}’ | sort -n
<I>[...]<I>
2000201
9000001
9999991
9999992
Tras ejecutar este comando, decidí asignar
al ejemplo el número 9999001. Con
script_add_preference se crea un nuevo
checkbox bajo las preferencias del cliente
de OpenVAS para habilitar el nuevo plugin.
El Sistema ObjetivoLa siguiente parte del plugin inicia una
conexión protegida por SSH con el sistema
objetivo. Por desgracia, el intercambio de
información genérica no funciona en las
pruebas locales porque los plugins son
incapaces de comunicarse a través de la
KB (knowledge base) interna. Dicho de
otro modo, para las pruebas locales se ha
de configurar la conexión SSH explícita-
mente.
Para comprobarlo, habilitamos el plugin
SSH Authorization. Después del escaneo,
deberíamos ver en SSH | Security Note la
verificación de que las comprobaciones de
seguridad están habilitadas. Ya que algu-
nos plugins han sido desarrollados de un
modo dependiente del lenguaje en que
están programados (por ejemplo, el plugin
para escanear VMware sólo reconoce la
cadena command not found), lo más lógico
es usar un entorno en inglés, por ejemplo,
definiendo la variable LANG=us en el
archivo ~/ .profile.
Escaneos de SeguridadPersonalizadosAunque OpenVAS cuenta actualmente con
21000 plugins, puede que necesitemos
desarrollar uno propio para cumplir las
políticas corporativas. Para ello deberemos
utilizar NASL (Nessus Attack Scripting Lan-
guage). Existen varios manuales disponi-
bles con los que aprender este lenguaje
[16] [17], y además se puede usar algún
plugin existente como plantilla. En un artí-
culo anterior de Linux Magazine [18] se
describe la estructura de un plugin NASL.
El código fuente del ejemplo de programa-
ción mostrado aquí está disponible para
descarga [8] y con traducción al castellano
[19].
El ejemplo implementa un requisito de
seguridad que previene el almacenamiento
de contraseñas en texto claro en servidores
de Subversion [20]. El script busca las con-
figuraciones de clientes que no prevengan
explícitamente el almacenamiento de con-
traseñas en texto claro. Para ello com-
prueba los archivos de configuración glo-
DESARROLLO • OpenVAS 4
48 Número 79 W W W . L I N U X - M A G A Z I N E . E S
Figura 6: Propiedades de plugin del cliente de
OpenVAS.
01 if(description)02 {03 script_id(9999001);04 script_version(“$Revision: 7732 $”);05 script_tag(name:”risk_factor”, value:”None”);06 script_name(“UniBwM 1: Plaintext passwords”);07 desc =”08 Overview : This script tests against plaintext pass-
words for subversion09 Risk factor : None”;10 11 script_description(desc);12 script_summary(“Plaintext passwords”);13 script_category(ACT_GATHER_INFO);14 script_copyright(“Copyright (C) 2010 Stefan
Schwarz”);15 script_family(“General”);16 script_dependencies(“ssh_authorization.nasl”);17 if(description)18 {19 script_id(9999001);
20 script_version(“$Revision: 289 $”);21 script_tag(name:”risk_factor”, value:”None”);22 script_name(“UniBwM 1: Plaintext passwords”);23 desc =”24 Overview : This script tests against plaintext pass-
words for subversion.25 Risk factor : None”;26 27 script_description(desc);28 script_summary(“Plaintext passwords”);29 script_category(ACT_GATHER_INFO);30 script_copyright(“Copyright (C) 2010 Stefan
Schwarz”);31 script_family(“General”);32
script_dependencies(“ssh_authorization.nasl”,”gath-erâfl’packageâfl’list.nasl”);
33 script_add_preference(name:”Launch this script”,type:”checkbox”, value:”yes”);
34 exit(0);35 }
Listado 3: Fragmento de unibwm1.nasl
No se puede usar la conexión existente
vía ssh-authorization.nasl, porque
ssh_login_or_reuse_connection no devolve-
ría un socket válido. Por desgracia, hay que
guardar en claro los datos de la conexión, y
eliminarlos al terminar el plugin. Una vez
más, se puede evaluar el valor de la opción
Launch this script.
Con la finalidad de indagar en el sistema
objetivo, el plugin puede ejecutar coman-
dos de terminal arbitrarios mediante
ssh_cmd para luego analizar su salida.
También disponemos de funciones inter-
nas, como por ejemplo egrep [16]. La
salida del plugin – es decir, la clasificación
de vulnerabilidades – la generan
security_note, security_warning y secu-
rity_hole.
Los plugins NASL se guardan o bien en
el directorio Directorio-de-la-instalación/
lib/ openvas/ plugins o en
cualquier subdirectorio
de éste. Es mejor que la
primera comprobación
de la sintaxis y la lógica
de nuestros plugins la
hagamos fuera del
entorno de OpenVAS. El
comando
openvas-nasl -X U
-i .. unibwm1.nasl
se encarga de ello. Aquí hemos tenido que
añadir la opción -X, porque el plugin no
está firmado. El parámetro -i apunta el
script a los scripts dependientes ubicados
en el directorio padre. Si la prueba finaliza
con éxito, ya podemos incluirla en los
clientes. Para ello debemos actualizar el
demonio openvassd enviándole una señal
kill -HUP. A partir de ese momento, cual-
quier cliente que abra una nueva conexión
con el escáner recibirá la actualización con
el plugin.
Tras seleccionar el plugin y escanear el
sistema objetivo, los resultados aparecerán
en el informe (Figura 7). �
OpenVAS 4 • DESARROLLO
49Número 79W W W . L I N U X - M A G A Z I N E . E S
[1] Software de OpenVAS – Clientes, ser-
vicios y protocolos: http:// www. openvas. org/ about-software. html
[2] Greenbone: Gestión de vulnerabili-
dades con el GSM: http:// greenbone. net/ learningcenter/ vm_with_gsm. html
[3] Greenbone Desktop Suite para Win-
dows: http:// greenbone. net/ technology/ gds. html
[4] Paquetes de instalación de Open-
VAS: http:// www. openvas. org/ install-packages. html
[5] Open Suse Build Service: http:// de. opensuse. org/ Build_Service
[6] Greenbone Networks:
http:// greenbone. net
[7] Repositorio Subversion de Open-
VAS: https:// svn. wald. intevation. org/ svn/ openvas/ trunk/
[8] Makefile y código fuente para la
compilación mostrada en este artí-
culo: https:// subversion. unibw. de/ public/ openvas
[9] IT-Grundschutz: https:// www. bsi. bund. de/ DE/ Themen/ ITGrundschutz/ itgrundschutz_node. html
[10] Virtualbox: http:// www. virtualbox. org
[11] Backports en desarrollo de software:
http:// es. wikipedia. org/ wiki/ Backport
[12] Parcheado de paquetes en Ubuntu
usando OpenSSH como ejemplo:
http:// packages. ubuntu. com/ hardy/ openssh-server
[13] “Nmap: Scanning the Internet”, por
Gordon Lyon (Fyodor), presentación
en la Black Hat y Debconf 2008:
http:// insecure. org/ presentations/ BHDC08/
[14] OpenVAS, “Perform local security
checks”: http:// www. openvas. org/ performing_lsc. html
[15] “SSH errors during scan”, por John
Bradley: http:// wald. intevation. org/ tracker/ index. php?func=detail&aid=1502&group_id=29&atid=220
[16] Manual de referencia para NASL2,
por Micel Arboi: http:// michel. arboi. free. fr/ nasl2ref/ nasl2_reference. pdf
[17] “Writing Nasl Scripts” (resumen),
por Hemil Shah: http:// www. infosecwriters. com/ text_resources/ pdf/ NASL_HShah. pdf
[18] “Analizando” – Linux Magazine
número 59, pg. 64: http:// www. linux-magazine. es/ issue/ 59/ 064-070_OpenVASLM59. pdf
[19] Script unibwm1 con traducción al
castellano: http:// www. linux-magazine. es/ Magazine/ Downloads/ 79/ OpenVAS
[20] Subversion:
http:// subversion. apache. org
RECURSOS
Figura 7: El cliente de OpenVAS mostrando los resultados del
escaneo proporcionados por el plugin de ejemplo.