As 2018 is on its way out, we reflect on the plethora of massive hacks resulting in endless concern for SMBs & enterprise security professionals as well as the necessary budgetary spend to mitigate and proactively defend against malicious actors. Yes, there’s been a shift in malicious actors’ attack vectors and you are, once again, forced to devote time that you don’t have to address it.
Cisco’s report identifies a concerning shift into more advanced DDoS (Distributed Denial-of-Service) attacks. The DDoS attack vector has been around for decades and has evolved into is a popular inexpensive attack vector for malicious actors. The size, scope and sophistication of these attacks continue to grow at an alarming rate with recent DDoS attacks exceeding one tera byte per second because malicious actors can easily amplify efficacy by purchasing DDoS kits or employing someone to carry out this malicious activity through massive botnets. Generally, DDoS attacks are aimed at large enterprise networks and solely focused on the network stacks' third and fourth layers. However, the alarming shift identified by Cisco this year has been from Layer 3 & 4 DDoS attacks to a totally a more sophisticated DDoS called Application-Layer DDoS attack, which is also known as a Layer 7 DDoS. These attack vectors are hard to detect and even harder to protect against because they tend to be smaller than typical Layer 3 & 4 DDoS attacks and often go unnoticed until it’s too late. Layer 7 DDoS attacks are often referred to as “slow-rate” or “low and slow” attacks, meaning they target applications in a way that they look like actual requests from users until applications become inundated with requests and can no longer respond. In fact, you may even fail to notice an attack until after your front-end application resources are brought offline and connected back-end systems are compromised and/or damaged.
How Does This Affect My SMB?
Layer 3 & 4 DDoS attacks sounds like the stuff that large enterprise networks have to deal with, right? Well...The underlying effectiveness of a DDoS attack comes from the disparity between the amount of resources it takes to launch an attack relative to the amount of resources it takes to absorb or mitigate one. While this is still the case with Layer 7 DDoS attacks, this particular attack does more damage with exponentially less bandwidth. When a user sends a request to into its Gmail account, the amount of data and resources the user’s computer must utilize are minimal and disproportionate to the amount of resources consumed in the process of checking login credentials, loading the relevant user data from a database, and then sending back a response containing the requested webpage. Even in the event of a failed login, a front end application must make database queries or other API calls in order to produce an error webpage. When this disparity is magnified by a botnet targeting a single web application, the effect can easily overwhelm it, resulting in denial-of-service to legitimate traffic.
Sure Eric, you think, I don’t have to worry about numerology and multiple layers except when I am skiing or snow-shoveling (preferably skiiing) because I don’t have a large enterprise network...why does this matter? Layer 7 DDoS attacks have shifted focus to SMBs because of their effectiveness; SMBs don’t have the resources to absorb or mitigate an attack so effectiveness is higher and a successful compromise is equally profitable. Another reason is the proliferation of Mirai variants. Mirai, malware that turns Linux based hosts into remotely controlled "bots" to use within a massive botnet, was originally used by malicious actors to perform Layer 2 and 3 DDoS attacks. Variants of Mirai have fueled DDoS attacks, including a 54-hour barrage against a U.S. college, and aimed squarely at Layer 7.
Attack Vector
Since your website, other customer facing applications, and supporting back end resources systems are open interface with users across the globe, they are key targets of Layer 7 DDoS attacks devised to affect the way in which the different systems interoperate. With the development of applications continuing to shift to the cloud, the application layer DDoS attack vector is becoming increasingly more difficult to defend against and mitigate.
With Layer 3 & 4 DDoS attacks, you focus on preserving your network’s bandwidth capacity and identifying network spikes and throttling; the ability to mitigate this type of attack always come down to 1 simple question: who has more network capacity, the attacker or the mitigation service? Successful defense and mitigation of Layer 7 DDoS attacks rely on the ability to accurately profile incoming traffic – to distinguish between humans, bots and hijacked web browsers. As a result, the defense and mitigation processes are much more complex than the attack itself.
Unless a malicious actor(s) has a vendetta against your SMB, a Layer 7 DDoS attack is just the tip of the iceberg. This attack vector is commonly a means to an end, setting the stage for more traditional attack vectors (e.g., exploiting known vulnerabilities, cross site scripting and SQL injection). In this typical scenario, malicious actors use a Layer 7 DDoS to weaken defenses or crash security resources, enabling them to gain access to your network and steal sensitive data for profit.
XSS (Cross-site Scripting)
Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into trusted websites. This attack vector is through using a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user without validating or encoding it. Yes, your web application is susceptible to malicious activity wherever it receives input from a visitor so any user forms, checkout carts, etc. An attacker uses XSS to send a malicious script or series of instructions to an unsuspecting victim. This particular Layer 7 attack vector is successful in acquiring a victim’s cookies, session tokens, or other sensitive information retained by the browser and used with that site. They can even rewrite the content of a HTML page rendered to a victim.
SQL Injection
The basic idea premise behind the SQL injection attack vector is an attacker manipulates data passed into a web application in order to modify the query that is run on the back-end database. This might seem relatively innocuous at first sight, but it can be extremely damaging. The most concerning aspect of this attack vector is that the basic method to query a database inevitably results in a SQL injection vulnerability. And the most common “fix” is to replace each occurrence of a single-quote character with two single-quote characters, effectively “escaping” the single quotes. This unfortunately does not fix the vulnerability or solve the underlying problem. User input validation is necessary throughout your applications to eliminate the ability for malicious actors to use input fields as proxies to perform malicious SQL queries.
Defense & Mitigation
Defending and mitigating this attack vector centers around your ability to distinguish between legitimate and bot created application requests. This is difficult and resource intensive because a botnet, which for example is performing a HTTP Flood attack against a victim, makes legitimate network requests that are not spoofed and appear “human” in origin. With other variants of this attack vector such as SYN floods or NTP amplification, strategies can be used to drop the network traffic fairly efficiently provided the network itself has the bandwidth to receive them. The common and effective method to distinguish between human activity and botnets is to implement a challenge to the application requestor. This is done through a human interaction test much like the CAPTCHA test commonly, which is commonly found when creating an account online. By issuing that challenge or a requirement such as a JavaScript computational challenge, you can defend your SMB from this attack vector. Other methods to stop this attack vector include the use of a web application firewall and managing and filtering network traffic through an IP reputation database.
In addition to those technological recommendations, below are additional recommendations you should heed:
Eric Hess
Managing Director
HLC LLC
Eric Hess has over fifteen years of experience acting as senior in-house counsel, general counsel or senior management for exchanges, broker dealers, and financial services technology providers. He has a proven track record of meeting business and legal goals, including creating legal, compliance and technology & operational risk management functions, designing compliant trading technology, advocating for regulatory change, closing transactions, navigating challenging issues, managing regulatory inquiries & investigations and facilitating company growth, both organically and through strategic transactions. Specialties: Equities, options, futures and cleared swaps regulation; hedge fund, broker dealer and markets regulation; technology and operations risk management; contract negotiation; technology transactions; regulatory examinations, inquiries & investigations; dispute resolution; corporate governance, mergers & acquisitions; intellectual property; lobbying; and financing transactions. Mr. Hess holds Series 7 and 24 licenses and is admitted to practice in the States of New York and New Jersey.
HLC, LLC is a strategic partner of NCS Regulatory Compliance