Pero vayamos a la cuestión: ¿qué es el MAC, DAC y cuales son sus diferencias?

Discretionary Acces Control es una forma de acceso a recursos basada en los propietarios y grupos a los que pertenece un objeto. Se dice que es discrecional en el sentido de que un sujeto puede transmitir sus permisos a otro sujeto. La mayoría de sistemas Linux ahora mismo usan este tipo de acceso, estando los permisos orquestados por grupos y usuarios, pudiendo un usuario normal cambiar los permisos de los archivos que posee con el comando chmod.

Mandatory Acces Control en cambio se basa en políticas. Existen un conjunto de reglas de autorización (políticas) las cuales determinan si una operación sobre un objeto realizada por un sujeto esta o no permitida basándose en los atributos de ambos. En este caso, el Mandatory refleja el hecho de que las políticas están centralizadas y no pueden ser sobrescritas por un sujeto.

La diferencia, una vez descritas las dos políticas, salta a la vista. En DAC el acceso esta descentralizado, siendo el propietario de cada objeto el encargado de asignar los permisos de los diversos sujetos (grupos en el caso de unix) que accederán a ellas. En cambio con el MAC los objetos y los sujetos tan solo tienen atributos, pero son las políticas las que se encargan de autorizar o denegar una acción.

Como se ha comentado, en los entornos GNU/Linux lo habitual suele ser el sistema de control de acceso DAC, pero hay excepciones. Red Hat ha apostado fuerte por SELinux a partir de un desarrollo de la NSA en Diciembre del 2000 que fue aceptado dentro del kernel 2.6.0-test3, liberado en agosto del 2003, e implementado por primera vez dentro de RHEL 4. También Suse Linux quiso implementar un sistema MAC, y lo hizo a través de AppArmor, cuyo equipo de desarrollo mantuvo hasta el 2007. Su primera inclusión por defecto en Suse fue en SuSe Linux Enterpise Server 10.

Desde el punto de vista de la seguridad, MAC es más completo que DAC. MAC es un sistema centralizado, en el cual las decisiones de seguridad no recaen en el propietario de un objeto y es el sistema el que fuerza el cumplimiento de las políticas por encima de las decisiones de los sujetos, además de permitir una granularidad y control mayores. Pero, ¿si es más completo, porque no es el sistema más usado? Pues se podrían poner muchas razones, pero el hecho de que es algo relativamente nuevo en la informática (tanto SELinux como AppArmor son desarrollos posteriores a los años 90) junto con que es más complicado de configurar y mantener hace que aún no sea el sistema por defecto en todos los sistemas GNU/Linux, aunque ya se ha comentado que tanto Suse como Red Hat ya lo incluyen por defecto y muchas otras (Gentoo, Debian, Ubuntu) lo soportan de algún modo. En el “lado opuesto” Windows, desde su versión Windows Vista para usuarios y Windows 2008 para servidores también soporta MAC, pero dado mi profundo desconocimiento de este sistema, no he realizado referencia alguna.

Para futuras entradas intentare explicar el funcionamiento de SELinux y su configuración básica. Saludos, hasta la próxima, y pasen un buen fin de semana.

En el taller personalmente constaté que, salvo honrosas excepciones, muchas de las empresas estratégicas españolas todavía se encuentran en una fase digamos intermedia en cuanto a la implantación real de planes de continuidad de negocio. Todavía se confunden términos, y por ejemplo se establecen equivalencias entre planes de contingencia TIC y planes de continuidad de negocio (si miran la fotografía que acompaña este post estarán de acuerdo conmigo en que “eso” no tiene nada que ver con continuidad TIC). Sobre esto ya les hablé en otro post sobre la resiliencia de las organizaciones.

Se constató el consenso entre los participantes relativo a la necesidad de una mayor sensibilización por parte de los actores, de que falta regulación, y de que faltan estándares en los que basarse que sean realmente de aplicación a sectores tan dispares como el transporte por ferrocarril, la banca o la telefonía móvil. La sensibilidad existente en las IC privadas se basa en la protección del negocio más que en la protección del servicio, y no son aspectos que sean contemplados en las estrategias corporativas. Asimismo, quedó en evidencia la necesidad de que los planes de prueba de los planes de continuidad de negocio consistan en pruebas “de verdad”, y no en simulaciones controladas y poco realistas. También es cierto que la realización de ejercicios de crisis sectoriales realistas es verdaderamente compleja. ¿Deberían ser obligatorias? ¿Y entre sectores interdependientes? ¿Cómo coordinarlas?

Otro de los aspectos que se comentaron fue la necesidad de definir modelos de datos estándar y una interfaz segura para el necesario intercambio de información entre los cuadros de mando y control en la gestión de la continuidad de IC. Se abogó por seguir un modelo como el holandés, en el que el estado “facilita” y apoya y el sector privado lidera y actúa, aunque al final hubo que reconocer que no es un modelo fácilmente implantable en España. Donde surgieron las discrepancias fue a la hora de valorar cuál debería ser el papel del Estado en esta materia. Hubo acuerdo en que debía regular los mínimos exigibles, y en que debía conocer el estado real de la seguridad de las IC nacionales, pero hubo desacuerdo en si además debía revisar, auditar, exigir e incluso sancionar. Por último, se propuso que el Estado subvencionara o apoyara económicamente proyectos I+D+i que trabajaran en esta línea, ayudas quizás dirigidas a asociaciones sectoriales, y se apuntó la idea de que la Responsabilidad Social Corporativa debería ser un impulsor para que las empresas se subieran a este barco.

Además de los temas tratados en el taller, me gustaría añadir algunos otros asuntos vistos durante las dos interesantes jornadas, alguno de los cuales ya ha sido apuntado por José Rosell en el post que escribió sobre este encuentro.

En el apartado de curiosidades o cosas que me llamaron la atención (quizás por ser un neófito en el terreno militar), me llamó la atención la exposición del Teniente Coronel Néstor Ganuza, director de la Sección de Adiestramiento y Doctrina del Centro de Ciberdefensa Cooperativa de la OTAN (aunque independiente de ésta, pues incluso apuntó que el Centro es crítico en algunos temas con la Organización del Tratado del Atlántico Norte), por mostrarse tan abierto a colaborar con otras organizaciones, públicas o privadas. Éste planteó temas interesantes en materia de ciberseguridad: habló de que ya se usan los ciberataques en la defensa de intereses legítimos, e hizo por ejemplo referencia a las declaraciones de Sir Stephen Dalton, jefe del Estado Mayor del Aire de UK, relativas al uso que hace el ejército israelí de twitter.

Como ya he apuntado, me pareció interesante el enfoque holandés presentado por Anne Marie Zielstra, del NICC holandés, basado en la previsión, el trabajo colaborativo entre el sector privado y el público, y dando un carácter básico al intercambio de información entre los dos sectores. Fue también interesante y muy serio el enfoque británico expuesto por Peter Burnett, del OCS (Office of Cyber Security) de UK, que destacó que en los análisis de continuidad de sus ICs están pasando de un enfoque basado en la amenaza a un enfoque basado en el impacto (cuanto mayor pueda ser el impacto, más crítica será la infraestructura), y que corroboró la necesidad de compartir la información para mejorar el conocimiento.

Por último, unas reflexiones personales:

• En España existen unas 3.700 infraestructuras estratégicas (críticas, algunas de ellas), el 80% de las cuales se encuentran en manos privadas.
• Algunos de los ponentes pusieron encima de la mesa la falta de confianza existente a la hora de facilitar información sensible en el necesario intercambio y cooperación entre el sector privado y público ¿a alguien se le escapan los lógicos recelos de, por ejemplo, una telco a la hora de informar de que tiene determinadas carencias de seguridad o de infraestructuras que pueden afectar a su continuidad, recelos que se acentúan si además no tiene la certeza de que esa información no pueda caer en manos de la competencia o de terceros interesados en ver cómo explotar esas vulnerabilidades?
• El Real Decreto de protección de infraestructuras críticas en que se está trabajando es la trasposición de la Directiva Europea 2008/114/CE. Pero cuidado. La directiva europea regula la protección de las ICs de un país que pueden afectar a otros países, pero no entra en el ámbito exclusivamente nacional. Ahí deja el tema a la soberanía y libertad de cada país. Si volvemos a recordar que el 80% de las infraestructuras estratégicas españolas está en manos privadas, y les comento que durante las jornadas la frase que todos los representantes de ICs nacionales privadas pronunciaron fue “¿Y esto quién lo paga?”, tenemos como país un importante reto por delante.

Todo esto, mientras estos días más de 100.000 personas de la Costa Brava gerundense han pasado (y algunos siguen pasando) varios días sin suministro eléctrico, 40.000 sin teléfono fijo y sólo un 50% de cobertura de telefonía móvil tras la nevada de hace unos días.

Vamos, que ni al pelo para el post.

Pero dejemos las siglas para otro post y centrémonos en el XSS. Esta vulnerabilidad ha estado presente en las tres clasificaciones de OWASP. En el 2004 se consideró la cuarta vulnerabilidad más encontrada, en 2007 se posicionó en la primera posición de esta clasificación y en esta nueva versión del 2010 continúa en la parte alta ocupando la segunda posición, únicamente superada por la Inyección, que ya vimos en el anterior post de la serie.

Las vulnerabilidades de XSS son explotadas cuando una aplicación obtiene datos de cualquier fuente y los envía al navegador del usuario sin realizar una validación previa de los datos. Este tipo de vulnerabilidades permiten a un atacante ejecutar código arbitrario en el navegador del usuario permitiendo el robo de sesiones, defacement de páginas web (¿se acuerdan de Mr. Bean en la página de la presidencia de turno del Gobierno?), o incluir código malicioso de páginas no confiables por el usuario en otras que sí lo son.

Existen tres situaciones en las que nos podemos encontrar ante una aplicación vulnerable a ataques XSS:

• Utilizando los parámetros que se envían a través de una URL,
• utilizando información almacenada en el back end de datos del servidor y
• utilizando el propio objeto DOM que representa la página web que se está visualizando.

Veamos el siguiente ejemplo como demostración del tipo de situaciones en las que podemos encontrar un ataque de XSS a través de una URL. Sea una aplicación que dispone de un frontal web en el que se muestra un formulario. Al seleccionar el usuario una determinada categoría, pulsa el botón de buscar y le aparece el conjunto de artículos que contiene dicha categoría. Al pulsar sobre “Seleccionar”, se envía una petición al servidor del tipo:

Una vez recibida en el servidor, obtiene el listado de artículos y devuelve la información, así como el identificador de la categoría que quedará almacenado en un input oculto para su posterior utilización de la forma:

<input type='hidden' name='category' id='category' value='<%=request.getParameter(“id”)'/>

Un atacante de nuestra plataforma podría modificar la petición esperada que provocase que no se retornará ningún artículo de la categoría pero le permitiese, por ejemplo, recuperar la cookie de sesión del usuario y realizar cualquier acción que considere oportuna:

Para que esta vulnerabilidad sea efectiva y el usuario pueda ser atacado es necesario engañarlo, por ejemplo a través de un correo en el que se solicita que pulse un determinado enlace que visualmente apunta a una página “segura” en la que se ofuscan los parámetros que pueden ocasionar la vulnerabilidad. Si no conocían esta vulnerabilidad, es posible que a partir de hoy le tengan tanto respeto como yo a los acortadores de URL tipo http://bit.ly/bcB8zC o http://tinyurl.com/yc7oq9e, pero esto ya lo trataremos en otro post.

Del mismo modo, es posible mostrar un ejemplo de vulnerabilidad de XSS basada en el árbol DOM que representa la página web que está visualizando el usuario. Sea una aplicación que permite la selección de lenguaje a través de un parámetro con el siguiente aspecto:

Seleccione su idioma:

<select>
   <script>
	document.write(“<option value=1></option>”);
	document.write(“<option value=2>”+
		document.location.href.substring(document.location.href.indexOf(“lang=”)+8
		+”</option>”);
	document.write(“<option value=3>English</option>”);
   </script>
</select>

Al seleccionar se envía una petición al servidor del tipo:

Un atacante de nuestra plataforma podría modificar la petición esperada que provocase que no se realizase un cambio en el lenguaje de la interfaz pero le permitiese, de nuevo, recuperar la cookie de sesión del usuario y realizar cualquier acción que considere oportuna:

Sin aprovechar ningún problema de validación en el servidor que recibe la petición ésta se transforma en un alert con la cookie del usuario en pantalla.

Por último, es posible aprovechar vulnerabilidades XSS permanentes procedentes del back end de datos del servidor de la aplicación, siendo esto posible si un mal diseño ha permitido a un usuario incorporar estos valores a través de la propia aplicación o mediante la explotación de alguna vulnerabilidad, por ejemplo las de inyección explicadas en el post anterior de la serie. De nuevo utilizamos el mismo ejemplo que desea obtener el listado de artículos de una categoría y las representa en una tabla con id, nombre y precio con una petición del tipo:

Supongamos que la tabla la compone directamente el back end del servidor en Java de la forma:

List<article> articles = proxyCategory.getArticles(id);
StringBuffer sbItem = new StringBuffer(“<table>”);
for (Article article : articles) {
	sbItem.append(“<tr><td>”).
	.append(article.getId())
	.append(“</td><td>”).
	.append(article.getDescription())
	.append(“</td><td>”)
	.append(article.getPrice())
	.append(“</td></tr>”);
}
sbItem.append(“</table>”)

Si la información almacenada en el back end ha sido comprometida, será posible que en el campo descripción, suponiendo que éste sea el único campo de tipo alfanumérico, se puedan incorporar datos maliciosos que puedan ocasionar una pérdida de información en la interfaz del cliente, de la misma forma explicada en los anteriores ejemplos. Para que esta vulnerabilidad sea efectiva y el usuario pueda ser atacado ya no es necesario engañarlo sino que la propia infraestructura del servidor al que se conecta es la que ha sido comprometida.

Al igual que en la entrada anterior, hemos realizado la muestra de vulnerabilidades a través de peticiones GET, siendo extensible a las peticiones POST sin que los ejemplos se vean alterados. Del mismo modo, estas vulnerabilidades son independientes del lenguaje utilizado en el servidor.

Aunque la primera manera de protegerse pueda considerarse eliminar por completo el uso de javascript en la página con plugins del tipo NoScript, siempre existirán páginas en las que confiaremos y para las que habilitaremos el uso de esta tecnología. Es por tanto necesario, desde el punto de vista del programador, incorporar los controles necesarios en la programación del servidor para mitigar y eliminar este tipo de vulnerabilidades. El resto de aspectos son similares a los que comentamos la última vez: es fundamental sanear las entradas: si el valor esperado es un número, que sólo pueda ser tratado un número, si es una cadena de texto, se deben validar que los caracteres incluidos sólo puedan contener caracteres válidos. En caso de que la aplicación desarrollada deba permitir el uso de caracteres especiales, se deberá tratar con especial atención esta información y garantizar que la información que se está tratando es adecuada antes de aceptar los datos.

Y hasta aquí todo lo referente a ataques de XSS, de momento. Como saben, si quieren extenderse en la materia, más allá de los innumerables recursos de la red, pueden acudir a la web de OWASP, donde encontrarán mucha información de utilidad. Si desean que demos más detalles sobre alguna de las vulnerabilidades mostradas, o no les ha quedado clara la explicación, no tienen más que indicarlo en los comentarios y estaremos encantados de ampliar la información.

Para evitar dichas manipulaciones el propio fabricante intenta proteger el sistema para que incluso el “propietario” del hardware (en el sentido de dueño del hierro) pueda utilizarlo para lo que guste. Este tipo de protecciones se usan de manera habitual para proporcionar contenidos con restricciones de uso (DRM), aplicar comisiones a los productos software, sistemas incopiables, etc. En algunos casos, los motivos aducidos serán razonables y en mi opinión otras veces abusos, la pregunta es: ¿Obedece el ordenador a su dueño? ¿U obedece a otra organizacion como Microsoft, Apple , Sony, Nokia, etc.? ¿Somos propietarios de nuestro propio hardware? ¿Quién manda en nuestra propia casa?

Algunos de nuestros lectores estarán ya pensando que que no son usuarios de este tipo de sistemas, pero la realidad es que existen muchos dispositivos de uso cotidiano que se han diseñado con esa filosofía. Vamos a ver algunos aparatos que, en muchos casos sin ninguna razón coherente, hacen “lo que ellos quieren” y no lo que quiere el dueño del “aparato”; son nuestros, pero no del todo, ya que obedecen a sus fabricantes (y a menudo en un sentido literal si existe algún tipo de conexión remota a los dispositivos).

Empecemos por las consolas de videojuegos. En todos los casos estos dispositivos están diseñados para poder ejecutar sólo un software determinado firmado digitalmente, lo que les protege de ejecutar copias de juegos, pero también impide la ejecución de software propio como Linux, o juegos sin pagar comisión. Como veremos, Internet es muy amplia y este tipo de protecciones no suelen durar demasiado tiempo, a pesar del tiempo y recursos utilizados por los fabricantes para diseñarlas (también es cierto que las modificaciones no llegan al gran público, por lo que el objetivo que se persigue con la protección se alcanza). Veamos:

• Xbox: Estos sistemas han sido vulnerados tanto por software mediante el uso de exploits, como por hacks hardware (los famosos modchips).
• Playstation 2: También reventado por hardware mediante modchips.
• Playstation 3: Les ha costado pero tras 3 años, parece que ya ha sido vulnerada.
• Wii: Vulnerado tanto por software como por hardware.
• PSP: Vulnerado tanto por software como por hardware (pandora battery).

En estos casos podríamos comentar que al desproteger el aparato se puede usar para ejecutar copias de juego, algo de moralidad cuestionable, pero también te permite ejecutar tus propios programas “hechos en casa” (homebrew) lo cual parece razonable en un aparato que has pagado y que no entra en conflicto con los intereses del fabricante que te lo vendió. Al respecto, hay ya varias sentencias que determinan la legalidad de estas modificaciones por hardware [ElPaís.com, sentencia completa en Bufet Almeida]aludiendo precisamente a la posibilidad de ejecutar programas como Linux.

En segundo lugar, están los teléfonos móviles, que cada vez son más inteligentes. En este caso, solo aplicaciones firmadas y que hayan pagado la correspondiente licencia pueden ejecutarse en estos dispositivos. En teoría, ademas se revisa que estas aplicaciones no sean dañinas para la estabilidad del teléfono, o incluso para la estabilidad de las redes de telefonía móvil (seguridad por lo tanto bastante cuestionable, si no es por la propia seguridad del protocolo, sino por el acceso a uno de los extremos). Las principales plataformas han sido manipuladas, como se muestra a continuación.

• Symbian: Solo el código firmado se puede ejecutar, si bien han aparecido diversos métodos para saltarse esas limitaciones.
• Iphone: Solo el codigo firmado y descargado de la Apple Store se puede ejecutar, también son ampliamente conocidas los hacks para poder ejecutar cualquier aplicación.
• Android: Incluso los moviles con Android por defecto no te dejan ser root (hay que hacer algunas triquiñuelas para serlo).

Por último, en la categoría de “Otros” existen multitud de dispositivos que entran dentro de este tipo de hardware. Veamos los ejemplos más relevantes:

• Ipad: Tal como lo describe la Free Software Fundation es un gran paso atrás en la historia de la computación ya que sólo permite ejecutar el código autorizado por Apple, siendo además difícil incluso acceder a los contenidos archivados en el propio aparato.
• Subsistema de video de ordenadores HDMI: Los cables HDMI de los equipos informáticos o televisiones disponen de sus protocolos de DRM, con lo que pueden establecer la resolución de la imagen dependiendo de las características del otro lado, o incluso no sacar señal si así lo deciden. Conecten un cable HDMI a su portátil, prueben a reproducir diversos contenidos con DRM y verán la pesadilla.
• Routers, dispositivos domesticos (NAS): numerosos aparatos domésticos están diseñados para que nadie pueda modificar, mejorar o tener pleno control de los aparatos.
• SmartCards, tarjetas de crédito EMV (tarjetas chip), DNI digital: Estos dispositivos aprovechan las funcionalidades de un pequeño sistema informático incrustado en la tarjeta, que tiene su procesador y su memoria, y que es muy robusto tanto desde el punto de vista del software como desde el punto de vista del hardware; al respecto, son sistemas muy difícilmente atacables en comparación con el resto de dispositivos comentados, lo que permite que la tarjeta proteja la clave privada con un PIN, y de ninguna manera la extraiga sino que solo opere con ella en su interior. Podríamos decir que se trata de un sistema confiable y que debe de ser así por la propia funcionalidad que el aparato ofrece, que protege al usuario ante un tercero que robe el propio aparato, y en principio no está a las ordenes de ninguna otra organización. En general estos sistemas no son vulnerados, quizá porque aun no están suficientemente extendidos. Debe destacarse que otros sistemas basados en tarjetas inteligentes como las de suscripciones de TV de pago si que han sido vulnerados, por lo que no seria de extrañar que también aparecieran exploits para estos sistemas.
• Decodificadores de televisión de pago: Normalmente los decodificadores incluyen una tarjeta criptográfica (que en sí mismo es un dispositivo de Computación confiable), que es el que se encarga de recibir las claves de los contenidos desde el proveedor y decodificar o no los contenidos. Al ser tarjetas criptográficas, no son fácilmente atacables debido a que además protegen un activo muy valorado economicamente. A pesar de ello, estos sistemas han sido vulnerados en repetidas ocasiones, pero en la actualidad los sistemas actuales de TV de pago están protegidos por un sistema denominado Nagra3 que parece que es resistente a los ataques.
• Trusted Platform Modules: Los equipos TPM son equipos PC que han sido adaptados para que funcionen de manera “Trusted” (Confiable/Controlada), integran procesadores criptográficos y dan una solución global (cifrado de disco, hardware, etc.). Con estos equipos se pueden diseñar sistemas que sólo ejecuten tu versión de Linux y los paquetes determinados, así como otros sistemas operativos. La solución en principio se ha diseñado para que sea robusta, sin embargo ha sido recientemente vulnerada. En torno a estos sistemas TPM y sobre todo para módulos criptográficos, en los que se quiere certificar su robustez desde el punto de vista lógico pero también desde el punto de vista fisico, existen certificaciones como FIPS que se centran en ello, como por ejemplo este pendrive.

Por último, y como precursor de todos estos artilugios, me gustaría comentar el artilugio de la edad media (popular tras la pelicula del código Davinci) Criptex, un aparato capaz de almacenar un pergamino, pero con vinagre de manera que si no introduces el código correcto destruye el pergamino. Para que vean que la idea de tener una máquina que tome sus propias decisiones en contra de quien la posee viene de muy lejos.

Todos los sistemas comentado se encuentran con los siguientes problemas:

• El software es atacable: Mediante todos los métodos que se os ocurran (exploits, overflows, etc.).
• El hardware es atacable: Se puede modificar el hardware añadiendo circuiteria (los famosos modchips que les comentaba). En el caso de las tarjetas las cosas se complican, aunque existen diversos ataques basados en modificar el voltaje, medir consumos para realizar ingeniería inversa, técnicas con microscopios electrónicos, limpiar con ácido los circuitos y otros muchos métodos de los cuales no soy ningún experto.

Como hemos podido ver, todos los intentos por parte de la industria de disponer de sistemas que no obedezcan al usuario en algún momento han fracasado, por lo que hemos de plantearnos varias cosas (aspectos que también y con mayor interés deberían plantearse los fabricantes de estos dispositivos),

• Primero, desde el punto de vista de la ingeniería, ingeniería del software y evolución técnica de la sociedad no debemos permitir que se impongan limitaciones artificiales sobre el software que se puede ejecutar en cada aparato. Sin duda alguna si el software y el hardware no hubieran funcionado como sistemas interoperables, la sociedad no habría avanzado todo lo que ha avanzado; es necesario por tanto impedir que los sistemas en su conjunto estén controlados por corporaciones.
• Desde el punto de vista de los usuarios, a nivel empresarial debemos de estar atentos a las limitaciones impuestas a nuestros aparatos/sistemas, cuáles son razonables y cuáles son excesivas.
• Desde el punto de vista de los desarrolladores de soluciones tecnológicas de este tipo, visto lo visto, hay que tener en cuenta que tarde o temprano si hay suficiente interés este tipo de sistemas serán vulnerados, y se debe de estar preparado para ese momento.

Este post me gustaría dedicarlo a Alan Turing (23 Junio 1912 – 7 Junio 1954) por inventar una máquina de propósito general, y al mismo tiempo no dedicarlo al resto de la industria por desear hacer todo lo contrario.

Estimados lectores, muy frecuentemente el primer pensamiento por parte de las empresas a la hora de afrontar la seguridad viene marcado por fuertes inversiones, como pueden ser costosas soluciones en infraestructura de red (IDS, Firewall), la compra de antivirus centralizados, suites de ServiceDesk, o laboriosos proyectos de consultoría. Si bien acometer dichas proyectos o compras de este tipo es un requisito para la consecución de cierto grado de seguridad empresarial, no resulta ser la panacea a la totalidad de los problemas de seguridad.

Cuántas veces han visto ustedes o incluso han empleado en presentaciones la frase: la cadena es tan fuerte como su eslabón más débil. Todos a estas alturas sabemos cuál es el activo que genera mayor riesgos a una empresa y que a menudo no contemplamos en nuestros análisis de riesgos: el empleado. De poco sirve que tengamos las medidas más sofisticadas, si mediante un simple correo electrónico cualquier empleado puede enviar informes clínicos a cualquier persona, no es consciente del problema de tirar los curricula de los candidatos descartados a un contenedor de basura cualquiera o se instala un programa P2P y comparte por descuido el contenido total del equipo. Dejando de lado problemas más graves que involucran a personal responsable o con privilegios de administración a los equipos.

Deliberado o no, estas cosas suceden y estos riesgos deben ser contemplados y tratados por las empresas. Aunque existen medidas técnicas mediante las que podemos limitar el riesgo asociado a estos eventos, es aconsejable establecer otro tipo de medidas para minimizar estos riesgos, ya que como hemos comentado alguna vez, las medidas técnicas no lo solucionan todo.

Tal y como cita ISO 27002, diferenciaríamos básicamente tres estadios para enfocar la seguridad respecto a la contratación: el previo la contratación, durante la contratación, y tras la contratación.

Previo a la contratación, lo más relevante es aclarar los términos contractuales a los que se someterá al empleado, destacando las cláusulas de confidencialidad que deberán ir mas allá de los datos personales con el fin de proteger el know-how de la entidad. Más allá de la mera firma, deberán recogerse las consecuencias derivadas del incumpliendo de tal clausula. Adicionalmente, en determinados cargos es aconsejable que el contrato incluya además de las cláusulas de confidencialidad, cláusulas de no competencia que durante un tiempo limitado restringen el cargo y funciones que el empleado puede realizar en otra organización una vez finalizada la relación contractual. Este tipo de cláusulas son más propias de multinacionales y conllevan una compensación económica.

Durante la contratación, una de las principales medidas es la concienciación de los empleados, algo que a menudo no va más allá de una pequeña charla de 30 minutos cada 2 años a una muestra “significativa” de la plantilla, que en general sirve de poco y no traslada de manera adecuada la importancia de la seguridad (la propia periodicidad y voluntariedad de estos cursos no ayudan). En este sentido es necesario cambiar la perspectiva del empleado, y que en lugar de un sujeto pasivo pase a ser un sujeto activo, a través de por ejemplo formación online mediante una plataforma estilo Moodle o Sakai que incluya examen, lo cual es económicamente viable tanto si se realiza internamente como si se decide subcontratar. Por otra parte es necesario establecer claramente los perfiles de los empleados y limitar el acceso a la información al mínimo necesario para el desempeño de las labores en el puesto de trabajo, según una filosofía need-to-know.

Una vez finalizada la relación contractual, debe como mínimo bloquearse el usuario de sistema perteneciente al ex empleado al finalizar su último día de trabajo efectivo en la entidad, y en caso de que este empleado fuera administrador, cambiar todas las contraseñas de los sistemas que fueran administrados por él. En cuanto al correo electrónico hay distintas sentencias, si bien el empresario únicamente tendrá acceso legítimamente a él si se cumplen el siguiente supuesto que menciona la Agencia Española de Protección de Datos en el informe 0247/2008, en el que concluye:

En última instancia y a pesar de que no se recoja en ninguna norma, cabe remarcar la posibilidad de mejorar la seguridad de este eslabón, cambiando el arraigado paradigma que considera al empleado según la teoría X en lugar de la teoría Y, ambas postuladas por Douglas Mcgregor. En este sentido la fidelización del empleado ayuda a que el empleado no se vea como un eslabón sino como parte de la cadena, fortaleciendo sin duda la seguridad de la organización.

(Imagen de sciain en Flickr)

A la vista de esto, sean las siguientes situaciones:

a) Una empresa A dispone de un servidor web meramente informativo donde tiene configurado, para la obtención de estadísticas de acceso, el registro de accesos del servidor, en el que almacena la fecha y hora de acceso, la IP con la que se ha accedido, y las características técnicas del navegador. Asumamos, para no complicar las cosas, que no existe en la web ningún formulario de contacto ni entrada de datos con los que la empresa propietaria de la web pueda relacionar a la IP con un nombre, o cualquier otro identificador. Esto, por ejemplo, sí es posible en un blog, en el que es posible asociar una IP a un identificador, en el mismo momento en el que éste realiza un comentario (claro que dicho comentario y el identificador no siempre identifican a una persona).

b) La empresa Telefónica dispone de un servicio al que sus usuarios acceden, y para cuyo acceso son identificados automáticamente mediante la IP, que es parte del pool de IPs que esta teleco tiene asignada.

Supongamos que la empresa A quiere obtener los datos de la persona ubicada detrás de la IP 259.1.1.259 (sí, ya sé que dicha IP no es posible). Las posibilidades son que haciendo uso de nslookup y whois se encuentre que dicha IP corresponde a una dirección de telefónica, jazztel, ONO o cualquier otro proveedor de Internet, o que detrás haya una empresa. Para obtener más información en el primer caso puede optar por analizar anteriores visitas y hacer algo de investigación sobre la posición geográfica de la IP, pero será difícil que sin una orden judicial pueda obtener mucho más que eso. En el segundo caso, deberá hablar con el administrador de red de la empresa a la que pertenece la IP, y que éste acceda de buena gana a darle más información basándose en sus registros DHCP y de navegacion web, si es que los tiene. Pueden probar, a ver qué tal les va.

Supongamos ahora que Telefónica quiere conocer los datos de la persona que ha accedido al servicio y que se encuentra detrás de la IP 259.1.1.259. Únicamente necesita ver los datos del usuario, tan simple como ello. Adivinen ahora en qué caso estamos hablando de “actividades desproporcionadas” y en qué caso no. Yo diría que recurrir a una orden judicial para obtener unos datos de un internauta no requiere sólo actividades desproporcionadas, sino que viendo cómo va la justicia en este país, el plazo es también desproporcionado.

Veamos ahora el siguiente fragmento del Dictamen 4/2007 sobre el concepto de datos personales del Grupo de Trabajo del Artículo 29, que les anticipo que aclarar, no aclara demasiado (pág. 18):

Es decir, ni blanco ni negro. Si el tratamiento de la dirección IP se lleva a cabo para identificar al usuario de un ordenador, es un dato de carácter personal dado que existe una intencionalidad en la que el propio captador de los datos asume como razonable el procedimiento que deberá aplicar para identificar a los usuarios de cada una de las direcciones IP; parece bastante lógico. Si yo capto matrículas para multar a los propietarios de los vehículos, es que asumo que el procedimiento de identificación es razonable (incluso aunque entremos en aspectos de valoraciones coste-beneficio), de lo contrario estaría haciendo el tonto. Pero si no es este caso, aunque usted crea que no podría identificar a los visitantes de su página web… pues bueno, en ese caso nos lavamos las manos y mejor que decida usted, que a nosotros nos supera.

Debe tenerse en cuenta que la letra a) de la mencionada Directiva dice lo siguiente:

Es decir, según esto prácticamente cualquier cosa es un dato de carácter personal, porque incluso en grados muy avanzados de “indirección” es posible relacionar un dato con su propietario. Por ejemplo, el justificante que la Administración Tributaria me facilitó para acceder a mi borrador es un dato de carácter personal. Veamos otro ejemplo. Mi perra se llama Samy y tiene un miedo atroz a básicamente todo. vivo en Valencia, tengo un Renault Megane tres puertas de color verde y el nombre de mi pareja es Laura. Combinen todos esos datos y seguro que aplicando algún procedimiento (e ignorando el hecho de que esta entrada está firmada con mi nombre y apellidos), por muy indirecto que sea, les llevará ante mi. ¿Significa eso que el nombre de mi perra es un dato personal? Pues no sé, pero si ven que me tuerzo me avisan.

No obstante, antes de seguir no hemos de olvidar que en este caso estamos hablando de la aplicación de la dichosa Directiva 95/46/CE, y no de nuestra querida LOPD y su Reglamento de Desarrollo. Veamos lo que dice la Agencia Española de Protección de Datos al respecto, en el informe Carácter de dato personal de la dirección IP. Informe 327/2003:

Por si no recuerdan, la letra a) del artículo 3 de la LOPD dice que datos de carácter personal son cualquier información concerniente a personas físicas identificadas o identificables. Correcto. Si es usted Telefónica, dispone de procedimientos razonables para acceder a las asignaciones de sus propios usuarios, y si usted es el administrador o dueño de una red local, muy probablemente disponga de herramientas para poder determinar la lista de leasings DHCP. Continuemos:

Si bien es cierto que muchas webs utilizan cookies, en realidad esto no hace al usuario más identificable ya que el procedimiento continúa siendo el mismo: tirar de los datos de la operadora a través de un procedimiento judicial. Incluso en aquellos casos en los que las cookies permiten identificar de manera unívoca al usuario, obtener el número de visitas, la frecuencia, la actividad e interactividad con la página, y sus características técnicas, por lo general seguimos sin tener a una persona identificada o identificable.

Claro que no es así siempre: Google sabe sin duda quiénes somos, qué hacemos y dónde estamos (entre otras muchas cosas) y de hecho casi no le hace falta ni la IP. Pero estarán de acuerdo en que no es el caso común. En ese caso, con las cookies lo único que probablemente tenemos sea un usuario de Internet que accede a nuestra página cada X días y navega por X enlaces antes de irse a otro lado.

¿Se acuerdan del ejemplo de mi perra? Quedamos en que ninguno de los datos proporcionados era suficiente para identificarme. Imaginen que para facilitar las cosas, añado el lugar donde veraneo, que tengo una bicicleta con la que vengo al trabajo siempre que no llueve, el nombre de la empresa que me realizó la instalación del gas en casa y la fecha cuando lo hizo. Para mí, ninguno de esos datos por separado hacen de mi una persona identificada o identificable, pero sí todos ellos en combinación, si tienen ustedes ganas. Ese parece ser el argumento expuesto: si bien la IP no es probablemente suficiente para identificar a una persona, si la combinamos con las cookies, entonces sí (que en la mayoría de los casos aún así, no, pero bueno).

Repito: les ruego que me corrijan si ven que me voy de lado. Más cosas:

Es agradable ver que al menos existe coherencia entre la AEPD y el Grupo de Trabajo del Artículo 29. Es decir, no sabemos si usted será capaz de identificar a alguien, pero por si acaso, si le parece bien suponga que sí que lo es.

De todas formas, si les sirve de consuelo, como bien indica Miguel Ángel Mata, no es la primera vez que la AEPD asume procedimientos no razonables como razonables. Aunque a ustedes y a mí nos parezca difícil identificar a la persona que hay tras la dirección p10292@hotmail.com (si es que hay una persona), la Agencia discrepa, y considera que “podrá procederse a la identificación del titular mediante la consulta del servidor en que se gestione dicho dominio, sin que ello pueda considerarse que lleve aparejado un esfuerzo desproporcionado por parte de quien procede a la identificación“. Si eso no es desproporcionado, entonces no hay nada desproporcionado; quiero pensar que la Agencia lo único que hace es dejarse llevar por ese eslógan de Adidas que decía aquello de Impossible is nothing.

Temo hasta el momento no haberles aclarado demasiado, más que la precaución de considerar como datos de carácter personal cualquier cosa que puedan imaginar. A fin de cuentas, a mi no me miren que la Agencia tampoco acostumbra a aclarar demasiado, y para ejemplo, esta resolución [Expediente Nº: E/00561/2004] en la que afirma que Atendiendo a lo que se acaba de indicar, aunque en principio es criterio de esta Agencia Española de Protección de Datos que el número del DNI, por si solo, no constituye un dato de carácter personal, si lo será en cuanto resulte adscrito al concreto titular del mismo., y este informe jurídico [Informe 0334/2008] cuatro años después dice que sí lo es.

Volviendo al conjunto de datos de carácter personal sobre mi persona, me llama especialmente la atención este fragmento, sacado del último informe (el del DNI, va a ser que sí) que les indico:

Reflexionen sobre eso; a mi me da que esa frase tiene algo de maldad intencionada.

Estoy acabando, no se preocupen. En mi opinión, el problema que radica en todo esto es que, manteniendo cierta ambigüedad muy perjudicial, la LOPD:

i) No tiene en cuenta la relación del responsable del tratamiento que va a tratar los datos con el propietario del dato, lo que puede resultar determinante para saber si hablamos de un dato de carácter personal o no. Creo que es cristalino como el agua que la dirección IP dinámica de mi casa es un dato de carácter personal para mi proveedor de telecomunicaciones, dado que pueden acceder a mi DNI, nombre, apellidos, facturación y muchas otras cosas, pero no lo es para casi nadie más. Las cinco últimas cifras de mi móvil podría ser un dato de carácter personal para las personas que me conocen, incluida mi empresa, pero para nadie más.

ii) No tiene en cuenta las características y finalidad del tratamiento para determinar qué es una “identificación que requiere plazos o actividades desproporcionado”, sentencia cuya concreción es francamente difícil de empeorar. El identificador (único) que la AEAT me envió para la confirmación del borrador de la declaración de la renta por Internet es un dato de carácter personal para Hacienda, pero para nadie más. ¿Significa que esta página, que consta de una lista NIFs, es un listado de datos de carácter personal? Como dice Manuel Parra, si ahora escribo el DNI 01891015R, ¿estoy llevando a cabo un tratamiento de datos de carácter personal? ¿Sí, no, a veces, y a mi que me cuenta?

Bueno. En cualquier caso, seamos sinceros, ¿y la de cosas que escribimos gracias a la Agencia, la LOPD, la Directiva y todo esto de los datos personales? ¿Y lo que nos reímos?

El funcionamiento de un proxy cache es el siguiente: cuando un cliente realiza una petición a un servidor web, en la que genera X peticiones a todos los objetos que componen dicha web, la petición llega al proxy, que revisa su cache para comprobar si dispone de los objetos que se van solicitando. En el caso de que el objeto buscado se encuentre en cache, el proxy verifica que no ha expirado: que el objeto se corresponde con el actual, y en ese caso se produce un HIT y el sistema devuelve al cliente el objeto en cuestión. Si por el contrario el objeto buscado no se encuentra en cache o la versión encontrada no está actualizada, se produce un MISS en cache, tras lo cual el proxy descarga el elemento solicitado y lo sirve al cliente.

Como puede verse, en el mejor de los casos nos ahorramos el enrutamiento desde el proxy al servidor sobre el que se realiza la petición y la transferencia de la información solicitada a través de Internet, mientras que en el peor de los casos añadimos un salto más en el enrutamiento. Por supuesto, cuánto más accedido sea un determinado contenido por los usuarios de la red interna, mayor probabilidad de que el objeto se encuentre en cache y por tanto, mayor incremento del rendimiento del sistema.

Veamos ahora un ejemplo enfocado a nuestro entorno. Como todos saben, la Ley 11/2007 de 22 de junio, de Acceso electrónico de los ciudadanos a los Servicios Públicos, promueve el ofrecimiento de los servicios prestados por las administraciones públicas a través de la web. El enfoque que se le está dando es que los organismos más grandes actuarán de prestadores de servicios para aquellos organismos más pequeños y con menores recursos; por ejemplo, una diputación presta la plataforma para los ayuntamientos. Teniendo en cuenta que las cifras empleadas únicamente van a servir de ejemplo y en ningún caso reflejan la realidad, apliquemos esto a lo que hemos visto hasta el momento.

Imaginemos que todas las peticiones web realizadas a los servicios prestados por los ayuntamientos se realizaran directamente contra el servidor de la diputación, que actúa no sólo de repositorio de contenidos, sino que además de frontal web para los usuarios finales. ¿Qué ancho de banda consumiría únicamente sirviendo las imágenes de la web? ¿Qué carga va a soportar el servidor? En este caso, el servidor de la diputación debería responder a cada petición de los usuarios. Sin embargo, si cada ayuntamiento dispone de un proxy cache, las peticiones de cada usuario repercutirá en una respuesta por parte del servidor del ayuntamiento, y el servidor de la diputación recibirá únicamente aquellas peticiones que correspondan a material que se encuentre obsoleto en el servidor del ayuntamiento (obviamente la parte dinámica siempre se trasladará al servidor de la diputación, por su imposibilidad de hacer uso de proxy cache para ello).

Hagamos algunos números, aunque de manera muy simplificada. Supongamos no hacemos uso de proxy caché, y que la página de un ayuntamiento está formada por 30 objetos, de los cuales 10 se actualizan cada minuto. Tenemos un total de 100 ayuntamientos que reciben 1000 peticiones por minuto, por lo que estamos hablando de un total de 3.000.000 de peticiones por minuto (30 objetos * 100 ayuntamientos * 1000 peticiones) directamente sobre el servidor de la diputación, lo que lo hace mucho más vulnerable a caídas y pérdidas de servicio en caso de existir un pico de carga que no pueda gestionar. Sin embargo, si se implementan proxys cache al nivel de los ayuntamientos, cada uno de éstos recibe un total de 30.000 peticiones por minuto (30 objetos * 1000 peticiones), y el servidor de la diputación 1000 peticiones por minuto (10 objetos que hay que actualizar cada minuto * 100 ayuntamientos). Como puede verse, ambos números son mucho más razonables y reducen tanto las necesidades de hardware como el impacto de un pico de carga. Por supuesto, para trasladar esto a un ejemplo real, deberíamos contemplar tanto el impacto de las verificaciones contra la fuente original del objeto demandado, además del impacto que tiene la cache de los propios navegadores sobre el tráfico soportado por los servidores. En cualquier caso, no es el propósito de la entrada elaborar un modelo elaborado, sino únicamente mostrar una aproximación numérica a las ventajas de la utilización de los proxy cache.

Como herramientas de servidor cache destaca SQUID, un programa de software libre que implementa un servidor proxy y un demonio para caché de páginas web, publicado bajo licencia GPL. SQUID es un proyecto que lleva tiempo disponible y que tiene muy buena aceptación por parte de la comunidad. Aunque orientado a principalmente a HTTP y FTP, es compatible con otros protocolos como Internet Gopher (sí, Gopher, ¿se acuerdan?). Implementa varias modalidades de cifrado como TLS, SSL, y HTTPS. Como herramientas para analizar los logs generados por el proxy, tenemos A CALAMARIS y SARG. Ambas ayudan a entender el funcionamiento de la red y permiten reconfigurar el proxy para mejorar las prestaciones del mismo.

Resumiendo, un proxy cache permite optimizar y mejorar las prestaciones, reduciendo (y limitando si es preciso) el consumo de ancho de banda, que puede ser utilizado para otros aspectos como puede ser trafico QoS (aunque este es más dependientes de latencias y jitter que de ancho de banda). En cualquier caso, aunque son patentes los beneficios de esta tecnología, es obvio que está enfocada a infraestructuras que soportan un importante número de peticiones web. Por otra parte, para mejorar su eficiencia es importante que exista un proceso de mejora continua, de modo que se aproveche el feedback que proporcionan los registros producidos por el servidor, ajustando la configuración del proxy a los requisitos de nuestra organización.

La inauguración oficial de las jornadas corrió a cargo del Secretario de Estado de Seguridad, D. Antonio Camacho, quien destacó la importancia que en los últimos tiempos ha tomado la seguridad para el conjunto de la sociedad y especialmente la seguridad de las infraestructuras críticas para todos los gobiernos del mundo. En su intervención lanzó una serie de datos que ponen los pelos de punta a cualquiera y que ponen de manifiesto la importancia de los temas tratados en el encuentro durante estos días. Habló, en términos generales, del ya disponible Catálogo de Infraestructuras Estratégicas de España, promovido a instancias proyecto de Directiva de la UE para la identificación y designación de infraestructuras críticas europeas (ICE) de diciembre de 2006, y desarrollado en España en base a lo establecido por del Acuerdo del Consejo de Ministros sobre Protección de Infraestructuras Críticas. Este Catálogo, tal y como se establece en el Real Decreto está considerado como material SECRETO y recoge información de unas 3.700 Infraestructuras Estratégicas en España, algunas de las cuales son Críticas. El Secretario de Estado comentó que aproximadamente el 80% de las Infraestructuras Estratégicas catalogadas están en manos privadas y que en los estudios que se han realizado en materia de seguridad sobre una población de unos 600 directivos de ICs, el 54% de las encuestadas reconocen haber sufrido ciberataques organizados.

A priori estos datos estremecen a cualquiera, y más cuando uno empieza a profundizar sobre las medidas de protección que algunas de estas instalaciones tienen en términos generales. En este blog ya hemos escrito en varias ocasiones sobre estos temas; hace algún tiempo, incluso antes de crearse el CNPIC, nos preguntábamos sobre si podíamos o no dormir tranquilos en un post que escribimos poco después de realizar una auditoría de seguridad en una instalación que no podemos ni debemos citar.

Para terminar su intervención, D. Antonio Camacho destacó la importancia del tema anunciando la próxima publicación del Real Decreto sobre la Protección sobre Infraestructuras Críticas Nacionales. El Plan Nacional de Protección de Infraestructuras Críticas define como Infraestructuras Críticas: “Aquellas instalaciones, redes, servicios y equipos físicos y de tecnología de la información cuya interrupción o destrucción tendría un impacto mayor en la salud, la seguridad o el bienestar económico de los ciudadanos o en el eficaz funcionamiento de las instituciones del Estado y de las Administraciones Públicas”, y contempla la inclusión de éstas en 12 Sectores estratégicos, subdivididos a su vez en Subsectores, Ámbitos y Segmentos que son los siguientes:

• Administración
• Alimentación
• Energía
• Espacio
• Sistema Financiero y Tributario
• Agua
• Industria Nuclear
• Industria Química
• Instalaciones de Investigación
• Salud
• Tecnologías de la Información y las Comunicaciones
• Transporte

En términos generales, constatamos el incipiente desarrollo de actividades en todos los sectores en esta materia y que es mucho el camino que queda por recorrer. No se puede decir, ni mucho menos, que sea un problema maduro en su definición, con soluciones maduras por parte del mercado. Mucha intención, mucho proyecto de I+D+i y mucho futuro para problemas que no obstante más que de futuro son totalmente presentes. Los asistentes tuvimos la oportunidad de recibir información sobre la perspectiva nacional, la internacional, la visión de algunos gestores de Infraestructuras Críticas y las tímidas soluciones de la Industria al problema planteado.

Las jornadas finalizaron con la creación de 4 talleres en torno a los temas que la organización consideró más urgentes e importantes:

• Taller I: Gestión de incidentes y Sistemas de detección preventiva
• Taller II: Gestión de Riesgos
• Taller III: Gestión de continuidad
• Taller IV: Seguridad en productos de sistemas y control industrial

En próximas entradas que escribirá el equipo que asistió al evento, intentaremos resumir las conclusiones que hemos sacado de cada uno de estos talleres. Por último, desde este blog queremos enviar nuestra más sincera enhorabuena al joven Centro Nacional de Protección de Infraestructuras Críticas (CNPIC) por la organización del encuentro, y nuestro mensaje de ánimo a su Director, D. Fernando Sánchez, para afrontar el duro trabajo que tienen por delante. Desde S2 Grupo seguiremos trabajando en labores de I+D+i, concienciación y consultoría para aportar nuestro granito de arena en una labor tan importante para los estados como es la protección de sus Infraestructuras Críticas.

La vulnerabilidad más comúnmente explotada desde el año 2004 que OWASP lleva realizando esta clasificación es la inyección. Aunque la más común sea probablemente la Inyección de SQL, existen otros tipos de inyecciones que es posible que no nos resulten tan familiares: LDAP, XPath, XSLT, XML, OS injection, etc., y que al igual que la Inyección SQL se aprovechan de la sintaxis del interprete que se va a encargar de ejecutar una determinada acción. Las vulnerabilidad de inyección pueden permiten a un atacante obtener cualquier tipo de información disponible en la aplicación, pudiendo llegar a comprometer totalmente la aplicación, así como los sistemas relacionados con ésta. Y ya saben que de ahí al infinito y más allá.

Veamos el siguiente ejemplo como demostración del tipo de situaciones en los que podemos encontrar una inyección SQL. Sea una aplicación que dispone de un frontal web en el que se muestra un formulario. Al seleccionar el usuario una determinada categoría, pulsa el botón de buscar y le aparece el conjunto de artículos que contiene dicha categoría. Al pulsar sobre “Seleccionar”, se envía una petición al servidor del tipo:

Una vez recibida en el servidor, dicha petición se transforma en el siguiente código para obtener el listado de artículos de una determinada categoría:

Un atacante de nuestra plataforma podría modificar la petición esperada y solicitar información no controlada, por ejemplo:

De esta forma, el atacante podría obtener el listado de todos los artículos de la base de datos con una simple modificación que puede ser realizada directamente desde el navegador con, por ejemplo, el plugin Hack Bar de Firefox. Aunque esto parezca trivial y quizá en algún caso pueda interesar que un usuario se pase toda la tarde viendo mi página web para comprar un cabecero para su dormitorio, la cosa cambia sustancialmente cuando la información que se pretende mostrar son los ingresos de un trabajador o el grado de minusvalía de una determinada persona. Si a esto le añadimos la posibilidad de algunos sistemas gestores de base de datos de concatenar sentencias en una misma ejecución, el resultado podría ser la modificación de una tabla o incluso el borrado de la propia base de datos.

Pasando a otra tipología, veamos ahora una inyección de sistema operativo. Supongamos que en la interfaz de administración de la aplicación de catálogo comentada anteriormente existe una interfaz de administración que permite ejecutar unas tareas administrativas sobre el servidor, cuyo resultado es mejorar la indexación de las distintas bases de datos que componen la aplicación. Una vez seleccionada la base de datos, el usuario pulsa el botón de optimizar y se envía una petición al servidor del tipo:

Una vez recibida en el servidor, dicha petición se transforma en el siguiente código para optimizar la base de datos solicitada:

Cuando el proceso termina se envía un mensaje al espacio privado del usuario con el resultado de la ejecución. Un atacante de nuestra plataforma podría modificar la petición esperada y solicitar información no controlada, por ejemplo de la siguiente manera:

De esta forma, podría obtener el listado de todos los usuarios y sus contraseñas en su espacio de usuario, únicamente esperando a que el proceso termine su ejecución (seguro que en lugar de /etc/passwd pueden pensar alternativas mejores).

Aunque los ejemplos de vulnerabilidades se han mostrado siempre con peticiones GET, las aplicaciones son igualmente vulnerables a peticiones POST. Del mismo modo, estas vulnerabilidades son independientes del lenguaje utilizado en el servidor, aunque el uso de determinados frameworks puede mitigar la existencia de estas vulnerabilidades. Los dos ejemplos mostrados son sólo un par de situaciones en las que es posible encontrar vulnerabilidades de inyección, pero la filosofía es extensible al resto de tipos de inyecciones.

La primera manera de protegerse, independientemente del tipo de inyección que podamos sufrir, es asegurar que los datos que se utilizan para componer la visualización dinámica de la aplicación —aquella que depende de la petición del usuario— se encuentran correctamente validados antes de su interpretación. Es decir, si “estamos esperando” un número, se debe validar que el parámetro utilizado será un número, y si por el contrario esperamos una dirección de correo electrónico, utilizaremos ese dato únicamente si éste es conforme al formato establecido. En segundo lugar, es importante prestar especial atención a la existencia de determinadas secuencias de caracteres y cuando se presenten, “escaparlas” mediante las funciones apropiadas. Por último, la mayoría de lenguajes disponen de APIs con funciones diseñadas para proteger la aplicación, y que ofrecen la posibilidad de ejecutar consultas especialmente preparadas para evitar este tipo de problemas de seguridad.

Y hasta aquí todo lo referente a ataques de inyección, de momento. Como saben, si quieren extenderse en la materia, más allá de los innumerables recursos de la red, pueden acudir a la web de OWASP, donde encontrarán mucha información de utilidad. Si desean que demos más detalles sobre alguna de las vulnerabilidades mostradas, no tienen más que indicarlo en los comentarios.

Para los que no conozcan el tema, en España, especialmente en las Administraciones Públicas, tenemos un referente indiscutible en el ámbito de la Seguridad de la Información cuando nos planteamos la metodología de análisis y gestión de los riesgos a seguir: MAGERIT, actualmente en su versión 2.0 y elaborada por el Consejo Superior de Administración Electrónica (CSAE), órgano del Ministerio de Administraciones Públicas encargado de la preparación, elaboración, desarrollo y aplicación de la política informática del Gobierno Español.

Por otro lado, el Esquema Nacional de Seguridad (ENS), Real Decreto 3/2010 de 8 de enero (BOE de 29 de enero), tiene por objetivo establecer la política de seguridad en la utilización de medios electrónicos, y está constituido por principios básicos y requisitos mínimos que permitan una protección adecuada de la información en el ámbito de acceso electrónico de los ciudadanos a los Servicios Públicos.

Volviendo al tema en cuestión, en el área de consultoría de S2 Grupo teníamos nuestro pequeño debate acerca de porqué en el ENS no se aconsejaba directamente el uso de MAGERIT, ni se mentaba implícitamente. Quizás la respuesta estaba en un explícito reconocimiento internacional. Así pues, decidimos investigarlo buscando referencias en ámbitos superiores y encontramos alguna referencia en ENISA (European Network and Information Security Agency) que la identifica junto a otras metodologías europeas e internacionales. Encontramos múltiples referencias en la documentación electrónica accesible de esta agencia, donde cabría destacar una ficha en la que se afirma que su extensión geográfica va más allá de los miembros de la UE y que cumple con determinadas normas nacionales e internacionales. Sin embargo, por otro lado, en el “Inventory of Risk Management / Risk Assessment Methods“, afirma que hay métodos que fueron excluidos deliberadamente de la encuesta, porque los documentos pertinentes no estaban disponibles para los miembros del grupo de trabajo (por ejemplo MAGERIT desde España).

Esta referencia nos dejó estupefactos por las consecuencias que ello pudiera tener. Trabajamos con clientes en las distintas administraciones públicas, donde utilizamos esta metodología, incluso en el sector privado, y su grado de aceptación e implantación es muy alto. Por tanto, valoramos las oportunidades de dirigirnos a personalidades que son referencias en nuestro negocio, por lo que decidimos pensar bien cómo plantear la pregunta y dirigirla, en principio, a quien publicaba el ENS: el Consejo Superior de Administración Electrónica (CSAE), a través de su dirección de contacto (secretaria.csae [en] map [punto] es).

La contestación nos ha agradado mucho, en especial porque la contestaba personalmente Miguel A. Amutio Gómez, Jefe de Área de Planificación y Explotación de la Dirección General para el Impulso de la Administración Electrónica del Ministerio de la Presidencia. Como verán, es suficientemente esclarecedora y no veo oportuno comentarla ni resumirla. Tras solicitar el preceptivo y oportuno permiso para publicarla, aquí la tienen.

Desde aquí, agradecer a Miguel A. Amutio su respuesta y el honor de hacernos partícipes de esta aclaración. Ahora le toca a nuestras administraciones ponerse manos a la obra en la implantación de ese necesario y ambicioso proyecto que es el Esquema Nacional de Seguridad. Por lo demás, nosotros nos vamos hasta el lunes; sean felices y pasen un buen fin de semana.