martes, noviembre 02, 2010

Porque los grupos bancarios no deberían compartir algoritmos + semillas y/o plataformas

Llevo mucho tiempo pensando en publicar este post, puesto que solo puedo hablar por experiencia propia y/o cercana de un par de grupos bancarios internacionales. El tema es que soy usuario de banca tanto tradicional como de internet, pero la de internet es la que más utilizo, por aquello de la profesión y que es más fácil y se pierde menos tiempo.

Vamos a plantear una situación hipotética, pero creo que real en la mayoría de los casos, puesto que ¿cuantos de vosotros sólo tiene una cuenta bancaria?.Así que tenemos:

  • Un grupo bancario que tiene en propiedad varios bancos con diferentes nombres, se dedican tanto a la banca tradicional como a la online, cada uno con su marca comercial por separado.
  • Un usuario que posee una cuenta en un banco determinado.
  • El usuario posee varias tarjetas de esa cuenta de ese banco

Ahora bien, por diferentes motivos el usuario decide que va a abrir otra cuenta en otro banco del mismo grupo del que ya tiene la cuenta y que además va a solicitar una tarjeta de crédito para fundirse su dinero bien a gusto.

La pregunta es: ¿es este usuario capaz de adivinar cual va a ser el número secreto o PIN de la nueva tarjeta de su nueva cuenta en el nuevo banco del mismo grupo antes de abrir la carta y/o de que le llegue la tarjeta físicamente? y o lo que es peor… ¿es capaz un malo malísimo de averiguarlo?

Pues aunque parezca mentira… si lo va a poder saber... ¿por que?… puesto que para ahorrar costes, este grupo bancario, seguro que comparte infraestructuras, algoritmos e incluso personal técnico.. y si un algoritmo es bueno para un banco del grupo, ¿porque no lo va a ser para otro banco del mismo grupo? Esto provocará que el PIN que se genera por defecto y que mande este banco, va a ser el mismo que otro de su mismo grupo, por lo que podemos jugar a ser adivinos de PIN.

Pongo un ejemplo, a mi hermana le duplicaron la tarjeta del banco y le hicieron un cargo por algo menos de 600€, ella se dio cuenta y anuló la tarjeta, puso la correspondiente denuncia y pidió al banco que le emitiesen una nueva tarjeta nueva con una numeración diferente, y lo que pasó es que ANTES de recibir la nueva tarjeta física, activarla y cambiarle el PIN…. ¡¡ya tenía un nuevo cargo en su cuenta hecha con esta nueva tarjeta!!!!.. evidentemente, mi hermana ha dejado de trabajar no solo con ese banco sino con todo el grupo de bancos.

Pongo otro ejemplo, tienes una tarjeta de la que no te acuerdas del PIN y le pides al banco que te envíe un nuevo PIN… y mágicamente te enviará el mismo número que te facilito la primera vez que te emitió la tarjeta… si tenéis alguna tarjeta que no utilicéis, probadlo y veréis que sorpresa os lleváis (no ocurre en todos los bancos)

Es por ello, el título del post…

Creo que un grupo bancario si que debería compartir plataformas y algoritmos, pero NO DEBERÍA COMPARTIR las SEMILLAS que generan los PIN y/o las claves de FIRMA, o cambiar el método para que se introduzcan variables en las semillas y cada vez que te envían el PIN este no sea el mismo una y otra vez.

Otro día hablaré de los numeritos de confirmación que te envían al móvil para que realices una transferencia…

Visto en AURIATIC: Han entrado en mi Cuenta. ¿Cómo? Han usado XSS o JFK o PMI o algo así...

Fusilo esta entrada del Blog de Auriatic… que allí se lee regular…

 

Se publican multitud de noticias (y las que no se publican) sobre: encontrada vulnerabilidad XSS que permite robar la cuenta de Tuenti, el sonado caso de "Samy is my hero" en MySpace, donde logró 1 millón de amigos en unas horas, o twitter sufre un masivo ataque denominado Rainbow, etc. etc. etc.

Pero uno trata de transmitir lo que es XSS (no es una marca de leche, ni nada parecido) y resulta complicado. Así que ni corto ni perezoso yo también me lanzo a la aventura de explicarlo y cómo protegernos (siempre, con mucho cuidado).

XSS significa Cross Site Scripting (con este palabro, en el país de los ciegos seréis los reyes) y en esencia consiste en ejecutar código "malicioso" en tu navegador cuando visitas una página "fiable" que se encuentre infectada con, normalmente, el objeto de obtener tus credenciales. Sí, en los navegadores se ejecuta código, no es todo HTML lo que reluce. El hecho de que las páginas sean dinámicas: se cargue sólo una parte mediante peticiones AJAX, salga una ventana de pop-up diciendo que tu edad y talla de calcetines son datos obligatorios para continuar o que se puedan arrastrar y pegar cosas en la Web es gracias a código (el famoso JavaScript, entre otros, que nada tiene que ver con el lenguaje de programación Java, cuidado con los curriculums). Y como es lógico, este código no es visible para el usuario :-)

Código JavaScript

Librería de Google Analytics minimizada.

Con JavaScript además de lo anterior, también se pueden obtener/manipular los datos necesarios para conseguir la sesión (cookies de sesión) de la persona que está visualizando la página Web en ese momento, de modo que si yo introdujera esos datos (cookies de sesión) en mi navegador, podría suplantar a la otra persona (parece magia cuando lo ves e impacta. Una charla de concienciación no vendría mal al respecto: colegios, AMPAs, empresas, etc.)

Bien, al lío, normalmente, perdón, en ocasiones, los sitios Web, cuando uno interactúa, por ejemplo: escribiendo en el estado de alguien, mandando un mensaje, etc. etc. validan los datos que se introducen de modo que se eviten posibles ataques de JavaScript. Por ejemplo, si fuéramos malpensados y con unos mínimos conocimientos sobre JavaScript, podría tratar de incluir cierto código JavaScript en ese mensaje que vamos a introducir (este es sólo una de las formas de realizar este ataque) para así robar la sesión del usuario que visualice dicho comentario y ya que estamos, infectar al resto de sus contactos.

Pues bien, cuando la Web es vulnerable, estamos perdidos, ¿qué medidas podemos tomar?

  1. Navegar por sitios reconocidos, diréis, pero si Facebook, Tuenti, etc. están infectados ¿qué hacemos? seguir leyendo.

  2. No fiarse de notificaciones en otros idiomas (por suerte, en nuestro caso, el inglés es el idioma más utilizado con lo que ya hay un punto para distinguir), aunque provengan de contactos conocidos y no abrirlas. ¿De cuándo nuestro amigo Manolo habla inglés? ¿Y si tengo un amigo extranjero? seguir leyendo

  3. Utilizar Firefox o navegadores Mozilla (SeaMonkey, etc.), donde podemos instalar la extensión NoScript, esta extensión bloquea la ejecución de JavaScript. Funciona a las mil maravillas, pero (en mi opinión) es para usuarios avanzados (no valdría para mi madre internauta). Dado que hay que configurarla y no es sencillo. Es similar a los firewalls personales, digamos se hace a modo de "aprendizaje", donde vas indicando qué URLs tienen permitido la ejecución de JavaScript y qué URLs no. ¿Y si utilizo otros navegadores?

  4. Si utilizas Google Chrome, puedes instalar la extensión NotScripts que trata de hacer algo similar a la extensión NoScript de Firefox.

  5. Internet Explorer 8 (pensábais que nunca llegaría) introdujo una nueva característica: filtro XSS que hace mucho más difícil explotar los ataques XSS de tipo 1 (no persistentes o reflejados), esto es, cuando se reutilizan datos de la petición en la respuesta del servidor. Por ejemplo, cuando realizamos una búsqueda (Google, Yahoo, etc.) de una cadena, esa misma cadena se suele mostrar en la página de resultados obtenidos y si esa cadena es maliciosa y no protegida, pues ya está el pastel montado. Este filtro revisa las peticiones/respuestas a través del navegador. Cuando determina que ha existe un posible ataque de XSS en la respuesta del servidor (recordad que vuelve a mostrar datos), lo neutraliza y modifica la visualización en el navegador de usuario notificándoselo. Posteriormente, Giorgio Maone, el desarrollador de NoScript demostró que esta funcionalidad presentaba problemas de seguridad. Esta característica puede ser deshabilitada por mediante la cabecera HTTP X-XSS-Proteccion: 0 (esto ya suena a chino, ¿verdad? Lo podéis obviar). Google deshabilita esta característica, lo que cede el control total para protegernos sobre estos ataques a, en este caso, Google.

  6. Safari (no soy usuario), pero existe una extensión para Safari 5 llamada Javascript Blacklist, que bloquea la ejecución de Javascript según los dominios seleccionados.

  7. Después de toda esta lista, sólo me queda decir: "que Dios te pille confesado" :-)

Espero que os sirva de utilidad y que tengáis cuidado por dónde naveguéis.