Autenticación y control de acceso

Autenticación y control de acceso
Seguridad en Redes de Ordenadores
Enrique Soriano
LS, GSYC
24 de abril de 2016
(cc) 2015 Grupo de Sistemas y Comunicaciones.
Algunos derechos reservados. Este trabajo se entrega bajo la licencia Creative Commons Reconocimiento NoComercial - SinObraDerivada (by-nc-nd). Para obtener la licencia completa, véase
http://creativecommons.org/licenses También puede solicitarse a Creative Commons, 559 Nathan Abbott Way,
Stanford, California 94305, USA.
Términos
I
Identificación: Alguien dice ser un sujeto concreto.
I
Autenticación: Alguien demuestra su identidad.
I
Autorización: Otorgamiento de privilegios a un sujeto para
realizar una operación de acceso sobre uno o varios objetos.
I
Control de acceso: Permitir o denegar una operación de
acceso sobre un recurso en base a la autorización del sujeto.
Autenticación
I
Un programa se autentica ante el sistema a nombre de un
usuario y pasa a ejecutar a su nombre.
I
¿Cómo te autenticas?
I
I
I
I
I
Algo que conoces.
Algo que tienes.
Algo que eres.
Algo que haces.
Donde estás.
Contraseñas
I
La forma más común y sencilla de autenticación: el usuario
proporciona un secreto que sólo él y el sistema conocen.
I
Riesgos:
I
I
I
I
I
Que vean nuestra contraseña.
Que la adivinen.
Spoofing (suplantación).
Que se hagan con el almacén de contraseñas.
Siempre que sea posible, es recomendable realizar una
utenticación en dos pasos (Two-Factor Authentication):
además de la contraseña, usar un método adicional de
autenticación (P. ej. Google Authenticator, Latch, etc.).
Contraseñas
Que vean nuestra contraseña:
I
No se deben compartir.
I
No se deben apuntar en claro.
I
No se debe usar la misma contraseña para distintos servicios.
I
Aplicaciones keyring : Password Safe (Windows), Keychain
(OSX), etc.
Contraseñas
Que adivinen nuestra contraseña:
I
Ataque de fuerza bruta.
I
Búsqueda inteligente.
I
Ataque de diccionario online.
Ataque de fuerza bruta
Keyspace:
I
Siendo S la longitud de la contraseña y N el número de
sı́mbolos que se pueden usar en las contraseñas.
Keyspace =
s
P
Ni
i=0
I
Ejemplo: Contraseñas de sólo minúsculas y de 0 a 8 caracteres:
I
Ejemplo: Con mayúsculas, minúsculas, números y sı́mbolos de
puntuación, de 0 a 14 caracteres:
Ataque inteligente
Imagen (C) xato.net
Contraseñas
No usar passwords comunes:
Contraseñas
Contraseñas de calidad:
I
Nnemotécnicos: TabletMipefaesstwa3 de “Mi pelı́cula
favorita es star wars 3”
I
Rimas: SEGURIDAD-0-calamidad@casa
I
Repetición: hey.h0.HEY.H0.6
Contraseñas
Distintas contraseñas para distintos servicios:
I
Se puede tener un método para generar las contraseñas para
distintos servicios.
I
Por ejemplo, poner al principio el número de caracteres del
servicio o servidor:
I
I
I
Amazon: A6m1--mej0r--SECRETO
Msn: M3m1--mej0r--SECRETO
Apple: A5m1--mej0r--SECRETO
Contraseñas
Medidas de protección:
I
No permitir contraseñas vacı́as en el sistema.
I
Obligar a cambiar las contraseñas por omisión.
Ejemplo: routers adsl.
I
Obligar a que tengan una longitud mı́nima (no menos de 8
caracteres).
I
Obligar a que no sean palabras del diccionario: requerimos
puntos, números, mayúsculas y minúsculas, etc.
Contraseñas
Medidas de protección:
I
Pasamos crackers para validarlas.
Ejemplo: John the Ripper.
I
Obligar a cambiar las contraseñas periódicamente.
I
No permitir reusar contraseñas antiguas.
I
No es buena idea generar contraseñas aleatorias para los
usuarios → las apuntan. Si son aleatorias, no deben ser
predecibles.
Contraseñas
Medidas de protección:
I
Limitar el número de intentos de autenticación.
I
Aumentar el tiempo entre autenticaciones fallidas.
I
Compromiso: seguridad vs. obstrucción.
Contraseñas
Más riesgos: que nos timen.
I
Spoofing
I
Keyloggers
I
Ingenierı́a social
I
...
Contraseñas
Spoofing:
I
Un atacante reemplaza al sujeto ante el que nos
autenticamos, y nos roba la contraseña.
I
Seguramente no nos demos cuenta: el resultado de la
autenticación parece un error al escribir la contraseña, pero no
lo es.
I
Ataque clásico: reemplazar /bin/login
I
En el WWW: te conectas a una página que no es la que crees
(p. ej. te engañan con phishing ).
Contraseñas
Medidas de protección:
I
Imprimir el número de intentos reales que se llevan.
I
Trusted Path: estar seguros de que el usuario se comunica con
el sistema operativo y no con un programa falso.
I
Autenticación mutua: el programa de login se autentica ante
el usuario antes de que el usuario se identifique y autentique.
Contraseñas
Keyloggers:
I
Software: un programa captura todo lo que tecleamos.
I
Hardware: espı́a el cable del teclado o la transmisión
inalámbrica de ratones/teclados. Aprox. 50 Euros, 2Gb. Los
hay WiFi.
Contraseñas
Medidas de protección:
I
Para PIN: mostrar una tabla por pantalla con una sustitución
de los números por caracteres, distinta en cada autenticación.
I
Usar el ratón para introducir la contraseña.
I
... pero también nos pueden engañar con hardware (150
Euros, 2 Gb de screenshots).
Contraseñas
Moraleja:
I
The Big Stick Principle.
Contraseñas
Si se hacen con el almacén de contraseñas:
I
Las contraseñas se suelen guardar cifradas.
I
Por lo general, se guarda un hash de la contraseña.
I
Ataque de diccionario offline: mucho más efectivo que online.
Contraseñas
Ataque de diccionario offline:
I
Buscar la hash que se quiere romper en una tabla precalculada
de tuplas (contraseña, hash) → cambias tiempo de
computación por espacio.
I
Rainbow-tables (p. ej. ophcrack).
I
Uso de Google para encontrar la hash. ¿Qué contraseña tiene
esta hash SHA-1?
99800b85d3383e3a2fb45eb7d0066a4879a9dad0
¡Búscalo en Google!
Rainbow Tables
Compromiso espacio/cómputo:
Contraseñas
Medidas de protección:
I
Contraseñas buenas: aumenta el keyspace objetivo de la tabla.
I
Hashes con salt: necesitas una tabla a medida para romper
una contraseña especı́fica.
I
key strengthening : salt secreta.
Caso: autenticación clásica en Unix
Pasos de arranque:
1. Scripts de arranque (init).
2. /bin/getty
3. /bin/login
Caso: credenciales en Unix
Un proceso tiene credenciales 1 :
I
PID: identificador de proceso.
I
UID: identificador de usuario.
I
GID: identificador de grupo.
I
EUID: identificador de usuario efectivo, el que se usa para
comprobar privilegios.
I
EGID: identificador de grupo efectivo, el que se usa para
comprobar privilegios.
I
...
1
Dependen del “sabor” de UNIX
Caso: autenticación básica en Unix
/etc/passwd:
I
Login.
I
Contraseña (“x” cuando tenemos shadow )
I
UID.
I
GID.
I
Gecos info: datos sobre el usuario, separados por comas.
I
Path del home.
I
Programa de inicio.
Caso: autenticación básica en Unix
/etc/shadow:
I
I
Login.
Hash: son tres campos separados por $.
I
I
I
Algoritmo: p. ej. 1 es MD6, 6 es SHA-512.
Salt
Hash
NOTA: Si tiene un valor que no se corresponde con una posible salida de crypt,
el usuario no se podrá autenticar con contraseña (pero sı́ de otras formas). Por
ejemplo, se pone ∗ o ! para evitar que el usuario entre con contraseña. Si está
vacı́o, el usuario no tiene contraseña (no es recomendable). En Linux recientes,
la contraseña de root es !.
Caso: autenticación básica en Unix
/etc/shadow (continúa):
I
Fecha Unix del último cambio de contraseña.
I
Mı́nima edad: mı́nimo número de dı́as para permitir un
cambio de contraseña.
I
Máxima edad: dı́as tras los que tiene que cambiar la
contraseña.
I
Dı́as, antes de la caducidad según el campo anterior, para
avisar al usuario.
I
Dı́as de prórroga desde que caduca, cuando pasan se anula la
contraseña.
Caso: autenticación básica en Unix
/etc/shadow (continúa):
I
Fecha Unix de caducidad para la cuenta. Si llega, se cancela la
cuenta. No es lo mismo que la edad de la contraseña, esta es
más dura.
I
Campo reservado para uso futuro.
Caso: control de credenciales en Unix
I
/bin/id: Permite ver tu UID y GID.
I
/bin/su: Permite ejecutar un shell con otro UID. Por
omisión, intenta ejecutar un shell con UID 0.
I
/usr/bin/sudo: Permite ejecutar un comando con otro UID,
proporcionando tu propia contraseña. El fichero
/etc/sudoers especifica quién puede convertirse en quién, y
para qué.
Caso: control de credenciales en Unix
Ejemplo de sudoers (I):
jose ALL = (root, bin : operator, system) ALL
I
jose puede, en cualquier máquina
I
adquirir el UID de root y bin
I
adquirir el GID de operator y system
I
para ejecutar cualquier comando
Caso: control de credenciales en Unix
Ejemplo de sudoers (II):
ramon mono = NOPASSWD: /bin/kill, PASSWD: /bin/ls,
/usr/bin/lprm
I
ramon puede, en la máquina mono
I
adquirir el UID de root
I
para ejecutar kill sin proporcionar contraseña
I
para ejecutar ls y lprm proporcionando contraseña
Caso: autenticación en Windows
I
Windows almacena las contraseñas en SAM:
\windows\system32\config\sam
I
El fichero está bloqueado en todo momento.
Puede contener dos tipos de contraseñas cifradas:
I
I
I
LM (Lan Manager). ¡Inseguro! Windows 7 no la usa por
omisión (pero se puede configurar para que las use, ojo).
NTLM (NT Lan Manager): No tan seguro como deberı́a.
Caso: autenticación en Windows
En un terminal (cmd.exe )como administrador:
Caso: autenticación en Windows
Contraseñas LM (Lan Manager):
I
Convierte todos los caracteres de la contraseña a mayúsculas.
I
Rellena con 0s la contraseña hasta llegar a los 14 caracteres.
I
Parte la contraseña en dos bloques de 7 bytes.
I
Usa los dos bloques como claves para cifrar con DES para un
bloque de datos conocido: 0x4b47532140232425
I
Concatena el resultado de los dos cifrados DES.
¡NO podı́an haber metido más la pata!
Caso: autenticación en Windows
Contraseñas LM (Lan Manager):
VS
Caso: autenticación en Windows
Contraseñas NTLM (NT Lan Manager):
I Usa una hash MD4 de 128 bits, que era segura en 1991:
I
I
Ataque de colisión en microsegundos.
Ataque de pre-imagen teórico.
I
Diferencia entre mayúsculas y minúsculas.
I
No usa salt.
Caso: autenticación en Windows
Syskey:
I
I
Añade una capa extra de seguridad cifrando el almacén de
claves de SAM.
Opción I (activada por omisión):
I
I
I
Usa una clave generada para cada sistema y que está oculta en
el Registro.
Viola el principio de Kerckhoffs: no sirve de nada.
bkhive la encuentra, samdump2 descifra el archivo de SAM.
I
Opción II:Generar la clave a partir de una contraseña adicional
que se introduce en el arranque.
I
Opción III: Almacenar la clave en un disco extraı́ble.
Caso: autenticación en Windows
Ophcrack rompe contraseñas débiles de Windows NT (hashes
MD4) con rainbow tables:
Caso: control de credenciales en Windows
En Windows es común usar una cuenta de administrador. User
Account Control (UAC) permite controlar los privilegios:
I
Un administrador tiene un token de usuario y token de
administrador.
I
Idea: evitar el uso del token de administrador para operaciones
que no lo requieren.
I
Cuando se intenta usar el de administrador (elevación) se
presenta una ventana de diálogo UAC para pedir permiso o
credenciales.
Caso: control de credenciales en Windows
Los diálogos de elevación usan un código de colores:
I
Rojo (con escudo) si el firmante de la aplicación está
bloqueado, es una aplicación sin firma bajada de Internet.
I
Azul (con escudo) si es una aplicación administrativa de
Windows (p.ej. Panel de Control).
I
Azul (con interrogación) si la aplicación está firmada por
terceros con Authenticode y se puede verificar.
I
Amarillo (con escudo) si la aplicación no está firmada o está
firmada pero no se puede verificar.
Caso: control de credenciales en Windows
Caso: control de credenciales en Windows
UAC niveles
I
Sólo el nivel más alto impide autoelevación silenciosa.
I
Los niveles más bajos no usan el escritorio seguro.
Caso: control de credenciales en Windows
Ventajas de UAC:
I
No hay que usar dos cuentas (usuario y administrador).
I
No hay que entender para qué hay que usar la cuenta de
administrador y para qué la otra.
I
No hay que gestionar dos perfiles distintos (carpetas,
escritorios, etc.).
I
Aplica el principio de mı́nimo privilegio.
Inconvenientes: No ha sido bien recibido por ser molesto ¿El
problema es la interfaz?
Algo que eres
Nuestro cuerpo nos puede autenticar (biometrı́a):
I
Escaner de iris.
I
Escaner de retina.
I
Huellas dactilares.
I
Palma de la mano.
I
Reconocimiento de voz.
I
Reconocimiento facial.
Algo que eres
I
I
Aumenta el riesgo para la integridad fı́sica del usuario.
Son más propensos a fallar:
I
I
I
Falso positivo: autenticación errónea.
Falso negativo: aumenta la obstrucción.
¿Cómo se revoca una huella dactilar o una cara?
Algo que tienes
I
Tu SmartPhone: Google Authenticator.
I
SecureID
I
Smart Cards
I
RFID / NFC
I
USB tokens
I
Fortezza
I
...
Algo que tienes
Los dispositivos de autenticación:
I
Pueden disminuir la obstrucción, como NFC.
I
Pueden aumentar la obstrucción, como SecureID.
I
Hay que fiarse del HW lector: igual que con las contraseñas,
puede existir spoofing.
I
Nuevo riesgo: puedes perder el objeto, o te lo pueden robar.
I
Si lo piensas, corremos los mismos riesgos a diario con las
llaves de nuestra casa o las tarjetas de crédito.
DNIe
Por ejemplo, el DNI electrónico (DNIe):
I
Se usa para cualquier tipo de tramitación telemática con el
estado.
I
Tiene la misma validez que el DNI normal.
DNIe
El DNI electrónico (DNIe) es una SmartCard tamper-resistant con
los siguientes ficheros dentro:
I Datos de filiación del titular
I Imagen digitalizada de la fotografı́a.
I Imagen digitalizada de la firma manuscrita.
I Plantilla de la impresión dactilar de los dedos ı́ndice de cada mano.
I Certificado X.509 para autenticación, y la clave privada correspondiente.
I Certificado X.509 para firma, y la clave privada correspondiente.
I Certificado X.509 de la autoridad emisora.
La generación de claves, el cifrado/descifrado, la firma, etc. se realiza en el chip de la
tarjeta.
DNIe
I Se entrega junto con un PIN (sic) (es una contraseña con 8-16 caracteres): algo
que tienes + algo que sabes.
I Se puede cambiar la contraseña desde cualquier PC si sabemos la contraseña
vieja.
I Se puede reestablecer la contraseña (sin conocer el viejo) en un terminal especial
(Punto de Actualización del DNIe). Es necesario proporcionar la huella dactilar
(la verificación se hace en el propio chip): algo que tienes + algo que eres.
Otras formas
I
Algo que haces: por ejemplo, gestos ante una cámara, en un
touchpad, etc.
I
Dónde estás: el simple hecho de encontrarte en una
localización fı́sica (p.ej., la sala de los servidores) te autentica.
Single Sign-On
I
Una única autenticación para usar varios servicios distintos.
I
¿Tendremos Single Sign-On para todos los servicios?
Combinación de métodos de autenticación
SUN’s PAM (Pluggable Authentication Modules):
I
Objetivos:
I
I
I
I
Combinar distintos métodos de autenticación proporcionados
por distintos módulos independientes.
Usar distintos métodos de autenticación sin modificar el código
de las aplicaciones.
Modificar la autenticación sin parar el sistema.
PAM está disponible para distintos sabores de Unix.
Linux-PAM
Seis primitivas englobadas en cuatro grupos:
I
Auth: tareas para autenticar al usuario.
I
Account: tareas de gestión de los datos de una cuenta.
I
Password: tareas para administrar los mecanismos de la
autenticación.
I
Session: tareas a realizar al crear y destruir sesiones.
Linux-PAM
Auth:
I
pam authenticate: sirve para autenticar al sujeto.
I
pam setcred: sirve para establecer y gestionar las
credenciales. Tiene que llamarse después de
pam authenticate y antes de establecer la sesión.
Linux-PAM
Session:
I
pam open session: realiza las tareas asociadas con el inicio
de sesión. Por ejemplo, actualizar logs de entrada, etc.
I
pam close session: se encarga de las tareas asociadas con el
fin de sesión. Por ejemplo, actualizar logs de salida, etc.
Linux-PAM
Account:
I
pam acct mgmt: verifica si la cuenta está en buenas
condiciones. Por ejemplo si la contraseña caducó, si la cuenta
está cancelada, etc.
Linux-PAM
Password:
I
pam chauthtok: cambia el objeto de la autenticación (p.ej.,
la contraseña), posiblemente comprobando que es
suficientemente bueno, etc.
Linux-PAM
I
En /etc/pam.d/ se crean ficheros con las polı́ticas para los
distintos servicios.
I
Un fichero de polı́ticas define una pila de reglas que determina
el éxito de una operación:
type control module-path module-arguments
I
I
I
I
type: grupo (auth, account, password, session).
control: cómo afecta al resultado de la operación.
module-path: módulo.
module-arguments: argumentos.
Linux-PAM
Control:
I
requisite: si la operación retorna error, se acaba la autenticación
con fallo.
I
required: si retorna error, el flujo continua aunque el resultado
final ya está decidido: será un fallo.
I
sufficient: si retorna éxito, termina inmediatamente la con éxito.
Si retornar error, se sigue llamando al resto (y si el resto funcionan,
la operación acaba con éxito).
I
optional se ejecuta, pero lo que retorne (éxito o fallo) no se tiene
en cuenta.
Linux-PAM: ejemplo
Aplica un retardo, da igual
lo que devuelva.
Si existe el fichero
/etc/nologin
sólo root puede
autenticarse en la máquina
Comprueba que el
contexto anterior se ha
limpiado
Se leen las variables de
entorno y las variables del
fichero
/etc/default/locale
Se aplican todas las reglas
del fichero de PAM
common-auth
(normalmente pedir
password, comprobar
hash)
Aplica las reglas de esos
tres ficheros de PAM
Imprime si el usuario tiene
correo.
Imprime el MOTD
(Message of the day)
Imprime la fecha del último
login.
Establece los límites del
usuario según
/etc/security/group.conf
Aplica filtros de
/etc/security/group.conf
para añadir al usuario a
grupos dependiendo de
factores como la hora, TTY,
etc.
Autenticación en sistemas distribuidos
Sistemas distribuidos: riesgos
Los riesgos a los que se expone el sistema:
I
Espionaje de los mensajes que viajan por la red. No se puede
detectar desde los extremos.
I
Eliminación, modificación, e inserción de mensajes
transmitidos. Este ataque es activo, y se puede detectar.
I
Repetición de mensajes antiguos. También es activo.
Challenge-Response
I
Objetivo: que las contraseñas no viajen por la red.
I
El servidor envı́a un reto.
I
El cliente responde el reto.
I
¡Los retos no se deben repetir!
Challenge-Response
CRAM-MD5:
1. C ← S : nonce
2. C calcula r = HMACMD5(nonce, pass)
3. C → S : r,login
4. S comprueba si r = HMACMD5(nonce, pass)
Challenge-Response: ejemplo de relay attack
1. M ← S : nonce
2. C ← M : nonce
3. C calcula r = HMACMD5(nonce, pass)
4. C → M : r,login
5. M → S : r,login
6. S comprueba si r = HMACMD5(nonce, pass)
solución: incluir información sobre los extremos de la conexión en
los mensajes (p. ej. dirección IP).
Protocolo ejemplo I
1. C crea m = “soy C”
2. C crea m0 = Ek (m, S)
3. C → S : m, m0
4. S verifica si m haciendo Dk (m0 )
problema: spoofing.
Protocolo ejemplo I: replay attack
1. M recupera m0 = Ek (m, S) viejo
2. M → S : m, m0
3. S verifica si m haciendo Dk (m0 )
solución: timestamps e historial de nonces
Protocolo ejemplo II
1. C → S : “soy C”
2. C ← S : nonce
3. C crea m = Ek (nonce, T , C , S)
4. C → S : m
5. S verifica m: el nonce es correcto y T no es viejo.
Protocolo ejemplo III
Versión con algoritmo de clave pública:
1. C → S : “soy C”
2. C ← S : nonce
3. C crea m = EKCpriv (nonce, T , C , S)
4. C → S : m
5. C → S : Certc
6. S verifica el Certc con la CA
7. S verifica m: descifra con el EKCpub , verifica que el nonce es
correcto y T no es viejo.
Needham-Schroeder
I
Se basa en un servidor de autenticación (A) que comparte
secretos con todos los clientes y servidores.
I
Las claves se centralizan en A.
I
Establece una clave para la sesión para proporcionar un canal
confidencial entre C y S: Kcs
Needham-Schroeder
1. C → A : C , S, Na
2. A crea m = EKc (Na , S, Kcs , EKs (Kcs , C ) )
3. C ← A : m
4. C consigue Na y Kcs haciendo DKc (m)
5. C verifica Na
6. C → S : EKs (Kcs , C )
7. S consigue Kcs haciendo DKs (EKs (Kcs , C ))
8. C ← S : EKcs (Nb )
9. C → S : EKcs (Nb − 1)
10. S verifica DKcs (Nb − 1) == Nb − 1
Needham-Schroeder
Problema: si una clave de sesión vieja Kcs queda
comprometida, el atacante puede reiniciar la sesión antigua si se
hace pasar por C:
1. M recupera EKs (Kcs , C ) viejo.
2. M → S : EKs (Kcs , C )
3. S consigue Kcs haciendo DKs (EKs (Kcs , C ))
4. M ← S : EKcs (Nb )
5. M consigue Nb .
6. M → S : EKcs (Nb − 1)
7. S verifica DKcs (Nb − 1) == Nb − 1
Solución: usar timestamps y tiempos de validez.
Kerberos
Está basado en Needham-Schroeder. Usa dos servicios centrales
(pueden ejecutar en el mismo nodo):
I
KDC (Key Ditribution Center): autentica al cliente.
I
TGS (Ticket Granting Service): proporciona tickets para
acceder a los servicios.
Kerberos
Fase 1
Fase 2
KDC
TGS
TICKET?
TGT?
TGT
TICKET
TICKET+AUTHENTICATOR
AUTHENTICATOR
C
S
Kerberos
Elementos:
I
Ln : tiempo de vida.
I
Tn : timestamp.
I
Nn : nonce.
Fase 1: Conseguir un Ticket-granting ticket (TGT):
1. C → KDC : C , TGS, L1 , N1
2. KDC genera Ticketc,tgs = EKtgs (Kc,tgs , C , T1 , L1 )
3. C ← KDC : EKc (TGS, Kc,tgs , Ticketc,tgs , L1 , N1 )
Kerberos
Fase 2: Conseguir un ticket para el servicio:
1. C genera Authenticators,tgs = EKc,tgs (C , T3 )
2. C → TGS : C , S, L2 , N2 , Ticketc,tgs , Authenticators,tgs
3. TGS genera Ticketcs = EKs (Kcs , C , T2 , L2 )
4. C ← TGS : EKc,tgs (S, Kcs , Ticketcs , L2 , N2 )
5. C genera Authenticatorc = EKcs (C , T4 )
6. C → S : Authenticatorc , Ticketcs
7. S genera Authenticators = EKcs (T4 )
8. C ← S : Authenticators
Autenticación en el WWW
Comúnmente:
1. Se establece un canal TLS con el servidor.
2. El cliente se autentica con login y contraseña.
3. Se instalan cookies en el cliente.
4. El cliente presenta una cookie en posteriores peticiones de
esta sesión.
Autenticación en el WWW
Algunos atributos de las cookies relacionados con la seguridad:
I
Domain: sólo se puede usar para ese dominio.
I
Path: sólo se puede usar para esa ruta en la URL.
I
Expires: fecha de caducidad.
I
Secure: sólo para usar con HTTPS.
I
HttpOnly: no accesibles para scripts.
Autenticación en el WWW
Riesgos comunes:
I
Mallory puede reemplazar las cookies si se hace pasar por el
servidor .
I
Session hijacking : Mallory se hace con la cookie (nos roba la
sesión). P. ej. cuando se mezcla HTTPS con HTTP (¡muy
mala idea!) hay riesgo de enviar cookies delicadas en claro.
I
Session fixation: Mallory nos induce a crear una sesión con un
ID determinado (por tanto, puede continuar con la sesión). P.
ej. phising.
Autenticación en el WWW
Riesgos comunes:
I
Cookie poisoning : Mallory forja sus propias cookies para
autenticarse como otro usuario.
I
Cross-site scripting (XSS): Mallory introduce scripts
maliciosos en las páginas que visitas (de una tercera parte)
que ejecutan como si fuesen legı́timos.
I
Ojo: los scripts maliciosos se pueden inyectar en páginas mal
hechas, en caches intermedias, en la cache del navegador, lo
puede hacer el propio navegador, etc.
Autenticación en el WWW: XSS
Ejemplo de script inyectado que roba la cookie para el sitio en el
que estamos:
<SCRIPT type="text/javascript">
var adr = ’../evil.php?cakemonster=’ + escape(document.cookie);
</SCRIPT>
Ejemplo de https://www.owasp.org
Autenticación en el WWW: XSS
Ejemplo de página vulnerable:
I
Código HTML:
<html>
<body>
<? php
print "Not found: " . urldecode($_SERVER["REQUEST_URI"]);
?>
</body>
</html>
I
Si pedimos esta página:
I
Se responde:
I
Si pedimos esta página:
I
Se responde:
http://testsite.test/file_which_not_exist
Not found: /file_which_not_exist
http://testsite.test/<script>alert("TEST");</script>
Not found: / (but with JavaScript code <script>alert("TEST");</script>)
Ejemplo de https://www.owasp.org
Autenticación en el WWW
Open ID:
I
Propósito: autenticación federada para el WWW.
I
Idea: usas un servidor de Open ID para autenticarte ante una
aplicación web de un tercero sin darle tu contraseña.
I
Proveedores de Open ID: Google, Facebook, Yahoo!,
Microsoft, AOL, MySpace.
I
No confundir con OAuth.
I
Riesgo de spoofing : se presenta una página exactamente igual
que la del proveedor de Open ID, pero que no es del proveedor.
Autorización en el WWW
c Justen Stepka
Imagen Control de acceso
Control de acceso
I
Acceso: un sujeto activo que intenta interactuar con un objeto
pasivo realizando una operación de acceso.
I
El sistema permite/deniega en base a:
I
I
I
Lo que le está permitido hacer al sujeto.
Lo que está permitido hacerle al objeto.
Errores en el diseño o la implementación pueden permitir
realizar operaciones no autorizadas.
Ejemplo: side-channel de Dropbox.
Operaciones de acceso
Ejemplos:
I
Añadir
I
Leer
I
Escribir
I
Ejecutar
I
Borrar
I
Cambiar permisos
I
Cambiar dueño
I
Listar
I
Buscar/atravesar
Pertenencia
El control de acceso puede ser
I
Discrecional (Discretionary Access Control o DAC): el
usuario posee objetos y autoriza al resto para acceder a ellos.
I
Obligatorio (Mandatory Access Control o MAC): los usuarios
no gestionan el acceso a los objetos.
Mandatory Access Control
I
I
Entornos muy restrictivos (p.ej., militares).
Sistemas de Seguridad Multinivel (MLS):
I
I
I
I
Centrados en la confidencialidad (modelo Bell-LaPaluda):
I
I
I
Usuarios con rango.
Objetos con nivel de seguridad.
Compartimentos.
Puedes generar documentos de tu nivel o de más alto nivel.
Puedes observar documentos de tu nivel o de más bajo nivel.
Centrados en la integridad (modelo BIBA):
I
Puedes modificar documentos de tu nivel o de más bajo nivel.
Mandatory Access Control
Ejemplo: Mandatory Integrity Control (MIC) en Windows 7 aplica
MAC BIBA antes de aplicar el control de acceso discrecional:
Cuatro niveles:
I Bajo (no confiable). Los ejecutables pueden ser marcados como nivel bajo si son
peligrosos (p.ej. bajados de Intenet y no firmados). Sólo pueden modificar
carpetas temporales, etc.
I Medio (usuario). Los usuarios normales y los objetos que no tienen etiqueta de
integridad tienen este nivel.
I Alto (administrativo). Los administradores tiene este nivel, la carpeta de
Archivos de Programa, etc.
I Sistema (control total). Los servicios del sistema tienen este nivel.
IBAC
IBAC: Control de acceso basado en la identidad.
I
Access Control Matrix: filas: usuarios, columnas: objetos.
esoriano
paurea
nemo
sdemingo
list.c
r,w
r
r
-
a.doc
r
r
r,w
-
word.exe
w,x
r,w,x
IBAC
I
Access Control List: una columna de la matriz.
list.c
esoriano
paurea
nemo
sdemingo
r,w
r
r
-
Caso: UNIX
Permisos POSIX:
I
Permisos rwx para dueño, grupo, y resto.
I
Los grupos se especifican en /etc/groups.
I
chmod cambia los permisos.
I
chown cambia el dueño de un fichero. Sólo puede hacerlo root.
Caso: UNIX
Permisos POSIX:
I
chgrp cambia el grupo de un fichero. Lo puede hacer el dueño
del fichero (tiene que pertenecer al grupo al que se cambia).
I
sticky bit (+t) en directorios: restringe la eliminación de
entradas de directorio aunque el directorio tenga permisos de
escritura para todo el mundo: sólo puede borrar/renombrar el
dueño y root. P. ej. /tmp
Caso: ACLs en Mac OS X
Ejemplo de ACLs, Mac OS X:
I
Conviven con los permisos UNIX. Nota: Linux (ext3) también
tiene ACL extendidas, pero no son iguales (man acl).
I
La ACL extendida es una lista ordenada de ACEs (Access
Control Entry).
I
Se pueden listar las ACLs extendidas con ls -le
Caso: ACLs en Mac OS X
I
La ACL extendida es una lista de ACE (Access Control Entry).
I
Una ACE se compone de:
I
I
I
¿Quién?: usuario o grupo.
Permiso: Allow o Deny.
Acción de acceso sobre el objeto.
I
Un usuario tiene acceso a un recurso si alguna ACE Allow o
los permisos UNIX se lo permiten, excepto si alguna ACE
Deny se lo impide → Los Deny mandan.
I
Es más fácil controlar el acceso determinando los permisos de
los contenedores (directorios) y que los ficheros los hereden.
Caso: ACLs en Mac OS X
I Acciones de acceso:
delete, readattr, writeattr, writeextattr, readsecurity, writesecurity,
chown.
I Directorios:
list, search, add file, add subdirectory, delete child.
I Ficheros:
read, write, append, execute.
I Herencia (para directorios):
file inherit, directory inherit, limit inherit, only inherit.
Ejemplo:
chmod +a ‘‘group:wheel deny delete,file inherit,directory inherit’’ dir1
Caso: ACLs en Windows 7
Dos tipos:
I
DACL (Discretionary ACL): lista de ACEs que permiten o
deniegan un tipo de acceso para una cuenta o grupo.
I
SACL (System ACL): usada para auditar, es una lista de ACEs
que indican el tipo de acción que provocará una entrada en el
Security Event Log.
RBAC
RBAC: Control de acceso basado en roles.
I
Rol: colección con nombre de permisos.
I
Se asignan roles a los sujetos/grupos del sistema. Un usuario
puede tener más de un rol. Los roles pueden ser dinámicos.
I
Un grupo es un conjunto de usuarios, un rol es un conjunto de
permisos.
I
Puede haber una jerarquı́a de roles.
I
Es útil para implementar la separación de deberes.
I
Escalabilidad: los usuarios del mismo tipo suelen tener los
mismos privilegios.
I
Cómodo: en general, los usuarios cambian más frecuentemente
que los privilegios que tienen las distintas clases de usuarios.
Capabilities
Control de acceso basado en capablities:
I
El sujeto presenta un capability junto con su petición para
realizar una operación de acceso.
I
La capability puede ser un certificado firmado, un ticket, una
secuencia pseudo-aleatoria, etc.
I
Facilita la delegación de privilegios y la escalabilidad.
I
Dificulta la revocación de privilegios y la auditorı́a (quién
puede hacer qué en un momento dado).
Autorización en el WWW: OAuth
OAuth :
I
Propósito: autorización para usar APIs de terceros sin dar las
credenciales.
I
El usuario permite a un tercero acceder a ciertas operaciones
del API de un servicio web, sin darle tu contraseña.
I
Usa timestamps, nonces y firmas digitales.
I
Ejemplos: Twitter, YouTube.
Autorización en el WWW: OAuth
c Google
Imagen ABAC
Control de acceso basado en atributos:
I
Un atributo del sujeto le autoriza a acceder a un recurso.
I
Por ejemplo: edad, nacionalidad, etc.