Apple y "goto fail", un fallo de seguridad en SSL/TLS y su posible relación con la NSA

El viernes pasado, Apple lanzaba una actualización urgente para iOS 7. La razón: una vulnerabilidad en el sistema SSL/TLS. Y no una vulnerabilidad cualquiera, sino un fallo muy grave. La librería de Apple no verificaba correctamente la autenticidad de la conexión, de tal forma que alguien podría escuchar sin problemas conexiones aparentemente seguras.

La misma vulnerabilidad se ha descubierto también en OS X, y además se ha detectado una enorme coincidencia sobre las fechas en las que ese fallo apareció y filtraciones que conocíamos sobre la NSA y el programa PRISM. Pero no adelantemos acontecimientos.

¿En qué consiste el fallo en SSL/TLS?

Tal y como explicamos en nuestro artículo sobre el funcionamiento de HTTPS, SSL/TLS es un protocolo para cifrar y autenticar las conexiones con un servidor. Cuando te conectas a tu banco no quieres que nadie vea los datos que le estás mandando (cifrado), pero además quieres asegurarte de que estás hablando con el banco y no con un impostor (autenticación).

Para cifrar los datos, el servidor y tu navegador tienen que intercambiar una clave. Para ello, el servidor tiene que enviar unos parámetros iniciales que tienen que ir firmados digitalmente. Esto es, tienen que tener un código que asegure que es el servidor quien te envía los datos.

Esa firma hay que verificarla, y ahí es donde entra el código que veis en la imagen (podéis verlo también en el código fuente de Apple). Seguramente veáis algo raro, y es ese goto fail; duplicado. Algún programador en la sala también se habrá asustado con los gotos, aunque en este caso son una buena práctica (ver capítulo 7 de la guía de estilo de Linux).

Frikadas informáticas aparte, expliquemos ese código. Los ifs van actualizando un hash o huella digital. Si fallan, se ejecuta la línea después del if: goto fail, que sale de la función y devuelve el código de error. Sin embargo, el goto duplicado se va a ejecutar siempre. Es decir, que en todo caso salta directamente a la salida y devuelve el código de error, que será 0 (indicativo de "todo ha ido bien").

Casualmente, el código que se salta es el encargado de verificar la firma. Esa línea duplicada se salta la verificación de la firma. Y como el código que devuelve la función es siempre 0, cualquier programa que use esa función pensará que al firma es siempre correcta.

¿Implicaciones? Que alguien podría espiar tus conexiones seguras. Hay que ejecutar un ataque MITM (man-in-the-middle o "hombre en el medio"). Un servidor intercepta las conexiones entre tu navegador y tu banco y modifica los parámetros iniciales de cifrado que te envía el banco antes de que te lleguen. La librería de Apple no verifica la firma y no detecta por lo tanto que los datos han sido modificados por el camino, y la conexión sigue como si no pasase nada. Sin embargo, ese servidor intermedio ahora sabe la clave de cifrado y puede ver qué estás enviando.

¿A quién afecta este fallo?

El fallo está en una librería de sistema de Apple usada por varias aplicaciones, por lo que muchísimos programas para OS X a partir de 10.9 y iOS a partir de la versión 6 están afectados. La actualización de iOS 6 y 7 ya está lista, la de OS X tardará algo más. El fallo no ha sido detectado hasta ahora - aunque había habido algún "aviso" de que algo no iba bien - así que es difícil que haya sido explotado por atacantes.

Para poder usar ese fallo y espiar tus conexiones, el atacante tendría que "ponerse" entre tu ordenador y el resto de Internet. Conectarse a redes WiFi inseguras es una forma de facilitarle las cosas al hacker de turno, así que, como siempre, nada de usar tranquilamente redes abiertas ni protección WEP, como dicen nuestros compañeros de Applesfera.

También podéis ver si vuestro navegador está afectado en gotofail.com. Chrome y Firefox no usan la librería de Apple, así que no deberíais de tener problemas con ellos.

Y la NSA, ¿qué pinta en todo esto?

Al principio del artículo he dicho algo de la NSA. ¿Qué tiene que ver con todo esto?

Lo cierto es que no hay ninguna prueba fehaciente, sólo circunstanciales. iOS 6, la versión en la que se introdujo el fallo, salió en septiembre de 2012. En las diapositivas filtradas de la NSA sobre el programa PRISM, la fecha en la que Apple es añadida al programa es... octubre de 2012. John Gruber plantea varios niveles de paranoia:

1. La NSA no sabía nada.

2. La NSA conocía el fallo pero no lo usó.

3. La NSA conocía el fallo y lo explotó.

4. La NSA introdujo la vulnerabilidad.

5. Apple introdujo la vulnerabilidad a petición de la NSA.

No podemos hacer más que especular sobre qué posibilidad es la correcta. Yo personalmente apostaría por la 3, pero con matices.

El fallo es sutil, y muy posiblemente fruto de un merge (combinación de dos versiones del mismo archivo) que no se repasó bien. Un desliz. Sin embargo, es lo suficientemente grave como para ser detectado por una herramienta automática de prueba de la NSA. Y con las capacidades de la agencia, es perfectamente posible que lo hayan explotado contra sus objetivos.

Ahora bien, no creo que esto tenga que ver con el programa PRISM. La razón es simple: este programa era de recolección de datos de los servidores de las empresas. La NSA podría haber usado la vulnerabilidad para otros menesteres, como espiar a ciertos objetivos interesantes, pero es difícil que se haya usado de forma masiva, sobre todo sin que nadie se haya dado cuenta.

Lo de la NSA no deja de ser una curiosidad/casualidad. Lo que sí es más grave es que un fallo de este tipo se corrija en un sistema (iOS) y no en otro (OS X), dejando vulnerables a muchísimos usuarios. Y como siempre, la falta de transparencia de Apple al explicar esta vulnerabilidad. En Cupertino tienen un problema con la seguridad: situaciones como esta no pueden volver a ocurrir.

Más información | Imperial Violet | Ashkan Soltani