¿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.

¿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...

¿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.

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.

Fraude en línea especializado: Man in the Browser Attack

Zeus, Silon, Torpig y Yaludle son solo algunos de los troyanos letales de los más salvajes que están enfocados en procesos de fraude en línea. Este tipo de troyano, espera a que sus clientes o empleados certifiquen los datos de sus cuentas (log-in) en el sitio de la aplicación de banca en línea del banco para el que fueron creados, e interceptan la comunicación entre el navegador y el usuario o entre el navegador y el sistema operativo, aprovechándose de debilidades del software o de la comunicación entre aplicaciones del sistema. De esta forma la información es enviada a repositorios específicos (desde cuentas de gmail hasta servidores IRC (internet relay chat) en donde los datos son almacenados a la espera de que el atacante los analice y extraiga la información de acceso para cometer el fraude. Este tipo de ataques también son conocidos como "Zero day attacks".

Normalmente la victima debe ser muy lista e inteligente para poder darse cuenta de algún síntoma de este tipo de ataque ya que inclusive a través de SSL todo trancurre con extremada normalidad en su equipo.

Este tipo de troyano se manifiesta o se adquiere de muchas maneras, pero básicamente las mas comunes son:

• Objetos BHO (Browser Helper Objects) conocidos como complementos del navegador en el caso de Internet Explorer.
• Extensiones de Firefox (el mismo caso pero diferente navegador)
• Api-Hooking: Programas insertados en el equipo que interceptan la comunicación entre el navegador y sus librerías DLL.
• Librerías Javascript: Usando gusanos AJAX ( AJAX worms) se puede ver un ejemplo como prueba del concepto en http://myappsecurity.blogspot.com/2007/01/ajax-sniffer-prrof-of-concept.html.

Menos de un 20% de las victimas logran detectar este tipo de estafa a tiempo, y ello se debe a la total normalidad aparente del sistema en el momento del fraude.

Este tipo de ataque fué detectado por primera vez en Julio del 2007, cuando fué utilizado para robar información al  United States Department of Transportation. Sin embargo a partir de mediados del 2009 ha sido detectado de forma creciente. La red de equipos infectados con Zeus, por ejemplo se estima en más de 3.5 millones de computadores solamente en USA. En Julio 14 de este año (2010) la empresa de seguridad Trusteer hizo público un reporte según el cual un gran número de tarjetas de crédito de 15 bancos no mencionados habían sido comprometidas. La más reciente variante de este troyano es conocida como Kneber.

En la actualidad este tipo de ataques tienen mucho éxito y en latino-américa se han detectado varios casos en México, Perú y Argentina esperando su pronta propagación hacia otros países de la zona.