XSS en RoundCube: Si administras un webmail RoundCube, deshabilita la opción de mostrar los archivos Flash en el navegador

RoundCube es un software open source para crear servicios de webmail. Bastante agradable y fácil de usar, un buen conjunto de características y posibilidades ampliable mediante plugins, personalizable mediante skins... Un sistema que, en definitiva, consigue su propósito de proporcionar al usuario una experiencia bastante cercana a la de las aplicaciones de escritorio tradicionales.

Desde luego, una opción a tener en cuenta. Y a seguir en el caso de que actualmente estemos usando otra. Su página web es:
http://www.roundcube.net/

El pasado 21 de noviembre de 2012 encontré una vulnerabilidad en RoundCube y la comuniqué a sus desarrolladores. Podéis encontrar los detalles y una prueba de concepto en:
http://trac.roundcube.net/ticket/1488828

Hay un fichero en el que se muestra un ejemplo y se proporcionan los detalles técnicos y una prueba de concepto:
http://trac.roundcube.net/attachment/ticket/1488828/roundcube.net.pdf.zip

Dadas las circunstancias, está en inglés. Por si alguien prefiere que se lo cuenten en español: básicamente se trata de que un atacante puede enviar un fichero Flash (SWF) adjunto a un mensaje. El fichero podría incluso haber sido renombrado a TXT para no levantar sospechas. Si el receptor abre el fichero (y hay formas de hacérselo abrir incluso sin que haga clic sobre él) el fichero Flash será abierto en el navegador.

El problema es que un fichero SWF, que no se nos olvide que fue enviado por un atacante, puede provocar la ejecución de código JavaScript en el contexto de la sesión abierta en RoundCube. Eso que en jerga técnica se denomina XSS.

Y ejecutar JavaScript en el contexto de una aplicación es casi tomar control de ella. El atacante podría robar la información de los contactos de la víctima. O sus correos electrónicos. O hacerle enviar mensajes, o eliminar los que haya en sus bandejas o forzarle a visitar páginas,...

La solución aportada hasta ahora por el equipo de desarrollo de RoundCube consiste en detectar los SWF "disfrazados" de otra extensión.

En lo que respecta a ficheros SWF con extensión SWF (sin renombrar), vinieron a decir que, bueno, es una situación similar a si a un usuario le envían un documento de Word con código malicioso en Visual Basic dentro. Como señalando que ya no es problema del sistema de correo. Lo cual no termina de convencerme, puesto que significaría dejar en manos del usuario la responsabilidad final.

Y los usuarios no siempre conocen los riesgos asociados y las repercusiones de sus actos.

Comentan, en todo caso, que es posible configurar RoundCube para que se fuerce la descarga de los archivos de Flash en lugar de mostarlos en el navegador. Con ello no se conseguiría evitar totalmente la ejecución de código JavaScript (el usuario siempre podría abrir el fichero SWF manualmente después), pero sí que se haga en el contexto de la sesión abierta en el correo electrónico. En definitiva, el código JavaScript no interactuaría con el correo. Y señalan que eso se puede hacer anulando manualmente la opción de configuración de 'client_mimetypes' en Roundcube.

Yo les he pedido que ésta sea la configuración por defecto.

No sé si terminarán haciéndolo o no. En todo caso, siempre habrá gente que tenga webmails que no pueda o no se atreva a actualizar y que podrían seguir siendo vulnerables indefinidamente.

De modo que, si administras un servicio de webmail basado en RoundCube, ahí va mi consejo: échale un vistazo a la configuración del webmail y asegúrate de que está deshabilitada la visualización en el navegador de los adjuntos de tipo Flash.

La trampa del elemento facilitador

Hace poco cruzaba unos correos con mi amigo Carlos sobre esos temas de Salud Móvil que tanto le fascinan (y de los que tanto sabe). Y en esa conversación salió, no una sino dos veces, una pregunta difícil: ¿cómo afecta a la Seguridad de la Información el uso de Software Libre? ¿Es beneficioso o perjudicial?

La idea quedó en el aire y no hubo ocasión de responderla. Y ahora no paro de pensar en ella. Como en los dibujos animados, dos pequeñas figuras se suben a mis hombros: una con alas, voz dulce y tocando la lira. La otra, de color rojo, voz maliciosa, rabo, cuernos y un tridente...

Una me dice: "El Software Libre es beneficioso. El código fuente está expuesto a la vista de todo el mundo y todo el mundo puede verificarlo, encontrar los errores...  e incluso corregirlos. Antes de instalarlo y usarlo es posible analizar el código y comprobar qué hace. Hay herramientas libres y gratuitas para securizar sistemas y para comprobar su seguridad. Es, en definitiva, fruto de un trabajo colectivo y colaborativo, lo que le confiere mayor calidad...".

La otra responde: "No hagas caso. El Software Libre es fruto de un proceso de desarrollo descentralizado, abierto... y, las más de las veces, desorganizado. Un proceso y una organización tan complejos que, inevitablemente, redundará en errores y en problemas de coordinación. Más aún, al ser públicamente revisable, los ciberdelincuentes pueden encontrar más fácilmente las vulnerabilidades y explotarlas sin avisar a la comunidad al respecto. Esas herramientas libres que se pueden usar para probar la seguridad de los sistemas pueden ser utilizadas por los ciberdelincuentes para atacarlos...".

Que cada cual decida quién dice qué. Yo, en cualquier caso, sigo en medio de esta discusión y creo que ambos tienen su punto de razón. Pero también que ninguno de estos argumentos ayuda a responder la pregunta original: ¿es beneficioso o perjudicial para la seguridad?

Mi respuesta es un categórico... DEPENDE. La pregunta tiene truco. Es como si se preguntara "¿Es un bisturí beneficioso o perjudicial para la salud de los pacientes?". Pues... dependerá de cómo se use. Y también de quién lo use, que creo que Jack el Destripador no lo manejaba de buena fe en sus fechorías. Con el Software Libre pasa lo mismo. Como norma general, el concepto en sí es beneficioso pero se puede hacer mal uso de él, ya sea de forma intencionada o no. Porque siempre que se toma una decisión se está corriendo, a sabiendas o no, unos riesgos y en ser conscientes de ellos, y en saber evitarlos, puede estar la clave del éxito.

Fácil de decir, difícil de llevar a cabo. Porque, igual que los vicios suelen camuflarse como virtudes, los riesgos simulan muchas veces ser una oportunidad. Un ejemplo viene dado por lo que he terminado llamando "la trampa del elemento facilitador".

Aunque ya esté más que dicho, Software Libre no es lo mismo que Software Gratuito. Pero con demasiada frecuencia se opta por determinado software libre porque instalarlo y usarlo no supone un coste. Pongámonos en la piel del responsbale de Informática de una pequeña organización. Debido a la crisis, no dispone de personal ni medios técnicos suficientes para sacar adelante su trabajo. Y cada vez le exigen más servicios. Que si una intranet, que si una página web institucional, que si un servicio de correo electrónico y webmail, que si un sistema colaborativo-participativo,... todo ello sin olvidarse de la ofimática, los equipos averiados, la gestión de cuentas del sistema, las redes de comunicaciones, el desarrollo y mantenimiento de programas, etc.

A la vez, en estos tiempos de crisis que corren, los presupuestos asignados a todos estos proyectos son cada vez más escasos. Son días de "hacer más con menos".

Para esta persona, el Software Libre es un elemento habilitante. No dispone de dinero para comprar esas soluciones propietarias que vienen acompañadas de costosas licencias de uso y que son difíciles de adaptar a sus necesidades. Ni de los recursos necesarios para desarrollar las suyas propias. Y, en cualquier caso... ¿para qué, si ya hay herramientas gratuitas, soportadas por una Comunidad en constante actividad? Lo que le interesa no es analizar el código fuente (y, si le interesara, no tendría tiempo), sino que puede utilizar el producto de forma gratuita y sin restricciones de uso. Si no fuera por el Software Libre, los proyectos que tiene por delante no podrían ser hechos realidad.

Hasta aquí, todo bien. Pero... ¿qué ocurre cuando se abordan más proyectos de los que se es capaz de gestionar?

Trasladémonos unos años en el futuro y veamos qué pudo ocurrir con aquellas herramientas. Como era gratis, se instalaron numerosos nuevos sistemas. Como eran útiles, se pidieron nuevos servicios. Pero la gestión de los mismos siguió en manos del mismo reducido equipo de técnicos. La Dirección, que no entendía demasiado de Nuevas Tecnologías ni conocía realmente lo que es el Software Libre, no se implicaba en estos temas. Sólo quería ver resultados.

Era demasiado trabajo. Muchos sistemas se quedaron sin actualizar. Quizá porque no se había establecido quién y cuándo debía hacerlo, quizá por falta de tiempo, quizá porque no se deseaba correr el riesgo de que algo crítico dejara de funcionar.

Gestionar un sitio colaborativo-participativo tampoco era una tarea fácil. Nadie quería dedicarse a monitorizar y controlar las creaciones de cuentas de usuario. A nadie le sobraba tanto tiempo. De modo que se permitió que la gente se diera de alta a través de un formulario en una página web. Al fin y al cabo, es algo a lo que estamos acostumbrados en otros servicios.

Y, mientras tanto, la idea de que "esto anda por sí solo" iba instalándose en la cultura del día a día.

Como resultado, por un lado, se disponía de versiones obsoletas de programas que presentaban problemas de seguridad conocidos y reconocidos públicamente. Vulnerabilidades que los hacían fruto fácil de los ciberdelincuentes. Por otro, los sistemas participativos se poblaron con cuentas creadas para publicar mensajes y comentarios con SPAM: anuncios de falsificaciones de productos de marca, medicamentos vendidos de forma ilegal, descargas de software pirata, pornografía,...

Esos sistemas que hasta poco antes habían servido a los intereses de la organización ya no estaban bajo su control. Visitarlos se convertía no sólo en una experiencia molesta, sino también en un riesgo de ser infectado por virus y otros tipos de software malicioso.

La causa de este problema no fue el Software Libre, sino la gestión que se hizo de él. Una gestión que se basó en que era gratuito y no en que fuera libre. En que se pensó que, si no cuesta nada... ¿por qué no hacerlo? En que se utilizó, no ya como elemento habilitante, sino como elemento facilitador que hizo posible tomar a la ligera unas decisiones que debarían haber sido abordadas desde un punto de vista estratégico. En que se confundió precio con valor y no se valoró ni se prestó suficiente atención a aquello que parecía no tener coste alguno. En que no se pusieron suficientes recursos organizativos al servicio del proyecto.

Posiblemente las aplicaciones siempre tendrán problemas de seguridad. El software, ya sea Libre o Propietario, es algo demasiado complejo como para que no surjan fallos. Y habrá quien los busque e intente aprovecharlos. Pero hay otros factores que afectan tanto o más a la Seguridad de la Información que el software. Y entre ellos están, claramente, los aspectos organizativos: cosas como quién realiza cada función, qué normas hay que cumplir, qué controles se deben realizar, qué medios se ponen al servicio de cada proyecto, cómo se forma y conciencia al personal, qué horizonte temporal y qué espectativas hay para cada sistema, cómo se gestiona la puesta en marcha, el mantenimiento, la gestión y la retirada del servicio de las aplicaciones, cómo se gestionan los incidentes de seguridad, etc.

No, las cosas no andan por sí solas. Deben tener una razón de ser. Si no se cubren las necesidades organizativas y de planificación, poco importará que el Software sea Libre o Propietario.

La principal diferencia entre usar uno u otro posiblemente radicará no en si se tiene éxito o se fracasa, sino en las herramientas utilizadas para fracasar.

El nombre del blog

Que nadie crea que elegir el tema con el que se va a romper el hielo en un blog es cosa sencilla. Hay que buscar algo que refleje lo que el blog va a ser y que a la vez atraiga a la audiencia.

Que de espantarla ya se ocuparán los siguientes posts.

Y hablar de cosas técnicas sin aburrir no es cosa vana. Espero que en este caso me baste con explicar de dónde saqué ese título tan raro.

"HTTP 418 - I'm a teapot" ("HTTP 418 - Soy una tetera") es un mensaje de error para el protocolo HTTP. Algo similar al "403 Forbidden" o al "404 Not Found". Sólo que no tan ampliamente implantado como éstos. De hecho, creo que casi ningún servidor HTTP lo utiliza.

La especificación de esta respuesta viene dada en el punto 2.3.2 del RFC 2324, que puede consultarse en http://tools.ietf.org/html/rfc2324 "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)". Este RFC describe un protocolo para controlar, monitorizar y diagnosticar las máquinas de hacer café y describe el error en los siguientes términos:

'Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout'

O, traducido:

'Cualquier intento de hacer café con una tetera deberá resultar en el código de error "418 I'm a teapot". El cuerpo de la entidad resultante PUEDE ser corto y espeso.'

Y, sí, como ya habrá adivinado alguien, hay gato encerrado. El RFC existe y se publicó en 1998. Más concretamente, el 1 de abril de dicho año. Fecha que, es tradición, se suele dedicar a gastar bromas en muchos países.

Costumbre a la que es habitual que se apunte la IETF con cosas como ésta. Que, quién sabe, quizá alguna vez se utilice para algo...

Saludos,