Evasión en IDS (III)

Tal como vimos en la anterior entrada, una forma sencilla de evadir el motor de reglas es emplear distintas codificaciones para intentar que el ataque no coincida con el patrón buscado por el IDS. Junto a lo visto con anterioridad, existen otros métodos sobre el protocolo TCP/IP para intentar evadir el motor de reglas. Veremos cuatro de los principales métodos de evasión a nivel de TDP/IP:

Explotar el tiempo de vida (TTL)

El TTL es un campo de las cabecera TCP/IP que se encarga de evitar que un paquete permanezca en la red para siempre. El TTL es un campo de 8 bits que indica el número máximo de enrutadores por los cuales puede pasar. Al llegar a un enrutador el TTL disminuye en 1, si el número resultante después de restarle 1 es igual a 0 el paquete es descartado, informando al emisor con un paquete ICMP de tipo Time Exceeded Message. A muchos de ustedes les sonará el campo porque es empleado por herramientas de tipo traceroute (véase esta entrada sobre las curiosidades del traceroute) para conocer los enrutadores por los que pasamos antes de llegar a nuestro destino.

[Read more…]

Hacking RFID, rompiendo la seguridad de Mifare (IV)

En este post vamos, por fin, a poder obtener las claves de un tag Mifare Classic para posteriormente leer el contenido, escribir… Para ello, partimos de la base que ya tenemos las librerías instaladas tal y como dijimos en el anterior post, y que detectamos el lector (si tenéis problemas con esto, decidlo en los comentarios).

Vamos ahora a instalar las herramientas que necesitaremos. La primera de ellas se llama mfcuk e implementa el ataque llamado “darkside” descrito en http://eprint.iacr.org/2009/137.pdf. Este ataque aprovecha la poca entropía que se utiliza en el cifrado Crypto-1 para obtener mediante fuerza bruta la clave de un sector.

svn checkout http://mfcuk.googlecode.com/svn/trunk/ mfcuk-read-only

(para la versión 1.3.4 de libnfc, 
svn checkout http://mfcuk.googlecode.com/svn/trunk/ mfcuk -r r37)

cd mfcuk-read-only
autoreconf -vis
./configure
make
sudo make install

Una vez instalado, lo ejecutamos con la orden:

mfcuk_keyrecovery_darkside -C -v 2 -R 3:A -M 8

-C     Para realizar la conexión
-v 2   Modo very verbose
-R 3:A Recuperar la clave A del sector 3
-M 8   Tipo de tag Mifare Classic 1K

Obtenemos el siguiente resultado:

Donde vemos que ha encontrado la clave A del sector 3. Este ataque, según los creadores dura unos 5 minutos, pero en mis pruebas no ha bajado de 20. Como veis, obtener las 30 claves (en el caso que sean todas diferentes) nos podría llevar demasiado tiempo. Ahora vamos a utilizar el programa mfoc para obtener todas las demás claves. Mfoc utiliza el llamado “Nested-Authentication attack” que se basa en el conocimiento de una clave para atacar a los sectores restantes. Su instalación es la siguiente:

wget http://micmd.googlecode.com/files/mfoc-new.tar
cd mfoc
autoreconf -vis
./configure
make 
sudo make install

Para usar la clave que hemos obtenido anteriormente hay que volver a compilar el archivo mfoc.c que está en ./mfoc/src/mfoc.c y buscar el vector de claves por defecto:

imagen1

Solo hay que añadir la clave siguiendo el mismo patrón. Luego hacemos un:

gcc mfoc.c -o mfoc

y ya lo tenemos a punto.

La ejecución del programa, yo la he hecho de la siguiente forma:

mfoc -P 100 -O salida.mdf

-P 100     Reintentos
-O         Archivo de salida

Veremos algo como esto:

Esta parte todavía no es el ataque; aquí mfoc está comprobando si las claves que tiene por defecto funcionan con algún sector. Primero hace una pasada probando las claves A. Como se deduce, la clave a884…. es la clave A del sector 0. Después de esto, empezará el ataque donde irá obteniendo las claves una a una. En el caso de que las obtenga todas en las 100 repeticiones, hará el volcado del tag en el archivo salida.mdf. Sí no, yo recomiendo apuntar las claves e ir introduciéndolas en el archivo mfoc.c.

Por último, una vez tengamos todas las claves podemos crearnos con un editor hexadecimal un archivo llamado keys.mdf. Este archivo lo podemos crear a partir del salida.mdf poniendo todo a ceros excepto los sectores tráiler de cada bloque. Con este archivo keys.mdf ya podemos operar con el tag con las funciones de la librería libnfc:

nfc-mfclassic w a contenido_nuevo.mdf keys.mdf

w                       Escritura
a                       Clave A
contenido_nuevo.mdf     Archivo de entrada
keys.mdf                Archivo con las claves

Con esta última orden hemos escrito un tag Mifare Classic con un contenido modificado, con lo que termina esta entrada y de momento (por mi parte) las entradas sobre seguridad en Mifare Classic. Si algún lector intenta llevar a cabo lo aquí explicado y tiene problemas, estaré encantado de ayudarle en los comentarios.

Evasión en IDS (II)

Después de unas largas vacaciones, vamos a continuar con el apartado de evasión de IDS que comenzamos hace un par de meses. Tal como vimos, existen distintos vectores de ataques para intentar evadir o denegar el servicio en los entornos de detección de intrusos a nivel de red. El principal objetivo del atacante es evadir el motor de reglas del IDS, de tal forma que el ataque es modificado para que el patrón de búsqueda del motor de reglas no reconozca el ataque como tal, pero sí que sea ejecutado por el servidor víctima.

Para que resulte más sencillo de explicar, vamos a introducirnos en el papel de un atacante en un ejemplo típico de evasión de IDS. Imaginemos que auditando un entorno web hemos detectado que hay un recurso vulnerable (index.php) que permite obtener ficheros de la máquina, y en este caso querremos obtener el fichero “passwd” del directorio “etc”. La consulta web que realizaríamos seria de este estilo:

http://servidorVictima/index.php?=/etc/passwd

Al realizar la consulta, vemos que el paquete es rechazado por un IDS (IPS) puesto que éste busca la cadena “/etc/passwd” y si la detecta rechaza el paquete. Nuestra intención como atacantes es pues explotar los distintos posibles vectores de ataques que evadan el IDS y nos permitan obtener el fichero “/etc/passwd”.

El primer tipo de vector de ataque será modificar la cadena “/etc/passwd” para que no sea interpretada por el IDS pero si por el servidor. Este tipo de vector de ataque se dividen principalmente en tres grupos:

1) Interpretación incorrecta del protocolo

Este vector de ataque es muy común en metadatos y servidor Web. Consiste en inyectar en el paquete cabeceras repetidas donde solo una de ellas, normalmente la última, contiene realmente la cabecera que quiere ser explotada por el atacante. Siguiendo el ejemplo anterior, un posible vector de ataque para intentar explotar la vulnerabilidad del servidor web sería enviando una solicitud con el siguiente contenido:

GET / HTTP/1.0
Host: www.servidorVictima
GET /index.php?=/etc/passwd
Host: www.servidorVictima

2) Modificación del direccionamiento

Existen métodos para introducir otros caracteres en la cadena que se quiere explotar, sin que esto altere el dato solicitado al servidor, de tal forma que el servidor al ejecutarlo nos permita acceder al recurso solicitado y a su vez, engañar al IDS al no coincidir con el patrón buscado:

/index.php?=/./etc/./passwd
/index.php?=/cadenamuylargaparaengañaralIDSynosigaleyendo/../etc/passwd
<tab>/index.php?=/etc/passwd </tab> (Empleado para otro tipo de evasión)
/index.php?=/etc\passwd

Codificación de los caracteres

Otro vector de ataque muy conocido consiste en emplear codificaciones que son interpretadas por distintos servicios pero no así por el IDS. Esto es debido a que algunos servicios soportan codificaciones no estipuladas en el estándar RFC. Por tanto, un IDS debe tener soportes para tantas codificaciones como soporten los distintos servicios, ya que de lo contrario, nosotros como atacantes podríamos evadir el IDS empleando una codificarción no soportada por el IDS pero sí por el servidor, tal como se describe en el paper de Daniel J. Roelker: HTTP IDS Evasion Revisited.

Por ello, dependiendo del servidor existen distintas codificaciones para representar caracteres y de esta forma, poder representar el vector de ataque que queremos realizar. En la siguiente tabla se representa un ejemplo sencillo de como se podría representaría el carácter A (no todos los servicios soportan las mismas codificaciones):

ASCII A
Hex Encoding %41 (41 es el carácter A en hexadecimal)
Percent Hex %2541 (%25 es el carácter % por lo que se nos queda %41)
Double Nibble %%34%31 (%34 es 4, %31 es 1 quedando %41)
First Nibble %%341 (dec %34 como 4 y queda %41)
Second Nibble %4%31 (dec %31 como 1 y queda %41)

En el caso del ejemplo, si quisiéramos representar el “/etc/passwd” en cualquiera de las codificaciones anteriores sería de la siguiente forma:

ASCII /etc/passwd

Hex Encoding %2f%65%74%63%2f%70%61%73%73%77%64
Percent Hex %252f%2565%2574%2563%252f%2570%2561…
Double Nibble %%32%66%%36%35%%37%34%%36%33%%32%66…
First Nibble %%32f%%365%%374%%363%%32f…
Second Nibble %2%%66%6%%35%7%%34%6%%33%2%%66…

Otra forma típica de evadir IDS es aprovechar las primeras características del UTF-8 (Unicode) que permitía representar un mismo carácter de distintas formas, ya que un mismo carácter podía representado con distinto número de bytes. Este fallo fue solventado en el actual estándar UTF8, pero algunos servicios siguen soportando el antiguo estándar. Al respecto, una de las principales ventajas que supone la codificación UTF8 frente a las vistas con anterioridad es la capacidad de emplear el “Bare Byte Unicode Encoding” que permite representar la codificación UTF8 sin necesidad de usar el carácter “%”, lo que le permite saltarse muchos filtros de seguridad.

Debido a lo descrito con anterioridad, los IDS están obligados a emplear normalizadores o preprocesadores, que permitan una representación normalizada del paquete enviado por el usuario, evitando tener que crear firmas para cualquiera de las posibles formas que pudiera adoptar un patrón de ataque. En el caso de Snort y de servidores Web, éste dispone del preprocesador http_inspect, encargado de normalizar las URL solicitadas por los usuarios para intentar eliminar cualquier posibilidad de evasión del IDS. Pero para ello, hay que configurar adecuadamente el preprocesador, indicando las direcciones IP de aquellos servidores que funcionan siguiendo el “estándar” (nótense las comillas, me río yo del estándar) del IIS o de Apache, tal como se describe a continuación:

preprocessor http_inspect_server: server { IP1 IP2 … IPX } profile apache ports { PUERTO1 PUERTO2 … PUERTOX }

preprocessor http_inspect_server: server { IP1 IP2 … IPX } profile iis ports { PUERTO1 PUERTO2 … PUERTOX }

Espero que les haya parecido interesante. En la siguiente entrada trataremos otro vector de ataque consistente en aprovecharse de las cabeceras TCP/IP para evadir IDS. Cualquier comentario es bienvenido.


(N.d.E.) En otro orden de cosas, Román Soft nos hace llegar la siguiente nota de prensa, relacionada con un concurso de seguridad que seguro que les parecerá interesante:

Buenas tardes,

El viernes próximo (17/Sep, 20h CEST) dará comienzo un concurso de seguridad web (para que nos entendamos: a lo “Boinas Negras”) que he organizado aprovechando algunas pruebas web que diseñamos Dreyer y yo con motivo del pasado CTF de la RootedCON’2010, y que tiene como premio el nuevo iPod touch de Apple (esto es, el 4G), cortesía de Hispasec Sistemas.

Podéis encontrar más info aquí (el periodo de inscripción ya está abierto): http://www.rs-labs.com/noticias/#38

Aclarar que se trata de una iniciativa propia ya que yo ya NO tengo nada que ver con RootedCON desde hace aproximadamente 6 meses (dejé el proyecto tras concluir la primera edición del congreso).

Por último, aprovecho para comentar que el pasado fin de semana publiqué además los resultados del *pasado* CTF, junto a otros detalles.

En fin, que os animo a participar en el concurso y a luchar por el precioso iPod… ¡que además vendrá con dedicatoria incluida (a láser)!

Mucha suerte a todos.

Seguridad en Cloud computing

He decidido poner el término Cloud computing en el titulo del post para tener mas visitas, ya que es un termino de moda, pero si me disculpan la pequeña “trampa”, en su lugar voy a hablar de la seguridad en Infraestructuras compartidas, que es un tema tanto o más interesante en seguridad.

Cuando hablamos de Infraestructuras compartidas nos referimos a la serie de infraestructuras TI que en cualquier organización son compartidas por diversos proyectos. Por ejemplo es habitual que se comparta la infraestructura de red, el almacenamiento en una cabina de discos, o los mismos servidores físicos mediante virtualización; si es un proveedor de servicios el que ofrece la infraestructura, estos elementos estarán compartidos además entre diversos clientes que en si mismo son organizaciones diferentes (vamos, el servicio de hosting de toda la vida).

Así pues, vamos a comentar diversas vulnerabilidades que con las medidas adecuadas están contempladas y en teoría resueltas, pero que son en todo caso posibles vulnerabilidades que pueden aparecer cuando se comparten infraestructuras.

Infraestructura de red compartida: No es difícil imaginar un escenario donde tenemos varios servidores conectados a la misma infraestructura de red, donde, si todo se configura bien no deberían haber problemas, pero si se configura mal, pueden pasar entre otras las siguientes cosas: (1)

  • Sniffing: Un equipo puede ver el trafico del equipo de al lado; esto puede pasar si están conectados al mismo switch y no se han tomado las necesarias precauciones (arp posisoning).
  • DOS: Al estar un equipo próximo a otro, puede atacarlo con un gran ancho de banda o un gran numero de conexiones.
  • Interceptar/sustituir: Es posible que un equipo pueda suplantar a otro (p.e. cambiando la IP) para interceptar el trafico o suplantar respuestas.
  • Atacar: Es posible que al compartir una misma infraestructura de red, desde dentro de la misma red (por ejemplo dentro de la misma DMZ) los equipos puedan atacar a los otros, teniendo mas visibilidad de servicios que desde el exterior están cerrados. Una descripción de cómo hacer esto pueden encontrarla aquí.

¿Están las infraestructuras de red compartidas convenientemente independizadas en los servicios de hosting y de Cloud?

Infraestructura de disco compartida: En cualquier infraestructura TI, es habitual que se disponga de una cabina de disco (SAN/NAS) a la que se conectan todos los servidores (desde servidores internos, hasta servidores de la DMZ)(2)

  • Acceso a datos (no autorizados): Técnicamente es posible que un servidor se conecte al disco de otro servidor si comparte cabina, con lo que podría leer o incluso alterar los datos. Las cabinas de disco normalmente limitan qué servidor puede conectar a qué parte de disco, basándose en la direccion “MAC” (se llama WWN) de la tarjeta. ¿Podría un hacker cambiar esa dirección? ¿Tenemos hard-zoning para evitar este ataque? Aun no he visto ninguna instalación en que se configure hard-zoning ya que es bastante mas incómodo. Si piensa que es muy raro que todos los servidores tengan acceso a los mismos discos, piense en todos sus servidores host de virtualizacion que pueden acceder a todos los discos del cluster.
  • DOS/Carga: ¿Qué pasa si un servidor monopoliza todos los recursos?
  • Acceso a datos borrados: ¿Qué pasa si montamos una unidad de disco en el servidor de un cliente y luego la conectamos a otro servidor de otro cliente? ¿Si leemos el disco vemos los datos del otro cliente? Muchos me diréis que es una posibilidad muy extraña ya que las cabinas de discos limpian las LUNs antes de asignarlas, pero esto “se le paso” a Amazon Ec2.

¿Están las infraestructuras de almacenamiento convenientemente independizadas en los servicios de hosting y de Cloud? (3)

  • Virtualización: Cualquier entorno TI de hoy en día dispone de servidores virtualizados, ya que es una de la manera mas efectivas de compartir recursos, garantizar la disponibilidad, ahorrar energía y muchas otras cosas. Numerosos sistemas Cloud (IAAS) están basados fundamentalmente en sistemas virtualizados, con APIs de autoprovisionamiento. Veamos algunos de los ataques que se pueden realizar en este tipo de entornos.
    • Ataques de guest a host: Ya han aparecido vulnerabilidades mediante las cuales un guest ha podido ejecutar código en el espacio del host, y por lo tanto desde un servidor virtual es posible atacar a otras maquinas virtuales. Véase este enlace para más detalles.
    • Consolas remotas compartidas (el “control panel” del cloud): Si tenemos un sistema de virtualización compartido, al cual accedemos desde una consola de gestión remota a través de Internet, ¿qué pasa si esta consola de gestión tiene alguna vulnerabilidad y alguien coge el control? Pueden haber muchos posibles problemas, desde vulnerabilidades de la aplicación de gestión remota (XSS para robo de sesión sería un ataque viable) a posibles pérdidas de credenciales. La autenticación de estos sistemas por ahora es simple y sin dispositivos robustos. Otro vector de ataque pueden ser las APIs de gestión de ofrecidas por los servicios de cloud, ya que mediante estas APIs se pueden crear o destruir servidores; ¿seguro que no hay vulnerabilidades mediante las cuales se puedan crear o destruir servidores de otro cliente?
    • Carga/DOS/QOS: ¿Qué pasa si un cliente monopoliza todos los recursos?
    • Vulnerabilidades del host (desde fuera, o desde los guests): El host es otro sistema que puede ser atacado, bien desde donde sea accesible (consola de gestión p.e.) o bien desde los propios guest que debido a alguna vulnerabilidad son capaces de coger control de host. Dicho de otra forma, aunque uno pueda tener su servidor web y sus aplicativos securizados, quizá el host que los alberga no lo está.
  • Servidores web/servidores de aplicaciones compartidos: Es habitual compartir el mismo servidor de aplicaciones entre diversos proyectos, pero hay que contemplar los problemas que nos podemos encontrar:(4)
    • Tienen acceso al mismo almacenamiento.
    • Son el mismo usuario de maquina/BBDD/memoria.
    • QOS: Puede un usuario degradar el rendimiento de todos los usuarios.

    Un ejemplo de estos servicios en la nube son: Windows azure o Google Application Engine.

¿Están las infraestructuras de virtualización convenientemente independizadas en los servicios de hosting y de Cloud?

Hosting/Aplicaciones SAAS compartidas: Dentro de lo que está tan de moda del cloud, también se incluyen de alguna manera las aplicaciones compartidas modelo cloud (SAAS). En el fondo, éste es el modelo mas antiguo de hosting, en el que las aplicaciones originales eran servidores web, servidores de correo compartidos entre diversos clientes. Hoy en día se ofrecen aplicaciones mas elaboradas que ofrecen más valor a las organizaciones. Veamos qué problemas nos podemos encontrar en estos modelos.

Imagínese que comparte aplicación entre “perfiles” o clientes. Es posible que dos usuarios de la misma aplicación, por algún error de diseño de ésta, tengan acceso a lectura o modificación de otro usuario. Por ejemplo, recordarán que hace poco sucedió que un usuario de facebook podía ver cualquier conversación del chat de otro. Así pues, si usamos de manera compartida una “aplicación” SAAS, nos podemos encontrar con posibles problemas si no ésta no está bien implementada. ¿Podría pasar que en nuestro CRM en SAAS por un error de programación pudiéramos ver los clientes de otra empresa también albergada en este SAAS? Facebook tuvo una vulnerabilidad con la que podías ver los chats de otros usuarios.

¿Están las aplicaciones convenientemente independizadas en los servicios de hosting y de Cloud? (5)

Mira por dónde, sin quererlo, he acabado hablando de Cloud Computing, nada nuevo respecto a lo que ya conocemos en cuanto a infraestructuras compartidas, pero sin duda una novedad en cuanto a que está todo junto, con las ventajas que esto aporta, pero con el añadido que hay que considerarlo todo conjuntamente.

Por repasar los tipos de Cloud existentes:

  • IAAS, Infraestructure as a service: básicamente podríamos decir que tenemos una macroplataforma virtualizada bajo demanda (1)(2)(3).
  • PAAS, Platform as a Service: tenemos una especie de servidor de aplicaciones distribuido y autoescalable (4).
  • SAAS, Software as a Service: tenemos una aplicación general la cual nos da servicio (5).

En este post hemos revisado algunas vulnerabilidades desde un punto de vista técnico que aparecen si compartimos infraestructuras. Desde el punto de vista de control sobre los servicios externalizados y concentrados en datacenters de megacorporaciones también hay mucho que hablar, y por otro lado los proveedores de sistemas virtuales están redefiniendo sus productos haciendo que cada vez se parezcan mas a una nube “privada” en cuanto a que se dispone de unas infraestructuras compartidas autogestionadas. Todas la posibles vulnerabilidades mencionadas sólo son posibles puntos de fallo por donde aparecerán vulnerabilidades, que aunque en principio ya están contempladas y cubiertas, debemos contar que irán apareciendo nuevas vulnerabilidades causadas por compartir infraestructura. Si dicha infraestructura es sólo compartida entre proyectos internos de la organización los riesgos son unos, pero si la infraestructura es compartida con no sabemos quién, y disponible en Internet los riesgos son mayores. Esto es lo que hay que saber valorar.

A pesar de ello, los servicios en Cloud son la evolución lógica de hosting (infraestructuras compartidas de toda la vida). Todo lo que tuviera sentido en ese entorno ahora lo puede tener en la nube; en todo caso los proyectos que necesitan una grandísima escalabilidad normalmente están asociados a accesos desde Internet, en cuyo caso la nube tiene todo el sentido del mundo, ya que nos permite acceder a proveedores con grandes capacidades de almacenamiento, ancho de banda y servidores. Es más, me atrevería a apostar que los proveedores serios de Cloud sí tienen en mente que todos los recursos compartidos deben estar independizados, y probablemente sean más conscientes de estos riesgos que los provedores de hosting más tradicionales, con aproximaciones más “ligeras” al Cloud.

Dicho esto, pasen un buen fin de semana, y ¡¡nos vemos en la nube!!

Introducción a RFID (II)

Como pudimos observar en la primera parte de esta introducción publicada hace un par de días, la tecnología RFID plantea nuevas oportunidades de mejorar la eficiencia de los sistemas de uso diario además de añadir comodidad. Pero dichas mejoras conllevan nuevos riesgos para la seguridad por ataques o caídas del servicio, riesgos para la privacidad como acceso ilegitimo a información sensible, y otros riesgos derivados de la exposición a las radiaciones. Dichos riesgos se comentarán un poco mas en profundidad a continuación. Todos los participantes de esta tecnología tienen la responsabilidad de prevenir estos riesgos, desde los responsables de desplegar la tecnología hasta los organismos o los propios usuarios.

Los riesgos para la seguridad son los derivados de acciones que pueden deteriorar, interrumpir o sacar provecho de forma maliciosa del servicio. Podemos citar diversos ataques:

  • La forma mas sencilla de ataque a un sistema RFID es evitar la comunicación entre lector y etiqueta, lo que se consigue introduciendo la etiqueta en una “jaula de Faraday” (en este blog se explicó el efecto Faraday en este post) creando un campo electromagnético que interfiera con el que ha creado el lector. Este ataque puede ser considerando, en otro entorno completamente diferente, como un sistema de protección. Por ejemplo, existen fundas especiales para el pasaporte electrónico que crean una “jaula de Faraday” evitando lecturas no autorizadas de su información.
  • Otro tipo de ataque sería la suplantación, que consiste en enviar información falsa que parece ser válida. De esta manera se podrían obtener productos caros con etiquetas suplantadas de productos mas económicos.
  • Un tercer ataque detectado es la inserción de comandos ejecutables en la memoria de datos de la etiqueta, que podrían inhabilitar lectores y otros elementos permitiendo algún tipo de fraude o una DoS.
  • Por otro lado, si saturamos el sistema enviándole de forma masiva mas datos de los que es capaz de procesar, o somos capaces de anular la comunicación de radiofrecuencia emitiendo ruido potente estaríamos frente a un ataque de denegación de servicio.

Aparte de éstos, también se pueden dar ataques como inyectar código SQL hacia el soporte físico que lee la tarjeta, ataques por inyección de malware o ataques Man in the Middle capaz de vulnerar la confianza mutua en los procesos de comunicación y reemplazar una de las entidades. También se pueden inutilizar las etiquetas sometiéndolas a un fuerte campo electromagnético si disponemos por ejemplo de una antena altamente direccional. Todos estos ataques pueden ser parcial o totalmente mitigados aumentando la capacidad de memoria y procesamiento de las etiquetas, permitiendo de esta manera implementar mecanismos avanzados de seguridad y cifrado.

Para evitar estos riesgos, se recomienda usar etiquetas de sólo lectura o no escribir los datos directamente en ellas, incluir únicamente un código en la etiqueta y el resto de información en una BBDD con mas seguridad, e incluir métodos de autenticación previos al borrado o desactivación de las etiquetas, y para realizar la comunicación entre lector y etiqueta.

Hablemos ahora de los riesgos para la privacidad de los usuarios. En éstos, se usan ataques con técnicas similares a las anteriormente mencionadas pero en los que se accede a la información personal. Este tipo de ataques van desde accesos no permitidos a las etiquetas con datos personales, hasta el rastreo de las acciones o gustos de las personas: accesos a recintos, hábitos, transportes…etc.

Las medidas para evitar los riesgos para la privacidad son una tarea primordial para las organizaciones, y requieren de una adecuada planificación del sistema de información. Al respecto, la Comisión Europea ha aprobado una Recomendación sobre Privacidad en Comunicaciones RFID denominada “On the implementation of privacy and data protection principles in applications supported by radio-frequency identification SEC (2009) 3200 final“, en la que se establecen recomendaciones y buenas practicas para implementar comunicaciones RFID.

Decir también que la Ley orgánica 15/1999 de 13 de diciembre de Protección de Datos de Carácter Personal (LOPD) es directamente aplicable a la tecnología RFID y con ello cada uno de los principios, derechos y obligaciones que regula. Por tanto los desarrolladores de este tipo de productos tiene que tener en cuenta entre otras cosas que:

  • Debe realizarse un juicio previo sobre si realmente es necesario usar tecnología RFID, definir las funcionalidades claramente y adoptarse revisiones en relación con la cancelación posterior de los datos personales recopilados cuando no sean necesarios.
  • Los usuarios deberán ser informados de la existencia del tratamiento que se le da a sus datos personales.
  • Debe garantizarse la seguridad de todos los recursos relacionados con los tratamientos de datos personales vinculados a la tecnología RFID (hardware, software, organizativos…). La implantación de este tipo de tecnologías en territorio español debe respetar las normas del Real decreto 1720/2007.

Por último y no menos importante, deberá tenerse en cuenta el futuro desarrollo de la Directiva 2009/136/CE7 que indica la necesidad de velar por la protección de los derechos fundamentales, y en particular del derecho fundamental a la protección de datos, cuando las etiquetas RFID estén conectadas a redes públicas de comunicaciones electrónicas o usen servicios de comunicaciones electrónicas como infraestructura básica. En este caso, deberán aplicarse las disposiciones pertinentes de la Directiva 2002/58/CE (Directiva sobre la privacidad y las comunicaciones electrónicas), incluidas las relativas a seguridad, datos de tráfico y de localización, y a la confidencialidad.

Cómo recomendaciones finales para los usuarios, para evitar este acceso indeseado a la información existen diversos sistemas:

  • Utilización de etiquetas watchdog. Estas etiquetas informan de intentos de lectura y escritura que se hagan en su área de actuación.
  • Aislamiento. Evitando la lectura de las etiquetas salvo en los momentos que se desee. Para ello, sólo hay que introducir la etiqueta en una funda de material metálico o plástico, que haga la función de “jaula de Faraday” comentada anteriormente.
  • Firewall RFID. Estos dispositivos crean una zona segura alrededor del usuario mediante la emisión de ondas que anulan la efectividad de RFID. Se denominan también inhibidores de radio- frecuencia. Esta solución es aplicable a entornos de máxima seguridad, no compatible con situaciones en las que ciertas lecturas deben ser permitidas y otras no.
  • La inutilización de las etiquetas una vez se haya realizado la transacción, destruyéndola físicamente, o mediante el comando KILL.

Con esto, finaliza la breve y básica introducción a RFID; si quieren indagar más en el tema, pueden seguir con la Guía sobre seguridad y privacidad de la tecnología RFID que ha publicado INTECO, y con los múltiples recursos que ofrece la red sobre esta tecnología tan interesante como potencialmente peligrosa.

Disuasión y ciberdisuasión

gatoSegún el DRAE, la disuasión es la “acción y efecto de disuadir”, y disuadir significa “inducir, mover a alguien con razones a mudar de dictamen o a desistir de un propósito”; básicamente, la disuasión consiste en convencer a alguien, de una u otra forma, para que cambie su manera de actuar. Cuando hablamos de seguridad, las medidas de disuasión son las que tratan de “convencer” a alguien hostil para que cese su actitud -al menos ante nosotros-; en muchos casos, son el efecto colateral de salvaguardas reales, pero en ocasiones se utilizan de forma pura, sin ningún otro mecanismo de seguridad real más allá de la intención de “convencer” a un delincuente de que nos deje tranquilos…

Desde siempre, la disuasión ha sido uno de los pilares básicos de la seguridad, junto aspectos como la prevención, la canalización o la detección; las medidas puramente disuasorias eran habitualmente tan baratas (cámaras de seguridad falsas, carteles de conexión a CRAs inexistentes, desfiles militares con misiles de cartón…o un simple cartel de “Cuidado con el perro”) que justificar (o amortizar) su coste era trivial, así que con una rentabilidad justificada, no había impedimentos para echar mano de estas salvaguardas. Por supuesto, la efectividad de una medida estrictamente disuasoria es cuestionable: volviendo a los ejemplos anteriores, si un potencial atacante descubre que las cámaras son falsas, que no estamos conectados a ninguna CRA, que nuestros misiles se rompen si llueve o que no tenemos perro, tendrá el camino libre hacia su objetivo; así, llegado este punto, la disuasión pura habrá dejado de funcionar y deberán entrar en juego otro tipo de salvaguardas más eficaces… Adicionalmente, otro aspecto de las medidas de disuasión puras es el efecto negativo que pueden llegar a tener; si nuestra casa está plagada de controles de acceso, carteles, etc. puede llegar a convertirse, con o sin razón, en un buen reclamo para un potencial atacante, y en ese caso deberemos disponer de más medidas de seguridad para frenar el ataque. Por tanto, el uso excesivo de medidas disuasorias puede ser, en ocasiones, contraproducente.

[Read more…]

Introducción a RFID

La tecnología RFID (Radio Frequency Identification) permite identificar de manera unívoca automáticamente un objeto gracias a una onda emisora incorporada en el mismo, que transmite por radiofrecuencia los datos identificativos del objeto. Actualmente estamos acostumbrados a encontrar esta tecnología en forma de etiquetas adhesivas, de forma que un objeto con una de estas etiquetas puede ser localizado a una distancia que va desde unos pocos centímetros hasta varios kilómetros, dependiendo de la fiabilidad de varias características de estas etiquetas, como pueden ser la frecuencia de la emisión, la antena o el tipo de chip que se use. En la etiqueta se graban los datos identificativos del objeto al que ésta está pegada, y dicha etiqueta genera una señal de radio que un lector físico se encargaría de recibir, transformar en datos y transmitir dicha información a la aplicación informática especifica (middleware).

La tecnología RFID va dirigida principalmente al sector logístico y al sector de la defensa y seguridad, pero sus beneficios son aplicables a otros ámbitos ya que dispone de múltiples ventajas. Entre otras, podemos citar que permite el almacenamiento de un gran volumen de datos mediante un mecanismo de diminutas dimensiones, automatiza los procesos para mantener la trazabilidad y permite incluir una mayor información a la etiqueta reduciendo así los errores humanos, evita su visibilidad en caso de intento de robo y permite mayor facilidad de retirada de un determinado producto del mercado en caso de que se manifieste un peligro para la seguridad.

Actualmente podemos encontrar dicha tecnología en tiendas de artículos, para identificar los productos y sus precios o como medida de seguridad, en transportes públicos para el control de acceso o de equipajes, en identificación de mascotas implantando un chip subcutáneo, en pago automático de peajes, en bibliotecas, eventos deportivos tipo maratones para identificar corredores, en el ámbito sanitario para control de medicamentos, identificación de muestras, etc.

Basándonos en lo anterior podemos hablar de cuatro componentes básicos en ésta tecnología:

  • Las etiquetas: también conocidas como tags o transpondedores (transmisor+responder). Están compuestas por una antena que se encarga de transmitir la información, un transductor radio que convierte la información que transmite la antena y un microchip capaz de almacenar el numero de identificación y otros datos. Dichas etiquetas tienen un coste de apenas unos céntimos de euro y sus dimensiones son de hasta 0.4 mm². Según la fuente de energía que usen podemos encontrar:
    • Etiquetas pasivas: no necesitan fuente de alimentación interna, son circuitos resonantes. Alcanzan distancias entre unos pocos milímetros y 7 metros. Son de un tamaño menor que el habitual. Se suelen insertar en pegatinas y son las mas baratas del mercado.
    • Etiquetas activas: poseen una batería interna, por lo que su cobertura (cientos de metros) y capacidad de almacenamiento es mayor. Se puede usar en zonas de agua, o con mucha presencia de metales y siguen siendo válidas. Son más fiables y seguras, por lo tanto más caras y de mayor tamaño.
    • Etiquetas semi-pasivas: mezcla de las dos anteriores.

    Según la frecuencia a la que trabajen, las etiquetas se pueden clasificar en baja (125kHz – 134kHz), alta (13,553 MHz – 13,567 MHz ), ultra alta (400 MHz – 1000 MHz ) y microondas (2,45 GHz – 5,4 GHz ). Dicha frecuencia está ligada a diferentes características, como la capacidad de trasmisión de datos, velocidad, radio de cobertura, coste…

  • Lector de RFID: recibe la información emitida por las etiquetas y la transfiere al middleware. Está formado por una antena, un transceptor y un decodificador. Si la etiqueta permite escritura también incorporaría un módulo programador.
  • Middleware: software instalado en un servidor y que hace de intermediario entre el lector y las aplicaciones. Filtra los datos que recibe, para que a las aplicaciones sólo les llegue la información útil.
  • Programadores RFID: dispositivos que realizan la escritura sobre la etiqueta. Codifican la información en un microchip ubicado dentro de la etiqueta RFID.

Además de las aplicaciones citadas anteriormente, se están estudiando otras nuevas aplicaciones de esta tecnología:

  • Pagos electrónicos con móviles a través de la tecnología NFC (Near Field Communication), que permite que un teléfono móvil recupere los datos de una etiqueta RFID. Esto, combinado con medios de pago electrónicos para móviles (Mobipay, Paybox, etc.), permite comprar productos con tal solo acercar el teléfono al punto de información del producto de donde RFID extrae los datos.
  • Pasaportes electrónicos que almacenan la información del titular, fotografía, huella dactilar, etc.
  • Activación de vehículos y maquinaria. La etiqueta actúa en este caso como control de verificación personal.

Como hemos podido observar, la tecnología RFID plantea múltiples e interesantes nuevas oportunidades de mejorar la eficiencia de los sistemas de uso diario además de añadir comodidad, pero dichas mejoras plantean nuevos riesgos, algunos de los cuales veremos en la siguiente entrada de la serie.

(Más información en la Guía sobre seguridad y privacidad de la tecnología RFID que ha publicado INTECO)

Seguridad en SAP

Recientemente recibimos un curso de Seguridad en SAP durante el que se analizaron los aspectos más importantes en la seguridad de estos entornos y los errores más comunes que pueden encontrarse en una implantación SAP. SAP es un sistema de planificación de recursos empresariales o ERP que permiten, mediante módulos, la integración y control de todas las operaciones relacionadas con la compañía, y como podrán imaginarse una reducción de costes para ésta. Se compone de una serie de módulos que realizan una función en concreto, como la gestión de almacenes (WM), producción (PP-PI), gestión de calidad (QM), gestión de materiales (MM), etc. Cada uno de estos módulos proporcionan al entorno SAP un mayor número de funcionalidades. En esta entrada de Security Art Work se comentarán, de forma resumida, los procesos correctores más comunes en el ámbito de la seguridad dentro de un sistema de estas características.

Los aspectos más habituales de seguridad SAP se centran en la parametrización general del sistema, la configuración de transacciones incompatibles desde el punto de vista operativo en el entorno de los procesos de negocio, la segregación de funciones y la gestión de identificación y autenticación de usuarios. Pero antes de comenzar a tratar cada uno de los puntos expuestos con anterioridad, debemos presentar el concepto de mandante. Un mandante es un subsistema o unidad independiente dentro de un sistema SAP. Las acciones que se realizan dentro de cada mandante reciben el nombre de transacción. Éstas son órdenes que llaman a un programa escrito en ABAP, que a su vez realiza transacciones a través del core de SAP, consultando en la mayoría de los casos la base de datos.

Desde el punto de vista de seguridad, los mandantes deben estar cerrados y no permitir las modificaciones a objetos del repositorio y la parametrización no dependiente del mandante. Para ello hay que restringir las transacciones SE06 y SCC4 indicando que no son modificables, no se debe permitir la comparación de customizing ni admitir cambios no dependientes del mandante, se debe seleccionar el nivel 2 de protección e indicar que el rol del mandante es de tipo productivo. Otras transacciones críticas a tener en cuenta a la hora de restringir su acceso son la SV01 (gestión de usuarios), SN01 (transacciones que se pueden realizar) y SCC5 (borrar el mandante).

Los mandantes por defecto en todo sistema SAP son 000, 001 y 066. Si no existe usuario para estos mandantes se podrá acceder a este mediante el usuario SAP* y la contraseña PASS, de la misma forma que si existen los usuarios por defecto, estos serán SAP* y DDIC, con contraseña 06071992 y 19920706 respectivamente. Otros usuarios por defecto son SAPCPIC y EARLYWATCH (sólo mandante 066), todos ellos con permisos de administración. Por tanto es importante en toda implantación SAP -como en toda implantación a secas- cambiar las contraseñas por defecto de dichos usuarios mediante el report RSUSR003.

En el entorno SAP existen una serie de transacciones que deben ser limitadas, incluso impedir desde cualquier usuario su llamada, debido a los riesgos de seguridad que implican. Principalmente se trata de la SE11, SE16, SE30, SA38, SM30, SE16m y SM49, y debemos prestar especial atención a RSBDCOS0, SM38 (shell de sistema), SM49 (creación de órdenes del sistema) y SM59 (ejecución de órdenes en el sistema). Otro punto de control a tener en cuenta son aquellas transacciones desarrolladas a medida para la empresa por un equipo de desarrollo no perteneciente a SAP y que, por tanto, no han pasado por el equipo técnico de calidad de SAP. Estas transacciones se identifican por la primera letra del nombre de la transacción (letra Z o letra Y) y son las llamadas transacciones Z* o Y*. Deben cumplir con unos requerimientos mínimos de seguridad que limiten su ejecución a los usuarios autorizados para ello; estas restricciones específicas se conocen con el nombre de authority-check y sin ellas cualquier usuario con acceso a la transacción de lanzamiento SE38 o SA38 podría ejecutar dichas transacciones (existe el report RSRSCAN1 que permite comprobar si se están realizando los correspondientes comprobaciones de autorización).

Otro aspecto de seguridad en el ámbito de SAP es el relacionado con la gestión de usuarios; de entrada, no se debe permitir a un usuario saltar a otro mandante distinto al asignado, para lo que aquellos usuarios que se conecten de forma remota (ya sea mediante la interfaz Web o mediante el cliente R/3) deben de estar configurados como usuarios de fondo y NO como diálogo. De la misma forma, es recomendable la aplicación de políticas de seguridad que fuercen al uso de contraseñas seguras, por ejemplo empleando la transacción SM30 → USR40 para especificar, mediante expresiones regulares, qué contraseñas no son válidas y un diccionario de palabras no permitidas. Adicionalmente, mediante el uso del report RSPARAM, se pueden parametrizar aspectos como el número de logins incorrectos, longitud mínima de la contraseña, seguimiento de la inactividad, etc.

Finalmente, pero no por ello menos importante, debemos hablar de una segregación de funciones correcta en SAP, que no permita a un determinado usuario acceso a determinadas combinaciones de transacciones; para ayudar en esta segregación de funciones, SAP dispone del report RSVR008_009_NEW, que permite indicar las combinaciones críticas existentes en el sistema.

Seguiremos añadiendo algún post de este mundo -SAP- que hasta el curso que hemos comentado, desconocía por completo y que, una vez hemos comenzado a entrar en él, se adivina inmenso -y conflictivo- desde el punto de vista de su seguridad.

La orden shun

Como cada día 1 de septiembre desde hace unos años, volvemos a la carga con el blog; y como cada día 1 de septiembre desde hace unos años esperamos que las vacaciones hayan sido provechosas en todos los sentidos, que hayan descansado y que vuelvan con las pilas cargadas para los meses que nos quedan (sólo 11) hasta el próximo periodo de descanso estival. Tras el mes de agosto, vamos a comenzar con la marcha habitual en Security Art Work, en este caso con un post de José Luis acerca del filtrado en los dispositivos ASA de Cisco. Vamos allá…

Si en nuestra organización disponemos de un IPS, cuando éste detecta un ataque suele filtrar de forma inmediata el tráfico proveniente de la dirección IP atacante; no obstante, si simplemente tenemos un IDS, una vez que nuestros sistemas de detección han detectado y notificado una actividad potencialmente sospechosa, la primera función que suele llevar a cabo el personal de seguridad es el filtrado manual de las conexiones en el firewall corporativo para, posteriormente, realizar un análisis más minucioso del ataque, una análisis forense e incluso, en caso de ser necesario, proceder a denunciar el hecho ante las FFCCSE. En cualquier caso, la velocidad de respuesta a la hora de llevar a cabo el filtrado de la dirección IP que nos ataca es crítica, ya que cuanto más tiempo pueda tener acceso el atacante a nuestros sistemas, mayor será el daño que nos cause, por ejemplo dejando puertas abiertas para conexiones futuras o directamente robando información.

Aunque debemos tener perfectamente procedimentados y probados los pasos a seguir como respuesta a un ataque -o intento de ataque-, lo cierto es que durante esos momentos de ‘tensión’ lo primero que se suele hacer es, al menos, filtrar todo tipo de acceso desde la IP atacante a nuestros sistemas. En este post se va a tratar una forma rápida y sencilla para llevar a cabo el filtrado de conexiones sospechosas en sistemas firealls ASA de Cisco Systems, los cuales integran otros sistemas como VPN o IPS.

A la hora de integrar un IPS en el sistema ASA, lo habitual es contar con una tarjeta hardware dedicada en el propio equipo o con sensores distribuidos en la red que recopilan la informacion del ataque y envían las órdenes de filtrado al firewall. Puesto que asuminos que no tenemos este tipo de sistemas -si los tuviéramos, el filtrado sería automático, como hemos comentado-, podemos usar directamente la orden shun de ASA para filtrar direcciones concretas de forma cómoda; incluso mediante la creación de varios scripts, podríamos integrar un IDS como Snort con un firewall ASA.

El funcionamiento de la orden shun es sencillo. Su función es básicamente la de finalizar las conexiones ACTUALES y denegar las nuevas conexiones, basándose en una serie de parámetros como pueden ser la dirección IP origen, la dirección o puerto destino, el tipo de protocolo, etc. A su vez, también registra las conexiones filtradas hasta que las direcciones son habilitadas de nuevo en el firewall. Por ejemplo, si nuestro IDS ha detectado un potencial ataque desde una IP externa (para este ejemplo, tomamos la dirección privada 192.168.1.1) hacia nuestro servidor web (con dirección 10.20.20.1), podemos proceder a filtrar la IP externa en nuestro firewall:

ASA# shun 192.168.1.1
Shun 192.168.1.1 successful
401002: Shun added: 192.168.1.1 0.0.0.0 0 0
401004: Shunned packet: 192.168.1.1 ==> 10.20.20.1 on interface outside
401004: Shunned packet: 192.168.1.1 ==> 10.20.20.1 on interface outside
401004: Shunned packet: 192.168.1.1 ==> 10.20.20.1 on interface outside
401004: Shunned packet: 192.168.1.1 ==> 10.20.20.1 on interface outside

Comprobamos que hemos aplicado shunning IDS y aumentan los contadores de tráfico bloqueado:

ASA# show shun stat
outside=ON, cnt=134
inside=OFF, cnt=0
intf2=OFF, cnt=0

Shun 192.168.1.1 cnt=9, time=(0:00:10)

Si en un futuro necesitamos habilitar de nuevo el tráfico desde la dirección IP que hemos bloqueado, podemos hacerlo mediante la siguiente orden:

ASA# no shun 192.168.1.1
401003: Shun deleted: 192.168.1.1

Como vemos, Cisco ASA proporciona una orden rápida y sencilla para bloquear completamente a un atacante en nuestro cortafuegos. Aunque lo ideal es tener un sistema IPS que filtre los ataques de forma automática, en caso de que esto no sea posible, el filtrado manual se vuelve un proceso critico, por lo que debe ser procedimentado y conocido por el personal de seguridad. Y por supuesto debe ser probado de forma periódica, ya que como sabemos, los momentos de tensión son los peores para ponerse a probar…

¡Vacaciones!

Como todos los años, llegan por fin las ansiadas vacaciones de verano para -casi- todos, y en Security Art Work también nos vamos a tomar nuestro (quiero creer que merecido) descanso estival. Y por supuesto, nos despedimos hasta septiembre, al igual que años anteriores, con un post titulado “¡Vacaciones!” cuyo objetivo principal no es otro que desearles un feliz verano y, de paso, agradecerles a todos su participación (escribiendo o leyendo) en nuestro blog.

Echando la vista atrás, durante estos meses han sucedido cosas muy destacables, buenas o malas, en nuestro mundillo; desde la aprobación del Esquema Nacional de Seguridad o la Ley Ómnibus a la primera BlackHat celebrada en España, pasando por los problemas de seguridad en redes sociales o en tecnologías como RFID hasta llegar a temas de Protección de Infraestructuras Críticas o de information sharing, que por fin parece empiezan a calar en nuestro país. Y por supuesto, lamentamos decir que el terrorismo ha seguido siendo noticia estos meses (ETA asesinó este año a un policía francés, y dos ciudadanos españoles permanecen secuestrados en África).

En Security Art Work hemos tratado de hacernos eco de algunos de estos temas; desde aquel post de nuestro compañero Manolo hace ahora unos once meses, titulado El cinturón de seguridad (I) hasta este que publicamos hoy, hemos “colgado” un total de 182 artículos de temática tan dispar como la monitorización de usuarios en Solaris, el RDLOPD, la esteganografía o el Esquema Nacional de Seguridad, por citar sólo unos cuantos, además de series como GOTO o Seguridad Sectorial, que mejor o peor, han tratado de poner de manifiesto realidades o ilusiones que nos encontramos en nuestro día a día todos los que trabajamos en Seguridad (seguiremos con estas series a partir de septiembre, y con alguna otra ;)

Desde aquí queremos también dar la bienvenida a todos los nuevos colaboradores que durante estos meses se han “estrenado” en el blog: Adrián, Alex, Toni, David, Iván, Ximo, José, Maite, Marcos, Pedro, Raúl, Samuel, Sergio… y creo que no se me olvida ninguno (y si se me olvida, perdón por adelantado… será que me hacen falta vacaciones ;). También queremos dar las gracias por su tiempo y sus opiniones a todos los que han escrito en Security Art Work estos meses artículos o comentarios, animando a todos una vez más (nuevos y antiguos, colaboradores ocasionales, lectores habituales…) a participar en el blog, a escribir entradas y opiniones y, sobre todo, a debatir.

Aprovechen las vacaciones para hacer lo que no han podido hacer durante el año, para recargar pilas y para pasarlo bien. Cuiden de su seguridad estos días, sobre todo al volante, y al igual que cuando salen de casa toman ciertas medidas de seguridad para evitar robos, no olviden hacer lo mismo con su información y sus sistemas. Descansen y aprovechen el tiempo (o piérdanlo ;), que las vacaciones se pasan muy rápido y, sin darnos cuenta, estamos de vuelta…

Un saludo para todos y, de nuevo, feliz verano. ¡Hasta septiembre!

(Sí, la foto es la de siempre).