sábado, 8 de septiembre de 2012

Inseguridad Bancaria Online. Parte IV

Dicen que cuando estamos más ocupados es el mejor momento de darnos más trabajo. En consecuencia, decidí escribir este artículo que está más que en deuda y recuperar un poco mi blog que ha estado en el olvido por demasiado tiempo ya.

En otros artículos de esta serie hemos escrito sobre el "teatro de seguridad" que tanto gusta a las organizaciones que ofrecen servicios de banca en linea. Este artículo está dedicado a todavía otra práctica que tiene más finalidad de teatro que de seguridad propiamente dicha.

Las famosas tarjetas de coordenadas.

Como bien sabemos, los sistemas de autenticación basados en un sólo factor (e.g. la conocida contraseña) sufren de una gran cantidad de amenazas de dificil solución. La idea detrás de las tarjetas de coordenadas es proveer al usuario de banca en linea de un sistema de autenticación adicional y, al menos en teoría, más robusto. En teoría, los dos factores de autenticación combinados deberían darle una protección adicional. En la práctica, sin embargo, la implementación de esta solución está usualmente plagada de demasiados problemas, fallas y vulnerabilidades. Algunas de las implementaciones que he visto tienen tantos huecos que sus huecos tienen huecos.

La descripción de este mecanismo es muy sencilla. El usuario es provisto de una serie de códigos que bajo determinadas condiciones son requeridos por el sistema web antes de ejecutar la transacción solicitada. Esta serie de códigos por lo general están organizados en una especie de "tabla" de fácil consulta para permitir al usuario contestar el "reto" que le plantea el sistema en una situación particular. Estas situaciones de "reto" pueden ser muy variadas, por ejemplo, pueden ser utilizadas desde para autorizar transacciones privilegiadas, pasando por la re-autenticación del usuario despues de la detección de patrones de uso inusuales o incluso hasta para inciar sesión. Por otro lado, el mencionado "reto" consiste usualmente en preguntar al usuario algún subconjunto de datos contenidos en la tarjeta de coordenadas que se supone sólo deberían ser conocidos por el poseedor de este instrumento.

He aquí el primer detalle. La teoría de los "multiples factores" de autenticación postula que la seguridad se incrementa cuando se insertan factores adicionales "distintos", mientras que multiples factores "iguales" no tienen un verdadero valor. Por ejemplo, si le impongo a mi sistema solicitar una contraseña y luego otra contraseña (dos factores de algo que "conoces") la seguridad no aumenta demasiado. Por el contrario, si combino algo que "conozco" con algo que "soy" (biometría), pues la seguridad aumenta notablemente. Nótese que muchas veces los factores de conocimiento, posesión y existencia no están bien definidos. Por ejemplo, uno podría pensar que los datos que utilizan los sistemas de biometría (minutia) son en realidad algo que se podría "conocer". Si tengo acceso a interactuar con el sistema que recibe esta minutia, acabo de transformar una autenticación de algo que soy, en una autenticación basada en algo que "conozco".

Bajo esta óptica, una tarjeta de coordenadas podría ser interpretada simplemente como una contraseña bien larga, y encima escrita en un pedazo de plastico. Justo lo que siempre nos han dicho que no debemos hacer (escribir nuestras contraseñas). Pero eso no es todo. Por otro lado, la generación de estas "contraseñas largas" no son de facil "cambio", no las pensamos nosotros, y son extremadamente dificiles de memorizar, por lo cual deben estar siempre escritas en algún lado. Creo que no hay ninguna otra recomendación que estas "contraseñas largas" podrían violar.

Sin embargo, todas estas ideas abordan el problema desde una óptica más bien operacional. El desarrollo de este problema lo estoy dejando para un artículo que estamos desarrollando en conjunto con segu-info, por favor que valga la cuña, excelente blog de noticias y articulos de seguridad informática en español. En lo que queda de este artículo, sin embargo, quisiera abordar el análisis de estas tarjetas de coordenadas desde un punto de vista netamente técnico, asumiendo que su utilización es llevada a cabo por un usuario "experto". Es decir, si uso todo esto de forma ideal, ¿Qué tanta protección me provée realmente?

Para este análisis, necesitamos comenzar identificando los parametros involucrados. Despues de pensar un poquito es fácil darse cuenta que existen sólo tres parametros que determinan la vida "util" de nuestras tarjetas de coordenadas:

Número de posibles simbolos. Asumamos por un momento, numeros de 0 a 99.
Numero de simbolos por "reto". Éste es el número de preguntas que nos hace el sistema en cada reto planteado. Asumamos por un momento 2.
Número de simbolos en la tarjeta. De forma general esto es el producto de las dimensiones de la tarjeta pero asumamos por un momento que es 9 x 5.

Un análisis superficial nos podría llevar a concluir "equivocadamente" que un atacante necesitaría de 10000 oportunidades para adivinar correctamente un reto sin poseer la tarjeta. Esto es simplemente la probabilidad de adivinar correctamente dos simbolos de 100 posibilidades cada uno. Aunque correcto de forma teórica, no se corresponde con la realidad práctica. Por un lado, ya hemos visto hasta el cansancio los problemas que ocurren al permitir ataques de fuerza bruta en este tipo de sistemas. En consecuencia, es inmaterial las oportunidades que necesite un atacante para "adivinar" las coordenadas puesto que de todas maneras vamos a implementar algún tipo de bloqueo despues de un número mucho más pequeño que 10000 intentos fallidos. Pero por el otro, existen muchas otras técnicas disponible para nuestro atacante ante esta situación.

Particularmente, si asumimos que el atacante puede observar un cierto número de retos resueltos de forma exitosa por el usuario legítimo, la pregunta más interesante es saber: ¿Cuantos retos tiene que observar el atacante para que el proximo reto sea ya conocido? El problema debe ser evidente: despues de un número de retos resueltos correctamente, el atacante podría tener toda la información necesaria para resolver el reto "nuevo". Por ejemplo, despues de ver los dos retos "A1 = 05, B3 = 71" y "C3 = 10, D2 = 97", el atacante puede responder los siguientes retos "nuevos": "A1, C3", "A1, D2", etc.

Este número es importante porque determina en qué momento debería el usuario pensar en reemplazar su tarjeta de coordenadas. Nótese que este número sólo depende de los parametros que habiamos identificado anterioremente y no depende de los "errores" que pueda cometer un usuario "no-experto". En consecuencia, este número es una evaluación de esta herramienta en el caso "ideal". Por otro lado, para los que les incomode requerir que nuestro atacante pueda ver la resolución de unos cuantos retos, hay que notar que esta situación no es nada dificil. De hecho, uno de los problemas que esta tarjeta de coordenadas intenta resolver es justamente ese. Proveer algún tipo de "contraseña de un sólo uso", es decir, a pesar de que el atacante la vea, pues no la puede usar a menos que el sistema vuelva a preguntarla exactamente de la misma forma en algún momento en el futuro.

Ahora bien, podríamos intentar hacer una derivación matemática de cuanto debe ser este número de forma general. Pero es demasiado temprano en la madrugada como para esos ejercicios. En consecuencia, siempre es divertido realizar un pequeño experimento de Monte Carlo y determinar ese número de forma práctica. Un muy simple programita en python arroja los siguientes resultados:


promedio 8.97 despues de 100 iteraciones
promedio 9.05 despues de 1000 iteraciones
promedio 9.0834 despues de 10000 iteraciones
promedio 9.05886 despues de 100000 iteraciones
promedio 9.049979 despues de 1000000 iteraciones

De donde se puede ver claramente que despues de unas 9 veces de haber usado nuestra tarjeta de coordenadas podemos estar bastante seguros que el siguiente reto podrá ser resuelto por nuestro atacante sin mayores problemas. No se que sistema me podría pedir que cambie una "contraseña" cada 10 veces que la use, pero más o menos eso es lo que resulta. Para los curiosos o para los que quieran corregirme (es muy temprano en la mañana, de seguro hay bugs) a continuación el programita en python que resuelve este problema:

#! /usr/bin/python -u
from __future__ import division
import random

n = 9
m = 5
iteraciones = 1000000

suma = 0
for iteracion in xrange(1,iteraciones):
        vistos = []
        count = 0
        while 1:
                a,b = random.randrange(1,n), random.randrange(1,m)
                c,d = random.randrange(1,n), random.randrange(1,m)
                if a == c and b==d:
                        continue
                #print "got",(a,b), "and", (c,d)
                if (a,b) in vistos and (c,d) in vistos:
                        #print "colision despues de ", count
                        break;
                vistos.append((a,b))
                vistos.append((c,d))
                count += 1
        suma += count

print "promedio", suma/iteraciones, "despues de",iteraciones,"iteraciones"

Pero esto no es todo. Supongamos por un momento que a nuestro usuario "ideal" no le importa cambiar su tarjeta de coordenadas despues de haberla usado tan solo 9 veces. Si le importara no sería un usuario tan "ideal" después de todo. En ese momento generaríamos otros 9x5 simbolos y comenzaría la carrera de nuevo. La pregunta inmediata es: ¿Después de cuantos cambios de tarjeta de coordenadas se hace todo este sistema completamente inútil?

Como es muy temprano en la mañana, esa pregunta la dejaré para otro momento, pero se puede vislumbrar fácilmente que la cosa no va nada bien. Sobre todo porque aquí empieza a mordernos otro problema que siempre es pasado por alto: la generación de aleatoriedad.

Este tema especificamente lo tengo reservado para otra serie de articulos que tengo en mente desarrollar justamente cuando esté todavía más ocupado que ahora. Prometo tener varias sorpresas :D