Mozilla hispano, tu comunidad en español de Mozilla

Hace un par de semanas, publicamos que Mozilla podría (y finalmente lo hizo) desactivar el plugin de Java debido a un problema de seguridad bastante crítico. El asunto era complejo (puedes leer el excelente artículo que publicó Willyaranda para más detalles) porque, además, no todos los navegadores se veían afectados, ni el problema estaba teóricamente limitado a Java.

Con todo, Oracle, actual propietario del lenguaje Java y sus productos asociados, ha publicado recientemente una actualización de las distintas versiones de Java que solucionan el problema (junto con otras correcciones menores, hasta totalizar unas 20). Que el problema existía y era grave lo demuestra el hecho de que no sólo ha publicado actualizaciones para las versiones en ciclo de soporte (Java 7u1 y Java 6 Update 29), sino también para Java 5 y Java 1.4; esta última terminó hace tres años su ciclo de soporte.

Este hecho viene a demostrar la importancia de que Mozilla siga teniendo una posición de influencia dentro de la web, manteniendo Firefox una cuota de mercado destacable. La presión ejercida para que Oracle ofreciera una solución a sus usuarios ha tenido éxito y de nuevo vuelven a estar navegando seguros, usaran Firefox o no.

Puedes descargar las últimas versiones del entorno de ejecución de Java en su página web. El entorno de ejecución de Java, además de proporcionar un plugin para los navegadores que permite ejecutar pequeñas, y no tan pequeñas, aplicaciones incrustadas en páginas web, te da acceso a miles de aplicaciones multiplataforma de todo tipo escritas en Java.

Supongo que muchos de vosotros conoceréis Java, un lenguaje de programación muy extendido (de hecho, el segundo más usado) que es denostado por muchos y alabado por otros tantos. Java es usado en la web en infinidad de sitios: el chat de vídeo de Facebook, applets en diferentes webs, bancos… Como digo, su uso está extendidísimo, y aún más en las redes internas de las empresas, ya que Java permite un desarrollo multiplataforma y rápido.

Así que antes de nada, vamos a hablar de qué es eso de BEAST que viene en el artículo poniendo la explicación que viene en el vídeo donde se presentó:

BEAST es un ataque al cifrado SSL3 y TLS1.0 que utilizan la mayoría de las páginas web para su conexión segura. ¿Lo entiendes? Si es que no, porque no hemos explicado nada, sigue leyendo. SSL es el protocolo de cifrado que se utiliza cuando tú como usuario pides una página cifrada. Por ejemplo la de tu banco. Lo que quieres es que nadie pueda tener algo para poder acceder a tu cuenta si están escuchando tu conexión. Poniendo un símil de película: imagínate que eres un ladrón de bancos, y estás hablando con tu compinche que está al otro lado del teléfono. Si dices: “A las 12 en el banco para robarlo”, si la policía tiene pinchado tu teléfono (que ocurre en las películas y en la realidad), te tiene cercado. ¿Por qué? Porque no has cifrado los datos, entienden que esa secuencia de palabras “A las 12 en el banco para robarlo” significa lo que todos sabemos. Los datos han viajado a través de la red en forma de texto claro. Pero ahora imagínate que estás realizando la conexión a tu banco y se envían los datos del login vía POST (un método de enviar datos en el protocolo HTTP, usado por ejemplo en los formularios)

¿Qué pasaría en este caso? Que si alguien está escuchando tus envíos y recepciones de paquetes de datos, podría ver que tu usuario es “pepito” y tu contraseña es “1234″, así, en claro. Lo mismo que en las películas o cuando la policía pincha tu teléfono. Pero ocurre.

¿Qué es lo que permite SSL?Pues que haya un intercambio de claves entre tú como usuario (lo hace el navegador de forma automática) y el receptor (el banco, por ejemplo). Así, por ejemplo, el texto que se envía no es usuario=”pepito” y contraseña=”1234″ si no que se puede mandar algo del estilo (aleatorio externamente, controlado internamente): “asdfElxcvn31CLxcv-asd-OO13..·asdfasf1235″. ¿Lo entiendes si estuvieras en medio? No, es una secuencia de números, letras y símbolos que es imposible de deshacer y ver qué es lo que era lo originariamente mandado si no tienes las claves privadas que sólo están en los equipos remotos. Eso se hace cuando haces ‘login’ a una página cifrada y durante todo el tiempo que la sesión esté abierta. Así por la red no va a viajar la página que estés viendo en claro, con sus etiquetas html, body, head, su javascript, css y demás, si no que viajará todo cifrado, pareciendo que los ordenadores se han vuelto locos y mandan cosas sin sentido.

Pero… ¿hay algo imposible? Ahí entra BEAST
BEAST puede descifrar esas comunicaciones. Pero dirás… ¡si es un intercambio privado de claves, cómo va a poder hacerlo! El problema radica en el diseño de los algoritmos que intervienen por norma general, que son del tipo CBC (buena explicación aquí). Resulta que estos algoritmos tienen una vulnerabilidad: para cifrar el bloque n, se utiliza la salida cifrada del bloque n-1, pudiendo hacer predecible cuál es el texto en claro en una secuencia suficientemente larga y si se ha podido inyectar datos.

Lo que hace BEAST es “simple”:

• Te conectas a una página maliciosa
• Esa página maliciosa tiene un contenido malicioso que crea una conexión desde él hasta la web de la que quieren sacar los datos
• Hay un sniffer en la web del atacante (donde está el contenido malicioso) que puede escuchar la comunicación y descifrar los datos.

Y tú como usuario, ya estás desprotegido. Y es aquí donde entra Java en este artículo. Java es capaz de cargarse en una página web normal (como Flash en Youtube, por ejemplo) para mostrar contenido. El problema es que Java permite crear una conexión entre su proceso (independiente del navegador en el caso de Firefox, en otros será dependiente de él) y la página atacada, debido a un bug. Se supone que sólo debería poder crear una conexión al dominio que lo ha pedido (si nuestra web atacante es http://soymalo.com/ no podría pedir datos ni cookies a algo que no sea de ese dominio). Ahí es donde radica el problema. Java empieza a realizar peticiones desde la página atacante a la web que se quieren sacar los datos (Paypal, tu banco, etc…) y empieza a descifrar los datos. Es un proceso “lento” (100 segundos en el caso de PayPal, elegido porque “lo hace todo bien en materia de seguridad SSL”) y requiere una buena conexión con el equipo atacado para que se realice en ese intervalo de tiempo (red universitaria, en tu trabajo, incluso una WiFi insegura) pero como se muestra en el vídeo, es totalmente posible.

Vale, ¿pero qué podrían hacer con esa cookie?
La cookie es tu identificador único con una página, a grandes rasgos. Es como tu número de DNI (aunque suele cambiar cada vez que haces logout y login en una página). Imagínate que consiguen ese “id” que te identifica. Pegan ese “id” en una cookie creada por el atacante en su navegador, van a la página y ¡voilá! él es tú. Y tú no te has dado ni cuenta.

Muy bien, pero… ¿sólo con Java?
No. Java ha sido la prueba de concepto para probarlo aprovechando un bug en Java. De hecho los investigadores no tienen duda de que se podría realizar con JavaScript (sí, eso que el 99.99% de las páginas usan) y XMLHTTPrequest o con otro plugin para los navegadores que permitan crear dichas conexiones y no comprueben el origen de las conexiones.

Entonces, ¿por qué bloquear Java?
Porque Oracle no ha arreglado el bug y no se ha pronunciado al respecto. Uno de los pilares de Mozilla es la privacidad y la seguridad de los usuarios en la red. Por eso la idea de que Java, al ser inseguro actualmente (junto a servidores que no implementan versiones nuevas de TLS como los navegadores y el propio protocolo SSL, no hay que olvidarse), no debería estar activado en Firefox, al menos en sus versiones vulnerables, esto es, todas.

¿Cómo mitigarlo?

• Desactivando Java y sólo permitirlo en los dominios que queramos. Hay plugins para ello, como NoScript
• Ver una actividad extraña en nuestra red, algo más complejo de comprobar
• Desconectarnos de cualquier sitio que use SSL cuando no vayamos a usarlo más (debido a que el ataque toma tiempo, si invalidamos nuestra sesión, aunque consiga la cookie, no será usable
• Si eres administrador de un servidor, cambiar el cifrado de AES o Triple DES a RC4 que no tiene este problema (aunque sí otros, pero no tan importantes para SSL)

Mozilla está y estará siempre en el lado de los usuarios. Y por eso no dudará en tomar medidas excepcionales (y quizás excepcionalmente impopulares) para proteger a los usuarios que usan Firefox y los demás productos de la fundación.

Podemos seguir la discusión en los comentarios

PD: es probable que haya imprecisiones en este artículo. Si es así, ¡no dudes en ponerlo en los comentarios!