📜 ⬆️ ⬇️

Layer 7 DoS: Web Application Denial of Service Attacks


Distributed denial of service attacks that popular sites typically undergo with thousands and thousands of hacked devices. These attacks are mainly aimed at suppressing the target system with large-scale traffic, clogging the communication channel. These attacks relate to layer 3 (the network layer of the ISO / OSI model) DoS / DDoS and are characterized by a large number of packets with which the resource is attacked. Layer 7 (ISO / OSI model application layer) DoS / DDoS is usually aimed at the weak points of the web application.


To begin with, I’ll give some statistics from the Incapsula research - starting from 2016, the DoS / DDoS attacks at the application level prevail over the classic denial-of-service attacks at the network level:


image

The difficulty in defining such attacks is that a web application cannot easily distinguish an attack from regular traffic. There are many factors that contribute to this difficulty, but one of the most important is that for several reasons IP addresses may not be useful as identification data. In a network attack, it is possible to distinguish illegitimate traffic and block attacking IP addresses; in the case of attacks on the application level, this is difficult to do: it is necessary to determine exactly the attacking signs without blocking legitimate users. Also, the simple use of a resource (without attacks) can lead to the exhaustion of its resources - this can be known here to many Habraeffect.


The main types of DoS / DDoS attacks:


Volumetric: Volumetric attacks target the bandwidth overflow of the hosting infrastructure's web application, directing large amounts of network traffic. Usually such traffic is represented by UDP / ICMP flood.


Layer 3: These attacks target the weaknesses of the TCP protocol stack architecture. The attacker sends packets designed to overflow, distort, or destroy connection state information, causing additional work for network processing functions on the target device and slowing down responses. The most common vectors for such attacks are TCP SYN flood, TCP fragmentation, teardrop, etc.


Layer 7: These attacks are focused on the logic of the web application and are aimed at the exhaustion of web server resources in the processing of "heavy" requests, intensive processing functions or memory.


Application resources


Most web servers can handle several hundred simultaneous users with normal resource usage. The problem is that a single attacker can generate enough traffic from a single host to deny service to a web application. Load balancing in this case does not help with the word "absolutely."


The main problems are as follows: CPU utilization - using 99% of the CPU causes other critical processes to stop; RAM - invalid memory allocation, leaks, memory exhaustion - a disadvantage for other critical processes; processes and threads - deadlock (freezing of processes), forks, race condition; disk - disk overflow.


One of the important resources of a web server is RAM. The attacks on the exhaustion of this resource may be the following:


Recursion Here is a good example of recursive code - include ('current_file.php'). PHP allocates new memory for each inclusion and repeats the process until there is no memory left. This vulnerability can be detected as a classic LFI (local file inclusion).


Zip bombs. Web applications that allow downloading of compressed files and extracting content may be susceptible to such an attack, especially if the application (or library that processes decompression) does not perform proper file checking.


XML bombs. Named entities can be expanded not only in character strings, but also in a sequence of other entities. Recursion is prohibited by the standard, but there are no restrictions on the allowed depth of nesting. This allows you to achieve a compact representation of very long text lines (similar to how archivers do it) and forms the basis of the attack “billion laughs”.


Deserealization. A relatively new type of attack, but quite serious, that is introduced in OWASP TOP 10 2017 A8-Insecure Deserialization. This is the process of restoring the initial state of the data structure from the bit sequence. With inadequate control of user input can lead to resource exhaustion.


File headers The manipulation of file header values ​​may lead to resource exhaustion. If the calculation is performed in the input file, where the file size is in its header. These can be images, video files, documents, etc. Example - pixel flood attack .


Reading infinite data streams. Reading / dev / zero or / dev / urandom via LFI, using 1TB speedtest , etc.


An important parameter of the web server is the CPU, attacks on the exhaustion of processor capacity can lead to the inoperability of the web application.


reDOS - Regular Expression Denial of Service. A relatively new type of attack was first identified on Stackoverflow. It was not an attack by the attacker, but by the actions of a user who included 20,000 whitespace characters in the code snippet. The regular expression was written in such a way that it forced the system to check a string of 20,000 characters for 200.010.000 steps (20,000 + 19,000, + ... + 2 + 1). If the web application allows the use of regular expressions, it is worth checking incoming data carefully.


SQL injection. Using SQL injection can significantly reduce the performance of a web application, especially when using functions like sleep, benchmark, etc.


Fork bombs Processes that are repeated again and again, using all the resources of the system. The most famous is: () {: |: &};:.


Abuse of resources / functions. An attacker can detect a resource-intensive operation on a web application and send a lot of resource exhaustion requests. An example would be the abuse of password hashing functions.


SSRF. Operation of the server side request forgery of vulnerabilities could allow an attacker to exhaust the resources of the attacked web server.


Disk space is also a critical parameter of the web server.


Download large files. The most obvious way to fill the system with data is to upload large files to the server. If the application does not apply the proper restrictions, the attacker can upload data to the system until the web server has exhausted its resources.


System log overflow. In the absence of log rotation functions, an attacker can “clog” the system logs or serve as a catalyst for creating a huge number of these logs, which will lead to the exhaustion of disk space resources.


Utilities for testing web applications:


I will deliberately not consider narrowly specialized utilities such as LOIC / HOIC, aimed, as a rule, at destabilizing the work of certain web applications.


Malicious use of these tools is prohibited and may be prosecuted by the laws of the country where you are a resident. Use these tools to test only your own servers, or servers that are legally agreed with their owner.


Slowloris is a fairly well-known testing utility. There is an nse script for nmap.


HULK (HTTP Unbearable Load King) - generates a large stream of unique requests that maximize the use of web server resources. To complicate the task of filtering the stream, HULK for each request substitutes a different user agent, obfusts the referrer, uses the no-cache and keep-alive attributes, as well as unique URLs.


OWASP DoS HTTP POST is a utility from the OWASP consortium for generating "slow" http requests.


GoldenEye HTTP Denial of Service Tool - exploits HTTP Keep Alive + NoCache vectors.


Preventive measures


A good practice of preventive protection of a web application would be load testing a web resource. To study the response time of the system at high or peak loads, "stress testing" is performed, at which the load generated on the system exceeds the normal usage scenarios.


The main purpose of load testing is to create a certain expected load in the system (for example, through virtual users or their actions) to monitor system performance indicators. This will allow you to identify and strengthen the bottlenecks / weaknesses of your web application and avoid possible risks of application unavailability in the future.


')

Source: https://habr.com/ru/post/347456/


All Articles