Seguridad Informática Control de acceso Ramón Hermoso, Rubén Ortiz y Matteo Vasirani Grado en Ingeniería Informática
1 Identificación y autenticación 2 Control de acceso 3 Autenticación y control de acceso en Unix 4 Aislamiento de código
1 Identificación y autenticación 2 Control de acceso 3 Autenticación y control de acceso en Unix 4 Aislamiento de código
Identificación y autenticación En un sistema seguro se necesita trazar la identidad de los usuarios que necesitan servicios y acceso a datos La autenticación es el proceso de verificar la identidad de un usuario Dos razones para autenticar un usuarios: La identidad de un usuario es necesaria para las decisiones de control de acceso La identidad de un usuario se almacena en los logs para tener traza de los eventos relevantes
Identificación y Autenticación Todos hemos interactuado con un sistema software (SO, cuenta email etc.) que nos pide digitar usuario y contraseña El primer paso se llama identificación: anunciamos quiénes somos El segundo paso se llama autenticación: damos prueba que de verdad somos quién decimos que somos El sistema compara nuestro input con los datos contenidos en una base de datos o en un fichero (password file), y si usuario y contraseña son correctos el sistema nos permite acceder a él
Identificación y autenticación El autenticación puede ocurrir de manera repetida a lo largo de la sesión, para evitar que un atacante se aproveche de una sesión huerfana TOCTTOU:Time of Check to Time of Use La autenticación repetida sirve para tratar el problema conocido como TOCTTOU. El sistema comprueba (check) la identidad al principio de la sesión pero utiliza (use) esta información más tarde para tomar decisiones de control de acceso.
Identificación y autenticación La identificación y autenticación es la primera línea de defensa de un sistema software, y ya es parte de la routina de cualquier usuario Sin embargo, mantener la seguridad de la contraseña es un serio problema de seguridad 1 El administrador del sistema tiene que asegurarse que nadie pueda tener acceso no autorizado a los datos relativos a las contraseñas 2 El usuario tiene que colaborar, eligiendo una contraseña robusta
Identificación y autenticación Hay varios problemas de seguridad relacionados con las contraseñas, ya que un atacante podría: 1 Interceptar la contraseña cuando se crea una cuenta nueva (p.e. keylogger) 2 Adivinar la contraseña 3 Robar la contraseña (phishing, ingeniería social...) 4 Obtener la contraseña comprometiendo el fichero de contraseñas
Adivinar la contraseña Tipos de ataques 1 Fuerza bruta: intentar todas las posibles combinaciones de caracteres, hasta una cierta longitud 2 Búsqueda inteligente: intentar contraseñas asociadas con el usuario (p.e., fecha de nacimiento, nombre del perro etc.) 3 Diccionario: usar un conjunto de palabras comunes
Adivinar la contraseña Las defensas 1 Cambiar la contraseña por defecto 2 Usar contraseñas de 8 dígitos (como mínimo) Un supercomputer tarda más de 600.000 millones de años en romper una contraseña de 20 dígitos Si el sistema es accesible sólo físicamente, una contraseña en blanco es más eficaz que 12345 o abc123 3 Mezclar mayúsculas, minúsculas, caracteres especiales
Adivinar la contraseña La realidad (según un estudio de Imperva 1 ): Las contraseñas más usadas son 123456, 12345, 123456789 y Password Casi el 50% de los usuarios usa como contraseña nombres, palabras de diccionario o combinaciones triviales de caracteres El 20% de las cuentas se pueden crackear en menos de 5000 intentos Casi el 50% de las contraseñas tienen 7 caracteres o menos, y más del 30% tienen 6 caracteres o menos. 1 http://www.imperva.com/ld/password report.asp
1 Identificación y autenticación 2 Control de acceso 3 Autenticación y control de acceso en Unix 4 Aislamiento de código
Control de acceso Una vez identificado y autenticado, un usuario se encuentra dentro del sistema Es necesario definir una política de control de acceso a los recursos del sistema Quién puede leer el fichero foo.txt? Quién no puede escribir el fichero bar.txt? Qué programas puede ejecutar el usuario pepe?...
Terminología Un sujeto quiere acceder a un objeto a través de una cierta operación, supervisada por un monitor de referencia que media la operación entre sujeto y objeto Sujeto: usuario, proceso Objeto: fichero, memoria, dispositivo hardware Operación: leer, escribir, ejecutar
Clasificación Control de acceso discrecional (DAC) La política de control de acceso es determinada por el propietario del objeto El propietario decide qué permisos se asignan a quién Normalmente el propietario de un objeto es el usuario que lo crea Control de acceso obligatorio (MAC) La política de control de acceso es determinada por el sistema, y no por el propietario del objeto Se clasifican sujetos y objetos en niveles de seguridad. Poco usado en sistemas software
Matriz de control de acceso S: conjunto de sujetos O: conjunto de objetos A: conjunto de operaciones de acceso M = (M s,o ) s S,o O, M s,o A } {{ } Matriz de control de acceso
Ejemplo S = {pepe,paco,luis} O = {bar.txt, foo.exe} A = {r = read,x = execute,d = delete} M = bar.txt foo.exe pepe {r} paco {x, d} luis {r, d} {x}
Ejemplo S = {inc bal,dec bal,reset} O = {balance, account} A = {,, } M = balance account inc bal { } dec bal { } reset { } { }
Matriz de control de acceso Puede ser muy grande en sistemas con muchos usuarios y muchos recursos Es un concepto abstracto, raramente se implementa directamente Posibles implementaciones: 1 Lista de control de acceso (ACL) Una lista por cada objeto. Indica las operaciones que cada sujeto puede hacer. 2 Lista de capacidades Una lista por cada sujeto. Indica las operaciones que puede hacer sobre cada objeto
ACL vs capacidades
Lista de control de acceso (ACL) S: conjunto de sujetos O: conjunto de objetos A: conjunto de de operaciones de acceso L o = {(s,α) s S,α A} o O } {{ } Lista de control de acceso Ejemplo: L bar.txt = { (pepe,{r}), (paco, ), (luis,{r,d}) } L foo.exe = { (pepe, ), (paco,{x,d}), (luis,{x}) }
Lista de control de acceso (ACL) Ventajas: Es fácil ver los permisos de acceso de un determinado objeto Es fácil revocar todos los permisos sobre un objeto, poniendo L o = {} Es fácil eliminar los permisos asociados a un objeto que ya no existe, eliminando L o Desventajas: Comprobar los permisos de acceso de un determinado sujeto Uso: Se suele implementar en sistemas orientados a la gestión del acceso a recursos, como en los sistemas operativos
Lista de capacidades S: conjunto de sujetos O: conjunto de objetos A: conjunto de de operaciones de acceso L s = {(o,α) o O,α A} s S } {{ } Lista de capacidades Ejemplo: L pepe = { (bar.txt,{r}), (foo.exe, ) } L paco = { (bar.txt, ), (foo.exe,{x,d}) } L luis = { (bar.txt,{r,d}), (foo.exe,{x}) }
Lista de capacidades Ventajas: Es fácil comprobar todos los permisos de un sujeto Es fácil revocar todos los permisos de un sujeto, poniendo L s = {} Es fácil eliminar los permisos asociados a un sujeto que ya no existe, eliminando L s Desventajas: Comprobar los permisos de acceso sobre un determinado objeto Uso: Se suele implementar en sistemas orientados a los usuarios, como las bases de datos o los sistemas distribuidos
Métodos de agregación Grupos Los operaciones de acceso se pueden definir para un determinado grupo de sujetos Asignando un grupo a un sujeto, éste hereda las operaciones de acceso definidas para el grupo Ejemplo: Crear el grupo mail Definir que los sujetos del grupo mail pueden acceder al servidor smtp Añadir el usuario pepe al grupo mail
Métodos de agregación Roles Las operaciones de acceso se agrupan en roles A cada sujeto se le asigna uno o más roles Los roles se estructuran de manera jerárquica Ejemplo: Operaciones: depositar, retirar, traspasar,crear } {{ } } {{ } } {{ cuenta } Rol: Empleado Rol: Supervisor Rol: Administrador Taxonomía: Administrador Supervisor Empleado Si a pepe se le asigna el rol Administrador, podrá ejecutar todas las operaciones Si a paco se le asigna el rol Empleado, sólo podrá depositar o retirar dinero de una cuenta
1 Identificación y autenticación 2 Control de acceso 3 Autenticación y control de acceso en Unix 4 Aislamiento de código
Usuarios Cada usuario está identificado por un username y un user ID (UID) Existe un usuario, root, que tiene privilegios especiales de administración (super user), cuyo UID es 0 Unix no es capaz de distinguir dos usuarios con el mismo UID El usuario root puede hacer prácticamente cualquier cosa, por lo tanto es el punto más debil de un sistema Unix Casi todos los ataques se reducen a conseguir ser root!!!
Grupos Un grupo está identificado por un group name y un group ID (GID) Cada usuario puede pertenecer a uno (primary group) o más grupos El usuario root pertenece al grupo root, cuyo GID es 0
/etc/passwd Los datos de autenticación de un usuario están almacenados en el fichero /etc/passwd, en el formato: username:encrypted pwd:user ID:group ID:ID:home dir:login shell Ejemplo: root:a5zhb29w:0:0:administrator:/home/root:/bin/bash pepe:hgf5d3ws:1002:1002:pepe:/home/pepe:/bin/bash Todos los usuarios pueden leer el fichero /etc/passwd, pero solo root puede modificarlo. Por qué? Qué pasa si pepe modifica el fichero /etc/passwd de esta manera? root:a5zhb29w:0:0:administrator:/home/root:/bin/bash pepe:hgf5d3ws:0:0:pepe:/home/pepe:/bin/bash
/etc/shadow La contraseña que aparece en el fichero /etc/passwd está cifrada. Sin embargo, hay problemas de seguridad. Por qué? En las versiones más recientes, el fichero /etc/passwd es algo así root:*:0:0:administrator:/home/root:/bin/bash pepe:*:1002:1002:pepe:/home/pepe:/bin/bash La password cifrada está en otro fichero, /etc/shadow, que sólo root puede leer y modificar
Set UserID y Set GroupID Si sólo root puede leer el fichero /etc/shadow o modificar el fichero /etc/passwd, cómo puede un usuario no privilegiado autenticarse en el SO o modificar su password? Los programas Set UserID (SUID) y Set GroupID (SGID) permiten a un usuario adoptar temporalmente el UID o el GID del propietario del programa a lo largo de su ejecución Ejemplos de programas SUID cuyo propietario es root: /usr/bin/passwd: cambiar password /usr/bin/login: autenticarse en el SO Cuando pepe ejecuta un programa SUID de root, hereda todos los privilegios de root!!!
Permisos Recurso fichero inode
Permisos
Permisos Los permisos de acceso están agrupados en tres tripletas, que representan las operaciones permitidas al propietario del fichero, a los usuarios del mismo grupo del propietario, y a todos los demás usuarios Para los ejecutables SUID, aparece una s en vez de una x El monitor de referencia concede el acceso comprobando los permisos de la siguiente manera if usuario.uid == inode.uid then comprueba permisos user else if usuario.gid == inode.gid then comprueba permisos group else comprueba permisos others end if Qué pasa si los permisos son ------rwx???
Permisos El propietario de un fichero (y obviamente root) puede cambiar los permisos de acceso usando el comando chmod Ejemplos: chmod [ugo][+-][rwx] file asignar o quitar (+-) los permisos de lectura/escritura /ejecución (rwx) al propietario/grupo/otros (ugo) chmod [ugo][+-][rws] file asignar o quitar (+-) los permisos de lectura/escritura /ejecución SUID (rws) al propietario/grupo/otros (ugo) chmod [+-][t] dir asignar o quitar (+-) el sticky bit (t) al directorio. Con el sticky bit, sólo el propietario puede borrar/renombrar los ficheros contenidos en el directorio chmod perm file especificar los permisos con un número octal (perm)
Permisos chmod 660 file = rw-rw---- chmod 777 file = rwxrwxrwx chmod 744 file = rwxr--r-- chmod 500 file = r-x------
Permisos Como manejar los recursos sensibles? 1 Crear un nuevo UID propietario del recurso y de todos los programas que acceden a él 2 Asignar permisos de acceso sólo a este UID (rwx------) 3 Definir como SUID todos los programas que acceden al recurso Pero cuidado con los programas SUID, sobre todo si el propietario es root!!!
Permisos Ejemplo: /dev/mem (block device de la memoria principal) Todos los usuarios pueden invocar el comando ps que mostra el consumo de memoria de los programas en ejecución
Permisos Ejemplo: /dev/mem (block device de la memoria principal) Todos los usuarios pueden invocar el comando ps que mostra el consumo de memoria de los programas en ejecución
Permisos Ejemplo: /dev/mem (block device de la memoria principal) Todos los usuarios pueden invocar el comando ps que mostra el consumo de memoria de los programas en ejecución
1 Identificación y autenticación 2 Control de acceso 3 Autenticación y control de acceso en Unix 4 Aislamiento de código
Aislamiento de código A veces, ejecutar una política de control de acceso no es suficiente Ejemplo Probar software no seguro Acceso a usuarios desconocidos (ftp) Solución: aislamiento de código Construir una prisión de manera que un proceso no pueda ver los recursos que están fuera chroot máquinas virtuales (VirtualBox, VMWare)
chroot Para limitar el acceso a los recursos, se cambia el directorio raíz Ejemplo chroot( /tmp ) Si se intenta acceder a /etc/shadow, en realidad se está intentando acceder a /tmp/etc/shadow Ventajas: El proceso no puede escapar de la prisión Desventajas: Hay que copiar todos los comandos y librerías necesarias (/bin/ls, /bin/cp)
chroot Solamente root puede ejecutar chroot En caso contrario, cualquier usuario puede escalar privilegios Ejemplo Crear un fichero /tmp/etc/passwd con los datos de un usuario fakeroot con UID=0 Ejecutar chroot( /tmp ) Ejecutar su fakeroot
Máquinas virtuales Idea nacida en los 60 Múltiples SO sobre harwdare muy costoso Pérdida de interés en los 80 y 90 Hardware barato, SO multiusuario Hoy, vuelta a los 60 Procesadores muy rápidos Prestaciones similares
Máquinas virtuales
Máquinas virtuales Seguridad Cada máquina virtual es independiente Diferentes SO, discos, direcciones IP Imposible compartir datos directamente Imposible afectar el SO donde corre la máquina virtual Fallos Los fallos son autocontenidos y no afectan al hardware subyacente Ejemplo: honeypot