Banca Electrnica Nuevos Vectores de Ataque

(versin pblica)

Hugo Vzquez Carams

01 de junio de 2006

NDICE

RESUMEN EJECUTIVO....................................................................Pag. 3 RESUMEN TCNICO........................................................................Pag. 4

1. OBJETIVO DEL DOCUMENTO ..........................................................Pg. 5 2. ESCENARIO COMN. PRECEDENTES ...............................................Pg. 6 a. Primer nivel de validacin .........................................................Pg. 6 b. Segundo nivel de validacin (firma) ...........................................Pg. 7 3. VECTOR DE ATAQUE PRINCIPAL ....................................................Pg. 8 a. Lgica del mecanismo de proteccin (2 validacin o firma) ..........Pg. 8 b. El taln de Aquiles de los sistemas de firma ...............................Pg. 8 c. Inyecciones de Cdigo Internas...............................................Pg. 9 4. NUEVO VECTOR DE ATAQUE.........................................................Pg. 10 5. DESCRIPCIN DE UN ATAQUE EN UN CASO REAL .......................Pg. 12 6. VARIACIONES..............................................................................Pg. 17 a. Captura de coordenadas del teclado virtual ............................... Pg. 17 b. Decodificacin directa de las coordenadas del teclado .............. Pg. 19 c. Troyanizacin del teclado virtual .............................................. Pg. 19

7. RECOMENDACIONES FINALES......................................................Pg. 22 8. CONCLUSIONES ...........................................................................Pg. 22

RESUMEN EJECUTIVO El acceso en Internet a las aplicaciones web de uso restringido, se protege normalmente mediante una combinacin de usuario y contrasea que se debe facilitar antes de entrar en la zona privada. La banca on-line emplea adems como sistema de seguridad adicional, y para las operaciones de riesgo, un mecanismo de proteccin conocido habitualmente como firma. Cuando un usuario desea realizar una transferencia entre cuentas por ejemplo, se le solicita que se identifique (que firme). Esta identificacin se lleva a cabo de distintas maneras en funcin del banco: unas entidades utilizan teclados virtuales, otras una tarjeta de coordenadas, otros dispositivos fsicos que generan claves de un solo uso, etc... Lo que tienen en comn todos estos sistemas de firma, es que estn destinados a identificar al usuario que realiza la operacin, para esa operacin en particular. Dicha identificacin se realiza gracias a una informacin que el usuario enva al servidor. La confianza de este mecanismo de seguridad, radica principalmente en que la informacin que el usuario enva solo autoriza dicha operacin, de manera que para cada gestin bancaria hay que volver a introducir la firma correspondiente. Este mecanismo es muy propio del sector de la banca y se viene utilizando para evitar cierto tipo de ataque muy conocido en el mundo de la seguridad informtica. El informe que a continuacin se expone presenta un perfil de los resultados obtenidos en el estudio de los mecanismos de seguridad utilizados habitualmente por el sector de la banca electrnica, en concreto el sistema de firma para operaciones de riesgo. Dicho perfil demuestra que independientemente de la solucin empleada (teclados virtuales, tarjetas de coordenadas, etc) existen distintas posibilidades de afectar la seguridad de dichos sistemas. Las metodologas que se describen en el siguiente informe no son nuevas ni presentan ninguna tcnica desconocida o novedosa en cuanto a la base tcnica en la que se sustentan. El presente informe sin embargo, s que muestra un nuevo enfoque en el uso de las tcnicas tradicionales de intrusin para conseguir romper la seguridad de los sistemas de firma que utiliza la banca electrnica. Las conclusiones que se desprenden del estudio es que actualmente, la gran mayora de mtodos de firma que utiliza la banca electrnica son susceptibles de verse comprometidos por toda una serie de vectores de ataque.

RESUMEN TCNICO La proteccin de las aplicaciones web viene siendo desde hace varios aos uno de los mayores retos de los programadores. La dificultad de la proteccin de dichas aplicaciones radica en gran parte en que el protocolo de base que se utiliza para las comunicaciones entre el cliente y el servidor (http/https) no es seguro. Uno de los mayores problemas del protocolo http, es la inexistencia de un mecanismo de seguimiento de sesin que sea formalmente seguro. Desde hace muchos aos vienen realizndose distintas propuestas relativas a dichos mecanismos, por ejemplo la RFC 2109 de Febrero de 1997, la RFC 2964 y 2965 de Octubre de 2000, etc, o las posteriores propuestas de algunos fabricantes en concreto. La problemtica de la inseguridad del seguimiento de sesin en comunicaciones http ha intentado solventarse en el entorno bancario mediante el uso de un mecanismo de validacin (la firma) que adolece de un contexto de sesin, y que por lo tanto en principio no es vulnerable a ataques de secuestro de sesin. La firma en el sector de la banca electrnica, es aquella identificacin que se le solicita al usuario cada vez que este quiere realizar una operacin delicada. Esta identificacin, independientemente del mtodo empleado (teclados virtuales, tarjetas de coordenadas, "tokens", claves de un solo uso, o combinaciones de varios de los anteriores) tiene por objeto validar al usuario solo para esa operacin en concreto. Generalmente esta validacin se pide en el ltimo paso de confirmacin de una operacin de riesgo (por ejemplo una transferencia econmica), y nicamente valida los datos enviados en el paso del formulario antes mencionado. El siguiente informe pretende mostrar como este esquema de validacin, que se emplea para evitar la suplantacin de identidad es vulnerable a los mismos ataques que se vienen empleando para secuestrar sesiones http, utilizando las mismas tcnicas, nicamente en un contexto y unas circunstancias distintas a las habituales. Siendo estrictos, este informe no presenta ninguna tcnica nueva ni innovadora, sin embargo, s demuestra que la aplicacin de las tcnicas de ataque clsicas, en ciertos escenarios, y haciendo uso de un poco de imaginacin pueden poner en riesgo gran parte de los sistemas de firma actualmente en uso por el sector de la banca electrnica. En el siguiente texto se hace referencia a conceptos como Inyeccin de Cdigo, Cross Site Scripting, Envenenamiento de Cach, Sesin http, Identificador de Sesin, Cookie, Secuencia o Estado de una sesin, etc. La explicacin detallada de cada una de estos conceptos particulares no es el objetivo de este documento, por lo que se recomienda estar familiarizado con dicha terminologa.

OBJETO DEL DOCUMENTO El presente documento tiene por objeto mostrar nuevas estrategias o vectores de ataque a los sistemas de autentificacin de banca electrnica. Este documento est basado en la investigacin concreta de una entidad bancaria, y sus conclusiones afectan a un mbito lo suficientemente amplio como para poder aplicarse a cualquier entorno web, aunque son de especial inters sus repercusiones en el entorno de la banca. Este documento NO tiene por objeto convertirse en una gua de explotacin prctica, ni ser una referencia para llevar a cabo acciones ilegales sobre sistemas telemticos. Toda la informacin que se muestra a continuacin, se ha obtenido lcitamente mediante la observacin del comportamiento lgico de una aplicacin. Sus conclusiones son el fruto de un minucioso estudio sobre un sistema de banca online. Las tcnicas que se explican pueden no ser aplicables directamente en muchos casos.

ESCENARIO COMN. PRECEDENTES

Primer nivel de validacin Los sistemas de banca on-line, habitualmente utilizan dos niveles de autentificacin. El primer nivel es el que se emplea para dar acceso al usuario a su entorno de banca electrnica, es decir, es el primer usuario y contrasea que pide el aplicativo. Con esta validacin, el usuario puede realizar tareas de supervisin, puede ver datos, pero no modificarlos (generalmente). Esto supone, poder comprobar el estado de las cuentas, su saldo, etc. Este primer nivel, puede usar distintos tipos de autentificacin: usuario y contrasea estticos, tarjeta de coordenadas, "token" fsico, etc. Sea cual sea el mtodo de validacin, una vez autenticado, el usuario (su navegador) obtiene una serie de identificadores de sesin y/u otros parmetros que le sirven al servidor para llevar a cabo el seguimiento del cliente. Es decir, que el servidor, mantiene el estado de la sesin y puede diferenciar a varios clientes gracias a esta informacin que ambos extremos de la comunicacin intercambian entre si en la capa de aplicacin (http/https). Esta mecnica no tiene nada de novedoso, y es con sus pequeas variaciones e implementaciones, el esquema comnmente empleado para llevar a cabo el seguimiento de sesin en aplicaciones que usan el protocolo http. Por otra parte como es de dominio pblico, este mecanismo no es completamente seguro... En una comunicacin TCP/IP que utiliza un solo "socket", el estado de la sesin se implementa en el nivel 4 de la capa OSI (TCP), mediante el uso de nmeros de secuencia. En una comunicacin http, se utilizan varios "sockets", de manera que no es factible, utilizar el esquema clsico de TCP. Para solucionar este problema, el seguimiento de sesin se realiza a nivel de aplicacin, mediante el uso de cierta informacin (identificadores de sesin, cookies, etc) que le permite al servidor, diferenciar a los clientes entre si. Aunque existen mtodos de seguimiento de sesin ms seguros, cmo por ejemplo a travs del propio protocolo SSL, solo algunos fabricantes lo implementan, y no es comn verlo en produccin por motivos cuya explicacin no es el objetivo de este documento. Por qu no son seguros los sistemas de seguimiento de sesin http comnmente utilizados? Tal y como se ha comentado, el seguimiento de las sesiones http se lleva a cabo mediante un cierta informacin, que se transmite a travs del propio protocolo http, ya sea en la URL, en las cabeceras, etc. Dicha informacin es accesible a travs de client side scripting, es decir, lenguajes de programacin cuya finalidad principal es ejecutarse en el lado del cliente de la comunicacin http. Dichos lenguajes (javascript, HTML, DHTML, etc), han ido evolucionando con el objetivo de aadir funcionalidad a la navegacin web, y es este aumento en la funcionalidad lo que tambin ha incremento la inseguridad de este tipo de comunicaciones. Muchas veces dichos lenguajes han intentado eliminar parte de la carga de trabajo del servidor, a costa de mayor poder de ejecucin en el lado del cliente. En la actualidad, todos los datos que se puedan utilizar para llevar a cabo un seguimiento de sesin http, se enven como se enven, son susceptibles de ser capturados de manera directa o indirecta mediante client side scripting. Y esto es un problema.

Tradicionalmente, los intrusos han venido utilizando tcnicas como Cross Site Scripting o Inyeccin de Cdigo, para capturar las credenciales de una sesin vlida y as poder suplantar la identidad del usuario. Actualmente, no existe, al menos formalmente demostrado, ninguna aplicacin web, invulnerable a un secuestro de sesin o suplantacin de identidad. Contrariamente a la creencia popular, ni tan siquiera la comprobacin de la IP de origen de conexin es suficiente como para impedir ataques de secuestro de sesin. Libreras como XMLhttp, permiten construir peticiones http a bajo nivel, y hacer que la propia vctima sea quien realice dichas peticiones en lugar del atacante, es decir, a modo de proxy, invalidando as la proteccin por IP de la aplicacin web del servidor. Segundo nivel de validacin (firma) El sector de la banca, consciente de la existencia del problema de secuestro de sesiones, ha venido utilizando un segundo nivel de autentificacin, dentro de la propia sesin. Esta segunda autentificacin se pide en todas aquellas operaciones de riesgo, como por ejemplo, una transaccin econmica, una orden de compra/venta de acciones, un cambio de contrasea, etc. Es decir, todas aquellas operaciones que puedan suponer prdidas econmicas o daos inmediatos a la entidad, en caso de fallo. Esta segunda contrasea, se suele pedir en el ltimo paso del formulario de la operacin crtica, pongamos por ejemplo, una transferencia bancaria a una cuenta externa. Es en este ltimo paso (la confirmacin final de los datos), cuando se realiza esta segunda autentificacin (firma), y que a diferencia de la primera no sirve para generar ninguna sesin sino que nicamente es un mecanismo para confirmar la identidad del usuario que realiza esa operacin en concreto dentro de la sesin vlida. La finalidad de este mecanismo es evitar que un atacante pueda hacer uso de una sesin vlida en la aplicacin bancaria (por ejemplo, si alguien olvida cerrar la sesin con su banco en un ordenador de acceso pblico). La autentificacin en este segundo nivel, puede ser, al igual que en el primer nivel, mediante contrasea esttica, mediante teclado virtual, tarjeta de coordenadas, "token" fsico, o una combinacin de varios de los anteriores mtodos. En cualquier caso, la segunda autentificacin (firma) no sirve para obtener una sesin, y por lo tanto, en principio, no parece ser susceptible de un ataque de secuestro de sesin, en cuanto no existe un nuevo contexto de sesin. Este sistema de proteccin de las sesiones de banca electrnica, se ha considerado desde siempre seguro, al menos conceptualmente. Si analizamos la lgica de este esquema de proteccin, vemos que al parecer, en el peor de los casos, un intruso, podra secuestrar una sesin de un usuario de banca (mediante obtencin del estado de la sesin), pero nunca podra realizar una operacin de riesgo. Es decir, que el intruso podra visualizar los datos de las cuentas de la vctima, pero nunca podra realizar un movimiento econmico, pues como se ha descrito, la segunda autentificacin no es susceptible a secuestros de sesin. Teniendo en cuenta que adems, las comunicaciones de banca on-line van cifradas mediante "Secure Socket" Layer", no parece viable poder acceder a los datos de validacin del segundo nivel, al menos, sin estar en el mismo segmento fsico que la vctima (mediante un clsico ataque tipo SSL man-in-the-middle). No hablaremos de este caso concreto, ya extensamente documentado y conocido.

En definitiva, el punto fuerte de los sistemas de banca on-line, ha sido desde siempre, este segundo nivel de autentificacin tambin conocido como firma.

VECTOR DE ATAQUE PRICIPAL Lgica del mecanismo de proteccin (2 validacin o firma) Anteriormente hemos apuntado conceptualmente que es posible secuestrar una sesin http mediante tcnicas de "Cross Site Scripting" o "Inyeccin de Cdigo". Para proseguir, supondremos que un atacante ya ha superado el primer nivel de validacin de una entidad bancaria mediante el secuestro de una sesin, y por lo tanto tiene acceso a la misma sesin que su victima. Tal y como ya se ha descrito, para cada operacin de riesgo se requiere una validacin de 2 nivel o firma. Esta validacin no establece un contexto de nueva sesin susceptible de ser secuestrada. En definitiva, si un atacante consigue saltarse el primer nivel mediante un secuestro de sesin, aun necesita conocer los datos de autentificacin del 2 nivel, los cuales, para mayor complicacin, en muchos casos, ni tan siquiera son estticos, sino que pueden tener valores distintos en cada ocasin ("tokens", tarjetas de coordenadas, etc). Sin embargo una cosa si parece posible: si el atacante que ya tiene acceso a la sesin de su victima es capaz de interceptar los datos de dicha 2 validacin o firma, para una transaccin en concreto, y conoce el estado de la sesin de su victima, en principio, no parece existir impedimento tcnico para que el atacante pueda suplantar a la vctima en dicho paso de la transaccin. El "taln de Aquiles" del sistema de firma. El proceso de secuestro de sesin http para burlar el primer nivel es bastante simple, solo se necesita que aparezca el tpico fallo de programacin por el cual no se valida la entrada de datos en algn formulario, o una inyeccin de cdigo en cualquier pgina que pueda ser explotada externamente. Debido a que la aplicacin misma realiza el seguimiento de sesin en toda la zona que requiere 1 validacin, un problema de "Inyeccin de Cdigo" probablemente le permitira a un atacante obtener sin problema el estado de la sesin. Sin embargo para burlar el segundo nivel solo existen ciertos puntos interesantes para el ataque de "Inyeccin de Cdigo": las pginas que muestran el formulario para introducir la 2 validacin (firma). Qu se conseguira con la inyeccin de cdigo en una de dichas pginas? Pues, si dicha inyeccin de cdigo es controlable por un atacante, ste puede modificar por completo el comportamiento de la pgina que solicita la 2 validacin (firma). El problema que aparece en este punto es cmo controlar externamente dicha inyeccin. Pongamos un ejemplo: supongamos que el atacante puede conocer el estado de la sesin de la vctima y por tanto, puede realizar peticiones validas suplantando su identidad. El atacante adems, descubre que una de las pginas donde se pide 2 validacin (firma) es susceptible de inyeccin de cdigo. Consecuentemente, aqu se plantean dos casos: Primero: La inyeccin se puede realizar externamente. Definiremos como inyeccin externa a aquella que se puede realizar de alguna de las siguientes maneras:

Desde fuera de la aplicacin misma Desde otra sesin vlida (distinto usuario)

En este primer caso (inyeccin externa), el atacante ya tiene el elemento que le faltaba, por tanto puede modificar el comportamiento de dicha pgina, es decir inyectar un formulario falso, redireccionar la peticin http, etc. El atacante est en condiciones de obtener el "token" y puede usarlo para realizar una transaccin. Este caso no es muy comn pero de cualquier modo, podemos afirmar que hablamos del "tpico" problema de inyeccin de cdigo. Segundo: La inyeccin se puede realizar internamente, es decir se puede realizar la inyeccin, pero solo desde la misma sesin del usuario. Aunque parezca extrao, es un caso harto comn en aplicaciones web. Son aquellos problemas de inyeccin de cdigo, en los que solo el propio usuario puede llevar a cabo la inyeccin. Estos casos, usualmente se catalogan como no peligrosos, pues no parece que tenga sentido auto inyectarse cdigo en la propia sesin.... Pues bien, veamos un escenario en el que este tipo de inyecciones pueden ser muy tiles para un intruso. Inyecciones de cdigo internas Es precisamente en este contexto el que aparece un nuevo vector de ataque que hasta el momento no se haba contemplado, pues hasta ahora, nadie encontraba sentido al hecho de poder realizar una inyeccin de cdigo desde la propia sesin del usuario. Por qu? Porque las aplicaciones web con zonas restringidas a usuarios registrados normalmente solo disponen de un nivel de validacin seguido luego de un seguimiento de sesin convencional. As pues el esfuerzo de los intrusos hasta el presente solo se centraba en poder controlar su inyeccin de cdigo desde el exterior porque una vez conseguida la sesin del usuario ya tenan acceso a toda la aplicacin. Es precisamente en el contexto de banca on-line -donde existe un segundo nivel de validacin- en el que las inyecciones en la propia sesin cobran una importancia vital. Podrn comprobar los usuarios de banca on-line ms curiosos, que generalmente, es posible inyectar cdigo desde la propia sesin con relativa facilidad. Por qu? A caso porque las auditorias de seguridad se centran, principalmente, en comprobar las aplicaciones de banca, desde la zona pblica, ms que desde la zona privada. No obstante y en principio, no existe impedimento para que el intruso cree una cuenta bancaria en una entidad, solicite acceso online y posteriormente estudie el comportamiento de la web, desde la zona de usuarios registrados...

NUEVO VECTOR DE ATAQUE Como se ha acaba de apuntar, aparentemente no tiene sentido inyectar cdigo en la propia sesin, excepto en algunos casos. Supongamos el siguiente escenario: un intruso ha sido capaz de secuestrar una sesin de un usuario vlido. El intruso sabe de la existencia de un problema de inyeccin de cdigo en la zona privada, es decir, una vez validado -esto puede obtenerlo tras haber realizado un estudio previo desde otra cuenta o en el mismo momento del secuestro, desde la propia sesin de la vctima-. Si el intruso est en la misma sesin que la vctima y puede autoinyectarse cdigo Se ejecutar dicho cdigo en el navegador de la victima? Existen al menos dos casos: 1) La inyeccin es de tipo esttico o permanente: es decir, una vez inyectado el cdigo en una determinada parte de la aplicacin web, este cdigo queda almacenado en una base de datos. 2) La inyeccin es de tipo dinmico o no permanente: o sea, la inyeccin tiene un tiempo de vida limitado y no se almacena al menos permanentemente en ningn sitio (es importante este matiz). De acuerdo con lo comentado anteriormente, el caso ms interesante para un atacante es poder inyectar cdigo EXACTAMENTE en el paso del formulario donde se exige la 2 autentificacin (firma) para poder manipular el comportamiento de dicho formulario. No es comn encontrar inyecciones de tipo esttico o permanentes en ese paso del formulario pero de existir, el juego para el atacante prcticamente habra terminado. El caso de inyecciones de tipo dinmico o no permanente, son menos frecuentes an pero no por ello despreciables. Partiendo de que la pgina del formulario correspondiente a la segunda validacin es dinmica, pues normalmente se deben reflejar los datos del usuario, su nombre, apellidos, cuentas, o datos del propio perfil (preferencias, etc), existe un caso que es especialmente curioso y delicado al mismo tiempo: estamos hablando de aquellos sistemas o aplicaciones que mantienen una conciencia del paso del formulario, o del paso de la sesin en el que se encuentra el usuario, de manera que impiden que ste pueda enviar mediante distintas peticiones, informacin distinta para el mismo paso de la sesin. El efecto que observar el usuario comn es que en un determinado paso del formulario donde realizamos el POST- no es posible utilizar el navegador para retroceder y modificar los datos del formulario. Esto significa que el usuario no puede modificar estos datos mediante la repeticin del POST pues la aplicacin web devuelve la misma respuesta que ya se obtuvo anteriormente para ese mismo paso. Este comportamiento, que se ha bautizado como el efecto formulario tozudo, es muy peligroso por las siguientes razones: 1) Puede permitir ataques man-in-the-middle en sistemas OTP (One Time Password). 2) Puede permitir ataques man-in-the-middle en sistemas que usan "tokens" (RSA Secur-ID, etc). 3) En general, puede permitir ataques man-in-the-midle en sistemas de segunda validacin (firma) como los usados en banca electrnica. 4) Puede permitir burlar los sistemas de seguimiento de sesin http ms avanzados, basados en testigos o pseudo-nmeros de secuencia que se intercambian en la capa de aplicacin (http).

10

5) Es un nuevo vector de ataque y es, conceptualmente hablando, bastante simple de combinar con otros ataques ya conocidos.

11

DESCRIPCIN DE UN ATAQUE EN UN CASO REAL

12

13

14

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

Imaginemos que la aplicacin web de nuestra entidad bancaria permite, como es usual, la realizacin de operaciones de transferencia. Dichas transferencias podran realizarse a travs de un formulario parecido al que se muestra a continuacin:

(...) <b> TRASPASO</b> <script> [Link]="[Link] </script> <form name="paso1" " method="POST" action=""> <b> Cuenta Origen:</b> <SELECT name="cuentaorigen"> <option value="1234-1234-00-1234567890"> 1234-1234-00-1234567890 <option value="1234-1234-00-1234567891"> 1234-1234-00-1234567891 </SELECT> <b> Cuenta Destino:</b> <SELECT name="cuentadestino"> <option value="1234-1234-00-1234567890> 1234-1234-00-1234567890 <option value="1234-1234-00-1234567891"> 1234-1234-00-1234567891 </SELECT> <b> Cuenta Destino:</b> <input type="text" name="importe" value="" size="17" maxlength="14" > <b> Comentarios:</b> <input type="text" name="comentarios" value="" size="36" maxlength="50">

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 operacin. Un caso delicado en este ejemplo es que la aplicacin bancaria no filtre la entrada de datos del usuario en el campo "comentarios" y sta se vuelque directamente sobre una pgina generada dinmicamente. Por ejemplo la pgina en la que el usuario puede ver los detalles de transferencia. Este puede ser un caso muy simple pero muy grfico, de un posible escenario en el que un atacante podra inyectar cdigo* y aprovechar la situacin para llevar a cabo un secuestro de sesin. *El atacante puede realizar una transferencia desde otra cuenta de la misma entidad bancaria a la cuenta de la vctima, y aprovechar el campo "comentarios" para su inyeccin de cdigo maligno. En otras ocasiones podr usar un sistema de webmail de la propia entidad bancaria o tambin, cualquier otra aplicacin web en el

15

mismo contexto que sea susceptible de un problema de "Inyeccin de Cdigo" o "Cross Site Scripting". No es objeto de este informe discutir las dificultades que un atacante encontrara al intentar aprovechar una vulnerabilidad de este tipo, o las mltiples maneras que existen para llevar a cabo dicha accin. Este documento parte de la premisa de que dichos ataques de secuestro de sesin son perfectamente posibles y factibles en la realidad. Una vez que el intruso tiene la capacidad de acceder a la misma sesin que el usuario vctima, puede explotar una o distintas tcnicas ("auto-inyeccin", "inyeccin en la cach HTTP de la aplicacin", etc.) para conseguir modificar el comportamiento del formulario del 2 nivel de validacin (firma). Una vez este formulario ha sido modificado, el ataque se resume a: 1. Las credenciales de la vctima son capturadas por el intruso*. 2. El intruso tiene las credenciales de la firma para una operacin determinada y puede realizar por lo menos una transferencia. Decimos por lo menos, porque en un sistema OTP (contraseas de un solo uso) o en un sistema de "tokens" tipo RSA SecurID, solo servira para una transaccin. En algunos casos concretos el uso de contraseas estticas (aunque sea a travs de un teclado virtual) agrava an ms la situacin, 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 transaccin ilegal. *La captura de las credenciales se puede llevar a cabo de distintas maneras, aunque la ms sencilla parece ser que es el desvo del POST en el formulario o la creacin por parte del atacante de otro completamente falso.

16

VARIACIONES De lo expuesto hasta ahora se deduce que la inyeccin de cdigo en las pginas de 2 autentificacin o firma, son extremadamente delicadas y explotables en un entorno real, y pueden comprometer los actuales sistemas de validacin de la banca electrnica. Durante el estudio que propici este informe, se plantearon distintas alternativas que hicieran de este vector de ataque, un mtodo de aplicacin ms genrico. Algunos ejemplos son:

Captura de coordenadas del teclado virtual Para un intruso es posible capturar las coordenadas de los clics del ratn mediante la inyeccin de un script especialmente creado que contenga estas funciones: - [Link] - [Link] - [Link] El resultado es que el intruso puede ser capaz de capturar las coordenadas de los clics del ratn tal y como se muestra a continuacin:

Las coordenadas se reciben en el servidor en el formato X.Y, de manera que una peticin como sta: GET /352.109 Equivale a la posicin x=352 e Y=109. Se puede argumentar en contra que los teclados cambian de posicin al invocarse..., sin embargo en el caso de aquellos teclados en los que las teclas no cambian de tamao ni de posicin relativa entre si, sigue siendo posible este ataque. Veamos como.

17

Imaginemos un teclado como este:

Ahora supongamos que un usuario tiene una contrasea como esta: imposible. Si representamos grficamente las coordenadas correspondientes a estas teclas, tenemos un grfico parecido a ste (se han agrandado los puntos para mayor comodidad visual):

Podemos observar que no existen muchas combinaciones posibles para poder encajar las coordenadas. En general, y como burda aproximacin, estimamos que existen como mximo 37 posiciones posibles. Eso en el peor de los casos, es decir, que la contrasea sea de una sola letra. Como se puede deducir, en el caso de los teclados virtuales que siguen este esquema -en los que no vara el tamao ni la posicin relativa de las teclas- a mayor complejidad de la contrasea menos combinaciones existen para encajar las coordenadas en el teclado. En el ejemplo indicado, las coordenadas correspondientes a la contrasea imposible no tienen ms de 4 o 5 representaciones grficas que encajen en el teclado. En general, cuanto ms distanciadas estn las teclas entre si menos combinaciones existen. Por ejemplo, las coordenadas correspondientes a la contrasea 8mpq, parece que solo encajan de una manera. Por otro lado, cabe decir tambin, que si la contrasea contiene una palabra de diccionario, sta puede descubrirse an ms rpidamente, al permitir identificarla de entre el resto de soluciones (posibles representaciones grficas).

18

Descodificacin directa de las coordenadas del teclado En algunos casos, el paso de coordenadas a contrasea de los sistemas de teclados virtuales se realiza directamente en el lado del cliente. Teniendo en cuenta esto, es fcil pensar que en muchos casos sera posible utilizar el propio script de la aplicacin bancaria para obtener la contrasea descifrada. Es decir, ya que el formulario contiene cdigo que realiza la conversin de coordenadas a clave, antes de realizar el POST No sera ms cmodo para un intruso utilizar la inyeccin de cdigo maligno con el fin de obtener dicha clave ya decodificada y desde el propio script?

Troyanizacin del teclado virtual El siguiente vector de ataque, se basa en la modificacin del cdigo que se encarga de gestionar el sistema de teclado virtual, y consiste en alterar el origen de carga del cdigo que gestiona el teclado (obsrvese que esto tambin hace vulnerables a los sistemas que usan applets de java empotrados para generar teclados virtuales, etc). Imaginemos una pgina web con un formulario de 2 validacin (firma) que contenga el siguiente cdigo: (...) <script language='JavaScript' src='/teclado_virtual.js'></script> (...) Se puede observar que el script que gestiona el teclado virtual se carga desde la ubicacin relativa /teclado_virtual.js. En principio, se podra modificar este origen cmo? simplemente inyectando algo parecido a esto: <script> src='[Link] En un caso como ste, el xito del atacante depende del lugar donde pueda inyectar, porque no es lo mismo hacerlo antes o despus de la lnea de carga "original" del teclado. Se deja al lector una reflexin sobre esta problemtica...

En ciertas ocasiones es posible redirigir la carga de scripts simplemente mediante la inyeccin de un "tag html" de tipo base href, de manera que todas las referencias relativas indicadas realizan la carga desde una ubicacin alterada. El problema de este tipo de ataques consiste en que se modifican todas las referencias relativas que existan posteriormente a la inyeccin del "base href", lo cual en muchos casos rompe la funcionalidad de la pgina... En cualquier caso el lector podr advertir la existencia de multitud de posibilidades que ofrece la inyeccin en pginas de firma de la banca electrnica. Y ello es as porque a pesar de la aparente dependencia que existe entre las distintas tcnicas de ataque, ha de tenerse muy en cuenta que al final, el eslabn ms dbil es el formulario de firma. Si un atacante es capaz de inyectar cdigo en esa parte de la aplicacin, ya sea directamente o a travs de varios fallos de la aplicacin, el

19

resultado es que los actuales sistemas de acreditacin que estn por encima de ese nivel (OTP, "tokens, teclados virtuales, tarjetas coordenadas, etc), pierden su efectividad. De todo lo anterior se deduce que las implementaciones de algunos sistemas de teclado virtual no son todo lo seguras que parecen, y por tanto permiten multitud de ataques.

RECOMENDACIONES FINALES A la finalizacin de este informe, se hizo patente la necesidad de incluir en l un apartado con recomendaciones para solucionar los problemas que aqu se plantean. Si bien el objetivo de este documento no era otro que el de llevar al interesado en el tema a una reflexin sobre la seguridad de los sistemas de acreditacin de banca online, sin caer en el tpico de facilitar un "recetario" de soluciones, parece interesante dedicar un breve espacio a presentar algunas propuestas sobre posibles soluciones. Tal y como se desprende del presente informe, el principal problema de seguridad de las aplicaciones web es su propia "naturaleza", es decir, la falta de seguridad en el el propio protocolo de comunicaciones (HTTP). Si como parece que sucede en la actualidad, no hay ms remedio que hacer uso de aplicaciones basadas en web en las operaciones de banca electrnica, para evitar los ataques descritos en este documento, de algn modo podran emplearse las siguientes tcnicas: Usar pginas estticas en los formularios de firma electrnica (2 validacin). Esto significa que en dichas pginas no se debera generar dinmicamente ningn contenido. Ello y a pesar de que en principio los datos "dinmicos" no dependen directamente de la entrada de datos del usuario, nunca se sabe. Aparentemente, aplicar la recomendacin anterior parece inviable, pues en los formularios de 2 validacin (firma) se deben reflejar todos los datos de la transaccin que va a validar el usuario, y esa informacin es por definicin, dependiente del propio usuario... Sin embargo, el problema de las partes de "informacin" que se generan dinmicamente no son el obstculo en si mismo, sino el mtodo de representacin. De alguna manera en la mayora de casos estamos ofreciendo al usuario una interfaz de "generacin de cdigo". Si, tal y como suena, porque al fin y al cabo, por muy filtrados que estn los datos, tanto a la entrada del usuario como la salida cuando se renderiza la pgina, siempre existe la posibilidad de que los mecanismos de filtrado no sean efectivos al 100% y al final el atacante pueda inyectar su cdigo. Pero veamos Lo que interesa es mostrar una informacin determinada para su confirmacin? Importa la manera de presentar esa informacin? Porqu no presentarla como una imagen, por ejemplo? La idea sera que el formulario de firma (2 validacin) presentara todos los datos dinmicos en formato imagen (GIF, PNG, JPEG, etc.). Si no se genera cdigo, sino una imagen, lo peor que puede suceder -si el atacante consigue inyectar cdigo maligno- es que ste aparezca en la imagen... Esto sera realmente frustrante para el intruso O no? Alguien podra pensar que este mtodo puede servir como prctica general para evitar la inyeccin de cdigo... No se piensa as y por una razn muy sencilla: Por la carga de CPU que debera soportar el servidor, para webs de alto contenido dinmico... y ms an, por la dificultad de integracin con todas las aplicaciones.

20

En cualquier caso, para la situacin concreta de aquellos formularios que requieran de firma (2 validacin), esta solucin s que se presenta como una opcin a estudiar. Si se quiere seguir utilizando el tradicional sistema de renderizado de pginas dinmicas que basan su seguridad en el filtrado de entrada de datos de usuario, no existe nada ms original que lo que cualquier analista recomendara: utilizar una metodologa de programacin segura. Otra opcin son los cortafuegos de aplicacin, aunque esto no siempre es posible por distintas razones: Coste, implementacin y un mantenimiento que no est al alcance de todas las empresas. Existen otros detalles, que van ms all de la programacin segura. Son pequeos "trucos" o prcticas que pueden dificultar la labor intrusiva: -Evitar referencias relativas y usar referencias absolutas. Esto hace la web menos portable, pero mas segura ya que evita los ataques basados en inyeccin de tag "base href". -En los formularios, no realizar el POST a una URL que dependa de una variable. Si hace esto se expone a que una inyeccin de cdigo modifique el valor de esa variable y se produzca un ataque de desvo de POST. -Aunque parezca absurdo y cuando sea posible, definir las variables "delicadas" al principio y al final de la pgina. S, repetidas. Esto no evitara una inyeccin y modificacin de variable, pues el atacante aun puede redefinir las variables y "comentar" el resto de cdigo. Pero en muchsimas ocasiones le complicara la intrusin. -Teclados virtuales: Utilizar un sistema del que no puedan obtenerse patrones. El teclado debe cambiar de posicin y de tamao cada vez que se invoca, las teclas deben cambiar de posicin y de tamao con cada invocacin del mismo. Se debera poner a disposicin del usuario algn sistema "generador de caos", es decir un sistema por el cual el usuario pueda efectuar clics de ratn antes, durante o despus de introducir su contrasea en el teclado virtual, y por tanto que dificulten la localizacin de coordenadas "vlidas". Si utiliza teclado virtual con contraseas estticas, hay que tener especial cuidado de no enviar la contrasea en claro... Aunque utilice SSL. Es muy simple, hay una mxima en la explotacin de vulnerabilidades de inyeccin de cdigo en aplicaciones web: toda la informacin que es accesible para un script cargado desde la pgina atacada, lo es para el atacante. Consecuentemente, si la pgina objeto de estudio contiene un script que realiza una "traduccin" de coordenadas a clave, el atacante puede que ya no necesite descodificar las coordenadas, sino simplemente acceder al valor de la variable que contiene esa clave que se va a enviar. Cmo solucionar este problema? Una manera, sera utilizar un sistema sincronizado entre el servidor y el cliente, de manera tal que el cliente enviara al servidor las coordenadas ms un token que identifica al teclado generado, con el objeto de que el servidor pueda resolver las coordenadas para ese teclado en particular. El modo ms sencillo de llevar a cabo ese cometido, es generando el teclado en el servidor y con formato de imagen. De esta manera el cliente no tendra "responsabilidad" alguna en la generacin de dicho teclado, solo cargara una imagen del tipo: "[Link]", la cual contendra una serie de teclas dispersas aleatoriamente por toda su superficie. Entonces los clics del cliente seran capturados por el script cliente, y enviados al servidor de banca. Y lo que recibira el servidor de

21

banca es una serie de coordenadas que solo tienen sentido para el teclado especfico que ha generado, es decir, en nuestro ejemplo, el que se asocia al token: "5tyfghtysdr94r". Un atacante que consiguiera desviar el POST como en los ataques mostrados anteriormente, obtendra unas coordenadas y un token sin ningn sentido para l. Evidentemente, el "eslabn dbil" de este esquema es la imagen que contiene el teclado, pues permite junto a las coordenadas en caso de capturarsedescifrar la clave. Sin embargo no parece existir, un modo sencillo de forzar al usuario a "enviar" dicha imagen al atacante, y siempre pueden reducirse los posibles ataques a este esquema mediante tcnicas cuya explicacin no es el objeto de este informe. Como puede observarse, a pesar de seguir siendo una serie de soluciones "imperfectas" son posibilidades originales, sencillas y elegantes que dotan a los sistemas de banca online de medidas adicionales de proteccin que dificultan en gran medida los ataques incluso de los intrusos mas decididos. CONCLUSIONES

No se ha realizado un estudio en detalle para otro tipo de sistemas de autentificacin de banca on-line, debido a la falta de un estndar para el resto de sistemas de autentificacin de firma. La conclusin mas inmediata que se desprende del presente informe es que los sistemas de firma de banca online, ya sea basados en "tokens" fsicos, teclados virtuales, u otros, actualmente distan mucho de poder considerarse como soluciones robustas pues prcticamente todos adolecen del mismo fallo: que su seguridad se implementa -en gran medida- a travs de un protocolo, http, que jams se dise para ser seguro, sino solo funcional. Hasta que llegue el da en que los mecanismos de verificacin de la identidad del usuario de una aplicacin web sean robustos, la banca on-line estar expuesta a toda serie de riesgos. Se pueden eliminar completamente dichos riesgos? No es probable, pero si que se pueden reducir en gran medida mediante la realizacin de pruebas peridicas especializadas sobre los sistemas de seguridad empleados. Si nos fijamos en la evolucin de las metodologas de evaluacin de la seguridad en los sistemas de informacin, observamos una tendencia a analizar cada vez con menor detalle las distintas tecnologas de proteccin. Ello es as porque a veces se confa ciegamente, en ciertos mecanismos clsicos, sin tener en cuenta que tan importante es un estudio de las particularidades de cada escenario concreto, como el del diseo en general y su especfica implementacin, y esto sea cual sea su origen y los Argumentos de Autoridad que lo defiendan.

22