«Saludos Profesor Falken, ¿le apetece una partidita de ajedrez?»

Muchos de los lectores de este blog recordarán esta mítica frase de la película Juegos de Guerra, película de culto para todos los apasionados de las nuevas tecnologías. Fue en esta película, siendo apenas un niño, en la que oí por primera vez el término PUERTA TRASERA, cuando los dos programadores amigos del protagonista le desvelan que suelen ocultar en el código puertas traseras para poder acceder a los sistemas posteriormente a su entrega.

Evidentemente, la posibilidad de que software que controla infraestructuras tan críticas como el lanzamiento de misiles pueda contener puertas traseras es aterradora, y más aún si el acceso está protegido por una contraseña como “Joshua” (¿y por qué no “patata”? Falken, te lo has currado…). Lamentablemente el riesgo existe, ya que los programadores siguen teniendo la costumbre de dejarse algún tipo de acceso oculto que queda fuera del control de los administradores de sistema que les permita entrar en caso de necesidad.

Desde hace unos meses se están publicando una serie de vulnerabilidades que afectan a los navegadores web más utilizados, Internet Explorer, Firefox, etc., convirtiéndose en un vector de ataque nuevo de gran peligrosidad para cualquier usuario u organización. En el siguiente video pueden ver un ejemplo donde se explota una vulnerabilidad que afecta a Internet Explorer y Adobe Acrobat Reader:

En su página de preguntas frecuentes, el CNI nos ilustra acerca de la diferencia entre información e inteligencia:

«El término información debe diferenciarse del de inteligencia. Información equivale a noticia de un hecho en su sentido más amplio. El concepto información debe entenderse, por tanto, como el elemento de partida para la elaboración de inteligencia, considerada ésta como el resultado de valorar, analizar, integrar e interpretar la información.»

Actualización (a 5 de octubre): casualmente (o no), ni el enlace original ni la versión cacheada por Google funcionan ya… ¡Pero no todo está perdido!

Actualización (a 31 de octubre): Ahora sí, todo está ya perdido.

(Después de algún tiempo de ausencia, y aprovechando que está de vacaciones, José Selvi nos trae la segunda parte de “Bichos et al” que tuvo su primera parte en una fecha tan lejana como el 13 de junio.)

En la anterior entrega de esta serie de artículos relacionados con el software malicioso hablabamos de las dificultades que tenían los sistemas antivirus para detectar software malicioso desconocido, es decir, aquel sobre el cual no han podido trabajar y por tanto extraer las firmas adecuadas para su detección. Para solventar estas deficiencias, comentábamos que los desarrolladores de sistemas antivirus dotaban a sus producto de capacidades heurísticas de detección, con el fin de identificar virus desconocidos a partir de partes de su código o de su comportamiento.

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.

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.

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.

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:

Siendo éstos los tiempos de la Web 2.0, es muy habitual que una empresa ofrezca servicios a través de aplicaciones Web; éstas se convierten en la interfaz perfecta para que todo el mundo desde cualquier lugar acceda a información que muy probablemente se almacena en bases de datos. Esta entrada (y otras que le seguirán) viene a mostrar uno de los ataques más habituales hoy en día en este tipo de aplicaciones: el ataque de inyección SQL, por el que adquiere especial importancia el tratamiento de la información que fluye entre el aplicativo visible al usuario que la muestra (lo que podríamos llamar el frontend) y la base de datos que la almacena y gestiona (lo que vendría a ser el backend).

Dejando los detalles técnicos para más adelante, este ataque se basa 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, que al no ser filtradas correctamente por el aplicativo web pueden tener efectos indeseados, como proporcionar información sobre el sistema, la estructura de la BD, o incluso acceso o borrado de los datos almacenados. Una variante muy interesante de este tipo de ataques es el “Blind SQL Injection“, o ataque a ciegas por inyección SQL, que aprovecha el resultado obtenido tras lanzar consultas que emiten páginas de error no tratadas por el desarrollador de la aplicación.

Para empezar bien la semana, ayer lunes nos “desayunamos” con varias noticias relacionadas con la seguridad. La primera de ellas, la desmantelación de una red internacional de piratería de software dirigida desde Valencia (podemos ver la noticia en Levante El Mercantil Valenciano). Al parecer, ha caído una banda que se dedicaba a distribuir CDs “todo en uno”. Una buena noticia, pero no tan buena como la siguiente. Sigan leyendo.

Al mediodía, los periódicos nacionales nos informaban de la detención de “El Solitario”, el atracador más buscado de España, con varios asesinatos y multitud de robos a sus espaldas. Otra buena noticia relacionada con la seguridad, y es que no sólo trabajamos contra hackers, crackers, virus y similares, sino que también nos preocupa la seguridad física —en especial cuando hay víctimas. A fin de cuentas, a una entidad bancaria le afecta tanto un ataque de phishing como un lazo libanés en un cajero, un descuidero o un atracador; obviamente mucho más el atracador cuando hay muertos o heridos de por medio. Otra buena noticia, y desde aquí nuestra enhorabuena a los que la han hecho posible.