A brief talk on JavaScript-based DDoS attacks

CloudFlare the oldest and most common attack against non-DDoS attacks by protecting millions of websites. In traditional DDoS attacks, attackers control a large number of puppet machines and then send a large number of requests to the target server to prevent legitimate users from accessing the site.

However, DDoS attacks have been evolving in recent years: attackers tricked users into attacking activities in a new and interesting way. Last year CloudFlare witnessed an attack using NTP mapping, possibly the largest attack in the history of DDoS attacks (greater than 400Gbps).

This year's DDoS attacks have also seen a new trend: using malicious JavaScript to trick users into DDoS attacks.

The consequences of NTP or DNS mapping attacks are limited by the number of puppet servers, while attack traffic is limited by the capacity of the puppet server. Over time, the server is constantly updating patches, and the number of servers that can be exploited by attackers is declining. JavaScript-based DDoS attacks have an unusual feature: any browser-equipped device is likely to participate in an attack with a potential attack size that is nearly limitless.

The principle of DDoS attack based on JavaScript

The interaction of modern web sites is mostly based on JavaScript. JavaScript scripts can be injected directly into HTML, or by

function imgflood () {
  var TARGET = ‘victim-website.com’
  var URI = ‘/index.php?’
  var pic = new Image ()
  var rand = Math.floor (Math.random () * 1000)
  pic.src = ‘http: //‘ + TARGET + URI + rand + ‘= val’
}
setInterval (imgflood, 10)
The script will generate a picture button on the target webpage, and the picture button will point to the "victim-website.com" website. As long as the user visits the web page containing the script, he will become a member of the "victim-website.com" DDoS attack. Every request issued by the browser is a valid request, so the attack becomes a Layer 7 attack again.

FreeBuf Encyclopedia: Application Layer Attack

Attackers send a large number of data packets or use vulnerabilities in server applications, etc. to saturate server resources and cause DDOS attacks. Such vulnerabilities often do not require a large number of broilers. Examples of application-level DDOS attacks include vulnerabilities such as Slowloris, Apache, Windwos, and OpenBSD. If the ModSecurity null pointer indirectly references the remote denial of service vulnerability (CVE-2013-2765), an attacker could use the vulnerability to crash the Apache web server.

If an attacker embeds a malicious JavaScript script in a website, then every visitor to the website will become a member of the DDoS attack. Higher website traffic means more serious DDoS.

Invade third-party servers that share JavaScript

Many websites use common JavaScript libraries. In order to save bandwidth and improve performance, JavaScript scripts are usually shared on third-party servers. That is to say, if the website contains a script tag pointing to a third-party server, it means that all users who visit the website will automatically download and execute the JavaScript script. Unfortunately, if an attacker invades the third-party server and injects DDoS attack code in the JavaScript script, then the result can be imagined, and all visitors will also become a member of the DDoS attack.

This form of intrusion occurred in jQuery in September 2014.

Introduction to Sub-Resource Integrity

Attacking by replacing JavaScript on a third-party server is actually an older attack method. At present, HTTP has no relevant mechanism to prevent the script from running, but the W3C has proposed a new feature called Sub-Resource Integrity (SRI), which uses encrypted hash values to verify the script. If the hash value does not match the browser, it can be blocked. Its running.

For example, the following script tag:

<script src = "https://code.jquery.com/jquery-1.10.2.min.js">
The browser will automatically download the .js file and run it indiscriminately. Even if a malicious script is injected into the file by the attacker, the browser will not recognize it. However, if the website finds that the hash value verification script does not match, the sub-resource integrity (SRI) will tell the browser not to run the script.

<script src = "https://code.jquery.com/jquery-1.10.2.min.js"
        integrity = "sha256-C6CB9UYIS9UJeqinPHWTHVqh / E1uhG5Twh + Y5qFQmYg ="
         crossorigin = "anonymous">
It is recommended that site administrators add this tag to the server to protect their users from being used.

Currently, the only browsers that support sub-resource integrity are Chrome and Firefox.

Man in the middle attack

The middleman between the browser and the server can modify the data at will, including changing HTML content or JavaScript scripts. And if the man-in-the-middle goes awry and does something malicious, such as adding malicious JavaScript to the page and executing it, the consequences are just as serious (also known as a man-in-the-middle attack).

Modifying the website during transmission is a unique technology for ISPs and WiFi providers, but if an attacker gains this permission, they will replace the script during the transmission with a malicious JavaScript script. What's more, if the DDoS script is included in the JavaScript script, the members of the DDoS attack will be further expanded.

The situation can be even worse. If the transmission path of the JavaScript file happens to pass through the attacker's network, the number of browsers and users participating in the DDoS attack will be staggering.

Summary: defense

JavaScript-based DDOS attacks are becoming more frequent, and the only way to defend against this attack is to fully enable HTTPS.

Talking about DDOS attack based on JavaScript