Pandora’s Box: Auditing for DDoS Vulnerabilities, Part II

The Rise of the “Availability Vulnerabilities”

Availability problems aren’t necessarily unique; however, the testing is certainly different.

This “availability security problem” is resulting in an increased risk to enterprises 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 into the vulnerabilities they have to hacktivists (ideologically motivated) and availability-based (competitively motivated) DDoS attacks.

The following are the solid reasons to test your organization for these risks:

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 CVE list as they are tools, however 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 DDoS protection 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 “availability” based vulnerabilities have been either not tested or ruled not meaningful since the inception of routine testing. Yes, 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.’

Well, 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 and diagnosis a problem, we must first know what it is.

[You might also like: Pandora’s Box: Auditing for DDoS Vulnerabilities, Part I]

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

So, from this blog we can categorically agree that information security threats to an organization revolve around the following problems:

• Real-time DDoS prevention and 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 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 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 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.