What does Google’s “HTTPS Everywhere” mean for Web Application Security

Sep 03, 14 What does Google’s “HTTPS Everywhere” mean for Web Application Security

Posted by in Web Application Security

This post was submitted by Product Manager Neeraj Khandelwal and is also published on our corporate blog here. Google’s recent announcement of boosting search rankings of HTTPS sites is welcome news from boosting the general security of the Internet. For example, it will force popular sites away from transporting passwords in plaintext. Undoubtedly, HTTPS is great to combat Man-in-the-Middle (MITM) attacks. To cite an analogy, HTTPS is like an armored delivery vehicle going from point A to point B that secures it’s passengers while in transit. It also ensures that the passengers are delivered to the right destination. However, just like the armored vehicle, it does not provide any guarantee for what you load into or take out from the vehicle. It could well be a live bomb, or your enemy itself in disguise… Adversaries can use this to their advantage. HTTPS can blindside traditional perimeter security Brad Pitt and his team pose as Germans to get past heavily guarded German bases in The Inglorious Bastards.If your adversary can’t recognize you for what you are, then their security is useless. HTTPS brings up a similar conundrum for perimeter security. Since the data is completely encrypted, traditional perimeter security solutions like firewalls, IDS/IPS, etc. have no way to tell if it is malicious. For your adversaries (attackers), it becomes easier to hide their attacks within HTTPS and target  your servers or applications. This also works both ways: responses originating from the servers in the data centers can contain data leaks as well as malicious exploits targeting the users and perimeter security will fail to notice them. The HTTPS padlock in the browser’s location bar only confirms the identity of the server, but will not prevent you from a watering hole attack. This can often induce a false sense of security at the endpoints, the web server and the site visitors. As a webmaster, if you are transitioning from HTTP to HTTPS and you rely on non-proxy security solutions, you may in fact be inadvertently relaxing your security posture in the process. Application Proxies can help...

read more

Whiz! Bang! ZAP! An Introduction to OWASP’s Zed Attack Proxy

Sojourn To The West Last week I escaped the frozen tundra of the northern mid-western United States to speak at the first OWASP AppSec California event in Santa Monica, California. By the events title alone, the conference gives the intimidating impression of being a web-application-developer-Google-Glass-wearing-fest discussing Hadoop optimizations and query parameterization. The event was actually a very friendly open culture of knowledge sharing and interpersonal networking. I never heard Hadoop mentioned, but I did hear plenty of conversations on today’s best practices for protecting web apps. I’m happy to say I spoke with many interesting and approachable people and made several new professional connections. Neil Matatall, the event coordinator and humble Twitter employee, took an impromptu survey of the attendee’s backgrounds during the opening comments. I was surprised to see that about half of the attendees were developers and the other half were pure Information Security professionals. Awesome! ZAP’ing Bugs One of the talks that connected with me the most was the name-fellow presentation shared with this article. Ben Walther, from Appropriate Control, provided a very engaging introduction to OWASP’s ZAP project. Briefly, ZAP (acronym for Zed Attack Proxy) is a project backed by many Mozilla developers with 30 contributors, many evangelists across the planet and supports 20 different languages, sadly none of them are Klingon. One of the objectives of ZAP is to enable anyone with a rudimentary knowledge of how websites are structured to validate their web app’s security with a very intuitive penetration testing tool. Features such an intercepting proxy, a spider, an active scanner, forceful browsing, a fuzzer, and break points for debugging and testing cookie injections are just the beginning. There is so much that OWASP ZAP can do to easily help find weaknesses in a web app that it earned the ToolsWatch.org’s best security tool for 2013 award #1 ranking. ZAP includes a ‘Plug-n-Hack’ feature for Firefox 24 to configure proxying of your browser HTTP/S traffic through ZAP. Ben Walther provided a mostly hands-on demonstration of the features...

read more

Moar Security War Games

Last weekend, the northern United States was covered with a wintery blanket of snow causing trapped commuters to hack back at the frosty accumulation with shovels to clear a path. Meanwhile Saturday, out of an Ann Arbor, Michigan office building lobby a hand selected team of Information Security professionals were hacking back with their computers in an International Capture The Flag (CTF). On May 17, 2013, I published a primer article titled Security War Games for Dark Reading highlighting the value for an organization to encourage their technologists to partake in security war games for a stronger defensive team. The team of ethical hackers is called MiSec, short for Michigan Security, and were testing their metal against 173 teams spread across the planet. The team captain, Wolfgang Goerlich, Vice President of Consulting Services for VioPoint, asked if I would join the MiSec team to deploy a Barracuda Web Application Firewall (WAF) and Barracuda NG Firewall in front of a highly vulnerable Linux server. The CTF was an attack and defend style competition. This means Mr. Goerlich assigned team leads to organize the attack, known as Red Team, on competitive vulnerable servers while the defensive, Blue Team, was looking to protect their nine services from attacks. That’s where the Barracuda WAF and Barracuda NG Firewall came into the mix. Mr. Goerlich dubbed the Barracuda layers of protection as project “SHIELD”. When asked about the strategy behind using Barracuda technologies, Mr. Goerlich respond, “The goal of project SHIELD was to reduce the number of flags we lose per application, thus increase our total points.” Unfortunately, once we established the lay of the land, as soon as points were earned they were quickly captured by competitors before the tuning can be applied. Mr. Goerlich continued, “We employed a strategy of putting the technology in place, monitoring, and selectively enabling IPS for specific applications.” As shown in the rules graphic, competitive team traffic was restricted from being filtered out, additionally, all hostile activity originated from a single IP...

read more

Survey results show frustration with firewall industry trends

Hey remember the firewall survey we ran a few months ago? The results are in, and there are definitely some eye-openers in there. Let’s look at some of the highlights. 80% of companies don’t know what all of their firewall rules do. Over 55% of companies have had a security gap because of a misconfigured firewall rule. Half of the companies surveyed experienced downtime due to a misconfigured firewall rule. 1 in 4 companies are unsatisfied with the ease of use of their firewall, and 1 in 3 believe that the firewall usability has not kept up with their applications.   These results are indicative of an industry problem, which is that many firewalls have cumbersome and non-intuitive interfaces. When it is difficult to construct rules in the firewall it becomes difficult to keep track of how the rules are configured. Just like any other technology: when you add complexity to technology, you add opportunities for human mistakes. This problem is compounded by the fact that many small and medium sized organizations are having difficulty finding a firewall that is the right size for them. Some SMBs have specific needs that require an enterprise level firewall. Many SMBs simply purchase consumer-grade firewalls to stay away from business-grade prices. This means thousands of organizations are operating with equipment designed for a different purpose. Admins are doing what they can to mold these devices to the contours of their networks. This relates to the usability problem as well. Admins who deploy firewalls often take a “hands-off” approach once their firewalls are working. If it works don’t fix it, and don’t upgrade until it breaks. This makes for a lot of networks where the firewall is the oldest and least usable device in the network. Ultimately the problem with usability comes down to how the industry treats firewalls. While other network applications have evolved and become more relevant, the firewall has continued in its original purpose as a lock on the network door. You can buy a...

read more

Deconstructing the BREACH attack

This post was contributed by Product Manager Nareej Khandelwal and is cross-posted at the Barracuda Product Blog. The Internet is abuzz with discussion on the latest “SSL attack” – BREACH – released last week at Black Hat USA. While the attack is not really an attack of SSL per se, the fact that one can sniff secrets inside of HTTPS gives off that impression to many folks. The attack is meant to steal “secrets” from HTTPS response bodies that are compressed, using HTTP layer compression (gzip, deflate). It’s a side channel attack that targets HTTP compression and not SSL/TLS compression. The later was targeted as part of the CRIME attack last year and is resolved by disabling TLS compression, which already was not widely supported by browsers and servers. However, HTTP response compression is very popular. Prerequisites for the Attack: A user input that is reflected in the attack A secret that is present in the response body (not headers) such as CSRF tokens, or other PII And the response compressed Attacker should be able to view the victim’s encrypted traffic (e.g. via arp spoofing or unsecured wifi). Attacker should be able to send requests on behalf of the victim (e.g. using social engineering to get the victim on an attacker controlled malicious site) What is the root cause? There are two key insights to understanding this attack. One, compression ratio (using deflate, etc.) is proportional to the amount of character repetition. For example, in the following two lines, the first one would compress more, as “sec” is repetitive. secret and secretary secret and boss As a result, the size of the compressed payload will be smaller for the top line. Of course, the compressed payload would be the smallest when you try to compress: secret and secret The second important observation is that while SSL is great at hiding content, it really doesn’t prevent the size of the content from leaking information. The size of the encrypted data is proportional to the size of...

read more

Anatomy of a SQL Injection Attack

Posted by: Oliver Wai, product marketing manager As you probably heard from our previous blog posting, Barracuda Networks suffered a breach from a SQL Injection attack on the weekend of April 8. While the overall impact of the breach turned out to be relatively minor (only contact names, including names and emails), such an event always involves a post-mortem. As is often the case in events such as data breaches or data center outages, there is never one single error that leads to the outage or attack but rather a series of interrelated errors that ultimately results in a failure or vulnerability that can be exploited. Taken individually, each event is usually accounted for by the organization and there are redundancies in place to handle any failure issues. However when taken together, the unexpected – in this case an attack on our site – occurs. In analyzing the attack, we observed: In the rush to continually add timely and fresh content to the corporate Web site, a few mistakes were made in the PHP code. Code vulnerability scanning of the affected part of the Web site was scheduled but had not yet occurred. The Web Application Firewall that was put in place to harden the Web site was put into Passive Mode by human error during a maintenance window. So while there were redundancies in place to secure our Web site, an unfortunate confluence of events last weekend left a vulnerability in our Web site exposed; this resulted in the SQL injection attack by a group we believe to be originating in Malaysia. The upside? Since the Barracuda Web Application Firewall was still inspecting traffic even in Passive Mode, it gave us a detailed audit trail of the SQL Injection probe and the subsequent attack. This gave us the necessary forensics to quickly analyze the breach, contain the damage and reach out to those affected. Analyzing the Attack From our Barracuda Web Application Firewall logs we determined that there were two clients used to...

read more