¿Cómo usar Internet mientras se repara Heartbleed?

Hay muchos sitios web que actualmente no son vulnerables, pero no tengo idea si fueron vulnerables hace unos días.

Por ejemplo:

• twitter.com: No vulnerable en este momento, pero el certificado es del Mié Mar 05 00:00:00 UTC 2014
• google.com: no vulnerable en este momento, pero el certificado es del miércoles 12 de marzo 09:53:40 UTC 2014
• bankofamerica.com: No vulnerable en este momento, pero el certificado es del jueves 05 de diciembre 00:00:00 UTC 2013

¿Qué debo hacer? ¿No usar estos hasta que vuelvan a emitir? ¿Cómo sé que vuelven a emitir el certificado con claves nuevas? Parece que ni siquiera debería iniciar sesión en estos sitios para cambiar mi contraseña porque no hay forma de saber que son el sitio web real.

Actualizaciones 2014-04-11

Cloudflare estableció un desafío para verificar que la extracción de clave privada fuera posible. Se ha realizado con alrededor de 100 mil solicitudes, y verifica los temores. Ya no es teórico, sino probado . Puedes ir aquí para leer sobre esto.

Además, Bloomberg ha informado que la NSA ha sabido sobre esta hazaña durante al menos dos años . Esto tiene sentido ya que la NSA tiene los recursos para contratar analistas cuyo único trabajo es encontrar exploits en software como este. Ahora que sabemos que el gobierno de EE. UU. Lo ha estado explotando durante tanto tiempo, la probabilidad de que otros estados lo hayan conocido y explotado es significativa.

TL; DR Esté atento a los anuncios de las organizaciones con respecto al estado de sus sistemas, cambie TODAS sus contraseñas y esté atento a fraudes / actividades sospechosas en cuentas importantes como bancos u otros sistemas financieros.

Para entender por qué la situación es tan peligrosa, primero tenemos que entender qué hace realmente este ataque. CVE-2014-0160, también conocido como Heartbleed, es un error de sobrecarga del búfer que permite a un atacante obtener hasta 64 kB de memoria de un servidor que ejecuta una versión vulnerable de OpenSSL.

Eso suena muy mal. Cómo funciona en la práctica

Tienes razón, es una falla grave, pero volveremos a eso un poco más tarde. Ahora hablemos de por qué funciona el exploit. La Seguridad de la capa de transporte (TLS) se utiliza para proteger la información de muchas aplicaciones, incluido HTTP ( HTTPS ) o para proteger SMTPsi está habilitado por ejemplo. En RFC 5246, que establece los estándares para TLS, hay una función conocida como latido del corazón. El cliente y el servidor envían algunos datos de un lado a otro para mantener viva la conexión y poder usarla más tarde. Ahora, en la práctica, el cliente enviará algunos datos y el servidor simplemente los devolverá, y todo es genial. Sin embargo, en las versiones afectadas de OpenSSL no hay verificación para ver si el cliente realmente envió la cantidad de datos que dijo que hizo. Entonces, si lo envío 1 byte y le digo al servidor que realmente lo envié 64 kB, entonces felizmente me devolverá 64 kB. ¿De dónde vienen esos otros bytes? Esa es la clave del problema allí mismo. OpenSSL le enviará de vuelta 64 kB - 1 bytes de memoria a los que el proceso tiene acceso y que originalmente no envió, dependiendo de dónde esté almacenado su 1 byte.material de clave privada¹ e información que el servidor está descifrando para usar. Ejemplos de esto serían: contraseñas, información de tarjeta de crédito y / o PIN .

OKAY. ¿Qué significa eso para la seguridad de la información? Si comprende cómo funciona la criptografía asimétrica, entonces ya sabe que esto es grave ya que la divulgación no hace que el cifrado sea más que ofuscación. Esto significa que a pesar de que los servidores pueden estar parcheados y ya no pierden memoria, las sesiones aún pueden ser inseguras. Es posible que esto haya sido explotado antes de que se conociera públicamente o mientras se realizaba la aplicación de parches, pero actualmente no hay ningún método comprobado que muestre que se haya producido un ataque. Es posible que las reglas para los IDS estén disponibles, pero a partir de ahora ese no es el caso. Se han publicado las reglas de IDS . Eso en sí mismo es extremadamente peligroso, porque los operadores no saben si sus claves siguen siendo seguras.

Nos vemos obligados a suponer que las claves se han filtrado, lo que significa que es posible que todo lo que envíe a través del cable pueda ser descifrado por un tercero. La única forma de mitigar esto es regenerando claves y volviendo a emitir nuevos certificados mientras se revocan los antiguos. Desafortunadamente, esto lleva tiempo ya que las CA sin duda están siendo inundadas con estas solicitudes en este momento. Aún así, esto deja la posibilidad de un ataque de hombre en el medio u otras oportunidades de phishing.

¿Cuándo será seguro? Saber cuándo será seguro es una pregunta difícil. Algunas cosas que sugeriría observar son anuncios públicos que explican que el error se ha parcheado en sus entornos o que nunca fueron vulnerables, porque nunca usaron las versiones afectadas. Cuando anunciaron que habían actualizado a una nueva versión de OpenSSL, me aseguraré de que estén utilizando un nuevo certificado firmado después de la fecha de lanzamiento público del exploit que fue 2014-04-07.

** Tenga en cuenta que el tráfico previamente registrado puede descifrarse si la clave privada se filtró más tarde.

¿Qué puedo hacer como usuario para protegerme?

Para los próximos días, si puede evitar el uso de sitios críticos como la banca en línea o el acceso a la historia clínica en línea, le sugiero que lo haga. Si debe hacerlo, comprenda que su sesión está potencialmente en riesgo y esté preparado para aceptar las consecuencias de eso. Además, después de que las organizaciones anuncian que ya no son vulnerables, debe cambiar su contraseña ; Usar un administrador de contraseñas puede ayudar. También debe prepararse para cambiar o controlar cualquier otra información que haya utilizado, como datos bancarios o números de tarjetas de crédito.

Aviso especial para activistas.

Cualquier cosa que use OpenSSL puede verse afectada, incluido Tor . Es posible que los gobiernos hayan podido usar esta falla desde su inclusión en los lanzamientos de OpenSSL de hace más de dos años, ya que tendrían los vastos recursos necesarios para buscar exploits como este, y como tal, debe estar preparado para que la información pueda Ya no ser privado.

** Tenga en cuenta que el tráfico previamente registrado puede descifrarse si la clave privada se filtró más adelante a menos que se haya implementado la seguridad de reenvío perfecto (PFS).

¹- Ha habido afirmaciones de que es probable que las claves privadas no estén en la memoria, pero al mismo tiempo ha habido afirmaciones de extracción exitosa de claves. En este punto, no está claro qué lado es correcto.

El riesgo que representa esta vulnerabilidad está siendo sobrevalorado. Digo esto porque hay CERO evidencia de que esta vulnerabilidad era conocida o explotada antes de su publicación por los investigadores hace 2 días.

Permítanme ser claro, es urgente que los sitios web vulnerables, particularmente aquellos que realizan transacciones de datos confidenciales a través de Internet, sean parcheados. Es igualmente urgente que las firmas para el ataque se carguen en IDS y herramientas de protección contra malware. Dentro de TI, debemos responder a esta vulnerabilidad con la máxima prioridad.

Dicho esto, no creo que el nivel de riesgo asociado con esta vulnerabilidad por parte de la prensa pública esté justificado.

¿Qué deben hacer los individuos para protegerse? No use sitios que ejecutan versiones vulnerables de OpenSSL.

Hasta y a menos que haya evidencia de que esta vulnerabilidad fue explotada, cualquier otra acción no tiene sentido y está motivada por nada más que FUD. ¿No estás de acuerdo? Considere las muchas vulnerabilidades publicadas cada mes o trimestre que permiten la ejecución de código arbitrario . Aquellos que otorgan al atacante privilegios de nivel raíz o del sistema o donde el atacante puede obtenerlos posteriormente mediante la escalada de privilegios presentan tanto o más riesgo para la seguridad de todos los datos manejados por los sistemas vulnerables como presenta esta vulnerabilidad.

En muchos casos, estas vulnerabilidades son descubiertas por el proveedor de software o los investigadores que informan al proveedor. El proveedor produce un parche y lo lanza al mercado sin publicar los detalles de vulnerabilidad. En algunos casos, los detalles se publican y la comunidad de seguridad publica los exploits para usarlos en las herramientas de prueba. No reaccionamos a estas vulnerabilidades diciendo "¡TODOS nuestros secretos PUEDEN haber sido expuestos!"

Si hay evidencia de explotación, debemos reaccionar a eso apropiadamente. Veo un gran riesgo en la reacción exagerada de los investigadores que anunciaron esta vulnerabilidad y en la prensa que amplificaron la charla suelta de los investigadores. Están llorando lobo.

- El viejo

No todos los sitios web usan bibliotecas OpenSSL para HTTPS (también hay GnuTLS y PolarSSL, por ejemplo), y no todas las versiones de OpenSSL eran vulnerables (las versiones anteriores no lo eran). Esto significa que existe una buena posibilidad de que los sitios web que mencionó no hayan cambiado los certificados porque no es necesario. Solo mirar las fechas en que se emitieron los certificados no le dice lo suficiente.

Hay una serie de herramientas y sitios que pueden ayudarlo a verificar si un sitio web es vulnerable, por ejemplo: - http://filippo.io/Heartbleed - https://gist.github.com/mitsuhiko/10130454 - https: / /www.ssllabs.com/ssltest/

Desafortunadamente, como ya dijiste, esto no te dice si lo fueron. Me temo que la cuestión clave aquí es la confianza: no hay forma objetiva de verificar qué bibliotecas SSL usan y usan sin información privilegiada. Tienes que esperar que hicieron lo que tienen que hacer (porque es lo correcto, o incluso porque temen la humillación pública) y si lo hicieron, solo puedes esperar que sean abiertos al respecto.

Por supuesto, siempre puede preguntar a estos sitios web si se vieron afectados, he visto varios sitios web que emiten declaraciones públicas sobre esto. Preguntar públicamente a través de las redes sociales como Twitter o Facebook a menudo funciona.

Entonces, el mejor consejo que puedo dar es un consejo general: tenga cuidado con lo que deja en Internet y en qué sitios web confía con su información personal.

Con respecto a las claves privadas expuestas, vale la pena agregar que, si bien alguien puede descifrar los datos en una sesión cifrada, porque ahora tiene la clave privada, aún tendrá que establecerse como el hombre en el medio de la sesión . No cualquiera en Internet puede hacer esto.

Tengo entendido que aún necesitarán interceptar el tráfico ya sea en su LAN local y suplantación de ARP o ser capaces de secuestrar / redirigir el tráfico mediante la publicidad de rutas falsas a enrutadores de Internet. Este tipo de ataques siempre han sido posibles incluso sin esta vulnerabilidad.

Puede ingresar la URL de un sitio en LastPass Heartbleed Checker y le dirá si el sitio era o sigue siendo vulnerable y cuándo se actualizó su certificado.

También hay una extensión de Chrome llamada Chromebleed que te avisará si estás visitando un sitio afectado por Heartbleed.

Mashable.com tiene una lista de sitios conocidos, si se vieron afectados y si debe cambiar su contraseña. Curiosamente, ninguno de los sitios en la lista de bancos y corredores se vio afectado.

También visitaría el siguiente sitio:

https://www.ivpn.net/blog/heartbleed-passwords-change

Tienen una lista de sitios populares que se han visto afectados y cuándo y dónde debe cambiar sus contraseñas.

En general, diría que no dejes que la paranoia te afecte. Siendo realistas, solo haber podido descifrar el tráfico y obtener su contraseña no es lo mismo que haberlo hecho realmente.

Si usa autenticación de dos factores (y debería hacerlo) en sitios como Twitter, Facebook, Gmail y su banca, entonces no debería estar demasiado preocupado, e incluso si no lo hace, probablemente esté bien como está.

Si siente la necesidad de cambiar todas sus contraseñas, tendrá que seguir adelante y hacerlo donde sienta que lo necesita. Eso es todo lo que hay que hacer, de verdad.