To be or not to be… evil?

25 de septiembre de 2007 Por

google_tanga.jpgReconozco que soy “de la vieja escuela”, que me gusta “tocar papel” cuando tengo que revisar un informe o leer un documento mínimamente extenso (y tengo que reconocer que esto me provoca un conflicto con mi conciencia medioambiental, pero eso es otro tema…). Ese gusto por el papel hace que periódicamente —siguiendo la política de mesas limpias implantada en mi organización— tenga que hacer limpieza, y destruir adecuadamente la documentación obsoleta.

Revisando papeles, y teniendo reciente un “correo-sugerencia” que me recordaba que hacía tiempo que no escribía nada para el blog (N.d.E: “hacía tiempo” es una estimación algo optimista, teniendo en cuenta que la anterior aportación es del 25 de mayo) me descubrí a mi mismo ojeando una noticia en ElPais.com sobre el apasionante mundo de “los buscadores y los datos personales”. Y me dije: de hoy no pasa.

Tan sólo quiero lanzar al aire una serie de reflexiones:

1) Si uno visita el sitio www.google.es, tras buscar la política de privacidad de la web, la misma resulta ser realmente vaga (política que ha sido denunciada recientemente por Privacy International como una de las peores que se pueden encontrar por Internet), por ningún lado se le va a dar el derecho de información que exige la legislación sobre protección de datos personales, y tampoco he visto información que responda al cumplimiento de la LSSICE (es un dominio .es, ¿no?)

2) En 2006, según una nota de prensa [PDF] publicada por la AEPD (de la disponibilidad de cuyo servidor hablaremos en otra entrada), un portavoz de ésta comentaba en relación a Google que era una situación complicada, pero aseguraba que “los responsables del buscador saben que tienen que aplicar la legislación y lo tienen en la cabeza”. Recuerdo que es una nota de prensa de 2006.

3) Si uno busca en el Registro General de la AEPD tratamientos de datos personales cuyo responsable contenga la palabra “Google”, aparecen 9 tratamientos, pero ninguno corresponde a datos de navegación, clientes, usuarios, o información similar.

4) Curiosamente en el registro figuran tres tratamientos a nombre de Google Ireland Ltd., con sede en Dublín, y en el detalle de la inscripción de esos tratamientos consta que se hacen una transferencia internacional de datos a sí mismos (¿?).

5) Curiosamente también, la sede europea (que no oficina de venta, ver http://www.google.es/intl/es/corporate/address.html) de Google reside en Irlanda, país afectado por el cumplimiento de la Directiva 46/95 de la CEE. ¿Porque creen ustedes que nuestros datos de navegación residen exclusivamente en la sede central de Google en California?

6) Y no voy a entrar en la polémica de si Google Desktop Search es o no es spyware, o de si Google Maps vulnera la privacidad de las personas que pueden aparecen en sus fotos (tal y como muestra la imagen superior), o de si Gmail vulnera o no la privacidad de sus usuarios…

Repito: sólo son unas reflexiones escritas “sin pensar demasiado”. No soy abogado, y reconozco que el tema me supera pero… ¿a que da qué pensar?

Bien por la FIA

19 de septiembre de 2007 Por

Como probablemente muchos de ustedes saben, hay un buen follón montado en la Formula 1. Resumiendo, y ciñéndome a la versión “oficial”, ciertas personas del equipo McLaren estuvieron durante un tiempo recibiendo información confidencial de Ferrari. Después de muchas vueltas, eso desembocó en algo parecido a un juicio que tuvo lugar el pasado 13 de septiembre, que vino a denominarse “Extraordinary Meeting of the World Motor Sport Council“, y en el que los principales implicados en la trama del espionaje dieron sus versiones ante la FIA (Federation Internationale de l’Automobile, Federación Internacional de Automovilismo) y respondieron a preguntas de abogados de una y otra parte. Finalmente, el tema se resolvió con la exclusión de McLaren del campeonato de constructores del presente año y una multa de 100$ millones.

Hace unos días, dicha organización, responsable entre otras cosas del Mundial de Rallies y de la Formula 1, decidió que hoy miércoles se publicaría la transcripción de dicha reunión, algo que había generado bastante expectación por la sanción y por otras razones que no vienen al caso. La cuestión es que sobre las 12 p.m., la transcripción (de 115 páginas) se publicó, como estaba previsto, en la página web de la FIA, con diferentes partes del texto cubiertas de negro, conteniendo presumiblemente información confidencial sobre mecánicas de Ferrari y McLaren.

Poco después, dicha transcripción dejó de estar disponible, y volvió a estarlo unas horas más tarde, pero ahora los segmentos en negro estaban en blanco. Aunque todo esto les pueda parecer interesante, estarán pensando qué tiene que ver exactamente con la seguridad de la información.

Pues bien. Seleccionando el texto “oculto” de la transcripción original, copiándolo y pegándolo en el bloc de notas, se puede ver qué era exactamente eso que quería ocultar la FIA. Bien por ellos.

Ya tenemos antivirus… estamos salvados.

18 de septiembre de 2007 Por

El pasado sábado la versión electrónica del periódico local valenciano Levante EMV daba la noticia de que un virus había causado el caos en la Escuela Oficial de Idiomas de Valencia. Al parecer, y según el diario, éste «provocó que las citaciones con el mismo número se duplicaran e incluso se triplicaran en algún caso». No niego que, aún desconociendo la aplicación y el procedimiento de citación, me parece sumamente interesante que un virus pueda actuar de forma tan “inteligente” y llegue a ese nivel de interacción con los datos, pero dejando polémicas, suspicacias y sospechas aparte, la cuestión es que me da la sensación, y entramos en el terreno de la opinión personal, de que para el público en general, y no tan general, los virus suelen residir en un universo independiente al del concepto “puro” de seguridad.

Es decir, que mientras éste parece estar más relacionado con grandes corporaciones, con hackers y crackers, intrusiones, robo de información privilegiada, IDSs, análisis forense, cortafuegos o gestión de contraseñas, los virus, troyanos, gusanos, spam y demás fauna relacionada son una molestia perrmanente y casi necesaria, fácilmente solventable con un antivirus y algún programa de malware. Parece, como digo, que políticas, procedimientos, y todas aquellas medidas típicas de un entorno seguro, orientado a evitar —mitigar— los riesgos relacionados con la seguridad de la información, están “de más” cuando se trata de controlar a estos no siempre pequeños y nunca inofensivos “bichos”. Vamos, resumiendo, que en ese caso no son necesarias.

Desgraciadamente, las cosas no funcionan exactamente así. No sólo es mucho más probable sufrir una infección vírica masiva que sufrir una intrusión o un ataque DoS por alguna banda criminal de Europa del Este (por no salirme de los tópicos), sino que las consecuencias pueden ser igualmente fatales. Y es que aparte de un siempre necesario antivirus, actualizado periódicamente e inmune a las manipulaciones del usuario más molesto, son imprescindibles políticas que gestionen los privilegios de acceso a los recursos compartidos, el control de acceso a los dispositivos, la gestión de permisos y usuarios, las políticas de uso de soportes como USBs, CDs o DVDs,… Y como siempre, es necesaria la concienciación del usuario. Porque las fotos de la última convención no siempre son las fotos de la última convención: las cosas no son siempre lo que parecen aunque a menudo lo descubrimos un poco tarde.

Todo sea, al menos, por no ver aparecer por la puerta de la empresa a doscientas personas pidiendo matricularse en clase de mandarín, ¿no les parece?

¿Es el correo electrónico un medio de comunicación seguro…?

5 de septiembre de 2007 Por

mail.jpgLeía hace unas semanas una noticia que decía “La policía danesa detiene a un hombre por acceder a los correos electrónicos de Michael Rasmussen” y seguía “La policía danesa ha arrestado en Herning, en el oeste de Dinamarca, a un danés de 30 años por introducirse en el correo electrónico del ciclista Michael Rasmussen e intentar vender a un periódico la información que obtuvo”.

Esta noticia me ha hecho reflexionar sobre la seguridad general del correo electrónico que transita por el mundo y el negocio lucrativo que algunas mentes enfermizas pueden obtener por el hecho de fisgar en el correo ajeno.

Nuestros equipos de trabajo han analizado en bastantes ocasiones la seguridad del correo electrónico desde la óptica, por ejemplo, de la Ley Orgánica de Protección de Datos y de las medidas de seguridad que el Reglamento nos exige. ¿Podemos enviar información de carácter personal por el correo electrónico? ¿Cumple el correo electrónico las medidas básicas de seguridad para proteger la información que contiene? ¿Cómo podemos hacer uso del correo electrónico como canal de comunicación seguro? Las respuestas no son desde luego triviales para el gran público.

Pero el foco del análisis ha sido siempre distinto. Nos hemos enfrentado a infraestructuras corporativas de correo electrónico con servidores de correo, a evitar que el correo sea interceptado dentro y fuera de las organizaciones y a garantizar unas medidas de protección para determinado tipo de información que viaja en nuestros sobres electrónicos, pero, al menos yo, no me había planteado el interés que los correos electrónicos personales pueden llegar a tener en función de los dueños de las cuentas y, por tanto, la necesidad de que los que hospedan estas cuentas de correo ofrezcan a sus clientes servicios que garanticen la seguridad de sus comunicaciones.
[Read more…]

Pescando…

4 de septiembre de 2007 Por

Imagino que la mayoría de ustedes conocen el sistema de mensajería instantánea Microsoft MSN. Seguramente sabrán también que puede uno cambiar el nombre o “nick” con el que le “ven” los demás, que es posible “bloquear” a otros usuarios de manera que para ellos aparezcas a todos los efectos desconectado y no puedan hablar contigo, y que el MSN y la cuenta de correo de Hotmail comparten el identificador de usuario y la contraseña. Dicho esto, hace unas semanas, mi novia —que comprueba que no la estoy mirando cada vez que introduce su contraseña de correo, a pesar de que lo consulta desde mi portátil— me saludó una mañana con el siguiente mensaje como nombre:

“www.QuienTeAdmite.com < -- Fijate quien te elimino y quien te desadmitio en el MSN, enterate TODO"

Aunque ya había visto eso antes, en este caso indagué un poco y llegué a sitios web como www.quienteadmite.com o blockoo.com, aunque hay muchas más, en las que aseguran que proporcionando el usuario de Hotmail y la contraseña, muestran qué personas tienen “bloqueado” a tu usuario en el MSN. Pese a que el método de proporcionar tu usuario y contraseña puede considerarse cuanto menos sospechoso y nada recomendable, no voy a entrar a cuestionar hasta qué punto el sistema funciona o no. Cabe decir, no obstante, que incluso aunque funcionase, eso no elimina los riesgos de “regalar” libremente el acceso a tu correo personal.

Lo que me llama la atención es que a pesar de que las “víctimas” de este tipo de iniciativas son por lo general usuarios experimentados de Internet (menores de treinta años) que conocen o deberían conocer los —a menudo exagerados— “peligros” de este medio, acaban confiando en una página web sin ninguna garantía que les pide su usuario y contraseña de correo personal. Lo que en mi opinión demuestra que, teniendo en cuenta que en gran parte de las relaciones a través de MSN la amistad y la confianza tienen un papel importante (y que el hecho de que una persona bloquee a otra se considera una afrenta relativamente seria), sólo hay que buscar el reclamo adecuado para que cualquier persona, en cualquier momento, revele información personal a extraños o sitios web desconocidos.

No me sorprende, por tanto, que el phishing funcione, y como es habitual, aunque no voy a aconsejarles que como suele decirse, no se fíen ni de su padre, cuando se trate de asuntos privados —finanzas, correo privado, datos personales…—, desconfíen. Esa suele ser siempre una buena política.

Ataques de Inyección SQL (III)

3 de septiembre de 2007 Por

Si recuerdan, en la segunda y anterior parte de esta serie [ver primera entrada] acerca de ataques de Inyección SQL comenzamos a introducir las medidas de seguridad preventivas contra este tipo de amenazas, y dimos una serie de pautas básicas a seguir, como eran la utilización de funciones para la eliminación de carácteres de escape, el uso de consultas estáticas, o evitar el acceso a la base de datos con usuarios privilegiados. En esta tercera entrada, y antes de irme de vacaciones (sí, han leído bien), seguiré en esa línea, introduciendo herramientas para la realización de auditorías de código, que ayudan a evitar los problemas más comunes. Por supuesto, la habitual renuncia de responsabilidad “for educational purposes only” aplica.

Debe ser evidente, antes de pasar a las herramientas, que esto no pretende ser un listado exhaustivo, y que existen alternativas comerciales a todas ellas, pero pienso que las que les voy a indicar pueden ayudarles como punto de partida.

En primer lugar, destaca Sqlninja como detector de vulnerabilidades de Injección SQL en servidores basados en Microsoft SQL Server. Esta herramienta es capaz de lanzar diversos exploits que atacan directamente al gestor de base de datos demostrando el grado de seguridad y hasta qué punto puede quedar nuestro servicio comprometido. Es una herramienta muy completa y fácil de utilizar, y cuenta con menus que resultan bastante intuitivos.

Absinthe es otra aplicación de fácil manejo, y que cuenta con interfaz gráfica de usuario, que destaca por la sencillez y rapidez a la hora de parametrizar una auditoría. Admite auditorías sobre varios gestores de bases de datos, como pueden ser Postgres, MySQL, MS SQL, etc…

SQL Power Injector es otra aplicación completísima desarrollada con el lenguaje C# bajo la plataforma de desarrollo de .NET. La interfaz gráfica posibilita realizar una auditoría de forma rápida e intuitiva. Es válida para varios gestores de bases de datos.

Más que una aplicación, SQLIer puede considerarse un script que utiliza un ataque de tipo verdadero-falso para determinar usuario y contraseñas de las bases de datos. Es por tanto un script a nivel informativo, con el que se pueden determinar la fortaleza de las contraseñas utilizadas y el grado de defensa contra ataques de este tipo.

Por último, SQL Injection Pentesting TooL es otra utilidad con interfaz de usuario muy completa para la realización de auditorías. Aunque a diferencia de las anteriores en este caso no se dispone del código fuente de la aplicación, y únicamente se puede ejecutar bajo entornos Windows, su descarga es totalmente gratuita.

Como es habitual, desgraciadamente nada es perfecto y a pesar de las facilidades que estas herramientas introducen, será necesario auditar de forma manual todas las implicaciones que conlleva todo lo relacionado con la conexión, acceso y tratamiento de la base de datos. Por poner un ejemplo, en Java se deberían buscar todas las llamadas execute(), prepareStatement() y prepareCall(), y hacer una traza de las mismas. El uso combinado de estos dos tipos de auditorías, la realizada de forma manual y la automática a través de las aplicaciones mencionadas, nos ayudarán a filtrar todos aquellos “bugs” no tratados durante el proceso de codificación de la aplicación, obteniendo así una aplicación relativamente protegida frente a estos ataques de Inyección SQL.

Y de momento, esto es todo. Como suele decirse, to be continued…

Cuidado: cuando borra, no siempre borra

31 de agosto de 2007 Por

Si alguna vez piensa usted en sacar un dinerillo vendiendo ese ordenador, esa llave USB o ese disco duro cuya capacidad es ya irrisoria o que no le sirve de nada, acuérdese de borrar los datos que contiene, porque con toda probabilidad, aparte del teléfono de su suegra o de su ex, no querrá que sus correos personales, las fotos de su pareja o los teléfonos de sus amigos acaben en manos de un desconocido, ¿verdad?

Y le digo esto porque, aunque no sea usted el gobernador de Arkansas, estoy seguro de que se aprecia sus datos tanto como él. Ah, y por si hay alguna duda, cuando hablo de “borrar”, no quiero decir borrar. Quiero decir “hacer los datos irrecuperables”.

Visto en Kriptópolis.

(Buen fin de semana a todos)

Escuchas telefónicas made in USA

30 de agosto de 2007 Por

Aunque no pensaba actualizar hasta mañana al menos, y no acostumbro a poner nada en inglés, no me he podido resistir a esto, que describe el impresionante y complejo sistema de escuchas telefónicas montado por el FBI, basado en un informe de cerca de mil hojas hecho público gracias a la Freedom of Information Act (FOIA) y destinado a la Electronic Frontier Foundation (EFF). Les recomiendo que vayan al artículo de Wired, mucho más completo y realmente interesante:

The FBI has quietly built a sophisticated, point-and-click surveillance system that performs instant wiretaps on almost any communications device, according to nearly a thousand pages of restricted documents newly released under the Freedom of Information Act.

The surveillance system, called DCSNet, for Digital Collection System Network, connects FBI wiretapping rooms to switches controlled by traditional land-line operators, internet-telephony providers and cellular companies. It is far more intricately woven into the nation’s telecom infrastructure than observers suspected.

It’s a “comprehensive wiretap system that intercepts wire-line phones, cellular phones, SMS and push-to-talk systems,” says Steven Bellovin, a Columbia University computer science professor and longtime surveillance expert.

DCSNet is a suite of software that collects, sifts and stores phone numbers, phone calls and text messages. The system directly connects FBI wiretapping outposts around the country to a far-reaching private communications network.

Visto en el blog de Bruce Schneier.

Asimetrías en las transacciones digitales futuras

29 de agosto de 2007 Por

El pasado mes de junio se aprobó la Ley de acceso electrónico de los ciudadanos a los Servicios Públicos, en la que se establece que la Administración no es que sólo “pueda”, sino que “debe” ofrecer todos sus servicios de manera electrónica. Sin ninguna duda, esta ley acompaña de manera definitiva al DNI electronico, y a otras opciones de certificación digital como puede ser la ACCV. No hay ninguna duda de que todas estas iniciativas pueden mejorar en mucho los trámites de los ciudadanos, pero por otro lado abren una gran cantidad de incógnitas frente a las garantías que tienen los ciudadanos al realizar trámites de manera digital, entre las que queremos destacar la asimetría de las transacciones digitales en la presentación de la declaración de Hacienda.

Recientemente muchos contribuyentes han realizado su declaración de Hacienda de manera digital a través de Internet. El proceso de presentación telemático asociado tiene visos de ser bastante completo: los usuarios deben acreditarse para obtener su certificado digital (formado por una clave pública y una privada), y la clave privada es generada por el PC particular de cada uno, con lo que este certificado digital permite que el usuario “firme digitalmente” su declaración. Todo ello a traves de la Fábrica Nacional de Moneda y Timbre, una autoridad de certificación con en principio todas las garantías.

Hasta aquí, todo bien (en realidad, no esta bien “del todo” al ser un certificado software, pero la tecnología que le sucederá en breve como es el DNI digital, sí tiene características como para considerarse firma electrónica); el proceso en su conjunto parece que sigue técnicas en principio bastante robustas en cuanto a los aspectos de seguridad, tanto organizativa como técnicamente.

Ahora analicemos el proceso de presentación de la declaración: preparamos ésta con el programa PADRE y nos conectamos a la página web de Hacienda donde nos aparece un applet, mediante el cual firmamos digitalmente nuestra declaración, y puesto que la firma digital equivale a la firma manuscrita, esto constituye en última instancia el equivalente a la entrega de nuestra declaración firmada. Ahora sólo cabría esperar que Hacienda tambien nos firmara (o cuñara) nuestra declaración con la misma robustez como nosotros se la hemos firmado, mediante un documento firmado digitalmente por la Administración (por la aplicación) que justifique que hemos entregado nuestra declaración. No obstante, en su lugar lo unico que recibimos es un número de registro, no firmado digitalmente ni de ninguna manera: un simple número de serie.

Por ello la autentificación y firmado de la declaración se produce de una manera completamente asimétrica: mientras que el ciudadano se autentica con ciertas medidas criptográficas y de seguridad, el justificante que obtiene es técnicamente muy debil, y con evidentes riesgos sobre su validez en caso de problemas. Y esta es la principal razón de que año tras año no presente la declaración por Internet sino a través del banco, del que al menos recibo un documento cuñado por la oficina con el que demostrar que la he presentado en caso de presentarse problemas futuros, ya que este documento sellado es a mi entender bastante más robusto que un simple número.

Muchos de los lectores podrían pensar que el tema de la declaración no tiene al fin y al cabo demasiada importancia, y quizá tengan razón, ya que al fin y al cabo Hacienda también permite maneras poco robustas de aprobar borradores de declaración como puede ser a través de SMS o medios similares. Pero el problema reside en que es esta es la tecnología que viene, y esta es por tanto la asimetría con la que nos vamos a encontrar en los futuros desarrollos con firma digital, como por ejemplo el nuevo DNI; ¿se imaginan ustedes firmando un contrato con algun operador de Telecomunicaciones en el que el usuario firma el contrato digitalmente y el operador simplemente entrega una hoja para imprimir? No parece un procedimiento demasiado apropiado, ¿verdad?

A la vista de este tipo de problemas que van apareciendo, no cabe duda de que los usuarios tendremos que estar alerta ante las futuras transacciones basadas en firma digital, que seguro que con el nuevo DNI electrónico van a comenzar a surgir.

Ataques de Inyección SQL (II)

27 de agosto de 2007 Por

Antes del pertinente, necesario, deseado y siempre corto descanso veraniego, recordarán que estuvimos hablando de ataques de Inyección SQL, utilizados al parecer en los ataques a la delegación de Microsoft en el Reino Unido el mes de junio y a la página Web de la ONU hace unas semanas.

Como les dijimos literalmente aquella vez, los ataques de inyección SQL se basan en explotar la interacción con el usuario ofrecida por aplicaciones Web (formularios de petición de datos, por ejemplo), para hacer llegar a la base de datos consultas SQL manipuladas. Y las principales herramientas utilizadas para ello son los caracteres que dentro de SQL sirven para declarar cadenas de texto: las comillas simples (‘) y los caracteres que introducen comentarios en el código (––), igual que en cualquier código fuente. Pues bien, los atacantes suelen aprovechar este tipo de caracteres para incrustar código aleatorio y conseguir validar cualquier sentencia manipulada. Vamos a ver un ejemplo:

Sea la siguiente sentencia para mostrar el perfil de un determinado usuario en una página web:

SELECT * FROM users WHERE name = '"+ userName +"';

El atacante manipula la sentencia de esta manera…

SELECT * FROM users WHERE name = 'a' or 't'='t';

(En rojo y negritas, código inyectado por el atacante)

Mientras que la sentencia anterior debería mostrar las características de un único usuario, al incrustar el atacante un operador “or” con una condición que siempre es cierta, consigue que la sentencia sea cierta para todos los usuarios, devolviendo la base de datos por tanto todos los datos de la tabla users.

Como medida de seguridad, los distintos entornos de programación poseen ciertas funciones en las que se revisa estos tipos de entrada para evitar que lleguen a la base de datos. Por poner algunos ejemplos, en PHP por ejemplo existe la función mysql_real_escape_string para MySQL, en JAVA tenemos la función PreparedStatement, en Mono y C# de .NET se trata con las funciones SqlCommand (para Microsoft SQL Server) y OracleCommand (para gestores Oracle). De esta forma, si validamos tanto las entradas de primer orden como las de segundo, es decir, no sólo los posts, gets, cookies, sino también las que provienen de lectura de ficheros, bases de datos, etc… conseguimos filtrar instrucciones no deseadas, errores por tipos de datos, y manejo de tablas de la base de datos.

Como complemento de la seguridad en la aplicación, es recomendable generar las consultas de forma estática en la medida de lo posible, es decir, si predefinimos las consultas obligaremos al usuario de la aplicación únicamente a interactuar con los parámetros, por lo que no existe la posibilidad de que éste modifique las sentencias.

Hay muchas otras recomendaciones, como por ejemplo no acceder a la base de datos desde la aplicación con una cuenta de usuarios con privilegios de administrador, o hacer un uso restringido y controlado de los llamados “procedimientos almacenados”, pero de eso hablaremos en la tercera parte de esta serie.