jueves, 13 de octubre de 2016

NMAP SCRIPTING ENGINE




Autor : @txambe

En el articulo de hoy vamos a ver una forma distinta de utilizar esta herramienta tan potente como es nmap normalmente utilizada como escaneador de puertos, en esta ocasión la utilizaremos como escaner de vulnerabilidades , no llega a la potencia de Nessus , Openvas , pero en determinados escenarios que no podamos utilizar dichos programas, nmap es un gran aliado a tener en cuenta.

Nmap Scripting Engine ( NSE ) es una de las opciones mas potentes que tiene nmap a parte de su función como escaner de red. Permite escribir scripts para automatizar tareas de red. Esos scripts pueden ser ejecutados en paralelo para así aprovecharse de de la velocidad y eficiencia de nmap.

Con NSE podemos acabar distintas tareas.

·         Auth: Verifica procesos de autenticación.
·         brute: Obtención de información por medio de fuerza bruta.
·         discovery: Recuperación de información de equipos.
·         dos: Relacionados con ataques del tipo DoS.
·         external: Script que utilizan servicios de terceras partes.
·         intrusive: Utiliza scripts que son considerados intrusivos para la víctima o target.
·         safe: ejecuta scripts “seguros” en cuanto a la intrusión de sistemas.
·         vuln: Verifica la existencia de las vulnerabilidades más conocidas.

Para mantener actualizados los scripts debemos ejecutar el comando nmap conscript-updatedb como parámetro.

En /usr/share/nmap/scripts/ (dependiendo el SO que corremos), se encuentran todos los scripts disponibles.

Comentar que los script de nmap están realizados en lenguaje LUA.

Para activar NSE deberemos escribir en la linea de comandos la opción -sC o --script si se quiere indicar un conjunto de scripts. Nmap soporte dos tipos de scripts de tipo servicio y de host..

Los  de tipo servicio relacionan  puertos abiertos ( servicio asociado )  en el objetivo.



Usando NSE

Para iniciar el motor de scripts:

 $nmap -sC 

Para seleccionar un script:

 $nmap –script

Pasar argumentos a los scripts:

   --script-args “http.useragent=0, hhtp.pipeline=15”
   --script-args  http.useragent=CUM,pipeline=10
   --script-args  whois={whodb=”no follow”}


Para realizar una selección  avanzada de scripts:

 nmap -p80 –script “http-*and(not(httpd-brute or http-slowloris))” < objetivo>


Recomendaciones de uso

No usar los dns de tu ISP , mejor usar los de google , por ejemplo:

nmap –dns-servers 8.8.8.8,8.8.4.4


Variar la configuración de tiempo:

nmap T5
Usar el filtro -p si solo interesa el resultado de cierto servicio:

$nmap -p80 –script http-trace 

Si trabajamos con scripts de tipo HTTP , mi recomendación es cambiar el user-agent:

$nmap -p80 –script http-enum 

Debido a la cantidad de argumentos que tiene , es recomendable tener otra consola abierta , en la carpeta donde están los scripts y usar:

c a t < script > | grep @args

O también entrar dentro de la carpeta de los scripts y desde ahí lanzar los scripts.


También una buena fuente de información sobre scripts no aceptados al repositorio oficial:


Enlaces interesantes a scripts no oficiales:

·         vulscan
·         http-google-email
·         http-screenshot

En este punto quería hablaros de una herramienta interesante , NSEarch no es mas que un buscador de scripts la podéis descargar de https://github.com/JKO/nsearch


Una vez descargada la herramienta , solo hay que descomprimir y lanzar su instalador. Cuando ya se encuentra instalada se puede ejecutar con el siguiente comando:

python nsearch.py



En el siguiente enlace podéis encontrar mas información:


Para distinguir entre versiones:

            Para la versión 5:  local http = require “http”

            Para la versión 6:  require “http”


Reglas de ejecución

Todos los scripts tendrán por lo menos una  de las siguientes funciones:

·         prerule()
·         hostrule(host)
·         postrule(host,port)
·         postrule()

Ejemplos de reglas de ejecución

Hay aliases como shortport.http

http = shortport_or_service ({80, 443 , 631 , 7080 , 8080 , 8088 , 5800 , 3872 , 8180 , 8000 }, {“http”,”https”,”ipp”,”http-alt”,”vnc-http”,”oem-agent”})

Una regla para servidores:

posrtrule = shortport.http


Formatos de salida

Nmap soporta distintos formatos de salida de datos XML, greppable ( aunque esta ya en desuso todavia nos puede ser útil en ciertas situaciones )  y normal. Pero solo se guardarán los datos si seleccionamos los formatos XML o normal.

Formato XML

Nmap genera elementos para el escaneo de puertos, detección de servicios y NSE. Anteriormente se guardaba en un elemento llamado ·         EXPOITABLE
·         VULNERABLE
·         NOT_VULN
 
Es muy recomendable asignarlo durante la ejecución:
 
vuln.state = vulns.STAT.VULN
 
Para generar el reporte se utiliza la función vulns.Report.make_output():
 
local report = vulns.Report:new(SCRIPT_NAME,host,port) return report:make_output(vuln_table)
 
 
Referencias:
 
·         https://nmap.org/book/nse.html
·         https://nmap.org/nsedoc/
 
 
Espero que os resulte de interés.
 
 
Happy h@cking.
 

 


-->< script > dentro del atributo ouput.

Al usar la función stdnse.output_table para guardar nuestros datos de salida se auto genera todo el árbol XML.

            Nse:

            local ouput_tab = stdnse.ouput_table()
            ouput_tab.ip = host.ip
            output_tab.hosts = domains

            return output_tab

Reporte de vulnerabilidades

Para realizar un reporte de vulnerabilidades, utilizaremos la librería vulns. La librería tiene una variable que lleva el registro del estado de la vulnerabilidad encontrada:

·         EXPOITABLE
·         VULNERABLE
·         NOT_VULN

Es muy recomendable asignarlo durante la ejecución:

vuln.state = vulns.STAT.VULN

Para generar el reporte se utiliza la función vulns.Report.make_output():

local report = vulns.Report:new(SCRIPT_NAME,host,port) return report:make_output(vuln_table)


Referencias:

·         https://nmap.org/book/nse.html
·         https://nmap.org/nsedoc/


Espero que os resulte de interés.


Happy h@cking.


domingo, 9 de octubre de 2016

Error de GPG al actualizar paquetes en Kali


Autor: @txambe

Esta semana se estrena en nuestro blog @txambe y nos cuenta sus problemas al actualizar Kali Linux, esta fue su experiencia.

Después de actualizar Kali Linux a la última versión  cuando ejecute un apt-get update me daba el error de GPG :
 “ GPG error: http://http.kali.org /kali Release: The following signatures couldn't be verified because  the  public key is not available  “


root@kali:~# aptitude update

Hit http://dl.google.com stable Release.gpg
Hit http://dl.google.com stable Release                                                      
Hit http://dl.google.com stable/main amd64 Packages                                          
Des: 1 http://repo.kali.org kali-bleeding-edge Release.gpg [819 B]                                                                                      
Des: 2 http://repo.kali.org kali-bleeding-edge Release [11,0 kB]
Err http://repo.kali.org kali-bleeding-edge Release                                             
Ign http://dl.google.com stable/main Translation-es_SV         
Ign http://dl.google.com stable/main Translation-es
Ign http://dl.google.com stable/main Translation-en
Des: 3 http://security.kali.org kali/updates Release.gpg [819 B]
Des: 4 http://http.kali.org kali Release.gpg [819 B]
Des: 5 http://security.kali.org kali/updates Release [11,0 kB]
Err http://security.kali.org kali/updates Release             
Des: 6 http://http.kali.org kali Release [21,1 kB]
Err http://http.kali.org kali Release
Descargados 23,6 kB en 3seg. (7.332 B/s)
W: Se produjo un error durante la verificación de las firmas. El repositorio no está actualizado y se utilizarán los ficheros de índice antiguos. El error GPG es: http://repo.kali.org kali-bleeding-edge Release: Las siguientes firms fueron inválidas: KEYEXPIRED 1425567400 KEYEXPIRED 1425567400 KEYEXPIRED 1425567400

W: Se produjo un error durante la verificación de las firmas. El repositorio no está actualizado y se utilizarán los ficheros de índice antiguos. El error GPG es: http://security.kali.org kali/updates Release: Las siguientes firms fueron inválidas: KEYEXPIRED 1425567400 KEYEXPIRED 1425567400 KEYEXPIRED 1425567400

W: Se produjo un error durante la verificación de las firmas. El repositorio no está actualizado y se utilizarán los ficheros de índice antiguos. El error GPG es: http://http.kali.org kali Release: Las siguientes firms fueron inválidas: KEYEXPIRED 1425567400 KEYEXPIRED 1425567400 KEYEXPIRED 1425567400

W: Se produjo un fallo al descargar http://repo.kali.org/kali/dists/kali-bleeding-edge/Release:
W: Se produjo un fallo al descargar http://security.kali.org/kali-security/dists/kali/updates/Release:
W: Se produjo un fallo al descargar http://http.kali.org/kali/dists/kali/Release:
W: Some index files failed to download. They have been ignored, or old ones used instead.


El problema tal como se muestra es que la llave pública GPG ha caducado, así que tenemos que importar la llave nueva que firma y da validez a los repositorios de Kali Linux.


Primero, debemos listar las claves de los repositorios que tenemos en el llavero (key-ring) con el comando apt-key list, por aquí el comando y su resultado:



root@kali:~# apt-key list



/etc/apt/trusted.gpg
--------------------
pub   1024D/7FAC5991 2007-03-08
uid                  Google, Inc. Linux Package Signing Key
sub   2048g/C07CB649 2007-03-08

/etc/apt/trusted.gpg.d//debian-archive-jessie-automatic.gpg
-----------------------------------------------------------
pub   4096R/2B90D010 2014-11-21 [caduca: 2022-11-19]
uid                  Debian Archive Automatic Signing Key (8/jessie)

/etc/apt/trusted.gpg.d//debian-archive-jessie-security-automatic.gpg
--------------------------------------------------------------------
pub   4096R/C857C906 2014-11-21 [caduca: 2022-11-19]
uid                  Debian Security Archive Automatic Signing Key (8/jessie)

/etc/apt/trusted.gpg.d//debian-archive-jessie-stable.gpg
--------------------------------------------------------
pub   4096R/518E17E1 2013-08-17 [caduca: 2021-08-15]
uid                  Jessie Stable Release Key

/etc/apt/trusted.gpg.d//debian-archive-squeeze-automatic.gpg
------------------------------------------------------------
pub   4096R/473041FA 2010-08-27 [caduca: 2018-03-05]
uid                  Debian Archive Automatic Signing Key (6.0/squeeze)

/etc/apt/trusted.gpg.d//debian-archive-squeeze-stable.gpg
---------------------------------------------------------
pub   4096R/B98321F9 2010-08-07 [caduca: 2017-08-05]
uid                  Squeeze Stable Release Key

/etc/apt/trusted.gpg.d//debian-archive-wheezy-automatic.gpg
-----------------------------------------------------------
pub   4096R/46925553 2012-04-27 [caduca: 2020-04-25]
uid                  Debian Archive Automatic Signing Key (7.0/wheezy)

/etc/apt/trusted.gpg.d//debian-archive-wheezy-stable.gpg
--------------------------------------------------------
pub   4096R/65FFB764 2012-05-08 [caduca: 2019-05-07]
uid                  Wheezy Stable Release Key

/etc/apt/trusted.gpg.d//kali-archive-keyring.gpg
------------------------------------------------
pub   4096R/7D8D0BF6 2012-03-05 [caducó: 2015-03-05]
uid                  Kali Linux Repository


Tal como se puede ver la fecha de caducidad, el uid de los repositorios de Kali Linux caducó el 5 de Marzo del año en curso 2015

Así que vamos a solucionar esto con el siguiente comando (más abajo el comando con su resultado):

apt-key adv --keyserver hkp://keys.gnupg.net --recv-keys 7D8D0BF6


root@kali:~# apt-key adv --keyserver hkp://keys.gnupg.net --recv-keys 7D8D0BF6

Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --secret-keyring /tmp/tmp.sYzbsBXbRo --trustdb-name /etc/apt//trustdb.gpg --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-jessie-automatic.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-jessie-security-automatic.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-jessie-stable.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-squeeze-automatic.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-squeeze-stable.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-wheezy-automatic.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-wheezy-stable.gpg --keyring /etc/apt/trusted.gpg.d//kali-archive-keyring.gpg --keyserver hkp://keys.gnupg.net --recv-keys 7D8D0BF6

gpg: solicitando clave 7D8D0BF6 de hkp servidor keys.gnupg.net
gpg: clave 7D8D0BF6: "Kali Linux Repository " 32 firmas nuevas
gpg: no se encuentran claves absolutamente fiables
gpg: Cantidad total procesada: 1
gpg:               nuevas firmas: 32



root@kali:~# apt-key list

/etc/apt/trusted.gpg
--------------------
pub   1024D/7FAC5991 2007-03-08
uid                  Google, Inc. Linux Package Signing Key
sub   2048g/C07CB649 2007-03-08

/etc/apt/trusted.gpg.d//debian-archive-jessie-automatic.gpg
-----------------------------------------------------------
pub   4096R/2B90D010 2014-11-21 [caduca: 2022-11-19]
uid                  Debian Archive Automatic Signing Key (8/jessie)

/etc/apt/trusted.gpg.d//debian-archive-jessie-security-automatic.gpg
--------------------------------------------------------------------
pub   4096R/C857C906 2014-11-21 [caduca: 2022-11-19]
uid                  Debian Security Archive Automatic Signing Key (8/jessie)

/etc/apt/trusted.gpg.d//debian-archive-jessie-stable.gpg
--------------------------------------------------------
pub   4096R/518E17E1 2013-08-17 [caduca: 2021-08-15]
uid                  Jessie Stable Release Key

/etc/apt/trusted.gpg.d//debian-archive-squeeze-automatic.gpg
------------------------------------------------------------
pub   4096R/473041FA 2010-08-27 [caduca: 2018-03-05]
uid                  Debian Archive Automatic Signing Key (6.0/squeeze)

/etc/apt/trusted.gpg.d//debian-archive-squeeze-stable.gpg
---------------------------------------------------------
pub   4096R/B98321F9 2010-08-07 [caduca: 2017-08-05]
uid                  Squeeze Stable Release Key

/etc/apt/trusted.gpg.d//debian-archive-wheezy-automatic.gpg
-----------------------------------------------------------
pub   4096R/46925553 2012-04-27 [caduca: 2020-04-25]
uid                  Debian Archive Automatic Signing Key (7.0/wheezy)

/etc/apt/trusted.gpg.d//debian-archive-wheezy-stable.gpg
--------------------------------------------------------
pub   4096R/65FFB764 2012-05-08 [caduca: 2019-05-07]
uid                  Wheezy Stable Release Key

/etc/apt/trusted.gpg.d//kali-archive-keyring.gpg
------------------------------------------------
pub   4096R/7D8D0BF6 2012-03-05 [caduca: 2018-02-02]
uid                  Kali Linux Repository
sub   4096R/FC0D0DCB 2012-03-05 [caduca: 2018-02-02]


Como se puede ver, el llavero de claves del repositorio de Kali ahora caducará hasta el 2 de Febrero de 2018

Despues de actualizar la clave, ya pude ejecutar apt-get update sin problemas y actualizar la versión de los paquetes con apt-get upgrade


Happy H@cking

domingo, 2 de octubre de 2016

SSL (III): Servidor bien configurado, páginas con problemas


Autor: @RaulRenales

Por último, para terminar esta trilogía de post sobre SSL y su configuración escribo este post con el objetivo de mostrar algunos problemas típicos que suelen pasar en la construcción de las webs alojadas en nuestro servidor habilitado para https.

Básicamente cuando nuestros diseñadores/desarrolladores realizan su trabajo y generan los contenidos de las webs alojadas en los servidores podemos encontrar errores de utilización de referencias http en sus trabajos.

A este problema se le denomina “Errores de contenido mixto” y pueden desembocar en diferentes resultados, como por ejemplo que un recurso sea inaccesible por la codificación, fallos en pasarelas de pago, revelación de usuarios y contraseñas en el tráfico de la web al viajar en texto plano, etc …
Pongamos un ejemplo, Imaginemos que subimos un contenido que utiliza una url externa en http en el campo action de un formulario. Si enviamos este formulario pese a estar en un contexto de navegación https los contenidos enviados son fácilmente reconocibles:


Como podemos ver en la imagen, tenemos un formulario que incluye una llamada http, en Chrome este problema se identifica rápidamente dado que no ofrece “candadito verde” por problemas de contenido mixto, pero en otros navegadores sí que podemos ver el “candadito verde” y tener una cierta sensación de seguridad.

El código del formulario es este:
Como podemos ver se hace la llamada al buscador de una página de libros para realizar directamente la búsqueda desde nuestra web, podría haber sido un login u otra funcionalidad.

Al enviar el formulario podemos ver con ZAP como podemos capturar el texto plano del envió:


Bueno, desde el punto de vista de la seguridad no es gran cosa, no hemos descubierto una nueva vulnerabilidad, pero es muy común encontrarte estos problemas en la vida real y en ocasiones no son tan leves como nuestro ejemplo.

Recientemente he encontrado estos problemas en módulos de terceros utilizados en los más famosos CMS del mercado, en ocasiones incluso en alguna pasarela de pago muy famosa y avalada por uno de los primeros bancos de este país.

Por resumir, el uso de contenido mixto provoca:

  • Perdida de la encriptación del contenido
  • Problemas de accesos a los recursos
  • Falsa sensación de seguridad en el usuario

Bueno, espero que esta trilogía SSL haya sido de vuestro agrado y que os haya permitido tener una visión más amplia sobre HTTPs y SSL.

Como Bonustrack os ofrezco una serie de enlaces interesantes sobre otro problema relativo a la navegación segura, en concreto con el problema de seguimiento HSTS, no quiero desarrollarlo en este post para no hacer otro mastodonte, pero prometo hablar de él más a fondo en el futuro.



martes, 27 de septiembre de 2016

SSL (II) - Fine tunning de servidores y no morir en el intento.


Autor: @RaulRenales

En episodios anteriores mostramos como obtener información de la instalación de certificados SSL para habilitar la navegación segura. Vimos cómo en algunos casos la nula o mala configuración de estos certificados presenta vulnerabilidades graves y agujeros de seguridad.

En este post intentaremos hablar sobre la configuración de estos certificados con el objetivo de obtener la calificación A+ de Qualys SSL Labs.


Paso 1: Obtención de los certificados. (Configuración básica)


Para la obtención de los certificados debemos o bien autogenerarlos, o bien debemos adquirirlo en alguno de los proveedores disponibles en internet. La oferta es muy variada y van desde precios muy elevados a pocos euros dependiendo de la entidad certificadora que los otorga y la calidad del certificado.

Nos centraremos en la compra de los certificados donde el proveedor nos tiene que facilitar los siguientes archivos:
  •          www.dominio.com.key - es el fichero con la Llave Privada que se ha usado para este certificado. Es privado y sólo Apache debe de tener acceso.
  •          www.dominio.com.crt - es el fichero con el Certificado SSL que queremos instalar en nuestro servidor web.
  •          ProveedorSSL-ca.crt - es el fichero con el certificado de la autoridad certificadora (CA) que ha firmado el certificado.



Paso 2: Configuración básica de los certificados en el servidor.


Una vez subidos los archivos al servidor procedemos a la configuración de los mismos en nuestro servidor.

Lo primero es dejar los archivos cada uno en su sitio:
  • Copiamos www.dominio.com.key en /etc/ssl/private
  • Copiamos www.dominio.com.crt en /etc/ssl/certs
  • Copiamos ProveedorSSL-ca.crt en /etc/ssl/certs


Ahora llega el momento de poner en marcha nuestro apache, lo primero activar el módulo ssl, para ello accedemos a nuestro servidor y en la consola habilitaremos el módulo con el siguiente comando:

sudo a2enmod ssl

Debemos asegurarnos de que el archivo ssl.conf este bien configurado, podremos encontrarlo en la ruta:

 /etc/apache2/mods-enabled/ssl.conf

Y deberíamos hacer que tuviera este aspecto añadiendo las rutas de nuestros certificados:

NameVirtualHost [Ip del servidor]:443

< VirtualHost [Ip del servidor]:443>
       ServerSignature On
       SSLCertificateFile    /etc/ssl/certs/ www.dominio.com.crt 
       SSLCertificateKeyFile /etc/ssl/private/ www.dominio.com.key        
       SSLCertificateChainFile /etc/ssl/certs/ ProveedorSSL-ca.crt 

      SSLEngine On



Una vez con el material en su sitio comenzamos a configurar la plantilla web que contiene los parámetros de navegación https, que podemos encontrar en la siguiente dirección:

/etc/apache2/sites-available/default-ssl

Su configuración básica debería de tener un aspecto similar a esto:

 ServerName mysite.com:443
 ServerAlias www.mysite.com
 DocumentRoot /var/www/sitioseguro


Tras realizar cualquier cambio en estos archivos, ya sea en el ssl.conf, como en el default-ssl  debemos de reiniciar apache para recoger los cambios:
 
#Comprobamos que las configuraciones realizadas son correctas
apache2ctl configtest
 
#Reiniciamos Apache2
sudo service apache2 restart

Hasta aquí lo que sería  una configuración muy básica de un servidor apache. Con ella obtendremos una bonita F en el test de Qualys. En el siguiente paso intentaremos subir nota y que no nos quede para septiembre.

 


Paso 3: Mejorar la configuración básica.


La idea principal de este punto es mejorar la configuración de nuestro servidor Apache2 y conseguir una seguridad más fuerte en el manejo de la navegación segura. Iré sugiriendo algunas configuraciones o operaciones para mejorar los problemas concretos detectados en estos casos.


Problema: Heartbleed

Heartbleed es una vulnerabilidad detectada en la versión 1.0.1f de OpenSSL, que permite a un atacante leer la memoria de un servidor o un cliente, permitiéndole por ejemplo, conseguir las claves privadas SSL de un servidor.

El único consejo que debemos dar en este punto es actualizar la librería OpenSSL y saltar la versión vulnerable. Para ello en nuestra consola lanzaremos el siguiente comando:

sudo apt-get openssl update
o
sudo apt-get openssl upgrade


Problema: SSL Compression (CRIME attack)


CRIME son las siglas de Compression Ratio Info-leak Made Easy, un exploit que trabaja contra las cookies generadas en las navegaciones HTTPS y SPDY que utilizan compresión de datos. Básicamente, cuando recuperamos el contenido de las secret authentication cookies se permite a un atacante obtener una sesión de usuario autenticado en la web atacada.

Para realizar este hechizo, CRIME utiliza SSL Compression como piedra angular con lo que puede ser muy interesante que deshabilitemos esta funcionalidad de en nuestro módulo SSL.
A partir de la versión 2.2.24 de Apache podemos incluir la siguiente línea en la configuración SSL para mitigar el problema:

SSLCompression off

Para versiones anteriores a la 2.2.24 de Apache se recomienda compilar OpenSSL sin soporte ZLIB. Con esto deshabilitamos el uso del método de compresión.

Problema: SSLv2 and SSLv3

La versión SSL v2 es insegura con lo que lo más normal es que la tengamos deshabilitada en nuestro servidor, además deshabilitaremos la versión SSLv3 para evitar que un atacante pueda habilitarlo para deshabilitar el forward secrecy.

Además SSLv3 permite explotar el bug de POODLE, con lo que esta es una muy buena razón para que deshabilitemos esta versión.

De nuevo en nuestro archivo de configuración del módulo SSL debemos incluir lo siguiente:

SSLProtocol All -SSLv2 -SSLv3


Problema: Poodle and TLS-FALLBACK-SCSV

Como hemos comentado en el punto anterior SSLv3 permite la explotación del bug POODLE. Y como comentamos en el punto anterior es razón suficiente para deshabilitar esta versión.

Además, Google ha propuesto una extensión para SSL/TLS llamada TLSFALLBACKCSV para prevenir el ataque de downgrades de versiones forzados en SSL, esta extensión estará habilitada para versiones recientes de OpenSSL. Recomendación actualizar OpenSSL.


Problema: OpenSSL CCS vuln. (CVE-2014-0224)

ChangeCipherSpec, más conocido por sus siglas CCS es una vulnerabilidad detectada en la librería OpenSSL en junio de 2014. Para más información recomiendo leer este txt: 

https://www.openssl.org/news/secadv/20140605.txt

La recomendación básica es actualizar OpenSSL a la última versión.


Problema: OpenSSL Padding Oracle vuln. (CVE-2016-2107)

Esta vulnerabilidad recientemente detectada abre la puerta a un atacante para desencriptar el tráfico de una conexión que utiliza AES CBC y está lanzándose en un servidor que soporta AES-NI

La manera más sencilla de solucionar este punto es mediante la actualización a la última versión de la librería OpenSSL.


Problema: OpenSSL OCSP Status Request extension unbounded memory growth (CVE-2016-6304)


Importante vulnerabilidad detectada en la extensión OCSP de OpenSSL mediante la cual se podría permitir el agotamiento de la memoria del servidor provocando una denegación de servicio. El atacante tan solo tendría que renegociar con esta extensión continuamente hasta agotar la memoria del servidor, la mayoría de los servidores con configuraciones por defecto son vulnerables a este ataque.

La solución a este problema es actualizar OpenSSL

Más información: http://security.360.cn/cve/CVE-2016-6304/

Problema: The BEAST attack and RC4

The Beast attack es un ataque que mediante la manipulación del algoritmo de encriptación CBC se puede desencriptar parte del trafico encriptado. Para más detalles se recomienda visitar este enlace: 


Para configurar nuestro servidor deberíamos incluir en nuestro archivo de configuración apache2.conf las siguientes líneas:

SSLHonorCipherOrder On
SSLProtocol -all +TLSv1 +SSLv3
SSLCipherSuite RC4-SHA:HIGH:!MD5:!aNULL:!EDH:!ADH
SSLInsecureRenegotiation off


Problema: Fallos en SNI

SNI son las siglas de Server Name, es una extensión del protocolo TLS.1 Este indica qué nombre de host el cliente está intentando conectar antes de que el proceso de handshaking se complete. Esta funcionalidad permite a un servidor utilizar múltiples certificados en una misma dirección IP y número de puerto y permitir múltiples sitios seguros (HTTPS).

En ocasiones si tenemos mal configurado nuestro servidor los handshakes no se completan y se provocan rechazos a las llamadas de determinados user-agents.

Para tener correctamente configurado el servidor no debemos olvidar incluir en la configuración del template ssl el siguiente comando:

ServerName www.example.com

ServerAlias example.com www.example.com




Problema: supports weak Diffie-Hellman (DH)


El protocolo criptográfico Diffie-Hellman es un protocolo de establecimiento de claves entre partes que no han tenido contacto previo, utilizando un canal inseguro, y de manera anónima (no autenticada).


Se emplea generalmente como medio para acordar claves simétricas que serán empleadas para el cifrado de una sesión (establecer clave de sesión). Siendo no autenticado, sin embargo, provee las bases para varios protocolos autenticados.

En ocasiones este protocolo presenta deficiencias en su uso que podemos solventar con las siguientes configuraciones:

Cipher Suites

Debemos deshabilitar el soporte para SSLv2 y SSLv3 y habilitar el soporte para TLS, debemos modificar la configuración en el archivo apache2.conf o en el propio de SSL dejándolo de esta manera:


SSLProtocol             all -SSLv2 -SSLv3

SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

SSLHonorCipherOrder     on

DH Parameters

En las últimas versiones de Apache (2.4.8 y superiores) y en OpenSSL 1.0.2 o superior se puede especificar los parámetros DH directamente, quedando de esta manera:

SSLOpenSSLConfCmd DHParameters "{path to dhparams.pem}"



Finalizando ...


Si se siguen estos pasos mejoraremos la seguridad de nuestro servidor y evitaremos algunos problemas. En el próximo post hablaré de cómo después de haber afinado el servidor y pasando los test con buena nota podemos joderla y tener un servidor inseguro.

lunes, 26 de septiembre de 2016

Taller hacking etico otoño 2016

El próximo 20 de octubre  arrancara un nuevo grupo de talleres para las tardes de los jueves en UNED Guadalajara. En esta ocasión la temática sera Hacking ético. El objetivo es formar a los componentes de la asociación en estas materias aunque el taller esta abierto a cualquier persona que quiera realizarlo (pertenezca o no a la asociación).

Tasa Asociados: 30€ 
Tasa no Asociados: 150€ 

Se otorgara certificado  por la asociación al finalizar todos los talleres con aprovechamiento.

Nota: Se podrá plantear un Taller 0 para reciclar conceptos sobre sistemas operativos, redes y utilización de CMD y SHELL, con el objetivo de comenzar el curso en condiciones óptimas

Interesados pueden poner en contacto en el email: asociacion@honeysec.info


Fecha de los talleres: (Horario de 19.15 a 21.30 horas)







domingo, 25 de septiembre de 2016

SSL (I) - Information gathering


Autor: @RaulRenales

Recientemente por temas de trabajo he tenido que revisar algunos servidores Apache y la manera en la que tienen configurados sus certificados que habilitan la navegación segura. La experiencia me pareció interesante para compartir en este blog dado que hay mucha gente que no tiene claro algunos conceptos sobre certificados y servidores.

Este artículo es el primero de una serie de tres entradas relativas a SSL y configuración de servidores Apache.

En esta primera entrada hablaremos de cómo podemos obtener información relativa al certificado que nuestro servidor web tiene instalado y que diferentes opciones o herramientas tenemos.

Opción 1:  Qualys SSL Labs (https://www.ssllabs.com/ssltest)


Una de las primeras opciones que siempre me gusta utilizar es la herramienta online de Qualys. Se trata de una herramienta 100% online y que nos puede dar un primer vistazo y muchas pistas de cómo está configurado nuestro servidor.


Como se puede ver en la imagen tan sencillo como indicarle el dominio o ip del servidor y dar al botón enviar. 

Una vez finalizado el análisis podemos observar los resultados, donde lo primero que veremos será una evaluación global con los puntos más importantes del análisis.


Si tiramos de scroll hacia abajo podremos ver los detalles del análisis, que se agrupan en dos categorías:

  •          Authentication: donde podremos ver los datos del certificado y de los certificados adicionales o intermedios relacionados con el principal.



  •         Configuration: donde podemos ver datos relativos a los protocolos, Cipher suites, área de simulación de handshakes para ver cómo se comporta nuestro certificado con varios user-agents. En la zona de Protocol details quizá podamos obtener la información más relevante de cara a explotar alguna vulnerabilidad relacionada con el certificado.


Como se puede ver en la siguiente imagen, el análisis ha encontrado una vulnerabilidad grave en esta instalación. Se trata de CVE-2016-2107 que permite obtener información sensible sin cifrar a través de un ataque de padding-oracle contra una sesión AES CBC.



Se trata de un conjunto de herramientas que nos ayudaran con los trabajos relacionados con los certificados y su instalación en los servidores. Además de la opción Checker que nos ofrece datos tan interesantes como los vistos en la opción 1, esta web nos ofrece herramientas de conversión de certificados, revisión de logs de transparencia y alguna que otra opción más.






Opción 3: SSL Tools (https://ssl-tools.net/)

Por último, y por no alargar mucho el post, también podemos utilizar la web SSL Tools, una interesante web que vive para y por el SSL. Entre sus opciones podemos encontrar interesantes herramientas que nos harán la vida más fácil.

También encontraremos muy buena información sobre vulnerabilidades como Heartbleed y Poodle.



Bueno, creo que de momento con estas tres opciones cubrimos de sobra la obtención de información sobre los certificados instalados en webs con navegación segura, permitiéndonos utilizar la información para avanzar en nuestra auditoría, o bien, afinar la configuración de nuestro servidor de cara a minimizar los riesgos.

En la próxima entrega hablaremos de cómo podemos afinar los servidores y obtener la nota más alta en los análisis que hemos visto anteriormente, nos vemos…