In our last post, we started digging into ways attackers target standard web servers, protocols, and common pages to impact application availability. These kinds of attacks are at the surface level and low-hanging fruit because they can be executed via widely available tools wielded by unsophisticated attackers. If you think of a web application as an onion, there always seems to be another layer you can peel back to expose additional attack surface.

The next layer we will evaluate is the underlying application stack used to build the application. One of the great things about web applications is the availability of fully assembled technology stacks, making it trivial to roll out the infrastructure to support a wide variety of applications. But anything widely available inevitably becomes an attack target. The best example of this within the context of an availability attack is how hash tables can be exploited to crush web servers.

Hash Collision Attacks

We won’t get into advanced programming but you need some context to understand this attack. A hash table is used to map specific keys to values by assigning the value of the key to a specific slot in an array. This provides a very fast way to search for things. On the downside, multiple values may end up in the same slot, which creates a hash collision that needs to be dealt with by the application, requiring significant additional processing. Hash collisions are normally minimized, so the speed trade-off is usually worthwhile.

But if an attacker understands the hashing function used by the application they can cause excessive hash collisions. This requires the application to compensate and consume extra resources to manage the hashing function. If enough hash collisions occur… you guessed it: the application can’t handle the workload and goes down.

This attack was weaponized as HashDoS, an attack tool that leverages the fact that most web application stacks use the same hashing algorithm within their dictionary tables. With knowledge of this hashing algorithm, the attacker can send a POST request with many variables to create hash table chaos and render the application useless. Mitigation for this attack requires the ability to discard messages with too many variables – typically implemented within a WAF (web application firewall) – or to randomize the hash function using application-layer logic. A good explanation of this attack using cats explains HashDoS in layperson’s terms.

Remember that any capabilities within the application stack can be exploited, and given the open source nature of these stacks probably will. So diligence in selection of a stack, ensuring secure implementation, and tracking security notices and implementing patches are all critical to ensure application security and availability.

Targeting the Database

As part of the application stack, databases tend to get overlooked as a denial of service attack target. Many attackers try to extract the data in the database and then exfiltrate it, so knocking down the database would be counter-productive. But when the mission is to impact application availability or to use a DoS as cover for exfiltration, the database can be a soft target – because in some way, shape, or form, the web application depends on the database.

If you recall our Defending Against Denial of Service Attacks paper, we broke DoS attacks into network-based volumetric attacks and application-layer attacks. The issue with databases is that they can be attacked using both tactics. Application servers connect to the database using some kind of network, so a volume attack on that network segment can impact database availability. If the database itself is exploited, the application is also likely to go down. Either way the application is out of business.

Database DoS Attacks

If we dig a little deeper into the attacks, we find that one path is to crush databases using deliberately wasteful queries. Other attacks target simple vulnerabilities that have never been patched, mostly because the need for continuous database uptime interferes with patching, so that it happens sporadically or not at all. Again, you don’t need to be a brain surgeon to knock a web application offline. Here are some of the attack categories:

1. Abuse of Functions: This type of attack is similar to the slow HTTP attacks mentioned in the last post – attackers use database functionality against you. For example, if you restrict failed logins, they may blast your database with bad password requests to lock legitimate users (or applications) out. Another example involves the attackers taking advantage of database autoscaling, blast it with requests until so many instances are running that the database falls over.
2. Complex Queries: If the attacker gives the database too much work to do, it will fall over. There are many techniques, including nested queries & recursion, Cartesian joins, and the in operator, which can overwhelm the database. The attacker would need to be able to inject a SQL query into the database directly or from within the application for this to work, so you can block these attacks that way. We will talk about defenses below.
3. Bugs and Defects: In these cases the attacker is targeting a known database vulnerability. This includes queries of death and buffer overflow to take down the database. With new functionality being introduced constantly, database attack surface continues to grow. And even if the database vendor identifies the issue and produces a patch (not a sure thing), finding a maintenance window to patch remains challenging in many operational environments.
4. Application Usage: Finally, the way the application uses the database can be gamed to cause an outage. The best example of this is SQL injection, but that attack is rarely used to knock over databases. Also consider the login and store locator page attacks we mentioned in the last post, as well as shopping cart and search engine attacks (to be covered later) as additional examples of application misuse that can impact availability.

Database DoS Defenses

The tactics used to defend against database denial of service attacks really reflect good database security practices. Go figure.

• Configuration: Strong database configuration processes entail removing unneeded functions, user accounts, protocols, and services. You will be best served by minimizing database attack surface as a matter of practice.
• Resource Limits: You can limit the database resources that any specific user, process, or query can consume to blunt an attack. Unfortunately resource limits can be also used against you by starving legitimate users and queries, so this defense is a double-edged sword.
• Patching: As mentioned above, the only way to fix database bugs and defects is through vendor-issued patches. Given that enterprises tend to patch only every 14 months or so, even if the patch is available, that doesn’t mean you are protected from the attack yet. We understand the need for maximum uptime and small operational availability windows, but if the database is knocked down via a known vulnerability everyone loses – except the attacker.
• Database Activity Monitoring: Combining a number of functions, including configuration checking and SQL query monitoring, DAM devices scrutinize every request and can alert on database misuse. But an alert is not very useful when your database is under attack, so to defend against DoS you will want to configure DAM devices to block clear attacks.
• Database Firewalls: Similar to a network firewall, a database firewall only allows authorized queries to reach the database, thus blocking many attacks. If you can reliably profile authorized queries this approach makes a lot of sense. But that’s harder than it sounds, given the rapid change inherent to many web applications.
• Web Application Firewalls: WAF devices are more generic than database firewalls, focusing on authorized application functionality and blocking known attacks, but they offer a similar function, indirectly protecting databases from attack. To be clear, a WAF is ineffective against attacks that involve misusing legitimate database or application functionality.
• Application and Database Hardening: Another option is to protect the application stack from misuse by building protections directly into the application code, including the logic used to access the database. We will discuss this later in detail.
• Website Protection Services: Finally, keep in mind that many website protection services offer WAF-like functionality and can block or slow down application attacks that impact the database.

For more detail on these kinds of database-centric attacks (and appropriate counter-measures), see our Dealing with Database Denial of Service paper.

Tomorrow we will tackle how attackers abuse application logic in our next two posts.