Prog Segura CWE-3 - profesor MAZ PDF

Preview

Summary

profesor MAZ...

Description

Seguridad Porosa Debilidades relacionadas con tecnicas defensivas que son usadas incorrectamente, abusadas o simplemente ignoradas.   

Encriptación Porosa Autentificación Porosa Autorización Porosa

Encriptación Porosa Debilidades relacionadas con la falta de encriptación, el uso incorrecto de la encriptación o su abuso.   

CWE-319: Cleartext Transmission of Sensitive Information CWE-311: Missing Encryption of Sensitive Data CWE-300: Channel Accessible by Non-Endpoint

La información transmitida sin ser encriptada es leida facilmente por herramientas tipo sniffers que leen la información en un punto intermedio entre emisor y receptor (se conoce como ataque Man-in-the-Middle http://capec.mitre.org/data/definitions/94.html).

Encriptación Porosa CWE-313: Cleartext Storage in a File or on Disk Información sensible (información personal, etc) no deberia guardarse en un fichero sin encriptarse ya que cualquiera podria acceder al fichero y obtener esa información.  CWE-318: Cleartext Storage of Sensitive Information in Executable Información sensible tampoco debe incluirse en un ejecutable ya que un atacante puede user ingenieria inversa en el código binario para obtener datos que no hayan sido cifrados.  CWE-921: Storage of Sensitive Data in a Mechanism without Access Control Existen mecanismos de almacenamiento que no tiene mecanismos de control de acceso, pe. memory cards, floppy disks, CDs, y disposivos USB en los que no se deberia de guardar información sensible. 

Encriptación Porosa CWE-327: Use of a Broken or Risky Cryptographic Algorithm Algunos algoritmos criptograficos pueden ser crackeados en poco tiempo por la fuerza bruta. Pj. DES (Data Encryption Standard) ya se considera un algoritmo insuficiente en muchas aplicaciones y se utiliza el AES (Advanced Encryption Standard). 

CWE-326: Inadequate Encryption Strength Cuando el tiempo de crackeo de los datos encriptados depende del tamaño de la llave de encriptación, es importante usar una llave con un tamaño adecuado. RSA dice que una llave de 2048-bit será suficiente hasta 2030. Una llave de 3072 bits deberia usarse si se quiere seguridad más allá del 2030 (https://es.wikipedia.org/wiki/RSA) (http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/key-size.htm) 

Ataques Fuerza Bruta http://en.wikipedia.org/wiki/Brute-force_attack  Consiste en usar todas las combinaciones de llaves o passwords hasta acertar con la adecuada.  se han desarrollado hardware especifico para hacer estos operaciones en el menor tiempo posible.  Se emplean para desencriptar, o para descubrir passwords.  Con llaves o passwords largos el tiempo de busqueda crece exponencialmente.

DES Cracker circuit board fitted on both sides with 64 Deep Crack chips

Clase del ataque (PC -> Cluster) y tiempo de recuperación de contraseña por “fuerza bruta” http://www.tufuncion.com/ataques-passwords-hacker-msn (2006)

Contraseñas Pwd

Combinac iones

Clase A

Clase B

Clase C

Clase D

Clase E

Clase F

darren (Solo 6 letras)

308.9 millones

8 horas

51 minutos

5 minutos

30 Secs

3 Secs

Inmediato

B33r&Mug (8 letras, números y caracteres)

72.000 billones

22.875 años

2.287 años

229 años

23 años

2 años

83 días

Autentificación Es el acto de verificar una petición de identidad. Hay tres tipos información que se pueden usar para autentificar: 





Algo que tienes: el carnet de identidad, una tarjeta con banda magnética,.. Algo que sabes: por ejemplo los PIN, un password, o el apellido de soltera de tu madre (US). Algo que eres(biométricas): huellas dactilares, las líneas de manos, la voz, o los dibujos de retina.

Proceso de acceso de usuario El sistema o aplicación solicita al usuario su identificación y la credencial que lo demuestra (password, dni, datos biométricos) 2. El sistema comprueba que la credencial es correcta: la compara con datos almacenados. Empiezan los problemas:  La credencial (password,..) tiene que estar almacenada en el sistema: ¿te fías del sysadmin? Primera solución: encriptar las credenciales (passwords,..), se utilizó en primeros Unix.  Y ahora el problema es ¿Quién guarda la llave de encriptación? 1.

Solución: Uso de Hash/ Digest de credenciales F_Digest(“Creden Auth_Server

cial_inicial”) Username

(Username, “Credencial_entrada”) Digest ¿F_Digest(“Credencial_entrada”) == Digest? OK/NOK Al crearse la credencial, se guarda el Digest en sistema: Digest = F_Digest (“Credencial_inicial”)

Cuando un usuario introduce su credencial, se calcula el digest en los datos actuales: Digest_now == F_Digest(“Credencial _actual”)

Si ambos datos son iguales entonces el usuario ha introducido la credencial correcta.

Solución: Uso de Hash/ Digest de credenciales En linux se guarda en ficheros /etc/passwords.  En apps de BBDD se guarda en campo pass de tabla usuarios. Si roban la tabla de digest, no pasa nada. Problema: no podemos recordar la clave al usuario que la olvide. 

Medidas para Recordar contraseña 

Comprobación adicionales:  preguntas

personales

 Añadir

CAPTCHA: “Completely Automated Public Turing test to tell Computers and Humans Apart”

 Enviar

enlace para resetear.  Enviar password por SMS.

Autentificación Porosa Debilidades relacionadas con la falta de autentificación, el uso incorrecto de la autentificación o su abuso.  

 

  

CWE-328: Reversible One-Way Hash* CWE-759: Use of a One-Way Hash without a Salt* CWE-640: Weak Password Recovery Mechanism for Forgotten Password CWE-307: Improper Restriction of Excessive Authentication Attempts* CWE-306: Missing Authentication for Critical Function* CWE-798: Use of Hard-coded Credentials* CWE-287: Improper Authentication

String username = request.getParameter("username"); String password = request.getParameter("password"); int authResult = authenticateUser(username, password);

CWE-307: Improper Restriction of Excessive Authentication Attempts Hay que evitar que un atacante pueda realizar todos los intentos que quiera para probar diferentes passwords y acceder a un sistema . String username = request.getParameter("username"); String password = request.getParameter("password"); int authResult = authenticateUser(username, password);

Se debe restringir el numero de intentos de acceso al sistema: String username = request.getParameter("username"); String password = request.getParameter("password"); while ((authResult == 0) && (count < MAX_ATTEMPTS)) { int authResult = authenticateUser(username, password); count ++; }

Medidas para evitar ataques en sistemas autentificación Para evitar ataques fuerza bruta:  Poner un numero alto de reintentos  Ralentizar sucesivamente reintentos sucesivos  Guardar también el numero de reintentos globales (y obligar a cambiar, cuando es alto) https://www.owasp.org/index.php/Authentication_Cheat_Sheet

Ataques de diccionario Intentar acceder con un conjunto finito de claves/passwords que son habitualmente usados por los usuarios. (vs. fuerza bruta que usaria todos los posibles elementos)

• Suficientemente largas (8 caracteres) Incluso más! • Evitar claves parecidas en distintos sitios • Evitar palabras, títulos de libros, ciudades, ... • Incluir símbolos de puntuación

Elección de claves de acceso

CWE-328: Reversible One-Way Hash Los algoritmos de autentificación basados en hash que se utilizan para guardar información sobre los passwords pueden ser revertidos y obtenerse el password o una clave con métodos como: Ataques de Tablas de Hash o Tablas Rainbow. http://en.wikipedia.org/wiki/Dictionary_attack http://en.wikipedia.org/wiki/Rainbow_table http://www.securityfocus.com/blogs/262 Los algoritmos de hash MD4, MD5 y SHA1 han sido comprometidos. El gobierno US recomienda SHA 2 con llave de 256. Algoritmos que necesitan muchos recursos computacionales y por lo tanto más costosos de revertir, son bcrypt, scrypt, o PBKDF2.

Ataques con Tablas de Hash y Tablas Rainbow Tablas de hash generadas a partir de claves/ passwords habituales. Tomate -> Hash(Tomate) = aqw Patata -> Hash(Patata) = 12d Pamplona -> Hash(Pamplona) = 3sw Madrid -> Hash(Madrid) = we4

Si se obtienen los Hash de los usuarios reales, se puede realizar una busqueda en la tabla Rainbow y averiguar el password del usuario. Aqw -> Tomate 12d -> Patata 3sw -> Pamplona We4 -> Madrid

Tabla con Hash/Rainbow Pre-computada

(No contienen todos los passwords posibles -> uso de passwords únicos). Las tablas pueden ser bastante grandes, varios Gigas, pero no infinitas. Solución: usar Salts al hacer el Hash.

Solución: Uso de Hash con Salts Al generar el hash se añade “salt” al password del usuario, se concatena: saltedhash(password) = hash(password + salt) Or saltedhash(password) = hash(hash(password) + salt)

El “salt” es una cadena aleatoria para cada usuario. Efectos:  Las tablas de hash pre-computadas no son factibles en tamaño, especialmente si el salt es aleatorio y diferente para cada usuario,  Dos usuarios con el mismo password tendran saltedhash diferentes,  Aunque se conozca el saltedhash y el salt, se tendria que calcular todos los saltedhash para crear la tabla pre-computada. Importante: el Salt se guarda con el Hash en la BBBD. Se recomienda un Salt de 64 Bits

CWE-759: Use of a One-Way Hash without a Salt.

CWE-798: Use of Hard-coded Credentials No se debe de incluir nombres de usuario y passwords en código cliente que accede a un servidor. Pje. Este código se conecta a una base de datos: DriverManager.getConnection(url, "scott", "tiger"); ...

Cualquiera que tenga el software cliente puede obtener con unas sencillas herramientas el username y password, y además no podemos cambiar el username y password porque sino dejamos sin acceso a los clientes que utilicen esa versión del software. En java la utidad javap -c permite el acceso al código a nivel de compilador, para el ejemplo anterior se obtendria la siguiente salida, mostrando el username y password. javap -c ConnMngr.class 22: ldc #36; //String jdbc:mysql://ixne.com/rxsql 24: ldc #38; //String scott 26: ldc #17; //String tiger

public BankAccount createBankAccount(String accountNumber, String accountName, double balance) { BankAccount account = new BankAccount(); account.setAccountNumber(accountNumber); account.setAccountOwnerName(accountName); account.setBalance(balance); return account; }

CWE-306: Missing Authentication for Critical Function

Funciones criticas son aquellas que realizan La autorización puede realizarse por diferentes operaciones consideradas imporantes por que mecanismos, pej. una función que autentifica el usuario y que pone a true una variable booleana. acceden a recursos valiosos, pej. Crear un cuenta bancaria: public BankAccount createBankAccount(String private boolean isUserAuthentic = false; accountNumber, String accountName, double balance) public boolean authenticateUser(String username, String { password) { BankAccount account = new BankAccount(); account.setAccountNumber(accountNumber); account.setAccountOwnerName(accountName); account.setBalance(balance); } return account; public BankAccount createNewBankAccount(String } accountNumber, String accountName, double balance) {

Este tipo de operaciones no deben de realizarse por usuarios no autorizados: debe de existir un mecanismo de autorización que verifique que el usuario tiene la autorización para realizar esa operación.

BankAccount account = null; if (isUserAuthentic) { account = new BankAccount(); account.setAccountNumber(accountNumber); account.setAccountOwnerName(accountName); account.setBalance(balance); } return account; }

Autorización Porosa Debilidades relacionadas con la falta de autorización, el uso incorrecto de la autorización o su abuso.    

CWE-284: Improper Access Control CWE-285: Improper Authorization* CWE-266: Incorrect Privilege Assignment CWE-732: Incorrect Permission Assignment for Critical Resource*



CWE-250: Execution with Unnecessary Privileges CWE-271: Privilege Dropping / Lowering Errors* CWE 272: Least privilege violation*



CWE-807: Reliance on Untrusted Inputs in a Security Decision*

 

umask(0); FILE *out; out = fopen(“hello.out”, "w"); if (out) { …}

CWE-732: Incorrect Permission Assignment for Critical Resource Debido a mal interpretaciones o confusiones de los comando es facil realizar asignaciones de permisos incorrectas. En este ejemplo se llama a umask(0) para no tener mascara y poder especificar los permisos que se quieren, pero fopen por defecto pone permisos rw-rw-rw- (0666): umask(0); FILE *out; out = fopen(“hello.out”, "w"); if (out) { …}

Sin embargo si se queria que el fichero tuviera permisos rw-r--r-- (0644), la llamada correcta para conseguir lo es: umask(0); FILE *out; out = open("test", O_CREAT | O_EXCL, 0644); if (out) {…}

CWE-271: Privilege Dropping / Lowering Errors  

No se realiza una operación para disminuir los privilegios tras aumentarlos. En este ejemplo, chroot() solo se ejecuta como root.  chroot(directorio) establece como directorio raiz a “directorio”  pero se sigue ejecutando como root. 

chroot(APP_HOME); chdir("/"); FILE* data = fopen(argv[1], "r+"); 

Habria que bajar los privilegios y ejecutarse como un usuario normal.

CWE 272: Least privilege violation El sistema tiene que ejecutarse siempre con los privilegios mínimos necesarios para ejecutar las tareas requeridas. Algunos mecanismos que implementan este principio:  Crear cuentas individuales para cada tarea con privilegios limitados, de esta manera un atacante solo podrá acceder a los recursos de esa cuenta.  Minimizar los bloques de código que contiene instrucciones de cambios de privilegios. Ejemplos de bloques de código con privilegios: C seteuid(0); seteuid(getuid())

Java AccessController.doPrivileged( new PrivilegedAction() { public Object run() { } })

String ip = request.getRemoteAddr(); InetAddress addr = InetAddress.getByName(ip); if (addr.getCanonicalHostName().endsWith("trustme.com")) { trusted = true; }

CWE-807: Reliance on Untrusted Inputs in a Security Decision Si la asignación de roles, permisos, etc se produce en base a un valor leido de una fuente no fiable (fichero local, cookie, fichero remoto, nombre de dominio,…) un atacante puede modificar dicha fuente para obtener los roles o permisos no autorizados. En este ejemplo se toma una decision en base al nombre de dominio de un servidor: String ip = request.getRemoteAddr(); InetAddress addr = InetAddress.getByName(ip); if (addr.getCanonicalHostName().endsWith("trustme.com")) { trusted = true; }

Sin embargo, el sistema de DNS (las caches o servidores intermedios) pueden alterarse para devolver otros valores. Es major basarse en la IP, pero tambien puede ser modificada. Una combinación de metodos es lo major.

if (! AuthenticateUser($q->param('username'), $q->param('password'))) { ExitError("invalid username or password"); } my $id = $q->param('id'); DisplayPrivateMessage($id);

CWE-285: Improper Authorization El siguiente código comprueba correctamente que un usuario esta autentificado : if (! AuthenticateUser($q->param('username'), $q->param('password'))) { ExitError("invalid username or password"); } my $id = $q->param('id'); DisplayPrivateMessage($id);

Sin embargo no se comprueba si el usuario tiene autorización para acceder al mensaje con identificador ‘id’. Cualquier usuario autentificado podria leer la información de cualquier otro usuario....