Control de Acceso. 12 de junio de 2002 Control de Acceso-1

Transcripción

1 Control de Acceso El tema de Control de Acceso es el eje tradicional del estudio de seguridad informática, porque trata de mecanismos que operan en cada máquina en forma aislada, usualmente por una combinación del diseño del sistema de operación (SOP) y la arquitectura del hardware. La función del SOP es mediar las interacciones entre los principales previamente autenticados (usuarios, procesos a veces llamados sujetos) y los objetos (archivos, dispositivos... ) que tratan de manipular. 12 de junio de 2002 Control de Acceso-1

2 Protección en el SOP El modelo más general se llama la Matriz de Control de Acceso, ej.: SOP MIDAS Datos Pista Sam r w x r w x r w - r - - Alicia - - x - - x r w Bob r - x r - - r - - r - - MIDAS es un programa de contabilidad, Pista es un archivo con la pista de auditoría. Sam es el administrador del sistema, Alicia la gerente de finanzas, y Bob el auditor. Las entradas expresan los derechos de acceso del sujeto (fila) sobre el objeto (columna) en términos de leer (r), escribir (w), y ejecutar (x). Entonces, Sam puede cambiar todo menos la Pista, Bob sólo puede leer más no cambiar, etc. 12 de junio de 2002 Control de Acceso-2

3 La matriz del ejemplo no refleja lo que queremos, porque Alicia puede modificar los Datos directamente. Mejor sería: SOP MIDAS Datos Pista Sam r w x r w x r - - r - - Alicia r - x - - x MIDAS r - x r - - r w - - w - Bob r - x r - - r - - r - - Nota: ahora MIDAS es un objeto y un sujeto. Esto todavía no es perfecto porque Sam podría sobreescribir a MIDAS con su propio programa de junio de 2002 Control de Acceso-3

4 Grupos y Roles Aunque el modelo de la matriz es teóricamente completo para expresar los controles de acceso, es impráctico para sistemas con muchos sujetos y/o objetos. En sistemas reales, los principales se pueden clasificar en categorías para reducir la complejidad. Hay varias formas de enfocar esto: Grupo: Un conjunto de principales, ej. empleados del departamento de contabilidad. Rol: Un conjunto de derechos de acceso que puede ser asumido por uno o más principales en forma no-permanente, ej. el oficial de guardia. Los enfoques no son contradictorios, pero en la práctica el enfoque de Grupos tiene mucha tradición, mientras el de Roles es más experimental, e implementado más en la semántica de aplicaciones que en el SOP. 12 de junio de 2002 Control de Acceso-4

5 Listas de Control de Acceso Dado que la matriz es casi vacia (la mayoría de los sujetos no tienen derechos sobre la mayoría de los objetos) podemos ganar en eficiencia guardando las entradas no-vacias de cada columna junto con el objeto correspondiente. Esto se llama una lista de control de acceso o ACL. Los ACLs permiten bastante flexibilidad, pero tienen un costo: es dificil saber a cuales objetos un determinado sujeto tiene acceso. En particular, es costoso revocar todos los derechos de un sujeto (por ejemplo cuando se le cancela la cuenta). No obstante, variantes de los ACLs existen en Unix y en Windows NT. La implementación en NT es más compleja y flexible, pero menos probado en el mundo real. Veamos la versión implementada en Unix. 12 de junio de 2002 Control de Acceso-5

6 Capabilities La alternativa a los ACLs es guardar las entradas no-vacias de cada fila junto con el sujeto correspondiente. En este caso las filas se llaman listas de capabilities (un capability es la tupla [{derechos}, objeto]). El uso de capabilities ofrece ventajas de eficiencia al tiempo de ejecución porque el SOP puede chequear inmediatamente si existe un derecho de acceso a un objeto, sin verificar quien es el sujeto. Además, facilita la delegación: Alicia le puede entregar a Bob el derecho de accesar a su archivo Datos, por ejemplo a determinada hora. Esto es dificil lograr con ACLs. Problema: ahora es dificil saber quien tiene acceso al objeto. Según las detalles de implementación, Bob podría haberlo regalado a Manuel, sin preguntarle a Alicia. Esto complica la revocación de todos los derechos sobre un objeto. Los capabilities son menos usados que los ACLs, pero un ejemplo real es el sistema AS/400 de IBM. También se puede considerar que los certificados criptográficos son realmente capabilities, con muchas de las mismas ventajas y problemas. 12 de junio de 2002 Control de Acceso-6

7 La meta de muchos administradores de redes locales o intranets es lograr single sign-on, o sea que el usuario se identifique una sola vez para obtener un abaníco de servicios, por ejemplo leer correo, ver las notas de un estudiante, consultar información personal de la Nómina, reservar un salón de clase, etc., todos los cuales son implementados en servidores distintos en unidades administrativamente independientes. A una escala más grande, se está empezando a trabajar en servicios de autentificación globales para el Internet, ej. Passport (Microsoft) o Liberty Alliance. Sin embargo, esto acarrea sus propios problemas: Requiere mucho cuidado en el diseño. Ej. el sistema Passport tiene vulnerabilidades conocidas. Implica depositar mucha confianza en el administrador central del servicio de autenticación. Puede permitir a un adversario (que puede ser el gobierno) correlacionar distintas actividades de un usuario. 12 de junio de 2002 Control de Acceso-7

8 Protección en Hardware El SOP sólo puede ser efectivo si siempre puede mediar los accesos a los objetos. Tiene que ser posible garantizar que un programa no pueda tomar control de la máquina y bloquear la intervención del SOP, o lo altere indebidamente. Esto requiere necesariamente cierto soporte de hardware, incluyendo como mínimo: Una arquitectura de procesador que soporte al menos dos modos de ejecución, uno de los cuales tiene menos privilegios que el otro. Cada modo debe tener su propio PC (contador de programa) y registros internos. En el modo no-privilegiado, debe ser posible: Restringir las direcciones de memoria accesibles. Limitar el acceso directo a los dispositivos. Evitar cambios de modo no-controlados. Un reloj que interrumpe la ejecución periódicamente y pasa control al modo privilegiado (para evitar denials of service). Sin estos elementos, no es posible implementar controles de acceso en una manera confiable. 12 de junio de 2002 Control de Acceso-8

9 Ataques a los Controles de Acceso El ataque favorito es aprovechar la falta de cuidado en el chequeo de parámetros a un programa que corre con privilegios de root, por ejemplo: { char buffer[16]; printf ("Nombre: "); gets (buffer); /* Leer nombre */... Nombre: unstringextremadamentelargo El programa no chequea el tamaño de su entrada. Como esta es más grande que el espacio reservado, se desborda el arreglo buffer y se sobreescribe la pila. Con suficiente cuidado, Manuel puede insertar instrucciones de máquina para que el programa ejecute una llamada al sistema similar a: system ("/bin/sh"); Ahora tiene un Shell corriendo en el servidor, con los privilegios del dueño del programa. Esto se llama stack-smashing. 12 de junio de 2002 Control de Acceso-9

10 Hay varias técnicas de defensa contra este tipo de problema: Algunos sistemas (ej. Linux) tienen una opción en el kernel para que el segmento de pila no sea ejecutable. En ciertos casos (no comunes) esto puede romper algunos programas, y en todo caso no es una solución 100 % efectivo. Un producto llamado Stackguard ( envuelve las llamadas a funciones en código especial que permite detectar cuando la dirección de retorno en la pila ha sido alterada. Tampoco es 100 % efectivo. Exhortar a los programadores a tener más cuidado cuando crean programas setuid. Además, realizar auditorias para que otros puedan revisar el código (por ejemplo el grupo Open BSD se dedica a esto). En este contexto el acceso al código fuente es crítico. 12 de junio de 2002 Control de Acceso-10

11 Condiciones de Carrera Otro tipo de ataque explota pequeñas ventanas de tiempo en que un sistema es vulnerable. Por ejemplo, a veces una aplicación crea un archivo temporal en el directorio /tmp, y luego lo borrar unos segundos después. Esto requiere que se genere un nombre para dicho archivo, que no coincida con otro ya existente: for (;;) { generar nombre aleatorio en /tmp si /tmp/nombre-nuevo no existe { crear /tmp/nombre-nuevo /* X */ break } } Si Manuel es suficientemente astuto, puede predecir el valor de nombre-nuevo y justamente en el punto X crear un enlace simbólico con ese nombre, apuntando a un archivo de su elección, por ejemplo /etc/passwd... Defensa: crear nombres temporales atómicamente es truculento pero hay rutinas de librería que lo pueden hacer. Uselas. 12 de junio de 2002 Control de Acceso-11

12 Otros Ataques Algunos ataques son legendarios: El sistema TENEX chequeaba passwords en un lazo secuencial, caracter por caracter, y devolvía un error tan pronto lo detectaba. Manuel podía colocar su candidato para el password al final de la memoria virtual: legal ilegal c a n d i d a t o Si el sistema retorna el error, el primer caracter es incorrecto y Manuel intenta con otro. Si da una excepción por acceso ilegal a memoria, el primer caracter es correcto. Manuel corre el candidato una posición y repite: legal ilegal c a n d i d a t o Esta técnica permite atacar un espacio de A N posibles passwords con un costo proporcional a A N, por un alfabeto de tamaño A y passwords de longitud máxima N. Alternativamente, Manuel puede medir cuanto tiempo le tarda al sistema en rechazar su candidato, para saber cuantas iteraciones del lazo fueron ejecutados. En este caso se llama un timing attack. 12 de junio de 2002 Control de Acceso-12

13 Ataques de denial of service (DOS): Manuel ejecuta tantos procesos que llena una tabla interna de tamaño fijo. Ni siquiera root puede ejecutar un comando de Shell para matar su programa. Manuel envia tantos paquetes SYN en la red (para abrir conexiones TCP) que se llenan los buffers. Esto es un SYN Flood. Ataques de interfaz al usuario: Manuel fabrica un programa (ej. un juego) y lo ofrece al administrador, quien lo ejecuta con sus privilegios. El juego funciona, pero también hace otras cosas... Esto es el famoso Caballo de Troya. Funciona por una violación del Principio de Mínimo Privilegio. Un variante es que Manuel crea su caballo de Troya con el nombre ls y lo deja en algún directorio donde tiene permisos. Algún día el administrador entra en el directorio y ejecuta ls para listar sus contenidos... El administrador debe cuidarse de no incluir el directorio actual. en su camino de búsqueda ($PATH en Unix). 12 de junio de 2002 Control de Acceso-13

14 Rootkits Si Manuel logra obtener privilegios de root, procede a encubrir sus acciones: Instala nuevos binarios de comandos importantes, por ejemplo con una puerta trasera para que le sea más fácil entrar la próxima vez. En los sistemas que permiten cargar módulos dinámicos del sistema de operación, puede colocar un módulo suyo para tomar control total sobre el sistema atacado. Cambia el comportamiento de los utilitarios que hacen logging en el sistema para que no le rastrean. Altera los logs existentes (/var/log/wtmp etc.) para quitar la evidencia de su penetración, y cambia las fechas de modificación de archivos claves (/etc/passwd etc.) para que no se note que han cambiado. Para facilitar estas acciones (que requieren de bastante sofisticación) puede utilizar un rootkit o paquete preparado por un experto. Disponible en los mejores sitios del Internet. Defensa: el sistema Tripwire mantiene una base de datos con un hash criptográficamente fuerte de todo archivo importante, y puede detectar cualquier cambio. La base de datos debe ser guardado en otro sitio que no sea vulnerable. Nótese que el programa tripwire en sí es un punto vulnerable a ataques. 12 de junio de 2002 Control de Acceso-14