Barracuda Networks Product Blog

by Oliver Wai, Product Marketing Manager

This article was originally published in Pentesting Magazine’s Nov 22, 2011 issue. For Part 1,  Part 2, Part 3.

Demands on Penetration Testers

When penetration testers look for weak spots, they should also take into account the Payment Card Industry Data Security Standard (PCI DSS) 2.0. This defines rules for distributing and storing Primary Account Number (PAN) information. The companies are required to develop secure web applications and maintain them constantly. Further points define formal risk checks and test processes that are intended to uncover high risk weak spots. In order to check whether systems comply with PCI DSS, penetration testers must heed the following requirements:

• Does the system have a Web Application Firewall?
• Does the web traffic occur via a WAF Proxy function?
• Are the web servers shielded against direct access by attackers?
• Is there a simple SSL encryption for the data traffic, even if the application or the server do not support this?
• Are all known and unknown threats blocked?

A further point is the protection against data theft. This involves checking whether the protection mechanism checks the outgoing data traffic for the possible withdrawal of sensitive data and then stops it.

Penetration testers can fall back on web scanners to run security checks on web applications. Several WAFs provide extra interfaces to automate tests.

Since, by its very nature, a WAF stands on the frontline, certain test criteria should be applied to it as well. These include in particular the identity and access management. In this context the principle of least privileges applies: The users are only awarded those privileges on a need-to-have basis for their work or the use of the web application. All other privileges are blocked. A general integration of the WAF in Active Directory, eDirectory or other RADIUS or LDAPcompatible authentication services makes this work easier.

The user interface is also an especially critical point, because it is the basis for safe WAF configuration. Unintelligible or poorly structured user interfaces lead to incorrect settings, which cancel out the protective functions. If, by contrast, the functions can be recorded intuitively, are clearly displayed, easy to understand and to set, then this in practice makes the greatest contribution to system security. A further plus is a user interface which is identical across several of the manufacturer’s products or, even better, a management center which administrators can use to manage numerous other network and security products with as well as the WAF. The administrators can then rely on the known settings processes for security clusters. This ensures that security configurations for each cluster are consistent across the organization. An extensive penetration test of web applications should therefore take the ergonomics of the WAF interface into account for the evaluation along with the consistency of security deployment across applications and sites.

Summary
In summary, any web application, old or new, needs to be secured by a WAF in Full Proxy Mode. Penetration testers should check whether the WAF reliably cloaks system information in order to make attacks on the infrastructure less likely in the first place. It should also check whether it prevents the hacking of the application itself with common or new means, whether it secures all the backend systems the application connects to and it stops leakage of sensitive data when the web application has weaknesses which the WAF cannot level out. If penetration testers are not only looking for a security snap shot, but want to help their customers in creating sustainable security, they should always include the WAF’s administration into their assessment.

by Oliver Wai, Product Marketing Manager

This article was originally published in Pentesting Magazine’s Nov 22, 2011 issue. For Part 1,  Part 2.

WAF Functionality
A major advantage of WAFs is that one single system can close the security loopholes for several web applications. If they are run in redundant mode they can also conduct load balancing functions in order to distribute data traffic better and increase the performance for the web applications. With content caching functions they reduce the load on the backend web servers and via automated compression procedures they reduce the band width requirements of the client browser.

In order to protect the web applications, the WAFs filter the data flow between the browser and the web application. If an entry pattern emerges here that is defined as invalid, then the WAF interrupts the data transfer or reacts in a different way that has been predefined in the configuration diagram. If for example, two parameters have been defined for a monitored entry form, then the WAF can block all requests that contain three or more parameters. In this way the length and the contents of parameters can also be checked. Many attacks can be prevented or at least made more difficult just by specifying general rules about the parameter quality, such as their maximum length, valid number of characters and permitted value area.

Of course, an integrated XML Firewall should also be the standard these days, because increasingly more web applications are based on XML code. This protects the web server from typical XML attacks such as nested elements or WSDL Poisoning. A fully-developed rule for access numbers with finely adjustable guidelines also eliminates the negative consequences of Denial of Service or Brute Force attacks. However, every file that is uploaded to the web application can represent a danger if it contains a virus, worm, Trojan or similar. A virus scanner integrated into the WAF checks every file before it is sent to the web application.

Several WAFs have the option of monitoring the data sent by the web server to the browser in such a way that they can learn their nature. In this way these filters can – to a certain extent – automatically prevent malicious code from reaching the browser, if for example a web application does not conduct sufficient checks of the original data. Learning Mode is a profiling mode that indexes every URL and parameter in a stream of traffic in order to build a whitelist of acceptable URLs and parameters. However in practice, a whitelist only approach is quite cumbersome, requiring constant re-learning if there are any changes to the application. As a result, whitelist only approaches quickly become out of date due to the constant tuning required to maintain the whitelist profiles. However, the contrary blacklist only approach offers attackers too many loopholes. Consequently the ideal solution should rely on a combination of both whitelisting and blacklisting. This can be made easy-to-use by using templated negative security profile (e.g. for standard usages like Outlook Web Access, SharePoint or Oracle applications) augmented by a whitelist for high value sub-section like an order entry page.

To prevent a high number of false positives some manufacturers provide an exception profiler. This flags entries in possible violation of the policies but can still be categorized as legitimate based on an extensive heuristic analysis to the administrator. At the same time the exception profiler makes suggestions for exemption clauses that prevent a similar false positive from being
repeated.

Some WAFs provide different operating modes: Bridge Mode (as Bridge Path) or Proxy Mode (as One-Arm Proxy or Full Reverse Proxy). In Bridge Mode the WAF is used as an In-Line Bridge Path and works with the same address for the virtual IP and the backend server. Although this configuration avoids changes to the existing network structure and as such can be integrated very easily and fast to protect an endangered web application. Bridge Mode deployments sacrifice security and application acceleration for network simplicity. Additionally this mode means that all data is passed on to the web application, including potential attacks – even if the security checks have been conducted.

The by far safer operating mode for a WAF is the Full Reverse Proxy configuration, as this is used in line and uses both of the system’s physical ports (WAN and LAN). As a proxy WAFs have the capability to protect web applications against attacks such as Session Spoofing or Cross-Site Request Forgery, which is not possible in Bridge Mode. And, only special functions are available here. As a Full Reverse Proxy a WAF provides for example Instant SSL that converts httppages into HTTPS without making changes to the code.

Proxy WAFs also provide a whole range of further security functions. They facilitate the translation of web addresses and as such the overwriting of URLs used by public requests to the web application’s hidden URL. This means that the application’s actual web address remains cloaked. With Proxy WAFs SSL is much faster and the response times for the web application can also be accelerated. They also facilitate cloaking techniques, Level 7 rules (to avoid Denial of Service attacks) as well as authentication and authorization. Cloaking, the concealment of one’s own IT infrastructure, is the best way to evade the previously mentioned scan attacks which attackers use to seek out easy prey. By masking outgoing data, protection can be obtained against data theft and Cookie-Security prevents identity theft. But the Proxy-WAFs must also be configured to correspond with the respective terms. Penetration tests help with the correct configuration.

Click here for Part Four.

by Oliver Wai, Product Marketing Manager

This article was originally published in Pentesting Magazine’s Nov 22, 2011 issue.

For Part 1, click here.

The problem with more recent web applications: Many offerings demand the integration of additional browser plug-ins and add-ons in order to facilitate the interaction in the first place or to make it dynamic. These include, for example, Ajax and JavaScript. While the browser was originally only a passive tool for viewing web sites, it has now evolved into an autonomous active element and has actually become a kind of operating system for the plug-ins and add-ons. But that makes the browser and its tools vulnerable. The attackers gain access to the browser via infected web applications and as such to further systems and to their owners’ or users’ sensitive data.

Some assume, that an unsecured web application cannot cause any damage as long as it does not conduct any security-relevant functions or provide any sensitive data. This is completely wrong. The opposite is the case. One single unsecured web application endangers the security of further systems that follow on, such as application or database servers. Equally wrong is the common misconception that the telecom providers’ security services would protect the data. Providers are not responsible for a safe use of web applications, regardless of where they are hosted. Suppliers and operators of web applications are the ones who have the big responsibility here towards all those who use their applications, one which they often do not fulfill.

Web Applications Under Fire

The security issues for web applications have not escaped the attackers and they have been exploiting these shortcomings in the IT environments for some time now. There are numerous attack scenarios using which they can obtain access to corporate data and processes or even external systems via web applications. For years now the major types have been:

All injection attacks (such as SQL Injection, Command Injection, LDAP Injection, Script Injection, XPath Injection)

• Cross Site Scripting (XSS)
• Hidden Field Tampering
• Parameter Tampering
• Cookie Poisoning
• Buffer Overflow
• Forceful Browsing
• Unauthorized access to web servers
• Search Engine Poisoning
• Social Engineering

The only more recent trend: The attackers have recently started to combine the methods more often in order to obtain even higher success rates. And here it is no longer just the large corporations who are targeted because they usually guard and conceal their systems better. Instead, an increasing number of smaller companies are now in the crossfire.

One Example
Attackers know that a certain commercial software program is widely used for shopping carts in online shops, and that the smaller companies rarely patch the weak points. They launch automated attacks in order to identify – with high efficiency – as many worthwhile targets as possible in the web. In this step they already gather the required data about the underlying software, the operating system or the database from web applications, which give away information freely. The attackers then only have to evaluate this information. As such they have an extensive basis for later targeted attacks.

How to Make a Web Application Secure

There are two ways of actually securing the data and processes that are connected to web applications. The first way would be to program each application absolutely error-free under the required application conditions and security aspects according to predefined
guidelines. Companies would have to increase the security of older web applications to the required standards later.

However, this intention is generally doomed to failure from the outset, because the later integration of security functions in an existing application is in most cases not only difficult, but also above all, expensive. Another example: a program that had until now not processed its inputs and outputs via centralized interfaces is to be enhanced to allow the data to be checked. It is then not sufficient to just add new functions. The developers must start by precisely analyzing the program and then making deep inroads into its basic structures. This is not only tedious, but also harbors the danger of making mistakes. Another example is programs that do not just use the session attributes for authentification. In this case it is not straightforward to update the session ID after logging in. This makes the application susceptible for Session Fixation.

If existing web applications display weak spots – and the probability is relatively high – then it should be clarified whether it makes business sense to correct them. It should not be forgotten here that other systems are put at risk by the unsecured application. A risk analysis can bring clarity, whether and to what extent the problems must be resolved or if further measures should be taken at the same time. Often however, the program developers are no longer available and training new developers as well as analyzing the web application results in additional costs.

The situation is not much better with web applications that are to be developed from scratch. There is no software program that ever went into productive operation free of errors or without weak spots. The shortcomings are frequently uncovered over time. And by this time correcting the errors is once again timeconsuming and expensive. In addition, the application cannot be deactivated during this period if it works as a sales driver or as an important business process. Despite this, the demand for good code programming that sensibly combines effectiveness, functionality and security still has top priority. The safer a web application is written, the lower the improvement work and the less complex the external security measures that have to be adopted.

The second approach in addition to secure programming is the general safeguarding of web applications with a special security system from the time it goes into operation. Such security systems are called Web Application Firewalls (WAF) and safeguard the operation of web applications.

A WAF should protect web applications against attacks via the Hypertext Transfer Protocol (HTTP). As such it represents a special case of Application-Level-Firewalls (ALF) or Application-Level-Gateways (ALG). In contrast with classic firewalls and Intrusion Detection Systems (IDS) a WAF checks the communications at the application level. Normally, the web application to be protected does not have to be changed.

Secure programming and WAFs are not contradictory, but actually complement each other: Analog to flight traffic it is without doubt important that the airplane (the application itself) is well serviced and safe. But even the perfect airplane can never replace the security gate at the airport (the Web Application Firewall), which, as the first security layer, considerably minimizes the risks of attacks on any weak spots.

After introducing a WAF, it is still recommendable to check the security functions, as conducted by Penetration Testers. This might reveal for example that the system can be misused by SQL Injection by entering inverted commas. It would be a costly procedure to correct this error in the web application. If a WAF is also deployed as a protective system, then this can be configured to filter the inverted commas out of the data traffic. This simple example shows at the same time that it is not sufficient to just position a WAF in front of the web application without an analysis. This would lead to misjudging the achieved security status: Filtering out special characters does not always prevent an attack based on the SQL Injection principle. Additionally the system performance would suffer, as the security rules would have to be set as restrictively as possible in order to exclude all possible threats. In this context too, penetration tests make an important contribution to increasing the Web Application Security.

Click here for Part Three.

by Oliver Wai, Product Marketing Manager

This article was originally published in Pentesting Magazine’s Nov 22, 2011 issue.

Anyone developing a new software program will usually have an idea of the features and functions that the program should master. The subject of security is, however, often an afterthought. But with web applications, the backlash comes quickly because many are accessible for everyone worldwide.

They are currently being used by hackers on a grand scale as gateways into corporate networks. Web Application Firewalls (WAFs) make it a lot more difficult to penetrate networks. In most commercial and non-commercial areas the internet has developed into an indispensible medium that offers users a huge number of interesting and important applications. Information procurement of any kind, buying services or products but also bank transactions and virtual official errands can be conducted easily and comfortably from the screen. Waiting times are a thing of the past and while we used to have to search laboriously for information, we now have the search engines that deliver the results in a matter of seconds. And so browsers and the web today dominate the majority of daily procedures in both our private as well as working lives. In order to facilitate all of these processes, a broad range of applications is required that are provided more or less publically. Their range extends from simple applications for searching for product information or forms, up to complex systems for auctions, product orders, internet banking or processing quotations. They even control access to the company’s own intranet.

A major reason for these rapid developments is the almost unlimited possibilities to simplify, accelerate and make business processes more productive. Most enterprises and public authorities also see the web as an opportunity to make enormous cost savings, benefit from additional competitive advantages and open up new business opportunities. This requires a growing number of – and more powerful – applications that provide the internet user with the required functions as fast and simply as possible.

Developers of such software programs are under enormous cost and time pressure. An increasing number of companies want to use the functionality of these socalled web applications for their business processes and offer their products, services and information as quickly as possible, simply and in a variety of ways. So guidelines for safe programming and release processes are usually not available or they are not heeded. In the end, this results in programming errors because major security aspects are deliberately disregarded or are simply forgotten. The productive use usually follows soon after development, without developers having checked the security status of the web applications sufficiently.

Above all, the common practice of adapting tried and tested technologies for developing web applications is dangerous, without having subjected them to prior security and qualification tests. In the belief that the existing network firewall would provide the required protection if possible weaknesses were to become apparent, those responsible unwittingly grant access to systems within the corporate boundaries. And thereby, they disclose sensitive data and make processes vulnerable. But conventional protection systems do not guard against apparently legitimate connections that attackers build up via web applications.

As a result, critical business processes that seemed secure within the corporate perimeter are suddenly freely accessible in the web. Conventional security strategies such as network firewalls or Intrusion Prevention Systems are no longer expedient here. Particularly in association with the web, the security requirements for applications have a different focus and are much higher than for traditional network security. The requirements of service providers who conduct security checks on business-critical systems with penetration tests should then also be respectively higher.

While most companies in the meantime protect their networks to a relatively high standard, the hackers have long since moved on to a different playing field. They now take advantage of security loopholes in web applications. There are several reasons for this: Compared with the network level, you don’t need to be highly skilled to use the internet. This not only makes it easier to use legitimately, but also encourages the malicious misuse of web applications. In addition, the internet also offers many possibilities for concealment and making action anonymous. As a result, the risk for attackers remains relatively low and so does the inhibition threshold for hackers.

Many web applications that are still active today were developed at a time when awareness for application security in the internet had not yet been raised. There were hardly any threat scenarios because the attackers’ focus was directed at the internal IT structure of the companies. In the first years of web usage in particular,professional software engineering was not necessarily at the top of the agenda. So web applications usually went into productive operation without any clear security standards. Their security standard was based solely on how the individual developers rated this aspect and how high their respective knowledge was.

Figure 1. This model (based on Everett M. Rogers adoption curve from “Diffusion of innovations”) shows a time lag between the adoption of new technology and the securing of the new technology. Both exhibit the similar Technology Adoption Lifecycle.

Click Here for Part Two

by Oliver Wai, Product Marketing Manager

We’ve been getting a number of customer inquiries on how the Barracuda Web Application Firewall could protect them from a new exploit that allows attackers to bypass Apache and access the internal systems behind the web server.

How Does the Exploit Work?
For those unfamiliar with the attack, it was discovered by Contextis researchers last month and targets the “mod_rewrite” module on Apache to exploit traffic rewriting rules. Specifically, they target an uncommonly used part of the URI scheme to rewrite the meaning of a request. Consider the two rewrite examples given by Contexis:

1. RewriteRule ^(.*) http://internalserver.com:80$1 [P]
2. RewriteRule ^(.*) http://internalserver.com:80/$1 [P]

The only difference between the two rules is the missing ‘/’. However without the ‘/’, an attacker can access the internal servers by manipulating the ‘$1′ portion of the request. For example, if you were to send the following request:

GET @InternalNotAccessibleServer/console HTTP/1.0

This will be translated by the first rule to:

http://internalserver:80@InternalNotAccessibleServer/console

Looking at the URI scheme specification in Wikipedia:

The “internalserver:80@” portion of the new URI is interpreted as the username:password for InternalNotAccesibleServer. In most cases, the user:password portion of the URI will be ignored, thus giving the attacker access to InternalNotAccesibleServer. If you had the ‘/’ in place, the request would look like this:

http://internalserver:80/@InternalNotAccessibleServer/console

This would be a malformed URI and Apache will reject that request with a 400 error.

Defending with the Barracuda Web Application Firewall

To fully discuss the exploit, we need to consider three parts of the Barracuda Web Application Firewall. The Barracuda management interface, the content rule capabilities of the Barracuda Web Application Firewall, and rewrite rules on the web servers themselves.

The Barracuda Web Application Firewall Management Interface

The Barracuda Web Application Firewall web interface is not susceptible to the exploit and is not at risk for the attack.

The Barracuda Web Application Firewall Rewrite Rules

From a security perspective, the Barracuda Web Application Firewall rewrite rules are more robust than the mod_rewrite on the Apache. Our URL translation examines each part of the input before constructing the translation. This prevents the attacker from accessing servers not specifically specified by the Barracuda Web Application Firewall.

Rewrite Rules on Apache Servers behind the Barracuda Web Application Firewall

Sometimes organizations prefer to use existing rewrite rules on their web servers and not leverage the traffic rewriting capabilities of the Barracuda Web Application Firewall. In this case, the Barracuda can still be configured to defend against attacks targeting the back end web servers by setting up a URL ACL rules. Here is how set this up:

1. Go to Security Policies->Global ACL
2. Create a new Global ACL rule as show below.

This rules works because the ACL rule enforces that the URI path start with a ‘/’ ultimately prevents attackers from overloading the URI in the manner shown above. Enabling this rule will result in the Barracuda Web Application blocking and logging any attempts to bypass your backend web servers.

In general the Barracuda Web Application Firewall is an extremely extensible platform that allows administrators and organizations to instantly build rules to respond to new and emerging exploits. I encourage you to take a closer look at the advanced functionality of your Barracuda Web Application Firewall to explore all of its defensive capabilities.

For more information on the attack, check out the seclist discussion at: http://seclists.org/fulldisclosure/2011/Oct/232

Posted by: Neeraj Khandelwal, Product Manager

The Information Security (InfoSec) teams responsible for web security configuration are always under pressure to provide just the right amount of up-to-date security without impacting business. As professionals, they are also wary of losing credibility from the development and business teams if they adversely affect deliverables or if they flag numerous false positives during security tuning.

To ease this, the default security policies in the Barracuda WAF have been fine tuned to provide a high level of security out of the box. They have been baked through continuous research and years of deployment in the wild to provide unmatched security while avoiding false positives. Many of our customers do not require more than these. However, for high value applications like online shopping carts or online banking, it may be necessary to create custom security policies.

With Barracuda, custom security is easy. You can quickly configure additional input validations for, say, patient IDs, DLP rules for custom PII (Personally identifiable information), custom protection against blog comment spam, etc. But becoming over-zealous with security can lead to false positives, while misconfiguration can make you vulnerable.

Relief from such issues is taken to the next level by the unique Exception Profiler in the Barracuda Web Application Firewall. You can deploy your custom policies without concern while the Exception Profiler applies a variety of intelligent heuristics to examine denied requests to detect false positives. If a pattern is suspected to be a false positive, the Exception Profiler will identify the policy rule that caused the issue and will recommend policy fix recommendations when it determines that genuine requests may have been blocked. If you prefer a hands off approach, it can even automate the process without any administrator intervention.

Accurate and Configurable
The Exception Profiler engine has been engineered from the ground up keeping accuracy in mind and to reduce noise from the recommendations. You can further tweak it to your personal and organizational preferences:

• Recommendation processing – select whether exceptions are applied to your policy only after admin approval or automatically
• Custom Profiling Levels – allows you to specify the level  of sensitivity the profiler should use before prescribing an exception criterion, for example, the minimum number of denied requests to legitimate sources, the length of time for observation, etc.
• Configurable limits– the profiler can be instructed to relax the security policies to a configurable level, in the context of the violation. E.g. relax the maximum HTTP header length by 20% or 40% etc.
• Conservative pattern validation sensitivity – allows you to relax the exact subclass of patterns that are violating a policy. For example, HTTP link tags relaxation in blog comments will continue to block other tags that constitute the XSS attack type class
• Trusted Sources – You can define a lower level of sensitivity for truster sources while maintaining a stricter posture for non-trusted sources.

The Barracuda Web Application Firewall comes with multiple pre-built exception profile templates to match applications of differing sensitivity. You can further tune  these policies as required to meet your exact requirements.

But why not just use the regular WAF “Learning” Mode?
So what about learning mode? Why this fuss about exception learning and custom security policies, when most WAFs have a white list-based learning mode?

Learning mode is based on creating on creating an input validation profile by observing traffic between clients and applications. The assumption is that all possible combination of valid inputs will be exercised and no attacks will occur over that period of time. However, this assumption may not be true in many cases. For example, consider a learned profile for an input representing user name may be {type=alphabetic, max length=40}. Once it is deemed that enough traffic or time has elapsed, the learned profile is set to “Enforce” mode. This does not help with false positives – a name containing a single quote (‘), or with length 50 would be blocked after the learned profile is enforced and such a name has not been encountered during the learning phase.

While there are advantages to learning in certain situations, there are some other considerations when using learning mode:

• Learning cannot replace manual custom security – It’s hard to learn the exact validation format (regex) for things like patient IDs.
• It is not easy to decide when the learning mode has covered a diverse enough sample set to be able to deploy in active protection so that enforcement can begin for the respective URLs
• Any change to the applications with almost always require  Learning to be redone

In practice, learning mode is only used for a small subset of application pages. Most applications use a strong security profile like the Barracuda default security policy that can be tuned using intelligent tools like the Barracuda Exception Profiler to the specifics of the applications.
Summary
Exception profiling custom security policies is a powerful tool for keeping your site visitors, development and business teams happy. It balances aggressive security with minimal business impact keeping performance and admin overhead to a minimum. You can enable exception profiling in the following quick and easy steps:

1. Decide the web applications that need exception profiling
2. Choose the profiling level for each web application, or parts thereof
3. Optionally define trusted hosts for precise and faster learning of exceptions
4. Review the fixes implemented or recommended periodically