Mostrando entradas con la etiqueta SSL. Mostrar todas las entradas
Mostrando entradas con la etiqueta SSL. Mostrar todas las entradas

miércoles, 25 de julio de 2018

Chrome dice que mi sitio no es seguro ¿Qué hago?

Hoy es el día elegido (no os quejéis, podrían haber escogido un viernes) para que el navegador Google Chrome comience a marcar los sitios que no posean un certificado como "No seguro". De momento es un mensaje adosado al nombre del dominio visitado, en gris. No salta a la vista, es algo discreto y con las prisas con las que vivimos hoy día no parece que a muchos les vaya a molestar...hasta que en octubre de este mismo año, ese mismo mensaje, se cabree y se torne de color rojo chillón...Ya lo contaba nuestro compañero Carlos 'Maestro' Ledesma en otra UAD. 

Casi es seguro, el resto de navegadores menos uno seguirá la estela marcada por Chrome. Con el tiempo añadirán el mismo mensaje o similar. Así que toca extender un certificado y configurar adecuadamente el cifrado del servidor para que ese mensaje desaparezca cuando nuestros visitantes entren en nuestros dominios. Pero no queremos que esa sea la motivación principal. Existe otra (y muchas más) importantes por las que ya deberías estar ofreciendo cifrado incondicional en todos y cada uno de tus sitios. Además vamos a derribar unos cuantos mitos acerca de los costes y complejidades inherentes a su despliegue.





1.- Respeta la privacidad de tus clientes o visitantes

Las conexiones cifradas no son un adorno ni están ahí para que "salga el candadito". Están para que otros no capturen y lean el tráfico que se produce entre cliente y servidor. Es posible que creas que ese tráfico "no es importante", pero en muchos contextos sí que lo es e importa mucho. Incluso si tu sitio es presencial y no existen formularios o campos de búsqueda, la propia traza de visitas de URLs del sitio ya permite crearse un perfil de la persona afectada por no cifrar las comunicaciones. 

2.- Da autenticidad a tu dominio

Sin un certificado debidamente extendido un visitante no sabría diferenciarlo de un sitio falsificado. Visitar un dominio no implica que sea el sitio correcto, tanto con un ataque de envenenamiento de la caché DNS como con un ataque sobre rutas BGP nos permite falsificar un sitio si este no posee un certificado adecuado. 

3.- Es gratis

Muchas personas y organizaciones piensan que extender un certificado es caro y un gasto innecesario (o simplemente, no dan importancia a los motivos del punto 1). No solo no es caro, es gratis. Iniciativas como Let's Encrypts nos permiten poseer un certificado libre de costes directos. No hay excusas si habías mirado la inversión en certificados como un gasto inútil. Es gratis. 0 euros. Nada.

4.- Es sencillo

No tengo/No voy a dedicar personal/tiempo para una tarea así. A veces no es cuestión de dineros sino de tiempo o no tener el personal adecuado para extender e instalar un certificado. En realidad es una tarea sencilla, no es compleja. Elige el certificado adecuado (recuerda, Let's Encrypts...es gratis!), lo obtienes, sigues los pasos indicados por el emisor (todos tienen una guía, por ejemplo), reinicias el servidor y a funcionar.

5.- Mejora tu imagen

A ver. ¿Cómo va a ser lo mismo una conexión plana, ahí, sin candado ni verde y con un mensaje de "No seguro" que una conexión cifrada con un buen candadazo TLS 1.3? Eso dice mucho. Da fuerza, vigor y sienta principios: "Esto es seguro, bueno (toc, toc) y de confianza". Aunque no lo hagas por la privacidad, te salga gratis y te lo instale un amigo con conocimientos informáticos al que invitarás a una paella a cambio, al menos piensa que va a reforzar tu imagen.

Desbloquea un logro más:

6.- HSTS o mata tus conexiones inseguras

No es suficiente con el certificado y las conexiones bien configuradas, que eso es otro menester. Mientras no configuremos nuestros servidores para que les diga al navegador de nuestros clientes que no usen conexiones inseguras cuando nos visiten, todo esto podría no servir de mucho. 

Aunque dispongamos de lo anterior, los ataques de hombre en el medio suelen usar herramientas del tipo ssltrip, donde se puentea la conexión segura hacia una insegura. Sin embargo, si el navegador visitó antes de ese ataque nuestro sitio y recibió la cabecera HSTS entonces optará por no establecer una conexión plana (no cifrada) y cortará las comunicaciones que se dirijan a nuestro dominio. ¿Sencillo verdad?.

HSTS (https strict transport security) no es para nada difícil de implementar. Hay miles de guías para ello. Una sola cabecera http puede proteger a tus clientes y visitantes de ataques de hombre en el medio de forma bastante sencilla y eficaz.






David García
@dgn1729




Más información:

Google dará el tiro de gracia a los sitios HTTP en 10 días:







viernes, 27 de enero de 2017

Nuevas versiones de OpenSSL solucionan cuatro vulnerabilidades

El proyecto OpenSSL ha anunciado la publicación de nuevas versiones de OpenSSL destinadas a corregir cuatro vulnerabilidades, tres calificadas de impacto medio y otra de importancia baja.

OpenSSL es un desarrollo "Open Source" que implementa los protocolos SSL y TLS, y que es utilizada por multitud de programas, tanto para implementar dichos protocolos (por ejemplo, HTTPS) como para emplear sus componentes criptográficos individuales (funciones de cifrado y "hash", generadores de claves, generadores pseudoaleatorios, etc).

El primer problema, con CVE-2017-3731, afecta a clientes o servidores SSL/TLS en sistemas 32bits cuando se usa un cifrado específico, entonces un paquete truncado puede provocar una lectura fuera de límites en ese servidor o cliente. Para OpenSSL 1.1.0 el fallo afecta cuando se usa CHACHA20/POLY1305; para OpenSSL 1.0.2 el problema se puede explotar con RC4-MD5.

Otra vulnerabilidad de gravedad media, con CVE-2017-3730, afecta a OpenSSL 1.1.0 si un servidor malicioso suministra parámetros incorrectos para un intercambio de claves DHE o ECDHE, puede provocar una desreferencia de puntero nulo en el cliente con la consiguiente caída. Un usuario malicioso podría provocar condiciones de denegación de servicio. 

Otra vulnerabilidad de gravedad media, con CVE-2017-3732, reside en un error de propagación de acarreo en BN_mod_exp() puede permitir obtener determinada información sobre claves privadas en determinadas circunstancias. Se ven afectados sistemas configurados con parámetros DH persistentes y que compartan claves privadas entre múltiples clientes.

Por último, de gravedad baja y con CVE-2016-7055, las multiplicaciones Montgomery pueden producir resultados incorrectos. El problema fue corregido anteriormente en la versión 1.1.0c, por lo que solo afecta a versiones OpenSSL 1.0.2.

OpenSSL ha publicado las versiones 1.1.0d y 1.0.2k disponibles desde

También se recuerda que las versiones OpenSSL 1.0.1 finalizaron su soporte a finales del año pasado.

Más información:

OpenSSL Security Advisory [26 Jan 2017]



Antonio Ropero
Twitter: @aropero

jueves, 7 de abril de 2016

Fundamentos de anatomía digital: "6 pasos esenciales antes de hacer click"

A lo largo de las escasas 24 horas que tiene un día tomamos cientos de decisiones. No es un número estable. Para algunos serán miles mientras que a otros les bastan unas pocas decenas. La mayoría de esas decisiones son triviales. ¿Papel higiénico acolchado, perfumado, con estampaciones de flores silvestres? Mientras que otras disyuntivas, sin percibir su justo peso, pueden condenar al decisor a una penitencia doble. Por un lado el pago que conlleva las consecuencias de una mala opción y por otro el amargo sabor a derrota que se siente cuando se rememora el momento en el que se tomó la vía equivocada. Somos esclavos de nuestro tiempo y el tiempo es alimento de la historia, lástima que ésta viaje en un solo sentido y nos impida rectificar la huella de nuestras imperfecciones.

Una decisión que ha traído a muchos de cabeza, es ese momento en el que otorgaron un inocente y bienintencionado 'click' a un enlace que les prometía una recompensa en maravedíes o por el contrario, les conminaba a hacerlo bajo la amenaza del cadalso digital. Naturalmente hablamos del phishing.

Aunque tradicionalmente lo asociamos al fraude bancario, ni de lejos es exclusivo su uso para tales menesteres. Es más (y ahora nos ponemos de pie, arrastramos la silla hacia atrás y nos llevamos la palma de la mano al pecho), incluso nosotros mismos lo usamos en nuestras tribulaciones, cuando nos encargan un test de penetración (si, suena gracioso cuando no estás habituado a escuchar el término) y nos permiten usar ingeniería social.

El antiguo arte de engañar
Porque realmente, el mecanismo de funcionamiento de un phishing se basa en la ingeniería social. En el engaño, estafa, argucia, ardid, fraude, artimaña, señuelo, falsedad, confusión, burla, embuste, etc. (Tampoco vamos a engañaros en este punto, es evidente que hemos usado un diccionario de sinónimos). El arte del engaño es tan antiguo como su padre, el arte de codiciar lo ajeno. Estos dos nacen como respuesta a una pregunta que nace a su vez de la necesidad congénita del ser humano de simplificar y optimizar los procesos vitales: "¿Por qué esforzarme lo mismo que el otro si puedo enajenar lo que él tiene con menos esfuerzo?". Bendita economía.

Bien, pues ya que hemos instalado la idea de una mala decisión y construido el canal por el que queremos plasmar la concreción en un ejemplo, pasemos a ver qué defensas podemos levantar contra la toma de una pésima alternativa o un decálogo de medidas a tomar antes de pulsar un maldito enlace que nos lleve a la perdición en forma de ransomware o un derrame pecuniario en nuestros haberes bancarios.

1) Si no eres capaz de demostrar que no es un phishing, entonces ES UN PHISHING.

En Barrio Sésamo todos eran buenos
Me encantaba "Barrio Sésamo". Era un lugar donde el mal no tenía cabida. Todo era felicidad y buen rollo encantador. De hecho no veréis en ningún episodio a un personaje echando la llave a una puerta (¿Julián el del kiosco quizás?). Nadie era malo allí. ¿Cómo pensar mal de un puercoespín rosa de dos metros con la capacidad humana del habla y la movilidad óptica de un cenicero de bronce?

Al menos en lo que respecta a tus correos entrantes no habituales, piensa mal por defecto. Si ves un correo de tu banco. Demuéstrate a ti mismo que realmente viene de tu banco. Quizás te llamen paranoico pero siempre puedes responderles que cuenten con los dedos de una mano a cuantos paranoicos conocen que hayan sido timados. En la mayoría de los casos les sobraran cinco dedos. Seis o más en caso de padecer polidactilia. No falla.

Recuerda, el principio de inocencia no se aplica a los activos digitales. Es culpable por defecto, demuestra su inocencia. Esa es la actitud.

2) Lee el correo. En serio, lee el correo.

Lee el correo con alguien como él
Da igual el idioma que hables. Un correo verdadero y corporativo debería llegar con una perfección ortográfica y gramatical que cuando termines de leerlo llores de emoción o tu corazón palpite entregado a los placeres de la prosa.

Un truco que utilizo es leerlo con un señor como nuestro académico Pérez Reverte pero imaginario. Coges el texto del correo e imagina que el señor Pérez Reverte está sentado junto a ti leyendo el mismo correo. Cuando termines de leerlo (o terminéis) fíjate en su rostro y estate atento. Si se levanta, te da una palmadita en el hombro y se va, entonces el correo podría ser bueno. Si te lo imaginas agitado y desenvainando un sable del siglo dieciocho mientras brama improperios coetáneos del mismo con una tempestad de fondo. No falla. El correo tiene la validez equivalente a una promesa electoral. ES PHISHING.

3) Copia el enlace y compruébalo en sitios de reputación online.

Ten mucho cuidado al copiarlo. En serio, activar un enlace puede suponer que tu navegador se abra y se dirija a una fiesta organizada por un exploit kit. Así que deposita el cursor sobre el enlace lentamente, botón derecho, copiar y sepárate muy muy despacio de él. Poco a poco.

Ahora, con el enlace en el portapapeles, puedes comprobarlo en sitios web que van a decirte si la dirección está en una lista negra. Pero recuerda, y esta idea es importante: Estos sitios sólo demuestran que el enlace está en una lista negra. Es decir, si no aparece en la lista negra no significa que sea bueno, significa que no está incluido.

Recuerda. Estos sitios confirman una sospecha, no confirman una coartada.

¿Sitios? Hay muchísimos, unos pocos ejemplos.

Ya sabes. ¿Dominio en lista negra? ES PHISHING. ¿No está en lista negra? Entonces no está en lista negra.

4) Comprueba el dominio.

Suponemos que llegados a este paso, que has visto el correo y tu sentido común no te ha puesto en alerta. Lo has leído con tu imaginario escritor favorito a tu lado y le ha dado el visto bueno. Por último, el enlace no aparece en una lista negra. Bien, porque nos acercamos a una fase crítica. De la URL céntrate, de momento, en el dominio.

Pega la URL en tu editor de texto favorito. Disecciónala y quédate con el dominio. Hay lectores que tienen un nivel básico, no hay problema, todos tuvimos un primer día, el resto puede saltarse el ejemplo. Pongamos la URL de una "Una Al Día" cualquiera:


Comprueba el dominio
¿Veis las barras inclinadas a la derecha? Las /

Separan componentes. Parte la url en piezas tomando como referencia esas /

http:


2016

03

petya-un-nuevo-ransomware-que-impide-el.html

Eso que está en negrita es el dominio. Eso se transformará en una dirección IP a la que se irá nuestro navegador de manera transparente para traerte una página web. El problema es que tu navegador web es incapaz de decidir si lo que vas a visitar es la banca online o un servidor controlado por un atacante y preparado para filibustearte los dineros.

¿Cuál es el dominio de tu banco? ¿Adónde te diriges cuando vas a visitar el sitio web de tu banco?

Coge la URL que usas habitualmente de tu banco y haz lo mismo. Compara los dominios. ¿Son idénticos? ¿No? ES PHISHING.

Es cierto que los subdominios pueden variar:

Pero cuídate mucho de que la parte final, ese hispasec.com antes del primer punto sean iguales en ambos dominios. ¿No es así? ES PHISHING.

5) Comprueba el certificado SSL

Hubo un tiempo que el sinónimo de seguridad en la red era la presencia de un candadito amarillo en el navegador cuando visitabas un sitio "seguro". Cuánto daño ha hecho esa frase en el subconsciente de los usuarios proporcionando una falsa sensación de seguridad.

Hubo incluso malware, que una vez instalado en el sistema, le endiñaba un candado amarillo por defecto al navegador, con el simple cometido de despreocupar al usuario de lo que iba a pasar a continuación. Bajar la guardia y ¡bum!

El dichoso candadito amarillo
Un candadito amarillo solo significaba que la conexión iba "cifrada" y que el sitio tenía un certificado SSL. Punto. Ahora pensad un momento. ¿Qué detiene a cualquiera de comprar un dominio, extender un certificado sobre ese dominio y poner a la escucha un servidor que ofrezca un canal cifrado?

Hoy día puedes montar una infraestructura con un dominio, su certificado digital y un servidor con HTTPS establecido, de manera anónima y en menos tiempo del que llevas leyendo este artículo. Todo eso puede hacerse en cuestión de minutos e incluso de manera anónima, sin dejar rastro.

Una conexión segura lo único que te asegura es que el canal con el que te comunicas está cifrado y el certificado te dice que el dominio es de quien dice ser. Y eso lo podemos jurar siempre y cuando no salga un ataque criptográfico de última generación o a la certificadora de turno no le hayan trabuqueado un certificado raíz.

Así que el sitio web de tu banco tiene que presentar su dominio habitual, su certificado seguro, correcto, al día y asociado al dominio y una conexión cifrada de manera robusta. Si no es así, no hay duda: ES PHISHING.

Si el dominio es correcto, pero la conexión no es cifrada o el certificado no es válido entonces amigo, te están haciendo un hombre en el medio. Sal de ahí. Ya.

6) ES PHISHING

¡Templanza!
Este nivel requiere de una templanza propia de esos maestros sabios que aparecen en las películas de kung-fu de los 70 u 80.

El principio es muy sencillo. Da igual que el correo sea de tu banco o no. ES PHISHING. No se pincha en el enlace. No se visita ninguna URL. No se manda por fax ni correo ninguna documentación. No se contesta a ese correo. Ni se le hace caso.

Ya sabemos que puede sonar radical. Pero es tremendamente efectivo. Además te pone en una ventaja táctica. Usa una suerte de patrón Hollywood. Si quieren algo de ti y es importante, llámales tú a ellos. Ponte en contacto con tu banco a través de las líneas que tienen disponibles y coméntales lo que has recibido. Si es cierto te lo confirmarán y ya puestos arregla el marrón con ellos. Si es un phishing lo más probable es que hablando con ellos termines ayudando a otras personas desmontando el fraude cuanto antes.

Vosotros, nuestros lectores, tenéis un nivel de concienciación y técnico considerable. No todo el público posee ese nivel capaz de distinguir una estafa de una comunicación legítima. Incluso confesemos, hasta un ojo avezado y curtido en las amenazas puede ser engañado. Somos imperfectos.

Sin embargo el día a día avanza, las comunicaciones se tornan digitales y para bien de los árboles, el papel va siendo sustituido por un puñado de bits. No dejes que esos bits te estropeen un día o un mes o los ahorros de una década.

Esperamos que de una forma entretenida, con gotas de humor y unas pequeñas reglas, ayudemos a crear conciencia en usuarios menos entrenados, más confiados y por lo tanto más vulnerables.

Más información:

una-al-dia (03/06/2008) Mitos y leyendas: "Compruebe el candadito del navegador para estar seguro" I (Phishing)

una-al-dia (17/06/2008) Mitos y leyendas: "Compruebe el candadito del navegador para estar seguro" II (Troyanos)

una-al-dia (20/12/2004) Nueva técnica de "phishing" afecta a Internet Explorer

una-al-dia (12/07/2006) Troyanos bancarios y evolución del phishing


David García
Twitter: @dgn1729


miércoles, 2 de marzo de 2016

DROWN, un nuevo ataque que intenta ahogar la criptografía

Ayer, junto con la publicación de una nueva versión de OpenSSL, saltó a la luz una nueva vulnerabilidad de esas que van a dar que hablar durante mucho tiempo. Se suma a las ya vistas en el 2014 e igualmente importantes en OpenSSL como Heartbleed y POODLE. Esta nueva vulnerabilidad podría permitir a un atacante descifrar comunicaciones seguras con relativa sencillez.

Sin ninguna duda esta vulnerabilidad es de gran importancia, según las estimaciones un 33% de los sitios son vulnerables a este ataque. Y como no podía ser de otra forma, la vulnerabilidad viene con nombre, logo y hasta página web; ha quedado bautizada como DROWN (Decrypting RSA with Obsolete and Weakened eNcryption).

La vulnerabilidad es grave en cierto contexto, podría permitir descifrar sesiones TLS si el servidor soporta SSL versión 2 o suites de cifrado marcadas como EXPORT. El problema, con identificador CVE-2016-0800, es una nueva forma de ataque de protocolo cruzado, similar o inspirado en el Padding Oracle Attack de años atrás, debido al uso que hace de un protocolo obsoleto, como SSL versión 2, mientras que la víctima sigue usando TLS, un protocolo actualmente seguro, sin percatarse del ataque.

La misma página web del problema dispone de un test que permite comprobar, con la simple introducción de un dominio (o dirección IP), ver todos los dominios y certificados vulnerables. Huelga decir que no se trata de un test "en directo" sino de una consulta a una base de datos que han hecho pública. No obstante se ha hecho pública de una herramienta que permite comprobarlo en local.


Los servidores y clientes actuales emplean TLS como protocolo de cifrado. Sin embargo, debido a errores o descuidos de configuración, muchos servidores todavía siguen soportando SSLv2. Este soporte, incluso en algunos casos se apoya debido a que algunos clientes sin actualizar todavía utilizan SSLv2. Por lo tanto, a pesar de que SSLv2 se sabe que es inseguro hasta el tuétano, soportar SSLv2 no se consideraba, en ciertos ambientes, un problema de seguridad grave por el reducido parque de clientes anticuados que lo usan.

DROWN muestra que simplemente el soporte de SSLv2 representa un riego para los servidores y clientes; ya que puede permitir descifrar las conexiones TLS entre servidor y cliente mediante el envío de sondas a un servidor que soporte SSLv2 y utilice la misma clave privada. El ataque en sí, a grandes rasgos, se basa en la posibilidad de obtención de la clave privada de la sesión segura gracias a SSL versión 2. Es decir, mientras que el cliente se conecta al servidor por TLS, el atacante hace hombre en el medio entre los dos e inyecta peticiones SSL. Debido a las vulnerabilidades de SSL es capaz de obtener la clave privada de esa sesión (ojo, no la clave privada del servidor como hemos escuchado por ahí) y posteriormente utilizarla para descifrar el tráfico capturado.

Como proteger un servidor ante DROWN

Para OpenSSL la forma más sencilla y recomendable es que se actualice a la versión OpenSSL 1.0.2g o OpenSSL 1.0.1s.

Para Microsoft IIS (Windows Server) las versiones de IIS 7.0 y superiors deben tener SSLv2 desactivado por defecto. Los usuarios que hayan activado SSLv2 de forma manual deberán tomar los pasos para desactivarlo de nuevo. De todas formas se recomienda comprobar si su clave privada está expuesta en otro lugar. Las versiones de IIS inferiores a 7.0 ya no están soportadas por Microsoft y deberían actualizarse a las versiones soportadas.

Para Network Security Services (NSS), librería criptográfica incluida en múltiples productos de servidor, las versiones 3.13 (publicada en 2012) y superiores deben tener SSLv2 desactivado por defecto. Los usuarios que hayan activado SSLv2 de forma manual deberán tomar los pasos para desactivarlo de Nuevo. Usuarios de versiones anteriores deberían actualizarse a una versión más reciente. De igual forma se recomienda comprobar si su clave privada está expuesta en otro lugar.

Hay que señalar que DROWN puede empeorar debido a otras vulnerabilidades (con CVE-2016-0703 y CVE-2016-0704) en OpenSSL, que afectan a versiones de OpenSSL anteriores a marzo de 2015, momento en el cual el código fue rediseñado para hacer frente a la vulnerabilidad CVE-2015-0293. Estas vulnerabilidades afectan a OpenSSL versiones 1.0.2, 1.0.1l, 1.0.0q, 0.9.8ze y anteriores. Fueron corregidas en OpenSSL 1.0.2a, 1.0.1m, 1.0.0r y 0.9.8zf. Estos problemas podrían permitir ataques de DROWN mucho más eficientes, incluso eficaces contra conjuntos de cifrado que no sean de exportación, y sin necesidad de requerir un cálculo significativo.

Y con CVE-2015-3197 un problema que afecta a OpenSSL versiones anteriores a 1.0.2f y 1.0.1r, permite a un atacante emplear DROWN para conectar a un servidor con SSLv2 desactivado, si el soporte para SSLv2 todavía se encuentra habilitado.

Más información:

una-al-dia (02/03/2016) OpenSSL soluciona ocho vulnerabilidades

OpenSSL Security Advisory [1st March 2016]

The DROWN Attack

Test DWOWN Attack

Full technical paper
DROWN: Breaking TLS using SSLv2 [PDF]

una-al-dia (20/03/2015) OpenSSL soluciona 13 vulnerabilidades

una-al-dia (08/04/2014) OpenSSL afectada por una vulnerabilidad apodada Heartbleed

una-al-dia (15/10/2014) SSL tocado y hundido




Antonio Ropero
Twitter: @aropero

martes, 1 de marzo de 2016

OpenSSL soluciona ocho vulnerabilidades

El proyecto OpenSSL ha anunciado la publicación de nuevas versiones de OpenSSL destinadas a corregir ocho vulnerabilidades, dos calificadas de impacto alto, una de gravedad media y otras cinco de importancia baja.

Logo DROWN
El primero y más destacado de los problemas reside en una vulnerabilidad, de gravedad alta, que puede permitir descifrar sesiones TLS mediante el uso de un servidor que soporte SSLv2 y suites de cifrado de categoría EXPORT. Una vulnerabilidad de esas que llevan nombre, logo y hasta página web, bautizada como DROWN (Decrypting RSA with Obsolete and Weakened eNcryption).

DROWN (con identificador CVE-2016-0800) es una nueva forma de protocolo cruzado Bleichenbacher padding oracle attack, que permite a un atacante descifrar conexiones TLS interceptadas mediante conexiones específicamente creadas a un servidor SSLv2 que use la misma clave privada.

Por otra parte, dos vulnerabilidades, una de gravedad alta y otra moderada (con CVE-2016-0703 y CVE-2016-0704), que solo afectan a versiones de OpenSSL anteriores a marzo de 2015, momento en el cual el código fue rediseñado para hacer frente a la vulnerabilidad CVE-2015-0293. Estas vulnerabilidades afectan a OpenSSL versiones 1.0.2, 1.0.1l, 1.0.0q, 0.9.8ze y anteriores. Fueron corregidas en OpenSSL 1.0.2a, 1.0.1m, 1.0.0r y 0.9.8zf.

La importancia de señalar estos problemas en la actualidad reside en que cualquiera de los dos pueden permitir versiones más eficientes de DROWN, incluso eficaces contra conjuntos de cifrado que no sean de exportación, y sin necesidad de requerir un cálculo significativo.

De gravedad baja, una vulnerabilidad de denegación de servicio por una dobre liberación cuando OpenSSL trata claves DSA privadas mal construidas (CVE-2016-0705), una fuga de memoria en búsquedas SRP (CVE-2016-0798), referencia a puntero nulo y corrupción de heap en funciones BN_hex2bn y BN_dec2bn (CVE-2016-0797) y problemas de memoria en funciones BIO_*printf (CVE-2016-0799).

OpenSSL ha publicado las versiones 1.0.2g y 1.0.1s disponibles desde

También se recuerda por parte de OpenSSL que las versiones 1.0.1 acaban su soporte a finales de año.

Más información:

OpenSSL Security Advisory [1st March 2016]

The DROWN Attack

una-al-dia (20/03/2015) OpenSSL soluciona 13 vulnerabilidades



Antonio Ropero
Twitter: @aropero

martes, 3 de marzo de 2015

FREAK, un nuevo ataque a SSL/TLS

Hubo un tiempo en el que el gobierno de los Estados Unidos consideraba toda tecnología de cifrado propia restringida para su exportación, en la misma categoría que el equipamiento militar. El razonamiento que se ofrecía era la posibilidad de que los algoritmos de cifrado cayesen en manos enemigas y estos dispusieran así de una herramienta que entorpecería el trabajo de las agencias de inteligencia.

El mundo estaba cambiando. Habíamos rasgado el telón de acero y el final de la guerra fría cerraba un ciclo que estuvo a punto de hacernos retroceder varios milenios en la historia. Hablamos de los primeros años 90, donde las puntocom y el Internet de entonces iban soplando aire a pleno pulmón en una burbuja que terminaría por reventar años después. El comercio electrónico despegaba y era necesario ganarse la confianza del cliente tradicional.

La industria necesitaba el cifrado, los lobbies no tardaron en echarse encima de los políticos y estos terminaron por capitular abriendo progresivamente las reglas del juego para que el cifrado permitiese poner un "candadito amarillo" en el navegador. Internet "ya era segura" (en efecto, las comillas denotan una gran ironía).

Decimos progresivamente porque no fue fácil. Estados Unidos permitía el cifrado, su exportación y uso, pero con serias limitaciones. En primer lugar, solo se permitía la exportación de algoritmos de cifrado en una versión "reducida". Por ejemplo, dentro de Estados Unidos era posible obtener un navegador con una capacidad de cifrado mayor que su versión internacional, la cual usaría longitudes de claves muy inferiores, tan reducidas que era posible descifrar comunicaciones cifradas con dicho navegador de manera relativamente fácil. A esos conjuntos de cifrado se les marcaron con la pseudoetiqueta EXPORT.

Años después la situación fue cambiando poco a poco hasta el casi completo levantamiento de restricciones fronterizas. Los cifrados deliberadamente débiles fueron cayendo en desuso o sustituidos por mejores algoritmos y longitudes de claves mayores... pero no terminaron por desaparecer.

Todo esto nos permite ponernos en situación para entender un nuevo ataque. Consiste en una vulnerabilidad descubierta por un colectivo de investigadores bajo el nombre de SmackTLS. El fallo permitiría a un atacante en situación de interceptar las comunicaciones entre cliente y servidor renegociar la conexión segura y hacer que ambos usen uno de los cifrados de la categoría EXPORT, capturar dicho tráfico y descifrarlo con una capacidad computacional al alcance de cualquiera.

El ataque ha sido denominado por sus autores como FREAK (Factoring RSA Export Keys), tiene su propio dominio y web con capacidad para hacer pruebas. Tan solo le ha faltado un requisito (un icono representativo) para cumplir con todos los requisitos de esta tendencia mediática.

Como informan en la comentada web, tanto cliente como servidor han de soportar el conjunto de cifrados EXPORT. Concretamente servidor y cliente han de aceptar y ofrecer respectivamente un conjunto RSA_EXPORT o usar el cliente una versión vulnerable de la librería OpenSSL; algo que, entre otros productos, usan Android e iOS.

¿Qué hacemos?

Como se ha comentado, todo aquello que use una versión de OpenSSL anterior a las siguientes versiones es virtualmente vulnerable: 0.9.8zd, 1.0.0p, 1.0.1k. Especial mención a los servidores, como medida preventiva se ha de asegurar que no se esté ofreciendo soporte a cifrados EXPORT.

Desde la línea de comandos:

openssl s_client –connect servidor:puerto –cipher EXPORT

Un servidor vulnerable devolverá la salida del tipo (resumida):

New, TLSv1/SSLv3, Cipher is EXP-RC4-MD5
...
Cipher   : EXP-RC4-MD5

Ese "EXP" es, por supuesto, una suite de cifrado que pertenece a EXPORT y es de un servidor vulnerable.

Otro ataque más a OpenSSL y una nueva técnica que pone en riesgo la privacidad de las comunicaciones.

Más información:

SmackTLS

FREAK

OpenSSL Security Advisory [08 Jan 2015]
DTLS segmentation fault in dtls1_get_record (CVE-2014-3571)



David García
Twitter: @dgn1729


viernes, 9 de enero de 2015

OpenSSL soluciona ocho vulnerabilidades

El proyecto OpenSSL acaba de publicar un boletín en el que corrige ocho nuevas vulnerabilidades, la mayoría de ellas calificadas como impacto bajo a excepción de dos moderadas. Afectarían a la implementación de los protocolos SSL, RSA y DTLS entre otros.

Para empezar, con CVE-2014-3571, tenemos un fallo de segmentación en la función "dtls1_get_record", el problema viene de una referencia a puntero nulo que podría causar denegación de servicio al mandar un mensaje DTLS manipulado. Esto fue reportado por Markus Stenberg de Cisco. También en DTLS y causando denegación de servicio, Chris Mueller detecta un fallo de memoria en la función "dtls1_buffer_record" al enviar repetidos registros DTLS con el mismo número de secuencia pero distinta época, asignado CVE-2015-0206.

Con CVE-2014-3569 tenemos otra denegación de servicio descubierta por Frank Schmirler. La función "ssl23_get_client_hello" no maneja adecuadamente los intentos de uso de protocolos no soportados. Cuando se recibe un "SSLv3 Hello" y está configurada la opción "no-ssl3" provoca una referencia a puntero nulo.

CVE-2014-3572, pérdida de "Forward Secrecy" al omitir el mensaje "ServerKeyExchange" y permitir bajar de ECDHE a ECDH de forma transparente. De forma similar, con CVE-2015-0204, otro fallo que también puede facilitar la disminución del nivel de seguridad de la sesión al permitir una clave RSA temporal en suites de cifrado de tipo "non-export". El último de los saltos de seguridad, con CVE-2015-0205, consiste en un fallo en la función "ssl3_get_cert_verify" que permitiría la autenticación de un cliente con certificado DH sin necesidad de la clave privada. Fallos reportados por Karthikeyan Bhargavan del equipo Prosecco de INRIA.

No se verifican ciertas partes sin firmar de un certificado lo que puede permitir modificar la huella de éste. Hay que destacar que esta vulnerabilidad (CVE-2014-8275) no permite saltar la verificación de certificados, solo afecta a sistemas que tengan una lista negra basándose en la huella. Variantes descubiertas por Antti Karjalainen y Tuomo Untinen del programa Codenomicon CROSS program y Konrad Kraszewski de Google.

Y para concluir, con CVE-2014-3570 y reportado por Pieter Wuille (Blockstream), existe un fallo en la implementación de BN_sqr que podría no calcular correctamente el cuadrado de un valor BIGNUM lo que facilitaría a un atacante romper los mecanismos de cifrado. Este fallo ocurre de forma aleatoria y con muy poca probabilidad.

Los usuarios de OpenSSL 0.9.8 deben actualizar a 0.9.8zd, los usuarios de OpenSSL 1.0.0 deben actualizar a la versión 1.0.0p y los usuarios de OpenSSL 1.0.1 deben actualizar a 1.0.1k. También se recuerda por parte de OpenSSL que las versiones 1.0.0 y 0.9.8 acaban su soporte a finales de año.

Más información:

OpenSSL Security Advisory [08 Jan 2015]


Fernando Castillo

jueves, 11 de diciembre de 2014

POODLE también afecta a algunas implementaciones de TLS

Hace apenas dos meses informábamos sobre POODLE la vulnerabilidad que parecía destinada a enterrar definitivamente al protocolo SSL. Ahora podemos comprobar como el mismo problema afecta también a diversas implementaciones de TLS.

En octubre se dio a conocer la vulnerabilidad POODLE ("Padding Oracle On Downgraded Legacy Encryption"), que basa su ataque sobre el modo CBC (Cifrado por bloques) lo que hace que este modo sea vulnerable a un ataque variante de Padding Oracle.

En aquel momento, se daba por enterrado SSL y se instaba a obligar al uso de TLS. Recomendábamos también el uso de la opción TLS_FALLBACK_SCSV (https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00), para evitar que se efectúe una renegociación hacia SSL.

POODLE contra TLS

Como un negro augurio, en aquel momento nos preguntábamos por la seguridad de TLS ("¿Y tú TLS, como andas de clavos?"). No se ha tardado mucho, tampoco ha hecho falta descubrir una nueva vulnerabilidad. Unos investigadores de Qualys han descubierto que Poodle también puede funcionar en algunas implementaciones de TLS, incluyendo la última (la 1.2).

El problema radica en que los bytes den relleno empleados en TLS, no dejan de ser un subconjunto del relleno empleado en SSLv3, por lo que técnicamente se podría emplear la misma función de decodificación en SSLv3 con TLS y seguiría funcionando correctamente. De esta forma no se comprobarían los bytes de relleno, pero no causaría ningún problema en el funcionamiento de TLS. Sin embargo, si se usa una función de decodificación SSLv3 con TLS el mismo ataque Poodle funciona incluso contra conexiones TLS. A esta vulnerabilidad se le ha asignado el CVE-2014-8730 (http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-8730)

Y esto es lo que se ha detectado, algunas implementaciones de TLS hacen uso de funciones decodificadoras SSLv3, por lo que Poodle sigue funcionando en estos sistemas. Ahora la diferencia está en que en vez de afectar a todas las implementaciones de SSLv3, solo afecta a un conjunto restringido de fabricantes. Qualys estima que un 10% de los servidores pueden estar afectados por un ataque Poodle contra TLS.

Por ahora, se ha confirmado que el problema se reproduce en los balanceadores de carga F5 (BIG-IP) y en dispositivos ADC de A10 Networks. El mayor problema reside que estos productos son empleados por un gran número de compañías y puede llegar a afectar a algunos de los sitios web más populares. Ambos fabricantes ya han publicado las actualizaciones necesarias para evitar este problema:
Actualizaciones de F5
Actualizaciones de A10 networks

Más información:

Poodle Bites TLS

The POODLE bites again (08 Dec 2014)

una-al-dia (15/10/2014) SSL tocado y hundido

#CVE-2014-8730published onDecember 8th,2014

Patches for the CVE-2014-3566 Poodle/SSL v3.0 vulnerability

sol15882: TLS1.x padding vulnerability CVE-2014-8730

CVE-2014-8730 Padding issue


Antonio Ropero

Twitter: @aropero

miércoles, 15 de octubre de 2014

SSL tocado y hundido

Hoy despedimos a SSL. El último clavo necesario para la tapa de su ataúd fue amartillado por tres investigadores a nómina de Google. No tuvo una existencia fácil. Ya desde su nacimiento demostró una debilidad que le auguraba un porvenir lleno de complicaciones.

La primera versión ni siquiera vio la luz, se quedó en la morgue de Netscape. Sus creadores, que al poco presentaron la versión 2.0 al público, vieron como el escrutinio de la comunidad dejó en evidencia al protocolo con una lista de errores de seguridad que desmoronaba la confianza en su criatura. En 1996 se publicaba la versión definitiva de SSL, la tercera. A la tercera va la vencida. Y vencida fue.

En realidad, SSL ha sobrevivido a nuestros días como un reducto del pasado. En 1999 se publicaba la versión 1.0 de TLS. No era un protocolo que se diferenciase técnicamente de SSL. Si leemos el RFC correspondiente, vemos que incluso se refleja en su justificación "Las diferencias entre TLS 1.0 y SSL 3.0 no son dramáticas, pero lo suficientemente razonables para que no interoperen entre ellos". El mensaje era que TLS no iba a ser un SSL 4.0.

SSL ha ido soportando los distintos golpes en forma de BEAST, CRIME, etc. Pero con este último golpe, POODLE (¿GOOGLE?), ya no hay remedio posible, contramedida o unguentum armarium sobre el que prolongar la vida de SSL. Se acabaron las excusas.

POODLE ("Padding Oracle On Downgraded Legacy Encryption") basa su ataque sobre el modo CBC (Cifrado por bloques) lo que hace que este modo sea vulnerable a un ataque variante de Padding Oracle. La alternativa a CBC es usar un cifrado por flujo, RC4, pero este último ya fue condenado al destierro. En marzo de 2013 se publicó un ataque que permitía recuperar componentes de un mensaje cifrado con RC4 si estos componentes se repetían con cierta frecuencia. Pensemos en una cookie de sesión dentro de un mensaje HTTP.

¿Entonces va a destruir Poodle a Internet?

No, al igual que Heartbleed, Shellshock u otros tampoco va suceder nada extraordinario. Simplemente se ha de deshabilitar, siempre que se pueda, SSL y si se usa TLS impedir que se efectúe una renegociación hacia SSL si ambas partes, cliente y servidor, soportan TLS.

A día de hoy, en realidad casi todas las conexiones a sitios "conocidos" o la gran mayoría de servidores y clientes se efectúan en TLS. Ahora depende de los actuales sistemas o software soportar una versión u otra de TLS. SSL, en porcentajes, no es un protocolo muy usado, pero está ahí, latente, soportado y preparado para actuar cuando ambas partes no se ponen de acuerdo con TLS. Y ese es el problema que los investigadores proponen como caso de uso de la vulnerabilidad.

En la práctica

Imaginemos una red local, una víctima, sus secretos más codiciados y un atacante. La víctima se conecta a su banco, el atacante efectúa un hombre en el medio, se mete en la conversación del cliente con el banco y decide "estorbar" lo suficiente como para que el navegador de la víctima y el servidor del banco se cansen de negociar que versión de TLS y con el lio terminen usando SSL.

Ahora que se está usando CBC como cifrado, debido entre otras cosas porque en una auditoría al banco le dijeron que se abstuviese de soportar RC4, el atacante solo tiene que capturar una buena cantidad de paquetes para que mediante un análisis comience a obtener "piezas" de esa conversación privada y haga trizas la privacidad.

¿Dejamos de soportar SSL ya?

Sin duda lo haremos. Pero va a ser una despedida agónica. No podemos cortar las amarras y dar la voz de avante a máquinas hoy mismo. Aun hay un número nada despreciable de servidores y clientes obsoletos que se arrastran por los oscuros callejones de Internet que no conocen otro protocolo que SSL.

Como medida, lo único que podemos hacer es evitar que TLS se manche las manos y permita verse degradado a un apestado SSL. Es decir, evitar el escenario que comentábamos anteriormente. Para ello disponemos de una opción que evita que innecesariamente, a clientes y servidores que soporten TLS, se use SSL en su lugar. De esta forma aunque un tercero esté interceptando las comunicaciones y metiendo ruido en el canal no se termine usando SSL.

La opción en cuestión se denomina TLS_FALLBACK_SCSV documentada aquí (https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00). En principio evitaría que en las negociaciones y renegociaciones de sesión segura se cambie de TLS a SSL. Eso para los servidores que tengamos funcionando, de los clientes ya se están encargando los fabricantes (se puede verificar en esta web si el navegador es vulnerable). Por ejemplo Chrome implementa esta opción desde febrero de este año. Al menos algo es algo.

¿Y tú TLS, como andas de clavos?

Más información:

This POODLE Bites: Exploiting The SSL3.0 Fallback

This POODLE bites: exploiting the SSL 3.0 fallback

POODLE Test


David García
Twitter: @dgn1729

miércoles, 7 de agosto de 2013

Ataque BREACH, la seguridad HTTPS comprometida en 30 segundos

Dentro de la Black Hat USA 2013, sin duda una de las conferencias de seguridad más prestigiosas, un grupo de investigadores demostraron cómo es posible obtener información sensible del texto cifrado https en menos de 30 segundos.

El ataque recibe el nombre de BREACH que no solo puede traducirse como "brecha" sino que además atiende a las siglas de "Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext" (Reconocimiento y Exfiltración del navegador a través de compresión adaptativa del hipertexto).

Los investigadores Angelo Prado, Neal Harris y Yoel Gluck demostraron el ataque en la Black Hat contra la aplicación web Outlook Web Access (OWA). Una vez abierta la aplicación web y lanzado el ataque BREACH, en tan solo 30 segundos habían conseguido extraer la información del canal seguro. El ataque se basa en la inyección de texto plano en una petición https y medir los cambios en las respuestas comprimidas.



El ataque BREACH es un tipo de vulnerabilidad y no una instancia específica que afecta a una parte específica del software. Para ser vulnerable, una aplicación web debe:
  • Ser servida desde un servidor que utilice compresión a nivel http (la mayoría lo hacen).
  • Reflejar entradas del usuario en el cuerpo de la respuesta http.
  • Reflejar un secreto (como un token CSRF) en el cuerpo de la respuesta http.

El atacante necesitará realizar peticiones estratégicamente construidas al sitio atacado para recuperar un secreto concreto en el cuerpo de una respuesta https (incluyendo IDs de usuarios, direcciones de correo electrónico e incluso tokens de autenticación). Será necesario enviar un par de peticiones para cada carácter del secreto a adivinar.

Para un token de una longitud de 32 caracteres y un espacio de caracteres (alfabeto) de 16 (en hexadecimal), el atacante necesitará una media de aproximadamente 1.000 peticiones si no se necesitan mecanismos de recuperación adicionales (en caso de obtener múltiples respuestas posibles). En la práctica, se ha comprobado que es posible recuperar tokens CSRF con menos de 4.000 peticiones. Navegadores como Google Chrome o Internet Explorer son capaces de realizar esas peticiones en menos de 30 segundos (de ahí el titular), incluyendo las llamadas de vuelta al centro de comando y control del atacante (que puede ser un sitio controlado por el atacante con un iframe apuntando al servidor vulnerable, o directamente con la intercepción y modificación del tráfico no asegurado).

Actualmente no se conoce una solución práctica y global a este problema. Sin embargo se ofrecen diversas contramedidas, algunas de ellas pueden proteger aplicaciones completas mientras otras solo sirven ante páginas web concretas. Entre las contramedidas se describen el desactivar la compresión http, separar secretos de las entradas del usuario, que los secretos en cada petición cliente sean aleatorios, enmascarar secretos, proteger páginas web de ataques CSRF y ofuscar la longitud de las respuestas web añadiendo cantidades aleatorias de bytes arbitrarios.

Más información:

BREACH

BREACH: REVIVING THE CRIME ATTACK

SSL, gone in 30 seconds - a BREACH beyond CRIME

Vulnerability Note VU#987798
BREACH vulnerability in compressed HTTPS

Antonio Ropero
Twitter: @aropero