Comisión de Seguridad

Banca Electrónica Nuevos Vectores de Ataque. 3º Parte.

DESCRIPCIÓN DE UN ATAQUE EN UN CASO REAL

Veamos de manera esquemática cuales son todos los pasos que seguiría un intruso en un ataque al sistema de banca electrónica.

20-06-2006 - 







Veamos ahora un ejemplo de ataque sobre una entidad bancaria ficticia.

Imaginemos que la aplicación web de nuestra entidad bancaria permite, como es usual, la realización de operaciones de transferencia.

Dichas transferencias podrían realizarse a través de un formulario parecido al que se muestra a continuación:



Podemos observar que en este primer paso del formulario para las operaciones de traspaso, se especifican: “cuenta de origen”, “cuenta de destino”, “importe”, etc... y “COMENTARIOS”, donde el usuario tiene la posibilidad de exponer el concepto de dicha operación. Un caso “delicado” en este ejemplo es que la aplicación bancaria no filtre la entrada de datos del usuario en el campo "comentarios" y ésta se vuelque directamente sobre una página generada dinámicamente. Por ejemplo la página en la que el usuario puede ver los detalles de transferencia. Este puede ser un caso muy simple pero muy gráfico, de un posible escenario en el que un atacante podría inyectar código* y aprovechar la situación para llevar a cabo un secuestro de sesión.

*El atacante puede realizar una transferencia desde otra cuenta de la misma entidad bancaria a la cuenta de la víctima, y aprovechar el campo "comentarios" para su inyección de código maligno. En otras ocasiones podrá usar un sistema de webmail de la propia entidad bancaria o también, cualquier otra aplicación web en el mismo contexto que sea susceptible de un problema de "Inyección de Código" o "Cross Site Scripting".

No es objeto de este informe discutir las dificultades que un atacante encontraría al intentar aprovechar una vulnerabilidad de este tipo, o las múltiples maneras que existen para llevar a cabo dicha acción. Este documento parte de la premisa de que dichos ataques de secuestro de sesión son perfectamente posibles y factibles en la realidad.

Una vez que el intruso tiene la capacidad de acceder a la misma sesión que el usuario víctima, puede explotar una o distintas técnicas ("auto-inyección", "inyección en la caché HTTP de la aplicación", etc.) para conseguir modificar el comportamiento del formulario del 2º nivel de validación (firma). Una vez este formulario ha sido modificado, el ataque se resume a:

1. Las credenciales de la víctima son capturadas por el intruso*.

2. El intruso tiene las credenciales de la firma para una operación determinada y puede realizar por lo menos una transferencia. Decimos “por lo menos”, porque en un sistema OTP (contraseñas de un solo uso) o en un sistema de "tokens" tipo RSA SecurID, solo serviría para una transacción. En algunos casos concretos el uso de contraseñas estáticas (aunque sea a través de un teclado virtual) agrava aún más la situación, pues una vez que el intruso ha obtenido las credenciales de la firma, ya no necesita volver a obtenerlas pues le sirven para cualquier futura transacción ilegal.

*La captura de las credenciales se puede llevar a cabo de distintas maneras, aunque la más sencilla parece ser que es el desvío del POST en el formulario o la creación por parte del atacante de otro completamente falso.

Continua:

Informe 1ª parte del informe

Informe 2ª parte del informe

Informe 3ª parte del informe

Informe 4ª parte del informe

Informe 5ª parte del informe

Hugo Vázquez Caramés
(Director Técnico de PENTEST, Consultores de Seguridad Telemática)
http://www.pentest.es

Nota: ”La empresa española “PENTEST” tal vez sea una de las mejores del entorno europeo en la realización de Tests de Intrusión. Empresa que basa su éxito en la recluta para cada tipo de proyecto de los mejores “Pen-Testers" existentes en la problemática a auditar. Una vez seleccionados, forma un equipo de auditores o "Tiger Team" que pone al servicio del cliente. Normalmente los "Tiger Team" de “PENTEST” no solo son los mejores, sino también los más motivados pues trabajan a partir de la propia libertad de sus conocimientos y experiencia y de la que concede Pentest para el desarrollo de su función profesional.


Articulo completo