miércoles, 26 de diciembre de 2012

Spam en Correos ¿desde GMail y usando cuentas comprometidas?

Esta mañana me he levantado y me he encontrado con varios correos sospechosos enviados, al parecer, por gente a la que conozco. Todos ellos con correo de GMail.

Los correos sólo tienen un enlace a una página. Los servidores varían, pero el nombre de la página sí que es el mismo: google.html

Al comentar el tema con uno de los remitentes, éste me ha indicado que todas las personas de su libreta de direcciones parecen haber recibido los mensajitos de marras. Además, añadió, algunos mensajes habían sido enviados a una hora en la que ni su ordenador ni su teléfono móvil estaban encendidos.

Sospechoso. Tiene pinta de que alguien se ha hecho con un montón de cuentas de correo en GMail, quizá aprovechándose de contraseñas débiles, y las está utilizando para enviar SPAM.

Además, parece que los sitios web a los que dirigen los enlaces han sido comprometidos por algún ciberdelincuente aprovechando alguna brecha en su seguridad. De modo que a saber qué contenidos les han podido colar...

La página a la que dirige el enlace del correo contiene el texto:

You are here because one of your friends
have invited you.
Page loading, please wait....

E inmediatamente redirige al usuario a al dirección:

http://newsmarketnextgenonline5.com/?12/2

Que nadie la visite, que ya sabéis de donde la he sacado. El dominio en cuestión ha sido creado el 21 de diciembre de 2012 (hace cinco días en el momento en que escribo esto) y la persona que lo registró dice estar ubicada en Auckland (Nueva Zelanda).  La información puede consultarse en
http://dns.robtex.com/newsmarketnextgenonline5.com.html#whois


El sitio web se comporta de forma sospechosa. Buscando páginas pertenecientes a él en Google, los resultados obtenidos son "raros":

 
Como puede verse, aparece la página en cuestión que, si se visita directamente (¡no lo hagas, por si acaso esto cambia!), redirige a Google. En realidad, a:
http://www.google.com/?12/2
 
... como si se estuviera tratando de clonar un sitio (en este caso, Google). Algo que a veces se hace con el objetivo de "robar" el posicionamiento web a un tercero.
 
Existen también los dominios newsmarketnextgenonline1.com, newsmarketnextgenonline2.com, newsmarketnextgenonline3.com y newsmarketnextgenonline4.com. Y también newsmarketnextgenonline6.com, etc. Y con resultados muy parecidos a los anteriores. Sin embargo, alguno hay diferente que haría pensar en "extrañas" ofertas de trabajo (mucho cuidadín con ellas).
 
 
Lo dicho: si recibís estos correos, ni caso. Nada de hacer clic en el enlace. Y si os dicen que se enviaron desde vuestra cuenta, por si acaso, comenzad por cambiar la contraseña.
 
Saludos.

martes, 11 de diciembre de 2012

Antivirus y Android. Doce razones (1 de 3)


******************************************
Antivirus y Android. Doce razones (1 de 3)
Antivirus y Android. Doce razones (2 de 3)
Antivirus y Android. Doce razones (3 de 3)
******************************************

Las sugerencias de Google son cosa curiosa y digna de atención. Una que me llamó hace poco la atención es la siguiente:


Sugerencia

Escribo "android antivirus " y, tras el último espacio,... Google me sugiere en cuarto lugar la palabra "necesario".

Con ello se pone de manifiesto que hay una preocupación generalizada sobre este tema. Miles, quizá millones, de personas se preguntan si es necesario instalar un antivirus en su dispositivo Android. Y no son pocos quienes dan su opinión sobre el tema y les dan consejo. Consejos que, aunque se les presuponga la buena voluntad, no siempre me parecen excesivamente afortunados. En particular, me preocupan los artículos, posts y comentarios en que pueden leerse cosas como:

- "Pienso que si descargas apps confiables o navegas sitios seguros, no habría problemas. Yo no uso !"

- "yo no uso antivirus en mi SII, bajo las aplicaciones del Market y las pagas, las compro. No he tenido ningún problema"

- "Controlar las aplicaciones maliciosas es muy sencillo, solamente vigilá de dónde instalás las cosas y qué permisos les das"

- "Eso es lo fuerte. Te habrá chupado lo que no te puedes imaginar en recursos y batería, para nada. Por eso os repetimos una y otra vez, NO hace falta un “antivirus”"

- "Mil veces preguntad y mil veces contestado: no es necesario. Android = Linux = no virus"

- "Si tu smartphone necesita antivirus es que has elegido el sistema equivocado"

- "para lo unico que sirve el antivirus es para relentizar el movil"

- "Los usuarios normales que dependen solo de Android Market (Google Play) para bajar aplicaciones no creo que se vean afectados. Somos mas bien los usuarios Root, que instalamos aplicaciones de internet y markets alternativas los que tendríamos que preocuparnos un poco"


Desde luego, me preocupa. Porque habrá muchas personas que se dejen guiar por estos consejos, sin cuestionarlos previamente, a la hora de tomar su decisión.

Cierto que los antivirus pueden ralentizar el sistema y consumir bastante batería. Y el problema puede ser especialmente serio con los dispositivos "low cost" y de baja gama que es de esperar que incrementen en el futuro su couta de mercado. Siempre que puedo, aprovecho para señalar que este tipo de productos me produce cierta inquietud: si las prestaciones no permiten tener una protección antivirus adecuada o si no es posible actualizar la versión del sistema operativo porque el hardware no lo soporta... casi habremos perdido la partida de la seguridad.

Pero hay razones muy sólidas para utilizar antivirus. Incluso en Android. Vayamos por partes.

1.- Los ciberdelincuentes existen.
Una de las cosas que me llamó la atención es que muchas veces parece que el asunto sea un problema entre el usuario y su teléfono o su tablet (o lo que sea). Si lo tratas bien, no pasa nada. Pero hay más agentes involucrados. Hay mala gente que quiere atacar cuantos equipos se conectan a Internet. No porque les divierta, sino porque con ello consiguen dinero.

Hay spam porque alguien paga por anunciarse. Hay robo de cuentas de correo y perfiles en redes sociales porque puedan venderse. Hay timos porque siempre alguien cae.

En definitiva, si se puede obtener ingresos infectando o atacando un equipo con Android, alguien lo intentará.


2.- Cuando usas Android, los riesgos existen.
Es curiosa la ecuación
Android = Linux = no virus

... un mensaje incorrecto por tres razones. La primera es que los virus son sólo una especie dentro del ecosistema del software malicioso. Hace tiempo que las soluciones antivirus ampliaron su ámbito de funciones y tratan de defender a sus usuarios de otros tipos de aplicaciones (y de cosas que no son aplicaciones) no deseadas, como caballos de Troya, spyware, puertas traseras, etc. Pero, bueno, si es que se hace por simplificar las cosas, acepto "virus" como animal de compañía.

La segunda, que sí que hay virus (y otros bichos) para Linux. Linux, como todo software complejo, tiene sus problemas de seguridad. Obviamente, los que se van conociendo suelen ser solucionados en versiones posteriores y quedar resueltos con las actualizaciones pero... siempre aparecerán otros nuevos. Por no hablar de las instalaciones desactualizadas. No hay sistemas invulnerables.

Es cierto que hay menos malware para Linux que para Windows, pero también hay muchos menos usuarios de Linux que de Windows. Y, para unos ciberdelincuentes que se mueven por dinero, siempre es más rentable un malware que valga para la mayor parte de la gente que uno que sólo pueda afectar a unos cuantos. Siempre se dedicará a lo que más beneficios pueda proporcionarle.

Y este último razonamiento puede servir también para marcar la diferencia entre Android y Linux. Android sí es un sistema operativo que, en su ámbito de aplicación, tiene un uso mayoritario. Sí es objetivo preferente para los ciberdelincuentes. Sí que hay un amplio mercado negro que explotar y, por lo tanto, muchos recursos invertidos en determinar sus fallos de seguridad.


******************************************
Antivirus y Android. Doce razones (1 de 3)
Antivirus y Android. Doce razones (2 de 3)
Antivirus y Android. Doce razones (3 de 3)
******************************************

Antivirus y Android. Doce razones (2 de 3)

******************************************
Antivirus y Android. Doce razones (1 de 3)
Antivirus y Android. Doce razones (2 de 3)
Antivirus y Android. Doce razones (3 de 3)
******************************************


3.- Aún cuando no instales nada, el riesgo de que te ejecuten código existe
El malware para Android existe... y no es cosa nueva. Por ejemplo, ya en 2008 se notificaba un serio problema de seguridad del que puede leerse en:
http://securityevaluators.com/content/case-studies/android/

Cito unas cuantas líneas:

-----------------
A user of an Android phone who uses the web browser to surf the internet may be exploited if they visit a malicious page. Upon visiting the malicious site, the attacker can run any code they wish with the privileges of the web browser application. We have a very reliable exploit for this issue for demonstration purposes. This exploit will not be released until a fix is available.

The Android security architecture is very well constructed and the impact of this attack is somewhat limited by it. A successful attacker will have access to any information the browser may use, such as cookies used for accessing sites, information put into web application form fields, saved passwords, etc. They may also change the way the browser works, tricking the user into entering sensitive information. However, they can not control other, unrelated aspects of the phone, such as dialing the phone directly.
-----------------
Que, traducido al español, quedaría algo como:
-----------------
Un usuario de un teléfono Android que utilice el navegador web para visitar páginas en Internet puede sufrir las consecuencias del ataque si visita una página maliciosa. Tras visitar el sitio malicioso, el atacante podrá ejecutar cualquier código que desee con los privilegios con que corra el navegador. Disponemos de un exploit muy fiable para este problema con propósitos de demostraciones. Este exploit no será publicado hasta que el problema esté solucionado.

La arquitectura de seguridad de Android está muy bien construida y el impacto del ataque queda limitado en parte por ello. Un atacante que consiga su objetivo tendrá acceso a cualquier información que el navegador pueda usar, tal como cookies para el acceso a sitios, información utilizada para rellenar campos de formularios, constraseñas guardadas, etc. También podría cambiar la forma en que el navegador trabaja, engañando al usuario para que introduzca información sensible. En todo caso, no controlaría otros elementos del teléfono tales como la marcación de número de teléfono directamente
-----------------

Un sistema con Android no tiene sólo el sistema operativo. También están las aplicaciones instaladas. Aunque todas ellas sean conocidas y obtenidas de fuentes fiables, basta con que una de ellas presente una vulnerabilidad.

Cierto que esto ocurrió ya hace años y que el sistema operativo ha mejorado. Pero los ciberdelincuentes también han ido desarrollando y aprendiendo nuevos "trucos".



4.- La elevación de privilegios existe
Muchas veces, cuando se habla de la severidad y las repercusiones de una vulnerabilidad se recomienda que los programas se ejecuten con los privilegios mínimos imprescindibles. Ciertamente, lo contrario sería una imprudencia. En el caso anterior, si el navegador hubiera corrido con privilegios de root, o tuviera acceso directo a la marcación de números, la cosa habría sido peor.

Pero no es suficiente. Hay que contar siempre con eso que se llama "elevación de privilegios". Hay ocasiones en que, aprovechando un fallo del software o incluso engañando al usuario, es posible conseguir el acceso con una cuenta distinta o unos privilegios superiores a aquellos con la que inicialmente se tenían. Desde luego, no siempre es fácil ni siempre se sabrá como hacerlo... por ahora, pero quizá mañana sí.

Y en el mundo de los teléfonos... ¿qué es el rooteo?


5.- Los usuarios arriesgados existen
Efectivamente, los hay. Y es de desear que sean conscientes de los riesgos que corren. Desde luego, ser root permite controlar mejor su dispositivo pero también puede incrementar el impacto de cualquier incidente de seguridad. Utilizar markets alternativos proporciona mayor libertad para instalar aplicaciones, pero supone depositar en ellos una confianza que, quizá, ni siquiera deberíamos tener en los más "oficiales"...

Cuanto más elementos se añaden al sistema, más complejo se vuelve. Más se escapa a nuestro control lo que hace.


6.- Los programas engañosos existen
Los markets, al menos los oficiales, tratan de detectarlos y de eliminarlos, pero existen programas que simulan ser una aplicación útil o un juego divertido y, mientras tanto, hacen cosas que no debieran. Y a veces tardan demasiado en ser descubiertos.


Para muestras pueden servir los artículos
http://www.pcmag.com/article2/0,2817,2411163,00.asp New Android Trojan Found in Google Play y
http://threatpost.com/en_us/blogs/new-trojan-app-spreading-app-store-and-google-play-070512 New Trojan Spreading On App Store and Google Play , ambos bastante recientes.

En definitiva, no hace falta que el usuario sea temerario. Sólo que lo engañen.


7.- Las aplicaciones maliciosas que se descargan sin que tú lo sepas existen
... y en 2012 ha habido ejemplos de ello. Como el que se relata en
http://www.pcworld.com.mx/Articulos/22916.htm
El troyano NotCompatible para Android: Lo que tienes que saber
Basta con visitar una página maliciosa para que el programa se descargue. Llegado el momento, el sistema indicará al usuario que dispone de una aplicación lista para instalar y le preguntará si desea hacerlo. Obviamente el nombre de la aplicación no será "el virus malvado" sino algo que suene más inocente, o incluso beneficioso, como "actualización de seguridad". Algo que invite a decir que sí.
Para que la instalación se realice, es necesario que el sistema acepte aplicaciones desde orígenes de software desconocidos. Pero eso es algo no poco frecuente...


******************************************
Antivirus y Android. Doce razones (1 de 3)
Antivirus y Android. Doce razones (2 de 3)
Antivirus y Android. Doce razones (3 de 3)
******************************************

Antivirus y Android. Doce razones (3 de 3)

******************************************
Antivirus y Android. Doce razones (1 de 3)
Antivirus y Android. Doce razones (2 de 3)
Antivirus y Android. Doce razones (3 de 3)
******************************************
 
8.- Las páginas maliciosas en sitios legítimos existen
Si alguien piensa que para protegerse de este tipo de cosas basta con no visitar páginas "raras", se equivoca.

Aún resuenan en los medios de comunicacióna algunos "defaces" memorables realizados por grupos de hacktivistas a sitios webs gubernamentales y de grandes organizaciones. Historias de sitios que tenían una vulnerabilidad que permitía modificar sus contenidos y hacktivistas que la encontraron. Situaciones que en muchas ocasiones se comentan entre chanzas

Pero... ¿qué ocurre cuando un ciberdelincuente, cuyo objetivo es el dinero, encuentra esta misma vulnerabilidad? En muchas ocasiones, la aprovechará para incluir en las páginas elementos ocultos que traten de infectar a los visitantes. No hace falta que el sitio web sea malicioso. Sólo que esté controlado por alguien que sí lo sea.



9.- El daño a la sociedad existe
En un mundo tan interconectado como éste en que nos movemos, ya van quedando pocas "islas" de seguridad. Es algo de lo que no se habla con la profundidad que el tema merece. Revisitando el ejemplo de los sitios web con vulnerabilidades: ¿son conscientes los usuarios de que esos fallos de seguridad no sólo afectan al sitio web, de que ellos también pueden ser víctimas al visitarlos? ¿lo son los administradores y propietarios del sitio? ¿se preocupan unos y otros? ¿hasta qué punto se preocupan o se deberían preocupar y ocupar los gobiernos? ¿qué penalización debería tener alguien que mantiene una web insegura?

Quizá leyendo el párrafo anterior alguien piense en imponer sanciones a quienes actúen de forma negligente en materia de seguridad. Pero el problema no sólo es de los sitios web. Quien tiene un ordenador infectado por un troyano en casa ya no es su dueño. Al menos, no completamente. Los ciberdelincuentes que crearon el malware pueden darle órdenes y hacerle enviar SPAM. Mensajes que quizá se utilicen para estafar a alguien. O atacar los sistemas de una organización para dejarlos fuera de servicio. O realizar parte de las tareas necesarias para descifrar una contraseña. ¿Qué habría que hacer con quienes no ciudan la seguridad de sus equipos? ¿dónde habría que marcar la línea que separa negligencia de indefensión?

Lo único que tengo claro es que, mientras yo pensaba y escribía esto, unos cuantos equipos habrán caído bajo el control de algún ciberdelincuente en algún lugar del mundo.


10.- El daño para las organizaciones existe
En estos tiempos del Bring Your Own Device y la generalizción de los dispositivos móviles y portables, las organizaciones no pueden resistir la tentación de aprovechar las nuevas posibilidades que la tecnología ofrece. Pero no siempre toman las medidas de seguridad oportunas.

Un terminal Android puede estar conectado, por ejemplo, a dos redes distintas en un entorno corporativo. Por un lado, a través de la red de telefonía móvil, a Internet y, por otro, a través de conexiones WiFi, a la red de un centro de trabajo. En caso de estar infectado con malware, el atacante podría utilizarlo para enrutar tráfico entre ambas redes, consiguiendo acceso a equipos y recursos internos de la organización.

Y cuando se trabaja con clientes o con otras organizaciones la cosa puede ser aún peor. Por un lado, si llega a saberse que se ha producido una infección, por la mala imagen que se pueda causar y la confianza que pueda perderse. Por otro, si no llega a descubrirse, por los efectos que puede llegar a tener...



11.- El riesgo para otros sistemas operativos existe
Android no crea un ecosistema cerrado. Todo lo contrario: se relaciona con equipos con otros sistemas operativos, como Windows o Linux. ¿Qué ocurre cuando una tablet o un teléfono pueden conectarse a un PC mediante un cable USB? ¿Cuando pueden utilizados como dispositivos de almacenamiento masivo, como unidades de disco, tal y como se podría hacer con un pendrive?

El equipo Android podría contener ficheros, quizá descargados sin ser conscientes de ello, que, sin ser nocivos para el propio Android, sí lo sean para el sistema operativo al que se conectan. Por ejemplo, virus creados para Windows.



12.- Además de tables y smartphones, otros equipos con Android existen
Ya se empiezan a ver a buen precio los Android-TV, pequeños dispositivos con Android diseñados para conectarlos a la tele y convertirlas en Smart-TVs. E incluso las propias televisiones con Android. El mercado está abierto y los precios son lo suficientemente atractivos como para esperar que el número de dispositivos con Android y sus posibles aplicaciones crezcan rápidamente en un futuro próximo. Siempre que no lo consigan antes otros sistemas operativos alternativos, claro.

Estos dispositivos contendrán o podrán acceder cada vez a más y más información sobre nosotros. Sobre nuestros gustos. Sobre nuestro consumo. Sobre nuestras relaciones sociales. Sobre nuestro trabajo. Todo ello en un entorno interconectado en el que el fallo de un elemento puede afectar al resto. En que un equipo controlado por un ciberdelincuente puede comprometer la información contenida en los demás.



Ya van doce razones para utilizar antivirus en Android. Suficientes. Por lo menos, para mí. Ahora habría que buscar uno bueno...


 

******************************************
Antivirus y Android. Doce razones (1 de 3)
Antivirus y Android. Doce razones (2 de 3)
Antivirus y Android. Doce razones (3 de 3)
******************************************

martes, 4 de diciembre de 2012

Dos XSS más (cerradas) en RoundCube

Hoy, 4-12-2012, los desarrolladores de RoundCube han cerrado y dado por resuelto un ticket que abrí ayer mismo y en el que les comunicaba dos nuevas vulnerabilidades de tipo XSS.

Los detalles figuran en el ticket
http://trac.roundcube.net/ticket/1488850

Y, sobre todo, en el fichero adjunto al mismo, que contiene una prueba de concepto:
http://trac.roundcube.net/attachment/ticket/1488850/RoundCube2XSS.pdf

Básicamente, para potenciales víctimas que utilicen Internet Explorer, es posible ejecutar scripts en el contexto de la sesión actual de webmail mediante el uso de enlaces a URLs de tipo "vbscript:".

En el caso de Mozilla Firefox, un resultado similar puede obtenerse mediante URLs de tipo "data:". Este tipo de URLs permiten embeber en un documento HTML contenidos que de otro modo tendrían que ser obtenidos de fuentes externas como, por ejemplo, imágenes.

Para más detalles sobre las URL "data:" se puede leer el siguiente RFC:
http://www.ietf.org/rfc/rfc2397.txt

Mediante el uso de las mismas, es posible crear de forma dinámica, y seguidamente abrir,  un documento HTML con código JavaScript al seguir un enlace creado y diseñado para este fin.

Es de esperar que las próximas versiones de RoundCube no presenten ya estos problemas. Pero siempre habrá instalaciones que se queden sin actualizar. Y es más que probable que otras aplicaciones de webmail tengan fallos similares. Así que si administras un correo web, quizá sea conveniente que realices comprobaciones al respecto...

viernes, 30 de noviembre de 2012

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.

jueves, 29 de noviembre de 2012

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.

martes, 27 de noviembre de 2012

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,