Paper.- Los costes ocultos de los certificados SSL autofirmados

Si, el titulo es un poco largo y posiblemente ya sabéis por donde va el tema, esperad que os pongo un poco al día.

Hoy en mis que haceres matutinos me ha sorprendido un hombre que me aseguraba que un certificado autofirmado era valido por qué la empresa que se ocupaba de instalar la herramienta se dedicaba exclusivamente a ello y por ahorrarse unos Euros pues que no lo iban a cambiar. Por lo que mi cabeza a empezado a dar chispazos y les he tenido que pasar el siguiente Paper para que entraran un poco en razón.

 

Es un poco antiguo pero a mi me ha venido la mar de bien para explicarles porque un certificado autofirmado es inseguro y ademas da una visibilidad horrenda de la empresa. Sobretodo he remarcado lo siguiente

Otro de los riesgos de usar certificados autofirmados para sitios internos es que los empleados acaben por hacer caso omiso de los avisos de seguridad del navegador y empiecen a añadir certificados a la lista de certificados fiables cuando de hecho no lo son . Esto no solo pone en riesgo las redes y sistemas internos, sino que además conduce a una peligrosa actitud de permisividad respecto a la seguridad de la empresa y va en contra de las normas más básicas de
seguridad de cualquier sistema interno . 

Por último, con los certificados autofirmados las empresas también corren más riesgo ante las amenazas avanzadas persistentes (APT) o los ataques con varios vectores, debido a que las CA internas suelen carecer de los procesos y medidas de seguridad que sí adoptan las CA externas .Por ejemplo, puede darse el caso de que el servidor donde se almacene y administre CA esté conectado a la misma red que se utiliza también para otros sistemas, sin establecer límites
de seguridad físicos adicionales . Normalmente, las CA internas carecen de control de acceso biométrico para utilizar la clave raíz que genera los certificados . Esto incide negativamente en
el nivel de seguridad y el rigor con el que se emiten los certificados . En definitiva, las empresas operan con un falso sentido de la seguridad .

Enlace al paper: 

•  https://symantec.certicamara.com/media/4252/costos_ocultos_de_los_certificados_autofirmados.pdf

Sed Buenos ;)

BadSSL.- Comprueba tu conexión con un clic

En el último año las siglas SSL han resonado muy fuerte tanto que ya siento un sudor frío siempre que veo alguna noticia relacionada con este protocolo. También sabéis que soy una persona un poco paranoica y me gusta hacer algunos checkings antes de realizar ciertas conexiones. 

Así que hoy ha sido una agradable sorpresa encontrarme con BadSSL del Proyecto Chromium aplicación web la cual nos permite verificar la seguridad de nuestro cliente web con solo hacer un clic.  Si, podríamos hacer estas comprobaciones a mano pero también verifica si tu cliente esta siendo victima de algún truco malicioso por parte del fabricante. 

Muy recomendable, echadle un ojo: 

• https://badssl.com/

Sed Buenos ;) 

Ettercap Text Only Manual

Hoy, pensando en mi flamante Raspberry Pi con pantalla táctil, me he puesto a buscar alguna guía que me explicara como funciona sslstrip junto a Ettercap para poder programar un sencillo bash o script en python para que lo configure todo directamente y no tener que tirar de tantas dependencias como lo hace WarBerry. 

Si, se puede automatizar el proceso, pero mi duda a llegado al ver el siguiente comando de ettercap: 

• ettercap -T -q -i tarjeta_de_red -M arp:remote /IP_VICTIMA/ /IP_ROUTER/

Seguro que vosotros lo sabéis, pero yo en el momento que he visto esto me he quedado sin saber que hacía cada una de las opciones. A ver, algunas se pueden intuir pero otras no.  Así que me he puesto a buscar algún manual, guía o chuleta, que me explicara estas opciones y aunque es un poco vieja, os recomiendo el siguiente manual. 

• http://www.irongeek.com/i.php?page=backtrack-3-man/ettercap

Lo explican todo, en ingles pero de una manera genial y creo que es la mejor manera para saber como funciona esta herramienta. 

Pero si realmente queréis saber lo que hace esta herramienta y como funciona tambien os recomiendo el An Ettercap Primer de SANS. También es antiguo, pero vale mucho la pena a nivel técnico. 

• https://www.sans.org/reading-room/whitepapers/tools/ettercap-primer-1406

Sed Buenos ;) 

Firefox y Su ¡No Toco SSLv3 y RC4 Ni Con Un Palo!

Hace un par de días que Mozilla Firefox que, aparte de solucionar algunas vulnerabilidades criticas como las siguientes: 

• CVE-2015-2731: Las vulnerabilidades críticas residen en un uso después de liberar memoria cuando Content Policy modifica el Document Object Model para eliminar un objeto DOM 
• CVE-2015-2722: Uso de memoria después de liberarla en workers mientras se usa XMLHttpRequest. 
• CVE-2015-2733: Uso de memoria después de liberarla en workers mientras se usa XMLHttpRequest. 
• CVE-2015-2724: Diversos problemas de corrupción de memoria en el motor del navegador
• CVE-2015-2726: Diversos problemas de corrupción de memoria en el motor del navegador 
• CVE-2015-2734: Múltiples vulnerabilidades encontradas a través de inspección de código
• CVE-2015-2740: Múltiples vulnerabilidades encontradas a través de inspección de código

Sino que le ha dado una patada de esas que utilizamos todos para esconder la suciedad debajo de las alformbras, al protocolo SSLv3 y a RC4,  La verdad es que ya era hora de que alguno de los navegadores mas importante del "mercado" se posicionara después de que el IETF dese a este protocolo como muerto. 

Algunos sabréis lo fan que soy de Google Chrome pero creo que, si no encuentro mas noticias al respecto, cambiaré de navegardor. Volveré a esa época donde usar plugins era molón. 

Sed Buenos y actualizad vuestro Firefox. 

Señores SSLv3 Ha Muerto

Hoy estoy de enhorabuena, no solo puedo centrarme en este tipo de entradas as libres y con mucha mas personalidad sino que por fin el [IETF siglas de Internet Enginnering Task Force] (Organismo que produce documentos técnicos pertinentes que influyen en el diseño de manera que la gente, usa y gestiona Internet)  ha declarado al protocolo SSL 3.0 Muerto, aunque ya era hora porque 20 años de protocolo han dado para mucho. 

¡¡SSLv3 ha muerto!! ¡¡Saca el cava tio sácalo!! http://t.co/cEnn7C9Gqd

— StateX (@State_X) julio 1, 2015

Este protocolo nos ha dado muchos dolores de cabeza a los que nos dedicamos a la gestión de vulnerabilidades desde POODLE. Hasta yo he pensado en tener un postit anunciando los días sin una vulnerabilidad en SSLv3. Así que me alegro mucho de que en el RFC 7568 lo proclamen como obsoleto.

"The Secure Sockets Layer version 3.0 (SSLv3), as specified in RFC 6101, is not sufficiently secure. This document requires that SSLv3 not be used. "

"The replacement versions, in particular, Transport Layer Security (TLS) 1.2 (RFC 5246), are considerably more secure and capable protocols."

Bueno, ahora solo tenemos faena para gestionar el cambio a TLS y a que salgan nuevas vulnerabilidades para esta nueva versión del protocolo.

Fuente:

• https://www.blogger.com/blogger.g?blogID=497157915730062003#editor/target=post;postID=6375697191115024240

Sed Buenos y sacad el cava antes de que sea tarde ;) 

Otra Vulnerabilidad en OpenSSL.- Si, Otra Vez

Últimamente y desde la vulnerabilidad Poodle OpenSSL se ha vuelto el blanco de los investigadores de seguridad. Me gusta que aparezcan este tipo de vulnerabilidades, ya que si no fueran publicado y "los malos" supieran de su existencia, podrían utilizarlas con fines malignos. 

Hablo de la vulnerabilidad CVE-2015-1791 publicada el 2 de Junio de este año.

CVE-2015-1791:  Un fallo en una condición de carrera cuando un cliente multihilo recibe un NewSessionTicket al intentar reusar un ticket anterior. Lo que comporta una doble liberación de memoria en los datos del ticket. El impacto aun no ha sido especificado. 

Productos afectados: 

• OpenSSL:
• 0.9.8o-4squeeze14 
• 0.9.8o-4squeeze20 
• 1.0.1e-2+deb7u13 
• 1.0.1e-2+deb7u16
• 1.0.1k-3
• 1.0.2a-1 

Más información: 

• https://git.openssl.org/?p=openssl.git;a=commit;h=98ece4eebfb6cd45cc8d550c6ac0022965071afc
• https://security-tracker.debian.org/tracker/CVE-2015-1791
• http://unaaldia.hispasec.com/2015/06/nueva-vulnerabilidad-en-openssl.html

Solución:

• Aplicar el parche correspondiente: 
• enlace: https://github.com/akamai/openssl/commit/c0bf69a791239ceec64509f9f19fcafb2461b0d3

Si, se supone que debería seguir con el CEH pero hoy me apetecía muchísimo volver a este tipo de entradas, ademas me ahorro trabajo mañana que es lo bueno que tiene que te guste tu trabajo.

Sed Buenos y parchead el OpenSSL.   

Configuraciones SSL Robustas Gracias a CIPHERLI.ST

Hoy, como no podria ser de otra manera, me disponía a leer el blog de Security by Default como cada día cuando al devolverme el navegador la pagina web, me he encontrado de cara con su articulo 

[CIPHERLI.ST: CONFIGURACIONES SSL ROBUSTAS PARA SERVICIOS]. 

Así que, en plena vorágine de vulnerabilidades en Open SSL y de problemas para actualizar a TSL una pagina que se dedica a la recolección de configuraciones robustas para diferentes servicios con el único fin de securizarlos, merece que sea compartida.

Si tenéis mas curiosidad sobre esta pagina web os dejo el enlace aquí: 

• https://cipherli.st/

Fuente: 

• http://www.securitybydefault.com/2015/04/cipherlist-configuraciones-ssl-robustas.html

Sed Buenos ;) 

¡RC4 Debe Moir! ¡Yo Pongo Las Antorchas!

Hace unos días hablamos de la futura actualización de OpenSSL. La cual esperábamos con bastante impaciencia ya que, lo que ha estado pasando con el protocolo SSL no tiene nombre. Lo en realidad tiene mas gracia de todos es que aunque consigas que toda una empresa actualice a TLS 1.0 aun tendrás problemas ya que el algoritmo de cifrado de RC4 también está comprometido. Así que, si no tuviste ojo antes de proponer la actualización te tocara revisarlo. 

Por esto,  me ha hecho especial ilusión encontrarme con el trabajo de [Christina Garman], [Kenny Paterson] y [Thyla van der Merwe] sobre porque RC4 debe morir y presentando diferentes tipos de ataques al algoritmo de cifrado. 

"Our attacks enhance the statistical techniques used in the previous attacks and exploit specific features of the password setting to produce attacks that are much closer to being practical. We report on extensive simulations that illustrate this. We obtain good success rates with 226 encryptions of the password. By contrast, the previous generation of attacks required around 234 encryptions to recover an HTTP session cookie."

La verdad es que han dejado fino a RC4 sobre TLS y sobretodo si sois unos apasionados de la criptografia y las matemáticas  os recomiendo mucho que leáis su paper. 

Por si teneis curiosidad os dejo el enlace a la página aquí abajo:

• http://www.isg.rhul.ac.uk/tls/RC4mustdie.html

Fuente: 

• http://seguinfo.blogspot.com.es/2015/03/rc4-debe-morir-mas-ataques-htttps.html

Sed Buenos con esto 0;) 

Infografia.- Como Funciona El Ataque POODLE

Hace unas semanas que apareció el ataque POODLE ("Padding Oracle On Downgraded Legacy Encryption") en nuestras vidas gracias al equipo de seguridad de Google. El cual, ya ha hecho un post amplio [al respecto de esta vulnerabilidad en su blog] de seguridad.  

POODLE es una vulnerabilidad bastante chunga en SSLv3 que, en el caso que un atacante nos hiciera un The Man In The Middle y capturase nuestra información podría romper el cifrado SSL. Pero, mejor que veáis esta imagen que os quedará mas claro. 

Sed Buenos ;) 

Qualys SSL Labs.- SSL Server Test

La verdad es que no debería sorprender ver servidores que aún no han parcheado la famosa vulnerabilidad HeartBleed o la mas reciente [CVE-2014-0224] bastante parecida a HeartBleed pero teniendo que realizar un ataque Man in the Middle previo, pero me sorprende. Mirado desde este punto de vista, la pasividad de los administradores para actualizar/parchar sus sistemas nos da un poco de margen para trastear y hacer reportes. Pero, para los que estáis en el lado de la seguridad defensiva podéis hacer uso como el SSL Server Test de Qualys SSL Labs para ver que grado de protección tenemos en nuestro SSL. 

 

"Este servicio gratuito en línea realiza un profundo análisis de la configuración de cualquier servidor web SSL en el Internet público. Tenga en cuenta que la información que envíe aquí se utiliza exclusivamente para prestarle el servicio."

Es sencillo, fácil de usar y podemos pasarnos unos buenos ratos jugando con esto  ^^ 

Sitio Web:

• https://www.ssllabs.com/ssltest/

Fuente:

• http://www.globbtv.com/4090/noticias/todavia-hay-20000-sitios-web-muy-populares-con-la-vulnerabilidad-openssl

Sed Buenos con esto ;) 

Ojo Con Los Certificados SSL Falsos

Muchas veces he hablado con mis amigos sobre los peligros que hay al comprar un articulo en una pagina que no sea de confianza o sin el pertinente certificado SSL. Seria una locura no hacerlo, pero nunca caigo a explicarles que un certificado SSL puede ser falsificado y que deberían examinar ese certificado cada vez que quieran corroborar su seguridad. (Tampoco es tan seguro como quisiéramos todos, pero menos da una piedra.)

Este sistema de certificaciones es muy utilizado y no solo esta relacionado con las webs sino que cualquier software que haga una conexión a Internet puede elegir que esta conexión sea segura. De esta manera no tenemos que controlar solo el Https típico sino,  todos los certificados que recibe nuestro equipo cuando realiza peticiones a la red. 

Si extrapolamos esto a equipos mas pequeños como los smartphones y sus aplicaciones el resultado es el siguiente: 

"Las aplicaciones de banca en línea para dispositivos móviles son tentadores objetivos para ataques man-in-the-middle, como la validación de certificados SSL está lejos de ser trivial, y aplicaciones móviles a menudo no alcanzan el nivel de la validación realizada por los navegadores web. 40% de iOS- aplicaciones bancarias basadas probados por IO activa son vulnerables a este tipo de ataques porque no pueden validar la autenticidad de los certificados SSL presentadas por el servidor. 41% de las apps Android seleccionados resultaron ser vulnerables en las pruebas manuales de la Universidad Leibniz de Hannover y de la Universidad Philipps de Marburg en Alemania. Ambas aplicaciones y navegadores también pueden ser vulnerables si un usuario puede ser engañado para instalar certificados raíz sin escrúpulos a través de ingeniería social o de los ataques de malware, aunque este tipo de ataque está lejos de ser trivial en un iPhone. " Netcraft dijeron los investigadores."

Así que, solo mirar el certificado de una web nos dejaría medio expuesto a todos los demas factores de risgo.  (Seria como utilizar TOR cuando otro esta mirando tu pantalla sentado en la mesa de atrás)

No me lo tengáis en cuenta pero es que venia muy al hilo xD

Fuente: 

• http://thehackernews.com/2014/02/Fake-SSL-Certificates-non-browser-applications-MitM-Attacks.html#

Sed Buenos ;) y que no os vea yo sin comprobar estos certificados. xD

BREACH Mis Hipoteis .- Reventar Https En 30 segundos.

Hoy dando una vuelta por los pocos blogs que puede leer ahora por culpa de mi ISP. Bueno, la cuestión es que recordareis que en la entrada de ayer dije que me parecía raro el silencio que había a  habido  después de la aparición de The Beast en el campo del Https. Pues cual ha sido mi sorpresa que en el blog de [HackPlayers] publicaron ayer un articulo donde hablaban de BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) una herramienta para sacar información en conexiones https la cual se presento en la BlackHat de este año.

"Fue presentada en la última conferencia Black Hat y se aprovecha varias vulnerabilidades de forma similar a lo que hacía CRIME con deflate, es decir, ataca al algoritmo de compresión aunque en las respuestas HTTP. Eso sí, como comentamos la información sensible ha de estar en las respuestas HTTP, el servidor por supuesto ha de utilizar compresión HTTP y el exploit requiere que la víctima visite primero un enlace malicioso."

 Me queda un largo día revisando los papers de la BlackHat para ponerme al día, pero os dejo con el Paper de BREACH para amenizar estas tardes de verano.

Paper: http://www.iacr.org/cryptodb/archive/2002/FSE/3091/3091.pdf

Sed Buenos ;)

HTTPS Everywhere.- ¿Conexiones Cifradas? Si Porfavor

Avanzando en el proyecto Prism"A" he topado con esta extensión que me encantaría que todos la probaseis y os hicierais una opinión. La verdad es que hace mucho que hable de SSL/TLS y https y de lo importante que es el cifrado de nuestra conexión en ciertos momentos sobretodo cuando queramos, por ejemplo, si queremos realizar cualquier pago a través de una tienda online, conectarnos a nuestra banca utilizando Internet, etc

HTTPS Everywhere es una extensión para Firefox y Chrome (en Chome me da algún problema de vez en cuando pero en Firefox aun no he tenido ninguno) que cifra sus comunicaciones en la gran mayoría de sitios web. (realmente en todos los que puede o le dejan xD) Muchos sitios en la web ofrecen un apoyo limitado para el cifrado sobre https, y hacen que sea difícil de usar. De esta manera podemos evitar esos sitos que tienen https sin cifrar por defecto, o páginas cifradas con enlaces que se remontan a algún sitio sin cifrar. 

Ademas este proyecto no es muy partidario de la NSA por lo que le hace sumar puntos en el proyecto Prism"A" aunque conociendo a BEAST, la cual, daba caña a https y el silencio que hay ahora mismo sobre avances en ese campo, me da que sospechar. así que no descarto la inclusión de esta extensión en un Firefox en Debian pero, aun lo dejo en fase de Stanby eh intentar encontrar una capa que recubra esos posibles fallos que pueda tener https.

Os dejo que enlace aquí abajo para que os hagáis vuestra opinion: 

• https://www.eff.org/https-everywhere

Sed Buenos ;) 

Slide.- Introducción a SSL

Si ya visteis el [articulo de ayer], prometí que haría una presentación comentada en SlideShare. Bueno he tenido tiempo de hacer las slides y el audio pero la pagina se niega a subir mi mp3. La parte buena, es que ha conseguido subirse la presentación entera, así que espero que os guste y os sirva de repaso a mas de uno. 

SSL/TLS.- Introducción

SSL (Secure Socket Layer) y su hijo TLS (Transport Layer Security) son protocolos de seguridad de uso común  Su función es establecer un canal seguro entre 2 equipos a través de Internet o un red interna. SSL llegó a la versión 3.0 que fue presentada en  1996 y reino hasta que en 1999 se definió TLS 1.0 como una actualización para SSL 3.0. 

Este protocolo se hace notorio para el usuario cuando el navegador detecta un certificado SSL y nos informa de ello mostrándonos un candado en la barra de navegación. 

Nociones básicas sobre SSL

• Primeramente se negocia entre los 2 equipos que algoritmo se utilizará para la comunicación.
• Luego se intercambiaran las claves publicas basadas en certificados.
• Y para acabar, se cifra el trafico con un cifrado simétrico. 

Todo tarde o temprano acaba cediendo y no fue hasta el 23 de septiembre del 2011 cuando Thai Duong y Juliano Rizzo demostrarían como hacer sangre de las restricciones de  TSL 1.0 con una prueba de concepto llamada BEAST (Browser Exploit Against SSL/TLS) usando una applet java. 

La base teorica de esta vulnerabilidad ya fue descubierta por Philip Rogaway en 2002 pero nadie sabia como implementarla.

Android y El Certificado SSL

El otro día vimos como entrar en un table/smartphone [saltándonos el patrón]de forma fácil. Pues hoy hablar de los fallos que pueden dejar a nuestro terminal a manos de un usuario remoto.

Muchas son las empresas que estas optando por implementar certificados en sus aplicaciones. Sin embargo esto no garantiza que nuestros datos estén seguros. Es mas, un grupo de investigadores estadounidenses ha cogido una muestra de 13.000 aplicaciones y ha descubierto que mas de 1.000 aplicaciones son vulnerables y podría provocar el robo de nuestra información.

Pues todo esto se debe a una mala implementación del certificado SSL. Se estima que el 20% de las aplicaciones con este certificado son propensas al robo de información. Ademas de estarle dejando a los Ingenieros del malware poder firmar sus aplicaciones con este tipo de certificados los cuales pueden hacerles escurrirse por  los controles que haga el antivirus.

Lo malo es que estamos hablando de un grado de Seguridad bastante elevado y hay escasas herramientas para poder hacerles frente. Como por ejemplo [Androguard]

Mas info: http://www.redeszone.net/2012/10/22/android-un-fallo-en-la-implementacion-de-ssl-deja-datos-al-descubierto/#more-23294