En Security Art Work hemos hablado mucho acerca de Nmap. Hemos comentado algunas de sus características, y novedades en sus últimas versiones (aquí y aquí); hemos visto ejemplos de su uso, desde el más habitual como escáner de red y herramienta de fingerprinting hasta usos más avanzados, para detectar vulnerabilidades y realizar ataques; hemos comentado otros aspectos de la aplicación; e incluso hemos hablado de cómo defendernos ante posibles escaneos de terceros.

A pesar de la popularidad de que goza Nmap, y de su gran comunidad de usuarios, a veces es difícil encontrar información concisa, y sobre todo, en español, de algunas de sus funcionalidades.

Si bien es cierto que existen varios listados de comandos o guías de referencia rápida (también conocidos como chuletas o cheatsheet, en inglés), siendo uno de los más populares por nuestras tierras el de SecurityByDefault para Nmap 5, su contenido es básico, aunque no por ello deja de ser muy útil.

Es por ello que desde CSIRT-cv hemos publicado un listado de comandos (cheatsheet) para Nmap 6, realizado por José Luis Chica (@BufferOverCat) y un servidor (@jovimon). En ella se puede encontrar un listado extensivo de todas las opciones que tiene la última versión de Nmap, con una pequeña descripción de su funcionamiento y observaciones, consejos sobre su uso o incluso en algunos casos el significado de los valores devueltos por la aplicación.

A pesar de no tratarse de un cheatsheet al uso, ya que ocupa un total de 6 páginas, el objetivo de este listado de comandos es servir de guía de consulta rápida sobre las características y el funcionamiento de Nmap 6. Vamos, lo que vendría a ser un nmap –help pero con un formato, con información adicional que ayude a entender el funcionamiento de cada parámetro y, lo más importante, en castellano.

Podéis obtener el documento en el portal de CSIRT-cv. También podéis ver más guías y documentación en su sección de descargas.

Esperamos vuestros comentarios.

Hoy le toca el turno a hashcat, una aplicación para obtener contraseñas a partir del hash de las mismas. Esto puede ser de utilidad cuando, en la realización de una auditoría, nos encontramos con una base de datos o un fichero que guarda credenciales cifradas de usuarios.

Tuve la oportunidad de probar hashcat hace unos días, y la verdad es que quedé gratamente sorprendido. Algunas de las características más destacables en mi opinión son:

• Viene precompilada y optimizada para Windows, Linux y OSX, con versiones de 32 y 64 bits, evitando retrasos y problemas de compilación.
• Su versatilidad. Tiene soporte multihilo, soporta muchos algoritmos (más de 50) y permite modos de trabajo avanzados utilizando reglas o tablas de permutación, entre otros.
• Es muy ligera. Los hilos que se encargan del grueso de trabajo corren a una prioridad baja, por lo que puedes seguir utilizando el equipo mientras está procesando.
• Tiene una versión que utiliza la tarjeta gráfica (GPU) para las operaciones de cómputo, lo que permite acelerar mucho el proceso de obtención de las contraseñas. Para probar su rendimiento la puse a descifrar contraseñas de Joomla! con mi equipo personal (Phenom II 955 y una ATI HD5770 con 1GB de memoria) y pasé, utilizando 2 cores de la CPU, de 11 millones de pruebas por segundo a más de 1400 millones utilizando la GPU. La única “pega” es que esta versión no está para OSX.

Si queréis descargarla u obtener más información podéis pasaros por la web de la versión “clásica” (la que utiliza la CPU). Para GPU dispone de dos versiones: oclhashcat-plus, que soporta más métodos de cifrado y entornos más grandes, y oclhashcat-lite, más básica.

La aplicación clásica tiene muchas opciones, pero vamos a enumerar las más comunes, que nos serán suficientes en la mayoría de los casos.
Una línea de órdenes genérica tiene esta pinta:

<ejecutable -hashcat> [opciones] fichero-hash [mascara|diccionario|directorio]

Como fichero ejecutable elegiremos el que corresponda a la distribución elegida (p. ej.: hashcat-cli32.bin o oclHashcat-plus64.exe).

De entre las opciones, destacan las siguientes:

• -n <num> Número de hilos a utilizar (solo versión para CPU).
• -m <num> Tipo de hash a descifrar. El listado completo aparece al mostrar la ayuda.
• -a <num> Tipo de ataque a realizar. Generalmente utilizaremos ataque por diccionario (por defecto, a=0) o por fuerza bruta (a=3). Listado completo en la ayuda.
• -o <fich> Fichero donde guardar los hash descifrados.
• -c <num> Tamaño de la caché en RAM del diccionario, en MB.
• -[1-4] <valor> Definición de conjuntos de caracteres personalizados, si queremos acotar los posibles caracteres que tendrá la aplicación. En la ayuda aparece un listado completo de las combinaciones.

El parámetro fichero-hash contendrá los hash que queramos descifrar, uno por línea. El último parámetro será o bien una máscara de caracteres si vamos a realizar un ataque por fuerza bruta, o un fichero o directorio con diccionarios sobre los que realizar las pruebas (se pueden encontrar diccionarios útiles y gratuitos en multitud de sitios web).

Os dejo con un par de ejemplos de ejecución:

$ ./hashcat-cli32.bin   Ejecutable de 32 bits bajo Linux.
-n 2                    Vamos a utilizar 2 cores de nuestra CPU.
-a 3                    Modo fuerza bruta.
-m 400                  Tipo de hash: phpass, MD5(WordPress), MD5(phpBB3).
-o wp.pass              Fichero de salida.
wordpress.hash          Fichero que contiene los hash a descifrar.
?l?l?l?l?l?l?l          Máscara, hasta 7 caracteres en minúsculas.

> hashcat-cli64.exe  Ejecutable de 64 bits bajo Windows.
-a 0                    Modo fuerza bruta.
-m 10                   Tipo de hash: md5($pass.$salt), utilizado en Joomla!.
-o joomla.pass          Fichero de salida.
joomla.hash             Fichero que contiene los hash a descifrar.
wordlist.dic            Diccionario sobre el que buscar los hash del parámetro anterior.

Si queréis ampliar la información al respecto podéis acudir a la Wiki oficial de hashcat. Si preferís la lengua de Cervantes, hace poco se publicó un manual en español (disponible aquí o aquí).

En este artículo os voy a contar una forma de auditar el uso de un sistema Linux, en concreto para saber quién ha modificado o borrado un fichero concreto.

La historia empieza cuando un amigo nos pregunta sobre la mejor forma de auditar los accesos a una carpeta concreta de un servidor linux, ya que han desplegado una aplicación nueva que interactúa con un servidor de ficheros linux y se han encontrado con que, en servidores y carpetas diferentes, se han borrado misteriosamente algunos ficheros sin encontrarse al culpable ni el porqué del borrado misterioso de los ficheros.

Tras una búsqueda de las mejores alternativas, entre las que planteamos, por ejemplo, Tripwire o algún HIDS como OSSEC, nos encontramos con audit, un demonio específicamente diseñado para monitorizar ficheros y carpetas y registrar cualquier modificación realizada.

La instalación es trivial, y existe paquete para las distribuciones más utilizadas:

Debian y derivados: apt-get install auditd.
RHEL y derivados: yum install audit.

Tras esto debemos añadir la siguiente línea en el fichero del servicio dentro de la carpeta /etc/pam.d/ que queramos monitorizar (en nuestro caso eran accesos SSH, por lo que modificamos /etc/pam.d/sshd) para que entre en funcionamiento el demonio:

session required pam_loginuid.so

Finalmente añadimos la regla para monitorizar la ruta en cuestión:

auditctl -w /home/prueba -p w

Esto crea, en el fichero de log del demonio (/var/log/audit/audit.log), entradas por cada acción de inicio y cierre de sesión que se realiza en el sistema, además de cada acción que se realiza sobre la carpeta que hemos seleccionado:

type=LOGIN msg=audit(1348584458.716:2200): login pid=28278 uid=0 old auid=0 new auid=502 old ses=148 
   new ses=202
type=LOGIN msg=audit(1348584458.716:2201): login pid=28278 uid=0 old auid=502 new auid=502 old 
   ses=202 new ses=203
type=SYSCALL msg=audit(1348584471.100:2202): arch=c000003e syscall=83 success=yes exit=0 
   a0=7f41f39dc990 a1=1ff a2=ffffffffffffffa0 a3=4000 items=2 ppid=28283 pid=28284 auid=502 uid=502 
   gid=502 euid=502 suid=502 fsuid=502 egid=502 sgid=502 fsgid=502 tty=(none) ses=203 
   comm="sftp-server" exe="/usr/lib/openssh/sftp-server" key=(null)
type=CWD msg=audit(1348584471.100:2202):  cwd="/home/prueba"
type=PATH msg=audit(1348584471.100:2202): item=0 name="/home/prueba/" inode=130822 dev=08:01 
   mode=040755 ouid=502 ogid=502 rdev=00:00
type=PATH msg=audit(1348584471.100:2202): item=1 name="/home/prueba/aa" inode=205645 dev=08:01 
   mode=040755 ouid=502 ogid=502 rdev=00:00
type=SYSCALL msg=audit(1348584476.181:2203): arch=c000003e syscall=84 success=yes exit=0 
   a0=7f41f39dc990 a1=3 a2=ffffffffffffffb0 a3=4000 items=2 ppid=28283 pid=28284 auid=502 uid=502
   gid=502 euid=502 suid=502 fsuid=502 egid=502 sgid=502 fsgid=502 tty=(none) ses=203 
   comm="sftp-server" exe="/usr/lib/openssh/sftp-server" key=(null)
type=CWD msg=audit(1348584476.181:2203):  cwd="/home/prueba"
type=PATH msg=audit(1348584476.181:2203): item=0 name="/home/prueba/" inode=130822 dev=08:01 
   mode=040755 ouid=502 ogid=502 rdev=00:00
type=PATH msg=audit(1348584476.181:2203): item=1 name="/home/prueba/aa" inode=205645 dev=08:01 
   mode=040755 ouid=502 ogid=502 rdev=00:00

En este log podemos ver como un usuario (uid 502) inicia sesión, y posteriormente accede al directorio /home/prueba y crea, para posteriormente eliminar, la carpeta /home/prueba/aa.

La aplicación utilizada para acceder a los archivos, marcado con la etiqueta “exe”, es sftp-server, ya que la aplicación utiliza SFTP para interactuar con el sistema de archivos.

En la mayoría de supuestos tendríamos suficiente con la información aportada por auditd, ya que si, por ejemplo, realizamos una orden de tipo rm <fichero>, el campo exe contendrá el comando rm lanzado y, con la información del uid del usuario que ha realizado la acción, podríamos saber quién ha borrado dicho fichero.

En este caso no tenemos información suficiente, ya que aunque sí que sabemos que es el servidor SFTP quien ha realizado el borrado, no sabemos exactamente el comando que se ha lanzado para efectuar el borrado de ficheros en nuestra carpeta monitorizada.

Para solucionar este problema, el servidor SFTP incluido en OpenSSH a partir de la versión 4.4, publicada en septiembre de 2006, ofrece la posibilidad de añadir un registro de las acciones realizadas dentro de cada sesión SFTP (ver página del man para más información). Para activar este registro debemos modificar la siguiente línea:

Subsystem sftp /usr/lib/openssh/sftp-server

añadiendo el parámetro -l INFO, por lo que quedará:

Subsystem sftp /usr/lib/openssh/sftp-server -l INFO

Tras reiniciar el servidor SSH, en el fichero /var/log/auth.log obtendremos, además de los registros habituales, otros como los siguientes:

Sep 25 16:52:16 lab1 sftp-server[28846]: session opened for local user user1 from [127.0.0.1]
Sep 25 16:52:23 lab1 sftp-server[28846]: sent status No such file
Sep 25 16:52:23 lab1 sftp-server[28846]: mkdir name "/home/prueba/aa" mode 0777
Sep 25 16:52:26 lab1 sftp-server[28846]: opendir "/home/prueba/aa"
Sep 25 16:52:26 lab1 sftp-server[28846]: closedir "/home/prueba/aa"
Sep 25 16:52:26 lab1 sftp-server[28846]: opendir "/home/prueba/aa"
Sep 25 16:52:26 lab1 sftp-server[28846]: closedir "/home/prueba/aa"
Sep 25 16:52:26 mysql1 sftp-server[28846]: rmdir name "/home/prueba/aa"
Sep 25 16:52:26 mysql1 sftp-server[28846]: opendir "/home/prueba"
Sep 25 16:52:26 mysql1 sftp-server[28846]: closedir "/home/prueba"
Sep 25 16:52:26 mysql1 sftp-server[28846]: opendir "/home/prueba"
Sep 25 16:52:26 mysql1 sftp-server[28846]: closedir "/home/prueba"

Este extracto nos permite, por ejemplo, saber que el usuario ha accedido al directorio /home/prueba, y ha creado y posteriormente borrado el directorio aa, del mismo modo que en el ejemplo anterior.

Utilizando todo esto nuestro compañero pudo finalmente descubrir cómo se estaban realizando los borrados misteriosos de ficheros y quién era el responsable.

(N.d.E. Dado que es festivo en la Comunidad Valenciana mañana nueve de octubre, les vemos el próximo miércoles. Cuidado ahí fuera.)

Todos nos hemos encontrado en algún momento con que ese servicio al que queremos acceder está en un equipo inalcanzable desde nuestra red u otros problemas similares. Si disponemos de acceso SSH podemos solucionar fácilmente problemas de este tipo utilizando túneles SSH.

Planteamos un primer escenario, en el que tenemos un servidor de bases de datos al que podemos acceder por SSH, pero cuyo cortafuegos nos impide interactuar directamente con la base de datos (suponemos MySQL, que utiliza el puerto 3306).

[Read more…]

Animado por la entrada que hizo hace unas semanas Chema Alonso en su blog, os voy a contar un poco más sobre la herramienta SoapUI, utilizada para auditar WebServices. Más que en cómo utilizar la herramienta en sí, en este post me gustaría explicar de qué forma se pueden automatizar las pruebas a un WebService utilizando esta herramienta.

SoapUI permite automatizar las pruebas a un WebService utilizando lo que él llama Test Cases. A continuación podemos ver que un TestCase tiene varios pasos (TestSteps), así como varias pruebas de carga y de seguridad, que quedan fuera de nuestro objetivo.

[Read more…]

En mi anterior post os comentaba unas mejoras que se habían introducido en las últimas versiones de Snort, y que si recordáis nos servían para obtener más información detallada acerca de las comunicaciones HTTP y SMTP, como pueden ser: dirección real detrás de los proxys, host y URI contactados, así como direcciones de origen y destino de correos electrónicos, o cabeceras SMTP entre otros.

Al final de la entrada nos quedamos con Snort configurado, pero sin poder extraer esta información tan importante ya que actualmente no se dispone de ninguna aplicación oficial o parche que utilice estas nuevas extensiones del formato Unified2. Por suerte, un usuario de Barnyard2 publicó en la lista de correo de desarrollo de Barnyard2 un parche con el que conseguir guardar esta información en una base de datos de tipo MySQL. Cabe destacar que el parche no es oficial, y ni el usuario que lo creó ni nosotros nos responsabilizamos de los problemas que su uso pueda ocasionar.

Este usuario realizó un parche para la versión 1.9 de Barnyard2 y otro para una snapshot del SVN de la versión en desarrollo. Por comodidad, vamos a utilizar el parche para la versión 1.9. Para instalarlo es necesario descargar Barnyard2, y ejecutar el parche desde la propia carpeta de Barnyard2 con la orden:

patch -p1 < barnyard2-1.9-extra-out.diff

Tras esto, se debe compilar Barnyard2 de la forma habitual, y ejecutar el script de creación del esquema de la base de datos MySQL (cuidado con no borrar bases de datos con información, ya que el script modificado elimina las tablas para crearlas de nuevo) para que ésta pueda albergar la información de las cabeceras extras.

El último paso consiste en modificar Barnyard2 para que, dentro del plugin de MySQL, utilice la “facility” alert-extra. De esta forma conseguimos guardar finalmente estos campos en la base de datos. La línea de configuración quedaría del siguiente modo:

output database: alert-extra, mysql, dbname=snort host=localhost user=snort 
         password=snort sensor_name=snort

Como detalle cabe comentar que durante el proceso de pruebas y gracias al usuario que creó el parche que hemos utilizado, dimos con una diferencia entre la forma en que Snort trata su salida estándar, y la forma en que lo hace Barnyard. En Snort, la “facility” alert guarda únicamente la información más relevante y la “facility” log guarda información extensiva acerca de las alertas generadas, mientras que Barnyard2 trata las “facility” en el modo inverso, enviando a alert información extensiva sobre las alertas generadas y a log únicamente una parte de la información.

Para aquellos más curiosos, el cambio principal que se realiza a la base de datos es la creación de una nueva tabla, llamada extra, que contiene los campos presentes en las cabeceras extra que hemos visto anteriormente. Los campos más relevantes son:

• sid y cid identifican la alerta asociada del mismo modo que en el resto de tablas.
• type indica el tipo de información que contiene la fila actual, según la clasificación mostrada en el post anterior.
• data muestra el campo finalmente obtenido.

A continuación se puede ver un extracto de esta tabla:

A partir de aquí podemos empezar a utilizar estos nuevos datos para obtener informes que nos resulten interesantes.

Por mostrar dos ejemplos, con la siguiente consulta se pueden obtener todas las alertas que disponen de cabeceras extra, mostrándolas:

select e.sid, e.cid, s.sig_name, e.timestamp, x.type, x.data from event e inner join 
      signature s on e.signature=s.sig_id inner join extra x on e.cid=x.cid and 
      e.sid=x.sid; 

La siguiente consulta nos muestra las firmas que están generando cabeceras extra:

select s.sig_name from event e inner join signature s on e.signature=s.sig_id inner join 
     extra x on e.cid=x.cid and e.sid=x.sid group by s.sig_name;

Por nuestra parte, vamos a utilizar esta información extra para tratar de descubrir los equipos detrás de proxys que tienen comportamiento anómalo (P2P, Malware, Spyware, etcétera), pero con el tiempo queremos ampliar su uso para conocer, por ejemplo:

• Qué nombres de equipo están comprometidos y sirviendo malware.
• A qué nombres de equipo se conectan los malware que tenemos en nuestra organización.
• Quienes son los usuarios que envian correos con contenido malicioso.
• Quienes son los usuarios que reciben correos con contenido malicioso.

¿Se os ocurren más usos de esta información? Si es así, escribidlo en los comentarios.

A partir de la versión 2.9, Snort ha ido introduciendo mejoras en sus preprocesadores de HTTP y SMTP que permiten la extracción por separado de varios campos importantes de conversaciones HTTP y SMTP.

La primera de ellas fue la posibilidad de reconocer las cabeceras X-Forwarded-For y True-Client-IP que añaden algunos proxies, para reconocer los equipos que realmente están produciendo las alertas en entornos en los que la navegación HTTP se realiza a través de estos dispositivos.

En la versión 2.9.1 se han introducido nuevos campos que pueden ser de utilidad en el análisis de alertas. Estas incluyen las siguientes:

HTTP: Dirección IPv4 True-Client-IP/XFF (Tipo 1)
HTTP: Dirección IPv6 True-Client-IP/XFF (Tipo 2)
HTTP: Datos Gzip descomprimidos (Tipo 4)
SMTP: Nombre de fichero adjunto (Tipo 5)
SMTP: Origen del correo (Campo MAIL FROM) (Tripo 6)
SMTP: Destino del correo (Campo RCPT TO) (Tipo 7)
SMTP: Cabeceras del correo (Tipo 8)
HTTP: URI de la petición (Tipo 9)
HTTP: Nombre de host solicitado (Cabecera Host) (Tipo 10)
Dirección de origen IPv6 del paquete (Tipo 11)
Dirección de destino IPv6 del paquete (Tipo 12)

[Read more…]

La semana pasada se publicó en El Mundo una noticia en la que se hablaba de que la privacidad que Facebook aplica a las fotos que subimos a la red social, de la que @mkpositivo se hizo eco a través del twitter.

En la noticia se indica que, cualquier usuario, sin necesidad de estar registrado en Facebook, puede acceder a cualquier foto hospedada en la red social, previo conocimiento de su URL.

Veámoslo mejor con un ejemplo. A continuación se puede ver una foto subida por mí a Facebook. Se puede ver como en la configuración de visibilidad aparece compartida únicamente con mis amigos.

Si pulsamos con el botón derecho encima de la foto y seleccionamos la opción “Propiedades” en Internet Explorer, “Ver información de la imagen” en Firefox, o “Copiar URL de imagen” en Chrome, podemos obtener la URL de la foto. Luego solo es necesario pegarla en otro navegador distinto, o acceder tras hacer cerrado la sesión.

[Read more…]