Cómo Realizar Un Penetration Test - Fabian Portantier

Como todos los trabajos, ser un profesional de la seguridad informática tiene sus partes divertidas y sus partes aburridas y uno de las temas más entretenidos es el de realizar pruebas de intrusión, o Penetration Tests que consisten, básicamente, en hacer lo que haría una persona que quisiera atacar los sistemas de la organización para la cual hacemos el trabajo.

En los próximos artículos voy a dar varios consejos acerca de cómo debe realizarse un Penetration Test de manera profesional. Primero que nada, veremos algunos temas burocráticos que deberemos respetar antes de empezar a trabajar en un Penetration Test

Un poco de burocracia hacker

Lo más importante: este tipo de trabajos debe realizarse sólo bajo el consentimiento escrito de los propietarios de los sistemas sobre los cuales vamos a realizar las pruebas. Esto es importante tanto para el ‘atacante’ como para el ‘atacado’.

Tenemos que definir exactamente qué sistemas vamos a atacar y con qué propósitos (si buscamos destruir, robar, modificar). Definir las horas en las cuales vamos a realizar los ataques y hasta dónde vamos a llegar. Es decir, si vamos a buscar vulnerabilidades que podrían ser explotadas, o si directamente vamos a explotarlas para verificar si realmente eran vulnerabilidades.

Todas estas cosas deben ser aclaradas de antemano, con el fin de que nuestro cliente no se lleve una sorpresa desagradable al ver daños inesperados en su infraestructura tecnológica y que nosotros no nos llevemos la desagradable sorpresa de un cliente molesto y varias demandas en nuestra contra.

Más adentrados en la parte técnica, veremos que hay dos formas de clasificar a un Penetration Test:

- Si es externo o interno. Básicamente indica dónde vamos a estar ‘parados’ al realizar las pruebas. Dentro de la red interna, o fuera de la red (generalmente, a través de internet).

- Si contamos con información de los sistemas que vamos a atacar. De ser así, se los denomina White-Box. De no contar con información acerca de los sistemas, estamos ante un Black-Box. Entre las White y las Black existen algunos intermedios, pero no son tan comunes.

Una vez definido esto, empezaremos a realizar las pruebas sobre los sistemas en cuestión. Para el caso de estos ejemplos, vamos a hablar de un penetration test del tipo Black-Box Externo (atacando desde internet, y sólo conociendo el nombre de la empresa que queremos atacar).

NOTA: En los siguientes ejemplos vamos a utilizar nombre de compañías ficticias y direcciones IP inválidas para proteger la privacidad de las empresas analizadas.

Paso1: Recolectamos información

En este paso vamos a ser una especie de ‘detectives’, con la misión de conseguir toda la información posible acerca de la organización que vamos a atacar.

La organización que nos ha contratado para este trabajo se llama ‘Sin Nombre S.A.’, así que lo primero que vamos a hacer será escribir eso en nuestro buscador favorito (en mi caso, Google).

Es muy probable que, dentro de los primeros resultados, veamos el sitio web de la empresa en cuestión. Tomaremos nota de la dirección para visitarla luego.

Como el nombre del sitio es No puedes ver links Registrate o Login, podemos buscar la información correspondiente al registro de ese dominio en el sitio web de nic.ar (No puedes ver links Registrate o Login), el cual va a mostrarnos información como:

- Nombre de la entidad registrante (persona física o jurídica)
- Dirección, teléfono, etc.
- Mismos datos del contacto técnico
- Datos de los servidores DNS para ese dominio

Además, utilizando los buscadores de internet, también podremos encontrar documentos de la organización, información de los empleados, datos privados, etc. Pero ése es  tema para otro artículo, que podríamos llamar “Google Hacking” (Si no quieren esperar a que tenga tiempo de escribir dicho artículo, pueden buscar el término en internet, incluso existen libros acerca de ese tema).

Con estos datos vamos a poder empezar a trabajar en niveles más técnicos (y más entretenidos), que vamos a analizar.

Vamos a utilizar los datos obtenidos de las consultas al dominio, para buscar todos los recursos accesibles a través de internet.

Lo primero que podemos hacer es utilizar el comando ‘dig’ para obtener la información acerca de los servidores DNS asociados a dicho dominio. Por ejemplo

fabian@debian:~$ dig sinnombre.com.ar NS

; <<>> DiG 9.7.3 <<>> sinnombre.com.ar NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58741
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;sinnombre.com.ar.            IN    NS

;; ANSWER SECTION:
sinnombre.com.ar.        576    IN    NS    ns1.sinnombre.com.ar.
sinnombre.com.ar.        576    IN    NS    ns2.sinnombre.com.ar.

;; Query time: 13 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Wed Jun  1 22:23:59 2011
;; MSG SIZE  rcvd: 68
=========================================================================

De aquí podemos ver que los servidores ns1.sinnombre.com.ar y ns2.sinnombre.com.ar son los encargados de los DNS de este dominio.

Ya con esto podemos utilizar el comando ‘fpdns’ para obtener más información acerca de cada uno de ellos:

fabian@debian:~$ fpdns ns1.sinnombre.com.ar
fingerprint (ns1.sinnombre.com.ar, 123.123.123.123): Microsoft Windows DNS 2003

Con esto ya sabemos que el servidor DNS es un Windows 2003 Server. Lo cual es un dato no menor.

Vamos a guardar los datos del equipo en nuestra lista de activos a analizar.

Nuestro siguiente paso será volver a utilizar el comando ‘dig’, esta vez para averiguar los servidores de correo, así:

fabian@debian: ~$ dig sinnombre.com.ar MX

De aquí vamos a hacer un análisis similar al de la consulta anterior, y guardaremos los registros MX que asocian a cada servidor de correo. En este caso SIN NOMBRE S.A. utiliza un único servidor: mx.sinnombre.com.ar

Ahora podemos analizar el servidor de correo (SMTP), con el siguiente comando:

fabian@debian:~$ telnet mx.sinnombre.com.ar 25
Trying 111.222.111.222
Connected to mx.sinnombre.com.ar.
Escape character is ‘^]’.
220 mx.sinnombre.com.ar ESMTP MDaemon 10.0.0; Wed, 01 Jun 2011 22:32:29 -0300

Rápidamente podemos observar el tipo de servidor de correo y su versión (MDaemon 10.0.0). También tenemos que guardar estos datos en nuestra lista de activos analizados.

Lo que debemos hacer ahora es buscar en el sitio web del fabricante del software SMTP (No puedes ver links Registrate o Login) cuál es la última versión de este software. Al día 01/06/2011, la última versión es la 12. Así que en el caso de SIN NOMBRE S.A. el software está muy desactualizado.

Esto, de por sí, ya puede considerarse una falla de seguridad. Pero, para ir más allá de esto, podemos buscar en internet cuáles son las vulnerabilidades existentes en MDaemon 10.0.0

Por ejemplo, en el sitio web de Tenable podemos encontrar el siguiente reporte:

No puedes ver links Registrate o Login

Este reporte indica una vulnerabilidad explotable en las versiones anteriores a la 10.0.2, así podemos ir armando el listado de posibles vulnerabilidades a los sistemas de la empresa analizada.

En estos casos debemos recordar siempre que si vamos a utilizar exploits que han sido desarrollados por desconocidos, debemos verificar exactamente qué hace el código o, por lo menos, hacer pruebas en servidores que no sean productivos.

También podemos probar rápidamente si los servidores de correo tienen abiertos los puertos 110 (POP3) e IMAP (143), directamente haciendo telnet a estos puertos. Como el SMTP es un MDaemon, que tiene todo el paquete integrado de webmail, POP3, IMAP y SMTP, podemos estar casi seguros de que vamos a encontrar estos servicios también en la versión 10.0.0, y sólo será cuestión de investigar a través de internet cuáles son las vulnerabilidades conocidas para estos servicios.

Más adelante haremos escaneos más avanzados con otras herramientas.

Ahora que ya tenemos la información acerca de los servidores DNS y SMTP, podemos pasar a analizar los servidores web.

Ahora es el turno de cerrar esta clase magistral sobre Penetration Test y por eso analizaremos los servidores web.

Como el servidor web es No puedes ver links Registrate o Login, vamos a hacer un telnet al puerto 80 para obtener alguna que otra información básica

===============================================================================
fabian@debian:~$ telnet No puedes ver links Registrate o Login 80
Trying 112.112.112.112
Connected to No puedes ver links Registrate o Login
Escape character is ‘^]’.
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Server: Apache/2.0.59
Content-Type: text/html; charset=UTF-8
Date: Thu, 02 Jun 2011 01:54:34 GMT
Keep-Alive: timeout=5, max=100
Accept-Ranges: bytes
Connection: close
Set-Cookie: X-Mapping-fiodmlao=0BF0CD86ED36BA7FDA6B0F9FBB6640F2; path=/
Last-Modified: Tue, 24 Nov 2009 22:52:54 GMT
Content-Length: 201

Connection closed by foreign host.
===============================================================================

Aquí podemos ver la información básica del servidor web (Apache 2.0.59). Para obtener información más detallada acerca del mismo, es una excelente idea utilizar herramientas especializadas, como nikto, así:

fabian@debian:~$ nikto -host No puedes ver links Registrate o Login

Se nos ha devuelto la siguiente información:

+ robots.txt contains 6 entries which should be manually viewed.
+ Allowed HTTP Methods: GET, HEAD, POST, OPTIONS, TRACE
+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST
+ Retrieved X-Powered-By header: PHP/5.1.6
+ ETag header found on server, inode: 606154, size: 121, mtime: 0x26d3b100
+ Apache/2.0.59 appears to be outdated (current is at least Apache/2.2.14). Apache 1.3.41 and 2.0.63 are also current.

Con lo cual, podemos determinar que nuestro siguientes pasos serán:

- Analizar el archivo ‘robots.txt’ y buscar anormalidades
- Verificar si se podría explotar el método ‘TRACE’ para atacar el servidor
- Buscar vulnerabilidades en la versión de PHP instalada (5.1.6)
- Buscar vulnerabilidades en la versión de Apache instalada (2.0.59)

También podemos utilizar la herramienta nmap para obtener más información del servidor, así:

(utilizando sudo, porque las pruebas -O y -sV necesitan permisos de root)
fabian@debian:~$ sudo nmap -O -sV No puedes ver links Registrate o Login

Starting Nmap 5.00 ( No puedes ver links Registrate o Login ) at 2011-06-01 23:01 ART
Interesting ports on No puedes ver links Registrate o Login:
Not shown: 992 filtered ports
PORT     STATE  SERVICE    VERSION
20/tcp   closed ftp-data
21/tcp   open   ftp        ProFTPD 1.3.1
25/tcp   closed smtp
53/tcp   closed domain
80/tcp   open   http       Apache httpd 2.0.59 ((CentOS))
110/tcp  closed pop3
443/tcp  open   ssl/http   Apache httpd 2.0.59 ((CentOS))
8080/tcp closed http-proxy

De este reporte podemos ver que, además de estar corriendo un servidor Apache 2.0.59, el sistema operativo es un CentOS Linux. Con lo cual, podemos ver que la empresa utiliza tanto servidores Windows como Linux.

Otro dato interesante que podíamos ver en el reporte es que, además, está disponible el servicio FTP (ProFTPD 1.3.1), así que podemos iniciar pruebas contra ese servicio y buscar en internet cuáles la última versión del software ProFTPD y si existen vulnerabilidades que afecten a la versión 1.3.1 .

Las pruebas con nmap también podemos hacerlas contra los servidores DNS y SMTP, para recabar más datos aún. Y tener más información para encontrar vulnerabilidades asociadas al software de cada equipo.

Con todos estos datos ya podemos armar un buen mapa de los servicios básicos que está brindando SIN NOMBRE S.A. En base a esto vamos a poder obtener algunos otros datos adicionales, con algunas herramientas como Nessus, OpenVAS, Metasploit y otras que veremos en otros artículos.

En la próxima entrega vamos a analizar cuestiones de arquitectura de red de la empresa, e intentaremos obtener datos acerca de los routers y las direcciones ip que utiliza.


Autor: Fabian Portantier
Fuente: redusers.com