Inseguridad Bancaria Online

Usualmente recibimos propaganda de nuestras entidades financieras acerca del cuidado que se debe tener de nuestra contraseña para acceder a los portales de banca online. Sin embargo, muy pocas veces se nos advierte que el nombre de usuario/login/etc es tan importante o tal vez más que el tan celosamente guardado "password".


La razón es simple: sin la contraseña, nuestro criminal informático puede no tener acceso a realizar operaciones bancarias en linea a nuestro nombre; sin embargo, con el nombre de usuario, el atacante puede lograr que nosotros tampoco las hagamos.


El problema radica en que ningún sistema bancario en linea puede darse el lujo de permitir infinitos intentos de acceso a una cuenta bancaria. De lo contrario, expondrian a sus clientes a ataques de fuerza bruta para adivinar su contraseña. Por lo tanto, absolutamente todos los sistema de banca en linea que he visto ejecutan algún tipo de bloqueo despues de un numero predeterminado de intentos de accesos incorrectos. En consecuencia, el atacante que conozca nuestro nombre de usuario, solo necesita hacer unos cuantos intentos de ingreso incorrectos para bloquearnos el acceso a nuestra cuenta de banca en linea.

La situación empeora cuando el propio sistema de banca en linea hace que los nombres de usuario sean facilmente predecibles. Esto sucede muy a menudo cuando las entidades financieras deciden utilizar numeros de cuentas de bancos, numeros de tarjetas de debito, etc en lugar de un nombre de usuario arbitrario. La razón es simplemente comodidad a la hora de hacer el rollout de credenciales. Por ejemplo, si el usuario ya tiene su tarjeta de débito y su clave de cajero, puede usar esas mismas credenciales para acceder al sistema de banca en linea. El usuario está automáticamente listo para hacer uso de la fabulosa banca en linea sin necesidad de emitir nuevas credenciales, verificación de identidad, firma de acuerdos, etc. Ésta comodidad no viene sin su alto costo en riesgo no sólo para el usuario final, sino también para la propia entidad financiera.

El resultado inmediato, pero no el único, es una vulnerabilidad de denegacion de servicio al sistema de banca en linea que no requiere más que de un ordenador personal, una conexión a internet de muy poco ancho de banda, y un programa de una docena de lineas de código para llevarse a cabo. Las entidades financieras invierten grandes sumas de dinero en sistemas redundantes, ancho de banda, sistemas de deteccion de inundaciones, etc. pero con esta vulnerabilidad hacen que todos estos sistemas queden completamente inútiles.

Diversas culturas tienen distintas imágenes sobre el futuro apocalíptico. La imagen que a mi se me viene a la mente con este tipo de sistemas es una entidad bancaria colapsada con tickets de soporte de reseteo de credenciales de acceso y una cantidad muy grande de clientes frustrados por no poder llevar a cabo sus transacciones financieras online. A pesar de nunca haber escuchado a alguna entidad financiera aceptar que ha tenido sucesos de esta índole, yo mismo he sido victima de reiterados bloqueos de acceso inexplicables. Estoy seguro que no soy el único tampoco.

La solución definitiva a esta problemática es por supuesto el uso de nombres de usuario que sean dificiles de predecir. Sin embargo, es posible disminuir el impacto de esta vulnerabilidad sustituyendo los bloqueos permanentes por bloqueos temporales. La intención es por supuesto evitar el escenario apocaliptico dando acceso a las victimas despues de un tiempo prudencial, pero previniendo en cierta medida que el criminal informático lleve a cabo un ataque de fuerza bruta contra las credenciales de sus victimas. Esta medida paliativa, por supuesto, se hace imposible de implementar si el espacio de contraseñas es muy pequeño. Por ejemplo, en el caso en que la clave de acceso sea una cadena de 4 digitos.

Especificamente señalamos que el alcance del objetivo de nuestro atacante se hace significativamente más sencillo cuando tiene disponible esta vulnerabilidad. Los objetivos pueden ser tan variados como ejecutar un ataque de denegacion de servicios total y muy dificil de detener, o simplemente obtener un par de credenciales que le permitan penetrar mas profundamente en el sistema de la entidad financiera.


Sin embargo, no sólo cuando el sistema obliga al usuario a usar nombres predecibles estamos a merced de nuestro atacante. Algunos sistemas de banca en linea, a pesar de reconocer la importancia de utilizar nombres de usuario arbitrarios, fallan en darse cuenta que también los mensajes de error pueden dejar completamente inefectivo su mecanismo anti-adivinacion de usernames.



Lo único que el atacante requiere para aprovechar esta vulnerabilidad, es que el sistema provea distintos mensajes de error cuando se introduce un usuario válido o inválido. Esta vulnerabilidad es fácil de detectar cuando los mensajes de error anuncian explícitamente que el nombre de usuario es inválido. La razón de este fallo es hasta entendible en cierta manera. Los sistemas de banca en linea tratan de ser lo más amigables posible dando al usuario legítimo la mayor cantidad de información para corregir su error. Esta conveniencia no viene sin su gran costo de riesgo para el sistema de forma global, pues se le otorga la misma información al atacante.

La naturaleza de esta vulnerabilidad es muchas veces tan sútil, que no es necesario que el sistema revele a nuestro atacante explícitamente que el nombre de usuario intentado es inválido. Muchas veces, nuestro atacante puede inferir esta información por la lógica de funcionamiento de la aplicación. Por ejemplo, supongamos que nuestro atacante comienza su ataque de adivinación de nombres de usuario y se encuentra con un sistema como el de la gráfica de la derecha. El mensaje de error del sistema es explícitamente ambiguo con la intención de imposibilitar el ataque.



Sin embargo, si el atacante ingresa un nombre de usuario válido, y cualquier contraseña (muy probablemente incorrecta), el mensaje de error que arroja el sistema es el que se ve en la gráfica de la izquierda. Ahora, por más truco Jedi que intente el sistema, nuestro atacante casi nunca es tan tonto. A pesar de que el error anterior asegure que el nombre de usuario o la contraseña pueda ser el incorrecto, nuestro atacante sabrá que el anterior error sólo se produce cuando se introduce un nombre de usuario incorrecto.

El tema es tan poco entendido entre los desarrolladores, que aún cuando evitan los casos anteriores con mucho trabajo, fallan al dejar distintos códigos de error dentro del código fuente de la página que no son renderizados por el navegador, por ejemplo. A pesar de que estas diferencias no son evidentes para el ojo no entrenado, el atacante avanzado, analizará sin descanso las respuesta de nuestros servidores en busca de estas diferencias casi imperceptibles. Una vez que nuestro atacante encuentre una diferencia confiable - podría ser incluso un distinto tiempo de respuesta del servidor web - entonces empleará todo su arsenal para llevar a cabo sus objetivos.

Por esta y muchas otras razones es tan importante llevar a cabo pruebas de penetración avanzadas que detecten este tipo de errores "no evidentes" antes que nuestros atacantes los encuentren y exploten con éxito.

Fuente: http://latinsec.blogspot.com/2011/01/inseguridad-bancaria-online-parte-ii.html