Tag Archive: SSL


https

Desde hace aproximadamente un año, las vulnerabilidades en los protocolos de comunicación supuestamente seguros han acaparado muchas de las noticias de seguridad informática. Fallo tras fallo, los últimos meses nos han dejado vulnerabilidades que han puesto de manifiesto la necesidad de abandonar definitivamente protocolos completamente rotos como SSL y revisar otros más seguros pero tampoco exentos de riesgos.

Desde Heartbleed hasta Freak, pasando por Poodle o Winshock, hemos visto numerosos ejemplos donde los datos de los usuarios podian ser robados por un atacante aun a pesar de ser transmitidos usando protocolos considerados como seguros por buena parte de los servicios de Internet. No obstante, estos casos también han provocado que la industria tome cartas en el asunto y ya se empiezan a ver las primeras reacciones para evitar seguir usando un canal de transmisión de datos confidenciales inseguro.

> Enterrando SSL

A pesar de tratarse de un protocolo con cerca de 20 años a sus espaldas, SSL v3.0 sigue siendo ampliamente utilizado para proteger conexiones que incluyen datos confidenciales. Pensemos por ejemplo en la comunicación que establecemos con nuestro banco cuando queremos realizar alguna operación a través de Internet. Los datos enviados pueden incluir nuestro nombre de usuario y contraseña, entre otros, y a nadie le gustaría que estos datos fueran fáciles de obtener.

Por suerte, la gran mayoría de entidades bancarias han realizado mejoras sustanciales para implementar la versión más avanzada del protocolo TLS disponible (v1.2 mientras que la v1.3 está terminando de definirse), aunque aún quedan unas pocas que no han terminado de realizar esta migración.

No ocurre lo mismo con un gran número de tiendas online que aun permiten la utilización de SSL 3.0 a pesar de que es vulnerable a ataques. De hecho, la gravedad de estas vulnerabilidades es tal que navegadores tan usados como Chrome y Firefox ya anunciaron dejar de soportar estas implementaciones antiguas para evitar poner en peligro a sus usuarios, muchos de los cuales aun piensan que la aparición de un candado en la barra de navegador ya es sinónimo de seguridad a pesar de usar un protocolo inseguro.

> Medidas necesarias

Así las cosas, no es de extrañar que el estándar PCI DSS, tan respetado en la industria, haya tomado la decisión de abandonar definitivamente el soporte para SSL y forzar la migración a TLS. Esto afectará principalmente a los sistemas de pago online, precisamente el aspecto más crítico de cara al usuario, pero tampoco debe suponer un gran esfuerzo puesto que los certificados de seguridad usados por SSL y TLS son los mismos. Esto significa que no deben volverse a adquirir.

Será a partir de la v.3.1 de PCI DSS cuando se obligue a este cambio y, los poseedores de un certificado SSL deberán contactar con sus proveedores de servicios para asegurarse de que cumplen con el estándar y no verse penalizados a la hora de ser marcados como sitio potencialmente peligroso por los navegadores.

Tampoco hay que olvidar que muchas empresas que venden a través de Internet ni siquieran entienden la importancia de contar con un protocolo de comunicación entre el cliente y su entidad de pagos online. Por eso es importante que se realice una campaña de concienciación para que todo el mundo que se vea afectado esté informado de la importancia de hacer este cambio.

> ¿Es TLS invulnerable?

Lamentablemente, la respuesta es que no al 100%. Sin embargo hay que matizar, puesto que un ataque contra el protocolo TLS v1.2 tenga éxito también depende de la implementación realizada. Y eso es así porque existen implementaciones de TLS que implementan funciones de descifrados propias de SSL v3, permitiendo que ataques como Poodle puedan funcionar ya sea haciendo undowngrade a la conexión de TLS a SSL o incluso directamente a TLS.

No obstante, TLS incorpora por defecto medidas de seguridad mucho más robustas que SSL y, lo que es más importante, se siguen desarrollando nuevas versiones (con la v1.3 prevista para dentro de poco). Esto permite solucionar cualquier fallo de forma más eficaz ya que no se trata de parchear un protocolo con lustros de antigüedad, sino de actualizar otro más reciente.

> ¿Cómo nos afecta como usuarios?

Al tratarse de una medida de seguridad que se ha de implementar desde el lado del que gestiona una web y no del que la visita, podría parecer que tenemos poco margen de maniobra y, en principio, deberíamos confiar en que las webs en las que confiamos implementen TLS. Sin embargo, tal y como hemos dicho anteriormente, los principales navegadores están realizando un esfuerzo para detectar aquellas webs que siguen utilizando un protocolo obsoleto y avisarnos para que seamos conscientes del riesgo que esto supone.

De esta forma, podremos saber rápidamente si el sitio en el que estamos a punto de introducir los datos de nuestra tarjeta de crédito cumple con los estándares de seguridad o no. Es una manera sencilla y continuista puesto que tan solo hemos de prestar la misma atención que hacemos ahora al candado que certifica que una conexión es segura. Además, es de utilidad seguir estos 7 consejos para una navegación segura.

> Conclusiones

Que se actualicen estándares para mejorar la seguridad de nuestras comunicaciones y, por ende, de los datos confidenciales transmitidos, siempre son buenas noticias. Sin embargo, los avances a la hora de descubrir nuevas vulnerabilidades se producen mucho más deprisa que las soluciones implementadas, más aun cuando se trata de estándares internacionales con largos plazos de implementación.

Es necesario que la industria sepa cómo reaccionar a este tipo de adversidades y para eso debe aliarse con la comunidad de investigadores, puesto que son ellos los que van a decirles donde están sus fallos y cómo solucionarlos antes de que sean aprovechados por los delincuentes y todos salgamos perdiendo.

Fuente | Welivesecurity

heartbleed-1

Primero fue Apple con el goto fail, un fallo que permitía interceptar y descifrar tus conversaciones seguras. Después vino GnuTLS, una librería de SSL para Linux, con un fallo que daba por válidos todos los certificados de un tipo concreto. Por si no teníamos suficiente con eso, hoy tenemos otro fallo extremadamente grave (mucho peor que los anteriores) en la librería OpenSSL.

OpenSSL es una librería ampliamente usada en el mundo del desarrollo para implementar SSL/TLS. Por ejemplo, el servidor Apache la usa para establecer conexiones HTTPS sin tener que preocuparse de los detalles de implementación. Servidores de correo, chat o redes privadas virtuales (VPNs) son otros servicios que suelen usar esta librería.

> Qué ha fallado

El fallo está en una función encargada de gestionar mensajes Heartbeat. Estos mensajes son llamados keep-alive: es una forma de decirle al servidor que sigues conectado y que no cierre la conexión. El mensaje que mandes puede tener una carga o contenidos (payload), como pueda ser la fecha en la que se ha enviado. El servidor recibe ese mensaje y responde al cliente con esa misma carga. Este tipo de esquema “te paso algo y me respondes con lo mismo” no es exclusivo de TLS: en los paquetes de ping, por ejemplo, también se pueden incluir datos para así calcular cuánto tarda el servidor en responder.

El cliente tiene que decir también qué longitud tiene esa carga, para que el servidor la pueda leer sin tener que adivinar dónde acaba. Y aquí es donde vienen los problemas. ¿Qué pasa si le digo al servidor que le estoy enviando mil bytes y en realidad sólo le estoy enviando uno?

Si habéis programado alguna vez en lenguajes de alto nivel, como Java, C# o JavaScript, pensaréis que eso fallará. Al fin y al cabo, estamos intentando acceder a cosas que no están ahí. Si mi paquete es una lista de bytes de longitud 10 y quiero leer el 20978, no tengo de dónde sacarlo y el programa debería pararse y reportar un fallo.

Pero OpenSSL está escrito en C, y en C las cosas no son tan felices. En este lenguaje, la variable“paquete” no es más que una dirección en la memoria RAM; por ejemplo, la 1076. El primer byte del paquete está en la posición 1076, el segundo en la 1077, el tercero en la 1078 y así sucesivamente.

Cuando se esté ejecutando un ataque, OpenSSL recibe un mensaje de longitud 10 (por ejemplo), que dice que tiene 200 bytes de carga y que almacena en la posición 1076. Cuando tenga que responder, empezará a copiar el byte 1076, el 1077, el 1078… así hasta el 1086. ¿Qué ocurre después? Fácil: OpenSSL sigue. A él le han dicho que hay 200 bytes (el código no verifica si la longitud que aparece en el paquete es incorrecta) y va a copiar sus 200 bytes. Es decir, seguirá leyendo y copiando hasta que llegue a la posición 1276.

¿Y qué hay en esas posiciones? Pues sorpresas. La reserva de memoria no es determinista así que puede haber absolutamente de todo. Quizás sólo hay basura, restos del paquete anterior – así es como se comprueba si un servidor es vulnerable – o la clave privada del servidor.

Repitiendo muchas veces el ataque – cada vez se pueden recuperar hasta 64 KB de la memoria del servidor – es probable que se acaben encontrando cosas de valor. Además, las estructuras más valiosas, como las claves privadas que comentábamos, son relativamente fáciles de encontrar cuando están guardadas en memoria. En resumen, es un fallo muy grave, una ventana abierta a los entresijos confidenciales de OpenSSL.

> ¿En qué me afecta a mí este fallo?

Vamos ahora a la parte práctica: en qué nos afecta esto a nosotros cómo usuarios. El fallo hace especialmente vulnerables a los servidores, así que en teoría no deberíamos preocuparnos, ¿no?

La realidad es que no. Heartbleed permite a los atacantes conseguir claves privadas de servidores, con las que podrían realizar ataques MITMRepasemos HTTPS: si un atacante tiene la clave de Google (por ejemplo), podría montar un servidor que se hiciese pasar por legítimo de Google. Tu navegador se conectaría a él y no te darías cuenta, de tal forma que en lugar de enviar tus datos confidenciales (correos, contraseñas, usuarios…) a Google, lo harías al atacante. Fantástico, ¿verdad?

Estaríamos hablando de miles de servidores potencialmente comprometidos. La vulnerabilidad se introdujo hace dos años, y no se sabe si alguien la ha estado explotando en secreto antes de que sea publicada. De hecho, la recomendación es que se revoquen los certificados SSL y se distribuyan otros nuevos por si han sido comprometidos.

¿Asusta? Pues todavía queda más. Hemos dicho que el fallo permite ver pedazos de la memoria del servidor. ¿Se puede ver algo más que las claves privadas? ¿Qué pasa si hay otros usuarios conectándose al servidor?

Lo que pasa es que se puede obtener información que permita robarles la sesión directamente. Los servidores de Yahoo!, por ejemplo, filtraban información de usuarios y contraseñas de sus propios usuarios. En texto plano. Sin ningún tipo de protección. Cualquiera podía ejecutar un comando en su ordenador y empezar a ver cómo aparecían contraseñas (ya han arreglado el fallo).

Entre la facilidad para explotar la vulnerabilidad, el número de servicios afectados y el hecho de que el ataque no deja rastros en los registros, este es uno de los fallos más graves que se hayan visto en SSL. Un verdadero caramelo para los black hat hackers. Por nuestro bien, más nos vale que este fallo no lo haya descubierto nadie antes.

> ¿Cuándo estará arreglado?

La corrección en OpenSSL ya está lista, y varias distribuciones de Linux tienen los paquetes listos para actualizar. La versión con el fallo corregido es OpenSSL 1.0.1g. Las versiones vulnerables van desde la 1.0.1 hasta la 1.0.1f (versiones anteriores no tenían Heartbeat implementado).

Servicios como HerokuAmazon Web Services o Lastpass han anunciado la corrección del error en sus servidores. Podéis probar qué servidores son vulnerables con un simple test disponible en la web.

Más información | Existential type crysis | Heartbleed | Corrección del fallo en Git | OpenSSL Advisory

Fuente | Genbeta

Complete Internet Repair es un programa gratuíto, de muy poco peso y que además es totalmente portable.

Según evoluciona la web y nuestra forma de vida nos vemos más y más ligados a Internet de modo que tan sólo con una conexión a la red es posible acceder a datos que de ninguna otra forma llevaríamos encima, datos en muchas ocasiones críticos.

Complete Internet Repair nos ayuda con ellas y entre otras cosas es capaz de realizar las siguientes acciones:

– Resetear el protocolo TCP/IP

– Reparar Winsock

– Renovar la conexión a Internet

– Renovar la caché DNS

– Resetear la configuración del Firewall de Windows

– Reparar las conexiones SSL

– Restaurar el archivo hosts

– Reparar los equipos del grupo de trabajo

    El uso de la aplicación es muy sencillo. Basta con ejecutar y seleccionar las acciones a realizar de la lista, de manera individual o todas a la vez. Tras iniciar las operaciones podremos ir leyendo el estado de las mismas mediante en la misma ventana mediante un completo log.

    Puedes descargar Complete Internet Repair  desde la Web del desarrollador >

    Fuente