DDoS Yourself First – Part II: Rise of the Availability Vulnerabilities

Availability problems aren’t necessarily unique; however the testing is certainly different, as I discussed in Part 1 of DDoS Yourself.

This “availability security problem” is resulting in an increased risk to enterprise’s whose business models are tied to time (government elections, financial trading, online promotional retailers, insurance reconciliations, etc.).

As a result, many organizations are asking themselves if they have adequate visibility to the vulnerabilities they have to hacktivist (ideologically motivated) and Availability-based (competitive motivated) DDoS attacks?

The following are the solid reasons to test your organization for these risks, in order to provide DDoS protection:

1. Validate the strength of your perimeter-protection security to availability attacks.

√Scores of new tools have been released and used lately – do you test for these new releases? Tools such as LOIC, RUDY, RefRef, Slowloris, etc., are not listed on the common vulnerability exposure (CVE) register as they are tools. Yet most companies don’t know if these new ‘weapon systems’ can pierce their current defenses.

2. Improve security of critical architectures.

√Knowing where the holes are in your current architecture allows you to adopt remediation procedures that close them. Radware helps you tighten security by identifying gaps and recommending solutions.

3. Strengthen your response capability for security attacks (e.g. DDoS, Server Cracking, Web Application Attacks, Debilitating Scans, Nefarious Transaction Inputs, etc.).

√By highlighting areas of improvement, you can greatly enhance the quality of event response plans.

4. Increase the effectiveness of security initiatives.

√Can you bring someone to justice if you undergo an attack? Gain valuable insight into your organization’s security posture and ensure the highest levels of readiness.

5. Test your current incident detection methods.

√What are your current methods for monitoring security incidents to ensure your approach is both comprehensive and effective.

High likelihood that “Availability” Vulnerabilities have not been enumerated:

It’s a new dawn and security professionals are waking up to the cold, hard fact that that ‘Availability’ based vulnerabilities remain untested or ruled not meaningful since the inception of routine testing. It’s true that for years, the standard penetration testing and vulnerability assessments did not scope in “Service Disrupting” vulnerabilities as part of the testing regimen. In addition, when, by chance, an Availability based vulnerability was enumerated, the standard assignment of this class of threat was ‘low’ or ‘informational.’

It appears that the nefarious underworld has turned their development efforts towards the sad fact that we have summarily disregarded a whole category of threats because they were either inconvenient to test or the tools themselves were inadequate for measuring these problems.

So, What are “Availability” Vulnerabilities?

To technically assess diagnosis a problem, we must first know what it is.

Should you need a nice definition, read here where I made the case that availability problems are paramount.

My point, which I hope we can all agree, is that information security threats to an organization revolve around the following problems:

• Real-Time Protection against Volumetric Attacks
• Application Protections Against Application Layer (L7) Outages
• Behavioral Protections (e.g., non-signature based) Protecting Critical Servers and Services
• Signature-based (IPS) & Reputation Services Coverage and Quality
• Effectiveness of from existing malware propagation and scanning Protection tools

DDoS threat only? No Way! The rising role of Web Applications in Availability!

Any assessment of an organization’s availability risks would be remiss if they focused only on DDoS threats. Any logical Availability security assessment will determine the appropriateness of role and rights assignments to specific user classes and how these assignments are controlled. Practices such as the following need to be thoroughly reviewed:

• Poor Logging Practices – Many web application logs contain sensitive information such as passwords, session IDs, and other codes. A strong logging design is key to a secure web application.
• Cross-Site Scripting (XSS) Flaws – The web application can be used as a mechanism to transport an attack to an end user’s browser. A successful attack can disclose the end user’s session token, attack the local machine, or spoof content to fool the user.
• Buffer Overflows – Web application components in some languages that do not properly validate input can be crashed and, in some cases, used to take control of a process. These components can include common gateway interfaces (CGI), libraries, drivers, and web application server components.
• Command Injection Flaws – Web applications pass parameters when they access external systems or the local operating system. If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the web application.
• Broken Thread Safety – Web applications are highly concurrent, and thread safety problems can result in significant security issues. Concurrent programming is one of the most difficult aspects of developing secure web applications.
• Web and Application Server Misconfiguration  – Having a strong server configuration standard is critical to a secure web application. These servers have many configuration options that affect security and are not secure out of the box.
• Remote Administration Flaws – Many web applications allow administrators to access the site using a web interface. If these administrative functions are not very carefully protected, an attacker can gain full access to all aspects of a site.

Auditors Must Change to Adapt to the New Landscape!!

So, as you can tell, Availability-based risks are a big problem and need a serious set of auditing and control procedures to both measure, monitor and protect!

To reiterate, any assessment of an organization’s Availability risks would be remiss if they focused only on DDoS threats. Any logical Availability security assessment will determine the appropriateness of role and rights assignments to specific user classes, and how these assignments are controlled. Practices such as the following need to be thoroughly reviewed.

Please don’t hesitate to contact me should you need more details as this is ONLY the beginning to these thoughts. Best of luck in with your endeavors!