29 de diciembre de 2010

OWASP Cheat Sheets Series - Hojas de Trucos de OWASP

A veces es necesario tener a mano soluciones rápidas y eficientes para evitar tener que releer todo un libro buscando aquel truco que sabemos que hemos leído pero que no recordamos a perfección como era  o dónde fué exactamente que lo leímos. Por otro lado si bien "googlear" es a veces la solución más rápida, tratándose de prevención y seguridad pudieran existir diferentes "soluciones" o puntos de vista, y tratando se escoger las apropiadas podríamos perder un tiempo preciado.

Cuando se trata de seguridad de aplicaciones, tener a mano una lista de trucos eficientes que nos ayuden a prevenir ataques a la hora de generar código o plantear soluciones integradas de protección puede ser una ayuda invaluable.

Pensando precisamente en lo anterior, la gente de OWASP ha creado las listas u hojas de trucos o "cheat sheets", para tener a mano de forma rápida la información de seguridad necesaria para aplicar las técnicas correctas cuando estemos ensamblando y programando las rutinas esenciales de nuestras aplicación.

Estas hojas de trucos  o "cheat sheets" son varias, y a continuación les muestro los enlaces de las más conocidas y útile a mi parecer:

Sin duda como podrán apreciar al leerlas son documentos eficiente que van directo al grano en lo referente a explicar los procesos de los tipos de ataque pero sobretodo en lo que se refiere a las técnicas de prevención necesarias a la hora de ensamblar y crear código. Espero que les sean de utilidad.

Hasta la próxima...

OWASP - Checklist de Prácticas de Código Seguro

Un documento muy importante creado por OWASP es el que se refiere a cómo ser programadores "seguros", aclarando específicamente una por una las prácticas que debemos seguir cuando generamos código para aplicaciones web. Este documento es precisamente la Guía de Desarrolo Seguro de OWASP.

Espero que tengan tiempo para leer esos documentos tan importantes que tocan a fondo temas actualizados referentes a seguridad web, pero quizás pensando precisamente en que no todos los programadores tenemos el tiempo necesario para ello OWASP ha redactado un checklist de prácticas de código seguro que puede descargar en este enlace.

Sin embargo si es de aquellas personas que cree que mediante ayuda visual puede mejorar su captación entonces el siguiente video grabado en OWASP AppSec USA 2010 le será de gran ayuda para comprender los temas y la terminología de seguridad web involucrada.




Hasta la próxima!

18 de diciembre de 2010

Tipos de ataques de DoS basados en fallas de la aplicación.

Cuando hablamos de DoS y DDoS podemos referirnos a muchos tipos diferentes de ataque que en definitiva lo que buscan es obligar al servidor a dejar de ofrecer el servicio. Sin embargo desde el punto de vista de la seguridad de aplicaciones web hay ciertos tipos de DoS (los más comunes) en los que no entraremos en explicaciones ya que no atacan directamente a la aplicación sino a los diferentes servicios necesarios para que esta pueda seguir en línea. Este tipo de ataques se denominan "Network based DoS Attacks" o Ataques de Dos basados en Redes y tratan primordialmente de explotar vulnerabilidades o limitaciones de los protocolos de red de las diferentes capas del protocolo TCP/IP.

Hablaremos hoy de un tipo de ataque de DoS que como programadores nos conciernen directamente y que se apoyan en fallas o vulnerabilidades de la aplicación. Aunque menos populares dichos ataques, son mucho más eficientes, ya que basados en vulnerabilidades en código de aplicación o de base de datos, suelen en muchos menos intentos consumir los recursos del servidor de forma muy eficaz.

Podemos dividirlos según OWASP en los siguientes:
NOTA: todos los enlaces llevan a la página correspondiente de OWASP en la que se trata acerca de cómo verificar y corregir el tipo de fallo que pudiera ocasionar estos tipos de ataque.

  1. SQL Wildcard Attacks.
    Son aquellos que se basan en desarrollar consultas que consumen gran cantidad de recursos del servidor SQL y aunque atacan a varios tipos de servidor SQL suelen preferir el MS-SQL por la cantidad de "wilcards" disponibles en las sentencias LIKE.
  2. DoS Locking Customer Accounts.
    Uno de los sistemas de defensa de las aplicaciones con validación de usuarios es la utilización de bloqueo de estos luego de una cantidad de intentos fallidos. Este mecanismo de defensa se convierte en un arma de negación de servicio bajo este tipo de ataque.
  3. DoS Buffer Overflows.
    La intención es hacer que una vulnerabilidad de Buffer Overflow en el control de la capacidad de los datos recibidos, se convierta en un arma que no permita que las rutinas completen y por ende liberen los recursos solicitados.
  4. DoS User Specified Object Allocation.
    Suele suceder cuando un usuario tiene la capacidad de solicitar multiples copias de un objeto a ser creado en el entorno del servidor sin un límite superior, lo que podría generar que dicho entorno quedara sin memoria disponible.
  5. User Input as a Loop Counter.
    Se produce al forzar a la aplicación a entrar de forma repetitiva en un bucle de código que consume gran cantidad de recursos.
  6. Writing User Provided Data to Disk.
    El objeto de este tipo de ataque es obligar al servidor a quedar sin suficiente espacio en disco, bien escribiendo datos provistos por el usuario, o llenado los archivos de logs de forma que crezcan lo suficiente como para acaparar el espacio en disco.
  7. DoS Failure to Release Resources.Este ataque se debe a la falla del programador o del entorno de desarrollo en liberar eficientemente los recursos utilizados por la aplicación. Suele suceder con mucha frecuencia especialmente al no liberar conexiones y sets de registros de bases de datos que consumen recursos por encima del promedio de otro tipo de objetos.
  8. Storing too Much Data in Session.
    Sucede cuando como el nombre lo indica, se guardan demasiados datos en la sesión del usuario, específicamente si el usuario no es un usuario autentificado, por lo cual el atacante no necesita de mucho esfuerzo para dejar a la aplicación sin recursos en el pool de memoria.

Hasta la próxima...

14 de diciembre de 2010

Los diez(10) tipos de vulnerabilidades de bases de datos más comunes

Aunque el tema no está relacionado directamente con las aplicaciones web, es importante para su sano funcionamiento, proteger de forma correcta los datos que estas utilizan y definitivamente proteger las bases de datos no es una tarea fácil, sobretodo porque a menudo los ataques que van tras las más simples vulnerabilidades son lo que tienen más éxito.

De acuerdo con Alex Rothacker, gerente AppSec's Team SHATTER (Security Heuristics of Application Testing Technology for Enterprise Research), su equipo ha encontrado 10 tipos comunes de vulnerabilidades base de datos por las que las organizaciones padecen ataques una y otra vez.

El hilo común de esta lista es que rara vez las bases de datos salen al mercado "security ready", y su configuración de seguridad no es un un trabajo de "hacer y olvidar" para los administradores de base de datos.

Las organizaciones deben evaluar continuamente los paquetes de su software de base de datos para determinar si son realmente necesarios y desactivar los que no son necesarios para reducir las superficies de ataque. Tienen que ser cuidadosos en controlar los campos en las búsquedas para prevenir inyecciones y tener conciencia de la debilidad en las credenciales de inicio de sesión. Y lo más importante, es necesario aplicar los parches de actualización de la casa matriz con regularidad.

Alrededor de la mitad de las vulnerabilidades nombradas por Rothacker y su equipo están directa o indirectamente relacionadas con las prácticas flojas de gestión de parches en el entorno de base de datos. Ese es un pensamiento aterrador considerando sólo el 38% de los administradores aplican los ajustes de seguridad en sus bases de datos Oracle en el ciclo de revisión inicial de tres meses. Y casi un tercio de ellos toman un año o más para aplicar el primer parche.

Dele una mirada a los 10 tipos de vulnerabilidades de bases de datos más comunes.

1.- Nombre de usuario/password en blanco, por defecto o débil.

No es nada raro conseguir en el día a día pares de usuario/password como sa/1234, esta el la primera línea de defensa y un punto fundamental de la armadura de nuestras bases de datos. Es importante hacer revisiones periódicas de credenciales.

2.- Inyecciones SQL.

Cuando la plataforma de base de datos falla para desinfectar las entradas, los atacantes son capaces de ejecutar las inyecciones SQL de forma similar a como lo hacen en los ataques basados en Web, lo que les permite elevar sus privilegios y obtener acceso a una amplia gama de funcionalidades. Muchos de los proveedores han dado a conocer soluciones para evitar estos problemas, pero no servirá de mucho si los parches no se aplican o no se toman los correctivos correspondientes.

3.- Preferencia de privilegios de usuario por privilegios de grupo.

Las organizaciones necesitan garantizar que los privilegios no se les den a los usuarios por asignación directa quien finalmente los recogerán como los conserjes recogen las llaves en sus llaveros. En cambio, Rothacker recomienda que los usuarios sólo reciban privilegios por parte de grupos o funciones y que  los privilegios sean manejados colectivamente. De esta forma será más fácil eliminar derechos a un usuario con simplemente eliminarlo del grupo, sin que queden derechos ocultos u olvidados asignados a dicho usuario.

4.- Características y funciones de base de datos innecesariamente habilitadas.

Cada instalación de base de datos viene con paquetes adicionales de todas las formas y tamaños que en su mayoría rara vez son utilizados por una sola organización. Dado que el nombre del juego en materia de seguridad de base de datos es el de reducir las superficies de ataque, las empresas necesitan buscar los paquetes que no utilizan y desactivarlos. Esto no sólo reduce los riesgos de ataques (0)day a través de estos vectores, sino que también simplifica la gestión de parches.

5.- Configuración de seguridad ineficiente.

Del mismo modo, las bases de datos tienen una gran cantidad opciones de configuración y consideraciones diferentes a disposición de los administradores para ajustar el rendimiento y funcionalidades mejoradas. Las organizaciones necesitan conseguir y desactivar aquellas configuraciones inseguras que podrían estar activadas por defecto para mayor comodidad de los DBA o desarrolladores de aplicaciones. Las configuraciones de bases de datos en producción y desarrollo deben ser radicalmente diferentes.

6.- Desbordamientos del búfer.

Otro favorito de los piratas cibernéticos, las vulnerabilidades de desbordamiento de búfer, son explotadas por las inundaciones de las fuentes de entrada con valores diferentes o muy superiores a los que aplicación espera - por ejemplo, mediante la adición de 100 caracteres en un cuadro de entrada pidiendo un número de Seguro Social -. Los proveedores de bases de datos han trabajado duro para solucionar los problemas técnicos que permiten estos ataques se produzcan. Esta es otra razón por la cual los parches son tan importantes.

7.- Escalada de privilegios.

Del mismo modo, las bases de datos con frecuencia exponen vulnerabilidades comunes que permiten a un atacante escalar privilegios en una cuenta con privilegios bajos hasta tener acceso a los derechos de un administrador. A medida que estas vulnerabilidades son descubiertas, los proveedores las corrigen y los administradores deben mantener las actualizaciones y parches actualizados.

8.- Ataque de denegación de servicio.

El caso del SQL Slammer es siempre un ejemplo muy esclarecedor de cómo los atacantes pueden utilizar las vulnerabilidades de los DBMS para derribar los servidores de base de datos a través de un alto flujo de tráfico. Aún más ilustrativo es el hecho de que cuando el Slammer atacó en 2003, un parche ya estaba por ahí que se dirigió a corregir la vulnerabilidad por la que se generó su ataque. Hoy en día siete años más tarde, SQL Slammer todavía está dando dolores de cabeza en los servidores no actualizados.

9.- Bases de datos sin actualizar.

Esto podría sonar repetitivo, pero vale la pena repetirlo. Los administradores de base de datos a veces no aplican un parche en el momento oportuno porque tienen miedo de este dañe sus bases de datos. Pero el riesgo de ser hackeado hoy es mucho más alto que el riesgo de aplicar un parche que descomponga la base de datos. Además existen ante esos temores los backups y las réplicas. Quizás este punto pudo haber sido válido hace cinco años, pero los proveedores ahora tienen mucho más cuidado con sus arreglos.

10.- Datos sensibles sin cifrar, tanto en reposo como en movimiento.

Tal vez sea una obviedad, pero las organizaciones no deben almacenar los datos sensibles en texto plano en una tabla. Y todas las conexiones a la base de datos siempre que manejen datos sensibles deben utilizar el cifrado.

Cualquier comentario al respecto será bienvenido...
Hasta la próxima.

4 de diciembre de 2010

¿Que es un Pen-Test? Herramientas de Pen-testing

Si usted está de alguna manera involucrado con cualquiera de las áreas de las tecnologías de información y no sabe lo que significa "Pen-test" o "Pen Test", y cree que el término trata quizás acerca de las formas de probar un bolígrafo, debiera entonces pensar en leeer este artículo detenidamente.

Pen Test es como comunmente se denomina a los "Test de penetracion" o en inglés "Penetration Tests", y son en conjunto la forma de denominar a una serie de técnicas utilizadas para evaluar la seguridad de redes, sistemas de computación y aplicaciones involucradas en los mismos.

Un Pen Test, no es tarea fácil y requiere de un conocimiento sólido y profundo de las tecnologías involucradas en los sistemas, aplicaciones y servicios, además de una óptica y experiencia amplia en el comportamiento de varios sistemas operativos. Mediante estas técnicas, el Black, White o Ethical Hacker puede descubrir vulnerabilidades en el sistema estudiado, y usarlas para obtener acceso al mismo, por lo que está técnica se diferencia entre otras cosas del "análisis de vulnerabilidades" en  que en este último una vez detectadas las vulnerabilidades no son usadas para penetrar el sistema.

Ahora bien, déjeme aclararle un punto importante: Sus sistemas o aplicaciones, por muy bien o mal protegidos que usted crea que se encuentren, pueden ser objeto de un Pen Test con o sin su consentimiento en cualquier momento, por lo que es importante entender que descubrir las fallas de los mismos mediante el uso de las herramientas para ello, puede ser una gran ventaja a la hora de la defenderse de futuros intentos de penetración.

Las herramientas disponibles para efectuar estas pruebas de penetración pasan por varios grados de complejidad, y el manejo de algunas de ellas puede ser todo un reto a la inteligencia y sagacidad del atacante o "pen-tester". Entre ellas se incluyen desde scanners de puertos, complejos algoritmos para descifrar claves, sistemas de intrusión por fuerza bruta, herramientas de sniffing de redes y penetración de firewalls, así como también herramientas de escaneo de vulnerabilidades de aplicaciones web y mucho más. Todo un mundo de aplicaciones en su mayoría desarrolladas para entorno Linux (el entorno preferido para este tipo de trabajo) con las cuales el proceso de intento de penetración se hace mucho más "simple". Estas herramientas suelen estar agrupadas en lo que se conoce como "Toolkits" o juegos de herramientas.

Algunos "toolkits" son muy famosos en el medio por la eficiencia de sus herramientas y por haber sido utilizados en penetraciones de alto nivel a sistemas que se consideraron es su tiempo fortalezas impenetrables. Algunos además se consiguen inclusive en formato de LIVE CD o ISO, de forma que las herramientas ya están integradas e instaladas en un CD de arranque del sistema operativo con el que trabajan y son portátiles.

Uno de los mejores pen-testing toolkits y más recomendados por todos los expertos es Backtrack , aunque en realidad puede llegar a ser muy complejo el uso de sus herramientas. Personalmente no creo haber llegado jamás a usarlas todas.

Claro está si usted no es un experto este tipo de herramientas pudieran ser muy complejas en su uso, pudiera ser muy interesante que usted "penetrara" en el mundo de las herramientas de pen-testing a través de la mano de este libro: Penetration Testers Open Source Toolkit

Ahora bien, si usted solo quiere tener a mano ciertas herramientas que le permitan verificar la calidad de sus sistemas de foma no tan sofisticada y compleja, existe un toolkit rápido para Windows llamado Net Tools  que puede hacer muy bien buena parte de los trabajos simples. En este se unen algunas herramientas simples y básicas con otras más complejas como Nmap (excelente herramienta de análisis de redes) -  y Wireshark (el más famoso analizador de protocolos de red.) que creo deberá descargar aparte.

Hasta la próxima...

1 de diciembre de 2010

¿Qué es el Google Hacking Database (GHDB)?

Google es entre muchas otras cosas el buscador con la mayor cantidad de páginas indexadas en el mundo y la mayor cantidad de búsquedas diarias, y precisamente por eso es una fuente inagotable de recursos y de información sobre cualquier tópico relacionado con la web. Es de suponer que una fuente de información de este tipo también puede ser usada para fines no muy éticos.

No hablamos de obtener información específica con fines no necesariamente legales. Tampoco se trata de utilizar las búsquedas para recoger información específica para hacer minería de datos. Esta vez hablamos (aunque pudiéramos relacionar algunos casos con las anteriores) de utilizar el mejor buscador del mundo para buscar aplicaciones web vulnerables a ciertos tipos de ataque o utilizar la información obtenida para mejorar la eficiencia de ataques pre-configurados.

¿Cómo puede ser esto? ¿Es verdad que a través de Google se pueden descubrir vulnerabilidades específicas? Pues es cierto, con el conocimiento necesario se pueden manejar las consultas para que nos provean de una lista de sitios que tienen una vulnerabilidad en común.

Es fácil, todo el tiempo oímos acerca de nuevas versiones de software (manejadores de contenido, servidores web, aplicaciones web pre-elaboradas) en las que se corrigen determinado tipo de vulnerabilidad. A veces esta información es colocada en línea para informar a los usuarios y desarrolladores lo cual es lógico, sin embargo de forma inocente al mismo tiempo se le informa a los atacantes acerca de una vulnerabilidad no conocida de la versión anterior. Así de sencillo.

Un ejemplo: El software para manejo de contenido que llamaremos "X" acaba de ser mejorado para resolver una vulnerabilidad de inyección de SQL, por tanto el atacante lo único que necesita hacer es ubicar una característica visible en la versión anterior de "X" que lo diferencie de la versión que no posee la vulnerabilidad. Algunas veces se trata de buscar una inocente cadena de texto como: "Powered by X version x.xxxx". Otras veces se trata de buscar un cambio en el nombre de un archivo o un cambio en el hash resultante del mismo.

Este tipo de búsqueda se realiza de forma sistemática y eficiente, parametrizando la cadena de búsqueda de Google con los "operadores" que pone a nuestra disposición el buscador y combinándolos de forma inteligente se puede afinar la búsqueda en un grado impresionante.

Par ver un listado de operadores de Google, puede visitar: http://www.googleguide.com/advanced_operators_reference.html
En este sitio encontrará una lista muy interesante de los operadores de Google para diferentes aplicaciones (stocks, groups, phonebook...) junto con su uso específico. Luego de apreciar algunos de los operadores que le parecerán sin dudad muy potentes, es muy posible de que no se haya percatado que estos operadores pueden además combinarse para hacer las búsquedas mucho más eficientes.

Por ejemplo, una búsqueda como: site:elsitio.com filetype:pdf  puede arrojar como resultado todos los archivos de formato "pdf" del sitio que coloquemos junto al operador "site:". Esta es una muestra de dos operadores muy potentes trabajando juntos. Con un poco de imaginación usted podrá entender con este simple ejemplo las razones por las que Google es la herramienta preferida de los atacantes y entenderá también como la distancia y el idioma dejan de ser barreras, ya que solo es necesario que un sitio tenga una vulnerabilidad detectable para que pueda ser accedido por los atacantes. Ah se me olvidaba el idioma, pero se preocupe, para eso existe Google Translator (el que además puede ser utilizado como "proxy" para evitar ser detectados en los test de penetración). Ah... se me olvidaba, si lo que quiere es ubicar un proxy ¡solo tiene que hacer la consulta correcta!

Quizás la idea es hacerle entender con lo anterior que su aplicación no se encuentra ya protegida por el enorme cúmulo de sitios web y aplicaciones en la red, tampoco la distancia ni el idioma son un obstáculo para el atacante. Ya no basta protegerse bajo la estrategia de la aguja en el pajar. Los operadores de Google pueden separar las agujas de la paja de forma rápida y hasta podría decirse que tan eficientemente como un verdugo experimentado aniquila a su víctima. 

Para más información puede acceder a la página:http://www.hackersforcharity.org/ghdb/
Allí podrá obtener información acerca de todos los tipos de consultas relacionados con vulnerabilidades que pueden ser detectadas mediante el uso de GHDB. También puede recurrir al libro Google Hacking Database for Penetration Testers, su versión "Volume 2" está bastante actualizada. Por otro lado allí podrá aprender la forma de combinar dichos operadores dependiendo del caso a tratar.

Le aseguro que no podrá volver al libro muchas veces, ya que pasará una gran cantidad de tiempo haciendo pruebas con el buscador entre un capítulo y otro, o mejor dicho, entre un párrafo y otro ;)

También es importante hacer notar que Google permanentemente hace esfuerzos por reducir la superficie de ataque proporcionada mediante los métodos de búsqueda avanzada y sus operadores por lo que algunos de los ejemplos del libro y del GHDB Central no son ya operativos. Claro aquí es donde su creatividad puede ser la diferencia.

Nota Importante: La información mostrada en el artículo se expone con fines estrictamente educacionales para ser utilizada como ayuda en la mejora de la seguridad de las aplicaciones web. No nos hacemos responsables del uso indebido de esta información por parte del lector.

26 de noviembre de 2010

El entrenamiento en seguridad web y lo que puede hacer por su empresa.

Para los negocios en línea, la seguridad es una parte vital en lo referente a la eficiencia y retorno de inversión de los mismos. Las aplicaciones web son las herramientas principales para las transacciones en línea, promoción de productos y servicios además de ser también las principales en presentar inconvenientes de seguridad que pudieran perjudicar a usted y a sus clientes a través de su aplicación. La capacitación de personal en el área de seguridad de aplicaciones web es definitivamente un valioso activo para las empresas. Proporcionar conocimientos básicos esenciales y la comprensión de las cuestiones de seguridad relacionadas, así como la capacitación práctica necesaria a su personal es actualmente imperativo. Este tipo de capacitación también ayuda al personal a entender y reconocer las posibles fallas de seguridad en sus negocios en tiempo real y por ende a evitar perjucios derivados.

¡Hacer las cosas bien antes desde el principio significa ahorrar dinero! 

La magnitud del riesgo actual es sin exageraciones demasiado alta para obviarla. Según fuentes de la industria, las aplicaciones web representan el 80% de las vulnerabilidades en línea. Su aplicación en línea puede tener cientos de vulnerabilidades latentes y por tanto una evaluación de riesgos al momento de la instalación de la misma es vital para el futuro de sus negocios en línea.

Aquí es donde la seguridad siempre es más eficaz, en la prevención de problemas antes de que sucedan. Pruebas exhaustivas y la comprobación de cada parte de su sistema para detectar las posibles deficiencias es parte primordial de una política preventiva. Los ahorros de costos pueden ser enormes. Infracciones o malas prácticas de seguridad pueden resultar en ataques tanto a las empresas en línea como a sus clientes, incurriendo en pérdidas financieras a veces muy graves. Y para añadir a los gastos, lo que usted no haya resuelto antes deberá resolverlo después, por tanto una política de prevención en el 80% de los casos significa un ahorro sin discusión.

Los problemas de seguridad en sus aplicaciones web son totalmente evitables. La mejor práctica es la prueba rigurosa y sistemática de todas las aplicaciones web antes de salir a la luz o entrer en línea de forma definitiva.

Piense en su aplicación web como en un buen submarino recién terminado: ¿Usted lo sumergiría a 5000 metros de profundidad sin haber hecho anteriormente una serie de pruebas de capacidad? Francamente no lo creo.

Tipos de entrenamiento necesarios:
La seguridad de aplicaciones web puede ser mucho más compleja de lo que parece por tanto existen varios tipos de entrenamiento dependiendo de las áreas en las que se desenvuelva el personal:
  • Entrenamiento Básico:
    Es necesario para cualquier personal a cargo de las áreas de negocios en línea conocer los riesgos a los que están expuestos así como ciertos principios fundamentales en cuanto a seguridad de las aplicaciones en línea con las que tienen relación y con las que desempeñan su trabajo cotidiano. La idea es formar una cultura de seguridad en línea sólida que forme parte a su vez de la cultura empresarial.
  • Entrenamiento Medio:
    Este es el que se brinda específicamente a las personas involucradas en las tomas de decisiones y que inciden en el tipo de aproximación al cliente y por tanto en el formato de las áreas de las aplicaciones en línea. Es importante que este personal esté al tanto de todos tipos de ataques que existen y cómo sus decisiones pudieran influir en que de una u otra forma estos tipos de ataque pudieran ser efectuados. Este entrenamiento debe convertirlos en conocedores de las posibles vulnerabilidades y las consecuencias que estas pudieran tener aunque no sean los encargados de corregirlas.
  • Entrenamiento Avanzado:
    Definitivamente, es a la hora de producir código y diseñar los procesos de la aplicación cuando se comete la gran parte de los errores que dejan abiertas las puertas a futuras complicaciones. En este tipo de entrenamiento, que es el más largo y especializado el programador o desarrollador deberá reconocer las fallas a nivel de código, pero por supuesto además deberá entender cómo evitarlas. Este entrenamiento tiene dos fases: La primera se encarga de enseñar a detectar, evaluar y evitar las fallas en forma genérica, y la segunda se basa en aquellas fallas específicas que dependen de la plataforma en la cual han sido desarrolladas o se desarrollarán la aplicación o aplicaciones.
Es importante aclarar que todo el aprendizaje debe estar basado en estándares OWASP y WASC, para que de esta forma se le haga entrega al personal de las herramientas necesarias para a su vez transmitir a otros los conocimientos adquiridos y potenciar los conocimientos en seguridad web como parte del capital de conocimientos empresarial.

Hasta la próxima...

25 de noviembre de 2010

La importancia de reducir la superficie de ataque.

Los atacantes logran penetrar una aplicación web por los más insospechados lugares. A veces inclusive el ataque es llevado a cabo por vectores que están relacionados pero que nada tienen que ver directamente con la aplicación web. Es común oír hablar de sitios vulnerados a través de servicios como FTP o SMTP e inclusive POP3, NNTP y muchos otros, pero: ¿Cuál es la razón por la cual este tipo de ataques son frecuentes? Lo que sucede es que la superficie de ataque de dichas aplicaciones es a veces demasiado extensa.


Para entender el concepto de "superficie de ataque" solo necesitamos imaginarnos a un bombardero de la segunda guerra mundial B25 (el atacante) tratando de visualizar la posición del objetivo a ser bombardeado. En esa época no existían radares sofisticados, ni posicionamiento por GPS, por lo cual la visibilidad del objetivo era uno de los principales factores que influían en que este pudiera ser alcanzado de forma más o menos eficiente.

Un objetivo más visible, necesitaba una protección antiaérea mejor y hasta se recurría en algunas ocasiones al camuflaje. También hay que recordar que del lado de atacante existían y existen los conocidos espías, que podían desde el campo de batalla, enviar información precisa acerca de la superficie, forma e importancia del objetivo. También un objetivo a veces bien camuflado, podía ser identificado por instalaciones adyacentes al mismo que no concordaban con el camuflaje. Por ejemplo un aeropuerto y sus aviones podían ser camuflados, pero si se existían grandes depósitos de combustible, muchos "graneros"con forma de angar, o demasiada actividad de personal, se podía comprometer el camuflaje y dejar al descubierto la operación.

Regresando a nuestro campo de batalla real, la web, y analizando el símil con el ejemplo anterior es indudable que mientras más rutinas, páginas dinámicas y especialmente formularios tenga una aplicación, mayor será su superficie de ataque. La cantidad de los anteriores es lo que determina su tamaño y llamaremos "superficie neta o necesaria".

Podemos después de lo anterior deducir que la posibilidad de un ataque es directamente proporcional a la superficie de ataque total de la aplicación.

Sin embargo, los servicios adicionales que utiliza el programador o que han quedado instalados por defecto, comprometen también la seguridad de nuestra aplicación web, tal como lo hacían la actividad del personal y los depósitos de combustible en el caso de nuestro ejemplo. Estos generan una superficie de ataque adicional, superflua o innecesaria que aumenta el riesgo de ataques.

Uno de los casos más comunes de este tipo de servicios instalados en los servidores y que a veces están completamente a disposición del atacante proviene de la instalación por defecto de paquetes de servicios pre-configurados, como por ejemplo XAMPP, algunas versiones de WAMP o LAMP  entre otros. Este enlace les llevará a una tabla de comparación de los más conocidos. También proviene de instalaciones de paquetes de código abierto mal configurados como manejadores de contenido CMS y otras utilidades.

El programador o el administrador del servidor, instalan dichos paquetes pre-configurados sin entender o percatarse de que la configuración por defecto es básica y hasta se pudiera decir que algo inocente. No hace falta decir por ejemplo, que no tiene mucho sentido proteger el servicio de MySQL si se deja el acceso al PhpMyAdmin completamente libre. Y esta es solo una de las configuraciones por defecto en las que no se repara a la hora de instalar el software pre-configurado.

Hay veces en que un simple escaneo de puertos permite verificar que tipo de software pre-configurado se ha instalado en un servidor web, ya que desde afuera de la red local se puede acceder a puertos como 21, 25, 110, 443, 119 y otros todos instalados en el mismo servidor, y así entablar conversaciones Telnet o de otro tipo con los servicios activos en dichos puertos. Si el atacante logra vulnerar uno solo de estos servicios inocentemente configurados desde el punto de vista de la seguridad, tendrá el camino prácticamente abierto hacia nuestra aplicación, o también podrá simplemente utilizar los servicios para sus fines, como enviar SPAM por el SMTP server, ubicar un sitio de phishing en nuestro servidor o simplemente colocar grandes cantidades de software ilegal para distribuirlo desde nuestro servidor FTP.

¿Y los espías? Cuando me refería a los espías quise hacer una comparación a lo que comúnmente se conoce como "Google Hacking Database". No hay mejor conocedor de nuestra aplicación web que Google. Los atacantes lo saben y hacen que trabaje para ellos mediante una serie de técnicas y consultas que han desarrollado y que permiten buscar sitios con determinadas vulnerabilidades conocidas en base a su tipo de servidor y servicio. Es realmente impresionante la cantidad de sitios vulnerables que puede mostrase mediante el uso del GHDB. El equipo de Google trabaja permanentemente en la caza de este tipo de consultas para reducir los posibles perjuicios, pero ellos mismos son víctimas del enorme potencial de la herramienta y no puede controlar su potencia por lo que permanentemente se descubren nuevos trucos.

Es claro que luego de leer este artículo Usted deberá tener un concepto algo más claro de lo que se conoce como "superficie de ataque" y posiblemente se le hayan ocurrido algunas ideas para reducirla. En otros artículos hablaremos de las técnicas de reducción y camuflaje de dicha superficie.

Hasta la próxima...

23 de noviembre de 2010

La importancia de manejar los archivos de registro de sucesos HTTP

Una de las informaciones menos apreciadas de las que el desarrollador web tiene a la mano, son los archivos de registro de sucesos del servicio HTTP. Estos normalmente eran considerados la única fuente de información estadística a mano. En ellos los usuarios van dejando su huella cada vez que solicitan un recurso en nuestro servidor, bien sea Apache, IIS, WebSphere o cualquier otro.

La razón por la que han sido dejando algo de lado, es que si bien su información es valiosa, ya no son tan útiles para fines estadísticos debido al gran éxito de Google Analytics el cual permite hacer seguimiento de todos los movimientos de páginas en las que se haya agregado un pequeño "script" al final de las mismas, y para ser realmente honesto sus reportes y estadísticas son impresionantes.

Pero a nivel de seguridad Google Analytics nos sirve de poco o casi nada, ya que no lleva control más que de las páginas en las que se agrega el script y no así de los recursos como imágenes, archivos de flash y archivos de código Javascript. Además si la página en ejecución genera un error 500 de ejecución en el servidor y no se completa, tampoco será de utilidad ya que el servidor no habrá entregado la parte final de la página (desde el error en adelante) y el archivo de control de Google Analytics se encuentra siempre al final del código de la página. Tampoco detectará un escaneo de vulnerabilidades no autorizado, debido a que las maquinarias de escaneo no ejecutan los scripts de las páginas que escanean...

Sin embargo dejando esta maravillosa solución estadística para el equipo de mercadeo, por efectos de seguridad es necesario retomar el control de los archivos de sucesos del servidor HTTP. El mejor lugar para detectar un intento de escaneo de vulnerabilidades no autorizado es precisamente allí. Sin embargo, hallar la información en estos enormes archivos de texto, no es simple debido a que cada solicitud hecha al servidor HTTP generará una línea, y una página junto con sus diferentes componentes podría generar hasta 80 líneas diferentes por lo que si la página es solicitada 1000 veces, estaríamos hablando de 80.000 líneas o "hits". En un ataque de DoS (Denial of Service) comunmente podemos llegar a recibir esa cantidad de solicitudes por minuto, por lo que capturar las direcciones IP de los equipos atacantes puede ser un trabajo bastante duro.

Escarbar en un archivo de estas magnitudes sin una herramienta apropiada es difícil. Pero no hay que alarmarse, probablemente usted ya haya oido hablar de AWstats 6.95  en su última versión estable en el momento de escribir este artículo. AWstats es una solución Open Source, y por tanto la mayoría de los proveedores de alojamiento compartido la ofrecen en sus soluciones en sus paneles de control. Es 100% configurable al tipo de servidor HTTP que se esté manejando y permite obtener una serie de reportes muy importantes acerca de las peticiones recibidas.

Existen soluciones mucho más sofisticadas como Urchin 7.0. Esta solución es la matriz de código sobre la que se basa Google Analytics y al estar instalado en un servidor y analizar los archivos de registro de sucesos (a los que no puede acceder Analytics) podrá reportar muchos más detalles. En realidad es una herramienta impresionante, pero no es gratis.

Sin embargo, ni AWstats ni URCHIN 7 ni siquiera los archivos de registro HTTP pueden servirnos para rastrear los errores de ejecución en nuestra aplicación, ya que si bien los registros de sucesos HTTP pueden decirnos en qué página y que IP generó el error, no pueden darnos detalle del error en sí  y datos como el número de línea, descripción del error y otros detalles muy importantes para corregir el problema.

Para poder manejar este problema Apache tiene un registro independiente que se encuentra en /var/log/apache2/error_log (o error.log) en donde podremos detectar los errores que produce la aplicación sin necesidad de esperar a que algún usuario los reporte. En el caso de IIS también existe una solución, pero los errores 500 del servidor HTTP son considerados errores de sistema y es necesario recurrir al visor de sucesos (Herramientas Administrativas/Administración de Equipos/Visor de sucesos).

En IIS el manejo del error 500 depende de la capacidad de poder acceder a los archivos de registros de error, por lo que la mejor solución para evitar problemas especialmente en entornos de alojamiento compartido, es generar nuestra propia página de error 500, con la que primordialmente ocultaremos la información que no deseamos ofrecer al visitante, y la registraremos a gusto en un archivo de sucesos propio.

En este artículo muy interesante explica el tratamiento de los errores 500 de diferentes formas para aplicaciones en ASP.NET. Para aquellos que trabajen sobre Apache este otro artículo puede explicarles detalladamente el proceso de manejo de páginas de error personalizadas.

Por otro lado siempre es importante aclarar que el uso de páginas de error personalizadas es muy importante, inclusive para el manejo de otro tipo de errores. Por ejemplo: Los atacantes pueden obtener mucha información detectando errores 404 y 403, con la mezcla de los cuales y una buena dosis de ingenio acerca de los nombres comúnmente utilizados para nombrar directorios y páginas, logran obtener una visión bastante acertada del arbol de directorios de nuestra aplicación.

Hasta la próxima.

21 de noviembre de 2010

Cuando la "S" en HTTPS no es suficiente!

Un error común de los programadores es creer que el hecho de que se ofrezca un servicio SSL/TLS en un servidor web con un certificado válido es más que suficiente para garantizar que los datos no sean interceptados por los atacantes.

Si bien en teoría y en la realidad esto es cierto, el programador debe entender que los protocolos SSL/TLS protegen la comunicación entre el navegador y el servidor hasta cierto punto. Y es que no es el navegador el encargado de cifrar el contenido y establecer la comunicación cifrada con el servidor. Los protocolos SSL/TLS se encuentran entre la capa de aplicación (en donde se halla el HTTP, SMTP, FTP y otros protocolos) y la capa de transporte, justo encima del protocolo del protocolo de comunicación TCP.

Cuando usted indica al navegador que conecte con un servidor que usa SSL usted utiliza HTTPS, la última consonante (S) indica al navegador que conecte por HTTPS que en realidad es simple HTTP con la adición de el protocolo de seguridad SSL o TLS.

Por tanto, cualquier ataque que intercepte la comunicación a nivel de la capa de aplicación podrá extraer la información sin cifrar en texto plano. Lo anterior significa que cualquier BHO (Browser Helper Object) Plug-in de Firefox o Chrome, e incluso cualquier sniffer que intercepte la mensajería del navegador fuera de este hacia las librerías de comunicación del sistema operativo, está en posibilidad de obtener la información que en un principio creeríamos que estaría protegida por el protocolo de cifrado SSL/TLS.

Es muy simple de verificar. Si usted tiene Firefox instalado en su sistema solo necesita instalar un add-on llamado Httpfox que si bien es una aplicación muy buena, útil e interesante, además de inofensiva, le permitirá verificar lo que en estas líneas intento exponer.

Esta aplicación a parte de ser extremadamente útil para los webmasters y programadores web, le permite ver todo el flujo de datos que pasa a través del protocolo HTTP. En resumidas cuentas es lo que llamaríamos un "HTTP sniffer". Utilíce Httpfox para visualizar el flujo de un sitio web que se comunica por SSL/TSL (un sitio que conecte por HTTPS) y verifique como usted podrá perfectamente visualizar los contenidos introducidos en los formularios y hasta aquellos de los de los campos de tipo "password", mientra explora el contenido de las peticiones POST.

Es lógico entender a partir de este peueño experimento que si el Httpfox está en capacidad de mostrarle esta información de forma completamente transparente y legal, eso también significa que cualquier otro add-on creado con mala intención podría tomarla la misma y enviarla a los amigos de lo ajeno. ¿Interesante no?

En futuros artículos hblaremos acerca de como proteger al usuario de este tipo de amenazas, aunque ya he mencionado algo en un artículo posterior: Man in the Browser Attack

Hasta la próxima...
Mauro Maulini R.

19 de noviembre de 2010

Vulnerabilidad de desbordamiento de enteros y cómo prevenirla.

Anteriormente hemos mencionado la importancia de la desinfección de parámetros como herramienta fundamental en el combate de las vulnerabilidades de una aplicación web, sin embargo la mayoría de las veces estamos atribuyendo que el parámetro recibido puede contener una cadena de SQL injection o XSS, sin percatarnos que hay un tipo infección utilizada para vulnerar nuestro sitio que es diferente a las anteriores: Desbordamiento de enteros o "Integer Overflow"

En palabra simples, se trata de parámetros numéricos recibidos por manipulación del querystring que desbordan la capacidad de los contenedores que hemos preparados para ellos, o que aunque no la desborden son luego utilizados en operaciones aritméticas en donde pudieran exceder la capacidad del contenedor asignado al resultado.

Es simple: Usted siempre recibe del usuario cadenas de texto por los parámetros del querystring, y si no toma las precauciones necesarias antes de convertirlas a enteros, puede tener errores. La primordial precaución que por defecto tomamos los desarrolladores es la de verificar que dicha cadena en realidad represente un número entero, sin embargo somos pocos quienes verificamos que dicho número no exceda la capacidad para la cual fue creado:

Un ejemplo de la vulnerabilidad en asp clásico. Si usted recibe un parámetro por el URL de la siguiente forma:

checkHotel.asp?idHotel=34 

Usted no solo debe preocuparse de que la cadena que contiene el parámetro idHotel sea numérica y entera sino de que soporte un intento de desbordamiento como por ejemplo:

checkHotel.asp?idHotel=642366423426423466423464

Si usted esperaba que el parámetro no superara un entero simple, se llevará una sorpresa al tratar de llamar una función como "cInt" ya que al desbordarse la capacidad de un entero la función generará un error debido a que espera un parámetro que se pueda convertir a un entero simple de 16 bits.

Quizás esta es una de las razones para dejar de una vez por todas de programar en ASP clásico, debido a que VbScript no posee una serie de funciones que permitan verificar los parámetros numéricos de forma eficiente.

Este tipo de falla puede ser utilizada para generar DoS (Denial of Service) ya que si por ejemplo el error se genera luego de haber abierto conexiones a bases de datos o requerido recursos que debido al mismo error no son liberados a tiempo, el atacante podría llamar la rutina indefinidamente hasta dejar al servidor inutilizado por falta de recursos, o al menos inutilizar la aplicación web.

Visto lo visto, mejor mudarse a ASP.NET si aún no lo ha hecho, en donde los métodos de los tipos enteros TryParse son una solución muy eficiente para convertir parámetros sin tantos dolores de cabeza. Cada tipo de entero tiene su propio método TryParse, así por ejemplo int32.TryParse es el método necesario para convertir cadenas a números de 32 bits.

En otros lenguajes como y JSP/Java podemos usar el manejo de excepciones (que si es eficiente) para verificar la validez de las conversiones con el conocido try/catch.

    public static boolean validateNumber(String num) {
        try {
            Integer.parseInt(num);
            return true;
        catch (Exception e) {
            return false;
        }
    }


En PHP una de las soluciones posibles además del manejo de excepciones es usar la librería "GMP arbitrary lenght integers" para enteros de longitud arbitraria. Hay que agregar la extensión al archivo "php.ini" des-comentando la línea:
;extension=php_gmp.dll


Una vez iniciada la librería solo resta usar los enteros:
<?php
$a 
gmp_init(123456);

$b gmp_init("0xFFFFDEBACDFEDF7200");
$c gmp_init("7756466309883824442551");
?>

De esta forma podrá manejar enteros sin importar su longitud de una forma mucho más segura ya que esta librería presenta todas las funciones matemáticas necesarias.

Hasta la próxima...

18 de noviembre de 2010

¿Que son Los OTP? One Time Password Tokens

OTP es el acrónimo para One Time Password o dispositivos generadores de claves de acceso perecederas de un solo uso. La idea es simple, usted puede obtener una clave o "token" en tiempo real mediante un dispositivo independiente de la web o de su sistema de acceso, que está sincronizado con el sistema de validación y utiliza la misma semilla aleatoria que este: el tiempo.

Son dispositivos que se han hecho muy comunes y famosos en Europa y Estados Unidos, ya que en la banca en línea son utilizados para validar las transacciones electrónicas y han demostrado ser una solución muy eficiente para solventar el problema de usurpación de identidad, ya que si no se posee el OTP correcto la clave que se enviará no será válida.

Sin embargo a pesar de su eficiencia han demostrado tener algunos problemas:
  • Su costo no permite su masificación por lo que solo son utilizados en muchos casos por clientes VIP.
  • Son dispositivos de hardware y por tanto para ser sincronizados en caso de pérdida de sincronización es necesario recogerlos.
  • Son suceptibles de sufrir el denominado efecto Tamagoshi. Si usted o alguno de sus familiares ha tenido este tipo de mascota virtual, sabrá a qué nos referimos. Se trata de los problemas que suceden cuando se pierde o se olvida el dispositivo, se introduce en la lavadora o sucede algún otro accidente que haga que el mismo deje de funcionar.
  • G-OTP - One Time Password
    versión para PC
    Desarrollado por Mauro Maulini R.
  • Su margen de error está directamente relacionado con la eficiencia de sincronización de sus relojes con el del servidor principal.

Si bien han demostrado ser una solución muy efectiva, tecnológicamente aún están siguiendo un proceso evolutivo que permita que sean más exactos y más económicos.

Han surgido muchas variantes, los hay en forma de tarjeta de crédito, con teclado para agregar una clave de uso, con lectores de huellas digitales y por último hay soluciones de software que los emulan en forma de OTP virtual.

Son muchas las variantes pero quizás esta última sea a mi entender la más eficiente, ya que al tratarse de software que puede ser utilizado en nuestros teléfonos inteligentes o nuestras PCs, reduciendo sustancialmente su costo final. Claro está que en estos casos los procesos de "enlistado" o "enrollment" que son los que permiten asignar un determinado OTP a un usuario, deben ser manejados con mucho cuidado. A mi parecer ese problema está resuelto.

Personalmente no puedo ser imparcial ya que he desarrollado un OTP Virtual con bastante éxito, a mi parecer es muy interesante y además se comunica con el usuario en formato gráfico evitando transmitir número y letras. Su nombre es GOTP (Graphic OTP). En la actualidad estamos integrándolo a un sistema de validación de ingreso para diferentes tipos de control de acceso desde web hasta control de ingreso físico, y para ello también estamos elaborando las versiones correspondientes en iOS, Android y Windows Phone, además de la versión para PC bajo Windows que ya es conocida y popular.
Si desean má información  sobre esta solución pueden contactarme

Hasta la próxima...

15 de noviembre de 2010

Clasificación de Amenazas WASC 2.0

La Clasificación de Amenazas WASC es un esfuerzo de cooperación para aclarar y organizar las amenazas a la seguridad de sitios web. Los miembros del Web Application Security Consortium han creado este proyecto para desarrollar y promover estándares de la industria en lo referente a la terminología para describir estos temas. Los desarrolladores de aplicaciones, profesionales de la seguridad, proveedores de software, y auditores tendrán la posibilidad de acceder a un lenguaje común y coherente, así omo a las definiciones para los problemas de seguridad relacionados con la web.


Las amenazas  traducidas al castellano son las siguientes:
  1. Autenticación insuficiente
  2. Autorización insuficiente
  3. Desbordamientos de enteros.
  4. Insuficiente protección en la capa de transporte.
  5. Inclusión de archivos remotos.
  6. Formato de cadenas.
  7. Desbordamiento del búfer.
  8. Cross-Site Scripting.
  9. Cross-Site Request Forgery.
  10. Denegación de Servicio. DoS.
  11. Fuerza bruta.
  12. Spoofing de contenido.
  13. Fuga de información.
  14. Configuración errónea del servidor.
  15. Configuración errónea de la aplicación.
  16. Indexación incorrecta de directorios.
  17. Permisos indebidos al sistema de archivos.
  18. Predicción de credenciales y/o sesión.
  19. Inyección de SQL.
  20. Manejo inadecuado de entradas.
  21. Anti-automatización insuficiente.
  22. Manejo inadecuado de salidas.
  23. XML inyección.
  24. HTTP Request Splitting.
  25. HTTP Response Splitting.
  26. Contrabando de solicitud HTTP.
  27. Contrabando de respuesta HTTP.
  28. Inyección de Byte Nulo.
  29. Inyección LDAP.
  30. Inyección de comandos de mail.
  31. Ejecución de comandos de SO.
  32. Desvío de enrutamiento.
  33. Recorrido de rutas.
  34. Localización previsible de recursos.
  35. Abuso de Arreglos SOAP.
  36. Inyección SSI.
  37. Fijación de sesión.
  38. Abuso de redireccionamiento URL.
  39. Inyección XPath.
  40. Insuficiente validación de procesos.
  41. Sobrecarga de atributos XML.
  42. Abuso de funcionalidad.
  43. Entidades externas XML.
  44. Expansión de entidades XML.
  45. Fingerprinting.
  46. Inyección XQuery.
  47. Caducidad de sesión insuficiente.
  48. Indexación Insegura.
  49. Debilidad de recuperación de contraseña.
Para conocer más de cada una de ellas específicamente, puedes visitar directamente http://projects.webappsec.org/w/page/13246978/Threat-Classification

Hasta la próxima...

OWASP Code Crawler

¿Porqué tenemos que esperar a que se realice sobre nuestra aplicación web un test de penetración, un escaneo de vulnerabilidades o peor aún a que esta sea atacada por una vulnerabilidad no corregida a tiempo?

Lo primero es programar de forma segura, o por lo menos manteniendo una clara visión de las posibles fallas de seguridad que pudieran existir en nuestras aplicaciones. Y cómo ya hemos hablado del tema con anterioridad, así como hemos hablado de las guías de desarrollo OWASP, no voy a aburrirles con el tema.

Es cierto que en muchas ocasiones la revisión de vulnerabilidades en código ante los típicos "deadlines" improrrogables queda relegada a un último plano, sin embargo hoy vamos a hablar de una utilidad que puede ahorrarnos muchas horas en estos casos y por lo menos nos va a permitir ubicar las posibles fallas en nuestro código.


Estoy hablando del OWASP Code Crawler que es una herramienta de depuración de posibles vulnerabilidades en código fuente para código en .NET y J2EE/JAVA. Puedes descargarlo aquí.

Es una aplicación desarrollada en .Net 3.5, que se basa en una maquinaria muy afinada de control de Expresiones regulares, que nos permitirá encontrar errores tradicionales y nos permitirá utilizar herramientas como un calculador DREAD (calculador de riesgo de una condición o amenaza de seguridad).

Hasta la próxima...

10 de noviembre de 2010

¿Claves de acceso fáciles de recordar y muy fuertes? ¿Cómo lograrlo?

El problema que normalmente tienen todos los usuarios es que a medida que van haciendo caso a los consejos de seguridad acerca de como crear claves "seguras" sus claves de acceso se empiezan cada vez más a parecer a unos garabatos extraños que se usaban en los "comics" para simular que un personaje decía malas palabras.

Sin embargo hay detalles que casi nunca se le les explican por posible desconocimiento de los programadores que realizan la interfaz de acceso, y estos son los siguientes:

  • Una clave de acceso no necesariamente debe estar formada por una sola palabra.
  • El espacio en blanco es tan válido como cualquier otro caracter.
  • Los campos usados para el ingreso y creación de claves no debieran tener límites de caracteres.
  • Una frase es mucho más fácil de recordar y más difícil de reproducir.

Basados en lo anterior una clave como: "Mi 1ª clave es 99% más segura!" cumple con reglas muy importantes para la construcción de claves de acceso fuertes como las siguientes:

  • Su longitud es mayor que los eternos 8 caracteres mínimos.
  • Utiliza letras en mayúsculas y minúsculas combinadas.
  • Tiene caracteres especiales.
  • Utiliza caracteres numéricos.
  • Contiene espacios en blanco. 
Hay que aclarar que la frase que hemos propuesto es muy superior a las convencionales claves que cumplen con los anteriores requisitos en una sola palabra y un promedio de 8 a doce caracteres, ya que solo para empezar tiene 30 caracteres. Sin embargo a pesar de su longitud es mucho más fácil de recordar.

El problema de enseñar al usuario a construir claves como esta se basa en que las interfaces de creación de claves no soportan cantidades razonables de caracteres como para construir este tipo de clave. Esto viene por herencia de cuando las claves se almacenaban.

Sin embargo ya todos sabemos que almacenar claves de acceso es un riesgo muy alto que no debemos correr y que lo que en realidad se debe almacenar es un hash de dicha clave (MD5, SHA1, SHA256, Whirpool, etc.), y que dicho hash tiene una cantidad máxima de caracteres según el tipo. Unos de los más largos como el SHA256 por ejemplo, siempre tendrá 64 caracteres así la clave tiene el largo de todo un libro.

Quizás otra de las razones para limitar la cantidad de caracteres en los campos de ingreso y creación de claves ha sido que estos son los primeros en ser utilizados por los hackers para intentar ubicar vulnerabilidades de XSS, SQL injection y muchas más, pero hay que recordar a los programadores que el que coloquen un simple atributo "maxlength" a los campos de ingreso de un formulario no evita que los hachers forjen formularios independientes. Por otra parte una buena política de desinfección de parámetros de entrada no puede basarse en controlar el flujo de ingreso de esa simple forma.

Por tanto, se deduce de lo anterior que si en realidad se desea que los usuarios puedan utilizar claves de acceso fuertes, se deberá permitir lo siguiente:
  • Campos de ingreso de clave con capacidad muy superior de caracteres (60 es un buen número).
  • Capacidad de insertar cualquier tipo de caracter UTF-8.
Sin embargo por mucho que aumentemos la capacidad, es importante recordar que el usuario podría seguir introduciendo claves débiles si no las validamos, por lo que un componente de validación de la fuerza de la clave del lado cliente es imprescindible para garantizar que los usuarios aprendan a mejorar la calidad de sus claves de acceso.

Hasta la próxima.

29 de octubre de 2010

Idea: Usar indicadores de la fuerza de la clave

Uno de los principales errores de un programador es dejar a criterio del usuario el formato o las condiciones mediante las cuales deben ser completados los diferentes campos de ingreso de datos en una aplicación. Llevado esto al campo de la seguridad, es importante entender que por mucho que le expliquemos a un usuario cómo crear una clave de acceso segura, estos no siempre están dispuestos a tomarse el tiempo de leer o escuchar nuestros consejos, aunque la falta de interés vaya en detrimento de su propia seguridad.

Es por eso que no podemos dejar bajo ningún concepto que las claves de acceso o de seguridad sean escogidas, sin la propia validación de las mismas para que cumplan con un formato relativamente seguro.

Sin embargo validar la seguridad de una clave o password no siempre es tarea fácil y la validación que pudiera ser aceptable o suficiente para otros casos no lo es tanto. Es por esto, que una modalidad muy aceptada actualmente es el uso de componentes en javascript llamados indicadores de fuerza de la clave o "password strength indicators" con los cuales los programadores podrán desarrollar mejores y mas ricas interfaces a la vez que mejorar drásticamente la fuerza de las claves de sus usuarios.


A continuación presento un listado de interesantes sitios en los que podrás conseguir componentes de este tipo de fácil adaptación a tus aplicaciones:
  1. jQuery Password Strength Meter
    http://mypocket-technologies.com/jquery/password_strength/
  2. jQuery Password Strength Meter Plugin
    http://phiras.wordpress.com/2007/04/08/password-strength-meter-a-jquery-plugin/
  3. Enzoic Password Meter
    https://www.enzoic.com/free-password-strength-meter/
Para los programadores que usan ASP.NET Microsoft provee incluido en el Ajax Control Toolkit un componente muy útil denominado PasswordStregth que encapsula varios tipos de comportamiento personalizables.

Todos estos componentes son utilidades client-side (del lado del navegador). Recuerden además utilizar del lado del servidor un hash suficientemente fuerte (SHA256, Whirpool) y preferiblemente usar técnicas de "salt key" para prevenir el uso de Ataques por Diccionario y Rainbow Tables.

Hasta la próxima.

26 de octubre de 2010

Phishing: El parásito que evoluciona permanentemente.

El Phishing ya se ha convertido en un parásito dañino de nuestras aplicaciones y sistemas en Internet. Uno de los ejemplos más claros y mas actuales se refiere a que ahora ataca a cualquier sistema en el que pudiéramos colocar nuestros datos personales y no solamente a las redes sociales sino hasta a los sistemas más pequeños como por ejemplo sistemas de clasificados en línea y otros que parecieran estar exentos de este tipo de amenaza, nada más lejos de la realidad.

Según el Grupo de Delitos Telemáticos de la Guardia Civil española, los casos de suplantación de identidad han llegado a atacar directamente a sistemas de clasificados y venta en línea, en los cuales el usuario coloca una oferta, como por ejemplo la venta de una casa. Una vez colocada la oferta el usuario recibe dias después un enlace por e-mail que le advierte que hay un posible cliente interesado o que alguien ha solicitado información sobre el producto anunciado, por lo que no duda ni un instante en hacer clic sobre el enlace que lo lleva a una página falsa copiada del sistema de ventas o clasificados en línea en la que se le solicitan los datos nuevamente.

¡El resto es historia vieja!

Como podrán apreciar, la seguridad web no es un tema específico dedicado a bancos y aplicaciones transaccionales. Hoy en día cialquier sitio puede ser víctima de un ataque o bien para obtener los datos del usuario como en el ejemplo anterior, o bien para servir de plataforma de lanzamiento de la amenaza, porque pueden ustedes suponer con mucho acierto que los atacantes no colocan este tipo de sitios falsos en servidores propios registrados a su nombre.

El enlace a la página del Grupo de Delitos Telemáticos de La Guardia Civil Española en el que se trata el tipo de estafa es el siguiente: https://www.gdt.guardiacivil.es/webgdt/alertas_gdt.php?id=106


Seguimos en contacto...

25 de octubre de 2010

Be smarter than John - Se más listo que John!

Muy interesante esta campaña de F-secure en la que se muestra a un usuario, un tal John, entregando los datos de su Facebook, Twitter y tarjetas de crédito a todo el mundo con carteles en las estaciones del metro y plazas de importantes ciudades europeas.

Aunque es una forma exagerada y llamativa de hacerlo, John solo está haciendo lo que mucha gente hace al dejar sus claves de acceso y datos personales al alcance de todos...




Trata de ser más listo que John!

Hasta la próxima!

20 de octubre de 2010

Evercookie: ¿Una cookie virtualmente imborrable?

Un nuevo desarrollo pone los pelos de punta a los programadores web, ya que no es fácil entender las repercusiones que este puede tener en lo referente a la privacidad de los usuarios en línea y como todo descubrimiento importante, puede ser utilizado para bien o para mal...

Se trata de los denominados Evercookies, o cookies virtualmente imborrables.

Para refrescar la memoria de los lectores, una "cookie" no es más que un pequeño archivo de texto que un desarrollador puede introducir en nuestro equipo a través del navegador y controlado por este, para poder guardar detalles importantes de navegación que solo le interesen específicamente al sitio que los guarda, como por ejemplo datos acerca de los gustos del usuario o preferencias de este, para teóricamente agilizar la navegación y presentar interfaces más inteligentes que se adapten mejor a nuestros gustos y usos. Por ejemplo mediante un cookie el sitio puede saber si el usuario ya ha votado en una encuesta para no presentársela nuevamente, si pertenece a un tipo de usuarios y enviarlo directamente a su área de interés, y hasta para saber si ya ha visto una cantidad de veces una publicidad determinada. La vida en la web sin cookies sería muy aburrida.

Los cookies además tienen muchas otras utilidades no tan obvias, por ejemplo controlar el rastreo de sesión a lo largo de las diferentes páginas de una aplicación en línea, ayudarnos a guardar los artículos que vamos seleccionando en un carrito de compras y muchas más. Inclusive muchos programadores que dicen no usar cookies los usan sin saberlo cuando acceden a la variable de sesión de un usuario de un lenguaje de desarrollo web.

Volviendo al nuestro punto de interés, la ventaja a nivel de privacidad con respecto a las cookies, es que cuando  el usuario lo desee puede borrarlas y punto. De esta forma los sitios que las colocaron pierden el rastreo que pudieran hacer mediante estas y el usuario navega "anonimamente" o lo más parecido a ello que puede.

El problema es que los Evercookies, además de ser una cookie convencional, usan entre 8 y 12 tipos de repositorios adicionales en el navegador para colocar la información (dependiendo de la viabilidad en cada caso), y si borramos ocho de ellos con que solo quede uno activo los otros se vuelven a crear.

Para aquellos interesados en verificar a fondo los nueve repositorios son los siguientes:


  1. Estandard HTTP Cookies
  2. Local Shared Objects (Flash Cookies)
  3. Silverlight Isolated Storage 
  4. Guardar cookies en valores RGB  auto-generados, colocados en PNGs cacheados por el navegador usando el tag de HTML5 "Canvas" para leeer los pixels (cookies) de nuevo.
  5. Guardando cookies el el Historial de Navegación 
  6. Guardando cookies en  HTTP ETags 
  7. Guardando cookies en el Web cache 
  8. window.name caching
  9. Internet Explorer userData storage
  10. HTML5 Session Storage 
  11. HTML5 Local Storage 
  12. HTML5 Global Storage 
  13. HTML5 Database Storage mediante SQLite
¿Interesante?
Más de los Evercookies en otras entregas...

19 de octubre de 2010

Las Botnets y el Distributed Brute Force Attack

Para empezar definamos de manera breve qué es una Botnet: Según Wikipedia Botnet es un término que hace referencia a un conjunto de robots informáticos o bots, que se ejecutan de manera autónoma y automática. Normalmente este tipo de redes de bots son asociadas con prácticas fraudulentas y se forman infectando gran número de ordenadores mediante troyanos ubicados en software obtenido de forma ilegal y otros vectores de infección. Una vez creadas su "amo" o "botmaster" puede controlar los ordenadores infectados mediante instrucciones que envía a los mismos por diferentes medios como por ejemplo IRC. Estas redes de ordenadores "zombies", son utilizadas al unísono con fines poco éticos, los cuales hasta hace poco tiempo se limitaban al envío de SPAM y a la generación de DDoS (Distributed Denial of Service).


Los amos de las Botnets, las ofrecen al mejor postor, y de esta forma un tercero logra por ejemplo enviar gran cantidad de SPAM desde una lista enorme de equipos lo cual es muy difícil de bloquear, o tratar de "colgar" un servicio en un servidor determinado, haciendo una enorme cantidad de solicitudes al mismo de forma que este se vea imposibilitado de atender los requerimientos reales.


Sin embargo actualmente se han conseguido otros fines para las Botnets, y uno de los que más preocupa es el Distributed Brute Force Attack, o ataque por fuerza bruta distribuido para obtención de passwords de servidores, servicios e inclusive a web transaccionales.


Lo que en realidad hace muy difícil manejar esta técnica de intrusión, es el hecho de que las solicitudes provienen de diferentes equipos, por lo cual un bloqueo por número IP no sería muy efectivo. 


Esta técnica de Distributed Brute Force Attack (DBFA) ha resultado muy eficiente en los últimos meses y han sido muchos los sitios a los que se les han violado sus servicios FTP, con el fin de conseguir plataformas de lanzamiento para ubicar los sitios falsos para ataques de phishing o pharming (entre otros tipos de ataques).


Esto demuestra que ningún sitio o aplicación web está a salvo de ser atacada, ya que si el ataque no se efectua directamente a la aplicación, el sitio puede ser utilizado para ensamblar ataques mayores o más "rentables".


¿Cómo podemos evitar el Distributed Brute Force Attack?
  1. Para empezar nunca es malo tener una contraseña fuerte, sobretodo en estos casos y además de fuerte larga, es decir de al menos unos doce caracteres, con todas las características de una buena contraseña que todos ya sabemos (caracteres especiales, números, mayúsculas y minúsculas...) Si quiere verificar que tan segura es su contraseña puede utilizar el verificador de contraseñas de Microsoft 
  2. Desactivar los protocolos FTP y SSH si no se están usando. No es necesario tener un servidor a la escucha permanentemente, si tenemos la posibilidad de desactivarlo y activarlo nuevamente cuando lo necesitemos. En el caso de los servidores dedicados, simplemente hay que apagar y encender el servicio cuando lo necesitemos. Es absurdo tener el servicio activo si apenas lo usamos una vez cada dos o tres meses. En el caso del hospedaje compartido, siempre tenemos la opción de apagar y encender el servicio FTP desde el panel de control.
  3. Controlar crecimientos inapropiados en el archivo de logs del servicio FTP. Lógicamente esta opción no está a la mano para aquellas aplicaciones web en servicios de hospedaje compartido, ya que el archivo de logs FTP solo puede ser visto por el administrador del servidor.
  4. Limitar el número de conexiones concurrentes de FTP y SSH en el servidor, pero sobretodo eliminar la posibilidad de conexiones ilimitadas. La cantidad máxima de conexiones simultáneas deberá ser calculada en relación a las necesidades del servicio. A menor cantidad de conexiones simultaneas permitidas el tiempo para lograr descubrir el password de acceso será exponencialmente mayor.
  5. Ubicar el servicio FTP o SSH en un puerto no convencional (ejemplo 2121).
  6. Evitar el escaneo de puertos por medio de un firewall. Si no hay servicio FTP visible simplemente no hay victima.
  7. Si es posible, restringir la máscara de números IP con acceso al servicio FTP o al SSH.
  8. Y como siempre, cambiar la contraseña cada tanto. Cambiarla cada 3 a 4 meses es suficiente. Pero lo más importante, no usar la misma para todos los servicios FTP a los que tenemos acceso.
Como verás algunas de las anteriores soluciones anteriores no son aplicables en todos los casos, pero el uso de al menos tres de ellas será suficiente respaldo para la gran mayoría de los casos.

Sin embargo, a medida que este tipo de ataques se hace más efectivo, el problema que se plantea es que pudiera ser utilizado también para transgredir aplicaciones web transaccionales o de banca en línea. Sin embargo un sistema de banca en línea que se respete, debe por lo menos bloquear los IPs de los sistemas que intenten acceder erróneamente más de un número determinado de veces. Sin embargo aunque parezca obvio, he podido comprobar que algunos de estos sistema si bien no son la mayoría, no tienen este tipo de control.

Hasta la próxima...

18 de octubre de 2010

Seguridad Web y Google: Gruyere

Es imposible pensar que Google podía faltar a la cita que tiene con todos los programadores a nivel mundial en lo referente a publicar algún tipo de documento para educar a los mismos en el proceso de generación de código seguro.

Pero Google no se conformó con hacer alguno que otro documento, sino creó toda una serie de cursos especializados en seguridad web en lo que se conoce como Google Code University , desarrollando toda una sección de cursos acerca de seguridad web a los que puedes acceder en http://code.google.com/edu/security/index.html

Una aplicación llena de agujeros
Entre estos cursos aparece una muy interesante aplicación llamada Gruyere hecha especialmente para que los programadores puedan aprender cómo son realizados los ataques  las aplicaciones y tomar las medidas pertinentes en su propio código.

Claro, ya se que algunos de ustedes dirán que han utilizado el  proyecto WebGoat de OWASP (Open Wen Application Security Proyect) a la que nos hemos referido en otros artículos pero este caso es algo diferente.
La diferencia primordial entre WebGoat y Gruyere, es que el segundo no necesita ser instalado en un equipo, ya que se puede ejecutar en línea sin necesidad de instalar la aplicación y ponerla en marcha, lo que es para muchos usuarios una ventaja, aunque para otros pudiera ser una limitación. 

La segunda diferencia es que WebGoat está desarrollada en JSP y Java bajo Tomcat, mientras Gruyere está hecha en Python. Esta puede ser una importante diferencia a la hora de tomar una decisión.

Sin embargo en ambos casos el lenguaje en que han sido desarrolladas no es lo importante a menos que quisiéramos ver el código de "como no debemos hacerlo", lo importante es su capacidad de explicarnos paso a paso como los errores o descuidos que comúnmente cometemos a la hora de programar pueden convertirse en nuestro peor enemigo.

Me gustó mucho la forma en que Gruyere explica el procedimiento del XSS en sus varias versiones aunque debo reconocer que WebGoat me pareció más completa y su interfaz es quizás más trabajada (posee incluso un instalador para Windows ). Sin embargo, la capacidad de que la aplicación pueda ser vulnerada directamente en línea le otorga a Gruyere un extra que no posee WebGoat. No se preocupen, la aplicación puede resetearse y además corre en un proceso de "sandbox" que no permite que puedan afectar a otros usuarios mientras ustedes cometen errores y dan sus primeros pasos, ya que cada usuario está ejecutando una copia personal.

Google al igual que OWASP no solo ha desarrollado esta aplicación sino muchas plantillas, presentaciones y otros tipos de material didáctico que valen la pena ser leidos, por lo que les recomiendo que visiten  http://code.google.com/edu/security/index.html y se pongan al tanto con lo que Google tiene que decirnos en cuanto a seguridad web, cuyo equipo seguramente algo de experiencia debe tener en el tema. ¿Cierto? ;)

Hasta la próxima!

Entradas populares