=-[ 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>