Muchos ya estarán enterados de esta gran falla de seguridad en OpenSSL, cuyo nombre común es «HeartBleed«.
Hoy ya se encuentra corregida dicha vulnerabilidad en el software, y por parte de los desarrolladores del proyecto, pero esta falla puede seguir teniendo repercusiones negativas (más de las que ya tuvo) en la medida en que los administradores de sistemas no actualicen sus servicios de seguridad.
Cómo nos enteramos de HeartBleed?
Muchos de nosotros nos dimos cuenta de esta vulnerabilidad al estar en contacto con feeds, mailing-lists y redes sociales cuya temática es la seguridad y el hacking ético.
A muchos también nos llegó a nuestras casillas de correo un mail cuyo contenido informaba la falla, y nos remitía a sitios oficiales sobre su explicación técnica, lo cual también nos dio una idea de la magnitud de la gravedad.
Algunos datos técnicos sobre OpenSSL
Heartbleed es un juego de palabras que traducido al castellano sería algo similar a «corazón desangrado«. Es un juego de palabras que hace referencia a la funcionalidad Heartbeat de TLS, cuyo objetivo es refrescar sesiones de SSL/TLS sin necesidad de re-negociar los datos de cifrado y autenticación.
SSL/TLS se utiliza para muchas comunicaciones seguras dentro de Internet. Es una capa de seguridad añadida al stack de protocolos TCP/IP justo debajo de la capa de Aplicación, lo que permite que varias aplicaciones que originalmente enviaban datos en texto plano, ahora pudieran hacerlo de manera cifrada, y autenticada mediante criptografía asimétrica y certificados digitales x509.
Básicamente, https o smtps, o pops, o ftps, son todos protocolos de aplicación que hacen uso de SSL/TLS, y que fueron afectados por esta vulnerabilidad.
Los algoritmos asimétricos que usan estas impelentaciones les permiten autenticarse, o validar su identidad, contra otros nodos de la red. Esta autenticación se basa en que cada nodo disponga de una clave privada que no debe ser comprometida, ya que quien tenga la clave privada de un nodo, podrá «hacerse pasar» por él en cualquier transacción segura.
Datos técnicos de la vulnerabilidad
Una de las funciones escritas en el código fuente de OpenSSL, la función dtls1_process_heartbeat(), cuya definición se encuentra en el archivo fuente ssl/di_both.c del raíz de Openssl, no valida correctamente la longitud de la estructura que administra el registro de conexión de SSL, llamada ssl3_record_st.
Cuando un cliente realiza una solicitud de algún valor, también setea la longitud de la respuesta que espera recibir.
Openssl reserva memoria dinámica para armar la respuesta al cliente, y esa cantidad de memoria se toma de la solicitud efectuada por el cliente, para poder almacenar en ella el dato a entregar.
Si bien esta reserva de memoria puede contener hasta 65535 bytes (64KiB), al ser reservada por el cliente, y el ssl copiar los datos a la respuesta mediante la función memcpy(), no valida el ancho del dato real a entregar.
Esto le da la posibilidad a un cliente de solicitar una cadena corta de información, de pocos bytes, o incluso, de ninguno en una cadena nula, y pedir 64 KiB de información para almacenarlos. Al llevar a cabo esta solicitud, la función dtls1_process_heartbeat() copia 64 KiB de información de la memoria en la respuesta al cliente.
Estos 64 KiB de datos corresponden con información contigua en memoria de la aplicación, que pueden contener datos sensibles, como información de claves privadas de servidores y clientes.
Los atacantes que tuvieron éxito lograron realizar consultas sucesivas al proceso renegociando la conexión, y obtener de esta forma diferentes bloques de datos de la memoria, lo que les permitió obtener las claves privadas de servidores y clientes.
Una buena explicación gráfica podemos encontrarla en esta imagen obtenida de http://xkcd.com/1354
Tiempo de soluciones…
La vulnerabilidad se encuentra resuelta en versiones de OpenSSL posteriores a la 1.0.1g del 7/abril/2014.
Esto nos dice que si disponemos de servidores que utilicen estas bibiliotecas (la mayoría), es más que recomendable actualizar la versión del openssl por medio del gestor de paquetes y actualizaciones de la distribución (apt-get, aptitude, yum, pacman, …) y asegurarnos de que la versión es la que corresponde.
Aquí un ejemplo de actualización en Debian testing «Jessie»:
La versión actual del openssl es:
[die@debian ~]$ openssl version -a
OpenSSL 1.0.1e 11 Feb 2013 (Library: OpenSSL 1.0.1f 6 Jan 2014)
built on: Mon Jan 6 18:46:41 UTC 2014
platform: debian-i386-i686/cmov
options: bn(64,32) rc4(8x,mmx) des(ptr,risc1,16,long) blowfish(idx)
compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -march=i686 -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/usr/lib/ssl"
En esta oportunidad haremos una breve introducción a la criptografía simétrica y asimétrica, y utilizaremos OpenSSL para cifrar archivos simétricamente. Cuántas veces nos ha sido necesario pasarle esos datos privados a alguien por correo electrónico, Leer más…
Hoy les voy a comentar algunos conceptos sobre aleatoriedad de la información y entropía en un generador random en sistemas Linux, particularmente de la entropía, su concepto y usos. Entropía La entropía, también llamada Entropía Leer más…
En este post veremos cómo podemos multiplexar o reutilizar una conexión de SSH contra un servidor para acelerar la autenticación o login de las siguientes conexiones. Este post complementa el contenido del Curso online de Leer más…
