Está usted visitando una publicación en la hemeroteca de CSIRT-CV.
Para acceder al portal y contenido actual, visite https://www.csirtcv.gva.es
10/04/2014
Heartbleed y el caos de seguridad en Internet
Desde que se publicó el bug de Heartbleed ha sido un día duro en Eleven Paths, como en muchas otras compañías de Internet para conseguir tener los sistemas actualizados sin sufrir interrupciones de servicio, para lo que hubo que tensar los procedimientos de emergencia y trabajar muchas horas y con intensidad.
Si no te has enterado aún de qué este fallo, voy a intentar hacerte entender la magnitud del fallo para que tomes tus medidas de seguridad.
¿Dónde está el fallo de HeartBleed?
El fallo se encuentra en una de las implementaciones más populares de SSL, la capa de cifrado y autenticidad que da seguridad a muchos de los protocolos de Internet, como son HTTPs, FTPs, SSTP, o muchos otros. Según Shodan hay más de 5 Millones de servidores que tienen instalado OpenSSL expuesto a Internet aunque solo una parte de ellos tienen alguna versión vulnerable, que como sabéis ya es la 1.0.1.
En concreto, el bug está en la implementación que hace esta capa de cifrado del"latido del corazón" o HeartBeat, que se usa para mantener la sesión SSL activa después del "saludo de manos" o Handshake. El funcionamiento si quieres una explicación detallada, la tienes en el libro de Cifrado de las comunicaciones digitales, pero digamos que cuando un cliente quiere establecer una sesión segura usando SSLcon un servidor, lo primero que hace es negociar una clave de cifrado simétrico con el servidor que les permita enviar toda la información de forma segura.
Para que esa clave de cifrado simétrico se intercambie de forma segura se usa un negociación, llamada HandShake, para lo que se usa el certificado digital y las claves PKI que tiene configuradas el servidor. Es decir, el servidor cuenta con us clave privada y su clave pública para firmar las comunicaciones y realizar procesos de cifrado asimétrico. Como sabéis, la gracia de PKI es que lo que se cifra con la clave pública solo puede ser descifrado con la clave privada. Por eso el servidor envía su clave pública al cliente y este usará la clave pública para cifrar la información que le va a enviar al servidor, lo que garantiza que aunque alguien intercepte la comunicación no va a poder descifrarla si no tiene la clave privada.
Una vez que el cliente ya tiene la clave pública del servidor para cifrar las comunicaciones ya pasa a negociar la clave de cifrado simétrico, usando diferentes posibles esquemas en función de las características que tengan servidor y cliente. Este proceso permitirá al cliente generar una clave simétrica y comunicarse con el servidor de forma segura lo que concluye con que tanto servidor como cliente conocen la clave simétrica de cifrado que se usará en esa sesión sin que nadie haya podido interceptarla.
A partir de ese momento se comenzarán a transmitir los datos del protocolo de aplicación que se esté protegiendo, que será HTTP, Telnet, FTP o los protocolosVPN en la red privada virtual, todo ello cifrado siempre con la clave simétrica negociada.
Como este proceso de saludo es costoso computacionalmente, se creo el "latido del corazón" o HeartBeat, que permite al cliente decirle al servidor "no cierres la sesión y fuerces otro saludo, que sigo trabajando contigo en esta sesión". Para ello en SSLv3se envía una estructura de datos TLS1_HB_REQUEST de 4 bytes en la va un payload de 1 byte que le permite decir qué tamaño tiene el mensaje de HeartBeat, a la que el servidor responde con un mensaje TLS1_HB_RESPONSE que se compone a partir del mensaje original.
Para ampliar esta noticia puede visitar el siguiente enlace.