In the last post we started digging into the ways attackers target standard web servers, protocols, and common pages to impact application availability. These kinds of attacks are surface level and really low hanging fruit because they can be executed via widely available tools wielded by unsophisticated attackers. If you think of a web application like an onion, there always seems to be another layer you can peel back to expose additional attack surface.
The next layer we’ll evaluate is the underlying application stack used to build the application. One of the great things about web application is the availability of fully assembled technology stacks making it trivial to roll out the infrastructure to support the application. Yet, anything that is 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 a web server.
Hash Collision Attacks
Not to get into advanced programming, but you do need some context to understand this specific 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 within the applications. 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. All other things being equal, hash collisions are minimal in most situations, so the trade-off for speed is usually worth it.
Yet, in a situation where an attacker understands the hashing function used by the application, they can cause excessive hash collisions. This requires the application to compensate and use 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 its dictionary tables. With the knowledge of this hashing algorithm, the attacker can send a POST message with many variables creating hash table chaos and rendering the application useless. The 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 helps to explain HashDoS in layperson’s terms.
Remember that any capabilities within the application stack can be exploited, and given the open source nature of the stacks — probably will. Thus diligence in the selection of the stack and ensuring proper implementation of the capabilities, as well as tracking security notices and implementing patches is 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 look to extract the data in the database and then exfiltrate it, so knocking down the database is counter-productive. But in the case when the mission is to impact application availability or to use a DoS as air cover to hide exfiltration, the database can serve as a soft target because in some way, shape or form the web application is dependent on the database.
If you recall back to the 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 with both tactics. Since the application servers connect to the database using some kind of network, a volume attack on that network segment can impact database availability. Likewise the database itself is exploited, the database can also go down. Either way the application is out of business.
The Database DoS Attacks
If we dig a little deeper into the attacks, what you’ll find one path is to crush the databases using horribly (intentionally) inefficient queries. Other attacks target simple vulnerabilities that have never been patched, mostly because of the need for continuous uptime on the database patching gets done sporadically or not at all. Again, you don’t need to be a brain surgeon to knock a web application offline. Here are some logical categories of attacks:
Abuse of Functions: This type of attack is similar to the Slow HTTP attacks mentioned in the last post in that attackers use the functionality of the database against you. For example, if you restrict failed logins, they may blast the database with bad password requests and lock legitimate users (or applications) out. Another example involves the attackers taking advantage of a database auto-scaling capability to blast it with requests until so many instances are running the database falls over.
Complex Queries: If the attacker gives the database too much work to do, it’ll fall over. There are many techniques, including nested queries & recursion, Cartesian joins, and the IN operator, which can result in overwhelming the database. To be clear, 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. But we’ll talk about defenses below.
Bugs and Defects: In this case, the attacker is targeting a known vulnerability in the database. This can include a query of death or buffer overflow to take down the database. With new functionality constantly being introduced, the attack surface of the database will perpetually expand. And even if the database vendor identifies the issue and produces a patch (which is not a sure thing), finding a maintenance window to commit the patch remains challenging in many operational environments.
Application Usage: Finally, the way the application uses the database can be gamed resulting in an outage. The best example of this is SQL Injection, but that attack is rarely used to knock over a database. 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 result in impacted 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 DB configuration processes involve removing unneeded functions, user accounts, protocols, and services. You’ll be best served by minimizing the attack surface on the database as a matter of practice.
Resource Limits: You can also limit the database resources any specific user, process, or query can consume as a means to blunt the force of an attack. Unfortunately resource limits can be 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 patching patch only every 14 months or so, even if the patch is available that doesn’t mean you’ll be protected from the attack. 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, the DAM devices scrutinize every request and can alert on database misuse. Although an alert is not very useful when your database is under attack, so to defend against a DoS you’ll want to configure the DAM devices to block on clear attack queries.
Database Firewalls: Similar to a network firewall, the database firewall only allows authorized queries to reach the database, 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 a database firewall, focusing on authorized application functionality and blocking known attacks, but can provide a similar function of indirectly protecting the database 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’ll discuss this later in the series in more 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), you can read our Dealing with Database Denial of Service paper.
As we continue the series tomorrow, we’ll tackle how attackers are abusing application logic in the next two posts.
- Mike Rothman
(0) Comments
Subscribe to our daily email digest