El error SSL de Apple: Otro ataque de intermediario (Man-in-the-Middle)

El problema

Es posible que hayas oído que recientemente se ha descubierto un grave fallo en la implementación de SSL por parte de Apple. Apple no ha ofrecido muchos detalles, pero los investigadores de seguridad familiarizados con el problema han declarado que el fallo puede abrir la posibilidad de un ataque de intermediario (man-in-the-middle, MITM). Esto significa que los sistemas sin parches son vulnerables a la fuga de contraseñas, números de tarjetas de crédito u otra información sensible sin que el usuario sea consciente de que su conexión es insegura. En el momento de escribir estas líneas, hay un parche disponible para iOS 7, pero no para los equipos Mac OS X.

Los ataques "man-in-the-middle" a SSL no son nada nuevo; de hecho, hace nueve años hice una presentación en la Conferencia RSA de 2005 sobre un ataque "man-in-the-middle" con malware que había descubierto uno de nuestros clientes, nuestro análisis de cómo funcionaba y qué se podía hacer para evitarlo.

Un arreglo

From the limited amount of information that’s been provided so far, it sounds like there’s not much that iOS and Mac users can do about this until a patch is released and installed. But can organizations maintain some assurance that the users communicating with them are not MITM victims? In many cases, the answer may be “yes,” with the help of client-side SSL certificates.

Para ver cómo funciona, veamos primero cómo funciona un ataque man-in-the-middle. La mayoría de las veces que se utiliza SSL , sólo implica un certificado en el servidor, como se muestra a continuación:

To be successful, the man in the middle must be able to convince the client that it’s talking directly to their intended endpoint. This is supposed to be impossible, if SSL is implemented properly (which appears to have been Apple’s problem), and appropriate trust anchors are maintained (which is sometimes easier said than done). If either of these aren’t upheld, man-in-the-middle attacks become possible.

But in mutual, or client-side SSL, the server requires that the client provide an authentication certificate as well. In this case, the server gains a level of assurance that it’s talking directly to the client:

Now the attackers’ task becomes at least twice as difficult, as they must convince both ends of the connection that they are communicating directly with each other, rather than just one.

Obviously, this specific problem with Apple iOS and Mac OS X will eventually be patched and go away. But it will almost certainly not be the last time we hear about a possible man-in-the-middle attack, and client-side certificates can help defend against MITM attacks the next time they come up as well. It’s worth noting, for example, that the server’s demand for a client certificate prevents the attack, even if the client’s machine is still unpatched and otherwise susceptible.

Protección de claves privadas

En cualquier implementación de certificados digitales, todo gira en torno a las claves privadas; si nuestro hombre del medio en el diagrama anterior consigue acceder a la clave privada del cliente, vuelve a las andadas. Por tanto, una protección diligente de las claves privadas es primordial; tecnologías como la Generación de Claves en el Dispositivo (ODKG) pueden ayudar, ya que limitan los lugares donde las claves privadas pueden ser capturadas o expuestas. Cada vez que las claves se generan fuera del dispositivo, lo que ocurre con frecuencia en escenarios móviles o BYOD, están sujetas a riesgo en cualquier lugar donde se creen, transmitan, almacenen o archiven. Esta es la razón por la que CSS pone tanto énfasis en habilitar ODKG en escenarios donde de otra manera es difícil de lograr - incluyendo dispositivos iOS y Mac.