Sobre Heartbleed, sin duda uno de los fallos de seguridad más importantes descubiertos en la historia de internet, ya han corrido ríos de bits, y en cualquier caso, deberíais buscar información en páginas de referencia en seguridad, no en la mía. La seguridad no es tema para especulaciones o para opiniones ligeras o no expertas. Sin embargo, el análisis de la cuestión sí puede dar para algunas conclusiones interesantes, sobre todo sobre la naturaleza de la red y de las actividades que desarrollamos en ella.
Hablamos de una vulnerabilidad descubierta en la capa de cifrado y autenticidad de OpenSSL, un desarrollo de código abierto instalado en unos cuatro millones de servidores, de los cuales un cierto porcentaje utiliza la versión afectada. En la gestión de conexiones cifradas o seguras existe un procedimiento, el heartbeat, que el servidor utiliza para verificar que la conexión debe mantenerse abierta tras haber llevado a cabo el intercambio de claves o handshake. Simplemente, una manera de evitar el cierre de esa conexión y la necesidad de volver a llevar a cabo el proceso de negociación de claves.
El problema surge cuando un error, aparentemente espontáneo, en el código que especifica cómo se desarrolla ese heartbeat, permite que un atacante conocedor del mismo pueda acceder a 64kB de la memoria del servidor, lo que permite que a base de sucesivas llamadas y sin dejar rastro alguno, alguien pueda acceder a muchísima información de la memoria de un servidor en pedacitos de 64kB. En esa memoria puede haber absolutamente de todo: cuentas de usuarios con sus contraseñas, claves privadas de los certificados digitales de los servidores… cualquier cosa, dado que todo pasa en algún momento por la memoria del servidor. Grave no, gravísimo, si pensamos que se trata de un fallo que lleva ahí mucho tiempo (la vulnerabilidad existe desde el 31 de diciembre de 2011, y el uso del código afectado se extendió a partir de la release de la versión 1.0.1 de OpenSSL, el 14 de marzo de 2012), y que afecta a servicios que utilizamos todos. Además de su posible uso por delincuentes, que aunque posible, no parece especialmente extendido, es muy posible que estemos hablando de vulnerabilidades que hayan sido utilizadas de manera sistemática por agencias de seguridad con el fin de acceder a información cifrada, en línea con algunas de las cuestiones reveladas por Edward Snowden con respecto a la capacidad de la NSA para penetrar servidores cifrados.
Aparte de recomendar que antes de llevar a cabo cualquier transacción te asegures, con alguno de los muchos tests que han sido ya desarrollados, de que el servidor en el que pretendes llevarla a cabo ha sido objeto de la correspondiente actualización que evite ese peligro, y de que estés atento a las recomendaciones de cambio de contraseña de los servicios que uses habitualmente (posiblemente no sea una mala idea empezar a utilizar alguna de esas aplicaciones de gestión automatizada de contraseñas), mi reflexión, sin embargo, va un poco más allá, y es sobre la naturaleza de esta red que tanto utilizamos.
Sin duda, la red está sujeta a vulnerabilidades, peligros y problemas de diversos tipos. Todo lo que hacemos en nuestra vida, desde caminar por la calle hasta bebernos una copa, está sujeto a vulnerabilidades, peligros y problemas de diversos tipos. En el caso de la red, además, estamos hablando de cuestiones de indudable complejidad, que se apoyan en tecnologías desarrolladas por infinidad de personas, en muy distintos tipos de regímenes diferentes. Hay tecnologías que fueron, en su momento, desarrolladas por empresas. Otras muchas, sin duda mayoritarias, lo fueron por programadores, a veces solos, a veces en grupos, a veces simplemente voluntarios, que contribuyeron con funciones que, a partir de ese momento, fueron siendo adoptadas en función de su utilidad. Una gran parte de las piezas sobre las que se asienta el uso cotidiano que hoy hacemos de la red provienen de ese tipo de orígenes.
Generalmente, asumimos que los fallos en el código son tanto más aparentes y fáciles de corregir cuanto más abierto es este, cuantos más ojos están en disposición de examinarlo. En este caso, hablamos de un fallo que nadie miró, o que quienes lo descubrieron, prefirieron mantenerlo en secreto, a modo de «llave maestra» que les permitía acceder a sitios de manera irregular. El equivalente en el mundo offline podría ser cuando, por ejemplo, se revela de repente que un componente utilizado en la cadena alimentaria ha podido estar generando problemas de salud para quienes lo ingerían: posiblemente alguien lo intuía, tal vez algunos lo han ocultado para así ganar más dinero, y algo que utilizábamos con toda naturalidad nos ha podido estar perjudicando. Pero con toda su gravedad… es algo que ocurre con relativa frecuencia.
La red no es tan distinta del resto de las herramientas que utilizamos los humanos. Simplemente, basa su enorme éxito en el hecho de ser abierta, de que cualquiera puede desarrollar código para plantear utilidades y funciones sobre esa plataforma, y que eso la dota de un dinamismo y una adaptabilidad brutal, que ha permitido que llegue a ser lo que hoy es. Posiblemente, deberíamos replantearnos hasta qué punto retribuimos y cómo a todas esas personas que desarrollan esas funciones que posteriormente terminamos utilizando todos, y que simplemente decidieron no darle un desarrollo comercial. Ese procedimiento, el desarrollo constante de piezas por actores de todo tipo, es susceptible de tener fallos. Esos fallos pueden ser más o menos graves, en ocasiones llegan a parecer de alguna manera enmiendas a la totalidad, pero no inhabilitan lo principal: que esa característica de la red, el estar construida a retales por infinidad de personas con todo tipo de motivaciones y objetivos, es precisamente donde radica su principal fortaleza.
Heartbleed no es la primera vulnerabilidad seria que se descubre, ni será la última. En la red siempre tendremos la impresión de que muchas de las cosas que utilizamos y damos por sentadas están sujetas con palillos pinchados en un corcho y con alambres hechos con clips retorcidos. Tras la revelación de la vulnerabilidad, toca examinar nuestros procedimientos, revisar hasta qué punto podemos haber sido afectados, y aprovechar para replantearnos algunas de nuestras prácticas comunes buscando reforzar su seguridad. Pero no dejemos que el tremendismo nos oculte la gran verdad: la red tiene peligros y problemas exactamente igual que lo tienen todos los sistemas y herramientas desarrollados por el ser humano. Lo que tenemos que seguir haciendo es trabajar con ellos, descubrirlos, aislar y responsabilizar a quienes los conocían y explotaban pero no los revelaron, y pensar que sobre esa característica de la red, su caos y su desorganización, se edifica una gran parte de su grandeza.
(This post is also available in English in my Medium page, “A few conclusions about Heartbleed«)
> en dos de cada tres servidores
El bug es muy grave, pero esos datos son erróneos y puro sensacionalismo iniciado por heartbleed.com:
https://twitter.com/gallir/status/453926366896218113
https://twitter.com/gallir/status/453927393032679424
http://www.meneame.net/story/antiguo-director-seguridad-microsoft-detras-heartbleed-com
http://www.meneame.net/c/14555192
#001: Gracias por el apunte, Ricardo. Corrijo…
Como informático confirmo que a lo más que podemos llegar a afirmar los técnicos, es que una aplicación ha funcionado correctamente en las pruebas que se han hecho. Por tanto, si las pruebas han sido concienzudas y sistemáticas, la aplicación es «segura», lo que no quiere decir que vaya a funcinar correctamente siempre, bien porque las pruebas no hayan sido completas, algo muy habitual, pues cuesta más probar una aplicación, que construirla desde cero, por lo que sólo las aplicaciones de alto riesgo se prueban exahustivamente, o porque no se ha tenido en cuenta algún factor, y por tanto no se ha probado, lo que parece que ha pasado en esta ocasión.
Esta incertidumbre existe inevitablemente siempre, se puede minimizar pero no hacer desaparecer y el riesgo de catástrofe es mayor,, a medida que cedemos máas control daa procedimientos digitales. Hoy sistemas totalmente vitales estan controlados automáticamente de las grandes redes de suministro eléctrico, (apagón de Nueva York), a centrales nucleares, (Chernobil) y no nos queda más remedio que cicir con ese umbral de incertidumbre.
Lo que es nuevo y preocupante, es que se daba por supuesto, que el Software Libre era más seguro, porque «millones de ojos» controlaban su calidad, pues parece ser que tampoco.
Totalmente de acuerdo, Enrique… Es parte de la naturaleza del medio afectado por este bug que la noticia se propaga tan rápidamente y con tanta ferocidad… Lo que yo encuentro un poco preocupante es que la empresa de testing Codenomicon nos cuenta que tardaron 2 años en encontrar el error por la enorme cantidad de trabajo manual que implica testear (según este artículo )… Con lo cual imagino que no han terminado de testear las demás versiones o programas parecidos todavía…
Asi que el Open Source también se presta a que millones descubran una vulnerabilidad y la usen para sus propios fines.
En fin, el único servidor seguro es aquel apagado, congelado bajo 30 metros de hielo, en un lugar no marcado con GPS de la Antártida y sin enchufe
#004 Noelle Acheson
yo encuentro un poco preocupante es que la empresa de testing Codenomicon nos cuenta que tardaron 2 años en encontrar el error por la enorme cantidad de trabajo manual que implica testear
Salvo que sean unos «crack», casi con toda seguridad que el testeo consiste en permitir utilizar los programas y si funciona correctamente, es que están bien. Si alguien encuentra un resquicio, donde copiar la memoria RAM del procesador y apropiarse de 64 kb de información, como eso no provoca errores en el funcionamiento del programa, sólo la casualidad, probablemente buscando el motivo de otro error, detecta la fuga de información.
Por supuesto que como haya sido en la realidad la detección del error, lo desconozco y a lo mejor lo han hecho con en un test específico, pero muy probablemente es como lo cuento, porque te puede asombrar o no, es lo habitual.
Yo creo que la seguridad se irá complicando cada vez más porque seguimos añadiendo capas de software unas sobre otras y añadiendo lineas de código a todas las aplicaciones y la seguridad es tan fuerte como lo sea el eslabón más débil.
Un sistema que está conectado a Internet tiene demasiados puntos que pueden convertirse en puntos de entrada si no están bien programados, y no existe ninguna metodología de prueba de software que permita descartar totalmente la presencia de errores.
Tampoco existe una especial sensibilidad por estos temas en las personas que tienen el dinero, las responsabilidades, o la capacidad de tomar las decisiones, pero que no tienen ni idea de informática.
Yo creo que la mejor herramienta para encontrar fallos de seguridad en un sistema es incentivar a los hackers para que obtengan beneficios importantes con un ataque.
#006 Felix Maocho
Interesante, Felix, y también tranquilizador en que ese largo periodo sea más o menos normal. No lo sabía, gracias por ilustrarme! Estoy de acuerdo con lo que dices en #003, que la vulnerabilidad lamentablemente siempre va a estar allí. Quizás con este susto se puede desarrollar tests más eficientes o más completos, o tener más gente testeando? Crowdsourcing, quizás?
#003
Es que lo de «el software libre es mas seguro» es una falacia. El software libre tiene la ventaja de que en el momento en que se encuentre un fallo no sea necesario esperar a que el fabricante lo solucione. Tambien tiene la ventaja de que es mas facil de detectar si realiza alguna accion «no documentada», siempre que se revise el codigo.
En cambio leemos tonterias como «el metodo de encriptacion xxxxx es seguro porque es libre». ¿Quieren decir que si al mismo metodo le ponemos la marca (C)Microsoft (por poner alguna) deja de serlo inmediatamente? Un algoritmo de encriptacion puede ser robusto o puede no serlo, pero no depende de si el codigo es abierto o no.
#003
Es que lo de “el software libre es mas seguro” es una falacia. El software libre tiene la ventaja de que en el momento en que se encuentre un fallo no sea necesario esperar a que el fabricante lo solucione. Tambien tiene la ventaja de que es mas facil de detectar si realiza alguna accion “no documentada”, siempre que se revise el codigo.
En efecto, lo has explicado muy bien, por eso es más seguro ;-)
Vale, ha sido una cagada, y ha sido importante (hasta que actualizas), pero conviene poner las cosas en perspectiva. Casi todos los PCs domésticos conectados a Internet usan Windows con su configuración por defecto, que es insegura, básicamente porque MS hace una cosa tan tonta como poner al usuario por defecto en el grupo Administradores.
Y no, los nuevos permisos del Vista y posteriores (me refiero a UAC) no solucionan el problema porque a su vez su configuración por defecto también es insegura (en el propio Vista no lo he comprobado, pero sí en Windows 7 y 8). ¿Solución? Tan sencilla como quitar al usuario del grupo Administradores, pero la gran mayoría de los usuarios domésticos ni saben que eso existe.
¿Recuerdan Windows 95? Ahí ni siquiera había permisos. En el mundo Windows, por lo menos a nivel doméstico, apenas se ha avanzado desde entonces. Los fabricantes de antivirus, una categoría que debería ser innecesaria (lo es en otros SOs), siguen haciendo su agosto.
#009 acerswap
Me parece que no ha fallado el algoritmo de encriptación, sino la forma de utilizarlo.
Cualquier sistema de encriptación tiene (al menos) un punto débil, más pronto o más tarde, en un momento u otro, hay que desencriptar la información para poderla utilizar. Si en ese momento se captura la información, la robustez del sistema de encriptación es irrelevante.
Es lo que yo entiendo que ha pasado aquí, teniendo en cuenta lo poco que de ello cuenta eDans, (no he investigado más). Parece como si se procediera a desenciptar un «cluster» o unidad mínima de información de un disco duro, (los 64kb del que habla Dans)m que contiene la información a tratar y algo que tiene delate y detras que pued ser cualquiier otra información, en general serán registro de la base de datos con información similar a la que se va a utilizar, (o con suerte, espacio no utilizado), que estarán por delante y por detrás del registro a utilizar hasta agotar los 64kb, (más o menos un folio de texto), y se llevaba a la memoria RAM del servidor para proceder a procesarla. Ese cluster desencriptado era el que potencialmente parece ser que se podía copiar dde la RAM y trasladarlo a un tercer ordenador.
Bastaba entonces ir recogiendo esas paginas de texto, y con mucha paciencia, (y alguna herramienta informática adecuada) ir ordenando y montando al menos partes de la base de datos y posteriormente interpretar el sentido de esos datos. Al menos teóricamente es posible hacerlo.
#010
No es asi. El que un software tenga codigo abierto no conlleva que alguien lo revise, ni que lo corrija. Proyectos abandonados no faltan. Tampoco que sea mejor que sus equivalentes propietarios. No es mas seguro por si mismo, por ser de codigo abierto, solo por la calidad del soporte que reciba. Lo es potencialmente, y hablando de seguridad como en este caso es lo mismo que nada.
Hola, Como dicen mas arriba, el problema es un tradicional y vulgar «buffer overflow» (un mensaje enviado por un atacante dice «te mando 64k de info, devuélvemelo para mantener el link» y el atacante manda 1k, con lo cual accede a los 63k que vienen después, por error de programación.
Es grave? Bueno, es a «suerte y verdad» tal vez acceda algo útil, tal vez no. El riesgo es la exposición de información no controlada en el servidor. El acceso a passwords? Probablemente NO, los passwords no son conocidos por la mayoría de los servidores que están programados como la gente, sino que conservan un hash del password. Las funciones de hash hacen difícil la vuelta atrás en el acceso para recuperar el password original y hay que buscar un sinónimo que produzca el mismo hash.
En cuanto a las claves privadas de un certificado…depende mucho de como esté estructurada la memoria y hablamos siempre de la clave privada del servidor y no la del cliente. El riesgo de exposición es posible pero relativamente bajo. En dispositivos de poca memoria el problema es mas simpático: el firmware es difícil de poner al día y la poca memoria real torna mas interesante el acceso a partes de la memoria útiles.
Por el otro lado, estamos llenos de clientes (androide, mac, que tiene una versión vieja de openssl, etc.)y quisiera saber cuantos lo han puesto al día.
Lo mas importante es que esta es UNA de las fallas de open ssl y que cada pocos meses hay que patchearlo para mantener los problemas controlados, solo que esta falla fue bien usada por una empresa para hacerse nombre.
Esto no es peor que otros buffers overflows anteriores, solo que fue muy bien «comercializado» para hacerse una reputación.
Me preocupa un poco la corrida de mucha gente a cancelar y solicitar la inútil y cara emisión de nuevos certificados cliente: Bruce Schneier señalaba hoy esta corrida masiva que hará largas las CRL (listas de certificados revocados) enlenteciendo potencialmente la validación de certificados.
Que aplicaciones de gestión automatizada de contraseñas son recomendados por uds??
#001 Ricardo Galli, cabe decir que los servidores de Microsoft (junto con todos sus servicios Outlook.com, OneDrive, MSN, etc,..) no se ve afectado por este gravísimo bug de seguridad, puesto que Microsoft usa Microsoft’s SChannel, una tecología de mayor calidad.
La falacia de que el software libre es «más seguro» no hay por donde cogerla en el momento en que Android es el sistema con mayores agujeros de seguridad y malware, frente a iOS y Windows Phone.
Y por último, resulta bastante infantil y penoso el link que pones diciendo que «hay un directivo de Microsoft detrás». Claro, la mano oscura de Microsoft….. Si es Google la que está detrás es santo de devoción, si hay un directivo de Microsoft entonces son «malos».
Por favor, subid un poco el nivel de argumentación la próxima vez que roza el infantilismo.
#011 Krigan, deja de decir tonterías hombre. La UAC soluciona todos esos problemas que dices. Así que deja de hablar de Windows 95, actualiza tus datos, y asume la realidad.
Desde el año 2006 por defecto, y gracias a la UAC los usuarios aunque no estén en modo administrador necesitan autorizar cada cambio que se hace a un nivel que conlleve peligros de seguridad en el sistema.
#11 Mac OSX tiene un antivirus instalado de fábrica por Apple (lo llaman software de seguridad). Microsoft no ha podido hacer eso hasta Windows 8 porque si no se le tiraban al cuello los payasos del antimonopolio (esos mismos que protestan cuando pone un navegador web y un reproductor de serie en Windows…¿te suena lo que hablo, no?).
En Windows 8 no hace falta instalar ningún antivirus porque el sistema ya trae un «software de seguridad».
Al que sí le hace falta instalar antivirus, de hecho muchísimos smarphones lo traen de serie, es a Android. El sistema móvl que presenta mayores agujeros de seguridad que es el objetivo de la mayoría del malware y virus para móvil.
Por cierto…¿tú eras ese tan «moderno» que sólo usabas un Tablet con Android, no??
¿Qué antivirus tienes instalado? ¿Cómo llevas el tema del LAG y la inestabilidad que aparecen en Android al poco de usarlo?
Saludos.
Ahora dijeron que el NSA tambien utilizo este virus para espiar las paginas de internet de miles de personas…la preguta ahora es? Con que fin y se puede confiar en el personal del NSA que no esten copiando nuestros numeros de tarjetas de credito, direccion etc.?
Pedro:
Como ya dije, la configuración por defecto de UAC es insegura:
http://windows.microsoft.com/en-us/windows/what-are-user-account-control-settings
Como puedes ver, el nivel por defecto es el segundo. Nótese que esta informacion es aplicable tanto a Windows 7 como a 8.1 (también a Win8, aunque no aparezca en el listado de MS).
En su día leí la sentencia del «caso del IE», ratificada por unanimidad por el tribunal de apelación, y en ningún momento se condena a MS por incluir el navegador en el SO, sino por hacer cosas tales como acordar con otras empresas que sus webs se vieran mal en Netscape Navigator.
En ninguno de los 2 móviles Android que he tenido venía ningún antivirus, tampoco en ninguno de los 2 tablets Android que he comprado (uno para regalo). Ni en los Linux de escritorio (Ubuntu, etc) ni en Android he usado nunca antivirus, cuando el SO hace las cosas bien el antivirus es completamente innecesario.
Tampoco he sufrido ninguna inestabilidad. El único SO que he visto que «se pudre» con el paso del tiempo, como si fuera un yogur caducado, es precisamente Windows.
¿Se ha confirmado ya sí Pedro es trabajador o accionista de Microsoft? Lo digo porque si no lo es, Microsoft está perdiendo aquí commmunity manager talibán de los que se ven pocos hoy día… Vale su peso en oro.