viernes, 28 de enero de 2011

Inseguridad Bancaria Online. Parte II.

En artículos anteriores hemos elaborado superficialmente sobre lo devastador que puede ser la vulnerabilidad de nombres de usuario predecibles. 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.

Ver también:
Inseguridad Bancaria Online. Parte I
Inseguridad Bancaria Online. Parte III

1 comentario:

  1. Ciertamente los desarrolladores (o las "empresas" desarroladoras de software) tienen _siempre_ este problema, se dedican a hacer dinero y no capacitan a sus desarrolladores y DBAs en materia de seguridad, en estos días traté de ingresar al Provincial (aplicación provinet) la cual obviamente no me dejó ingresar arrojando un "error" lo cómico es que quien se ponía en frente era una pantalla de Tívoli, especificando hasta la versión que estaban usando, nada más a un curioso pudiere ocurrirsele buscar esa versión de Tívoli y ver que tipos de vulnerabilidades o exploits existen para esa versión y hacerles pasar un mal rato a los del BBVA. Otra cosa cómica es que veo en muchos de los internet banking que usan un teclado virtual para tipear la clave, y al colocarse sobre él colocan *** para "proteger" la clave de los "Clic -> PrintScreen de ciertos trojanos, pero la posición de los números no cambian en cada clic (grave error) porque? porque un atacante ("dueño" del trojano) podría ver si hay números que se repiten, acortando con ello la cantidad de intentos en la clave (simple matemática) pero realmente lo más Funny de todo, es que cuando te posicionas y le das clic en [Aceptar] _NO_ oculta el teclado con ***, y ese printscreen en ese evento de clic, ya me dio lo que requiero para saber _TODO_ lo que necesito, lo más triste de todo es que esos Bancos gastan millones en tecnologías como Tívoli, y tiren toda esa "seguridad" (realmente Tívoli pinta muy bueno, pero propietario es seguridad por oscuridad, en la que particularmente yo no creo), para retomar el párrafo :) se gastan todo ese dinero en equipos de seguridad y las aplicaciones dejan mucho que desear, como leí en otro de tus post, la puerta bien cerrada, pero la ventana bien abierta.

    ResponderEliminar