Este es el primer artículo de una serie de entradas que se publicarán en este sitio de forma periódica sobre un tema que actualmente se encuentra en constante evolución (y crecimiento), la seguridad en aplicaciones web y pentesting. Se trata de un tema que dada su complejidad y cantidad de información disponible puede abarcar un buen número de entradas (que al momento de escribir este documento no tengo del todo claro), sin embargo intentaré que sea lo más profundo y a la vez fácil de comprender para todo el mundo.

Después esta breve introducción, se procede a comenzar con el contenido propiamente dicho de esta serie de publicaciones.

Problemas con las Aplicaciones Web actuales

Uno de los principales activos de los que dispone cualquier tipo de organización (e incluso una persona) es la información, la forma en la se almacena, organiza y accede a ella es de vital importancia para que los procesos organizativos se lleven a cabo con normalidad y con la mayor eficiencia posible, esto es desde el punto de vista de una organización que busca utilizar la tecnología como un medio para mejorar sus procesos internos o simplemente captar la atención de un mayor público (clientes potenciales en todo el mundo). Sin embargo la “magia” de las aplicaciones web y de Internet, es la facilidad con la que cualquier persona puede acceder a contenidos de su interés, intercambiar ideas, opiniones y adquirir conocimientos, esa ha sido la base de su éxito. Actualmente las organizaciones, pequeños grupos o individuos tienden a la “expansión” gracias a las posibilidades que brinda la tecnología, es así como desde hace un poco más de dos décadas las aplicaciones para internet (en concreto aplicaciones de HyperText) han tenido un crecimiento abismal y la sofisticación con la cual se desarrollan ha mejorado sustancialmente, lo que es directamente proporcional a la complejidad involucrada. Sin embargo, existen dos problemas que son intrínsecos en este escenario:

  1. Las aplicaciones web están disponibles prácticamente a cualquiera, simplemente es necesario una conexión a internet, lo que le brinda a un atacante una posible “puerta” con la que podrá probar muchísimas “combinaciones”, normalmente sin un limite de tiempo establecido y desde cualquier lugar del mundo.

  2. Dada la complejidad involucrada en el desarrollo de aplicaciones web, se alzan una serie de problemas que afectan la escalabilidad, el desempeño y la seguridad de dichas aplicaciones entre los que se incluyen:

    1. Falta de conocimientos y fallos conceptuales sobre las tecnologías utilizadas, lo que en muchas ocasiones termina convirtiéndose en fallos para la seguridad. Cada vez más, se requiere que los programadores inviertan mucho más tiempo en aprender sobre nuevas tecnologías (y técnicas de explotación de las mismas), muchos programadores (habitualmente aquellos con poca motivación y pocas ganas de aprender) no están dispuestos a asumir este esfuerzo lo que conlleva a que por “pereza”, presión por tiempos de entregas y un absoluto desconocimiento, implementen “soluciones” que funcionalmente pueden parecer validas, pero que desde el punto de vista de la seguridad, representan una amenaza que puede ser aprovechada por una persona con suficientes conocimientos.

    2. Procesos de desarrollo poco estructurados y mal planificados que normalmente son medidos por personas sin la cualificación y conocimientos necesarios para definir un proceso de desarrollo y lo que implica. No se puede planificar ni medir un proyecto si no se tiene un conocimiento mínimo sobre el mismo (conocimiento técnico y funcional), algo que por desgracia, en muchas ocasiones es así, encontramos personas que ejercen cargos de responsabilidad que carecen casi por completo de conocimientos técnicos y/o funcionales que son requeridos, esto suele ser lo común, pero lo que es “común” no significa que sea lo adecuado o correcto.

    3. Aplicación inadecuada de metodologías de desarrollo, donde no se tiene en cuenta el factor motivacional indicado anteriormente, lo que conlleva a que “cualquier” solución propuesta por un equipo de desarrollo que “funcione” de acuerdo a lo que la aplicación “debería” hacer sea suficiente para darla por aceptable.

 

Normalmente, un equipo de desarrollo o persona con unos tiempos prudentes, motivada y con ganas de hacer las cosas de la mejor forma posible, siguiendo buenas practicas de programación, tiene la posibilidad de desarrollar aplicaciones estables y con unos buenos niveles de seguridad que podrán las cosas un poco más difíciles a cualquier atacante.

En este orden de ideas, un buen punto de inicio para conocer buenas practicas y técnicas en la planificación, análisis, metodología y desarrollo de una aplicación web puede encontrarse en el proyecto abierto OWASP

 

OWASP PARA DESARROLLADORES Y PENTESTERS

OWASP (Open Web Application Security Project) es un estándar abierto y de libre participación con un amplio reconocimiento a nivel mundial donde se realizan propuestas y se desarrollan proyectos de software y documentación para definir procesos de desarrollo con la seguridad en mente. Sin embargo, este proyecto no solamente se centra en el desarrollo de aplicaciones web, también cuenta con un gran numero de recursos para realizar pruebas de penetración.

En OWASP, existe una serie de principios sobre la seguridad en aplicaciones web que son de gran interés y que sin lugar dudas representa el punto de partida para un pentester o un programador interesado por la seguridad de las aplicaciones que desarrolla. Dichos principios son simplemente algunas practicas que han sido elaboradas durante los últimos años por numerosos expertos involucrados en el sector de seguridad web, donde se indican propiedades, diseños, implementaciones y características que son deseables para intentar reducir el riesgo y el impacto de los ataques realizados por una entidad “malintencionada”. A continuación se intentará explicar estos principios y como afectan (positivamente) al funcionamiento de una aplicación.

 

Defensa en Profundidad

Es altamente recomendable utilizar un modelo de defensa en profundidad, el cual puede resumirse con la frase “no poner todos los huevos en la misma cesta”, con esto lo que se quiere decir, es que no es recomendable utilizar un único mecanismo de seguridad que protege a una aplicación o servidor, dado que si un atacante logra sobrepasar dicha barrera, no existirá nada que se interponga entre él y recursos valiosos almacenados en un servidor. Un ejemplo, es la habilidad que tienen algunos atacantes de evadir sistemas de protección WAF (Web Application Firewall), si este es el único mecanismo de defensa implementado por una aplicación, es posible que un atacante tenga mayores probabilidades de vulnerarla una vez evite los filtros de dicho WAF. Un ejemplo practico que es bastante notorio hoy en día sobre este principio, es el que implementan algunos sitios de banca en internet, los cuales no utilizan un único mecanismo para que sus usuarios puedan autenticarse desde Internet y acceder su cuenta bancaria, algunos utilizan varios filtros, entre los cuales resaltan:

  • Autenticación por medio de dispositivos seguros, como en el caso de España y otros países de la unión europea, el uso del DNI electrónico.

  • Combinando la clave personal de un usuario junto con datos personales como por ejemplo, fecha de nacimiento, documento identificativo, etc.

  • Transferencias utilizando claves diferentes a las empleadas para la autenticación, en algunas entidades financieras se suele utilizar el concepto de “Tarjeta de Coordenadas” que es una tarjeta que contiene una matriz de números que son únicos para cada fila y cada columna. Los valores indicados en esta tarjeta son solicitados por dichos sitios web para autorizar movimientos delicados tales como transferencias de dinero a otras cuentas.

 

Modelo positivo/negativo de Seguridad

Este principio es uno de los más extendidos y seguramente de los que mejor se conoce, se trata del modelo de “whitelist” y “blacklist” en donde se “permite” todo de forma explicita, exceptuando algunas reglas definidas en la lista (blacklist), este se conoce como modelo “negativo” de seguridad, dado que implica cualquier elemento malicioso que no se encuentre en la lista, por defecto se encuentra permitido. En contrapartida se encuentra el modelo positivo de seguridad, el cual es conocido como “whitelist” en el cual todo es denegado por defecto a menos que se encuentre definido de forma explicita en la lista. Este modelo es recomendado y es ampliamente utilizado por diferentes tipos de soluciones relacionadas con la seguridad (las cuales no solamente implican la seguridad en aplicaciones web).

Los beneficios de este modelo saltan a la vista, sin embargo es necesario tener una lista muy bien estructurada y no “bloquear” peticiones que sean legitimas, este trabajo puede ser difícil y requiere un proceso de pruebas muy completo, pero esta comprobado que a mediano y largo plazo, representa un mecanismo de seguridad bastante eficiente.

 

Fallo Seguro

Las aplicaciones pueden fallar por “infinidad” de razones, sin embargo cuando estos errores no se tratan de una forma adecuada, pueden producirse “fugas” de información sensible relacionada con detalles técnicos de la aplicación, por ejemplo algunos servidores web, enseñan el “fingerprint” de la versión del servidor cuando una página falla por un error (errores HTTP 5xx o HTTP 4xx), esta información puede ser útil para el atacante, en el sentido de que ciertas versiones de servidores web cuentan con vulnerabilidades conocidas y que pueden ser aprovechadas de forma remota. Por otro lado, el tratamiento seguro de los fallos que se puedan producir en una aplicación, son especialmente críticos cuando estos se producen durante la ejecución de un filtro o módulo de seguridad, por ejemplo, en el caso de que una excepción se lance durante el proceso de autenticación de un usuario, la situación debe ser claramente identificable por medio de registros de logs u otros mecanismos, además de que el proceso debería dar como resultado un usuario NO autenticado.

 

Ejecución bajo el ultimo privilegio

Se trata de un principio muy importante dado que su violación ha causado una gran cantidad de ataques de “elevación de privilegios local”. Este principio consiste simplemente, en que las operaciones que se lleven a cabo en la aplicación se ejecuten con los privilegios mínimos sin afectar las funcionalidades requeridas por la misma, en este orden de ideas, es necesario entender que los permisos deben de ser asignados de la forma más granular posible, de tal modo que no sobre ni falte ninguno. Esta practica no solamente aplica a las aplicaciones web, es también perfectamente valida para cualquier tipo de aplicación dado que los que se le asignan a un fichero ejecutable pueden ser utilizados por un atacante con suficiente destreza. Por este motivo, es una recomendación muy valida y conocida el crear un usuario con pocos privilegios para iniciar un servidor web (como por ejemplo Apache, que cuenta con algunas directivas pensadas para arrancar con un usuario y un grupo definido)

 

Evitar la seguridad por medio de la “ocultación”

La seguridad por medio de la “ocultación” consiste en ocultar la mayor cantidad posible de detalles técnicos (y en algunos casos, funcionales) al público en general, en realidad se trata de un tema que ha sido muy debatido y tiene sus detractores y benefactores, pero en cualquiera de los casos esta comprobado que la seguridad de un sistema no solamente puede depender de mantener “secretos”, por ejemplo, en muchas ocasiones se suele pensar que el hecho de que el código fuente de un programa no se encuentre disponible al público general lo hace “más seguro” y que en contrapartida, que el código fuente se encuentre abierto representa una “amenaza” dado que pueden existir personas que al estudiarlo y depurarlo, encuentren vulnerabilidades, sin embargo existe un ejemplo práctico de que estas “creencias” no son del todo ciertas: Windows (código cerrado) y Linux (código abierto). IIS (código cerrado), Apache Web Server (código abierto)… Algo más que decir?

Por otro lado, tal como se ha dicho anteriormente, la seguridad por medio de la ocultación, no solamente esta relacionada con la ocultación del código fuente de una aplicación, también se relaciona con la ocultación de cualquier detalle técnico, como por ejemplo el cambio del puerto por defecto de un servicio, cambio del fingerprint de un servidor, mensajes equivocados sobre consultas que intenten recuperar información sensible, etc. Este tipo de medidas menos radicales de ocultación son perfectamente compatibles con otros mecanismos de defensa y en algunos casos, pueden ser recomendables.

Simplicidad

La belleza está en la simplicidad. Cuando un sistema tiene demasiadas capas de procesamiento o demasiadas funcionalidades innecesarias, el número de fallos potenciales sobre la seguridad aumenta exponencialmente. Por otro lado, también es necesario no abusar del principio de “defensa en profundidad” expuesto anteriormente, demasiados mecanismos de seguridad pueden aumentar la complejidad de un sistema a tal punto que las interacciones entre dichos mecanismos pueden verse comprometidas de tal forma que sus “beneficios” se vean completamente menguados ante un ataque correctamente orquestado. Los mecanismos de seguridad deben de ser eficientes y simples, de tal forma que puedan ser mantenidos fácilmente y si es necesario reemplazarlos en un momento determinado, pueda hacerse sin mayores dificultades.

Detección de intrusos

Normalmente es una practica recomendada implementar sistemas de detección y prevención de intrusos con el fin de tener información oportuna cuando un evento relacionado con la seguridad del sistema sea notificado. Existen muchísimas herramientas en el mercado que permiten llevar un registro de estos eventos, entre las que destacan Snort y Suricata, sobre la primera se han escrito algunas publicaciones en este blog, por lo tanto se asume que el lector tiene ciertos conocimientos sobre estos conceptos.

Ver los siguientes enlaces:

 

No confiar completamente en elementos externos a la aplicación

Normalmente las aplicaciones con un alto número de funcionalidades suelen tener interacciones con otros sistemas externos o servicios que se encuentran en ejecución en el servidor. En cualquier caso, no es recomendable confiar “ciegamente” en dichos servicios y/o aplicaciones, los mismos controles de seguridad deben ser establecidos para asegurar que las peticiones y las respuestas son seguras para ambas partes, las políticas de seguridad implementadas para usuarios comunes de la aplicación, deberían ser implementadas de la misma forma que con servicios o aplicaciones externas y en ningún caso se deberían “relajar”.

 

Esta ha sido la primera publicación sobre Web Application Hacking, donde se han definido algunos conceptos básicos que servirán para comprender mucho mejor las “buenas practicas” a la hora de definir entornos seguros sobre entornos web. Tal vez pueda parecer un poco tedioso de leer, sin embargo como profesionales en seguridad informática, es importante tener en cuenta estos conceptos.