La Comunidad DragonJAR

Hace unos días en DragonJAR publicábamos un artículo sobre Dirb, para hacer fuzzing sobre servidores web. En el artículo explicábamos que con el fuzzing llegábamos a descubrir directorios ocultos entre otros cosas.

Vamos a ver un ejemplo práctico, pero hoy no usaremos Dirb, pasaremos a usar Wfuzz.

Página de acceso.

Tenemos la típica pagina de acceso a un recurso interno de una corporación.

La página de acceso es algo así como:

https://paginadeacceso.acceso.dragonjar.org

Cuando los clientes o proveedores externos entran a esa páginas son redireccionados hacia otra página donde han de introducir su usuario y password para acceder al recurso interno.

La URL a donde redireccionaba era algo así como:

https://acceso.dragonjar.org/acceso_1/index.php

El usuario era redirigido con un código 302.

Lo primero que haremos con curl, es ver como se comporta, así que lo hacemos.

darkmac:~ marc$ curl -I https://paginadeacceso.acceso.dragonjar.org
HTTP/1.1 302 Found
Location: https://acceso.dragonjar.org/acceso_1/index.php

Vi que siempre hacía el mismo 302 a el mismo sitio, así que lo más sencillo es lanzar un fuzzer para ver si hay más páginas.

¿Donde colocar el Fuzzer?

Pues el fuzzer lo podemos colocar en múltiples sitios, pero en este caso en concreto, lo colocaremos donde tenemos marcado el texto con negrita.

https://acceso.dragonjar.org/acceso_1/index.php

Vamos a generar un diccionario para que el fuzzer  pruebe distintas posibilidades.

Para generar el diccionario podemos tirar de bash, algo tan sencillo como:

for (( i=0; i<1000; i++ ))
do
echo $i
done

Una vez generada la lista que vamos a probar la lanzamos con Wfuzz, algo así como:

python wfuzz.py -c -z file,lista.txt –hc 404 -o html https://acceso.dragonjar.org/acceso_FUZZ/index.php 2> report.html

Ya hemos lanzado el fuzzer, una vez acabe guardará los resultados en un report que tendrá el siguiente aspecto:

A la izquierda tendremos el código de respuesta, como veis hemos encontrado varios códigos 200, por oq ue hay mas de una página de acceso.

Estarán securizadas?

Los ataques entre instituciones, gobiernos, países, empresas cada vez sen mas claros. La ciberguerra es algo que siempre ha estado presente pero que es hasta no hace poco tiempo que se está expresando públicamente.

Norman ha liberado un report sobre una investigación que ha realizado durante mas de un mes.

He estado leyendo el report y he querido compartirlo aquí en la comunidad DragonJAR.

La historia empieza cuando la empresa Telenor avisa de que  han sufrido una intrusión en sus instalaciones. Norman empieza la investigación y descubren patrones de ataques. La infraestructura detectada en la investigación pertenece presuntamente a India. Con las evidencias que obtienen persiguen las pistas que van encontrando y descubren que los atacantes no son muy buenos escondiendo sus pruebas. Estirando del hilo de las pruebas encontradas encontraron directorios accesibles con la información que habían robado entre otras cosas.

Imagen del blog de Norman

El espionaje industrial, parece uno de los objetivos, ESET publicó información sobre ello => http://www.welivesecurity.com/2013/05/16/targeted-threat-pakistan-india/

F-Secure publicó una entrada sobre Spyware para MAC que encontraron en el evento del Oslo freedom forum, han encontrado relación entre ambos casos por el mismo developer, mismo Apple iD etc..=> https://www.f-secure.com/weblog/archives/00002554.html

Los países que han sufrido los ataques han sido diversos, entre ellos países Bajos, Pakistán, EE.UU., Irán, China, Taiwán, Tailandia, Jordania, Indonesia, Reino Unido, Alemania, Austria, Polonia, Rumania etc..

Para conseguir infectar  a los usuarios se han usado los clásicos ataques de Spear Phishing via email. Los adjuntos que había en los correos explotaban los siguientes CVE: CVE-2012-0158, CVE-2010-3333, CVE-2012-0422 CVE-2012

En el informe encontraron una infraestructura muy grande en la que operaban, mas de 600 dominios. Incluso mientras realizaban el informe. Han proporcionado un mapa con los C&C e infraestructura en general:

Mapa de la infraestructura en el blog de Norman

En el informe han colocado los dominios, ip’s y MD5 relacionados con el caso, he decidido investigar que parte de la infraestructura todavía seguía viva.

IP’s que había en el informe de Norman: 

seifreed@hl20:~/server$ wc -l ips.txt
239 ips.txt

¿Cuantas de estas IP’s siguen activas?

seifreed@hl20:~/server$ wc -l ips_up.txt
116 ips_up.txt

Dominios que había en el informe de Norman:

seifreed@hl20:~/server$ wc -l blacklist_domains.txt
595 blacklist_domains.txt

¿Cuantos de estos dominios siguen activos?

seifreed@hl20:~/server$ wc -l host_alive_with_ips.txt
376 host_alive_with_ips.txt

Dominios e IP’s activas

Con tal de hacer un poco el seguimiento de la infraestructura presentada en el informe de Norman, comprobé cuales de esos dominios todavía resolvían y que procedencia tenían.

Dominios.

En el informe de Norman existían 595 dominios, cuando he realizado la investigación habían 376 dominios activos. He realizado un gráfico con los resultados obtenidos.

IP’s

En el informe de Norman habían reportado 239 ip’s relacionadas con el caso. Después de la revisión por mi parte he encontrado 116 Ip’s activas. He realizado un gráfico de la procedencia de estas IP’s

Como veis la infraestructura detectada por Norman permanece todavía activa y  es que el trabajo por parte de los CSIRT e ISP para el cierre de estas IP’s y dominios maliciosos no siempre es tan rápido como ellos querrían.

Para ver los reportes de Norman, podemos visitar

Informe ejecutivo => Norman HangOver report (Executive Summary)

Informe de la infraestructura => Unveiling an Indian Cyberattack Infrastructure

Apéndices del informe => Unveiling an Indian Cyberattack Infrastructure (Appendixes)

Creo que si publicara en Twitter que he encontrado una vulnerabilidad del tipo 0day de Java a nadie le sorprendería…

Llevamos arrastrando en el mundo de la seguridad informática desde hace tiempo varios problemas de seguridad en productos como Adobe Reader y Java. De echo a los autores de los Exploits Kits les estamos dando trabajo ya que han de correr para integrar estas últimas vulnerabilidades que han surgido en sus kits de exploits.

Leyendo un artículo de los cracks de ESET, han recopilado una tabla con los 10 CVE mas explotados:

Una de las cosas que tendríamos que configurar en nuestros equipos es que el Java empiece a actualizarse de manera automática!

Servicios como los que oferta Rapid7 que permiten escanear para saber como de seguro es tu navegador.

Rapid7

No hay excusa, actualiza tu Java!

Existen multitud de aplicaciones para revisar la seguridad de una página web. Las pruebas las puedes realizar de manera manual o bien las puedes lanzar una aplicación que lance unos testeos sobre la aplicación, cabe decir que lanzar una de estas herramientas no garantiza que se hayan probado todas las vulnerabilidades.

Hoy os traigo una aplicación que se llama Arachni y que me ha gustado mucho por el diseño que tiene y la configuración que le puedes hacer a la herramienta.

La herramienta la descargamos de aquí:

http://www.arachni-scanner.com/download/

La herramienta como digo le han cuidado la parte gráfica y tendremos un bonito espacio web desde el que podremos hacer las pruebas pertinentes.

Una vez que hayamos bajado arachni, lo iniciamos por consola para que levante el servidor web.

Como veis nos ha levantado un servidor web en local, accedemos para ver que nos encontramos.

Antes de iniciar Arachni, es recomendable que os leáis el README, pues ahí especifica el usuario y password de administrador para que podamos acceder a la aplicación.

Iniciamos sesión y lo primero es que creemos un usuario con el que poder trabajar.

Ya tenemos el usuario creado, accedemos con él y la aplicación ya podrá identificarnos.

Ahora que ya tenemos nuestro usuario lo que haremos será empezar un nuevo escaneo.

Aquí tenemos para seleccionar varias cosas, la web a la que lanzaremos el scaner, que profile escogeremos, por defecto viene XSS y SQL Injection.

Rellenamos los datos y lanzamos el scaner, nos irá mostrando los resultados.

Como veis es bastante bonito

Una vez que acabe nos mostrará abajo los resultados y nos mostrará el CVE y todo

Podemos configurar en la herramienta mas módulos de escaneo aquí tenemos la prueba.

Pero sin duda de lo que mas me ha gustado es el report generado.

Arachni, puede formar parte perfectamente entre tus herramientas de auditoría mas usadas.

Vamos a cambiar la dinámica de las últimas entradas que han habido por aquí y vamos ha pegarle hoy ha algo mas técnico pero para el alcance de todo el mundo.

Vamos a entrar en la ingeniería inversa para ver que se pueden hacer cosas muy chulas, pero sin entender todo el proceso, para que la entrada en el mundillo sea mas apetecible….

Tenemos el siguiente programa que nos pregunta por un serial:

Este es el aspecto que tiene la aplicación, como veis algo muy sencillo, nos pide un password, si le metemos uno cualquiera…

Evidentemente nos dará que la contraseña es incorrecta, así que toca paso de abrir el debugguer para ver como podemos solventar este problema.

Abrimos OllyDebugguer y la aplicación que nos pide el password.

Si nunca has abierto Olly, tranquilo, no has de entenderlo todo, por no decir que muy poco, es un artículo de introducción.

Si os acordáis cuando metíamos el password nos daba un error y nos decía que era incorrecto…

Este mensaje es un string, así que lo que haremos será buscar todos los strings del binario.

Usamos la opción All references text strings.

Lo que nos saldrá será lo siguiente:

Ya tenemos todas las referencias a los strings dentro del binario. Ahora lo que haremos será ir a la dirección de memoria donde dice el mensaje de que se ha introducido un serial incorrecto.

Primera manera de aceptar el password

Una de las cosas que podemos hacer para que nos acepte el serial es modificar en memoria el binario para que nos acepte cualquier serial. Una vez modificado el binario podemos guardar el resultado para tener un binario parcheado, pero primero vamos a ver que instrucciones nos encontramos.

En la imagen podemos ver instrucciones como:

CALL: Llama/Salta a la dirección/función indicada

PUSH: Guarda el valor en la pila.

JMP: Salta a la dirección indicada.

Lo que vamos ha hacer nosotros es modificar la dirección de memoria 00401299. Aquí lo que hay es un JE que significa que cuando el programa llegue aquí saltará si es igual o si es cero.

Nosotros los cambiaremos por un JnE, que saltará si NO es igual o si no es cero. Esto lo que hará es que cualquier cosa que introduzcamos salte a que el serial es correcto. Hacemos Assemble con Olly en esa dirección de memoria.

En este caso tenemos dos soluciones posibles, colocar un JMP, que saltará hacia la parte de el serial es correcto, o un JnE que le pongamos lo que le pongamos dará OK también. A cada cual elija el que mas le guste.

Hacemos Assemble y corremos el programa con F9, metemos cualquier serial y…

Recordar que en ningún momento hemos modificado el binario, si queremos guardarnos una copia de lo que hemos modificado solo tendremos que hacer:

Y seleccionamos Selection.

Segunda manera de sacar el password

Vamos a volver aquí:

Ahora lo que vamos ha hacer es meter un breakpoint (apretamos F2) en el CALL. Esto lo que hará es que el programa, parará su ejecución en ese CALL, la dirección de memoria en concreto es: 00401291.

Ejecutamos el programa y parará en el CALL donde hemos puesto el breakpoint, entonces apretamos F7 para entrar dentro del call y F8 para ir yendo instrucción a instrucción para que en la parte de registers de Olly nos acabe mostrando el password.

Y aquí hemos acabado.

Antes de que me lo diga algún lector, con un strings sacábamos el password que estaba harcodeado en el binario.

m0tNaF-EmKCARc
Check Status
Wrong Password! Keep trying, you’ll get it!
You got it! Your now a cracker!

Espero que este artículo os anime a poneros con la ingeniería inversa / cracking, es un mundo fascinante.

Los proveedores de correo electrónico vigilan de ajustar sus filtros de SPAM para que los usuarios no sufran oleadas de correos basura con phishings, malware etc…

Yo siempre reviso el SPAM por si acaso viene algún premio que merezca la pena analizar.

En la revisión de correos que estaba realizando me ha llegado un correo de SPAM, se trataba de un phishing. Sabía que era así porque me ofrecían cambiar las claves de una cuenta bancaria de la que yo no tenía cuenta registrada.

Observamos el correo:

Tenía claro de que se trataba de un phishing ya que yo no tengo cuenta en Banamex.

Miramos el enlace donde apunta la palabra Entrar:

http://www.baltiprofiil.ee/boveda.banamex.com.mx/serban/

La parte en negrita es el dominio, para confundir al usuario han usado la palabra banamex en el directorio donde estaría alojado el phishing.

darkmac:malware marc$ curl -I http://www.baltiprofiil.ee/boveda.banamex.com.mx/serban/
HTTP/1.1 404 Komponenti ei leitud
Date: Mon, 20 May 2013 21:38:03 GMT
Server: Apache/2.2.24/DataZone SP (Unix) mod_zfpm/0.2
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"
Expires: Mon, 1 Jan 2001 00:00:00 GMT
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: fb2e82f3aa5e9e6274ab1d0eb636e5bd=6e5fcf339c991bbe34523d245d2d2a29; path=/
Set-Cookie: lang=deleted; expires=Sun, 20-May-2012 21:38:02 GMT; path=/
Set-Cookie: jfcookie=deleted; expires=Sun, 20-May-2012 21:38:02 GMT; path=/
Set-Cookie: jfcookie[lang]=deleted; expires=Sun, 20-May-2012 21:38:02 GMT; path=/
Last-Modified: Mon, 20 May 2013 21:38:03 GMT
Content-Type: text/html; charset=utf-8

El phishing no está disponible, una lástima, me hubiera gustado analizarlo.

He consultado el dominio en las listas negras y no está, por lo tanto puede que se trate de un dominio comprometido.

http://multirbl.valli.org/lookup/baltiprofiil.ee.html

Una de las cosas que podemos hacer es mirar las cabeceras del correo eso nos aportará mas información.

Received: by 10.60.27.70 with SMTP id r6csp7332oeg;
Sat, 18 May 2013 02:11:56 -0700 (PDT)
X-Received: by 10.15.108.6 with SMTP id cc6mr79602894eeb.28.1368868315363;
Sat, 18 May 2013 02:11:55 -0700 (PDT)
Return-Path: <[email protected]>
Received: from s16071902.onlinehome-server.info (intercampusonline.com. [212.227.89.54])
by mx.google.com with ESMTPS id i3si21728397eev.129.2013.05.18.02.11.54
for <[email protected]>
(version=TLSv1 cipher=RC4-SHA bits=128/128);
Sat, 18 May 2013 02:11:55 -0700 (PDT)
Received-SPF: neutral (google.com: 212.227.89.54 is neither permitted nor denied by best guess record for domain of [email protected]) client-ip=212.227.89.54;
Authentication-Results: mx.google.com;
spf=neutral (google.com: 212.227.89.54 is neither permitted nor denied by best guess record for domain of <strong>[email protected]</strong>) smtp.mail=[email protected]
Received: by <strong>s16071902.onlinehome-server.info</strong> (Postfix, from userid 502)
id 9E1269FB0; Sat, 18 May 2013 10:18:52 +0200 (CEST)
To: [email protected]
Subject: Verificacion de datos en BancaNet
X-PHP-Originating-Script: 502:index.php
From: Notificaciones<[email protected]>
Reply-To: [email protected]

La dirección de correo estaba spoofeada por lo tanto el destinatario del correo pensará de nuevo que la notificación se la envía el banco. Una de las maneras de revisar esta parte es mirar la cabecera del correo.

Como véis un pequeño análisis nos da información sobre el phishing recibido.

Una de las técnicas que se usan para descrubrir directorios con información sensible es hacer ataques del tipo fuzzing.

El objetivo de estos ataques es el de tratar de descubrir directorios que el administrador se ha dejado descuidados o simplemente para tratar de hacerse una idea de la estructura web del servidor web.

En el artículo de hoy hablamos de dirá. Esta aplicación es de sobras conocido pues tiene ya bastantes añitos. Pero no he encontrado ninguna que pueda decir que haga su trabajo mejor .

A dirb se le pasa como parámetro la web a escanear y el diccionario con el que haremos fuzzing.

Ejecutamos dirb desde la linea de comandos.

—————–
DIRB v2.04
By The Dark Raver
—————–

./dirb <url_base> [<wordlist_file(s)>] [options]

========================= NOTES =========================
<url_base> : Base URL to scan. (Use -resume for session resuming)
<wordlist_file(s)> : List of wordfiles. (wordfile1,wordfile2,wordfile3…)

======================== HOTKEYS ========================
‘n’ -> Go to next directory.
‘q’ -> Stop scan. (Saving state for resume)

======================== OPTIONS ========================
-a <agent_string> : Specify your custom USER_AGENT.
-c <cookie_string> : Set a cookie for the HTTP request.
-f : Fine tunning of NOT_FOUND (404) detection.
-H <header_string> : Add a custom header to the HTTP request.
-i : Use case-insensitive search.
-l : Print “Location” header when found.
-N <nf_code>: Ignore responses with this HTTP code.
-o <output_file> : Save output to disk.
-p <proxy[:port]> : Use this proxy. (Default port is 1080)
-P <proxy_username:proxy_password> : Proxy Authentication.
-r : Don’t search recursively.
-R : Interactive recursion. (Asks for each directory)
-S : Silent Mode. Don’t show tested words. (For dumb terminals)
-t : Don’t force an ending ‘/’ on URLs.
-u <username:password> : HTTP Authentication.
-v : Show also NOT_FOUND pages.
-w : Don’t stop on WARNING messages.
-X <extensions> / -x <exts_file> : Append each word with this extensions.
-z <milisecs> : Add a miliseconds delay to not cause excessive Flood.

======================== EXAMPLES =======================
./dirb http://url/directory/ (Simple Test)
./dirb http://url/ -X .html (Test files with ‘.html’ extension)
./dirb http://url/ wordlists/vulns/apache.txt (Test with apache.txt wordlist)
./dirb https://secure_url/ (Simple Test with SSL)

Es sencillo ¿verdad?

Lanzamos sobre un servidor web y vamos viendo los resultados.

darkmac:vulns marc$ dirb http://www.ub.edu ../general/big.txt

—————–
DIRB v2.04
By The Dark Raver
—————–

START_TIME: Mon May 20 00:23:14 2013
URL_BASE: http://www.ub.edu/
WORDLIST_FILES: ../general/big.txt

—————–

GENERATED WORDS: 3024

—- Scanning URL: http://www.ub.edu/ —-
+ http://www.ub.edu/agenda/
==> DIRECTORY
+ http://www.ub.edu/ajuda/
==> DIRECTORY
+ http://www.ub.edu/asd/
==> DIRECTORY
+ http://www.ub.edu/business/
==> DIRECTORY
+ http://www.ub.edu/carpeta/
==> DIRECTORY
+ http://www.ub.edu/cataleg/
==> DIRECTORY
+ http://www.ub.edu/cerca/
==> DIRECTORY
+ http://www.ub.edu/cgi-bin/
(FOUND: 403 [Forbidden] – Size: 7007)
+ http://www.ub.edu/chat
(FOUND: 403 [Forbidden] – Size: 325)
+ http://www.ub.edu/config/
==> DIRECTORY

Dirb irá haciendo match con el diccionario que le pasemos. Si encuentra el directorio le pasará el diccionario también a ese directorio.

En proximos posts le daremos mas usos y conocemos otras herramientas.

Encontramos dirb aquí:

http://dirb.sourceforge.net/

Hoy en DragonJAR os enseñamos otra herramienta que nos sirve para identificar que tecnologías usa un servidor web.

Esto nos será muy útil ya que nos permitirá poder enfocar un ataque/análisis mas concreto.

Con los ataques de denegación de servicio los administradores optan por usar servicios de protección para que sus sitios web no caigan ante un ataque.

Uno de esos servicios es Cloudfare, veamos un gráfico para saber mejor como funciona:

Servicios como Cloudfare o Akamai tendrán ciertas partes del sitio web protegido pero rara vez tendrán todo el sitio akamaizado o en la red de Cloudfare.

Podemos tratar de identificar un punto de entrada que no pase por este sitio web.

Vamos a ver unos ejemplos de uso con WhatWeb:

Bajamos WhatWeb y escaneamos el primer sitio web:

darkmac:WhatWeb marc$ ./whatweb www.ub.edu
http://www.ub.edu [302] Apache, Country[EUROPEAN UNION][EU], HTTPServer[Apache], IP[161.116.100.2], RedirectLocation[http://www.ub.edu/web/ub/ca/], Title[302 Found]
http://www.ub.edu/web/ub/ca/ [200] Apache, Country[EUROPEAN UNION][EU], DublinCore, Google-Maps, HTTPServer[Apache], IP[161.116.100.2], Script, Title[Universitat de Barcelona - Home]

Podemos ver la información que ha extraído WhatWeb, vamos a ver otro caso.

darkmac:WhatWeb marc$ ./whatweb http://www.whitehouse.gov
http://www.whitehouse.gov [200] AddThis, Country[EUROPEAN UNION][EU], Drupal, Frame, IP[195.59.150.147], OpenGraphProtocol[100000095507875], Script, Title[The White House], UncommonHeaders[x-drupal-cache,x-varnish,x-ah-environment,x-pf-uncompressing], Varnish, X-UA-Compatible[IE=9]

Podemos ver que no ha podido identificar que se trata de un Drupal pero vemos cosas como:

x-drupal-cache

Por lo que sabemos que hay un Drupal detrás.

Si lo lanzamos encima de otra web:

darkmac:WhatWeb marc$ ./whatweb https://www.bicing.cat
https://www.bicing.cat [200] Apache[2.2.16], Country[UNITED KINGDOM][GB], Drupal, Frame, HTTPServer[Debian Linux][Apache/2.2.16 (Debian)], IP[62.97.112.138], JQuery[1.9.1], MetaGenerator[Drupal 7 (http://drupal.org)], PHP[5.3.3-7+squeeze15], PasswordField[pass], Script, Title[Bicing | Mou-te en Bicing, cuida de tu i de Barcelona], UncommonHeaders[x-generator], X-Powered-By[PHP/5.3.3-7+squeeze15]

Podemos ver que ha identificado que es un Drupal pero que también ha extraído que es una distribución Debian y la versión.

Habrá sitios webs de los que casi no podremos obtener información.

darkmac:WhatWeb marc$ ./whatweb http://www.mossad.gov.il
http://www.mossad.gov.il [200] Country[ISRAEL][IL], IP[147.237.72.71], Script

Otro caso:

darkmac:WhatWeb marc$ ./whatweb http://www.wikipedia.org
http://www.wikipedia.org [200] Apache, Country[NETHERLANDS][NL], HTML5, HTTPServer[Apache], IP[91.198.174.225], probably MediaWiki, Script, Title[Wikipedia], UncommonHeaders[x-content-type-options], X-Cache[sq63.wikimedia.org, MISS from amssq38.esams.wikimedia.org, HIT from amssq43.esams.wikimedia.org,sq63.wikimedia.org:3128, HIT from amssq38.esams.wikimedia.org:3128, HIT from amssq43.esams.wikimedia.org:80]

Aquí podemos ver que dice cosas como que probablemente se trata de MediaWiki.

¿Como sabemos que versiones detecta?

Pues podemos saberlo preguntandole a WhatWeb sobre un CMS en concreto por ejemplo

darkmac:WhatWeb marc$ ./whatweb -I joomla
WhatWeb Plugin Information
Searching for joomla
——————————————————————————–
Plugin Name Details
FreeJoomlas_com
Author: Brendan Coles <[email protected]>
Version: 0.1
Examples: 9
Matches: 1
Passive function: No
Aggressive function: No
Version detection: No
Description:
FreeJoomlas.com – We provide free hosting for your Joomla portals. It
is absolutely FREE. Moreover, we provide FREE subdomains
(YOURNAME.FreeJoomlas.com) and UNLIMITED data transfer. – homepage:

http://www.freejoomlas.com/

——————————————————————————–
Joomla
Author: Andrew Horton
Version: 0.7
Examples: 18
Matches: 4
Dorks: 1
Passive function: Yes
Aggressive function: Yes
Version detection: Yes
Description:
Opensource CMS written in PHP. Aggressive version detection compares
just 5 files, valid for versions 1.5.0-1.5.22 and 1.6.0-1.6.1.
Homepage: http://joomla.org.

Como veis WhatWeb nos es muy útil y nos puede dar gran información sobre un sitio web en concreto.

Podéis descargar WhatWeb desde aquí

http://www.morningstarsecurity.com/research/whatweb