Heartbleed un año después, ¿quién es responsable de prevenir otro incidente?
Han pasado 12 meses desde que se reveló públicamente un error que daría forma a titulares, investigadores y presentaciones para el próximo año.
Una falla en la biblioteca de software criptográfico OpenSSL, Heartbleed permitió que la información protegida por el cifrado SSL / TLS fuera capturada por cualquier persona en Internet que pudiera leer la memoria de los sistemas protegidos por las versiones vulnerables del software.
Se lanzó una solución el 7 de abril.th 2014, y muchos lo aplicaron de inmediato debido a las ondas en la escala de publicidad que causó Heartbleed. Sin embargo, la falla aparentemente estuvo presente desde el 31 de diciembre.S t 2011, y estaba en el lanzamiento de OpenSSL versión 1.0.1 el 14 de marzoth, 2012.
¿Era realmente tan grave? Bruce Schneier dicho que “catastrófico” es la palabra correcta, diciendo que “en la escala del 1 al 10, esto es un 11”. Desde entonces tuvimos el error Bashbug / Shellshock en septiembre, mientras que POODLE volvió a picar OpenSSL en octubre. El anuncio de correcciones de «alta gravedad» el mes pasado para OpenSSL puso a la industria en un giro antes de que se revelara que las correcciones no eran tan críticas como se esperaba.
Un año después, había dos preguntas que quería que la industria respondiera por mí, y estoy seguro de que no soy el único que me pregunta si es hora de que se asigne más responsabilidad a la reparación del código fuente abierto para que esto no vuelva a suceder. y, de ser así, ¿de quién es la responsabilidad?
Mike Janke, presidente de Silent Circle, estuvo de acuerdo en que debería haber más responsabilidad, ya que si construyes un producto y publicas el código en código abierto, es tu responsabilidad como autor. “Sin embargo, si su código termina siendo utilizado por organizaciones, corporaciones y miles de personas más en su producto, es responsabilidad de todos”, dijo. “Es muy difícil o imposible controlar esto e incluso hacer que se cumpla. Un método sería más fondos para las juntas de revisión de código abierto y las organizaciones sin fines de lucro «.
Del mismo modo, Wim Remes, gerente de servicios estratégicos para EMEA en Rapid7, dijo que Heartbleed fue una llamada de atención, no solo para la comunidad de seguridad, sino para la comunidad de Internet en general «. Nos ayudó una vez más a darnos cuenta de que la red en la que todos confiamos se basa en gran medida en los esfuerzos de los voluntarios ”, dijo. “Si bien iniciativas como la Recompensa por errores de Internet son loables (habiendo pagado más de $ 200,0000 por errores corregidos, lo cual es increíble), no es la primera vez que se ofrece una revisión de código para código fuente abierto crítico como una solución al problema.
«Sin embargo, desafortunadamente, la Iniciativa de recompensas por errores de Internet tiene solo dos patrocinadores hasta la fecha, y es imposible creer que esas sean las únicas dos organizaciones con un interés personal en hacer de Internet un lugar más seguro».
Admitió que no hay una respuesta inmediata a la pregunta de quién tiene la responsabilidad de garantizar que el código que respalda nuestra Internet sea seguro, pero dijo que es una responsabilidad compartida. “Los recursos con acceso a las habilidades adecuadas para hacerlo son limitados”, dijo. «Todos compartimos la responsabilidad de estar atentos, pero Internet no se va a arreglar de la noche a la mañana».
Luis Corrons, director técnico de PandaLabs, dijo que Heartbleed y los errores posteriores no son culpa del código fuente abierto, ya que todo el software tiene agujeros de seguridad y se encontrarán nuevas vulnerabilidades en el futuro. “Uno de los principales problemas con el código fuente abierto es que se usa en una amplia variedad de dispositivos, y es responsabilidad de los fabricantes de esos dispositivos proporcionar una actualización tan pronto como se publique la corrección”, dijo.
Durante un tiempo, los titulares de este sitio web estuvieron dominados por Heartbleed, aunque el número de víctimas denunciadas no fue especialmente alto. Entonces, ¿es cierto que lo peor está por venir de este error, y 12 meses después de la revelación, cuántos quedan sin parchear?
La investigación publicada la semana pasada encontró que el 86 por ciento de los ciudadanos estadounidenses ni siquiera habían oído hablar del error. Gavin Millard, director técnico de Tenable Network Security, dijo: “Una de las principales lecciones aprendidas en 2014 a partir de la aparición de las superbacterias es que las organizaciones que pensaban que tenían una buena comprensión de la seguridad, rápidamente se dieron cuenta de que no tenían idea de lo que se implementaba y dónde y los procesos diseñados para solucionar problemas importantes no pudieron manejar eficazmente una respuesta rápida.
“Otro impacto interesante de Heartbleed es cómo ahora vemos las revelaciones de vulnerabilidades que podrían convertirse en el próximo Heartbleed o Shellshock. Un buen ejemplo es la reciente vulnerabilidad de denegación de servicio OpenSSL que fue embargada durante unos días. Sin noticias de los colaboradores del proyecto, la falta de información se llenó de rumores de problemas masivos de ejecución remota de código. Como ahora sabemos, este error en particular no era más que una tormenta en una taza de té SSL / TLS, pero sirve como un recordatorio de que no debemos dejar que la exageración anule la lógica «.
Le pregunté a Robert Hansen, vicepresidente de WhiteHat Labs, si una lección aprendida es que tenemos que hacer las cosas mejor. Dijo que hay un interés mucho mayor en buscar tecnologías que todos hemos asumido que eran seguras (la auditoría de TrueCrypt fue un gran ejemplo de eso), pero hay innumerables bibliotecas en las que confiamos que no se han examinado cuidadosamente.
“Entonces, si bien la intención es buena, hay una gran cantidad de montañas por delante de nosotros que aún tenemos que escalar”, dijo. “Hacer las cosas bien en primer lugar es un gran objetivo, pero no veo que tenga mucha tracción. No creo que veamos mucha más atención a hacer las cosas bien en primer lugar que antes, sino más bien un ritmo acelerado de soluciones rápidas «.
Cuando se le preguntó con quién sentía que recaía la responsabilidad de arreglar el código abierto, preguntó si le habíamos atribuido la responsabilidad a alguien, ¿qué implica esa responsabilidad? ¿Demandas? ¿Vergüenza pública? ¿Le quitan la licencia de Internet? “Desafortunadamente, hay más preguntas que respuestas cuando se habla de asignar responsabilidades”, dijo.
Investigar publicado ayer por Venafi descubrió que el 84 por ciento de los servidores externos de las organizaciones de Forbes Global 2000 siguen siendo vulnerables debido a que los certificados no se renuevan, y el 67 por ciento de las empresas más rentables de Forbes Global 2000 en el Reino Unido siguen siendo vulnerables a la falla de seguridad y se arriesgan a una violación masiva de seguridad.
Mark Nunnikhoven, científico investigador senior de OpenDNS, dijo que si un atacante roba la clave del certificado (y, por lo tanto, puede leer todo el tráfico cifrado), cualquier organización que no haya rotado sus certificados corre el riesgo de sufrir un robo. el ataque medio.
“Rotar un certificado no es una tarea particularmente difícil ni tendrá un impacto en los usuarios de una organización”, dijo. “La razón por la que la mayoría de las organizaciones no cambian sus certificados es porque creen que la crisis ha terminado y hay alguna otra tarea que requiere la atención de TI. Pero al no hacerlo, ponen a sus usuarios en riesgo innecesariamente. La mayoría de los proveedores de certificados ofrecieron rotación gratuita a la luz de la vulnerabilidad. No hay excusa para no hacer el cambio «.
Entonces, un año después de la revelación pública, solo podemos suponer que la mayoría tomó alguna acción y que algunos servidores aún no se han actualizado. Mark James, especialista en seguridad de ESET, dijo que no es suficiente tomar alguna acción para proteger los servidores internos, sino que lo parchea o no.
«Debe verificar todo su hardware para ver si está utilizando una versión afectada de OpenSSL y, si es así, debe ser parcheado, incluso si se considera un servidor sin importancia o no», dijo. “Las malas prácticas de TI son las que hicieron que este tipo de ataques tuvieran éxito años después de haber sido detectados y parcheados. Sería posible que los atacantes utilizaran todos y cada uno de los medios para explotar sus sistemas, así que no se lo facilite «.
Sospecho que los principales errores de 2014 no serán el final de la historia, y es probable que algo esté acechando ahora en los cables esperando sorprendernos. El problema no estará en la falla, el problema estará en la respuesta y una industria proactiva mitigará mejor el problema.