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