=-[ 0x05 ]-==================================================================
=-[ NetSearch Ezine #7 ]-====================================================
=-[ Abrete Sesame  ]-========================================================
=-[ por Memonix ]-===========================================================


 1.INTRODUCCION:
   ------------
 
 Para empezar vayamos por partes, Sesame es una amplia arquitectura de
 seguridad, este sistema de seguridad fue desarrollado en Europa para las 
 aplicaciones en un ambiente de red multiproveedor, es un sistema de 
 autentificacion de ingreso similar al encontrado en Kerberos, a su vez
 tiene varios elementos en comun con este mismo, incorporando muchas 
 capacidades de Kerberos 5 pero elimina muchas de sus limitaciones; aade
 heterogeneidad, acceso a funcionalidades de control de acceso, escalabilidad
 de los sistemas de llave publica, administracion mejorada y un sistema de
 auditoria.

 La principal diferencia entre Sesame y Kerberos es que Sesame usa una clave
 de cifrado publica (la cual no es cubierta por la patente en Europa), 
 permitiendo evitar algunas de las complicaciones operacionales que Kerberos
 experimenta.
 El proyecto Sesame esta fundado por la comision de la Union Europea y por
 la comision del programa RACE de esta misma, sus siglas significan
 "Secure European System For Applications in a Multi-vendor Environment".
 
 Con este articulo se intentaran dar las nociones basicas sobre ambos 
 sistemas, Kerberos y Sesame, viendo las posibles vulnerabilidades de ambos
 sitemas, pudiendo muchas de estar ser solucionadas por Sesame, ademas
 de introducir el sistema Sesame en si, el cual es poco conocido en la
 comunidad hacker, por lo que ha sido poco estudiado en cuanto a posibles
 fallos se refiere. 

 2.KERBEROS:
   --------

 En 1983 se comenzo un proyecto, llamado Proyecto Athena, llevado a cabo
 por el MIT, IBM y Digital , diseado para integrar computadoras en las
 universidades, Athena comenzo con unas 50 minicomputadoras (VAX 11/750 de
 DEC con un Unix de Berkeley 4.2), cada una tenia varias terminales, que
 eran usadas por los estudiantes, ya que su objetivo era permitir a 
 cualquier usuario que estuviese sentado en cualquier ordenador el acceso
 completo a los archivos de la red; a medida que pasaba el tiempo los 
 problemas de espionaje en la red se hicieron patentes, por lo que se 
 necesitaba proteger a los archivos de los estudiantes en un ambiente de
 tiempo compartido.
 La solucion de Athena a este problema de seguridad fue Kerberos, un sistema
 de autentificacion que usa cifrado DES para proteger la informacion en una
 red abierta. Cuando un usuario ingresa al sistema el servidor Kerberos
 entrega un ticket al usuario, este ticket unicamente se puede descifrar
 con la contrasea del usuario y este contiene informacion necesaria para
 obtener tickets adicionales, ya que cada vez que un usuario quiere tener
 acceso a un servicio de red debe presentar un ticket apropiado para ese
 servicio, como es logico estos tickets se cifran antes de ser enviados
 al igual que toda la informacion.
 
 -Autentificacion:
  ~~~~~~~~~~~~~~~
  
 La autentificacion de Kerberos se basa en el conocimiento de las contraseas
 que se almacenan en el servidor Kerberos, a diferencia de las contraseas
 de Unix que se cifran con un algoritmo de un solo sentido que no se puede
 revertir, las contraseas de Kerberos se almacenan en un servidor cifradas
 con un algoritmo de cifrado convencional (DES) para que el servidor pueda
 descifrarlas cuando lo requiera, un usuario prueba su identidad al servidor
 Kerberos al demostrar que conoce su clave.
 El que el servidor  Kerberos tenga acceso a la contrasea descifrada es 
 consecuencia de que no usa cifrado de clave publica, lo que supone una gran
 desventaja, ya que el servidor Kerberos debe ser seguro "fisicamente" y
 "computacionalmente", fisicamente para impedir que un intruso robe el 
 servidor y tenga acceso a las contraseas de los usuarios, y tambien
 computacionalmente ya que si el intruso se convierte en root de nuevo
 puede robar las contraseas.
 Actualmente hay en el mercado dos versiones de Kerberos, la version 4 y la 
 5, habiendo notorias diferencias entre ambos.
 
 En Kerberos 4 la estacion de trabajo envia un mensaje al servidor de 
 autentificacion de Kerberos (teoricamente en Kerberos hay dos servidores
 el de autentificacion y el de servicio de concesion de tickets, pero lo 
 desconozco, si alguien lo sabe que me lo comunique) despues de que se
 introduce la clave de usuario, este mensaje contiene la clave de usuario,
 el servidor Kerberos revisa su base de datos y si es un usuario valido
 le envia un ticket de concesion de tickets que se cifra con la contrasea
 del usuario, la estacion de trabajo intenta descifrar el ticket cifrado
 con la contrasea introducida, si la operacion es exitosa la estacion
 de trabajo olvida la contrasea y usa el ticket de concesion de
 tickets exclusivamente, en caso de que la contrasea sea incorrecta se
 da la oportunidad de introducirla de nuevo.

 Con Kerberos 5 se mejora este sistema ya que la estacion de trabajo 
 espera a que se haya proporcionado la contrasea antes de conectarse al
 servidor; el proceso seria el siguiente, se envia un mensaje al servidor
 de autentificacion de Kerberos que consiste en el nombre de usuario y
 el tiempo actual cifrado con la contrasea. El servidor de autentificacion
 busca el nombre de usuario, determina la contrasea e intenta descifrar
 el tiempo cifrado; si el servidor puede descifrar el tiempo actual crea
 un ticket de concesion de tickets, lo cifra con la contrasea del usuario
 y lo envia de regreso.
 Como se puede apreciar al comparar ambos sistemas, en Kerberos 4 se pretende
 minimizar la cantidad de tiempo que una contrasea del usuario era
 almacenada en la estacion de trabajo, lo que lo hace vulnerable a un 
 ataque de fuerza bruta para hacerse con las contraseas, un intruso podria
 perdirle a un servidor de autentificacion de Kerberos un ticket de concesion
 de tickets para un usuario en particular, luego tratar de descifrar ese 
 ticket mediante el uso de un diccionario.
 Con Kerberos 5 la estacion de trabajo debe demostrar al servidor de 
 autentificacion que el usuario conoce la contrasea correcta del usuario,
 este es un sistema mas seguro, aunque el ticket cifrado de concesion
 de tickets del usuario puede ser interceptado.

 * Proceso de autentificacion inicial de Kerberos:
     

    -------------                          -----------
   | Estacion de |=====================>  | Servidor  |
   | trabajo     |                        | Kerberos  | 
    -------------                          -----------
                    Nombre de usuario


    -------------                           ----------
   | Estacion de |  <===================== | Kerberos |
   | trabajo     |                         |          | 
    -------------                           ----------
                          Ticket (cifrado)


 Una vez que se ha producido el proceso de autentificacion, la estacion de
 trabajo del usuario puede conectarse al servicio de concesion de tickets 
 de Kerberos pudiendo obtener tickets dentro del "universo" de Kerberos.
 Un punto a favor de este sistema es que un intruso que intercepte el ticket 
 enviado al usuario desde el servidor Kerberos no podra beneficiarse de el
 debido a que ya esta cifrado; de la misma forma si el intruso intercepta
 el ticket enviado del servidor Kerberos al servicio de concesion de tickets 
 no sera capaz de utilizarlo ya que esta cifrado con la contrasea del 
 servicio de concesion de tickets.

 Ahora al haber obtenido un ticket de concesion de tickets, se puede
 realizar cualquier operacion que requiera el uso de un servicio
 autentificado, como la simple lectura de unos archivos en el directorio
 base.
 Si estamos en posesion de la version corriente de NFS de Sun, una vez que
 el servidor de archivos exporta su sistema de archivos a una estacion de 
 trabajo, el servidor confia irremediablemente en la estacion de trabajo,
 por lo que si un intruso inicia una sesion en una estacion de trabajo
 como el usuario "joe" tendra acceso a los archvios pertenecientes a joe,
 pero si ahora "joe" se convierte a root en esa misma estacion de trabajo
 cambiara su UID automaticamente al de root, pudiendo tener acceso a todos
 los archivos de este mismo, ya que un servidor normal NFS no tiene ningun 
 mecanismo para detectar y parar esta posible intrusion.

 Pero ahora veamos como tendria lugar este mismo proceso si el servidor NFS
 hubiese sido modificado para usar Kerberos:

 Si un usuario desde una estacion de trabajo Kerberos intenta acceder a sus
 archivos, el sistema operativo de esta misma se conecta con el servicio
 de concesion de tickets y requiere un ticket para el servicio de servidor
 de archivos; este ticket le es enviado al usuario conteniendo otro ticket 
 a su vez cifrado con la contrasea del servicio del servidor de archivos,
 el cual sirve para la solicitud de archivos; este ticket "encapsulado"
 contiene el nombre del usuario autentificado, el tiempo de expiracion
 y la direccion de la estacion de trabajo del usuario, la cual presenta su
 ticket al servicio de servidor de archivos, que es el encargado de
 descifrar el ticket usando la contrasea propia, entonces se construye
 una relacion entre el UID de la estacion de trabajo y un UID en el
 servidor de archivos.
 Como antes todas las solicitudes y tickets que se intercambian estan 
 cifrados.

 * Proceso de comunicacion Estacion de trabajo/Servidor de archivos/Servicio
   de concesion de tickets:


    -------------                          -----------------------
   | Estacion de |                         | Servicio de concesion|
   |             | =====================>  |  de tickets          |
   | trabajo     |                         |                      | 
    -------------                          -----------------------
                   Solicitud del ticket de
                   servicio de archivos (cifrado)


    -------------                           ----------------------
   | Estacion de |                         | Servicio de concesion|
   |             | <=====================  |  de tickets          |
   | trabajo     |                         |                      | 
    -------------                           ----------------------
                   Servicio de archivos (cifrado)

 Como se puede apreciar la contrasea del usuario en ningun momento es 
 transmitida por la red lo que hace que disminuzcan las posibilidades
 de exito por parte de cualquier intruso para la interceptacion de 
 la misma, ademas de que Kerberos usa el tiempo del dia en la solicitud
 para prevenir que cualquier intruso intercepte la peticion de solicitud
 de servicio y la retrasnmita desde el mismo anfitrion pasado un cierto
 tiempo, por lo que se puede afirmar que Kerberos no es vulnerable a ningun
 ataque de los llamados "ataques de reproduccion o de repeticion".

 Pero Kerberos no solo puede ser usado como un sistema de autentificacion,
 ya que tambien puede usarse para asegurar la integridad de los datos, 
 cifrando toda la informacion transmitida por la red, aunque lamentablemente
 en el proyecto Athena solo se usaba el cifrado con informacion muy sensible
 como las contraseas y no con la mayor parte de la transferencia de datos.
 Aun asi Kerberos incorpora medidas adiccionales de seguridad, como son
 la inabilitacion de servicios de red tales como rlogind y telnetd para 
 impedir que un posible intruso ingrese en el sistema mientras un usuario
 legitimo esta siendo autentificado ya que si dos personas estan en sesion
 en una estacion de trabajo al mismo tiempo, estos usuarios pueden intentar
 hacerse pasar por el otro, lo cual suponia una falla de seguridad.

 Actualmente podemos encontrar en el mercado dos versiones de Kerberos,
 Kerberos 4 y Kerberos 5, pudiendo afirmar que Kerberos 4 es mas eficiente
 aunque mas limitado,ya que puede funcionar unicamente sobre redes TCP/IP,
 aun asi esta mucho mas extendido que Kerberos 5, al que ultimamente se le
 esta dando un apoyo cada vez mayor ya que es mas resistente a muchos tipos
 de ataques, ademas de ser mucho mas flexible pudiendo trabajar con
 distintos tipos de redes, a la vez que con esquemas de cifrado distintos
 a DES; por ultimo cabria destacar caracteristicas de seguridad tan
 importantes como el soporte para tickets que expiran pasadas mas de 21
 horas, tickets renovables, etc.

 Otra caracteristica importante de Kerberos es que puede usarse dentro de
 una variedad de esquemas RPC, habiendo versiones disponibles para SunRPC
 y para X Window; aunque es facil el encontrar mejores caracteristicas 
 de seguridad en RCP seguro (AUTH_DES) que en Kerberos como pueden ser que
 RCP seguro almacena en el servidor NIS tanto la clave privada como la 
 publica (ya que usa un sistema de cifrado de clave publica) por lo que no
 es necesario el uso de un servidor de autentificacion fisicamente seguro 
 para establecer la identidad de los usuarios de la red, tambien cabe 
 destacar que RCP seguro esta basado en el sistema de Sun, mientras que
 Kerberos requiere que cada aplicacion sea confeccionada especificamente
 a lo que han contribuido empresas como la OSF o IBM.

 Despues de ver en conjunto al sistema Kerberos es hora de pasar a las
 posibles vulnerabilidades a las que se enfrenta.

 -Vulnerabilidades:
  ~~~~~~~~~~~~~~~~

 Ha habido muchas discusiones acerca de Kerberos y su seguridad, habiendosele
 encontrado limitaciones tanto en los protocolos como en su diseo entero,
 siendo algunos ejemplos los siguientes casos.
 
 1.Si se ingresa en una estacion de trabajo Kerberos durante mas de 8 horas
 los servicios de red suelen dar problemas ya que los tickets generados
 suelen expirar despues de 8 horas, estos tickets se suelen almacenar en el 
 directorio /tmp y se destruyen de manera automatica cuando se acaba la
 sesion, esta tecnica es usada para evitar los ya mencionado ataques de 
 reproduccion, requiriendo que se volviese a ejecutar el programa kinit para
 entregar un nuevo ticket al servicio de concesion de tickets.

 2.Debido a su diseo, cada programa que use Kerberos debe ser modificado,
 este proceso de "kerberizacion" para poder usar los servicios de red es
 muy costoso, suponiendo un gran problema para su satisfactoria implantacion.

 3.Kerberos no trabaja bien en un ambiente de tiempo compartido, ya que esta
 diseado para que haya un usuario por cada estacion de trabajo; pudiendose
 dar el caso de que se produzca un robo de los ticket de un usuario en 
 particular, para ser usados mas tarde para obtener un servicio fraudulento.

 4.Otra vez debido a su diseo, Kerbero requiere de un servidor central 
 seguro que contenga la base de datos maestra de las contraseas lo que 
 supone otro problema para su implantacion en entornos donde se necesita
 un elevado grado de seguridad; a su vez si este servidor suspende su
 servicio la red Kerberos quedaria inutilizable.

 5.De la misma forma, si un servidor se ve comprometido, el sistema entero
 lo esta, lo que muestra una gran falla en el diseo, pudiendo tambien 
 responsabilizar a este hecho de que Kerberos requiere una comunicacion
 sincronica, es decir a la vez con todos los servidores que viene a 
 significar un rendimiento mas bajo del posible.

 6.Kerberos almacena todas las contraseas cifradas con la clave maestra del
 servidor, la cual se suelen encontrar en el mismo disco duro que las
 contraseas cifradas, por lo que si el servidor Kerberos se ve comprometido
 todas las contraseas deberan ser cambiadas.

 7.Una de las mayores vulnerabilidades que se pueden encontrar en Kerberos
 es que es imposible el que la computadora se pueda autentificar a si misma
 ante el usuario, es decir no hay una proteccion aparente para los caballos
 de troya, pudiendose modificar los programas de la estacion de trabajo 
 debido a que muchas de estas tienen copias locales de los programas que
 ejecutan aun encontrandonos en un ambiente de red.


 -Puntos criticos:
  ~~~~~~~~~~~~~~~

 A lo largo del tiempo se han encontrado serios problemas de seguridad en 
 el sistema Kerberos, algunos de los mas destacados o curiosos son:

 1. En ciertos sistemas se puede llegar a comprometer remota y localmente
 la cuenta root si el sistema usa la implementacion KTH (en OpenBSD por 
 defecto), incluso no es necesario que el sistema este configurado
 especificamente para usar Kerberos para que algunas de estas
 vulnerabilidades no sean explotadas aunque haya sido desactivado en el
 archivo krb.conf.

 2.En la version del MIT se puede observar que el codigo compatible de
 de Kerberos 4 en la version 5 tiene varios fallos; por ejemplo se podria
 decir que la version de telnetd usada en muchos sistemas Linux no transfiere
 las variables "Krb_Conf" y Krb_Realms" al proceso login.

 3. La variable "krb4_proxy" es usada sin reparar en que el proceso se usa
 con el permiso SUID, un usuario local puede preparar la variable para
 interceptar la autentica solicitud con su propio proxy y generar una falsa
 respuesta; en conjunto con ciertos buffer overflow puede llevar a 
 comprometer la cuenta root. Esta variable es usada cuando una peticion de
 autentificacion esta empezando a ser enviada, siendo necesario que el
 sistema este configurado para usar Kerberos para que pueda ser explotable.

 4. La variable "krb4_proxy" tambien puede ser importada a traves de una
 sesion telnet para engaar al proceso login de la misma forma, esto es
 posible sin tener una cuenta local en el sistema aunque puede que esto no 
 sea posible sin explotar un buffer overflow, pudiendo evitar el chequeo de
 la contrasea pero encontrando la complicacion de que el programa login 
 hace un chequeo adicional para averiguar si esta contactando con un
 servidor falso. La llave encriptada usada para esto esta contenida en el
 archivo local srvtab, si esta llave pudiese ser recuperada por el falso
 servidor o la verificacion de la peticion pudiera ser validada por este
 mismo entonces seria posible explotar esto si un buffer overflow.

 5. La variable "krbconfdir" es usada si el proceso no se esta ejecutando
 con el permiso SUID, esta variable puede ser introducida mediante una
 sesion telnet para redefinir el directorio que contiene los archivos de 
 configuracion de Kerberos; un usuario local o remoto que sea capaz de poner
 archivos en el sistema podria suplantar los archivos de configuracion
 (krb.conf, krb.extra, krb.realms, srvtab) para ser usados por el programa
 login, el cual al momento de la autentificacion tiene a la vez al usuario
 real y efectivo con uid igual a cero, es ademas posible definir un servidor
 arbitrario de Kerberos el cual pueda decirle al programa login que acepte
 la autentificacion; para que esta opcion fuese explotable el sistema no
 necesitaria estar configurado para usar Kerberos o Kerberos podria estar
 desactivado en el archivo original de configuracion /etc/kerberosIV/krb.conf
 Esta posible via de ataque es posible de realizar en sistemas Linux y 
 OpenBSD con el ultimo paquete compilado de KTH Kerberos; los logins de
 cualquier usuario con una shell valida definida son aceptados cuando se usa
 un password cifrado en el servidor falso. 
 Para conseguir acceso como root un nombre de usuario como nobody.root puede
 ser usado, como simple login root no es usualmente aceptado.

 6. Hay algunos buffer overflow facilmente producibles en las librerias
 de Kerberos, un ejemplo podria ser el siguiente; cuando se analiza la 
 contestacion de autentificacion de un servidor Kerberos una llamada
 memcpy() sin limite de verificacion es realizada, ocurriendo en funcion de
 kdc_reply_cipher(), estando en el archivo lib/krb/kdc_reply.c:

 p += krb_get_int(p, &clen, 2, little_endian);
 cip->length = clen;
 memcpy(cip->dat, p, clen);
 p += clen;

 El codigo lee un valor de 16 bytes de longitud desde el paquete y sin
 chequeos adicionales copia la cantidad de bytes a un buffer limitado en 
 tamao.
 Esto causa un fallo en segmento,aunque no es facil de explotar ya que 
 existe un limite para la maxima longitud de la respuesta que es leida
 desde el servidor (Max_Ktxt_Len, 1250 bytes). La longitud del parametro
 contenido por el paquete puede tomar cualquier valor entre 0 y 65535.
 Tambien existen ciertos buffer overflow que interrumpen el normal 
 funcionamiento del KDC (Key Distribution Center), consiguiendose mediante el
 envio de peticiones erroneas al servidor.

 A su vez tambien podemos encontrar ciertos aspectos que pueden llevar a 
 provocar por parte de un intruso varios tipos de DoS:

 -El buffer usado para almacenar la variable localrealm en la funcion
  process_v4() puede desbordarse, pasando lo mismo con la variable e_msg en
  la funcion kerb_err_reply() y con lastrealm en la funcion set_tgtkey() 

 -El codigo de Auth_Msg_Kdc_Requests no verifica adecuadamente las 
  terminaciones nulas

 -La memoria que ha sido liberada previamente puede ser liberada de nuevo
  inadecuadamente provocando una operacion inestable

 -Otros tipos de ataques podrian llevar a que el KDC generase tickets 
  invalidos o que simplemente se viniese abajo lo que llevaria a que el
  sistema Kerberos quedase inoperativo

 7. Respecto al tema de los buffer overflow podemos encontrarnos con algunos
 mas interesantes que los anteriores los cuales es muy posible que esten
 sin parchear en muchos sistemas permitiendo a un intruso ganar privilegios
 de root en sistemas que usen la autentificacion Kerberos, aadiendo que si
 los servicios vulnerables estan habilitados en el sistema KDC el dominio
 entero puede ser comprometido; los principales son :

 -Buffer overflow en krb_rd_req(); esta presente en la version 4 y 5, tambien
  puede ser explotada localmente mediante el suid v4rcp en Kerberos 5

 -Buffer overflow en krb425_conv_principal(); esta presente en la version 5
  y puede ser explotada en conjunto con el exploit de la vulnerabilidad en
  krb_rd_req() 

 -Buffer overflow en ksu; en la version 5 debido a problemas con la variable
  krb5_parse_name 

 Hay muchos mas pero estos son posiblemente algunos de los mas interesantes

 
 8. Como ya ha sido dicho el sistema Kerberos almacena los tickets en el
 directorio /tmp, aun mas estos tickets son guaradados con un nombre 
 totalmente predecible, un atacante podria crear un enlace simbolico con un
 nombre que Kerberos podria usar, existiendo una race condition que 
 permitiria sobreescibir cualquier archivo del sistema como root, llegando
 al caso de que si se sobreescribiese un archivo critico del sistema se 
 podria provocar un DoS siendo el sistema mas implicado OpenBSD.

 9. En la version 4 de Kerberos podemos encontrar un ejemplo de la eleccion
 erronea de una semilla aleatoria; teoricamente el encontrar y manejar un
 generador de numeros es sencillo pero obtener una semilla aleatoria es algo
 mas complicado ya que hay muchas cosas que cambian constantemente con el
 tiempo pero este cambio es predecible; en la version 4 esta semilla 
 aleatoria fue escogida basandose en la hora del dia aplicandosele una
 operacion XOR junto con otra informacion, esta operacion generaba una 
 semilla de tan solo 20 bits de valores predecibles, lo que permitia y
 permite hacerse con las contraseas en un plazo muy breve de tiempo.

 Como se ve Kerberos es un sistema que puede mejorarse para proporcionar
 seguridad en ambientes de red, aunque el sistema de por si es una gran
 solucion para evitar cualquier tipo de problemas de seguridad.
 Una vez visto es hora de pasar a estudiar el sistema Sesame.


 3.SESAME:
   ------

 La tegnologia Sesame ofrece las siguientes ventajas ademas de las ya 
 mencionadas...

 -Soporta un simple metodo de comunicacion en la red

 -Suministra una identificacion basada en controles de acceso distribuido
 usando firmas digitales mediante certificados de privilegios, pudiendo
 usar opcionalmente delegaciones de autentificacion

 -Soporta una completa proteccion criptografica de las transacciones
 efectuadas entre los usuarios y las aplicaciones remotas

 -Dispone de diferentes controles de seguridad

 -Como ya se dijo puede ser escalable para funcionar bajo grandes redes
 usando un sistema de llave publica

 -Esta diseado mediante los estandares internacionales de la ISO, es un
 sistema abierto

 -Usa los Generic Security Service API (GSS-API) que son ampliamente 
 aceptados, ya que suponen un importante avance en el campo de la seguridad
 en los sistemas abiertos; este interfaz oculta desde sus llamadas los 
 detalles subyacentes de los mecanismos de seguridad utilizados, haciendo
 que las aplicaciones sean mas portables. Los GSS-API a su vez separan la
 eleccion de mecanismos de seguridad de la eleccion de los protocolos de
 comunicacion, es decir su implementacion es posible a traves de cualquier
 metodo de comunicacion, ademas de que el usuario mediante su uso dispone
 de mecanismos transparentes. Resumidamente se podria decir que mediante
 ellos las aplicaciones establecen una relacion de seguridad entre el cliente
 y el servidor, verificando los mensajes enviados entre ambos.

 En la actualidad hay importantes productos de seguridad que se basan en la
 tegnologia Sesame como son por ejemplo el ICL's Access Manager y el
 ISM Access Master de Bull, siendo despues de esta Siemens la compaia
 que mas usa el sistema Sesame en sus productos.
 
 En Sesame incluso los tickets contienen derechos de acceso lo cual no esta
 disponible en Kerberos. 
 Como posibles desventajas se podria decir que Sesame es incluso mas complejo
 que Kerberos, lo cual no es un buen sintoma en un sistema de seguridad.
 Un esquema del sistema Sesame para dar una idea de su complejidad seria
 de la siguiente forma:

              -----------                --
   -------   |           |   --- ------ |AS|
  |Usuario|--|    US     |--|APA|        --
   -------   |           |   --- ------ |PAS|
              -----------                ---
                  |             +-------|KDS| 
                  |             |        ---
                  |             |                ---
                  |             |               |PVF|
                  |             |                ---
                  |             |                 |
                  |            ----              ----
                  +-----------|SACM|------------|SACM| 
                               ----              ----
                                 |                 |
                             ----------        ----------
                            |Aplicacion|      |Aplicacion|   
                            |   del    |------|   del    |
                            | cliente  |      | servidor |
                             ----------        ----------


 El proceso empezaria cuando el usuario se conecta al US (User Sponsor) el
 cual conecta con el Servidor de Autentificacion (AS) mediante el cliente
 APA (Authentication Privilege Attribute). El US se autentifica a si mismo
 ante el AS, entonces el US contacta con el PAS (Privilege Attribute Server)
 y recibe un PAC (Privilege Attribute Certificate) que contiene los 
 privilegios del usuario siendo este el encargado de los controles de acceso.
 El usuario una vez que se ha autentificado y ha recibido una PAC puede
 empezar a usar cualquier aplicacion y no como en el caso de Kerberos donde
 la operacion se haria con tickets.
 Cuando el usuario quiere ejecutar una aplicacion el US debe contactar
 con el Secure Association Context Manager (SACM) para la aplicacion del
 cliente, a su vez este SACM contacta con su homologo del lado del
 servidor y intercambian los datos del usuario. EL siguiente paso seria
 cuando el SACM del lado del servidor contacta con el modulo PVF (PAC
 Validation Facility) para chequear el PAC del usuario.
 Despues de todo este complicado proceso el usuario puede ejecutar la
 aplicacion requerida y intercambiar datos con el servidor.
  
 Actualmente hay varios proyectos en marcha sobre el sistema Sesame, de los
 cuales varios ya han sido acabados; algunos de estos proyectos son :

 *Transportar Sesame al entorno Solaris y Linux (Red Hat)

 *Sesamizar los siguientes programas: telnet, rlogin, rsh, rcp

 *Usar Sesame para asegurar los protocolos de red RPC (Remote Procedure Call)
  y NFS (Network Filesystem)

 *Tambien para asegurar el servicio Ftp

 -Autentificacion:
  ~~~~~~~~~~~~~~~

 En Sesame cuando un usuario se ha autentificado, obtiene un certificado
 de atributo de privilegios (PAC). El PAC contiene los derechos de acceso
 del usuario, el PAC es una estructura de datos protegida criptograficamente
 y es presentado ante los servidores como evidencia de su autorizacion; en
 sistemas de procesamiento (TP) de transacciones online se usan los controles
 de acceso RBAC que aaden ciertas mejoras respecto a los anteriores, siendo
 la principal que permite decidir quien puede acceder a un particular
 recurso en base a otras caracteristicas distintas a las de la identidad.
 Una de las principales mejoras de seguridad se ha producido en la 
 "sesamizacion" del protocolo RCP, el proceso de autentificacion visto a
 grandes rasgos seria de la siguiente manera :

 *Usando Auth Unix que no contendria mejoras significativas:


        Servidor                                       Cliente
        ~~~~~~~~                                       ~~~~~~~

   Servidor registrado como
          UDP y TCP
              |
              |
              v
 +--> Listo para peticiones  <------------------- Se crea un enlace con el
 |no                                              servidor (clnt_create())
 |                                                            |
 +---Hay alguna peticion                                      |
            |                                                 |
            | si                                              |
            v                                chan1            v
 +-> Si el servicio es requerido             <---+ Se solicita un servicio               
 |   (las funciones de respuesta son permitidas               | 
 |    una vez que se han verificado los niveles               |
 |    UID / GID)                                              | 
 |           |             chan2                              v
 +-----------+------------------------> Se reciben los resultados desde el
    Se aseguran mas servicio hasta      servicio
    que una peticion DESTROY                |   Cuando hemos terminado
    es enviada                              |   mandamos una seal DESTROY 
                                     chan3  |   (auth_destroy())    
                      <---------------------+

 Donde chan1, chan2 y chan3 son canales de redes inseguras. Como se ve se
 realiza un chequeo para asegurarse de que el UID del cliente esta
 autorizado para hacer uso del servidor.

 *Usando RPCSec:


     Servidor                                         Cliente
     ~~~~~~~~                                         ~~~~~~~

 Servidor registrado como
      UDP y TCP    
          |
          |
          v
 Registro del Service_Name
 (rpc_sec_register(SERVICE_NAME))
          |
          |
          v
 +--> Listo para peticiones <------------------- Se crea un enlace con el
 | no                                            servidor (clnt_create()) 
 |                                                        | 
 +-- Hay alguna peticion                                  v
          |                                 Se crea un ambiente seguro
          | si   <---------------------     Autentificacion ante el servidor
          |                                 (authrpcsec_gss_create())
          |                                               |
          |                                               |
          v                             chan1             v
 +-> Si el servicio es requerido      <-------- Se solicita un servicio
 | (las funciones de respuesta son permitidas             |
 |  una vez que se han verificado los niveles             |
 |  UID / GID)                                            v
 | se usan para ello los mecanismos                       |
 | svc_rpcsec_client_attributes(ATTR)                     |
 |            |                   chan2                   v
 +------------+------------------------> Se reciben los resultados desde el
  Se aseguran mas servicios hasta        servicio 
  que una peticion DESTROY                    |
  es enviada                                  | Cuando hemos terminado
                                      chan3   | mandamos una seal DESTROY
                            <-----------------+ (authrpcsec_destroy())   


 En este caso se usan mecanismos de autentificacion basados en los GSS-API
 de Sesame, donde chan1,chan2 y chan3 son asegurados por los contextos de 
 seguridad de Sesame, siendo capaces de asegurar los datos de las 
 siguientes formas None / Integrity Only / Integrity & Privacy siendo menos
 susceptibles a sufrir ataques.
 Las funciones con cierta importancia en el proceso son :

 1.rpc_sec_register(Service_Name):
 Sirve para registrar el nombre del servicio que es el que esta siendo usado
 en la base de datos del KDC

 2.authrpcsec_gss_create(Client, Service_Name, Authrpcsec_Service):
 Esta funcion crea el ambiente de seguridad entre el servidor y el cliente
 sirve para asegurar cualquier servicio que sea requerido mediante la
 funcion Auth_Rpcsec_Service	
 
 Auth_Rpcsec_Service puede tomar uno de los siguientes valores :
  
 -Rpc_Gss_Svc_None          datos transmitidos en claro
 -Rpc_Gss_Svc_Integrity     la integridad de los datos es protegida
 -Rpc_Gss_Svc_Privacy       la integridad y privacidad de los datos es
                            protegida   

 3.svc_rpcsec_client_attributes(Attribute):
 Esta funcion es usada para configurar las caracteristicas de seguridad
 contenidas en el PAC

 4.authrpcsec_destroy(Client):
 Es usada para pedir que el ambiente de seguridad sea roto al igual que
 las estructuras Client y Auth sean borradas


 -Vulnerabilidades:
  ~~~~~~~~~~~~~~~~

 Aunque es cierto que hasta la fecha se han encontrado pocos fallos en el
 sistema Sesame por no decir que no se han encontrado, como en cualquier 
 otro sistema de seguridad estos fallos simplemente estan esperando a ser
 descubiertos ademas de contar con que es un sitema mucho mas complejo que
 Kerberos lo que no es un buen presagio ya que complejidad y seguridad
 generalmente no se llevan bien; a continuacion comentare algunas de sus
 posibles desventajas, puede que sean de menor magnitud que las
 encontrados en otros sistemas pero ahi estan para quien quiera ver 
 "mas alla".
 
 1.En algunos sistemas con conexion a Internet se ha encontrado que
 Sesame empieza la conexion automaticamente sin que esta opcion hubiese sido
 habilitada por el usuario, se lanzo un parche para corregir este defecto
 pero aun asi en muchos sistemas se sigue reproduciendo, la verdad es que no
 le encuentro explicacion pero ahi queda.

 2.En un sistema con un administrador poco precavido cualquier usuario del
 grupo "sesame" puede ejecutar con privilegios de root el servidor pvf
 encargado del controlar el acceso a las aplicaciones, esto se conseguiria
 habilitando el bit setuid en los programas ses_login y rc.sesame.

 3.Al igual que Kerberos Sesame requiere de una comunicacion sincronica, si
 un servidor se ve comprometido el sistema en si tendra problemas para
 funcionar, teniendo a su vez mas estados que Kerberos lo que puede
 suponer una desventaja.

 4.En un sistema con Sesame solo deberia de ser posible acceder a los
 servidores desde root y una vez hecho esto el servidor deberia cambiar
 su userid efectivo a sesadm, esto implicaria una mejor proteccion del
 sistema, pero en cambio esta opcion no viene por defecto siendo muy comun
 el olvidarse de activarla.


 4.CONCLUSION:
   ----------

 Como se ve cada sistema tiene pros y contras sobre el otro, ambos sistemas
 de seguridad estan basados en el paradigma cliente - servidor mientras
 que ultimamente se han introducido en el mercado nuevos paradigmas muy
 distintos, asi que solo cabe esperar si tanto Kerberos como Sesame tendran
 un lugar reservado en el nuevo panorama que se avecina.

 Espero que este articulo haya servido para dar a conocer el sistema
 Sesame, un gran desconocido, a grandes rasgos asi como dar un repaso al 
 sistema Kerberos conocido por todos.
 Un saludo.

                     "The future is now, forget the past!"                                     
 

                       Memonix <memonix@bigfoot.com> 

