Primero , antes de enloquecer, asegúrese de comprender si esta vulnerabilidad realmente se aplica a usted o no. Si tiene un servidor, pero en realidad nunca ha tenido ninguna aplicación que use TLS, entonces esto no es una cuestión de alta prioridad para que lo arregle. Si, por otro lado, alguna vez ha tenido aplicaciones habilitadas para TLS, entonces le espera un regalo. Sigue leyendo:
¿Qué es exactamente CVE-2014-0160, también conocido como "Heartbleed"?
Es un gran desastre, eso es lo que es. En resumen, se descubrió una vulnerabilidad explotable de forma remota en las versiones de OpenSSL 1.0.1 a 1.0.1f a través de las cuales un atacante puede leer ciertas partes de la memoria del sistema. Esas partes son las que contienen datos confidenciales, como claves privadas, claves previamente compartidas, contraseñas y datos corporativos de alto valor, entre otras cosas.
El error fue descubierto independientemente por Neel Mehta de Google Security (21 de marzo de 2014) y la firma finlandesa de pruebas de seguridad de TI Codenomicon (2 de abril de 2014).
¿Cual es la causa?
Bueno, código errante en OpenSSL. Aquí está el commit que introdujo la vulnerabilidad, y aquí está el commit que solucionó la vulnerabilidad. El error apareció en diciembre de 2011 y fue parcheado hoy, 7 de abril de 2014.
El error también puede verse como un síntoma de un problema mayor. Los dos problemas relacionados son (1) qué proceso existen para garantizar que el código errante no se introduzca en una base de código, y (2) por qué los protocolos y extensiones son tan complejos y difíciles de probar. El ítem (1) es un problema de gobernanza y proceso con OpenSSL y muchos otros proyectos. Muchos desarrolladores simplemente se resisten a prácticas tales como revisiones de código, análisis y escaneo. El ítem (2) se está discutiendo en el TLS WG del IETF. Ver Heartbleed / complejidad del protocolo .
¿Se insertó el código erróneo de forma maliciosa?
No especularé si esto fue realmente un error o posiblemente un poco de código introducido en nombre de un mal actor. Sin embargo, la persona que desarrolló el código para OpenSSL afirma que fue inadvertido. Vea que el hombre que introdujo una falla de seguridad grave de 'Heartbleed' niega haberlo insertado deliberadamente .
¿Qué sistemas operativos y versiones de OpenSSL son vulnerables?
Como se mencionó anteriormente, cualquier sistema operativo que esté usando, o una aplicación que esté vinculada con OpenSSL 1.0.1 a 1.0.1f.
¿Cuáles son los síntomas? ¿Hay algún método para detectar una explotación exitosa?
Esta es la parte que da miedo. Hasta donde sabemos, no hay una forma conocida de detectar si esta vulnerabilidad ha sido explotada o no. Es teóricamente posible que pronto se publiquen firmas IDS que puedan detectar este exploit, pero a partir de este escrito, no están disponibles.
Existe evidencia de que Heartbleed estaba siendo explotado activamente en la naturaleza ya en noviembre de 2013. Vea el EFF's Wild at Heart: ¿Las agencias de inteligencia utilizaron Heartbleed en noviembre de 2013? Y Bloomberg informa que la NSA había armado el exploit poco después de que se introdujera la vulnerabilidad. Ver NSA dijo para explotar Heartbleed Bug para inteligencia durante años . Sin embargo, la Comunidad de Inteligencia de los Estados Unidos niega las afirmaciones de Bloomberg. Ver IC EN EL REGISTRO .
¿Cómo puedo verificar si mi sistema está afectado?
Si mantiene OpenSSL en su sistema, simplemente puede emitir openssl version:
$ openssl version
OpenSSL 1.0.1g 7 Apr 2014
Si la distribución es el mantenimiento de OpenSSL, entonces es probable que no se puede determinar la versión de OpenSSL debido al regreso de parches utilizando opensslcomandos o la información del paquete (por ejemplo, apt-get, dpkg, yumo rpm). El proceso de revisión de parches utilizado por la mayoría de las distribuciones (¿todas?) Solo usa el número de versión base (por ejemplo, "1.0.1e"); y no incluye una versión de seguridad efectiva (por ejemplo, "1.0.1g").
Hay una pregunta abierta sobre Superusuario para determinar la versión de seguridad efectiva para OpenSSL y otros paquetes cuando los paquetes se remontan. Desafortunadamente, no hay respuestas útiles (aparte de consultar el sitio web de la distribución). Consulte ¿ Determinar la versión de seguridad efectiva cuando se enfrenta a Backpatching ?
Como regla general: si alguna vez instaló una de las versiones afectadas y alguna vez ejecutó programas o servicios que se vinculaban con OpenSSL para el soporte TLS, entonces es vulnerable.
¿Dónde puedo encontrar un programa para probar la vulnerabilidad?
A las pocas horas del anuncio de Heartbleed, varias personas en Internet habían publicado aplicaciones web de acceso público que supuestamente podrían usarse para verificar la presencia de esta vulnerabilidad en un servidor. Al momento de escribir este artículo, no he revisado ninguno, por lo que no publicaré más sus aplicaciones. Se pueden encontrar con relativa facilidad con la ayuda de su motor de búsqueda preferido.
¿Cómo se mitiga esta vulnerabilidad?
Actualice a una versión no vulnerable y restablezca o vuelva a proteger los datos vulnerables. Como se señaló en el sitio de Heartbleed , los pasos de respuesta apropiados son en general:
- Parchear sistemas vulnerables.
- Regenerar nuevas claves privadas.
- Envíe una nueva CSR a su CA.
- Obtenga e instale un nuevo certificado firmado.
- Invalidar claves de sesión y cookies
- Restablecer contraseñas y secretos compartidos
- Revocar certificados antiguos.
Para obtener un análisis y una respuesta más detallados, consulte ¿Qué debe hacer un operador de sitio web sobre el exploit Heartbleed OpenSSL? en el intercambio de pila de seguridad.
¿Debería preocuparme que mis claves u otros datos privados se hayan visto comprometidos? ¿De qué otros efectos secundarios debería preocuparme?
Absolutamente. Los administradores de sistemas deben asumir que sus servidores que utilizan versiones vulnerables de OpenSSL están realmente comprometidos y responden en consecuencia.
Poco después de que se revelara la vulnerabilidad, Cloudfare ofreció un desafío para ver si la clave privada de un servidor podía recuperarse en la práctica. El desafío fue ganado independientemente por Fedor Indutny e Ilkka Mattila. Ver el desafío Heartbleed .
¿Dónde puedo encontrar más información?
Enlace de volcado, para aquellos que buscan más detalles:
Se puede encontrar una línea de tiempo bastante detallada de los eventos de divulgación en la línea de tiempo de divulgación de Heartbleed: quién sabía qué y cuándo .
Si es un programador y está interesado en varios trucos de programación, como detectar un ataque Heartbleed a través de la msg_cbdevolución de llamada de OpenSSL , consulte el Aviso de seguridad 2014047 de OpenSSL .
