28 de septiembre de 2010

¿Es la tarjeta de coordenadas o tarjeta matricial realmente segura?

Una de las nuevas tendencias de seguridad en lo referente a validación de transacciones en línea es el uso de lo que se denomina tarjeta matricial o tarjeta de coordenadas. Este sistema se basa en entregar al usuario una serie de números y/o letras ubicadas en una grilla o plano cartesiano que comúnmente tiene unas 50 a 80 casillas. A la hora de realizar la transacción el usuario deberá ubicar las coordenadas solicitadas por el sistema e introducir los valores solicitados por este para validar la transacción. 

Este sistema se ha creado para fortalecer las claves de los usuarios, pero está muy lejos de ser un sistema de “clave dinámica” como algunos le denominan, ya que si bien el usuario va a introducir claves relativamente diferentes según se le consulte por diferentes coordenadas, estas casillas contienen siempre la misma información.


Si a esto agregamos los problemas convencionales existentes del lado del usuario con los troyanos bancarios, HTTP sniffers y otros, además del hecho de que las interfaces se apoyan solamente en el SSL para cifrar los datos en la transmisión olvidando que cualquier intercepción en la capa de la aplicación no está aún cifrada por el SSL, entonces tenemos un sistema claramente vulnerable.

El punto no es que queramos desprestigiar este método de validación que funciona perfectamente si el usuario realiza menos de cuatro a cinco transacciones al mes. Sin embargo si el usuario realiza por ejemplo unas 15 a 20 transacciones al mes entonces teóricamente la matriz de posibilidades podría ser re-ensamblada por un atacante.

Para explicar lo anterior piensen en un álbum de cromos coleccionables, a medida que el usuario hace transacciones el atacante podría ir completando los cromos de dos en dos o tres en tres (el número de casillas solicitadas en cada transacción), pero a diferencia de los álbumes de cromos, el atacante no necesita completarlo y puede intentar una transacción cuando tenga un 60% de los datos ensamblados en la matriz.

El punto principal es que al haber realizado un estudio de tres entornos bancarios específicos hemos detectado que no existe protección alguna contra ataque de MIB (Man In the Browser) ya que si acaso raramente existe alguna defensa contra estos métodos de ataque cada vez más populares, esta defensa se encuentra en el procedimiento de acceso al sistema solamente.

No quiere decir lo anterior que el sistema de clave por coordenadas sea altamente y definitivamente  vulnerable, lo que significa es que se ha implementado sobre vulnerabilidades existentes no eliminadas eficientemente.

7 de septiembre de 2010

¿Qué es el OWASP WebGoat?

Volvemos a mencionar en este artículo la importancia del OWASP (Open Web Application Security Project) y en especial esta vez mencionaremos uno de sus más interesantes proyectos: WebGoat.

Uno de los principales inconvenientes que tienen los programadores web cuando se trata de aprender sobre cómo funcionan las técnicas de los hackers que explotan las vulnerabilidades de nuestros sitios, es que si bien hay una razonable cantidad de información disponible, no hay sin embargo un sitio en donde hacer las pruebas a menos que indudablemente nos dediquemos a hacer experimentos en vivo con otros sitios web, lo cuál está muy cerca del límite entre lo que puede ser legal o no. Lógicamente también podemos hacerlas con nuestro sitio, pero no siempre estamos lo suficientemente capacitados como para asegurar que en vez de aprender no vayamos a cometer un desastre mayúsculo.

Aquí es precisamente en donde entra este proyecto. El WebGoat, es una aplicación en J2EE deliberadamente insegura, sobre la cual hacer las pruebas necesarias para aprender las técnicas utilizadas por los hackers y entender su verdadero alcance.

Pero WebGoat no es simplemente una aplicación insegura a propósito. Este proyecto nos presenta paso a paso un tutorial de las mayores amenazas existentes en la web, y nos lleva de la mano a aplicar las técnicas y entender  las razones por las cuáles fueron exitosas, para luego ser capaces de prevenirlas en nuestros futuros desarrollos.

XSS, SQL Injection, Parameter manipulation, Hidden fields manipulation, Weak Session Cookies y muchas otras son las amenazas que aprenderemos a manejar y comprender para pasar a defender a nuestras aplicaciones de dichas vulnerabilidades de forma eficiente.

4 de septiembre de 2010

¿Qué es el pharming? Tipos de pharming y alcance.

09Si bien el término "pharming" tiene detractores que explican que básicamente se trata de una variante más del phishing, es importante acotar que en ese caso estaríamos hablando una de las variantes más peligrosas.

Básicamente, el pharming tiene la finalidad de llevar al usuario a una página falsa para robarle la información personal, pero a diferencia del phishing utiliza técnicas muy diferentes para lograrlo, y estas se basan principalmente en engañar ya no al usuario sino al equipo o PC, para que resuelva las direcciones URL correctas y bien formadas hacia números IP diferentes de los originales y consecuentemente lleve al usuario a destinos no deseados.

En el caso del pharming el usuario está algo más desprotegido debido a que la dirección o URL que está en el navegador es el correcto, aunque este en realidad esta dirección le lleve a un servidor diferente. Su nombre se debe principalmente a que al vulnerar un servidor DNS o un router todos los usuarios de ese servicio son víctimas probables, osea una granja de víctimas ("farm" en inglés significa granja ) y si cualquiera de ellas introduce el URL correcto este será resuelto hacia el servidor del atacante.



Esta técnica de ataque a su vez tiene tres variantes conocidas:

Pharming local:
El que se logra al introducir un troyano o virus en el equipo de la víctima, el cual se encarga de alterar los registros de nombres que se encuentran el el archivo "hosts" (sin extensión) que se ubica en diferentes direcciones dependiendo del sistema operativo de la víctima. Se denomina local porque el ataque se realiza en el equipo del usuario. Aquí es precisamente donde el proceso se parece más al phishing debido a que los usuarios se infectan uno a la vez y el término de "granja" pierde sentido.

Drive By Pharming:
Este se realiza atacando directamente a los firewalls o routers (enrutadores), y cambiando la dirección del servidor DNS a la de un servidor DNS bajo poder del hacker, que indudablemente resolverá las direcciones tal como éste lo desee. Esta técnica hasta hace poco era utilizada solo para propósito académico debido a la dificultad que existe para acceder a los routers empresariales, sin embargo ha cobrado auge en la actualidad debido a las plataformas wireless que en muchos casos utilizan enrutadores cuyos usuarios no han cambiado la clave administrativa que traen estos equipos por defecto.

DNS Poisoning (Envenenamiento de DNS):
Aunque esta técnica es bastante difícil de ejecutar, se basa en vulnerabilidades de los servidores DNS en lo que respecta al control de su caché de direcciones. Aunque es muy peligrosa actualmente son muy pocos los casos, debido a que los servicios de DNS de gran escala están en manos de proveedores de Internet que ya han corregido este tipo de fallas. Sin embargo sigue latente la posibilidad de que se descubra alguna nueva vulnerabilidad que permita este tipo de ataque nuevamente.

¿Cómo saber si ha sido victima de un ataque de pharming?

  • Para lo que respecta al alcance de la mayoría de los usuarios la técnica más usada es la de la infección del archivo host (pharming local). Simplemente busque el archivo host en su sistema y elimine cualquer línea con direcciones IP excepto aquella que define a "localhost" como 127.0.0.1
  • Si tiene acceso a su router verifique que el número IP del servidor DNS configurado en el router sea el que le ha designado su proveedor de Internet o el administrador del sistema.

Hasta la próxima...

3 de septiembre de 2010

¿Qué son los HTTPonly Cookies?

Como ya es sabido una de las mayores amenazas que rondan las aplicaciones web es el XSS o Cross Site Scripting, y algunas de sus múltiples variantes basan su operatividad en la modificación o lectura de los cookies generados por la aplicación en el navegador del usuario.

Si bien un buen sistema de desinfección de parámetros de entrada desde y hacia la aplicación es siempre la mejor solución ante este tipo de ataques, una técnica muy útil que existe desde hace tiempo en el navegador Internet Explorer 6 SP1 y adoptada por todas las nuevas versiones de otros navegadores (Firefox desde 3.01, Opera desde 9.5 )  consiste en declarar los cookies como HTTPonly, protegiéndolos de lectura y escritura por parte de scripts del lado del usuario. De esta forma solo el servidor y el navegador tendrán acceso a la información guardada en los mismos.

La solución es en realidad muy simple en algunos casos, por ejemplo en ASP.NET solo tendrá que agregar un parámetro a la línea de configuración "httpCookies" al archivo de configuración web.config:


<httpCookies httpOnlyCookies = "true"... />

En PHP el proceso es parecido, añada la siguiente línea al archivo php.ini:

session.cookie_httponly = True

En Java EE desde la versión 6, se soporta la propiedad o flag HttpOnly en la interfaz Cookie y esta puede modificarse a true o false con los métodos setHttpOnly y getHttpOnly.
En Tomcat 6 puede colocar la línea del archivo context.xml . Esto es válido para cualquier framework basada en Tomcat como por ejemplo JBoss.

useHttpOnly = True

Como cualquier programador web podrá apreciar el proceso es muy simple, sin embargo esto no es la panacea anti-XSS, recuerde que para estar seguro ante ataques de este tipo de amenaza y otras como el SQL injection, la única solución eficiente proviene de una desinfección a conciencia de los parámetros de entrada hacia a la aplicación.

2 de septiembre de 2010

Vishing, Smishing y ¿Que tan segura es la plataforma en línea de mi banco?

Dos técnicas interesantes están volviendo al ruedo y tomando fuerza en la actualidad: El Vishing y el Smishing. Aunque desde hace tiempo son conocidas, en estos momentos en que la plataforma de VoIP crece cada vez más, es cuando empezamos a escuchar acerca de casos con este tipo de ataques.

Vishing no es más que un termino acuñado a partir de VoIP y Phishing, es decir hacer Phishing a través de sistemas de "Voz sobre IP" (Voice over IP) tales como Skype, Messenger o cualquier otro que permita comunicación de voz desde su PC.

El Smishing es también un termino acuñado de la mezcla de SMS y Phishing, o lo que significa hacer Phishing por SMS o mensajería de texto (se incluyen los sistemas para chatear en línea también).

Es un  hecho que los usuarios saben en su gran mayoría que no deben entregar claves de acceso ni otro tipo de información por teléfono o por SMS, pero los amigos de lo ajeno ensamblan sistemas muy inteligentes a la hora de cometer sus fraudes.

Por ejemplo, ¿Que haría usted si mientras está conectado a su página del banco, recibe una supuesta llamada del mismo banco por Skype? ¿Creería en la autenticidad de la misma si un operador le dice que para confirmar su transacción es necesario enviar sus datos por este medio alterno también?

Posiblemente usted no, pero seguro conoce mucha gente de la que no tiene idea acerca de cómo reaccionaría ante este tipo de fraude.

La mecánica del mismo es simple: los atacantes normalmente se basan en la ignorancia de ciertos aspectos tecnológicos, y algunos usuarios podrían creer incluso que ellos originaron la llamada al entrar en la interfaz del banco. La llamada es generada en algunos casos, porque el usuario ha instalado una aplicación que sin que él lo sepa envía una señal a los atacantes cada vez que se abre la página de la aplicación del banco.

Es por esta razón primordial que cada vez más son necesarios métodos de validación mas eficientes y seguros. Si su banco es de los que simplemente valida sus transacciones con un simple código o número de tarjeta y/o clave de acceso cuasi permanente, la cual es usted responsable de cambiar cada tanto porque ni siquiera le advierte que lleva mucho tiempo usándola, entonces es hora de que piense en cambiar de banco o exigir mejoras radicales en la plataforma.

Pero: ¿Cómo reconocer una interfaz bancaria segura?
En realidad aunque esto sea trabajo de profesionales, hay puntos muy interesantes para que usted pueda verificar si una plataforma bancaria en Internet al menos cumple con uno que otro estándar. No hablaremos aquí del protocolo seguro (SSL, HTTPS) ni del candadito del certificado, ya que sería el colmo que no lo usaran. A continuación cuatro puntos muy importantes que usted puede verificar:


  1. No solo usted debe validar su acceso, la interfaz de la aplicación debe poder demostrar que no es falsa, mediante la presentación de elementos que solo usted conozca o que solamente puedan haber sido creados por dicha interfaz. Esto se logra por acceso en dos etapas, es decir en la primera usted solo entrega un dato (a veces su login o número de tarjeta) y en la siguiente fase de la interfaz reconociendo ese dato la aplicación debe mostrarle algo que solo usted conoce. De esta forma usted sabrá sin duda que no está en una página falsa ya que ha validado su autenticidad.

  2. A la hora de las transacciones debe existir, una clave de seguridad adicional variable (si es fija el atacante solo tendría que hacerle una consulta más). Un pin que se recibe por otro medio en tiempo real puede ser la solución (OTP - One time password). También puede recibir en la misma interfaz unas coordenadas que debera verificar en una tarjeta matricial o rejilla de números, para introducir como clave segura los caracteres que se encuentran en cada una de las coordenadas recibidas de la rejilla. Hay otros métodos, pero lo importante es que existan, no entraremos ahora en que tan seguros son.

  3. No debe permitir que usted pueda entrar a la interfaz desde dos computadoras simultáneamente, al menos una de las dos sesiones debe bloquearse al siguiente movimiento. Esto le protegerá de técnicas como CSRF (Cross Site Request Forgery) y otras mediante las cuales el atacante puede apropiarse de su sesión una vez que usted ha accedido a la página correcta.

  4. Verifique que una vez dentro de la aplicación el URL completo siga siendo exactamente el mismo a pesar de que usted haya hecho varios clics y operaciones. De esta forma se asegura que la aplicación no está dando al atacante datos de cómo puede intentar acceder a las rutinas sin pasar por el proceso de acceso.


Estas son pruebas sencillas y usted mismo puede verificar estos puntos. Si usted duda del resultado simplemente no han sido contempladas por los desarrolladores o no lo han hecho con éxito.

Existen lógicamente muchas otras pruebas complicadas ante ataques de todo tipo, pero si su banco pensó en las anteriores ya tiene una buena parte de la calificación necesaria.

Hasta la próxima.

Entradas populares