Protection from the Inside:

Application Security Methodologies Compared

A SANS Product Review

Written by Jacob Williams

April 2015

Sponsored by

HP

©2015 SANS™ Institute

Introduction

Web applications are a common source of compromise and the vector attackers often use to penetrate a network. They are often complex and developed by those with little understanding of security in software development. Fundamental misunderstandings of security by those responsible for custom code development in our environments too often lead to compromises, with disastrous results.

What will help keep organizations safe, while allowing the flexibility that web application designers demand? Many in the industry suggest that a web application firewall (WAF) is the answer. WAF filtering technology normally sits in front of a web application, inspecting incoming traffic for attack patterns and preventing those inputs from reaching the web application itself. However, a WAF is only as good as its signature base and pattern- matching engine, and bypassing WAF filtering is an active topic of security research.

So begins a cat-and-mouse game, where attackers research new and clever ways to create malicious inputs that cause undesired application behavior while bypassing the WAF’s input filters. (After all, the WAF doesn’t truly understand what the application will do with the input, so it must block any input that could cause an exploit, whether or not it would.)

What if, rather than monitoring for potentially malicious inputs, you could monitor the application itself and block only those inputs that actually changed the behavior or operation of the application? Such an approach would render filter bypasses impossible and increase true positive rates.

This approach is the idea behind runtime application self-protection (RASP), which Gartner defines as a security technology built or linked into an application runtime environment to control execution and prevent real-time attacks.1 HP Application Defender (hereafter, “App Defender”), the focus of this review, adds this protection to servers hosting any

Java or .NET application by loading an agent into the Java Virtual Machine (JVM) or .NET Common Language Runtime (CLR). The agent establishes program points App Defender uses to identify attacks in the application code itself, providing RASP functionality without touching the application code. Implementing App Defender is a simple matter of installing the agent and restarting the application server; the agent instruments the application at strategic locations in the code, automatically protecting vulnerable library calls before attackers can exploit them.

In this review, we compare App Defender to an unnamed WAF, examining their respective preventive and detective capabilities. Where WAFs simply put up a wall in front of the application, RASP protects the application from the inside out. Its instrumentation of

the runtime environment enables the mitigation of vulnerabilities without access to the source code. When tested against the WAF, App Defender caught more events, reduced false positives and improved visibility into vulnerabilities, including those weaknesses we didn’t know we had.

1“Runtime Application Self-Protection (RASP),”Gartner IT Glossary, retrieved February 27, 2015; www.gartner.com/it-glossary/runtime-application-self-protection-rasp

WAF Versus RASP: Comparing Capabilities

WAF Versus RASP: Comparing Capabilities (CONTINUED)

RASP Capabilities

RASP and WAFs protect applications in fundamentally different ways. Consider WAFs to be the gloves and masks medical personnel use when dealing with an infected patient. These barriers might block germs from entering the body, but gloves and masks do not protect against all infections. RASP, in this example, is a vaccine that protects the application from attack, even if bad inputs get in.

Table 1 compares the basic characteristics and functions of RASP tools and WAFs.

Table 1. Comparison of RASP and WAF Characteristics

Detecting Threats and Vulnerabilities (CONTINUED)

It is also worth noting that App Defender is able to provide specific information, making remediation efforts much more efficient. A WAF cannot provide this insight.

Cross-Site Scripting

Cross-site scripting (XSS) is an attack where JavaScript input sent by the attacker is then reflected back to a website user. This input may then be used to steal authentication cookies from the user or redirect them to a malicious website.

The App Defender agent detects XSS attacks with little trouble. Our testing showed it detects an XSS attack by matching on the string <script anywhere in a request parameter and preventing the upload of any input containing this string. App Defender effectively prevents the insertion of new XSS input to the web application, but at the risk of triggering a false alert if users are allowed to upload JavaScript (to a message board, for instance).

Although App Defender does a commendable job defending against reflected XSS and preventing the insertion of new, stored XSS, it cannot shield against stored XSS attacks that rely on preloaded malicious content transferring from an unprotected database to a protected one. The WAF also failed to detect this stored XSS attack. In order for any solution to detect this type of attack, it would have to examine all JavaScript returned to the user for potential malicious applications, which would likely have either abysmal detection rates or astronomically high false positives and a large impact on availability.

Command Injection

Command injection is one of the most potentially damaging attacks on a web application; it occurs when developers accept untrusted user input and use it as part of a shell command without first filtering out dangerous characters. Unlike XSS (which attacks the browser) or SQL injection (which obtains data), command injection goes after the server directly, executing code in the context of the user running the web application. Unfortunately, some administrators still run their web servers as the root user and, in such a case, command injection vulnerabilities result in total compromise of the machine running the web application. Even in cases where a non-root user runs the web application, command injection vulnerabilities are devastating and allow attackers to pivot their attacks from the web server to internal hosts.

The App Defender agent detected command injection reliably, even when the actual command injection attack would not have been successful in executing code on the server because of syntax issues. We attempted multiple filtering evasions, but App Defender caught the attack every time. The WAF also caught the command injection attempts because they contained character combinations that benign user scripts typically lack.

Detecting Threats and Vulnerabilities (CONTINUED)

Detecting Threats and Vulnerabilities (CONTINUED)

The problem with the WAF approach is that creating a usable configuration requires some prior knowledge of the vulnerable fields, while the RASP approach suffers from potential false positives thanks to naïve pattern matching. However, because App Defender inspects input at the time it passes to the database query strings, it eliminates false-positive detections for fields not vulnerable to SQL injection so the administrator does not waste time chasing attacks that don’t apply to his environment. On the other hand, the WAF still detected this as an attack, resulting in a false positive, as shown in Figure 1.

Figure 1. False-Positive SQL Injection

In addition to testing for naïve SQL patterns (such as or 1=1), we attempted several other tautologies, hoping to extract additional data from the database. Although such tautologies sometimes bypass WAF technologies, App Defender caught them all. The App Defender agent appeared to match our strings against blacklisted parameters, including any quotes and Boolean operators passed to the SQL query string. This result makes sense, because any query including a Boolean operation would necessarily change the structure of the query.

However, the naïve pattern matching of WAFs may sometimes be the best tool for the job; one example of this is testing for XPath injection, another class of query injection attacks.5 App Defender failed to detect a basic XPath injection string that the WAF detected. (Our analysis of the underlying code appears to indicate that when the input strings do not pass directly to a SQL library call—as was the case in this example—the App Defender agent does not detect the query injection.) Figure 2 shows a typical XPath injection using tautologies.

Figure 2. XPath Injection Using Tautologies

5The XPath query language extracts data from an XML database—used by some web applications to store data—in much the same fashion as SQL.

Detecting Threats and Vulnerabilities (CONTINUED)

App Defender’s application-level instrumentation detected all of our standard SQL injection attempts but missed query injection attacks that did not use standard SQL libraries. (Although our WAF also caught our SQL injection attempts, instrumentation through RASP offers better theoretical protection against SQL injection attacks than do firewall technologies like WAF. We expect RASP’s low-level instrumentation would likely catch future evasion techniques that use SQL injection to bypass WAF.)

Forceful Browsing

App Defender protected successfully against forceful browsing attacks, although configuring this protection is not what some experienced users might anticipate or desire. The App Defender agent checks for these file extensions and only these extensions: .log, .bak, .old, _log, _bak and _old. Other extensions could reflect forceful browsing as well; extensions commonly seen during penetration tests include

.1, .2, .2015 (the year) and .012015 (the month and year). Although it’s not possible to configure App Defender to detect these additional extensions, most WAFs can block access to all such extensions.

Method Call Failure

Method call failures exist only in programming languages that support object-oriented programming. These errors usually occur when an object of one type improperly calls a method from its base class. Bugs of this nature are particularly dangerous because they may remain hidden if they do not generate error logs or other obvious output. App Defender can detect method call failures when SQL exceptions occur during database transactions, an example of a method call failure that occurs without displaying any output to the user.

Testing for method call failures can identify underlying vulnerabilities as well as attacks. During our review, App Defender detected a number of previously unknown errors in the web application we used for our tests. None of these errors appeared in standard web application logs, and none displayed to the user. Although such errors in a web application are often invisible to users, an attacker might be able to exploit them by using novel or unusual attack code. App Defender detects these errors by instrumenting the API calls themselves, rather than examining the output, making it useful for identifying underlying application errors in a production environment.

Detecting Threats and Vulnerabilities (CONTINUED)

An example of App Defender’s output from a method call failure appears in Figure 3.

Figure 3. Method Call Failure

In contrast, no WAF, even one that filters responses, could detect method call failures if the web application did not display errors.

Unhandled Exceptions

Unhandled exceptions can give the attacker insight into how an application functions. One potential risk is that the stack trace output from the server may reveal the application’s use of vulnerable libraries to the attacker and provide him with a roadmap for his assault.

We deliberately configured the web application we tested to throw unhandled exceptions, mimicking a common misconfiguration of web applications. Figure 4 displays a typical App Defender stack trace from an unhandled exception.

Detecting Threats and Vulnerabilities (CONTINUED)

Even though

exposures of sensitive data can lead to big fines, developers often do not realize where their apps have stored sensitive information.

Figure 4. Unhandled Exception Revealed in Stack Trace

App Defender was able to detect these exceptions. Meanwhile, the WAF did not detect the unhandled exceptions. No such thing as a universal input that triggers an unhandled exception exists, leaving the WAF (focused on input) with no way to detect such exceptions.

Privacy Violations

Even though exposures of sensitive data can lead to big fines, developers often do not realize where their apps have stored sensitive information, and even audited applications may disclose sensitive data while under attack. Applications may write sensitive data to their log files, especially when the application fails in response to attack input. An attacker can then use his access to the web application to examine the application log files to retrieve sensitive data, including payment card numbers.

Detecting Threats and Vulnerabilities (CONTINUED)

App Defender has two rule categories for detecting sensitive information: credit card numbers and Social Security numbers (SSNs), two of the data items attackers are most likely to want. The default action for both rules is to rewrite (or mask) the output, an operation that offers an optimal blend of usability and security. In the event the output of sensitive data was the result of normal operation and not an attack, the operation still proceeds, but with the sensitive data masked in the log file.

Figure 5 shows an example of App Defender detecting sensitive data as it is sent to server log files.6

Figure 5. Sensitive Data Detection

Detecting and masking such values at the library call level could prevent a compliance violation in breach scenarios where sensitive data is not blocked even though the application itself was exploited. The credit card and SSN algorithms App Defender used matches the patterns; for example, ###-##-#### for an SSN. However, organizations need to configure App Defender to recognize and mask other patterns—such as the filtering of medical record numbers or bank account numbers, features currently missing from the product.

Not only did App Defender detect the sensitive data where the WAF did not, but also we believe its functionality may be useful to auditors who wish to find in the application unanticipated locations that hold sensitive data.

6App Defender’s documentation incorrectly stated that it masks sensitive data in HTTP responses; actually, it masks such data only when writing to external files, because masking sensitive data returned in HTTP responses can cause problems with database updates.

Detecting Threats and Vulnerabilities (CONTINUED)

Unsupported Method

App Defender protects against requests that employ infrequently used HTTP request methods; it treats any HTTP methods other than GET, POST and PUT as “unsupported” methods. (However, some poorly coded clients may send these request methods in mixed case, triggering false alerts.) Other requests may also be required for protected applications, which might legitimately support methods such as DELETE, OPTIONS or TRACE. RASP products need to support such functions in their libraries and should provide a means to configure alternative options to better handle such cases.

(Then again, our voyage through the configuration notes for the WAF we used made it clear that enabling the detection of unsupported HTTP requests on a traditional WAF is possible, but not for the faint of heart.)

Both App Defender and the WAF successfully detected unsupported HTTP methods. App Defender’s information screen for this attack appears in Figure 6.

Figure 6. Unsupported HTTP Request Method

Missing Content-Type

Attackers may bypass file type upload restrictions by not specifying anything for content- type in the request header. Both App Defender and the WAF were able to detect this attack vector with ease. App Defender’s display of one such attack appears in Figure 7.

Figure 7. Typical Display of a Missing Content-Type Attack

Detecting Threats and Vulnerabilities (CONTINUED)

Missing Accept Header

HTTP does not strictly require accept headers—which tell the application server what languages or character sets the client supports—but virtually all legitimate clients send them as part of the request. Many automated scanning engines fail to include these headers, making this a potential early warning sign of an automated attack. Both App Defender and the WAF detected the missing Accept header. App Defender’s detailed output is shown in Figure 8.

Figure 8. Missing Accept Header in HTTP Request

Known Vulnerability Scanners

Vulnerability scanners often embed a predefined user agent string in their probes and—for obvious reasons—security analysts seek to prevent attackers from using them. Both App Defender and the WAF detected the user agent strings of known vulnerability scanners, although the list of vulnerability scanners App Defender can detect is not documented and not configurable. For this reason, some security analysts may prefer the flexibility of a fully configurable WAF solution. Figure 9 shows a typical message generated by App Defender when detecting a vulnerability scan through examination of the user agent string.

Figure 9. Vulnerability Scanner Detected

In summary, our tests proved App Defender’s capability to protect against attack classes that the WAF was unable to even see.

About the Author

Jacob Williams is founder and principal consultant at Rendition Infosec and a certified SANS instructor and course author. He has more than a decade of experience in secure network design, penetration testing, incident response, forensics and malware reverse engineering. Before founding Rendition Infosec, he worked with various government agencies in information security roles. Jake is a two-time victor at the annual DC3 Digital Forensics Challenge.

Sponsor

SANS would like to thank its sponsor: