Heartbleed

La vulnerabilidad Heartbleed CVE-2014-0160 es un grave defecto de implementación en la librería OpenSSL que permite a los atacantes robar datos de la memoria del servidor víctima. El contenido de los datos robados depende de lo que haya en la memoria del servidor. Podría contener potencialmente claves privadas, claves de sesión TLS, nombres de usuario, contraseñas, tarjetas de crédito, etc. La vulnerabilidad está en la implementación del protocolo Heartbeat, que SSL/TLS utiliza para mantener viva la conexión.

El rango de versiones de OpenSSL afectadas va desde 1.0.1 hasta 1.0.1f. La versión en la VM de Ubuntu es 1.0.1.

El ataque Heartbleed se basa en la solicitud Heartbeat. Esta solicitud simplemente envía algunos datos al servidor, y el servidor copia los datos en su paquete de respuesta, de modo que todos los datos se devuelven. En el caso normal, supongamos que la solicitud incluye 3 bytes de datos “ABC”, por lo que el campo de longitud tiene un valor de 3. El servidor colocará los datos en la memoria y copiará 3 bytes desde el comienzo de los datos en su paquete de respuesta. En el escenario de ataque, la solicitud puede contener 3 bytes de datos, pero el campo de longitud puede decir 1003. Cuando el servidor construye su paquete de respuesta, copia desde el inicio de los datos (es decir, “ABC”), pero copia 1003 bytes, en lugar de 3 bytes. Estos 1000 bytes adicionales, obviamente, no provienen del paquete de solicitud; provienen de la memoria privada del servidor, y pueden contener información de otros usuarios, claves secretas, contraseñas, etc.

A continuación, cambia el campo de longitud de la solicitud. Primero, entendamos cómo se construye el paquete de respuesta Heartbeat a partir de la figura anterior. Cuando llega el paquete de solicitud Heartbeat, el servidor analiza el paquete para obtener el payload y el valor de Payload_length (que está resaltado arriba). Aquí, el payload es solo una cadena de 3 bytes "ABC" y el valor de Payload_length es exactamente 3. El programa del servidor tomará ciegamente este valor de longitud del paquete de solicitud. Luego construye el paquete de respuesta apuntando a la memoria que almacena "ABC" y copia Payload_length bytes al payload de la respuesta. De esta manera, el paquete de respuesta contendría una cadena de 3 bytes "ABC".

A continuación, lanza el ataque Heartbleed como se muestra en la figura siguiente. Mantén el mismo payload (3 bytes), pero establece el campo Payload_length en 1003. El servidor volverá a tomar ciegamente este valor Payload_length al construir el paquete de respuesta. Esta vez, el programa del servidor apuntará a la cadena "ABC" y copiará 1003 bytes desde la memoria al paquete de respuesta como payload. Además de la cadena ”ABC”, los 1000 bytes adicionales se copian en el paquete de respuesta, y pueden ser cualquier cosa de la memoria, como actividad secreta, información de registros (logs), contraseñas, etc.

El código del ataque permite cambiar el valor de Payload_length. Por defecto, el valor se establece en uno bastante grande (0x4000), pero puede reducirse.

La forma más sencilla de corregir la vulnerabilidad Heartbleed es actualizar la librería OpenSSL a la versión más reciente. Sin embargo, el objetivo es parchear la vulnerabilidad a través del código fuente.

Formato del paquete de solicitud/respuesta Heartbeat

struct {
    HeartbeatMessageType type;  // 1 byte: request or the response
    uint16 payload_length;      // 2 byte: the length of the payload
    opaque payload[HeartbeatMessage.payload_length];
    opaque padding[padding_length];
} HeartbeatMessage;

El primer campo (1 byte) del paquete es la información de tipo, y el segundo campo (2 bytes) es la longitud del payload, seguido del payload real y el padding. El tamaño del payload debería ser el mismo que el valor del campo de longitud del payload, pero en el escenario de ataque, la longitud del payload puede establecerse en un valor diferente. El siguiente fragmento de código muestra cómo el servidor copia los datos del paquete de solicitud al paquete de respuesta.

Procesar el paquete de solicitud Heartbeat y generar el paquete de respuesta

/* Allocate memory for the response, size is 1 byte
 * message type, plus 2 bytes payload length, plus
 * payload, plus padding
*/

unsigned int payload;
unsigned int padding = 16; /* Use minimum padding */

// Read from type field first
hbtype = *p++; /* After this instruction, the pointer
                * p will point to the payload_length field */

// Read from the payload_length field from the request packet
n2s(p, payload); /* Function n2s(p, payload) reads 16 bits
                  * from pointer p and store the value
                  * in the INT variable "payload". */

pl = p; // pl points to the beginning of the payload content

if (hbtype == TLS1_HB_REQUEST)
{
    unsigned char *buffer, *bp;
    int r;

    /* Allocate memory for the response, size is 1 byte
     * message type, plus 2 bytes payload length, plus
     * payload, plus padding
     */

    buffer = OPENSSL_malloc(1 + 2 + payload + padding);
    bp = buffer;

    // Enter response type, length and copy payload *bp++ = TLS1_HB_RESPONSE;
    s2n(payload, bp);

    // copy payload
    memcpy(bp, pl, payload);   /* pl is the pointer which
                                * points to the beginning
                                * of the payload content */
    bp += payload;

    // Random padding
    RAND_pseudo_bytes(bp, padding);

    // this function will copy the 3+payload+padding bytes
    // from the buffer and put them into the heartbeat response
    // packet to send back to the request client side.
    OPENSSL_free(buffer);
    r = ssl3_write_bytes(s, TLS1_RT_HEARTBEAT, buffer, 3 + payload + padding);
}

La vulnerabilidad reside aquí

    // copy payload
    memcpy(bp, pl, payload);

No hay ninguna comprobación para determinar si pl es válido o no. Por lo tanto, puede ocurrir una fuga de memoria.

Parches:

• Comprobación de límites antes de ejecutar memcpy()
• El servidor calcula el tamaño del paquete en tiempo de ejecución, lo que requiere una sobrecarga adicional

Los parches se realizaron en la VM, pero no se muestran en este repositorio.

¡Gracias por tu interés! Este proyecto fue divertido e interesante.