sandbox-caja-magica

Sandbox “La Caja Mágica”

¿Que es SandBox?

Sandbox viene del anglicismo “caja de arena” que se utiliza mucho en países americanos para que los niños jueguen sobre todo en época de verano, en el término de seguridad un SandBox es una máquina virtual donde se corren los procesos maliciosos antes de que lleguen al usuario final.

En la actualidad existen en el mercado varias soluciones de SandBoxing que nos dan un gran abanico de opciones y de sabores.

¿Porqué implementar un SandBox en mi organización?

Es una de las preguntas más complejas de responder pero más fáciles de explicar.

Recientemente se ha venido incrementando los códigos maliciosos específicamente el “malware” que busca sacar dinero a los usuarios de la organización ejecutando programas de procedencia “no confiable”, un ejemplo palpable lo tenemos recientemente con el Cryptolocker que cifraba los datos del afectado y pedía un rescate para enviarte la llave para descifrar los datos.

Si tenemos un solución de SandBoxing permitirá que antes de que le demos clic a una imagen, url, fichero o cualquier tipo de información adjunta al correo electronico se ejecute en una máquina virtual comprueba si es de fuente confiable y que no venga codificado (código malicioso), luego de verificar que el correo electronico es confiable o legítimo le permite al usuario abrir el contenido anexado sin ningún tipo de riesgo a infecciones o robo de información.

¿Cuanto tiempo me lleva implementar una solución de SandBoxing?

Dependiendo de la casa fabricante que elijamos podremos tener un tiempo de implementación corto y que se reduce en complejidad del proyecto y dedicación de recursos.

Existen soluciones que se integrarán nativamente con las demás soluciones que tenemos en nuestro entorno corporativo como por ejemplo las consolas antivirus o los servidores de parcheo de sistemas corporativos, teniendo como especial punto que en estos últimos sistemas se aloja el core business es decir, los sistemas que mantienen el negocio y que deben de funcionar las 24 horas los 365 días del año con un porcentaje superior al 99.9999% de disponibilidad.

En este sentido lo más lógico sino queremos tener recursos dedicados al proyecto o evitarnos la complejidad de una implementación podemos contratar servicios en la nube (cloud) que hoy en día ofrecen la mayoría de los fabricantes.

¿Cuanto cuesta una solución de SandBoxing?

No te cuestiones ni de vueltas a la hora de invertir en este tipo de soluciones, la respuesta seria la siguiente: “¿Cuánto dinero pierdes si un código malicioso te bloquea o roba la información?”

Muchas veces lo primero que nos preguntamos es cuanto cuesta pero nunca hemos realizado un ejercicio de riesgo tecnologico o una matriz de riesgo que nos plantee en dinero $$$$ €€€€ cuánto perdemos hora/hombre hora/negocio si tenemos por ejemplo “Cryptolocker acechandonos”, cuando una verdad es cierta cada dia las mafias mejoran mas y mas el codigo haciendo que sea una lucha de hormiguitas o que la labor de bloqueo de URL en los Firewalls sea prácticamente imposible.

¿Quién nos puede asesorar en este tipo de soluciones?

Más que vendernos una solución lo clave es buscar la persona o la consultora que nos de no solo una consultoría experta porque instalar “facil” pero tunear una solución de SandBoxing es donde está el secreto.

Por eso es preferible si no somos expertos contratar horas de servicio del propio fabricante que nos sirva para llevar a cabo el proyecto sin ningún tipo de contratiempos.

Finalmente les dejo algunos URL que les servirán para ampliar esta información.

Hasta la próxima……

https://blogs.mcafee.com/business/security-connected/thinking-outside-of-the-sandbox-mcafee-advanced-threat-defense-unveiled

https://blogs.mcafee.com/business/developing-the-ultimate-defense-against-advanced-malware

http://blog.trendmicro.com/trendlabs-security-intelligence/deploying-a-smart-sandbox-for-unknown-threats-and-zero-day-attacks/

https://support.symantec.com/en_US/defaultProductLanding.63070.html

http://docs-legacy.fortinet.com/fos50hlp/50/index.html#page/FortiOS%205.0%20Help/antivirus_chapter.150.25.html

 

 

 

 

salt_pepper

Aliñando contraseñas en base de datos, ¿desarrollas o enriqueces?

En el anterior post hablamos de contraseñas desde el punto de vista de un usuario, de la importancia que tiene tener una buena política para evitar que sean sencillas de descubrir tanto a nivel de imaginación como de procesamiento mediante fuerza bruta.

En esta entrada vamos a centrarnos en las formas que hay para tratarlas y almacenarlas poniéndonos en la piel del desarrollador de aplicaciones.

La prehistoria… ¿o no?

Hace años, las aplicaciones que necesitaban gestión de usuarios se creaban implementando acceso a una base de datos en la que se guardaba la habitual pareja “usuario – contraseña”. Cuando se realizaba el proceso de login en el que el usuario indicaba sus credenciales (<user, <password>), bastaba con preguntar algo del tipo:

select user from users where user = <user> and password = <password>

Si obteníamos respuesta, entonces el usuario era quien decía ser, así de sencillo.

Esto, que debería ser algo totalmente obsoleto, todavía lo podemos encontrar en muchas más aplicaciones webs y de escritorio de las que creeríamos…

A modo de ejemplo, el dump de una base de datos MySql de una conocida marca de… (la llamaremos “Acuario” para no dar su verdadero nombre) almacena las credenciales de sus usuarios en un sistema vulnerable a ataques SQL Injection tal que así:

mysql_dump

Dump MySQL con información privada en texto plano

No hace falta decir que almacenar nombre, apellidos, usuario y contraseña de esta forma no es lo correcto, el desarrollador no ha hecho bien los deberes.

Almacenamiento de hashes

El siguiente paso fue dejar de almacenar los dos valores para almacenar el usuario y “algo” relacionado con la contraseña. Ese algo es un hash.

Un hash es el equivalente a una huella digital. Se consigue realizando un proceso matemático que da un valor de salida determinado a un objeto de entrada (podemos hablar de un fichero, un texto, un número…). Es importante tener en cuenta que un proceso de hashing debe ser irreversible, lo que quiere decir que no debemos ser capaces de calcular el objeto de entrada a partir del objeto de salida (ahí reside su fuerza como algoritmo).

Aunque no vamos a entrar en ellos, los algoritmos de hashing habituales son SHA (Secure Hash Algorith) y MD5 (Message-Digest Algorithm 5).

El sentido de todo esto es almacenar hashes en lugar de contraseñas. Así, si alguien ve nuestro hash, no le servirá de nada ya que no podrá deshacerlo.

En este caso, se ha dado un paso más para complicarle la vida a un atacante. Suponiendo que ha conseguido el dump de nuestra base de datos de usuarios, ya no lo tendrá tan sencillo como antes (recordemos que solamente tenía que saber leer para conseguir las credenciales). Ahora tendrá que realizar un ataque de fuerza bruta para generar hashes e ir comparando hasta dar con el objeto de entrada que genera el hash de salida almacenado en la tabla.

Aquí enlazamos con la importancia de tener una buena política de contraseñas, ya que existe lo que se conoce como “tablas rainbow” que son tablas con hashes ya calculados para grandes cantidades de posibles contraseñas.

Cuanto más sencilla sea nuestra contraseña, más probabilidad habrá de que se encuentre en una de estas tablas y que el atacante consiga las credenciales.

El funcionamiento desde el punto de vista del desarrollo es sencillo, cuando ingresemos nuestras credenciales <user> y <password>, se calcula el hash de la contraseña introducida y se compara con el que hay en base de datos, algo como:

select user from users where user = <user> and hash = hash(<password>)

En este ejemplo podemos ver una base de datos de prueba en la que se han obtenido los nombres de usuario y los hashes. Mediante un ataque de fuerza bruta con diccionario incluso se han podido sacar algunas contraseñas en claro.

hash_mysql

Dump MySQL con información privada hasheada y algunos valores obtenidos mediante fuerza bruta.

La práctica actual, “aliñando” el problema

Para atajar el problema de las tablas rainbow se ha optado por dar un paso más en complicar la vida al atacante. Surgen entonces los planteamientos con “salt & pepper” (sal y pimienta), que consisten en utilizar cadenas que se concatenan con la contraseña de usuario para convertir cualquier password débil en una password fuerte.

Imaginemos que tu contraseña es algo como “123456” (sólo números y longitud 6). El hash de esta contraseña va a estar en tablas rainbow, por lo que el atacante conseguiría credenciales casi al instante.

La aplicación podría añadirle el salt “f0Et%%kS*yJ@” y convertir tu pass en “123456_f0Et%%kS*yJ@”. Con este sencillo paso, tu clave débil se ha convertido en una clave fuerte, hemos conseguido una buena defensa frente a ese atacante.

Normalmente ese salt se almacena en la propia base de datos y se utiliza para realizar la consulta, que sería del tipo:

select user from users where user = <user> and hash = hash(<password>+salt)

Como alternativa o paso más, podríamos utilizar el pepper que es igual que salt, pero almacenado fuera de la base de datos.

hash_salt

Dump MySQL con hash y salt almacenados en la misma tabla

¿ Con esto ya estamos seguros?

La seguridad absoluta es una quimera, en nuestro caso (recordad que tenemos puesto el casco de desarrollador ahora mismo) nuestra intención es que los datos que almacenamos sean lo más complejos de obtener en el caso hipotético de que un usuario malicioso haya llegado a ellos.

Debemos poner medidas externas para evitar que se pueda acceder a la base de datos, pero tomar este tipo de controles es una buena práctica que todo desarrollador debe tener en cuenta.

Pensad siempre que si alguien quiere entrar, es posible que lo consiga. Cuantas más piedras le pongamos en el camino, más probabilidad tendremos de aburrirle en su tarea y de que decida cambiar por otro objetivo más sencillo.

Pero sobre todo, a nivel de imagen, no podemos permitirnos que los datos personales de nuestros clientes sean publicados, es nuestro deber aplicar medidas preventivas como estas, sobre todo cuando son tan sencillas de implementar.

 

Espero haberte ayudado con esta visión de seguridad en contraseñas desde los perfiles de usuario y desarrollador. En cualquier caso, si ves algún error, no estás de acuerdo con lo que cuento o quieres hacer alguna aportación, no dudes en pasarte por los comentarios.

¡Feliz semana!
informacion-privada-apps

Información privada en apps… ¿es posible?

Si eres un desarrollador con la intención de mantener información privada en apps, seguro que en tu cabeza ronda algo como… ¿puedo estar tranquilo de que los datos no salgan del móvil? La respuesta rápida es que… no, pero con algunos matices… Leer más