Security Art Work

En esta ocasión, el artículo sobre el TOP 10 del catálogo de vulnerabilidades de OWASP del año 2010 se basa en la vulnerabilidad conocida como XSS, cuyas siglas en inglés se traducen como Cross Site Scripting. Por si alguien se lo está preguntando, la X es realmente una cruz y de ahí lo de Cross, ya que tuvieron que buscarle unas siglas que no pudieran confundir con CSS, Cascade Style Sheet. La nomenclatura es la misma que en Xing, la red social de profesionales, por lo que si alguna vez hay que pronunciarlo: será mejor hacerlo como crossing.

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/9Uc1S4 o http://tinyurl.com/382hyoz, 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.

En esta entrada me gustaría repasar algunas aproximaciones al respecto del concepto de Trusted Computing, y como lo lógico es empezar con la definición, por Computación Confiable nos solemos referir a sistemas completos e integrados hardware+software, en los que todo lo que se ejecuta se encuentra bajo el control del sistema y hay muy poca flexibilidad para la ejecución de otras cosas; enseguida veremos algunos ejemplos. Así pues, podría decirse que disponemos de una caja “blindada” que no puede en teoría ser manipulada ni por software ni por hardware, de modo que sólo realizará las funciones para las que esta diseñada siguiendo las directrices marcadas por el fabricante, sin que pueda ser manipulada o alterada.

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.

(N.d.E. Nada más volver del pasado verano hicimos una analogía entre la función de la norma ISO 27001 en seguridad de la información y el cinturón de seguridad en seguridad del automóvil. En ella “prometíamos” hacer un repaso a los “anclajes” de ISO 27001, en especial al Anexo A de ISO 27002. Recuperamos dicha serie con esta primera entrada de Antonio Huerta, que habla del Dominio de Control 8: Seguridad relacionada con Recursos Humanos)

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.

[Read more…]

Esta, entre otras, es una eterna cuestión que rodea a los datos personales y que nos da más de un dolor de cabeza: ¿es la IP un dato de carácter personal? Pues bien, todo parece apuntar, según lo que les mostraré en esta entrada, que sí. Yo, si les digo la verdad, siempre he sido un poco reacio a considerarla como tal, al menos en algunos ámbitos. Veamos un par de definiciones del Reglamento de Desarrollo de la LOPD:

[Read more…]

Apreciados lectores, me voy a alejar un poco de la temática de mis anteriores publicaciones, más enfocadas a aspectos organizativos de la seguridad, y en esta publicación hablaré sobre el uso de sistemas proxy cache para optimizar el uso del ancho de banda de red. Como introducción a los proxys, decir que básicamente se trata de un servidor que hace de intermediario en la conexión entre un cliente e Internet. Los proxys se emplean en distintos ámbitos y con distintas funcionalidades como puede ser seguridad (filtrado) o mejora de las prestaciones de las comunicaciones, entre algunas otras. Este artículo se centrará en los servidores Proxy Cache que permiten optimizar el uso de ancho de banda, reducir latencias y por lo general hacer un uso más racional de los recursos disponibles.

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.

Hace un par de semanas tuvo lugar en Madrid el primer encuentro internacional CIIP sobre Ciberseguridad y Protección de Infraestructuras Críticas. El encuentro se desarrolló en la División de Formación y Perfeccionamiento de la Subdirección General RRHH de la DG de la Policía y la Guardia Civil con una muy alta participación tanto de gestores de Infraestructuras Críticas como de consultores que estamos trabajando en estos temas.

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.

Si recuerdan el post que publicamos hace poco más de una semana titulado OWASP Top 10 2010. Release Candidate, éste iniciaba una serie de entradas a través de las que pretendemos mostrar en qué consiste cada una de las vulnerabilidades que forman el TOP 10 de OWASP, así como ofrecer algunas indicaciones y recomendaciones sobre la mejor forma de evitar que nuestras aplicaciones sufran estas conocidas vulnerabilidades. Con algo de retraso sobre la fecha prevista, he aquí el primero.

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.

El pasado 18 de enero, nuestro compañero y “alma mater” de este Blog, el ínclito Manuel Benet, nos sorprendió con una nueva entrada que titulaba “MAGERIT: ¿Sí, o no?“, donde transcribía el artículo 13 del aún por entonces no publicado Esquema Nacional de Seguridad (ENS), y sometía la cuestión a una encuesta informal.

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.

Hace ya unos meses, en este mismo blog, comentábamos la seguridad de los procesos de negocio y de los diferentes factores de riesgo (legal, técnico…) que pueden degradar dichos procesos; hablábamos en ese post del riesgo humano, ya que las personas son un activo crítico de las organizaciones y, como tal, pueden introducir riesgos en éstas, riesgos que como siempre debemos tratar de forma adecuada. Pero el paso previo al tratamiento de riesgos es, como siempre, su análisis, y para analizar estos riesgos debemos ser capaces de determinar amenazas, probabilidades e impactos que pueden causar las pesonas en la organización.

Bajo mi punto de vista, las amenazas derivadas del factor humano son claras: todas las englobadas bajo el paraguas de amenazas corporativas (errores), las derivadas de actividades sociales (accidentes) y las derivadas de actividades antisociales (delitos); incluso rizando el rizo, podríamos hablar del factor humano en las amenazas de origen industrial y, siendo todavía más retorcidos, en las de origen natural. De la misma forma, los impactos asociados a estas amenazas también suelen estar más o menos claros, y estarán —con toda probabilidad— en la parte más alta de la escala de impactos que queramos utilizar en nuestro análisis. ¿Dónde está entonces lo que más nos interesa? En la medida de la probabilidad, como casi siempre…

Para analizar probabilidades a la hora de hablar del riesgo humano, una aproximación que me gusta mucho —adaptándola a nuestras circunstancias, por supuesto— es la presentada en [1]. La idea resumida y simplificada es que cualquier persona está modelizada por una serie de perfiles que la definen, perfiles afectados además por una serie de condiciones de contorno (relaciones, privilegios, motivaciones…) y de eventos externos o internos a la organización que pueden provocar cambios sustanciales en el perfil de una persona (un cambio de estado civil, un ERE, la muerte de un familiar…). Si somos capaces de monitorizar esto, de una u otra forma, seremos capaces de establecer controles cuando sea necesario, y por tanto de mitigar los riesgos humanos no asumibles en la organización.

¿Cuáles son los perfiles que definen a las personas? Según el trabajo anterior, son los siguientes (existe un último perfil identificado en el trabajo, el de utilización de recursos informáticos, bajo mi punto de vista demasiado ad hoc para la detección de insiders y no tan apropiado para la modelización del riesgo humano en general):

• Perfil económico (estabilidad, actividades sospechosas…).
• Perfil social (estado civil, personas dependientes, hobbies…).
• Perfil psicológico (adicciones, comportamientos anómalos, falta de carácter…).
• Perfil profesional (inteligencia, satisfacción, implicación, reconocimiento…).
• Perfil legal (antecedentes penales, procesos pendientes, sanciones…).
• Perfil ideológico (implicaciones políticas, religiosas…).

Si somos capaces entonces de crear estos perfiles, y lo que es más importante, de monitorizarlos en el tiempo para detectar cambios sustanciales que puedan introducir riesgos en nuestra organización, habremos dado un paso importante para reducir los riesgos derivados del factor humano. Ahora la pregunta del millón: ¿cómo monitorizar todo esto? Lo ideal sería, como siempre, hacerlo todo de forma automática, con sensores que nos avisan en tiempo real de cambios potencialmente peligrosos en la modelizacion de una persona. Para empezar, esto no es siempre posible (¿cómo diseño un sensor que detecte comentarios sospechosos durante la hora del café? ¿y rasgos faciales que puedan implicar falta de interés o cansancio?) y, cuando lo es, no suele ser fácil; seguramente para el gobierno estadounidense puede ser trivial controlar en tiempo real las transacciones económicas o los antecedentes de sus ciudadanos, pero desde luego, para nosotros (pobres mortales) ni es fácil ni muchas veces sería legal.

¿Qué hacer entonces? Mientras trabajamos en monitorización automática de personas para calcular probabilidades cambiantes que puedan aumentar los niveles de riesgo (¡toma ya!), podemos conformarnos con realizar manualmente una modelización de las personas de nuestra organización, teniendo en cuenta los perfiles anteriores —u otros cualesquiera que nos sean útiles — y por supuesto con las consideraciones legales oportunas. En base a este análisis, y pensando un poco, seguramente no hará falta ser psicólogo para darnos cuenta de posibles riesgos (en cualquiera de los ámbitos de la seguridad, desde un insider a un riesgo reputacional) que pueden existir derivados de las personas, y por supuesto cuando identifiquemos un nivel de riesgo no asumible, deberemos tomar medidas -aplicar controles- contra el mismo. Ojo, estos controles no tienen por qué ser ni caros ni complejos: como casi siempre en seguridad, simplemente hace falta pensar.

[1] Mitigating insider sabotage and espionage: a review of the United States Air Force’s current posture. Erika C. Leach, Air Force Institute of Technology. Marzo, 2009.