Open Vas

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



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.


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.


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-



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). �



[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.

Open Vas

Documents

Transcript of Open Vas