DoS producido por fallas de la Aplicación (Application Failure DoS)

Uno de los métodos más eficientes de bloquear o conseguir que una aplicación quede fuera de servicio, consiste en ubicar fallas comunes de aplicación que ejecutadas repetitivamente dejen a la aplicación y/o al servidor de la misma sin los suficientes recursos como para seguir prestando el servicio a sus usuarios.

A continuación enumeraremos y daremos una breve explicaciçon de las variantes de este tipo de ataque y la falla de programación en la que se basan para causar el daño perseguido por el atacante.

SQL wildcard attack:
Se basan en consultas que consumen gran cantidad de recursos del servidor SQL del que se alimenta la aplicaión, creando consultas con "wilcards" disponibles en las sentencias LIKE. Unos de los servidores más vulnerables a este tipo de ataque es el MSSQL debido a que posee unos tipos de caracteres wildcard muy potentes (%,[],[^],_).

Una consulta como:

SELECT * FROM Article WHERE Content LIKE '%foo%'

puede ser resuelta en una tabla con unos 10000 registros en menos de un segundo, mientras que la siguiente consulta puede amarrar al CPU hasta por 6 segundos en una tabla de apenas 2500 registros:

SELECT TOP 10 * FROM Article
WHERE Content LIKE
'%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'

DoS Locking Customer Accounts (DoS mediante bloqueo de cuentas de usuario):
Muchas aplicaciones bloquean al usuario si este o un atacante que se trate de hacer pasar por él cometen errores en la validación por más de un número determinado de veces. Este tipo de ataques convierte este mecanismo en un arma de negación de servicio creando intentos de ingreso con identificadores de usuarios conocidos.

DoS Buffer Overflow (DoS mediante desbordamiento del buffer):
Intentan generar errores de Buffer Overflow en las rutinas que solicitan datos, convirtiéndose en un arma que no permita que dichas rutinas completen su ciclo y liberen los recursos solicitados antes de que dicho error aparezca. El Buffer Overflow se genera cuando el atacante logra introducir datos en campos no suficientemente bien validados, que superan la capacidad del contenedor o variable creada para contenerlos. Por ejemplo si una variable se declara como entero simple de 16 bits, no podrá soportar que el atacante introduzca en un campo sin validar un número de 7 cifras.

DoS User Specified Object Allocation (DoS mediante creación de recursos específicos por el usuario):
Sucede cuando un usuario puede solicitar múltiples copias de un determinado objeto sin límite superior, lo que es utilizado para consumir toda la memoria asignada a la aplicación. Por ejemplo, si un usuario solicita un acceso a un determinado recurso que se guarda temporalmnete en una variable de sesión sin que exista un límite para la cantidad de veces que pueda hacerlo.

User Input as a Loop Counter (Utilizar el input de usuario como contador de bucles):
Se produce al forzar a la aplicación a entrar de forma repetitiva en un bucle de código que consuma gran cantidad de recursos. Se genera cuando se utiliza un parámetro que provee el usuario, como contador de un bucle y este es forjado por el atacante para aumentar radicalmente el numero de interacciones del bucle de código. Un ejemplo práctico puede ser un parámetro utilizado como contador de un sistema de paginación que se reciba por el URL. Si el atacante lo modifica podría lograr que en vez de mostrar una cantidad limitada de datos se muestre el contenido completo de una determinada consulta. Este ataque puede ser utilizado en conjunto con el SQL wildcard Attack.

Writing User Provided Data to Disk (Escribir datos que provee el usuario a disco):
Este tipo de ataque obliga al servidor a quedar sin suficiente espacio en disco, escribiendo datos provistos por el usuario, o llenado los archivos de logs.
Por ejemplo, uno de los problemas de un ataque por fuerza bruta que guarda los intentos fallidos en un archivo de registro, es que aunque no logre dar con la clave de acceso de un determinado sistema, puede dejar sin espacio en disco al servidor, debido a que el archivo de registro puede alcanzar un tamaño insospechado. Los formularios públicos que guardan datos en disco, deben ser controlados para que no puedan ser llenados por BOTs (sistemas de llenado automáticos) ya que pudieran agregar millones de datos basura al disco.

DoS Failure to Release Resources (DoS por fallas al liberar recursos):
Se debe a fallas del programador o del entorno en liberar eficientemente los recursos utilizados por la aplicación. Suele suceder con frecuencia al no liberar conexiones y sets de registros de bases de datos. Esta falla es muy simple de descubrir aunque no lo parezca, a veces el hacker todo lo que necesita es utilizar una herramienta de escaneo de vulnerabilidades para darse cuenta que los requerimientos excesivos de un recurso o página determinada al servidor lo hacen cada vez más lentos.

Storing too Much Data in Session (Guardar demasiados datos en sesión):
Sucede cuando 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.

OWASP Appsec Serie de Tutoriales - Episodio 3: Cross Site Scripting (XSS)

Ya acaba de ser publicado el tercer episodio de OWASP Appsec Tutorial Series que trata específicamente acerca de XSS o mejor conocido como Cross Site Scripting. No dejes de verlo es muy interesante y sencillo de entender.



Hasta la próxima...

¿Por qué el "login" o identificador de usuario es usado como un campo clave?

Hace unos tres años tuve una pequeña controversia con un ingeniero de una empresa a la que prestabamos nuestros servicios, simplemente porque él consideró un exabrupto el hecho de que yo le propusiera que usara un campo clave diferente al identificador de usuario convencionalmente conocido como "login" en la tabla de los usuarios de su aplicación web. No fué ese el único caso en el que sentí que las personas a quienes proporcioné dicho consejo lo tomaron como una locura por no decir algo peor.

Pero póngamonos a reflexionar un instante: En la actualidad todos los sistemas de manejo de bases de datos relacionales (MySQL, PostgreSQL, MSSQL, PL-SQL y otros) manejan tipos de campos de identificación de registros que se generan automáticamente de forma más que eficiente y que en muchos casos suelen ser utilizados como los connocidos IDs (Id_user por ejemplo). Estos pueden contener hashes únicos, ser campos autonuméricos secuenciales o simplemente identificadores aleatorios a gusto del programador.

El campo comunmente conocido como "login" si bien tiene que ser demostradamente único para un determinado usuario no necesita ser utilizado para identificar un determinado registro de usuario en un grupo de tablas relacionadas. Existen muchos otros identificadores más sólidos y fiables como por ejemplo el número del documento de identidad del usuario o simplemente un campo clave autogenerado.

Aclaremos, no hablo de eliminar el identificador de usuario de los procesos de validación de ingreso, lo que estoy proponiendo es que este campo no sea utilizado como campo clave del registro ya que esto último es una limitación seria de seguridad en la mayoría de los casos, ya que al ser un campo clave relacionado con otras tablas y procesos, no podremos cambiar su contenido.

Todos aquellos que hemos hecho alguna vez un sistema de control de acceso, sabemos que ciertas rutinas como aquellas de recuperación y cambio de clave de acceso son ciertamente parte obligada de dichos sistemas, debido a que bajo un concepto de seguridad obsoleto, el campo correspondiente a la clave de acceso soporta todo el peso de la seguridad del proceso de validación de ingreso. Esto puede variar, si permitimos que también pueda ser cambiado el campo correspondiente al identificador del usuario.

Imaginemos el ejemplo típico en que una persona en una empresa detecta el "login" del administrador o gerente de la misma en una interfaz de acceso de un programa o aplicación de banca en línea. Para poder penetrar en la aplicación solo necesita conocer el password. Imaginemos también que este segundo dato es obtenido mediante cualquier proceso de hacking o ingeniería social de los tantos existentes y que el gerente de la empresa se percata o sospecha que alguien ha utilizado sus datos de acceso. El paso siguiente será cambiar la clave para tratar de que el atacante no pueda ingresar nuevamente. Sin embargo si no conoce el proceso por el cuál su clave ha sido vulnerada (vector de ataque) lo más probable es que en poco tiempo el atacante pueda nuevamente conocer dicha clave y entrar nuevamente en la aplicación.

Sin embargo otra cosa sería que el atacante tenga nuevamente que descubrir dos campos, ya que en nuestra aplicación hemos permitido (verificando que no puedan existir duplicados) que el usuario pueda cambiar no solo la clave de acceso sino también el identificador de usuario. Haciendo esto reducimos la presión sobre el campo de la clave de acceso y repartimos algo mejor la responsabilidad de ingreso en ambos campos. También aumentamos radicalmente el tiempo necesario para adivinar los datos por fuerza bruta. No tendremos que controlar demasiado la longitud de dicho campo ya que no se repetirá su contenido en otras tablas, pudiendo permitir inclusive logins en forma de frases. Identificadores de acceso como "El mejor usuario que ha tenido este banco" no deberían extrañarnos y serían mucho más difíciles de adivinar.

Los hackers me han enseñado que si uno quiere saber el login o identificador de un usuario, en el 50% de las veces basta con saber la parte anterior al arroba (@) en su dirección de e-mail principal. Permitiendo o exigiendo cambiar el identificador en un caso de sospecha de intrusión la seguridad del sistema de ingreso aumentará radicalmente y esta premisa dejaría de ser cierta.

De todas  formas aclaro que tampoco es muy sano tener solamente dos factores de autentificación en un sistema de acceso, pero mucho menos lo es que uno de esos dos factores sea prácticamente público y permanente. Actualmente los factores de autentificación solicitados por empresas de certificación y de regulación están en el orden de cuatro o cinco incluyendo un factor externo a la aplicación. Sin embargo eso es tema para otro artículo.

Hasta la próxima!