Google-Hacking con Metagoofil

La recopilación de información es la primera fase en la evaluación de seguridad. un paso necesario en una prueba de intrusión. Se centra en recoger tanta información como sea posible sobre una aplicación objetivo.

Metagoofil es una herramienta que se encarga de extraer Meta-Datos de ciertos ficheros accesibles en los websites.

Los ficheros que utiliza son los clasicos utilizados en ofimática PDF,PPT,DOC,XLS y MDB

La manera de operar de la herramienta se basa en realizar búsquedas en Google (Google-Hacking) dentro del dominio del Objetivo, y solo de los ficheros con formatos concretos.

Una vez identificados los ficheros, se bajan de la web a nuestra máquina donde Metagoofil extraerá la informacion interesante, por último genera un HTML con los resultados.

De esta forma tenemos una fuente más de donde extraer usuarios potenciales de los sistemas objetivos.

Seguir Leyendo...


Esta herramienta utiliza libextractor para obtener la meta-información de los archivos. Tendremos que instalarla aparte.

Acaba de publicarse la nueva versión de esta herramienta (MetaGooFil 1.4 - 20/04/2008) que obtiene la dirección MAC de los documentos Microsoft Office.
Es capaz de obtener:
Nombres de usuario, rutas de los archivos y direcciones MAC.

Otro punto más que proteger por parte de los responsables de seguridad.


Enlaces:
http://www.edge-security.com/metagoofil.php
http://www.s21sec.com/metagoofil/metagoofil.html

Certificados digitales

Un certificado digital es una versión "firmada" o verificada de una clave pública.
Los certificados digitales siguen el estándar X.509 para definir su formato. Las extensiones de estos certificados pueden ser:

• .P7b - Estructura PKCS#7. Usado para firmar y/o cifrar mensajes (contiene sólo la clave pública).
• .Pfx - Estructura PKCS#12. Puede contener claves públicas y claves privadas (protegido mediante clave simétrica)
• .CER - Certificado codificado en CER, algunas veces es una secuencia de certificados
• .DER - Certificado codificado en DER
• .PEM - Certificado codificado en Base64, encerrado entre "-----BEGIN CERTIFICATE-----" y "-----END CERTIFICATE-----" Puede contener claves privadas o públicas.
  

Nota: Cuando queremos exportar un certificado, si elegimos el formato PKCS#7 sólo estaremos exportando la clave pública, por en contrario, si elegimos el formato PKCS#12 también estaremos exportando la clave privada.

A la hora de utilizar certificados digitales en una infraestructura PKI para fortificar las comunicaciones en internet, las organizaciones disponen de dos opciones:

Seguir Leyendo...


1ª Utilizar un certificado raiz de confianza autofirmado
Una organización puede optar por crear su propia CA para firmar sus propios certificados digitales. Esta CA poseerá un certificado raiz o certificado autofirmado que cada navegador que acceda a un portal bajo SSL deberá añadir previamente a su lista de certificados de confianza, si no lo hace, cada vez que se intente acceder a ese recurso, el navegador devolverá un error de certificado. Más adelante veremos por qué.
Se dice que es un certificado autofirmado porque que el propietario y el emisor son la misma entidad.

2ª Utilizar un certificado firmado por una Autoridad de Certificación, solicitando y pagando por la firma de una entidad certificadora reconocida. De esta forma, la CA es la responsable de asegurar que la identidad del propietario del certificado es auténtica. En este caso los navegadores no necesitan instalar ningún certificado raiz de la CA ya que al ser una Autoridad Certificadora reconocida, estos certificados raiz ya se encuentran instalados por defecto en los navegadores.

Procedimiento de adquisición de un certificado digital:

- Cuando una organización desea solicitar un certificado de seguridad para utilizarlo, por ejemplo, en un servidor web protegido con SSL, primero debe realizar una solicitud de certificado o CSR (Certificate Signing Request). Una CSR consiste en generar un "pre-certificado" (pre-certificado porque no está firmado aún) con los datos de la entidad solicitante: nombre de la organización, correo, DN Distinguished Name (dato de mucha importancia ya que identificará el dominio sobre el que se alojará el recurso) entre otros. Cuando se crea una CSR se obtiene dos ficheros:
cert.pem -> pre-certificado
key.pem -> clave privada que utilizará el servidor web para futuros handshake de SSL

- La CA recibe la solicitud de certificado y comprueba que los datos que contiene se corresponden realmente con la entidad que lo solicita (cada CA utiliza sus propios metodos). Una vez comprobado, la CA crea una firma a partir de su llave privada y los datos del "pre-certificado" y genera un certificado ya firmado y definitivo y lo hace llegar a la organización que lo solicitó.

Una vez la organización reciba el certificado ya firmado, deberá instalar este certificado en su servidor web.
Ejemplo de configuración del fichero httpd.conf de apache:

...
SSLEngine on
SSLCertificateFile /etc/httpd/conf/certificado-firmado.pem <- certificado ya firmado
SSLCertificateKeyFile /etc/httpd/conf/key.pem <- clave privada que obtuvimos cuando generamos la CSR. ...

A continuación se muestra el proceso de negociación o Handshake entre el cliente y el servidor:

Hacer click sobre la imagen para agrandar

Autenticación a un servidor SSH utilizando cifrado asimétrico

Vamos a configurar el método de autenticación a un servidor con Windows y freeSSHd instalado, utilizando el cliente putty y un sistema de cifrado de clave pública.

- Generamos nuestro par de claves:
Abrimos el PuTTy Key Generator (puttygen.exe) y puslamos sobre "Generate". Nos pide que generemos información aleatoria moviendo el cursor sobre la zona gris.
Copiamos el texto que viene en la sección "key" en un editor de texto, por ejemplo bloc de notas. Lo guardamos en el directorio donde el servidor de ssh freeSSHd guarde las claves públicas. Este directorio es por defecto "C:\Archivos de programa\freeSSHd\" y se puede modificar en la pestaña "Authentication". Este documento lo guardamos con el nombre del usuario que tengamos para el freeSSHd. Este usuario deberá tener configurado como método de autorización "Public key (SSH only)"; lo comprobamos en la pestaña "Users" seleccionando un usuario y pulsando sobre el botón "Change". Por otra parte, tendremos que tener a "Allowed" o "Required" el parámetro "Public key authentication" en la configuración del freesshd para que nos permita este tipo de autenticación. Volvemos al PuTTy Key Generator y puslamos sobre "Save private key" para guardar la llave privada en un lugar seguro (en el cliente).
Podemos utilizar passphrase o no para guardarla, si elegimos que sí, cuando intentemos conectar nos la pedirá.



Seguir Leyendo...

- Probamos a conectarnos.
Abrimos putty en el cliente y nos vamos a Connection -> SSH -> Auth, y en la sección "Authentication parameters", indicamos la llave privada que usaremos para autenticarnos. Elegimos la que hayamos guardado con el PuTTy Key Generator.



- Podemos utilizar Pageant.exe para que gestione automáticamente las claves privadas que utilizaremos para autenticarnos:
Ejecutamos pageant.exe y nos coloca en la barra de sistema un icono, cuando hacemos doble click sobre él nos abre una ventana donde aparecen listadas las claves privadas que contiene. La prmiera vez aparecerá vacía y tendremos que añadir las claves privadas pulsando sobre "Add key", si la clave tiene passphrase asociada nos la pedirá en ese momento. Al arrancar putty, detectará automáticamente que pageant está funcionando y utilizará las llaves privadas que contenga. Cuando haya varias, putty probará una por una hasta que encuentre alguna que corresponda con la cabe pública del usuario que esté logeando en el servidor.



NOTA: Si no queremos que nos pida usuario al conectar, podemos añadir un usuario por defecto en "Auto-login username" en Connection -> Data.

- Si ya tenemos un par de claves generadas con freeSSHd, para utilizarlas, tan solo tendremos que pulsar sobre el botón "Load" en el PuTTy Key Generator, seleccionar "All files (*.*)" en "Tipo:" y abrir la llave privada .rsa o .dsa. Una vez abierta, tendremos que volver a repetir los mismos pasos que si las hubieramos generado directamente con el puttygen.exe, es decir, guardar la llave pública con el nombre del usuario y la privada con extensión ppk.



- Si tenemos un par de claves generadas con OpenSSH (utilizando por ej. el comando # ssh-keygen -t dsa), seguiremos el mismo proceso importando la clave privada en el puttygen.exe y guardándola en formato ppk.