If the server component or an app library is not specifically designed to handle various edge cases, the attacker’s input can end up blocking the entire app or server for seconds or minutes at a time, while the server analyzes and pattern-matches the input.
When a ReDoS attack hits, this ends up clogging the entire server, rather than slowing down one particular operation.
ReDoS attacks known since 2012, but gaining momentum
Subsequent research published in 2017 revealed that 5% of the total vulnerabilities found in Node.js libraries and applications were ReDoS vulnerabilities.
Cristian-Alexandru Staicu and Michael Pradel, two academics from the Technical University in Darmstadt, Germany, say they’ve found 25 previously unknown vulnerabilities in popular Node.js modules.
The two said that an attacker could craft special exploit packages and attack websites/servers using any of these 25 libraries.
Sending an exploit packages causes any of the vulnerable websites to freeze between a few seconds to even minutes, as the server is trying to match the text contained within the exploit to a regular expression (regex) pattern in order to decide what to do with the input. Such regex filters on input fields are common, as they are the base of many XSS filters.
But while one attack is bad, sending repeated exploit packages to the same server can cause prolonged downtime periods.
Nearly 340 sites vulnerable to ReDoS attacks
Staicu and Pradel say the primary reason for these flaws is the lack of attention to the performance of regex matching, as most developers seem to be focused on accuracy, leaving big holes in their code that attackers can exploit using ReDoS attacks.
The two also took their research one step further. They devised a method of detecting these vulnerabilities on live websites without actually using the ReDoS exploit code.
They used this method to scan 2,846 popular Node.js-based sites, revealing that 339 —approximately 12%— were vulnerable to at least one ReDoS vulnerabilities.
Some ReDoS issues were patched
The TU Darmstadt research team reported all the vulnerabilities to the respective module developers, some of who addressed the problems. This GitHub repo contains proof-of-concept exploits for testing the vulnerable libraries but also links to the appropriate fixes for the affected modules.