Security Art Work

Hoy me gustaría compartir con vosotros una aplicación que he descubierto al revisar las ponencias de la próxima RootedCON.

La herramienta en cuestión es XSSer, un Framework que detecta, explota e informa de vulnerabilidades XSS en aplicaciones Web. Supongo que las vulnerabilidades XSS no son desconocidas para nuestros lectores, aunque si tienen alguna duda pueden visitar esta entrada para refrescar conceptos.

Como comenta el propio autor en la web del proyecto, contiene diversas opciones para evadir ciertos filtros y diferentes técnicas de inyección de código.

Para empezar a usar la herramienta, basta con descargar la última versión del repositorio:

$ svn co https://xsser.svn.sourceforge.net/svnroot/xsser xsser

Una vez realizado esto, podemos ejecutarlo de dos formas distintas, desde consola o mediante su interfaz:

[Read more…]

La entrada de hoy corre a cargo de Javier Cao, un “clásico” del sector que no requiere demasiadas presentaciones y al que nos gustaría ver más a menudo por estos lares.

Aunque la entrada de hoy no es totalmente original como suele ser habitual, ya que fue publicada en su mayor parte ayer en su blog personal “Apuntes de seguridad de la información”, hemos creído interesante traerla también a nuestros lectores ya que guarda relación con dos de los aspectos en los que S2 Grupo está especializada: la Seguridad de la información y la Gestión de procesos (o eventos, en este caso) en tiempo real. Vamos pues con ella y esperemos que les guste.

Todas las organizaciones, grandes o pequeñas, disponen de sistemas de recogida de eventos que guardan en ficheros de log datos sobre lo que está sucediendo en el funcionamiento de los sistemas de información. Esta materia prima permite establecer un puesto de vigilancia y conocer de primera mano qué ocurre en sus sistemas de información. En algunos casos por tiempo, en otros por desconocimiento sobre las problemáticas a analizar, esos datos no sirven para tomar decisiones que en un momento dado pueden luego costar una factura muy cara. El ejemplo en el mundo físico es como quien coloca cámaras de vigilancia y sensores volumétricos en todos los rincones a vigilar de su empresa, centralizando toda esa información en un cuarto de control y luego no pone vigilantes las 24 horas del día para que monitoricen lo que sucede en esas pantallas y centrales de alarma.

[Read more…]

Para hoy tenemos una nueva encuesta, que pueden contestar en esta entrada y en la columna de su derecha. La encuesta dice así:

Respecto a la encuesta anterior, los resultados se dividen entre los optimistas, que consideran que podremos mantener la privacidad en el futuro siempre que queramos renunciar a ciertos servicios, y los pesimistas, que piensan que hagamos lo que hagamos, es una batalla perdida. Como tercera alternativa, la idea de que la pérdida de la privacidad es algo positivo que es inherente al progreso que incorporan las nuevas tecnologías no parece tener demasiados seguidores, ya sea porque nadie considera en realidad que tal pérdida pueda ser considerado un avance, o porque las otras opciones estaban más definidas.

¡Esperamos sus respuestas!

Seguimos hablando de nuestro anonimato en Internet y de las diferentes formas existentes de identificación de usuarios que existen. En este caso, llegamos a este paper donde se explica como se puede llegar a obtener una “huella digital” de los usuarios que visitan una página web. El investigador Peter Eckersley se dio cuenta de que los
navegadores proporcionan mucha información sobre su configuración a la hora de visitar una página web, y que esta información puede utilizarse para identificar al navegador de forma única, y si entendemos que este navegador solo lo utiliza una persona o un conjunto de ellas, podríamos identificar a dicho usuario, o en el peor de los casos a la máquina utilizada.

Como ya sabe, cada navegador tiene unas características diferentes, como pueden ser las fuentes instaladas en la máquina o los plugins (y la configuración de éstos) entre otras. Con esta información, que el propio navegador puede llegar a proporcionar al servidor web cuando se accede a su página web, se puede obtener la huella digital del mismo, pudiendo llegar a ser única. Para poder conseguir esto, en el estudio realizado, decidieron recolectar algunas de las características (comunes y no tan comunes) de los navegadores cuando se visitaba su página web. Una vez se conseguían todos los datos posibles (vistos en la tabla 1), se concatenaban todos con el fin de obtener un identificador para este navegador.

Con este identificador, se creaba una cookie con el fingerprint obtenido y la dirección IP (sin los últimos ocho bits menos significativos) para poder comprobar la siguiente vez que se accedía a la página web si la huella digital generada anteriormente correspondía con la actual o había variado. Por tanto, para poder crear la huella digital de nuestro navegador, se utilizan todas las características que éste contiene y que hace públicas a los servidores con el fin de visualizar lo más correctamente posible la página web solicitada. Estas características son necesarias para dichas páginas, y no podemos “deshacernos” de todas, pero lo que si que podemos es “ocultar” algunas de ellas. Como se describe en el paper, los plugins de Java y Flash son los que más entropía generan, por tanto, son los que identificarán y harán único al navegador más fácilmente. Dicho esto, una de las cosas que podemos hacer, es desactivar todos aquellos plugins que no necesitemos obligatoriamente, para así proporcionar la menos información posible al servidor web. De esta forma, el servidor verá que tenemos los plugins desactivados, pero no llegará a obtener las características de los mismos.

Las cookies son otros de los sistemas que permiten obtener mucha información del navegador (o usuario), ya que cuando se visita una web, el servidor puede crear una cookie y leerla la próxima vez que accedemos a dicha web, y de esta forma obtener la información que detectó en el momento previo.

Javascript es otra de las tecnologías que también tiene una entropía muy grande, ya que dispone de diferentes grados de configuración. Gracias a programas como NoScript, podemos desactivar la ejecución de los scripts y “camuflar” una vez más algunas características de nuestro navegador.

Por último, otra opción que tenemos para dificultar la identificación de nuestro navegador, es hacer modificaciones en los datos que nuestro navegador envía al visitar una página web, ya sea a través
de un proxy personalizado modificando por ejemplo el User-Agent o utilizando proxys públicos como por ejemplo TOR, el cuál tal y como se comenta en el estudio es uno de los proxys que mejor funcionan para impedir crear nuestra huella digital. Desde la web utilizada para el estudio podemos comprobar como de “único” es nuestro navegador. En mi caso, aún y teniendo desactivado el javascript, en el momento de realizar la prueba el resultado obtenido fue el siguiente:

Y utilizando TOR, el siguiente:

Así que podemos ver claramente la efectividad de usar proxys al visitar una página web para mantener nuestro “anonimato”.

En uno de los últimos portales web que he tenido que desarrollar una de las principales premisas era que tenía que ser muy seguro. El nuevo portal tenía que suplir a una versión hecha en html puro, sin código en el servidor. ¿Para qué cambiar si la versión anterior ya era segura? Tampoco entraré en más detalles pero, ¿os acordáis de esas “bonitas” webs con montones de gifs animados y colores espartanos? Esas páginas eran bonitas al lado de esta. Al grano. Para el desarrollo del nuevo portal se estuvieron haciendo pruebas con varios CMS (Gestores de contenidos) en PHP. ¿Por qué en PHP? Pues porque los recursos del servidor eran limitados, y porque me gusta. Al final nos decantamos por Drupal, ya que ofrecía a priori una robustez y seguridad que otros no. ¡Ah!, y porque me gusta.

Una vez tenía el portal ya bastante terminado, me puse a indagar como podía añadirle más seguridad. Al final, en todos los gestores terminas instalando una infinidad de “plugins” (módulos) hechos por terceros que, aunque sea una comunidad muy rápida en resolver los problemas de seguridad, siempre existe cierto riesgo. Fue entonces cuando di con un módulo de Drupal llamado PHPIDS. El módulo actúa de “envoltorio” del programa PHPIDS.

Encontré también un enlace a howforge dónde se documenta la instalación de éste. Voy a resumir dicha instalación, ya que las bondades de este programa están bien resumidas en este post de Security By Default, y luego voy os explicaré como lo hice en Drupal.

Instalación Básica de PHPIDS

Esta instalación sirve para cualquier aplicación PHP, incluyendo todos sus CMS (Drupal, Joomla, WordPress, Moodle etc…). El ejemplo está realizado en una máquina Debian Squeeze.

1) Descargamos el programa de la web. En estos momentos en su versión 0.7. y descomprimimos el paquete.

$ wget http://phpids.org/files/phpids-0.7.tar.gz
$ tar zxvf phpids-0.7.tar.gz

2) Creamos un directorio en la ruta dónde vayamos a ubicar la web y copiamos la el subdirectorio ‘lib’.

$ mkdir /var/www/phpids
$ mv lib/ /var/www/phpids/

3) En el directorio de la aplicación IDS, creamos ‘tmp’ y le damos permisos de escritura (en este caso hacemos propietario del directorio) al usuario del servidor web (en apache a www-data).

$ mkdir  /var/www/phpids/lib/IDS/tmp
$ chown -R www-data:www-data /var/www/phpids/lib/IDS/tmp

4) Copiamos el archivo IDS/Config/Config.ini.php en Config.ini y modificamos las rutas por defecto.

; PHPIDS Config.ini
...
[General]
 filter_type     = xml
 filter_path     = /var/www/phpids/lib/IDS/default_filter.xml
 tmp_path        = /var/www/phpids/lib/IDS/tmp
 scan_keys       = false
...
[Logging]
 ; file logging
 path            = /var/www/phpids/lib/IDS/tmp/phpids_log.txt
...
[Caching]

 ; caching:      session|file|database|memcached|none
 caching         = file
 expiration_time = 600

 ; file cache
 path            = /var/www/phpids/lib/IDS/tmp/default_filter.cache
...
 ; memcached
 ;host           = localhost
 ;port           = 11211
 ;key_prefix     = PHPIDS
 ;tmp_path       = /var/www/phpids/lib/IDS/tmp/memcache.timestamp

Como prueba de concepto, creamos un pequeño script php que nos muestra un mensaje de OK, si la petición es correcta, o nos muestra una traza del error en caso de un intento de ataque.

<?php
set_include_path(
get_include_path().PATH_SEPARATOR.'/var/www/phpids/lib');
require_once 'IDS/Init.php';
$request = array(
      'REQUEST' => $_REQUEST,
      'GET' => $_GET,
      'POST' => $_POST,
      'COOKIE' => $_COOKIE );
$init = IDS_Init::init('/var/www/phpids/lib/IDS/Config/Config.ini');
$ids = new IDS_Monitor($request, $init);
$result = $ids->run();
if (!$result->isEmpty()) {
   echo $result;
   require_once 'IDS/Log/File.php';
   require_once 'IDS/Log/Composite.php';
   $cLog = new IDS_Log_Composite();
   $cLog->addLogger(IDS_Log_File::getInstance($init));
   $cLog->execute($result);
  }else print(“<h1>Todo OK!</h1>”);
?>

En la web de howforge encontraréis este ejemplo y otros un poco más desarrollados, así como la explicación para poder usar PHPIDA en todas las páginas PHP sin tener que modificar una a una usando la propiedad de PHP auto_prepend_file.

Si no tienes ni idea de este gestor y no quieres tenerla, puedes dejar de leer, ya que a partir de aquí puede que no te interese mucho.

PHPIDS en Drupal

Otra manera de usar PHPIDS es mediante el módulo de Drupal (ver la página de PHPIDS en la web de Drupal). Este módulo permite configurar el programa desde la consola de Drupal y registra los eventos en la base de datos de este, para poder acceder a ellos de una forma más visual. La instalación es bastante sencilla.

1) Descargar el último paquete de PHPIDS si no lo teniamos.
2) Se descomprime el tar en el directorio para las bibliotecas externas de Drupal (/sites/all/libraries/phpids-0.7).
3) Se crea un directorio de archivos temporales de escritura para PHPIDS para almacenar en caché los filtros y se le añade permisos como en el apartado anterior (phpids-0.7/lib/IDS/tmp)
4) Se copia, instala el módulo de Drupal PHPIDS.

En la configuración (http://miweb/es/admin/settings/logging) se establece:

General
PHP-IDS Path: /opt/drupal/sites/all/libraries/phpids-0.7/lib
PHP-IDS Temp Path: /opt/drupal/sites/all/libraries/phpids-0.7/lib/IDS/tmp
Mail impact: 9

Filter settings.
Anonymous users: "Log Anonymous users without actions" 
Authenticated users: "Log Authenticated users users without actions"

El resto se quedan en blanco por el momento.

Con esto ya se tiene instalado y registrando los “accesos indebidos”. No se han tomado medidas, lo único que hacemos es registrar, de manera que si vamos a http://miweb/es/admin/reports/dblog podemos filtrar los eventos de PHPIDS como muestra la figura:

Y si hacemos clic sobre el enlace del mensaje, se puede ver todo el detalle:

En ambos casos se PHPIDS se puede configurar de varias maneras: que registre, que bloquee, distintos grados de seguridad etc. Espero que este post al menos haya servido para mostrar que no es difícil poner un +1 a la seguridad de una web PHP.

Recientemente he tenido la ocasión de leer un artículo titulado “Risky business” (Leah Hoffmann, Communications of the Association for Computing Machinery). Ya os adelanto que poco o nada tiene que ver con la película con la que comparte nombre y que protagoniza Tom Cruise. Este artículo ha sido publicado en la revista CACM (Communications of the Association for Computing Machinery) y como ya hemos hablado de esta revista en un post anterior, aprovecho para indicar que CACM es una publicación mensual con alrededor de 80.000 suscriptores donde podemos encontrar muchos artículos relacionados con la computación y los sistemas de información.

El artículo en cuestión, Risky Business, trata distintas cuestiones relacionadas con los ataques informáticos. Se citan, a modo de ejemplo, algunos de los ataques más sonados del último año:

• Los ciberataques a la compañía “Epsilon” que comprometió millones de cuentas de los empleados de dicha compañía.
• La intrusión en los servidores del Fondo Monetario Internacional. Aunque no se tiene certeza de qué registros pueden haber sido accedidos, un oficial del FMI declaraba que la filtración de información confidencial podría ser “Dinamita política en muchos países”.
• Los ataques desde Jinan (China) comprometieron la seguridad de cuentas de correo GMAIL de altos funcionarios del Gobierno EEUU.
• El robo de datos que sufrió SONY y que ya comentamos en su día en Security Art Work

Expertos en el campo de la seguridad de la información pertenecientes a distintas organizaciones (Carnegie Mellon University, Purdue, Indiana University,…) y compañías del sector TIC como CISCO Systems estudian la evolución de las acciones ilícitas. Las conclusiones de estos estudios indican que se está reduciendo el número de ataques masivos y por el contrario aumenta el número de ataques centrados en un objetivo específico como por ejemplo, los ataques de phishing. En general, se detecta que los robos de información se suelen producir por motivos económicos o políticos. Se estima que la venta de información personal mueve más de 100 millones de dólares anualmente, aunque grupos de hackers como Lulz Security (o LulzSec) realizan ataques por diversión.

Para abordar el problema se plantean diversas líneas de actuación. Éstas son algunas de las que menciona el artículo.

Marco regulatorio legal: Se remarca la importancia de crear un marco legislativo firme en materia de seguridad de la información. En este sentido la Comisión Europea ha propuesto la creación de leyes que permitan responsabilizar a las compañías desarrolladoras de software de los daños que se deriven de las vulnerabilidades o bugs de sus productos.

Personalmente creo que es complicado que esta propuesta tenga éxito. Es cierto que reducir las vulnerabilidades del software contribuye a incrementar la seguridad. No obstante, a la hora de rendir cuentas, es previsible encontrar situaciones complejas en las que en un mismo sistema haya instaladas múltiples aplicaciones susceptibles de contener vulnerabilidades. En esta situación ¿Quién paga el pato? Si la propuesta sigue adelante podemos vaticinar un incremento en la demanda de servicios de peritaje informático.

Incentivar la identificación y notificación de vulnerabilidades. La segunda línea de actuación también tiene que ver con los bugs y vulnerabilidades del software. En este caso se plantea la creación de un fondo entre las compañías que desarrollan software a fin de bonificar a aquellos que identifiquen y notifiquen sus hallazgos. (Actualmente ya se están llevando acciones similares como son, por ejemplo las iniciativas de TippingPoint).

Information sharing. Como viene siendo habitual las iniciativas concretas sobre algún aspecto de la seguridad van acompañadas de actuaciones propias de “information sharing”. Es decir, iniciativas que permitan compartir información entre grupos con los mismos intereses o afectados por un problema común. En este caso particular, se pretende fomentar que se compartan experiencias sobre la detección y resolución de vulnerabilidades.

En mi opinión ésta es una de las líneas de actuación más importantes y que más beneficios puede aportar. Dicho esto, aprovecho la despedida para agradecer la participación de nuestros amigos, compañeros y lectores que respaldan estas iniciativas aportando su granito de arena.

Pasen todos ustedes un buen fin de semana.

Estimados lectores, el post de hoy parte del artículo “Privacy and Security, Security Risks in Next-Generation Emergency Services” escrito por Hannes Tschofenig [ver enlace $] y publicado en Communications of the ACM el pasado noviembre. En éste trataremos de plantear estudiar las implicaciones que conlleva la evolución del servicio 911 de un entorno “analógico” a un entorno “digital” 2.0.

La arquitectura a alto nivel de esta versión 2.0 del servicio 911 fue aprobada en Junio por la National Emergency Number Association (NENA), el nombre elegido es arquitectura “i3” y en ella básicamente se detallada cómo interactúan las redes y servicios para dar soporte a los ciudadanos. Dicha evolución conlleva una serie de riesgos propios de las nuevas tecnologías a soportar tales como los inherentes a la infraestructura del VoIP, o el uso de redes sociales.

En primer lugar me gustaría lanzar una pregunta a los lectores ¿Qué consideran más crítico en un servicio 911 la disponibilidad, la integridad, la confidencialidad, la trazabilidad, la autenticidad? Si me permiten mi humilde opinión, destacaría dos: la disponibilidad y la confidencialidad y ya puesto y si no es excederme apostaría por la disponibilidad. ¿De qué sirve un servicio de emergencia si no puede atender una emergencia dentro de unos tiempos aceptables?

Uno de los riesgos que afectan a la disponibilidad de los actuales servicios 911 son las falsas llamadas de emergencia. ¿Saben ustedes que en ciertos países europeos tienen un tasa de 70% de falsas llamadas sobre las llamadas totales? Es lo que en el argot podríamos considerar una forma de ataque de Denegación de Servicio (DoS). Si tienen en cuenta que en algunos países tienen SLAs referentes a la respuesta de todas las llamadas, esto puede tener un impacto significativo en el servicio.

Otro de los riesgos y dificultades a los que se enfrenta esta migración es la necesidad de localización de la llamada, donde el uso de sistemas basados en IP dificulta la tarea debido al que se hace uso de múltiples diversos proveedores para la prestación del servicio que deben permitir la trazabilidad del identificador mediante enlaces de identificadores. Esto viene dificultado por el hecho de que habitualmente no se suelen implementar sistemas de autenticación suficientemente robustos en servicios de VoIP y mensajería instantánea.

Otro punto a tener en cuenta e influido por el carácter global de Internet son los problemas, dificultades y conflictos legales que surgen entre países con normativas muy dispares en temas como puede ser todo lo referente a protección de datos, y que surgen cuando se hacen necesarias funcionalidades relacionadas con la identificación y la trazabilidad.

A pesar de todo esto, se han desarrollado medidas pendientes de implantar para limitar algunos de estos riesgos, como el protocolo Location-to-Service Translation (LoST) empleado para redirigir llamadas de emergencia a puestos de respuesta oportunos.

Para concluir esta pequeña revisión, las principales barreras a las que se enfrentan la implantación de servicios de emergencia basadas en IP, son las siguientes:

1. No existe un número significativo de ataques debido al escaso grado de implantación de servicios de emergencia basados en IP, lo cual no incentiva a la resolución y estudio de los problemas subyacentes.
2. Los ISPs no ven ventajas económicas para invertir en infraestructuras para garantizar la seguridad de estos servicios.
3. Existe una falta de consenso en el ámbito legal.

Aunque parece evidente que el futuro de los servicios de emergencia pasa por la migración a soluciones IP, queda un largo camino por recorrer para garantizar que las debilidades introducidas por el nuevo paradigma son tratadas de modo adecuado. En cualquier caso, ¿quién sabe que nos depara el futuro? A lo mejor algún día twitteamos un SOS o colgamos una foto pidiendo socorro y somos rescatados.

Who knows…

Siguiendo con la entrada que publicamos ayer sobre empresas que se dedican a recopilar digitalmente información de los usuarios, no podemos olvidar a otrasempresas más del “mundo analógico” que ejercen este tipo de actividades. Muchas veces estamos preocupados, y con razón, por nuestra privacidad en las redes sociales y en la vida real. Sin embargo, descuidamos otros aspectos que también pueden ser dañinos para nosotros o por lo menos bastante molestos. Esto es lo que a mí, que soy bastante cuidadosa con todo el que llama a mi puerta y con las fotos y comentarios que publico, me ha pasado.

Llevo un tiempo pensando en cambiar el seguro de mi coche a otra compañía más barata, así que se me ocurrió la feliz idea de solicitar información a un conocido comparador de seguros, llamémosle COMPARATUS.COM. Tras rellenar un formulario con ciertos datos personales obligatorios, ayer recibí el siguiente email:

Resumiendo un poco el email, además de hacerme un poco la pelota me dicen que para adecuarse mejor a mis necesidades van a utilizar todos mis datos personales para venderlos a otros que me mandarán publicidad y usarán mis datos sin permiso a su conveniencia. Por supuesto, tengo que notificarles que no quiero ese “servicio” que me ofrecen, y no al revés.

Curiosamente, hace un par de meses recibí una llamada en mi móvil (número que supuestamente no tiene más que mi familia y amigos) preguntando por mí (con nombre y apellidos) para ofrecerme productos de una teletienda, a lo que me negué. Aquella vez me pregunté cómo habían conseguido mi número y por supuesto mis datos con tanta precisión, y pensé que había sido mi compañía de teléfono. Como dice el anuncio sobre sacar las migas de la tostadora cuando está enchufada: ¡Error! (o no). Tienen mis datos de alguna vez que he rellenado un formulario y o no he señalado que no quiero recibir publicidad ni que vendan mis datos o les he dicho que no quería y aún así lo han hecho.

Así que la próxima vez que tengáis que rellenar algún formulario, hacedlo con datos falsos. Y por supuesto, desconfiad de todas las promociones y concursos que te regalan una toalla o un MP4 sólo por participar (¿de verdad es necesario dar el DNI para eso?). Ese MP4 que regalan les sale más que gratis vendiendo todos esos datos que recopilan.