Abr 9 2014

Desdramatizando heartbleed: No se han comprometido dos tercios de Internet

Actualización: El Mundo ha modificado el titular eliminando la afirmación de que se han comprometido dos terceras partes de Internet, pero mantienen en el cuerpo de la noticia la afirmación de que dos terceras partes de los servidores usan OpenSSL.

Actualización 2: Errata Security ha hecho un estudio de propagación del bug de Heartbleed dando como resultado que, de las direcciones IP que dan un servicio de HTTPS, solo el 2% son vulnerables. Para interpretar este dato es necesario tener en cuenta:

  • No es el 2% de Internet, ni el 2% de servidores, ni siquiera el 2% de servidores web. Se trata del 2% de los servidores web que tienen activado HTTPS.
  • El dato se refiere al número de direcciones IP. Detrás de cada dirección IP puede haber varios servidores igual que cada servidor también puede tener varias direcciones IP.
  • Solo se ha analizado si es vulnerable la implementación SSL de servidores web, pero cualquier servicio que use SSL podría ser vulnerable, como se comenta más abajo.

Actualización 3: INTECO cifra el porcentaje de dominios .es afectados en torno al 1%. Ojo, que son dominios .es. Ni servidores ni direcciones IP, así que a tener en cuenta consideraciones similares a las de la actualización anterior: servidores ≠ direcciones IP ≠ dominios.

Hoy nos llamó un cliente asustado diciéndonos que fuésemos a ver la portada de tecnología de El Mundo y comprobásemos si lo que aparecía allí le afectaba.

Al ir a ver en la susodicha portada la noticia que ha provocado esa alerta, veo que se trata de una noticia de la popular periodista de Internet Mercè Molist sobre el recientemente divulgado (aunque descubierto en diciembre) y grave fallo de seguridad de OpenSSL conocido como heartbleed (CVE-2014-0160):

Un gravísimo agujero de seguridad compromete a las dos terceras partes de Internet

El fallo es grave por tres motivos.

  • La extendida presencia de OpenSSL.
  • El nivel de acceso que proporciona a la máquina comprometida y la ausencia de rastros de las posibles intrusiones.
  • La existencia de exploits in the wild que hacen que sea muy fácil explotar el fallo.

Pero como señala Ricardo Galli, también es matizable el alarmismo que se ha podido ver en algunos medios sobre el punto dos. El problema de seguridad deja abierta una importante puerta de acceso al sistema, pero tampoco nos desmadremos con las conclusiones:

Actualización: Más sobre el punto dos: una de las posibles consecuencias que más se han repetido es que heartbleed también permitiría robar la clave privada del certificado del servidor. Esto es bastante improbable.

Pero vamos, que sí, que hay que estar preocupados y comprobar si somos vulnerables. Así que el cliente tiene razón al pedirnos que nos aseguremos de que sus servidores no son vulnerables. Pero sus servidores, al igual que el 99% de servidores que he comprobado, no son vulnerables. Eso deja en un 1% el número de servidores vulnerables que he encontrado. A lo mejor es que somos muy buenos y tenemos unos servidores muy seguros, que probablemente algo de eso también haya, pero un descenso del 66% al 1% me parece una diferencia bastante significativa. ¿Qué ha pasado?

¿Seguro que el fallo compromete a dos tercios de Internet? Mira que Internet es muy grande. Bueno, pues si entramos al cuerpo de la noticia, ya cambia un poco la afirmación:

El Proyecto OpenSSL hizo público el lunes un comunicado que metafóricamente paró el corazón a muchos administradores de sistemas: avisaba de un grave fallo en las versiones 1.0.1 y 1.0.1f de OpenSSL, un paquete de herramientas y bibliotecas que utilizan dos terceras partes de los servidores de Internet, para cifrar sus comunicaciones y contenidos.

Ahora resulta que ya no son dos tercios de Internet sino dos tercios de los servidores de Internet. Y no son servidores comprometidos sino servidores con OpenSSL instalado. El fallo afectaría a los dos tercios de los servidores que tienen OpenSSL instalado y en Internet hay algo más que servidores, así que el dato de que afecta a dos tercios de Internet ya se esfuma.

A partir de aquí ya no se vuelve a hablar de este dato, así que no tenemos más información para poder juzgarlo. Pero con lo visto, ya hemos detectado el primer problema para tomarnos en serio el titular: Internet no son solo los servidores. Y aún si hablamos de servidores, me parece un dato exagerado ya que el dato que usa para cifrar el número de servidores comprometidos en dos tercios se basa en el número de servidores que supuestamente usan OpenSSL. Así que así se lo transmitimos al cliente para tranquilizarlo: hemos comprobado que sus servidores no son vulnerables y el dato del titular es exagerado.

Aviso también por Twitter a mis seguidores con respecto a no tomar en serio el titular sensacionalista:

Y este tuit, como la mayoría de mis tuits, pasaría desapercibido si no fuera porque Ricardo Galli, al que tampoco le va la marcha ni nada 😉 , le da difusión

Entonces Mercè Molist muy justamente nos pide que expliquemos por qué nos parece exagerado el dato:

Como me pilla a la hora de comer, le digo que ahora mismo no puedo y que le responderé más tarde explicándole cuáles son mis objeciones.

Pero a modo de adelanto, le explico cuál es la base de mis objeciones:

También, como el dato en el que se basa esa información parece ser el número de servidores que usan OpenSSL, le pido a Mercè Molist la fuente de ese dato:

Aclarando que no estoy dudando de su profesionalidad, sino que quiero acceder a la fuente original de los datos para poder comprenderlos mejor. Con emoticionos y todo:

La respuesta que recibo son insultos y la negación de proporcionar la fuente:

Vaya. Esa no es una buena respuesta. Hay cosas por las que no estoy dispuesto a pasar en un debate, y una de ellas son los insultos. Para mí, ahí se acaba la discusión. Así que esta explicación que estaba escribiendo para Mercè Molist ya no se la enviaré, al menos mientras no retire sus insultos.

Lo más curioso es que después se justifica y lamenta diciendo que ella ha sido la insultada, cosa que yo nunca he hecho:

En fin, como a menudo le gusta decir a Ricardo Galli: «puños de hierro, mandíbulas de cristal». Decimos que quien nos pide referencias de los datos que damos nos está insultando, pero luego respondemos con insultos.

Debo de haber superado algún límite del humor o algo. El de las susceptibilidades que se la cogen con papel de fumar, por ejemplo.

Por otra parte, dar un dato y negarse a respaldarlo con ninguna prueba o fuente diciéndole a los que pidan pruebas que las busquen ellos mismos va en contra de toda lógica. ¿Se lo imaginan? «Noticias de la noche. Muere a tiros el Presidente de Elbonia. El que quiera pruebas, que las busque él mismo». Absurdo, ¿verdad? Y es que el que hace una afirmación es el que tiene que aportar algún dato que sustente esa afirmación (carga de prueba). De lo contrario, vamos listos. Si alguien te dice que dos de cada tres personas usan dentadura postiza sin aportar ninguna fuente o prueba, ¿lo aceptas sin más o le pides que justifique su afirmación? ¿No te parece una cifra demasiado grande como para aceptarla sin más? Pues lo mismo con la afirmación de Mercè Molist.

Por lo tanto, como Mercè Molist sigue sin aportar la fuente de su dato, no podemos confiar en su veracidad. Sin embargo, podemos especular de dónde lo ha sacado. Es un dato muy divulgado que dos tercios de los servidores web usan Apache y NGINX. Nótese que, de la reducción inicial del ámbito de aplicación de esos dos tercios de Internet a solo dos tercios de los servidores, ahora ya pasamos a dos tercios de los servidores web. Pero de esto ya hablaremos más adelante, sigamos. Como decía, tenía la sospecha de que cuando Mercè Molist hablaba de dos tercios de servidores con OpenSSL se refería a los dos tercios de servidores web con Apache y NGINX, pero quería confirmarlo porque a lo mejor estaba usando otros datos. Al fin y al cabo, no solo los servidores web usan OpenSSL (de esto también hablaré más adelante). Recibiendo como respuesta solo insultos y la negativa a justificar la afirmación, solo nos queda la especulación, a la cual también se une Ricardo Galli apuntando a la misma sospecha que yo:

Me apunto en la montaña de cosas por hacer buscar la referencia a esos datos de dos tercios de servidores Apache y NGNIX. Si bien, no hay una fuente oficial y 100% fiable para estos datos, Netcraft suele ser una fuente bastante citada en cuanto a estadísticas de servidores, probablemente ahí encuentre algo.

Y, efectivamente, una vez que he buscado informes de Netcraft, sus datos cifran en dos tercios los servidores web que usan Apache y NGINX y, efectivamente, Apache y NGINX ofrecen HTTPS con OpenSSL. ¿Es suficiente este dato para sostener la información de que dos tercios de Internet ha sido comprometido? Veamos por qué no:

  • Mi móvil, tablet, portátil, … también están conectados a Internet. ¿Están en el informe de Netcraft? No. Así que ya no son dos tercios de Internet.

  • Los servidores de correo, FTP, mensajería instantánea, … también pueden usar OpenSSL. ¿Están en el informe de Netcraft? Tampoco. Esos dos tercios solo se refieren a servidores web.

  • Pero es que esos dos tercios no se refieren a servidores web que usan HTTP sobre SSL, sino a servidores web que usan Apache y NGINX. ¿Usan todos los servidores HTTP SSL? Desde luego que no. Puedes probar a cambiar en las webs que más visitas el http:// por https://, a ver cuántas lo soportan. La web en la que escribe Mercè, por ejemplo, no funciona sobre SSL. Se reducen más todavía esos dos tercios.
    Esto mismo ya lo avisa también Netcraft en un artículo que nos envía @chencho:

  • De todos los Apaches y NGINX que usan SSL, ¿todos lo hacen con OpenSSL? Aunque la mayoría sí, hay otras implementaciones de SSL, como GnuTLS que Apache permite como sustituto de OpenSSL. Aunque OpenSSL es mayoritario, los dos tercios se reducen un poco más.

  • De todos los que usan OpenSSL, ¿son todos vulnerables al fallo de seguridad? No, solo las versiones entre la 1.0.1 y 1.0.1f. Toda la rama 1.0.0 y toda la rama 0.9.8 están libres del fallo. Esas ramas todavía se usan. Por ejemplo, el primer servidor con el que se me ocurrió comprobar su versión de OpenSSL:

    Barrapunto usa OpenSSL 0.9.8c.

    Los dos tercios se hacen más pequeños todavía.

  • ¿Todas las versiones de OpenSSL entre 1.0.1 y 1.0.1f son vulnerables? No, depende de la compilación. Solo son vulnerables las que fueron compiladas con heartbeat. Las que fueron compiladas sin heartbeat (OPENSSL_NO_HEARTBEATS) no están afectadas.

Pero como ya se ha comentado, resulta que OpenSSL no solo se usa para HTTP sino que también se puede usar para correo, mensajería instantánea, FTP… Aquí un ejemplo del bug heartbeat en NNTP:

Exportando heartbleed en un servidor NNTP

Exportando heartbleed en un servidor NNTP

Y si sumamos todos los servidores vulnerables y no solo los HTTP, ¿podríamos llegar a esos dos tercios? ¿Puede ser ese el dato que usó Mercè Molist? Nunca lo sabremos, porque sigue sin explicar su afirmación y a mí me seguiría pareciendo una estimación exagerada.

Todo esto me ha recordado a un artículo que escribí en Security by Default acerca del ataque de CB3ROB a Spamhaus. En ese artículo también se daban cifras sensacionales, pero citaba su fuente, la identificaba con una fuente interesada en dar cifras exageradas y aconsejaba varias veces escepticismo hacia esos datos.

Aún así hubo quien dijo que había sido sensacionalista. A quienes lo dijeron, no los insulté, solo le recordé a quien dudó de los datos que, efectivamente, yo también recomendaba escepticismo.

Bonus por haber llegado hasta el final: ¿Cómo comprobar si un gran número de máquinas es vulnerable? Esto es lo que he hecho yo: si las máquinas están en un rango de direcciones IP consecutivas (para el ejemplo vamos a suponer que están en el rango 192.0.2.64/27), con el siguiente comando obtenemos el listado de máquinas que tienen heartbeat activado en el puerto 443:

for i in $(seq 65 94); do echo -e "Q\n\r" | timeout 3 openssl s_client -connect 192.0.2.$i:443 -tlsextdebug 2>&1 | grep -q heartbeat && echo 192.0.2.$i; done

Y para los protocolos que usen STARTTLS (en el ejemplo, para SMTP):

for i in $(seq 65 94); do echo -e "Q\n\r" | timeout 3 openssl s_client -connect 192.0.2.$i:25 -starttls 25 -tlsextdebug 2>&1 | grep -q heartbeat && echo 192.0.2.$i; done

Una vez que tenemos el listado de direcciones IP con heartbeat activado, podemos probar si es vulnerable con hb-test.py, que incluso nos mostrará un volcado de memoria de la máquina como prueba.

6 comments on “Desdramatizando heartbleed: No se han comprometido dos tercios de Internet

  1. Gracias por tu artículo, Jesús. Me has aclarado muchas dudas que tenía sobre el “Heartbleed”. En cuanto a la “simpática” periodista de El Mundo, quizá yo no le dedicaría más tiempo. Ni ella va a llegar a más ni tú debes aspirar a menos.

    Un afectuoso saludo.

  2. Hola Chuso.

    Nunca antes te había leído, pero agradezco el pedazo de explicación que nos has compartido. Mi intención era encontrar datos objetivos sobre el tan cacareado defecto de OpenSSL. Creí que sería una labor larga y tediosa, pero al cabo de un rato me encontré con una lectura sumamente útil, además de divertida.

    Por cierto, te pudiste ahorrar la parte de “La web en la que escribe Mercè, por ejemplo, no funciona sobre SSL”, pero vamos, fue mentalmente sano. 😉

    Para la señora Ferrer: Como es muy probable que leas esto (estoy casi seguro de que alguien te canalizará aquí), a ti tampoco te había leído, y lamento que la primera impresión haya sido tan mala, pero vamos, una disculpa pública para Chuso podría mejorar mucho las cosas. Ten esa grandeza, te sentirás mejor. Precisamente apenas ayer me registré en El Mundo (para poder comentar), no dejes que me vaya con la idea de que lo visto hoy es una actitud normal en su medio de comunicación.

    Chuso: no prometo seguirte en Twitter, tal vez lo haga, pero lo seguro es que te estaré “vigilando”. 🙂

    Un gran saludo y gracias nuevamente.

    Al González.

    • Hola, Al.

      Gracias por tu comentario, me alegro de que te haya resultado interesante mi explicación.

      Mi intención era encontrar datos objetivos sobre el tan cacareado defecto de OpenSSL

      Acabo de actualizar el post para incluir un enlace de Errata Security que da cifras orientativas del alcance del bug.

      Por cierto, te pudiste ahorrar la parte de “La web en la que escribe Mercè, por ejemplo, no funciona sobre SSL”

      La noticia de Mercè Molist equipara servidores Apache y nginx con servidores que usan OpenSSL, lo que no es cierto. Quise buscar un ejemplo claro de que un servidor web no tiene por qué tener activado HTTPS, quise que fuese una web popular y grande para que no se pudiera considerar que era un caso aislado y se me ocurrió probar con El Mundo. Resultó que, efectivamente, El Mundo no soporta HTTPS y no me pareció inadecuado usar este ejemplo.
      Por cierto, como señala Ricardo Galli, este error de equiparar servidores Apache/nginx con servidores que usan OpenSSL procede de una mala interpretación de un dato sensacionalista en la web de heartbleed: https://twitter.com/gallir/status/453946144096149504

  3. “Más sobre el punto dos: una de las posibles consecuencias que más se han repetido es que heartbleed también permitiría robar la clave privada del certificado del servidor. Esto es bastante improbable.”. Chuso, me temo que vas a tener que retractarte… el artículo al que se enlazaba desde las palabras “bastante improbable” ya ha sido retractado.
    Hoy 13 de abril de 2014 se ha revelado que Heartbleed es más grave aún de lo que se suponía. Sí, más aún. Cloudflare ha demostrado que no sólo es posible adquirir las claves privadas, sino además no queda constancia de ello. Eso quiere decir que todo servidor que haya utilizado OpenSSL 1.0.1 _en algún momento de la historia_ está comprometido. Eso son los 600.000 servidores que identificáis aquí… como mínimo.

    • Hola, Ignacio. Gracias por tu comentario.
      Sí, estoy al corriente tanto de que el artículo enlazado se ha retractado como del desafío de Cloudflare.
      En el artículo enlazado se retractan de la explicación que habían dado pero siguen manteniendo que es muy difícil obtener las claves privadas y yo estoy de acuerdo.

      Para explicarlo, vamos a recordar por encima en qué consiste Heartbleed: el cliente le dice al servidor que va a enviarle X bytes a un servicio echo, es decir, un servicio en el que el servidor le devuelve al cliente la misma información que envió. Por lo tanto, el servidor reserva X bytes de memoria. Después, el cliente, en vez de enviarle esos X bytes le envia una cantidad Y<X y el servidor, al devolverle esos datos, le devuelve todos los X bytes que había reservado en vez de los Y que el cliente envió, por lo que le envía también la información que había previamente en esa zona de memoria y que no fue sobreescrita con la información enviada por el cliente como se esperaba. Probablemente quede más claro con una explicación gráfica.

      Bien, teniendo esto en cuenta, ya nos encontramos con la primera restricción: no podemos leer cualquier zona de memoria, solo la memoria que ha sido reservada para los datos que iban a ser enviados al servicio echo de hearbeat hasta un máximo de 64 KB. La vulnerabilidad se encuentra en que esa memoria reservada para hearbeat puede ser memoria que haya sido usada previamente por otros procesos que después la hayan liberado y que por lo tanto puedan haber dejado información sensible residual. Esa información se esperaría que fuera sobreescrita con la que envía el usuario, pero, al no comprobarse la discrepancia entre el tamaño efectivo de los datos que envía el usuario y el declarado, se permite que se reserve más memoria de la necesaria que nunca será sobreescrita y que se enviará tal cual al usuario. Aquí tenemos la segunda restricción: solo podemos obtener datos que ya no estén en uso. Y aquí es donde fallaba el artículo de Errata Security ya que decía que era imposible obtener la clave privada porque nunca se liberaba de la memoria. Sería así si, efectivamente, la clave privada nunca se liberase, pero eso no es así.
      ¿Cuál es la probabilidad de que ningún otro proceso haya sobreescrito la zona de memoria liberada en la que se encontraba la clave privada? ¿Y la de que entre esos 64 KB que reserva hearbeat se encuentre la clave privada? Si por ejemplo tenemos un servidor con 8 GB de RAM, ¿qué probabilidades hay de que seleccionemos un fragmento de 64 KB en el que se encuentre la clave privada y de que no haya sido sobreescrita todavía por ningún proceso? No he hecho las cuentas, pero me da que va a salir una probabilidad bastate pequeña.

      En cuanto al desafío de Cloudflare, el usuario que la consiguió hizo 2,5 millones de intentos siendo el 30% de las peticiones realizadas por todos los usuarios. Es decir, que entre todos los usuarios hicieron 8,3 millones de intentos hasta que se consiguió la clave. Me parece un número de intentos suficientemente alto para seguir considerando que es bastante difícil conseguir la clave privada. Se ha demostrado que es posible, pero yo no he dicho que fuera imposible, solo muy difícil.
      Por otra parte, la clave privada se obtuvo después de reiniciar el servidor. Ya desde el principio se dijo que hay más probabilidades de obtener la clave privada tras reiniciar el servidor ya que en ese momento es accedida la clave privada y, después de liberar la zona de memoria en la que se encuentra, es más fácil que sea reservada para heartbeat debido a la tendencia de algunas implementaciones de malloc a reservar zonas de memoria recientemente liberadas (aunque OpenSSL usa su propia implementación de malloc que no sé si influye en este punto) y a que es menos probable que haya sido sobreescrito por otro proceso. Hay que tener en cuenta también que el servidor de Cloudflare estaba destinado exclusivamente a este propósito constando únicamente de una página estática y un formulario de contacto, por lo que tendría muy poca actividad de memoria y era menos probable que la clave privada fuese sobreescrita con datos de otro proceso.

      Eso quiere decir que todo servidor que haya utilizado OpenSSL 1.0.1 _en algún momento de la historia_ está comprometido

      ¿Todas las versiones de OpenSSL entre 1.0.1 y 1.0.1f son vulnerables? Lo he respondido en el post.

      • Me matiza este comentario Ricardo Galli por Twitter:

        Claro, sería un grave problema de seguridad que en la memoria que reservara un proceso aparecieran datos de otro proceso, no pensé eso. Gracias a Ricardo por aclararlo 🙂

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.