Capítulo 4. En busca de vulnerabilidades
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
Después de realizas actividades de reconocimiento y recopilas información sobre tu objetivo, normalmente puedes pasar a identificar puntos de entrada a sistemas remotos. Buscas vulnerabilidades en la organización, que puedan estar abiertas a la explotación. Puedes identificar las vulnerabilidades de varias formas. Basándote en tu reconocimiento, puede que hayas identificado una o dos. Éstas pueden basarse en distintas piezas de información que hayas obtenido a través de fuentes abiertas.
El escaneo de vulnerabilidades es una tarea habitual para los probadores de penetración, pero también para los equipos de seguridad de la información de todo el mundo. Existen muchas herramientas comerciales para buscar vulnerabilidades, pero también algunos escáneres de código abierto. Algunas de las herramientas que proporciona Kali están diseñadas para buscar en distintos tipos de sistemas y plataformas. Otras herramientas, sin embargo, están diseñadas para buscar específicamente vulnerabilidades en dispositivos como routers y conmutadores. Puede que no te sorprenda mucho que también haya escáneres para dispositivos Cisco.
La mayoría de las herramientas que veremos en este capítulo buscarán vulnerabilidades existentes. Éstas son las que se conocen, y su identificación puede hacerse basándose en las interacciones con el sistema o sus aplicaciones. A veces, sin embargo, puede que quieras identificar nuevas vulnerabilidades. Hay herramientas disponibles en Kali que pueden ayudar a generar caídas de aplicaciones, que pueden convertirse en vulnerabilidades, aunque la herramienta no creará exploits asociados. Estas herramientas se denominan comúnmente fuzzers. Se trata de una forma comparativamente fácil de generar un montón de datos malformados que se pueden proporcionar a las aplicaciones para ver cómo se gestionan las entradas.
Pero incluso para empezar este proceso, tienes que entender qué es una vulnerabilidad. Puede ser fácil malinterpretar las vulnerabilidades o confundirlas con otros conceptos. Una noción importante a tener en cuenta es que el hecho de que hayas identificado vulnerabilidades no significa que vayan a ser explotables. Incluso si un exploit coincide con la vulnerabilidad que has encontrado, no significa que el exploit vaya a funcionar. Es difícil subestimar la importancia de esta idea. Las vulnerabilidades no conducen necesariamente a la explotación.
Comprender las vulnerabilidades
Antes de seguir adelante, asegurémonos de que todos estamos de acuerdo en la definición de vulnerabilidad. A veces se confunden con los exploits, y cuando empezamos a hablar de riesgos y amenazas, estos términos pueden resultar realmente confusos. Una vulnerabilidad es una debilidad en un sistema o pieza de software. Esta debilidad es un fallo en la configuración o desarrollo del sistema o software. Si se puede aprovechar esa vulnerabilidad para acceder al sistema o perjudicarlo, es explotable. El proceso para aprovechar esa debilidad es el exploit. Una amenaza es la posibilidad de dañar un sistema o de que éste deje de estar disponible. El riesgo es la intersección de la pérdida y la probabilidad, lo que significa que debe haber una pérdida o daño que sea medible, y una probabilidad de que esa pérdida, o daño, se haga realidad.
Todo esto es bastante abstracto, así que hablemos de ello en términos concretos. Supongamos que alguien deja configurados nombres de usuario y contraseñas por defecto en un sistema. Esto es algo muy habitual, sobre todo en dispositivos como puntos de acceso inalámbricos domésticos o módems por cable. Dejar configurados el nombre de usuario y la contraseña por defecto es una vulnerabilidad porque los nombres de usuario y las contraseñas por defecto se pueden probar fácilmente. El proceso de intentar la contraseña es la explotación de la vulnerabilidad de dejarla en su lugar. Éste es un ejemplo de vulnerabilidad que proviene de una configuración errónea. Las vulnerabilidades que se reconocen con más regularidad son de naturaleza programática y pueden proceder de errores de programación como desbordamientos de búfer.
Si te interesan las vulnerabilidades y estar al tanto del trabajo que supone descubrirlas, puedes suscribirte a listas de correo como Full Disclosure. Puedes obtener detalles sobre las vulnerabilidades que se han encontrado, incluyendo a veces el código de prueba de concepto que puede utilizarse para explotar la vulnerabilidad descubierta. Con tanto software en el mundo, incluidas las aplicaciones web, cada día se descubren muchas vulnerabilidades. Algunas son más triviales que otras, lo que puede hacer que el proceso de mantenerse al día de todo sea todo un reto. El archivo de Full Disclosure está disponible en la página web de SecLists. Puedes suscribirte desde esa página, así como consultar las divulgaciones más antiguas.
Vamos a echar un vistazo a un par de tipos de vulnerabilidades. La primera son las vulnerabilidades locales. Estas vulnerabilidades sólo pueden activarse si estás conectado al sistema con acceso local. Esto no significa que estés sentado en la consola, sólo que tengas algún tipo de acceso interactivo al sistema. Podrías estar accediendo remotamente con un acceso de terminal o de escritorio gráfico. Las vulnerabilidades locales pueden incluir vulnerabilidades de escalada de privilegios, en las que un usuario con permisos normales obtiene privilegios de nivel superior hasta derechos administrativos. Utilizando algo como una escalada de privilegios, los usuarios pueden obtener acceso a recursos a los que de otro modo no deberían tener acceso. También pueden obtener plenos derechos administrativos para realizar tareas como crear usuarios y servicios o acceder a datos sensibles.
La vulnerabilidad opuesta a una vulnerabilidad local es una vulnerabilidad remota. Se trata de una vulnerabilidad que puede activarse sin acceso local. Eso sí, requiere que esté expuesto un servicio al que pueda acceder un atacante. Las vulnerabilidades remotas pueden ser autenticadas o no autenticadas. Si un usuario no autenticado puede explotar una vulnerabilidad para obtener acceso local al sistema, eso sería algo malo. No todas las vulnerabilidades remotas conducen a un acceso local o interactivo a un sistema. Las vulnerabilidades pueden conducir a la denegación de servicio, el compromiso de los datos, el compromiso de la integridad o, posiblemente, el acceso completo e interactivo al sistema.
Los dispositivos de red, como conmutadores y routers, también son propensos a las vulnerabilidades. Si uno de estos dispositivos se viera comprometido, podría ser devastador para la disponibilidad o incluso la confidencialidad de la red. Alguien que tenga acceso a un conmutador o a un router puede redirigir potencialmente el tráfico a dispositivos que, de otro modo, no deberían tenerlo. Kali incluye herramientas que pueden utilizarse para comprobar las vulnerabilidades de los dispositivos de red. Como Cisco es un proveedor destacado, no es de extrañar que la mayoría de las herramientas centradas en las vulnerabilidades de los dispositivos de red se centren en Cisco.
Tipos de vulnerabilidad
El Open Web Application Security Project (OWASP) mantiene una lista de categorías de vulnerabilidades comunes. Periódicamente, el OWASP actualiza una lista de los 10 principales problemas de seguridad de las aplicaciones. Cada año se publica y actualiza software, y todo software contiene errores. Cuando se trata de errores relacionados con la seguridad que crean vulnerabilidades, hay que tener en cuenta algunos comunes. Antes de entrar en cómo buscar estas vulnerabilidades, debes entender un poco qué es cada una de ellas.
Desbordamiento del búfer
El desbordamiento del búfer es una vulnerabilidad común y lo ha sido durante décadas. Aunque algunos lenguajes realizan muchas comprobaciones de los datos que se introducen en el programa, así como de los datos que se pasan en el programa, no todos los lenguajes lo hacen. A veces depende del lenguaje y de cómo crea el ejecutable realizar este tipo de comprobaciones. Sin embargo, algunos lenguajes no realizan este tipo de comprobaciones. Comprobar los datos automáticamente crea sobrecarga, y no todos los lenguajes quieren imponer ese tipo de sobrecarga a los programadores y a los programas. Los lenguajes más recientes son mucho mejores en cuanto a la seguridad de la memoria, como Go, Rust y Swift. El lenguaje de programación C ha sido famoso durante mucho tiempo por no ofrecer protección, o ofrecerla de forma limitada, contra errores de memoria como el desbordamiento del búfer.
Un desbordamiento de búfer se aprovecha de la forma en que se estructuran los datos en la memoria. Cada programa recibe un trozo de memoria. Parte de esa memoria se asigna al código, y otra parte se asigna a los datos sobre los que debe actuar el código. Parte de esa memoria es una estructura de datos llamada pila. Piensa en pasar por la cola de una cafetería o incluso de un bufé. Los platos o bandejas están apilados. Alguien que pasa tira de la parte superior de la pila, pero cuando se reponen los platos o bandejas, los nuevos platos o bandejas se colocan en la parte superior de la pila. Cuando la pila se repone de este modo, puedes pensar en empujar hacia la pila. Sin embargo, cuando se retira el elemento superior, puedes pensar en saltar de la parte superior de la pila.
Los programas funcionan de la misma manera. Los programas suelen estructurarse mediante el uso de funciones. Una función es un segmento de código que realiza una acción o conjunto de acciones claramente definidas. Permite llamar al mismo segmento de código varias veces en varios lugares del programa sin tener que duplicar ese segmento cada vez que se necesita. También permite la ejecución no lineal del código. En lugar de tener un programa largo que se ejecuta en serie, el uso de funciones permite que el programa altere su flujo de ejecución saltando por la memoria. Cuando se llama a las funciones, a menudo se hace con parámetros, es decir, con fragmentos de información. Estos parámetros son los datos sobre los que actúa la función. Cuando se llama a una función, los parámetros y las variables locales de la función se colocan en la pila. Este bloque de datos se denomina marco de pila.
Dentro del marco de la pila no sólo están los datos asociados a la función, sino también la dirección a la que debe volver el programa una vez finalizada la función. Así es como los programas pueden ejecutarse de forma no lineal. La CPU no mantiene todo el flujo del programa. En su lugar, antes de llamar a una función, la dirección dentro del bloque de código donde se ejecutó el programa por última vez también se introduce en la pila.
Los desbordamientos de búfer son posibles porque a estos parámetros se les asigna un espacio de tamaño fijo en la pila. Supongamos que esperas recibir datos del usuario de 10 bytes de longitud. Si el usuario introduce 15 caracteres, eso son 5 bytes más (suponiendo un único byte por carácter, lo que no es necesariamente el caso) que el espacio que se asignó para la variable que se está copiando en ella. Debido a la forma en que está estructurada la pila, todas las variables y datos van antes del puntero de la instrucción de retorno. Los datos que se colocan en el búfer no tienen adónde ir si el lenguaje en tiempo de ejecución no realiza ninguna comprobación previa para truncar los datos. En lugar de eso, se limita a escribir sobre las siguientes direcciones de la memoria. Esto puede provocar que se sobrescriba el puntero de la instrucción de retorno si envías suficientes datos para llegar hasta donde está almacenado el puntero de la instrucción.
La Figura 4-1 muestra un ejemplo simplificado de un marco de pila para una función individual. Algunos elementos que pertenecen al marco de pila no se muestran aquí. En su lugar, nos centramos sólo en las partes que nos interesan. Si la función está leyendo en Var2, el atacante puede introducir más de los 32 caracteres previstos. Una vez superados los 32 caracteres, cualquier dato adicional se escribirá en el espacio de direcciones donde se almacena la dirección de la instrucción de retorno. Cuando la función retorne, ese valor se leerá de la pila, y el programa intentará saltar a esa dirección. Un desbordamiento de búfer intenta que el programa salte a una ubicación conocida por el atacante o bajo su control para ejecutar el código del atacante.
Figura 4-1. Vista simplificada de un marco de pila
Un atacante que ejecuta el código que desea ejecutar, en lugar del código del programa, se denomina ejecución arbitraria de código. El atacante puede controlar el flujo de ejecución del programa, lo que significa que controla lo que hace el programa, incluido el código que ejecuta. Un atacante que pueda hacer eso puede potencialmente obtener acceso a recursos a los que el propietario del programa tiene permisos de acceso. La razón es que los atacantes suelen abrir un shell de comandos en el sistema remoto, razón por la cual el código inyectado en el espacio del búfer se denomina shellcode, porqueejecuta un shell.
Condición racial
Cualquier programa en ejecución no tiene acceso exclusivo al procesador. Mientras un programa está en modo de ejecución, está siendo intercambiado dentro y fuera de la cola del procesador para que el código pueda ejecutarse. Los programas modernos pueden ser multihilo. Tienen múltiples vías de ejecución simultáneas. Estos hilos de ejecución siguen teniendo acceso al mismo espacio de datos, y si tengo dos hilos en ejecución que están alterando ambos una variable, y los hilos de alguna manera se salen de secuencia, pueden surgir problemas en el funcionamiento del programa. El ejemplo 4-1 muestra una pequeña sección de código C. No es así como deberías escribir los programas, por supuesto, ya que hay una variable global y hay mejores formas de proteger los datos compartidos, pero esto es sólo para demostrar un concepto, no una buena forma de escribir código C.
Ejemplo 4-1. Función simple en C
int x;
void update(int y)
{
x = x + y
if (x == 100)
{
printf("we are at the value");
}
}Digamos que tenemos dos hilos ejecutando esa función simultáneamente. La variable global x está siendo incrementada en un valor desconocido por dos hilos distintos. Esta variable es un único lugar en la memoria. En cambio, los dos hilos que ejecutan la función de actualización obtendrán sus propias instancias de la variable y, que se pasa a la función. La variable x, sin embargo, debe ser compartida por las instancias de la función. Una condición de carrera es lo que ocurre cuando dos rutas de ejecución distintas acceden al mismo conjunto de datos al mismo tiempo. Cuando la memoria no está bloqueada, puede producirse una lectura en un momento en que se ha producido una escritura inesperada. Una segunda lectura a la posición de memoria puede recuperar un valor diferente. Todo depende de la sincronización.
En este caso, veamos la línea x = x + y. En primer lugar, hay que leer los valores de las posiciones de memoria a las que se refieren x e y. Digamos que cuando recuperamos el valor de x, tiene el valor 11. A continuación, añadimos el valor de y. Digamos que cuando recuperamos el valor de x, éste tiene un valor de 11. A continuación, añadimos el valor de y. Tal vez, antes de que el valor resultante se escriba de nuevo en la posición de memoria a la que hace referencia x, otra instancia de la función haya actualizado esa posición de memoria. Si y se fijó en 5, el valor de esta instancia llamada sería 16. Sin embargo, puede que en la segunda instancia y fuera 10. De repente, el valor de x es 21, pero en cuanto x se escribe aquí, tenemos un valor de 16. ¿Cuál es el correcto? Con una programación como ésta, se obtienen comportamientos imprevisibles en el programa.
Si el flujo correcto de un programa requiere una temporización específica, existe la posibilidad de que se produzca una condición de carrera. Las variables pueden alterarse antes de una lectura crítica que puede controlar la funcionalidad del programa. Puede haber algo como un nombre de archivo que podría insertarse antes de que se lea el valor y se opere sobre él. Las condiciones de carrera pueden ser difíciles de encontrar y aislar debido a la naturaleza asíncrona de los programas con múltiples hilos. Sin controles como los semáforos para indicar cuándo los valores están en un estado en el que se pueden leer o escribir con seguridad, puedes obtener un comportamiento incoherente simplemente porque el programador no puede controlar directamente qué hilo tendrá acceso a la CPU y en qué orden.
Por supuesto, lo que hemos visto aquí es un ejemplo sencillo sólo para demostrar claramente la cuestión. Errores de programación mucho más sutiles pueden dar lugar a comportamientos impredecibles como resultado de condiciones de carrera.
Validación de entradas
La validación de entrada es un término amplio que engloba en cierto modo los desbordamientos de búfer, así como otras vulnerabilidades. Si el búfer introducido es demasiado largo y no se ha comprobado, es un problema de validación de entrada. Sin embargo, la validación de entradas es un problema que va más allá de los desbordamientos de búfer. De hecho, los desbordamientos de búfer tienen que ver con la comprobación del tamaño de la entrada, pero otros tipos de errores son el resultado de que la entrada contenga valores que podrían ser perjudiciales para el programa o para el sistema en el que se ejecuta el programa. El Ejemplo 4-2 muestra un pequeño fragmento de código C que podría ser fácilmente vulnerable a un ataque sin una validación de entrada adecuada.
Ejemplo 4-2. Programa en C con posibles errores de validación de entrada
int tryThis(char *value)
{
int ret;
ret = system(value);
return ret;
}Se trata de una pequeña función que toma una cadena como parámetro. El parámetro se pasa directamente al sistema de funciones de la biblioteca C, que pasa la ejecución al sistema operativo. Si se pasara el valor useradd atacante, se pasaría directamente al sistema operativo, y si el programa tuviera los permisos adecuados por el usuario con el que se ejecuta, estaría creando un usuario llamado atacante. Cualquier comando del sistema operativo podría pasarse así. Sin una validación de entrada adecuada, esto podría ser un problema importante, especialmente si no se dan los permisos adecuados al programa atacado. Ésta es una de las razones, francamente, por las que Kali Linux ya no permite a los usuarios iniciar sesión directamente como usuario root de. Podrían explotarse errores de programación en un programa que se ejecute como usuario root, lo que significa que disponen de todo el funcionamiento del sistema para hacer lo que quieran.
Este tipo de problema de validación de entrada es quizás más probable que se vea en aplicaciones web. Los ataques de inyección de comandos, inyección SQL e inyección XML son ejemplos de una mala validación de la entrada. Se introducen valores en los elementos de una aplicación sin comprobarlos. Esta entrada podría ser un comando del sistema operativo o código SQL, por ejemplo. Si el programador no valida correctamente la entrada antes de actuar sobre ella, pueden ocurrir cosas malas.
Control de acceso
Desde el punto de vista de la vulnerabilidad,el control de acceso es, una categoría un poco "cajón de sastre". A primera vista, el control de acceso no es más que determinar quién puede acceder a los recursos y qué nivel de acceso tiene. Un área en la que el control de acceso puede convertirse en una vulnerabilidad es cuando los programas se ejecutan como usuarios que tienen más permisos o privilegios de los que el programa necesita estrictamente para funcionar. Cualquier programa que se ejecute como root, por ejemplo, es potencialmente problemático. Si se puede explotar el código, como con una entrada mal validada o un desbordamiento de búfer, cualquier cosa que haga el atacante tendrá permisos de root.
Esto no se limita estrictamente a los programas que se ejecutan como root. Cualquier programa se ejecuta con los permisos del propietario del programa. Si cualquier propietario de un programa tiene permisos para acceder a cualquier recurso de un sistema, un exploit de ese programa puede dar a un atacante acceso a ese recurso. Estos ataques del tipo pueden conducir a una escalada de privilegios: un usuario obtiene acceso a algo a lo que no debería tener acceso en el estado normal del sistema.
Este problema concreto podría paliarse, al menos hasta cierto punto, exigiendo la autenticación dentro de la aplicación. Es un obstáculo que un atacante tendría que superar antes de limitarse a explotar un programa: tendría que eludir la autenticación mediante un ataque directo o adquiriendo o adivinando una contraseña. A veces, lo mejor que podemos esperar es que conseguir acceso sea una molestia.
Exploración de vulnerabilidades
Exploración de vulnerabilidades es el proceso de buscar principalmente vulnerabilidades conocidas. En el resto de este capítulo, nos ocuparemos de los escáneres de vulnerabilidades, pero cuando la gente piensa en escáneres de vulnerabilidades, puede que piense en escáneres de uso general que puedan buscar vulnerabilidades tanto locales como remotas. Hay muchos escáneres comerciales disponibles. En los años 90, uno de los primeros escáneres fue el Security Administrator's Toolkit for Analyzing Networks (SATAN), aunque para la gente a la que le ofendieran las siglas, podías ejecutar un programa que hiciera un cambio y llamarlo SANTA en su lugar. SATAN acabó convirtiéndose en SAINT, el Conjunto de Herramientas de Redes Integradas del Administrador de Seguridad, que aún está disponible como escáner comercial. SATAN, sin embargo, era de código abierto y estaba disponible gratuitamente. No mucho después apareció otro escáner de código abierto y de libre acceso llamado Nessus.
Nessus se desarrolló originalmente en 1998, pero en 2005 sus desarrolladores decidieron cerrar el código fuente y convertirlo en software comercial. Lo que recuerdo es que los desarrolladores estaban cansados de ser los únicos que contribuían. La comunidad no contribuía, así que cerraron el código fuente. Todo esto sirve para explicar la fundación de un escáner de vulnerabilidades de código abierto llamado OpenVAS, que empezó como una bifurcación de Nessus. Las primeras versiones utilizaban el programa gráfico y la base de Nessus, así que no había mucha diferencia.
OpenVAS, como tantos otros escáneres de vulnerabilidades, y francamente mucho software comercial, se ha pasado a una interfaz basada en web. Aunque puedes conseguir uno de los escáneres comerciales, instalarlo y utilizarlo en Kali Linux, OpenVAS está disponible como un paquete que se puede instalar. No está instalado por defecto, así que tienes que instalar el paquete openvas. Una vez instalado como paquete, tienes que hacer el trabajo de instalar y preparar todo lo necesario para utilizar OpenVAS. No es necesariamente un proceso sencillo. En primer lugar, requiere que esté instalada la base de datos PostgreSQL, lo cual está bien porque Metasploit, que se instala por defecto, también requiere PostgreSQL. El primer paso para configurar OpenVAS se ve en el Ejemplo 4-3. Tienes que ejecutar gvm_setup. No es un proceso corto. Además de configurar la base de datos, descarga todas las firmas.
Ejemplo 4-3. Instalar OpenVAS
┌──(kilroy@badmilo)-[~] └─$ sudo gvm-setup [>] Starting PostgreSQL service [>] Creating GVM's certificate files [>] Creating PostgreSQL database [*] Creating database user [*] Creating database [*] Creating permissions CREATE ROLE [*] Applying permissions GRANT ROLE [*] Creating extension uuid-ossp CREATE EXTENSION [*] Creating extension pgcrypto CREATE EXTENSION [>] Migrating database [>] Checking for GVM admin user [*] Creating user admin for gvm [*] Please note the generated admin password [*] User created with password 'af6c349c-5a7e-4a84-862a-de61f00e807d'. [*] Configure Feed Import Owner [*] Define Feed Import Owner [>] Updating GVM feeds [*] Updating NVT (Network Vulnerability Tests feed from Greenbone Security ↩ Feed/Community Feed)
Los escáneres de vulnerabilidades saben qué aspecto tiene una vulnerabilidad porque buscan firmas o patrones. Los escáneres de vulnerabilidades no intentan explotar las vulnerabilidades. No encuentran vulnerabilidades que no hayan existido previamente. Buscan patrones en sus interacciones con programas y sistemas. Estos patrones son desarrollados por los mantenedores de OpenVAS basándose en los anuncios de vulnerabilidades. No asumas, sin embargo, que sólo porque los escáneres de vulnerabilidades no exploten vulnerabilidades para validarlas, el escáner es perfectamente seguro. Es posible que un escáner cause inadvertidamente daños a los sistemas, incluso cortes. Cuando envías muchos datos en busca de vulnerabilidades, existe la posibilidad de que el sistema receptor acabe teniendo problemas. Las aplicaciones que son realmente frágiles pueden acabar teniendo problemas que provoquen fallos en la aplicación.
El proceso gvm_setup descarga cientos o miles de archivos XML que contienen información sobre vulnerabilidades. Cada vulnerabilidad instalada tiene que ser catalogada para que puedas utilizarla en tu exploración de vulnerabilidades. El Ejemplo 4-4 muestra algunos de estos archivos XML que se están descargando. Dependiendo de la velocidad de tu disco, procesador y red, esto puede tardar varias horas. Ten paciencia, aléjate, busca otra cosa que hacer y espera hasta que todo se haya instalado. Deberás prestar atención a la última parte de la instalación. Parte del resultado de la última sección será la contraseña del usuario administrador. La necesitarás para acceder a OpenVAS por primera vez.
Ejemplo 4-4. Descargar firmas
nvdcve-2.0-2010.xml
22,577,713 100% 983.91kB/s 0:00:22 (xfr#10, to-chk=33/44)
nvdcve-2.0-2011.xml
22,480,816 100% 969.40kB/s 0:00:22 (xfr#11, to-chk=32/44)
nvdcve-2.0-2012.xml
25,153,405 100% 995.05kB/s 0:00:24 (xfr#12, to-chk=31/44)
nvdcve-2.0-2013.xml
28,559,864 100% 989.41kB/s 0:00:28 (xfr#13, to-chk=30/44)
nvdcve-2.0-2014.xml
30,569,278 100% 991.56kB/s 0:00:30 (xfr#14, to-chk=29/44)
nvdcve-2.0-2015.xml
32,900,521 100% 634.44kB/s 0:00:50 (xfr#15, to-chk=28/44)Una vez finalizada la instalación, verás una salida como la del Ejemplo 4-5. Puedes ver la contraseña del usuario admin hacia el final de la salida. Puedes ver que es larga. Aunque puedes añadir usuarios en la línea de comandos, probablemente sea más fácil asegurarte de copiar esta contraseña y guardarla en algún sitio hasta que puedas iniciar sesión en la interfaz web. También verás la sugerencia de que ejecutes gvm-check-setup. Puedes pasar por gvm-setup y seguir teniendo una instalación de OpenVAS estropeada. Debes asegurarte de que ejecutas gvm-check-setup.
Ejemplo 4-5. Configuración completa de OpenVAS
ent 735 bytes received 106,076,785 bytes 986,767.63 bytes/sec total size is 106,049,031 speedup is 1.00 [+] GVM feeds updated [*] Checking Default scanner [*] Modifying Default Scanner Scanner modified. [+] Done [*] Please note the password for the admin user [*] User created with password 'af6c349c-5a7e-4a48-862a-de61f00e708d'. [>] You can now run gvm-check-setup to make sure everything is correctly configured
Lo ideal es que pase por gvm-check-setup sin problemas. Si lo haces, verás la salida que se muestra en el Ejemplo 4-6. Si te encuentras con errores, puedo decirte por experiencia personal que resolverlos puede ser muy complicado. Intenta hacer una instalación sencilla y limpia, sin desviarte del enfoque básico descrito aquí.
Ejemplo 4-6. Ejecutar gvm-check-setup
┌──(kilroy@badmilo)-[~]
└─$ sudo gvm-check-setup
gvm-check-setup 22.4.1
Test completeness and readiness of GVM-22.4.1
Step 1: Checking OpenVAS (Scanner)...
OK: OpenVAS Scanner is present in version 22.4.1.
OK: Notus Scanner is present in version 22.4.4.
OK: Server CA Certificate is present as /var/lib/gvm/CA/servercert.pem.
Checking permissions of /var/lib/openvas/gnupg/*
OK: _gvm owns all files in /var/lib/openvas/gnupg
OK: redis-server is present.
OK: scanner (db_address setting) is configured properly using the ↩
redis-server socket: /var/run/redis-openvas/redis-server.sock
OK: redis-server is running and listening on socket: ↩
/var/run/redis-openvas/redis-server.sock.
OK: redis-server configuration is OK and redis-server is running.
OK: the mqtt_server_uri is defined in /etc/openvas/openvas.conf
OK: _gvm owns all files in /var/lib/openvas/plugins
OK: NVT collection in /var/lib/openvas/plugins contains 85634 NVTs.
OK: The notus directory /var/lib/notus/products contains 301 NVTs.
Checking that the obsolete redis database has been removed
OK: No old Redis DB
OK: ospd-OpenVAS is present in version 22.4.6.
Step 2: Checking GVMD Manager ...
OK: GVM Manager (gvmd) is present in version 22.4.2.
Step 3: Checking Certificates ...
OK: GVM client certificate is valid and present as ↩
/var/lib/gvm/CA/clientcert.pem.
OK: Your GVM certificate infrastructure passed validation.
Step 4: Checking data ...
OK: SCAP data found in /var/lib/gvm/scap-data.
OK: CERT data found in /var/lib/gvm/cert-data.
Step 5: Checking Postgresql DB and user ...
OK: Postgresql version and default port are OK.
gvmd | _gvm | UTF8 | en_US.UTF-8 | en_US.UTF-8 | | libc |
16435|pg-gvm|10|2200|f|22.4.0||
OK: At least one user exists.
Step 6: Checking Greenbone Security Assistant (GSA) ...
OK: Greenbone Security Assistant is present in version 22.04.1~git.
Step 7: Checking if GVM services are up and running ...
OK: ospd-openvas service is active.
OK: gvmd service is active.
OK: gsad service is active.
Step 8: Checking few other requirements...
OK: nmap is present.
OK: ssh-keygen found, LSC credential generation for GNU/Linux targets is ↩
likely to work.
OK: nsis found, LSC credential package generation for Microsoft Windows ↩
targets is likely to work.
OK: xsltproc found.
Step 9: Checking greenbone-security-assistant...
OK: greenbone-security-assistant is installed
It seems like your GVM-22.4.1 installation is OK.En ya deberías tener configurado OpenVAS. Puedes iniciarlo utilizando gvm-start. Si los servicios se están ejecutando y quieres detenerlos, puedes ejecutar gvm_stop. Si alguna vez tienes problemas con la instalación de OpenVAS, merece la pena volver a ejecutar gvm-check-setup. Una vez que tengas instalado OpenVAS, puedes acceder a él con cualquier navegador en http://127.0.0.1:9392. Recuerda que el nombre de usuario es admin y la contraseña es la que haya salido en tu proceso de instalación. Cada instalación tendrá una contraseña diferente, así que asegúrate de llevar un registro de la tuya.
Vulnerabilidades locales
Las vulnerabilidades locales requieren cierto nivel de acceso al sistema. El objetivo de una vulnerabilidad local no es obtener acceso. Tienes que tener ya acceso local para ejecutar un programa que tenga una vulnerabilidad de este tipo. La idea de explotar una vulnerabilidad local suele ser obtener acceso a algo a lo que el atacante no tiene acceso de otro modo, lo que significa que podría tratarse de una escalada de privilegios.
Las vulnerabilidades locales pueden producirse en cualquier programa de un sistema. Esto incluye los servicios en ejecución -programas que se ejecutan en segundo plano sin interacción directa del usuario y que suelen denominarse daemons-,así como cualquier otro programa al que un usuario pueda acceder. Un programa como passwd es setuid para permitir que cualquier usuario lo ejecute y obtenga privilegios temporales de root. Un programa setuid establece el ID de usuario del programa en ejecución en el propietario del archivo. Esto es necesario porque cambiar la contraseña de un usuario requiere cambios en un archivo en el que sólo puede escribir root. Si quisiera cambiar mi contraseña, podría ejecutar passwd, pero como hay que cambiar la base de datos de contraseñas, el programa passwd necesita tener privilegios de root para escribir en el archivo necesario. Si hubiera una vulnerabilidad en el programa passwd, ese programa se ejecutaría temporalmente como root, lo que significa que cualquier exploit durante el periodo de tiempo en que el programa se ejecutara como root tendría permisos de root.
Nota
Un programa que tiene activado el bit setuid se inicia como el usuario propietario del archivo. Normalmente, el usuario propietario de un archivo sería root, porque los usuarios necesitan poder realizar tareas que requieren privilegios de root, como cambiar su propia contraseña. Sin embargo, puedes crear un programa setuid para cualquier usuario. No importa el usuario que haya iniciado el programa, cuando se esté ejecutando, parecerá como si el propietario del programa en disco estuviera ejecutando el programa.
Utilizar lynis para comprobaciones locales
En la mayoría de las distribuciones de Linux existen programas que pueden ejecutar pruebas para detectar vulnerabilidades locales. Kali no es diferente. Uno de estos programas es lynis, un escáner de vulnerabilidades que se ejecuta en el sistema local y realiza numerosas comprobaciones de configuraciones que serían habituales en una instalación de un sistema operativo endurecido. Los sistemas operativos endurecidos se configuran para que sean resistentes a los ataques. Esto puede significar activar el registro, reforzar los permisos y elegir otros ajustes.
El programa lynis tiene ajustes para varios tipos de escaneado. Puedes hacer escaneos rápidos o escaneos completos, según la profundidad a la que quieras llegar. También existe la posibilidad de ejecutar en modo pentest, que es un escaneo sin privilegios. Esto limita lo que se puede comprobar. Cualquier cosa que requiera acceso root, como mirar los archivos de configuración, no se puede comprobar en modo pentest. Esto puede darte una buena idea de lo que puede hacer un atacante si consigue acceder a una cuenta normal sin privilegios. El Ejemplo 4-7 muestra una salida parcial de una ejecución de lynis contra una instalación básica de Kali.
Ejemplo 4-7. Salida de lynis
[+] Kernel
------------------------------------
- Checking default run level [ RUNLEVEL 5 ]
- Checking CPU support (NX/PAE)
CPU support: PAE and/or NoeXecute supported [ FOUND ]
- Checking kernel version and release [ DONE ]
- Checking kernel type [ DONE ]
- Checking loaded kernel modules [ DONE ]
Found 120 active modules
- Checking Linux kernel configuration file [ FOUND ]
- Checking default I/O kernel scheduler [ NOT FOUND ]
- Checking for available kernel update [ OK ]
- Checking core dumps configuration
- configuration in systemd conf files [ DEFAULT ]
- configuration in /etc/profile [ DEFAULT ]
- 'hard' configuration in /etc/security/limits.conf [ DEFAULT ]
- 'soft' configuration in /etc/security/limits.conf [ DEFAULT ]
- Checking setuid core dumps configuration [ DISABLED ]
- Check if reboot is needed [ NO ]
[+] Memory and Processes
------------------------------------
- Checking /proc/meminfo [ FOUND ]
- Searching for dead/zombie processes [ NOT FOUND ]
- Searching for IO waiting processes [ NOT FOUND ]
- Search prelink tooling [ NOT FOUND ]
[+] Users, Groups, and Authentication
------------------------------------
- Administrator accounts [ OK ]
- Unique UIDs [ OK ]
- Unique group IDs [ OK ]
- Unique group names [ OK ]
- Password file consistency [ SUGGESTION ]
- Checking password hashing rounds [ DISABLED ]
- Query system users (non daemons) [ DONE ]
- NIS+ authentication support [ NOT ENABLED ]
- NIS authentication support [ NOT ENABLED ]
- Sudoers file(s) [ FOUND ]
- PAM password strength tools [ SUGGESTION ]
- PAM configuration files (pam.conf) [ FOUND ]
- PAM configuration files (pam.d) [ FOUND ]
- PAM modules [ FOUND ]
- LDAP module in PAM [ NOT FOUND ]
- Accounts without expire date [ OK ]
- Accounts without password [ OK ]
- Locked accounts [ OK ]
- Checking user password aging (minimum) [ DISABLED ]
- User password aging (maximum) [ DISABLED ]
- Checking Linux single user mode authentication [ OK ]
- Determining default umask
- umask (/etc/profile) [ NOT FOUND ]
- umask (/etc/login.defs) [ SUGGESTION ]
- LDAP authentication support [ NOT ENABLED ]
- Logging failed login attempts [ ENABLED ]Como puedes ver en la salida, lynis encontró problemas con las herramientas de seguridad de contraseñas del módulo de autenticación conectable (PAM) de, hasta el punto de ofrecer una sugerencia. También encontró un problema con la coherencia del archivo de contraseñas, aunque para más detalles, tendría que mirar la sugerencia. Además, encontró un problema con la configuración por defecto de los permisos de los archivos. Esta es la configuración umask que comprobó en /etc/login.defs. El resultado completo de la herramienta contiene muchas otras recomendaciones, pero se trataba de una auditoría completa del sistema y, en su mayor parte, es una instalación "lista para usar". Sin embargo, es interesante señalar que en la edición anterior del libro, al ejecutar lynis se detectaron problemas con la autenticación en modo monousuario, que es cuando arrancas el sistema en modo monousuario, utilizado habitualmente para la administración de sistemas críticos en los que no quieres que se toque nada, como el sistema de archivos, mientras realizas tareas. Aparentemente, este problema se ha resuelto desde esa versión de Kali, ya que aquí ya no es un problema.
La salida de la consola proporciona un nivel de detalle, pero se crea un archivo de registro. El archivo de registro se almacena en el directorio personal del usuario que ejecuta el comando. Puedes encontrar detalles adicionales del registro en var/log/lynis.log. El ejemplo 4-8 muestra un fragmento de la salida del archivo de registro que se almacenó en mi directorio personal cuando lo ejecuté como mi usuario. La salida de este archivo de registro muestra cada paso dado por el programa, así como el resultado de cada paso. También observarás que cuando hay hallazgos, el programa los indica en la salida. Verás que en el caso de libpam-usb hay una sugerencia para endurecer aún más el sistema operativo contra los ataques.
Ejemplo 4-8. Archivo de registro de una ejecución de lynis
2023-07-10 19:31:33 ==== 2023-07-10 19:31:33 Discovered directories: /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin 2023-07-10 19:31:33 DEB-0001 Result: found 7981 binaries 2023-07-10 19:31:33 Status: Starting Authentication checks... 2023-07-10 19:31:33 Status: Checking if libpam-tmpdir is installed and enabled... 2023-07-10 19:31:33 ==== 2023-07-10 19:31:33 Performing test ID DEB-0280 (Checking if libpam-tmpdir is ↩ installed and enabled.) 2023-07-10 19:31:33 - libpam-tmpdir is not installed. 2023-07-10 19:31:33 Hardening: assigned partial number of hardening points ↩ (0 of 2). Currently having 0 points (out of 2) 2023-07-10 19:31:33 Suggestion: Install libpam-tmpdir to set $TMP and $TMPDIR for ↩ PAM sessions [test:DEB-0280] [details:-] [solution:-] 2023-07-10 19:31:33 Status: Starting file system checks... 2023-07-10 19:31:33 Status: Starting file system checks for dm-crypt, ↩ cryptsetup & cryptmount... 2023-07-10 19:31:33 ==== 2023-07-10 19:31:33 Skipped test DEB-0510 (Checking if LVM volume groups or file ↩ systems are stored on encrypted partitions) 2023-07-10 19:31:33 Reason to skip: Prerequisites not met (ie missing tool, other ↩ type of Linux distribution) 2023-07-10 19:31:33 ==== 2023-07-10 19:31:33 Skipped test DEB-0520 (Checking for Ecryptfs) 2023-07-10 19:31:33 Reason to skip: Prerequisites not met (ie missing tool, other ↩ type of Linux distribution) 2023-07-10 19:31:34 Status: Starting Software checks...
Se trata de un programa que puede utilizar regularmente cualquier persona que opere un sistema Linux, de modo que pueda ser consciente de los problemas que necesita corregir. Sin embargo, como persona implicada en pruebas de penetración o de seguridad, puedes ejecutar este programa en los sistemas Linux a los que tengas acceso. Si trabajas codo con codo con la empresa para la que realizas las pruebas, será más fácil realizar escaneos locales. Es posible que te proporcionen acceso local a los sistemas para que puedas ejecutar programas como éste. Por supuesto, necesitarías tener instalado este programa en cualquier sistema contra el que quisieras ejecutarlo. En ese caso, no lo ejecutarías desde el propio Kali. Sin embargo, puedes obtener mucha experiencia con lynis ejecutándolo en tu sistema local y consultando el resultado.
Escaneo local OpenVAS
Tú no estás limitado a realizar pruebas en el sistema local para detectar vulnerabilidades locales. Con esto quiero decir que no tienes que estar conectado a los programas en ejecución para realizar las pruebas. En su lugar, puedes utilizar un escáner de vulnerabilidades remoto y proporcionarle credenciales de inicio de sesión. Esto permitirá al escáner iniciar sesión de forma remota y ejecutar los escaneos a través de una sesión de inicio de sesión. En la interfaz web Greenbone Security Assistant, la mayor parte de lo que haremos en esta sección se encuentra en el menú Configuración. Aquí es donde se configuran todos los elementos esenciales para crear un escaneo.
Anteriormente, instalamos OpenVAS; pero ahora podemos echar un vistazo a su uso para escanear vulnerabilidades. Aunque es principalmente un escáner remoto de vulnerabilidades, como verás, se le pueden proporcionar credenciales para iniciar sesión. Esas credenciales de inicio de sesión, que se muestran configuradas en la Figura 4-2, serán utilizadas por OpenVAS para iniciar sesión de forma remota y ejecutar pruebas localmente a través de la sesión de inicio de sesión. Puedes seleccionar la opción para que OpenVAS autogenere, lo que hará que OpenVAS pruebe las contraseñas con un nombre de usuario especificado.
Figura 4-2. Configuración de credenciales en OpenVAS
Sin embargo, la creación de credenciales en es sólo una parte del proceso. Todavía tienes que configurar un escaneo que pueda utilizar las credenciales. Lo primero que hay que hacer es identificar o crear una configuración de escaneo que incluya vulnerabilidades locales para los sistemas operativos de destino que tengas. Como ejemplo, la Figura 4-3 muestra un cuadro de diálogo que muestra una sección de las familias de vulnerabilidades disponibles en OpenVAS. Puedes ver un puñado de sistemas operativos en la lista con vulnerabilidades locales. Entre ellos están Debian y Ubuntu. Se incluyen otros sistemas operativos, y cada familia puede tener cientos, si no miles, de vulnerabilidades.
Figura 4-3. Selección de familias de vulnerabilidades en OpenVAS
Una vez que tengas tus vulnerabilidades seleccionadas, necesitas crear objetivos y aplicar tus credenciales. La Figura 4-4 muestra el cuadro de diálogo de OpenVAS para crear un objetivo. Esto requiere que especifiques una dirección IP, o un rango de direcciones IP, o un archivo que incluya la lista de direcciones IP que deben ser los objetivos. Aunque este cuadro de diálogo ofrece otras opciones, las que más nos interesan son aquellas en las que especificamos las credenciales. Las credenciales configuradas aquí se han seleccionado para ser utilizadas contra objetivos que tengan servidores SSH ejecutándose en el puerto 22. Si has identificado previamente otros servidores SSH que puedan estar ejecutándose en una configuración no estándar, puedes especificar otros puertos. Además de SSH, puedes seleccionar SMB y ESXi como protocolos con los que iniciar sesión.
Cada sistema operativo va a ser diferente, y esto es especialmente cierto con Linux, que es la razón por la que hay diferentes familias en OpenVAS para las vulnerabilidades locales. Cada distribución está configurada de forma un poco diferente y tiene diferentes conjuntos de paquetes. Cada paquete puede tener diferentes ajustes de configuración por defecto. Más allá de la distribución, los usuarios pueden tener muchas opciones para las categorías de paquetes. Una vez instalada la base, normalmente pueden instalarse cientos de paquetes adicionales, y cada uno de esos paquetes puede introducir vulnerabilidades.
Figura 4-4. Seleccionar un objetivo en OpenVAS
Nota
Un enfoque común para el endurecimiento es limitar el número de paquetes que se instalan. Esto es especialmente cierto cuando se trata de sistemas de servidores en los que debe instalarse la cantidad mínima de software necesaria para que funcionen los servicios.
Una vez que tengas todas las configuraciones en su sitio, aún tienes que crear una tarea de escaneo. En el menú Escaneos, debes seleccionar Tareas. Como en las otras páginas, deberías ver un icono parecido a una hoja de papel con un asterisco en la esquina superior derecha. Así es como se añade una nueva configuración, y en esta página, estás creando una nueva tarea de escaneado. La Figura 4-5 muestra el cuadro de diálogo en el que creas una nueva tarea de escaneado. Los ajustes importantes aquí son los desplegables Objetivos de Escaneado y Configuración de Escaneado. Deberías seleccionar el objetivo de escaneado que creaste y que tenía tus credenciales. A continuación, selecciona la configuración de escaneado que hayas creado y que tenga el conjunto adecuado de familias seleccionadas para tu escaneado.
Una vez hayas configurado la nueva tarea de escaneo, aparecerá en la lista de tareas. Durante la configuración de la tarea, puedes establecer que se ejecute según una programación, pero si quieres, también puedes ejecutarla bajo demanda. Sólo tienes que hacer clic en el botón de reproducción que se parece un poco a un triángulo lateral.
Figura 4-5. Crear un escaneo en OpenVAS
Kits Raíz
Aunque no es estrictamente un escáner de vulnerabilidades, merece la pena conocer Rootkit Hunter. Este programa puede ejecutarse localmente en un sistema para determinar si ha sido comprometido y tiene instalado un root kit. Un root kit es un paquete de software destinado a facilitar una pieza de malware. Puede incluir utilidades de sustitución del sistema operativo para ocultar la existencia del malware en ejecución. Por ejemplo, el programa ps puede alterarse para que no muestre los procesos asociados al malware. Además, ls puede ocultar la existencia de los archivos del malware. Los kits de raíz también pueden implementar una puerta trasera que permita a los atacantes el acceso remoto.
Si se ha instalado software root kit, puede significar que se ha explotado una vulnerabilidad en algún lugar. También significa que en tu sistema se está ejecutando software que no deseas. Conocer Rootkit Hunter puede ser útil para permitirte escanear sistemas. Puede que quieras dedicar tiempo a ejecutar este programa en cualquier sistema en el que hayas ejecutado escáneres y hayas encontrado vulnerabilidades. Esto puede ser un indicio de que el sistema ha sido comprometido. Ejecutar Rootkit Hunter te permitirá determinar si hay rootkits instalados en tu sistema.
El nombre del ejecutable es rkhunter, y es fácil de ejecutar, aunque no está instalado en una compilación por defecto de la distribución actual de Kali Linux. rkhunter ejecuta comprobaciones para determinar si se han instalado kits de root. Para empezar, comprueba los permisos de los archivos, de lo que puedes ver una muestra en el Ejemplo 4-9. Aparte de eso, rkhunter realiza búsquedas de patrones de firmas del aspecto de los root kits conocidos. Al igual que la mayoría de los programas antivirus, rkhunter no puede encontrar lo que no conoce. Buscará anomalías, como permisos de archivo incorrectos. Buscará archivos que conozca de root kits conocidos. Si hay root kits que no conoce, no los detectará.
Ejemplo 4-9. Ejecutar Rootkit Hunter
┌──(kilroy@badmilo)-[~]
└─$ sudo rkhunter --check
[ Rootkit Hunter version 1.4.6 ]
Checking system commands...
Performing 'strings' command checks
Checking 'strings' command [ OK ]
Performing 'shared libraries' checks
Checking for preloading variables [ None found ]
Checking for preloaded libraries [ None found ]
Checking LD_LIBRARY_PATH variable [ Not found ]
Performing file properties checks
Checking for prerequisites [ OK ]
/usr/sbin/adduser [ OK ]
/usr/sbin/chroot [ OK ]
/usr/sbin/cron [ OK ]
/usr/sbin/depmod [ OK ]
/usr/sbin/fsck [ OK ]
/usr/sbin/groupadd [ OK ]
/usr/sbin/groupdel [ OK ]
/usr/sbin/groupmod [ OK ]
/usr/sbin/grpck [ OK ]Al igual que con lynis, se trata de un paquete de software; necesitarías instalar Rootkit Hunter en un sistema que estuvieras auditando en busca de software malicioso. No puedes ejecutarlo desde tu instancia Kali en un sistema remoto. Si trabajas mucho con pruebas y exploits en tu instancia Kali, no es mala idea que sigas comprobando tu propio sistema. Siempre que ejecutes software de una fuente en la que no confías necesariamente del todo, como puede ser el caso si estás trabajando con exploits de prueba de concepto de, deberías comprobar tu sistema en busca de virus y otro malware. Sí, esto es tan cierto en Linux como en otras plataformas. Linux no es invulnerable a los ataques ni al malware. Lo mejor es mantener tu sistema tan limpio y seguro como puedas.
Vulnerabilidades remotas
Mientras que a veces se te puede dar acceso a los sistemas trabajando estrechamente con tu objetivo, definitivamente tendrás que realizar comprobaciones remotas de vulnerabilidades cuando estés haciendo pruebas de seguridad. Cuando obtienes acceso completo, que puede incluir credenciales con las que realizar pruebas, compilaciones de escritorio para auditar sin afectar a los usuarios, o ajustes de configuración de dispositivos de red, estás realizando pruebas de caja clara. Si no cuentas con la cooperación del objetivo, aparte de un acuerdo claro con él sobre lo que piensas hacer, estás haciendo pruebas de caja opaca; no sabes nada en absoluto sobre lo que estás probando. También puedes hacer pruebas de caja gris. Se trata de algo intermedio entre la caja clara y la caja opaca, aunque hay muchas gradaciones intermedias.
En las pruebas de para detectar vulnerabilidades remotas, es útil empezar con ventaja. Necesitarás utilizar un escáner de vulnerabilidades. Aunque OpenVAS no es el único escáner de vulnerabilidades que se puede utilizar, está disponible gratuitamente y se incluye con los repositorios de Kali Linux. Debe considerarse un punto de partida para tus pruebas de vulnerabilidad. Si bastara con ejecutar un escáner, cualquiera podría hacerlo. Ejecutar escáneres de vulnerabilidades no es difícil. El valor de que alguien haga pruebas de seguridad no es cargar un montón de herramientas automatizadas. En cambio, es la interpretación y validación de los resultados, así como ir más allá de las herramientas automatizadas. El trabajo duro consiste en comprender el resultado del escáner y ser capaz de determinar si los hallazgos son legítimos, así como la prioridad real de la vulnerabilidad.
Anteriormente, hemos explorado cómo puede utilizarse OpenVAS para el escaneo local. También puede utilizarse, y quizá sea más conocido, para escanear vulnerabilidades remotas. Esto es a lo que vamos a dedicar algo de tiempo ahora. OpenVAS es un software bastante denso, por lo que vamos a repasar algunas de sus capacidades en lugar de ofrecer una visión general exhaustiva. Lo importante es comprender cómo funcionan los escáneres de vulnerabilidades.
Nota
Como ya se ha dicho, el proyecto OpenVAS comenzó cuando Nessus se bifurcó del proyecto Nessus. Desde entonces, se han producido cambios arquitectónicos significativos en el diseño de OpenVAS. Aunque Nessus también ha pasado a tener una interfaz web, ya no hay ningún parecido entre OpenVAS y Nessus, ni en la interfaz ni en la arquitectura subyacente del escáner.
Cuando utilices OpenVAS o cualquier escáner de vulnerabilidades, éste tendrá una colección o base de datos de vulnerabilidades conocidas. Esta colección debe actualizarse periódicamente, igual que los programas antivirus. Cuando configuras OpenVAS, una de las primeras cosas que ocurre es que se descarga la colección actual de definiciones de vulnerabilidades. Si tienes el sistema funcionando regularmente con los servicios de OpenVAS, tus vulnerabilidades se actualizarán por ti. Si has tenido OpenVAS inactivo durante un tiempo y quieres ejecutar un escaneo, merece la pena que te asegures de que todas tus firmas están actualizadas. Puedes hacerlo en la línea de comandos utilizando el comando greenbone-nvt-sync. Es necesario ejecutarlo como el usuario _gvm creado para OpenVAS. Para ello, ejecuta el comando sudo -u _gvm greenbone-nvt-sync. Esto ejecutará el comando utilizando el usuario especificado. OpenVAS utiliza el Protocolo de Automatización de Contenidos de Seguridad para intercambiar información entre tu instalación y los servidores remotos donde se almacenan los contenidos.
OpenVAS utiliza una interfaz web, como muchas otras aplicaciones actuales. Para acceder a la aplicación web, entra en https://localhost:9392. Cuando te conectas, se te presenta un panel de control. Éste incluye gráficos relacionados con tus propias tareas. El panel también presenta información sobre las vulnerabilidades que conoce y su gravedad. En la Figura 4-6, puedes ver una página web abierta al salpicadero. Puedes ver el número de tareas (es una instalación nueva, así que sólo hay una), así como un gráfico que muestra las vulnerabilidades que hay en la base de datos.
Figura 4-6. Asistente de Seguridad de Greenbone
Los menús para acceder a las características y funciones se encuentran en la parte superior de la página. Desde ahí, puedes acceder a funciones relacionadas con los escaneos, los activos y las configuraciones, así como a la colección de información de seguridad que conoce OpenVAS, con todas las vulnerabilidades de las que tiene conocimiento.
Inicio rápido con OpenVAS
Aunque OpenVAS es ciertamente un software denso, que ofrece muchas posibilidades de personalización, proporciona una forma sencilla de empezar. Un asistente de escaneo te permite simplemente proporcionar un objetivo y empezar a escanear. Si quieres hacerte una idea rápida de las vulnerabilidades más comunes que pueden encontrarse en el objetivo, ésta es una forma estupenda de hacerlo. Un escaneo sencillo con el asistente utilizará los valores predeterminados, que es una forma de empezar rápidamente. Para empezar con el asistente, ve al menú Exploraciones y selecciona Tareas. En la parte superior izquierda de esa página, verás algunos iconos pequeños. El de color morado que parece la varita de un mago abre el Asistente de Tareas. La Figura 4-7 muestra el menú que aparece cuando pasas el cursor sobre ese icono.
Figura 4-7. Menú del Asistente de Tareas
En ese menú, puedes seleccionar el Asistente de Tareas Avanzadas, que te ofrece más control sobre los activos y las credenciales, entre otros ajustes. También puedes seleccionar el Asistente de Tareas, que puedes ver en la Figura 4-8. Al utilizar el Asistente de Tareas, se te pedirá una dirección IP de destino. La dirección IP que se rellena cuando aparece es la dirección IP del host desde el que estás conectado al servidor. Puedes introducir aquí no sólo una única dirección IP, sino también toda una red, como se ve en la Figura 4-8. En mi caso, utilizaría 192.168.1.0/24. Es decir, todo el rango de red comprendido entre 192.168.1.0-255. El /24 es una forma de designar rangos de red sin utilizar máscaras de subred ni una notación de rango. Lo verás a menudo, y se suele llamar Notación CIDR, que es la notación Classless Inter-Domain Routing.
Figura 4-8. Asistente de tareas
Una vez que hayas introducido tu objetivo u objetivos, sólo tienes que hacer clic en Iniciar exploración y OpenVAS se pondrá en marcha, por así decirlo. Has iniciado tu primer escaneo de vulnerabilidades. Ésta es la forma más sencilla de iniciar un escaneo, pero no tienes ningún control sobre el tipo de escaneo ni sobre cuándo se ejecutará. Para eso, tenemos que echar un vistazo al Asistente de Exploración Avanzada.
Consejo
En puede ser útil tener cerca algunos sistemas vulnerables cuando realices tus escaneos. Aunque puedes conseguir varios sistemas (y una simple búsqueda en Internet de sistemas operativos vulnerables hará que aparezcan), uno es realmente útil. Metasploitable 2 es una instalación Linux deliberadamente vulnerable. Metasploitable 3 es la versión actualizada basada en Windows Server 2008, aunque también hay una versión de Metasploitable 3 que está construida sobre Ubuntu. Metasploitable 2 es una descarga directa. Metasploitable 3 es un sistema operativo "constrúyelo en tu propio sistema". Requiere VirtualBox y software adicional.
Podemos echar un vistazo al Asistente de Escaneado Avanzado de, que se muestra en la Figura 4-9, para ver el conjunto más amplio de ajustes de configuración a los que tienes acceso, sin dejar de utilizar un asistente para ayudarte a establecer todos los valores. Esto te dará una idea rápida de con qué trabajaremos a mayor escala cuando pasemos a crear escaneos de principio a fin.
Figura 4-9. Asistente de Escaneado Avanzado
Crear una exploración
Si quieres tener un mayor control de tu escaneo, se requieren pasos adicionales. Hay unos cuantos lugares por los que empezar, porque necesitas varios componentes en su sitio antes de poder iniciar el escaneo. Un punto de partida sencillo es el mismo lugar de la interfaz donde configurábamos los escaneos locales. Necesitas establecer objetivos. Si quieres ejecutar escaneos locales como parte de tu escaneo general, configurarías tus credenciales como hicimos antes, yendo al menú Configuración y seleccionando Credenciales. Una vez que hayas establecido las credenciales que necesites, puedes ir a Configuración/Objetivos para acceder al cuadro de diálogo que te permite especificar los objetivos.
A partir de ahí, añades o configuras las credenciales que puedas tener, y tus objetivos están configurados. Tienes que pensar en el tipo de escaneo que quieres hacer. Aquí es donde tienes que ir a Configuraciones de Escaneado, también en el menú Configuración. Esto es algo más que hemos visto rápidamente en "Vulnerabilidades locales". OpenVAS viene con configuraciones de escaneo incorporadas, y puedes ver la lista en la Figura 4-10. Se trata de configuraciones enlatadas a las que no podrás hacer cambios. También en esta lista verás un par de configuraciones que he creado yo. Si quieres algo distinto de lo que te ofrecen los escaneos enlatados, tienes que clonar una de éstas y editarla o crear la tuya propia.
Figura 4-10. Lista de exploraciones
Cuando quieras crear tu propia configuración de escaneado, puedes empezar con una configuración en blanco o con una configuración completa y rápida. Una vez que hayas decidido por dónde quieres empezar, puedes empezar a seleccionar las familias de escaneado que quieres incluir en tu configuración de escaneado. Además, puedes modificar la forma en que se comporta el escáner. En la Figura 4-11 puedes ver una serie de ajustes de configuración que cambiarán la forma en que se ejecuta el escáner y las ubicaciones que utiliza. Un área a señalar específicamente aquí es la configuración de Comprobaciones Seguras. Esto indica que las únicas comprobaciones que se ejecutarán son las que se sabe que son seguras, es decir, que no es tan probable que causen problemas en los sistemas de destino. Esto significa que algunas comprobaciones no se ejecutarán, y pueden ser las que comprueben las vulnerabilidades que más te preocupan. Al fin y al cabo, si la mera comprobación de una vulnerabilidad puede causar problemas en el sistema remoto, eso es algo que la empresa con la que trabajas debe tener en cuenta.
Los escáneres de vulnerabilidades no pretenden explotar vulnerabilidades. Sin embargo, el mero hecho de hurgar en el software para evaluar su reacción puede bastar para provocar caídas de la aplicación. En el caso del sistema operativo, como ocurre con los problemas de la pila de red, puedes estar hablando de bloquear el sistema operativo y provocar una denegación de servicio, aunque no sea eso lo que pretendías. Este es un ámbito en el que debes ser claro con las personas para las que realizas las pruebas. Si esperan pruebas limpias y trabajas en colaboración con ellos, debes tener claro que, a veces, aunque no busques interrupciones del servicio, éstas se producirán. Safe Checks es un ajuste con el que hay que tener cuidado, y debes ser muy consciente de lo que haces cuando lo desactivas. Las Comprobaciones Seguras desactivan las pruebas que puedan tener el potencial de causar daños al servicio remoto, desactivándolo potencialmente, por ejemplo.
Figura 4-11. Preferencias del escáner
Aunque también puedes ajustar parámetros adicionales, estarás listo para empezar cuando hayas establecido la configuración del escaneo y tus objetivos. Antes de empezar aquí, puedes considerar la posibilidad de establecer algunos horarios. Esto puede ser útil si quieres trabajar con una empresa y hacer las pruebas fuera del horario laboral. Si estás realizando pruebas de seguridad o una prueba de penetración, es probable que quieras monitorear el escaneo. Sin embargo, si se trata de un escaneo rutinario, quizá quieras programarlo para que se ejecute durante la noche, para no afectar a las operaciones diarias de la empresa. Aunque no afecte a los servicios o sistemas en funcionamiento, generará tráfico en la red y consumirá recursos de los sistemas. Esto tendría un impacto si lo hicieras mientras la empresa estuviera operativa.
Pero vamos a suponer en que ya tienes tus configuraciones. Sólo quieres iniciar un escaneo con todo lo que has configurado. Desde aquí, tienes que ir al menú Escaneos y seleccionar Tareas. A continuación, haz clic en el icono Nueva Tarea. Aparecerá otro cuadro de diálogo, que puedes ver en la Figura 4-12. En este cuadro de diálogo, le das un nombre a la tarea, que luego muestra las opciones adicionales, y a continuación puedes seleccionar tus objetivos y tu configuración de escaneado. También puedes seleccionar una programación, si has creado una.
En nuestra instalación sencilla, tendremos la opción de utilizar un único escáner. Ese es el escáner de nuestro sistema Kali. En una instalación más compleja, puedes tener varios escáneres para seleccionar y gestionar todos desde una única interfaz. También podrás seleccionar la interfaz de red en la que quieres ejecutar el escaneo. Aunque normalmente esto lo gestionarán las tablas de enrutamiento de tu sistema, puedes indicar una interfaz de origen específica. Esto puede ser útil si quieres que todo tu tráfico proceda de un rango de direcciones IP mientras gestionas desde otra interfaz.
Figura 4-12. Crear una nueva exploración
Por último, tienes la opción de almacenar informes en el servidor OpenVAS. Puedes indicar cuántos quieres almacenar para poder comparar los resultados de un escaneo con los de otro y demostrar los progresos. En última instancia, el objetivo de todas tus pruebas, incluida la exploración de vulnerabilidades, es mejorar la postura de seguridad de tu objetivo. Si la organización recibe tus recomendaciones y luego no hace nada con ellas, eso es peor que no realizar los escaneos. Lo que ocurre cuando presentas un informe a la organización para la que trabajas es que ésta toma conciencia de las vulnerabilidades que has identificado. Esta información puede utilizarse en su contra si no hacen nada con lo que les has dicho.
Informes OpenVAS
El informe es el aspecto más importante de tu trabajo. Redactarás tu propio informe cuando termines las pruebas, pero el informe que emite el escáner de vulnerabilidades te será útil para comprender por dónde puedes empezar a buscar. Debes tener en cuenta dos cosas cuando empieces a mirar los informes del escáner de vulnerabilidades. En primer lugar, el escáner de vulnerabilidades utiliza firmas específicas para determinar si lavulnerabilidad está ahí. Esto puede ser algo así como la captura de banners para comparar números de versión. No puedes estar seguro de que la vulnerabilidad exista porque una herramienta como OpenVAS no explote la vulnerabilidad. En segundo lugar, y esto está relacionado, puedes obtener falsos positivos. Un falso positivo es una indicación de que la vulnerabilidad existe cuando no es así. Como el escáner de vulnerabilidades no explota la vulnerabilidad, lo mejor que puede hacer es obtener una probabilidad.
Si no realizas un escaneo con credenciales, vas a pasar por alto la detección de muchas vulnerabilidades. También tendrás un mayor potencial de obtener falsos positivos. Por eso no basta con un informe de OpenVAS o de cualquier otro escáner. Puesto que no hay garantía de que la vulnerabilidad exista realmente, tienes que poder validar los informes para que tu informe final presente vulnerabilidades legítimas que debanremediarse.
Sin embargo, basta de reafirmaciones. Empecemos a examinar los informes para poder determinar qué es legítimamente preocupante y qué puede serlo menos. Lo primero que tenemos que hacer es volver a la interfaz web de OpenVAS una vez finalizado el escaneado. Los escaneos de redes grandes con muchos servicios pueden llevar mucho tiempo, sobre todo si haces escaneos profundos. En el menú Escaneos, encontrarás la opción Informes. Desde ahí, accederás al panel de Informes. Eso te dará una lista de todos los escaneos que has hecho, así como algunos gráficos de la gravedad de los hallazgos de tus escaneos. Puedes ver el panel de Informes de en la Figura 4-13.
Figura 4-13. Panel de informes
Cuando selecciones el escaneo del que quieres el informe, se te presentará una lista de todas las vulnerabilidades encontradas. Cuando utilizo la palabra informe, puede parecer que estamos hablando de un documento real, que sin duda puedes obtener, pero en realidad lo único que buscamos es la lista de hallazgos y sus detalles. Podemos obtener todo eso tan fácilmente de la interfaz web como de un documento. En la mayoría de los casos, me resulta más fácil pasar de la lista a los detalles según sea necesario. Tu propio kilometraje variará, por supuesto, en función de lo que te resulte más cómodo. La Figura 4-14 muestra la lista de vulnerabilidades resultante del escaneo de mi red. Me gusta mantener algunos sistemas vulnerables por diversión y con fines de demostración. Tenerlo todo actualizado no nos daría mucho que mirar.
Figura 4-14. Lista de vulnerabilidades
Verás ocho columnas en la lista de vulnerabilidades. Algunas de ellas se explican por sí mismas. Las columnas Vulnerabilidad y Gravedad deberían estar claras. La vulnerabilidad es una breve descripción del hallazgo. Pero merece la pena hablar de la gravedad. Esta evaluación se basa en el impacto que puede tener la explotación de la vulnerabilidad. El problema con la gravedad que proporciona el escáner de vulnerabilidades es que no tiene en cuenta nada más. Todo lo que sabe es la gravedad que acompaña a esa vulnerabilidad, independientemente de cualquier otra mitigación que exista y que pueda limitar la exposición a la vulnerabilidad. Aquí es donde tener una idea más amplia del entorno puede ayudar. Como ejemplo, digamos que hay un problema con un servidor web, como una vulnerabilidad en PHP, un lenguaje de programación para el desarrollo web. Sin embargo, el sitio web podría estar configurado con autenticación de dos factores, y se podría conceder un acceso especial sólo para este análisis. Esto significa que sólo los usuarios autenticados podrían acceder al sitio para explotar la vulnerabilidad.
El hecho de que existan mitigaciones para los problemas que puedan reducir su impacto global en la organización no significa que deban ignorarse. Lo único que significa es que el listón está más alto para un atacante, no que sea imposible que se produzca el exploit. La experiencia y un buen conocimiento del entorno te ayudarán a acertar en tus descubrimientos. El objetivo no debe ser asustar a la gente, sino proporcionarles una expectativa razonable de dónde se encuentran desde el punto de vista de la exposición al ataque. Si trabajas con la organización, lo ideal es que consigas que mejore su postura general en materia de seguridad.
La siguiente columna de la que hablaremos es la columna QoD, o Calidad de Detección. Como ya se ha indicado, el escáner de vulnerabilidades no puede estar absolutamente seguro de que la vulnerabilidad exista. La puntuación QoD indica el nivel de certeza del escáner de que la vulnerabilidad existe. Cuanto mayor sea la puntuación, más seguro está el escáner. Si tienes una QoD alta y una gravedad alta, probablemente se trate de una vulnerabilidad que alguien debería investigar. Como ejemplo, en la Figura 4-15 se muestra uno de los hallazgos. Tiene una QoD del 97% y una gravedad de 10, que es lo máximo que alcanza el escáner. OpenVAS considera que se trata de un problema grave que cree confirmado. Así lo demuestra la salida recibida del sistema bajo prueba.
Figura 4-15. Hallazgo de Ubuntu en OpenVAS
Cada hallazgo te dirá cómo se detectó la vulnerabilidad. En este caso, OpenVAS había obtenido acceso al sistema local y revisó una lista de los paquetes instalados. OpenVAS identificó que la versión instalada tiene una vulnerabilidad abierta que fue revelada por el desarrollador. Para comprobarlo, puedes revisar el informe CVE de. También puedes consultar la lista de paquetes instalados para verificar el número de versión instalada. Por último, y quizás lo más importante, puedes revisar el aviso de seguridad proporcionado por Canonical, la empresa que está detrás de Ubuntu. En algunos casos, es posible que existan medidas correctoras para limitar la exposición, mientras que la aplicación sigue llevando el mismo número de versión que el proporcionado por el mantenedor del paquete upstream.
Cuando obtengas resultados de algunos servicios, merece la pena que intentes duplicarlos manualmente lo mejor que puedas. Aquí es donde te conviene aumentar el registro todo lo que puedas. Puedes hacerlo yendo a las preferencias del escáner y activando Registrar todo el ataque. También puedes comprobar el registro de la aplicación objetivo para ver exactamente lo que se hizo. Repetir el ataque y luego modificarlo de forma útil puede ser importante. Puedes obtener un mensaje de error del servicio de escucha o, si se trata de una aplicación web, de la aplicación o del servidor de aplicaciones. Es posible que obtengas resultados de detección de baja calidad que aún pueden ser graves y que deben verificarse a mano.
Si necesitas ayuda para realizar la investigación y validación adicionales, las conclusiones tendrán una lista de recursos. Estas páginas web tendrán más detalles sobre la vulnerabilidad, lo que puede ayudarte a comprender el ataque para que puedas trabajar en duplicarlo. A menudo, estos recursos apuntan al anuncio de la vulnerabilidad. También pueden proporcionar detalles de los proveedores sobre correcciones o soluciones.
Otra columna a la que debes echar un vistazo de la Figura 4-14 es la segunda columna, que está etiquetada sólo con un icono. Es la columna que indica el tipo de solución. Las soluciones pueden incluir soluciones alternativas, correcciones del proveedor o mitigaciones. Cada hallazgo proporcionará detalles adicionales sobre las soluciones o arreglos que pueden ser posibles. Una de las vulnerabilidades detectadas se refería a características de un servidor SMTP que podrían conducir a un atacante a información sobre direcciones de correo electrónico. La Figura 4-16 muestra uno de los hallazgos y su solución. Esta solución concreta es una corrección del proveedor. En este caso, la solución consiste en actualizar el software instalado a la última versión. También puedes encontrar soluciones en las vulnerabilidades identificadas, y la solución estará documentada.
Figura 4-16. Solución OpenVAS
Las últimas columnas que debes mirar son las de Anfitrión y Ubicación. El host te indica qué sistema tenía la vulnerabilidad. Esto es importante para que tu organización sepa en qué sistema debe realizar el trabajo de configuración. La ubicación te indica en qué puerto se ejecuta el servicio objetivo. Esto te permite saber dónde debes dirigir tus pruebas adicionales. Cuando proporciones detalles a la organización, es importante incluir el sistema afectado. También incluyo cualquier mitigación o solución que pueda estar disponible cuando escribo informes para los clientes.
Vulnerabilidades de los dispositivos de red
OpenVAS es capaz de probar dispositivos de red. Si tus dispositivos de red son accesibles a través de las redes que estás escaneando, pueden ser tocados por OpenVAS, que puede detectar el tipo de dispositivo y aplicar las pruebas adecuadas. Sin embargo, con Kali también se incluyen programas específicos para dispositivos de red y proveedores. Dado que Cisco es un proveedor de redes habitual, hay más posibilidades de que alguien desarrolle herramientas y exploits contra esos dispositivos. Cisco tiene una cuota de mercado mayoritaria en enrutamiento y conmutación, por lo que esos dispositivos son buenos objetivos para los ataques.
Los dispositivos de red suelen gestionarse a través de redes. Esto puede hacerse a través de interfaces web mediante HTTP(S) o en una consola mediante un protocolo como SSH o -mucho menos ideal pero aún una posibilidad remota- Telnet. Una vez que tienes cualquier dispositivo en una red, tiene el potencial de ser explotado. Utilizando las herramientas disponibles en Kali, puedes empezar a identificar posibles vulnerabilidades en la infraestructura crítica de la red.
Dispositivos de auditoría
En primer lugar, utilizaremos una herramienta para realizar algunas auditorías básicas de los dispositivos Cisco de la red. La Herramienta de Auditoría de Cisco (CAT) se utiliza para intentar iniciar sesión en los dispositivos que le proporciones. Lo hace a partir de una lista de palabras proporcionada con la que intentar iniciar sesión. El inconveniente de utilizar esta herramienta es que utiliza Telnet para intentar las conexiones en lugar de SSH, que sería más habitual en redes bien protegidas. Cualquier gestión a través de Telnet puede ser interceptada y leída en texto plano, porque así es como se transmite. Dado que la gestión de los dispositivos de red incluirá contraseñas, es más habitual utilizar protocolos cifrados como SSH para la gestión.
Nota
Muchas de las herramientas de esta sección no estarán instaladas en Kali por defecto. Los paquetes están disponibles, pero probablemente no estarán ahí cuando intentes ejecutarlas por primera vez. Afortunadamente, Kali normalmente se dará cuenta de lo que intentas hacer y te sugerirá un paquete que instalará la herramienta que intentas ejecutar. Siempre puedes buscar e instalar por adelantado, pero también puedes simplemente intentar ejecutar la herramienta y dejar que Kali te ayude a instalarla.
El CAT también puede investigar un sistema utilizando el Protocolo simple de gestión de redes (SNMP). La versión de SNMP que utiliza el CAT está anticuada. Esto no quiere decir que algunos dispositivos no sigan utilizando versiones anticuadas de protocolos como SNMP. El SNMP puede utilizarse para recopilar información sobre la configuración, así como sobre el estado del sistema. La versión antigua de SNMP utiliza una cadena de comunidad para la autenticación, que se proporciona en texto claro porque la primera versión de SNMP no utiliza encriptación. CAT utiliza una lista de posibles cadenas de comunidad, aunque durante mucho tiempo fue habitual que la cadena de comunidad de sólo lectura fuera pública y la de lectura-escritura fuera privada. Eran las predeterminadas en muchos casos, y a menos que se cambiara la configuración del sistema, eso es lo que tendrías que suministrar.
CAT es un programa fácil de ejecutar. Es un script Perl que llama a módulos individuales para ejecutar SNMP y fuerza bruta. Como ya he indicado, requiere que proporciones los hosts. Puedes proporcionar un único host o un archivo de texto con una lista de hosts. El Ejemplo 4-10 muestra la ayuda de CAT y cómo ejecutarlo con dispositivos Cisco.
Ejemplo 4-10. Salida CAT
┌──(kilroy@badmilo)-[/etc/default]
└─$ CAT
Cisco Auditing Tool - g0ne [null0]
Usage:
-h hostname (for scanning single hosts)
-f hostfile (for scanning multiple hosts)
-p port # (default port is 23)
-w wordlist (wordlist for community name guessing)
-a passlist (wordlist for password guessing)
-i [ioshist] (Check for IOS History bug)
-l logfile (file to log to, default screen)
-q quiet mode (no screen output)El programa cisco-torch puede utilizarse para buscar dispositivos Cisco. Una de las diferencias entre éste y CAT es que cisco-torch puede utilizarse para buscar puertos/servicios SSH disponibles. Además, los dispositivos Cisco pueden almacenar y recuperar configuraciones de servidores Trivial File Transfer Protocol (TFTP). cisco-torch puede utilizarse para tomar huellas digitales tanto de servidores TFTP como de servidores Network Transfer Protocol (NTP). Esto ayudará a identificar la infraestructura relacionada tanto con los dispositivos Cisco Internetwork Operating System (IOS) como con la infraestructura de soporte de dichos dispositivos. IOS es el sistema operativo que Cisco utiliza en sus routers y conmutadores empresariales. El Ejemplo 4-11 muestra un escaneo de una red local en busca de servidores Telnet, SSH y web de Cisco. Todos estos protocolos pueden utilizarse para gestionar remotamente los dispositivos Cisco.
Nota
Cisco lleva décadas utilizando su IOS. No hay que confundir IOS con iOS, que es como Apple llama al sistema operativo que controla sus dispositivos móviles.
Ejemplo 4-11. Salida de cisco-torch
┌──(kilroy@badmilo)-[~] └─$ cisco-torch -t -s -w 192.168.1.0/24 Using config file torch.conf... Loading include and plugin ... ############################################################### # Cisco Torch Mass Scanner # # Because we need it... # # http://www.arhont.com/cisco-torch.pl # ############################################################### List of targets contains 256 host(s) Will fork 50 additional scanner processes Range Scan from 192.168.1.0 to 192.168.1.5 528028: Checking 192.168.1.0 ... HUH db not found, it should be in fingerprint.db Skipping Telnet fingerprint Range Scan from 192.168.1.48 to 192.168.1.53 528036: Checking 192.168.1.48 ... Range Scan from 192.168.1.24 to 192.168.1.29 528032: Checking 192.168.1.24 ... HUH db not found, it should be in fingerprint.db HUH db not found, it should be in fingerprint.db Skipping Telnet fingerprint Range Scan from 192.168.1.30 to 192.168.1.35 Skipping Telnet fingerprint Range Scan from 192.168.1.72 to 192.168.1.77 528040: Checking 192.168.1.72 ... 528033: Checking 192.168.1.30 ... HUH db not found, it should be in fingerprint.db Range Scan from 192.168.1.66 to 192.168.1.71 528039: Checking 192.168.1.66 ... Skipping Telnet fingerprint HUH db not found, it should be in fingerprint.db Skipping Telnet fingerprint Range Scan from 192.168.1.84 to 192.168.1.89 528042: Checking 192.168.1.84 ...
Los dispositivos Cisco tienen vulnerabilidades conocidas. Esto no dice nada en absoluto sobre Cisco o sus desarrolladores, sino todo sobre el hecho de tener mucho código en dispositivos complejos, así como una larga trayectoria de ser una opción muy común para las empresas en equipos de red. Como siempre, los atacantes dedicarán tiempo a buscar vulnerabilidades en sistemas de uso común. Ejecutar escáneres de red u otras herramientas que identifiquen dispositivos Cisco en la red es una cosa, pero en algún momento también querrán identificar vulnerabilidades. En consecuencia, tenemos que ser capaces de identificar vulnerabilidades en los dispositivos de la red. Afortunadamente, además de utilizar OpenVAS para el escaneo de vulnerabilidades, que también puede buscar vulnerabilidades en dispositivos de red como los fabricados por Cisco, Kali incluye un script Perl para buscar vulnerabilidades de Cisco. Este script de, cge.pl, conoce vulnerabilidades específicas relacionadas con los dispositivos Cisco. El Ejemplo 4-12 muestra la lista de vulnerabilidades que pueden comprobarse con cge.pl, así como la forma de ejecutar el script, que toma un objetivo y un número de vulnerabilidad.
Ejemplo 4-12. Ejecución de cge.pl para la exploración de vulnerabilidades de Cisco
┌──(kilroy@badmilo)-[~] └─$ cge.pl Usage : perl cge.pl <target> <vulnerability number> Vulnerabilities list : [1] - Cisco 677/678 Telnet Buffer Overflow Vulnerability [2] - Cisco IOS Router Denial of Service Vulnerability [3] - Cisco IOS HTTP Auth Vulnerability [4] - Cisco IOS HTTP Configuration Arbitrary Administrative Access Vulnerability [5] - Cisco Catalyst SSH Protocol Mismatch Denial of Service Vulnerability [6] - Cisco 675 Web Administration Denial of Service Vulnerability [7] - Cisco Catalyst 3500 XL Remote Arbitrary Command Vulnerability [8] - Cisco IOS Software HTTP Request Denial of Service Vulnerability [9] - Cisco 514 UDP Flood Denial of Service Vulnerability [10] - CiscoSecure ACS for Windows NT Server Denial of Service Vulnerability [11] - Cisco Catalyst Memory Leak Vulnerability [12] - Cisco CatOS CiscoView HTTP Server Buffer Overflow Vulnerability [13] - 0 Encoding IDS Bypass Vulnerability (UTF) [14] - Cisco IOS HTTP Denial of Service Vulnerability
Una última herramienta de Cisco que puedes consultar es cisco-ocs. Se trata de otro escáner de Cisco, pero no se necesitan parámetros para realizar las pruebas. No eliges lo que hace cisco-ocs; simplemente lo hace. Lo único que tienes que hacer es proporcionar el rango de direcciones. Puedes ver una ejecución de cisco-ocs en el Ejemplo 4-13. Después de indicarle el rango de direcciones y las IP de inicio y fin, la herramienta empezará a probar cada dirección por turnos en busca de puntos de entrada y posiblesvulnerabilidades.
Ejemplo 4-13. Ejecutar cisco-ocs
┌──(kilroy@badmilo)-[~] └─$ cisco-ocs 192.168.1.1 192.168.1.254 ********************************* OCS v 0.2 ****************************** **** **** **** coded by OverIP **** **** overip@gmail.com **** **** under GPL License **** **** **** **** usage: ./ocs xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy **** **** xxx.xxx.xxx.xxx = range start IP **** **** yyy.yyy.yyy.yyy = range end IP **** **** **** ************************************************************************** (192.168.1.1) Filtered Ports (192.168.1.2) Filtered Ports
Como puedes ver en estas herramientas, varios programas buscan dispositivos Cisco y vulnerabilidades potenciales. Si puedes encontrar estos dispositivos y muestran puertos abiertos para probar inicios de sesión o, peor aún, vulnerabilidades, sin duda merece la pena marcarlos como dispositivos para buscar exploits. Esto no quiere decir que los dispositivos Cisco sean los únicos dispositivos de red disponibles, pero llevan existiendo el tiempo suficiente y tienen suficientes dispositivos instalados en todo el mundo como para constituir un objetivo atractivo para el desarrollo de herramientas. Con el tiempo, a medida que más empresas como Palo Alto Networks y otras consigan más tracción de la que ya tienen, puedes esperar que estén disponibles herramientas de código abierto que los escaneen e identifiquen vulnerabilidades.
Vulnerabilidades de la base de datos
Los servidores de la base de datos suelen tener mucha información sensible, aunque suelen estar en redes aisladas. Sin embargo, no siempre es así. Algunas organizaciones también pueden creer que aislar la base de datos la protege, lo cual no es cierto. Si un atacante puede atravesar el servidor web o el servidor de aplicaciones, ambos sistemas pueden tener conexiones de confianza con la base de datos. Esto expone mucha información a los ataques. Cuando trabajas en estrecha colaboración con una empresa, puedes obtener acceso directo a la red aislada para buscar vulnerabilidades. Independientemente de dónde resida el sistema, las organizaciones deberían bloquear sus bases de datos y remediar cualquier vulnerabilidad encontrada.
Oracle es una gran empresa que construyó su negocio sobre bases de datos empresariales. Si una empresa necesita grandes bases de datos con información sensible, es muy posible que haya recurrido a Oracle. El programa oscanner que viene instalado en Kali escanea las bases de datos Oracle para realizar comprobaciones. El programa utiliza una arquitectura de plug-in para permitir pruebas de las bases de datos Oracle, incluido el intento de obtener los identificadores de seguridad (SID) del servidor de la base de datos, listar cuentas, descifrar contraseñas y varios ataques más. oscanner está escrito en Java, por lo que debería ser portátil en varios sistemas operativos.
oscanner también viene con varias listas, incluidas listas de cuentas, usuarios y servicios. Algunos de los archivos no tienen muchas posibilidades, pero son puntos de partida para ataques contra Oracle. Como con tantas otras herramientas con las que te encontrarás, irás reuniendo tu propia colección de identificadores de servicios, usuarios y posibles contraseñas a medida que avances. Puedes ampliar estos archivos para probar mejor las bases de datos Oracle. A medida que pruebes más y más sistemas y redes, deberías ir aumentando las posibilidades de datos que tienes para realizar comprobaciones. Con el tiempo, esto aumentará las posibilidades de éxito. Ten en cuenta que cuando ejecutes listas de palabras para nombres de usuario y contraseñas, sólo tendrás éxito si el nombre de usuario o la contraseña configurados en el sistema coinciden exactamente con algo de las listas de palabras.
Identificar nuevas vulnerabilidades
El software tiene fallos. Es la naturaleza de la bestia. El software, especialmente el de mayor tamaño, es complejo. A mayor complejidad, más posibilidades de error. Piensa en todas las elecciones que se hacen en el transcurso de la ejecución de un programa. Si empiezas a calcular todas las trayectorias de ejecución potenciales a través de un programa, llegarás rápidamente a grandes números. ¿Cuántas de esas rutas de ejecución completas se comprueban cuando se realizan pruebas de software? Lo más probable es que sólo un subconjunto de todo el conjunto de rutas de ejecución. Incluso si se prueban todas las rutas de ejecución, ¿qué tipo de entradas se prueban?
Algunas pruebas de software pueden centrarse en pruebas funcionales. Se trata de verificar que la funcionalidad especificada es correcta. Puedes hacerlo mediante pruebas positivas: asegurándote de que lo que ocurre es lo que se espera que ocurra. También puede haber cierta cantidad de pruebas negativas: quieres asegurarte de que tu programa falla educadamente si ocurre algo inesperado. Es esta prueba negativa la que puede ser difícil de realizar, porque si tienes un conjunto de datos que esperas, es sólo un conjunto parcial comparado con todo lo que podría ocurrir en el curso de la ejecución de un programa, especialmente uno que toma la entrada del usuario en algún momento.
La prueba de límites se produce cuando vas más allá de los límites de la entrada esperada. Compruebas los perímetros de los valores máximos o mínimos y justo fuera de los máximos o mínimos, buscando errores y un manejo correcto de la entrada.
Enviar a las aplicaciones datos que no esperan es una forma de identificar fallos en un programa. Puedes obtener mensajes de error que proporcionen información que puede ser útil, o puedes conseguir que el programa se bloquee. Una forma de conseguirlo es utilizar una clase de aplicaciones llamadas fuzzers. Un fuzzer genera datos aleatorios o variables para proporcionar a una aplicación. La entrada se genera programáticamente basándose en un conjunto de reglas.
Nota
Algunas personas pueden considerar el fuzzing como una prueba de caja opaca en, porque el programa de fuzzing no tiene conocimiento del funcionamiento interno de la aplicación del servicio. Envía datos, independientemente de cómo espere el programa que sea la entrada. Aunque tengas acceso al código fuente, no estás desarrollando las pruebas que ejecutas con un fuzzer con respecto al aspecto del código fuente. Desde ese punto de vista, la aplicación bien puede ser una caja opaca, aunque tengas el código fuente.
Kali tiene unos cuantos fuzzers instalados y otros más que se pueden instalar. El primero que hay que ver, sfuzz, se utiliza para enviar tráfico de red a servidores. sfuzz tiene una colección de archivos de reglas que indican al programa cómo crear los datos que se envían. Algunos de ellos se basan en protocolos concretos. Por ejemplo, el Ejemplo 4-14 muestra el uso de sfuzz para enviar tráfico SMTP a un servidor de correo electrónico. La bandera -T indica que estamos utilizando TCP, y la bandera -s dice que vamos a hacer fuzzing secuencial en lugar de fuzzing literal. La opción -f indica que utilicemos el archivo /usr/share/sfuzz-db/basic.smtp como entrada para el fuzzer. Por último, las banderas -S y -p indican la dirección IP y el puerto de destino, respectivamente.
Ejemplo 4-14. Utilizar sfuzz para fuzzear un servidor SMTP
┌──(kilroy@badmilo)-[~]
└─$ sudo sfuzz -T -s -f /usr/share/sfuzz-db/basic.smtp -S 127.0.0.1 -p 25
[17:37:30] dumping options:
filename: </usr/share/sfuzz-db/basic.smtp>
state: <8>
lineno: <14>
literals: [30]
sequences: [31]
symbols: [0]
req_del: <200>
mseq_len: <50050>
plugin: <none>
s_syms: <0>
<-- snip -->
[17:37:30] info: beginning fuzz - method: tcp, config from: ↩
[/usr/share/sfuzz-db/basic.smtp], out: [127.0.0.1:25]
[17:37:30] attempting fuzz - 1 (len: 50057).
[17:37:30] info: tx fuzz - (50057 bytes) - scanning for reply.
[17:37:30] read:
220 badmilo.washere.com ESMTP Postfix (Debian/GNU)
250 badmilo.washere.com
========================================================================
[17:37:30] attempting fuzz - 2 (len: 50057).
[17:37:30] info: tx fuzz - (50057 bytes) - scanning for reply.
[17:37:30] read:
220 badmilo.washere.com ESMTP Postfix (Debian/GNU)
250 badmilo.washere.com
========================================================================
[17:37:30] attempting fuzz - 3 (len: 50057).
[17:37:30] info: tx fuzz - (50057 bytes) - scanning for reply.
[17:37:30] read:
220 badmilo.washere.com ESMTP Postfix (Debian/GNU)
250 badmilo.washere.com
========================================================================
[17:37:30] attempting fuzz - 4 (len: 50057).
[17:37:30] info: tx fuzz - (50057 bytes) - scanning for reply.
[17:37:31] read:
220 badmilo.washere.com ESMTP Postfix (Debian/GNU)
250 badmilo.washere.com
========================================================================
[17:37:31] attempting fuzz - 5 (len: 50057).
[17:37:31] info: tx fuzz - (50057 bytes) - scanning for reply.
[17:37:31] read:
220 badmilo.washere.com ESMTP Postfix (Debian/GNU)
250 badmilo.washere.com
=========================================================================
Un de los problemas que plantea el uso de ataques de fuzzing es que pueden generar caídas del programa. Aunque ésta es, en última instancia, la intención del ejercicio, la cuestión es cómo determinar cuándo el programa se ha bloqueado realmente. Puedes hacerlo manualmente, por supuesto, ejecutando el programa bajo prueba en una sesión de depuración para que el depurador detecte el fallo. El problema con este enfoque es que puede ser difícil saber qué caso de prueba causó el fallo, y aunque encontrar un fallo es bueno, el mero hecho de conseguir que un programa se bloquee no es suficiente para identificar vulnerabilidades o crear exploits que se aprovechen de la vulnerabilidad. Después de todo, un fallo no es necesariamente una vulnerabilidad. Puede ser simplemente un fallo. Se pueden utilizar paquetes de software para integrar el monitoreo de programas con las pruebas de aplicaciones. Puedes utilizar un programa como valgrind para instrumentar tu análisis. El Ejemplo 4-15 muestra el arranque de un servidor POP3 con la herramienta memcheck de valgrind. Esto vigilará las fugas de memoria.
Ejemplo 4-15. Comprobación de fugas de memoria con valgrind
┌──(kilroy@badmilo)-[~] └─$ sudo valgrind --tool=memcheck popa3d ==552080== Memcheck, a memory error detector ==552080== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==552080== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info ==552080== Command: popa3d ==552080== +OK
Una vez que tengas valgrind funcionando con un servicio, puedes ejecutar una herramienta como sfuzz contra él para ver si puedes encontrar fugas de memoria. Por supuesto, valgrind también incluye otras funciones además de memcheck que puedes utilizar para instrumentar tus aplicaciones. El reto con una herramienta como valgrind es que necesita que el programa al que llama permanezca en ejecución. Muchos servicios quieren estar en modo demonio, lo que significa que parecen terminar limpiamente desde la perspectiva del terminal donde lo ejecutas. El programa llamado llama a su vez a otro programa, pero es el programa llamado el que valgrind vigila. En cuanto se detiene, valgrind ya no tiene nada que vigilar. Hay opciones para que valgrind siga procesos hijo que pueden ayudar en estas circunstancias. Sin embargo, esta herramienta te dará una idea de lo que ocurre con el programa bajo prueba mientras trabajas en la comprobación de aplicaciones.
En algunos casos, puedes encontrar programas dirigidos a aplicaciones o protocolos específicos. Mientras que sfuzz es un programa de fuzzing de uso general que puede ir tras múltiples protocolos, programas como protos-sip están diseñados específicamente para probar el Protocolo de Iniciación de Sesión (SIP), un protocolo común utilizado en las implementaciones de VoIP. El paquete protos-sip es una aplicación Java que se desarrolló como parte de un programa de investigación. La investigación se convirtió en la creación de una empresa que vende software desarrollado para fuzzear protocolos de red.
No todas las aplicaciones son servicios que escuchan la entrada de datos en las redes. Muchas aplicaciones reciben datos en forma de archivos. Incluso algo como sfuzz, que toma definiciones como entrada, las toma en forma de archivos. Ciertamente, los procesadores de texto, los programas de hojas de cálculo, los programas de presentación y una amplia variedad de otros tipos de software utilizan archivos. Algunos fuzzers se desarrollan con el fin de probar aplicaciones que toman archivos como entrada.
Un programa que puedes utilizar para realizar una gama más amplia de pruebas fuzz es zzuf. Este programa puede manipular la entrada de un programa para introducir datos inesperados. El Ejemplo 4-16 muestra una ejecución de zzuf contra el programa pdf-parser, que es un script de Python utilizado para obtener información de un archivo PDF. Lo que estamos haciendo es pasar la ejecución del programa a zzuf como un parámetro de la línea de comandos después de haberle dicho a zzuf lo que tiene que hacer. Sin embargo, este programa plantea un problema. Es una herramienta antigua, por lo que no se ha probado con versiones más actuales de Python. Aquí verás los errores.
Ejemplo 4-16. Fuzzing pdf-parser con zzuf
┌──(kilroy@badmilo)-[~] └─$ zzuf -s 0:10 -c -C 0 -T 3 pdf-parser -a fuzzing.pdf This program has not been tested with this version of Python (3.11.4) Should you encounter problems, please use Python version 3.11.1 Comment: 151 XREF: 1 Trailer: 1 StartXref: 1 Indirect object: 1 Indirect objects with a stream: 1: 2020 Unreferenced indirect objects: 2020 2 R This program has not been tested with this version of Python (3.11.4) Should you encounter problems, please use Python version 3.11.1 Comment: 56 XREF: 0 Trailer: 1 StartXref: 0 Indirect object: 32 Indirect objects with a stream: 2022, 2030, 2033, 2034, 2037, 2040, 2, 6, 9, 11, ↩ 12, 14, 16, 18, 20, 21 15: 2022, 2021, 2033, 2034, 2036, 2037, 2040, 2, 3, 5, 12, 18, 24, 26, 27 /EztGState 1: 2029 /Font 2: 2025, 2026 /FontDescrip4or 1: 2027 /OCG 1: 2123 /OCMD 1: 2030 /ObjStm 7: 6, 9, 14, 16, 17, 20, 21 /OâjStm 1: 11 /Page 1: 2024 /Pages 1: 25 /XRef 1: 2041 Unreferenced indirect objects: 2 0 R, 3 1 R, 5 0 R, 6 0 R, 9 0 R, 11 0 R, 12 0 R, ↩ 14 0 R, 16 0 R, 17 0 R, 18 0 R, 20 0 R, 21 0 R, 24 0 R, 26 0 R, 2022 0 R, ↩ 2024 0 R, 2036 0 R, 2037 0 R, 2041 0 R, 2123 0 R Unreferenced indirect objects without /ObjStm objects: 2 0 R, 3 1 R, 5 0 R, ↩ 11 0 R, 12 0 R, 18 0 R, 24 0 R, 26 0 R, 2022 0 R, 2024 0 R, 2036 0 R, ↩ 2037 0 R, 2041 0 R, 2123 0 R
En la línea de comandos de zzuf, le estamos diciendo que utilice valores semilla(-s) y que fuzz la entrada sólo en la línea de comandos. Cualquier programa que lea archivos de configuración para su funcionamiento no debería alterar esos archivos de configuración durante su ejecución. Lo que queremos es alterar sólo la entrada del archivo que estamos especificando. Especificar -C 0 indica a zzuf que no se detenga tras el primer fallo. Por último, -T 3 dice que debemos esperar 3 segundos para que la prueba no se bloquee.
Utilizar una herramienta como ésta puede proporcionar mucho potencial para identificar fallos en aplicaciones que leen y procesan archivos; en concreto, un lector de PDF, en este caso. Como programa de uso general, zzuf tiene potencial incluso más allá de las capacidades limitadas que se muestran aquí. Además del fuzzing de archivos, puede utilizarse para el fuzzing de redes. Si te interesa localizar vulnerabilidades, un poco de tiempo utilizando zzuf podría ser bien empleado.
Resumen
Las vulnerabilidades son las puertas potencialmente abiertas por las que pueden entrar los ataques mediante el uso de exploits. Identificar las vulnerabilidades es una tarea importante para alguien que realice pruebas de seguridad, ya que remediar las vulnerabilidades es un elemento importante del programa de seguridad de una organización. Aquí encontrarás algunas ideas que te puedes llevar:
-
Una vulnerabilidad es un punto débil de un programa informático o de un sistema. Una vulnerabilidad es un fallo, pero un fallo puede no ser una vulnerabilidad.
-
Un exploit es un medio de aprovechar una vulnerabilidad para obtener algo a lo que el atacante no debería tener acceso.
-
OpenVAS es un escáner de vulnerabilidades de código abierto que puede utilizarse para buscar vulnerabilidades tanto remotas como locales.
-
Las vulnerabilidades locales requieren que alguien tenga algún tipo de acceso autenticado, lo que puede hacerlas menos críticas para algunas personas, pero siguen siendo esenciales para remediarlas, ya que pueden utilizarse para permitir la escalada de privilegios.
-
Los dispositivos de red también están abiertos a vulnerabilidades y pueden proporcionar a un atacante acceso para alterar los flujos de tráfico. La búsqueda de vulnerabilidades en los dispositivos de red puede realizarse mediante OpenVAS u otras herramientas específicas, incluidas las centradas en dispositivos Cisco.
-
Identificar vulnerabilidades que no existen puede llevar algo de trabajo, pero herramientas como los fuzzers pueden ser útiles para provocar fallos del programa, que pueden ser vulnerabilidades.
Recursos útiles
-
Proyecto Abierto de Seguridad de las Aplicaciones Web (OWASP) Fuzzing
-
Presentación de Mateusz Jurczyk en Black Hat: "Fuzzing eficaz de formatos de archivo".
-
Blog de José Ramón Palanco, "El asombroso mundo del File Fuzzing"
-
Tutorial de Hanno Böck, "Guía para principiantes sobre Fuzzing"
-
Hacker Target, "Tutorial OpenVAS"
-
El Oficio de Codificar, "Programación Defensiva, Validación de Entradas en C y Fortran"
Get Aprendiendo Kali Linux, 2ª Edición now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
