Reading this article from the Guardian, on this guy apparently being banned from fully discussing research results in his talk at upcoming USENIX Security, leaves me scratching my head once more. Things might (as so often) be more complex than they seem, but this looks like yet-another misconception as for the contribution of security research (and its public discussion) to the greater good of us all. Which is unfortunate for the speakers (I’ve been in a similar situation once, receiving a threatening legal letter from a very large organization one day before one of our Black Hat presentations and can tell you that stuff like that doesn’t add to one’s anticipation of the talk or the event…), for the audience (including some ERNW guys who will be a USENIX-SEC, so, btw, expect a summary post here) and for the whole community of security researchers.
Ross Anderson from the University of Cambridge (so just ~ 100 miles from Birmingham, where Flavio Garcia works) formerly gave a very nice response when one of his students was approached in a similar fashion. Based on the publicly available information, the judge in the above case did not follow this reasoning. Which I think, is not a good thing for all of us.
Still, have a great remainder of the weekend everybody,
“Nein! Ein von unbeugsamen Galliern bevölkertes Dorf hört nicht auf, dem Eindringling Widerstand zu leisten.”
This is a famous quote pretty much every German kid used to know. Not sure if this still applies though, my three haven’t touched Asterix comics so far. Anyhow, you might ask why I cite this.
Simple answer: see this recent article from the Guardian on a Utah-based ISP “resisting some pressure”. That’s the spirit…
Some days ago a security advisory related to web application firewalls (WAFs) was published on Full Disclosure. Wendel Guglielmetti Henrique found another bug in the IBM Web Application Firewall which can be used to circumvent the WAF and execute typical web application attacks like SQL injection (click here for details). Wendel talked already (look here) at the Troopers Conference in 2009 about the different techniques to identify and bypass WAFs, so this kind of bypass methods are not quite new.
Nevertheless doing a lot of web application assessments and talking about countermeasures to protect web applications there’s a TOP 1 question I have to answer almost every time: “Wouldn’t it be helpful to install a WAF in front of our web application to protect them from attacks?”. My typical answer is “NO” because it’s better to spent the resources for addressing the problems in the code itself. So I will take this opportunity to write some rants about sense and nonsense of WAFs ;-). Let’s start with some – from our humble position – widespread myths:
1. WAFs will protect a web application from all web attacks .
2. WAFs are transparent and can’t be detected .
3. After installation of a WAF our web application is secure, no further “To Dos” .
4. WAFs are smart, so they can be used with any web application, no matter how complex it is .
5. Vulnerabilities in web applications can’t be fixed in time, only a WAF can help to reduce the attack surface.
And now let us dig a little bit deeper into these myths ;-).
1. WAFs will protect a web application from all web attacks
There are different attack detection models used by common WAFs like signature based detection, behavior based detection or a whitelist approach. These detection models are also known by attackers, so it’s not too hard to construct an attack that will pass the detection engines.
Just a simple example for signatures ;-): Studying sql injection attacks we can learn from all the examples that we can manipulate “WHERE clauses” with attacks like “or 1=1”. This is a typical signature for the detection engine of WAFs, but what about using “or 9=9” or even smarter 😉 “or 14<15”? This might sound ridiculous for most of you, but this already worked at least against one WAF 😉 and there are much more leet attacks to circumvent WAFs (sorry that we don’t disclose any vendor names, but this post is about WAFs in general).
Another point to mention are the different types of attacks against web applications, it’s not all about SQL injection and Cross-Site Scripting attacks, there also logic flaws that can be attacked or the typical privilege escalation problem “can user A access data of user B?”. A WAF can’t protect against these attacks, it a WAF can raise the bar for attackers under some circumstances, but it can’t protect a web application from skilled attackers.
2. WAFs are transparent and can’t be detected
In 2009, initially at Troopers ;-), Wendel and Sandro Gauci published a tool called wafw00f and described their approach to fingerprint WAFs in different talks at security conferences. This already proves that this myth is not true. Furthermore there will be another tool release from ERNW soon, so stay tuned, it will be available for download shortly ;-).
3. After installation of a WAF my web application is secure, no further “To Dos”
WAFs require a lot of operational effort just because web applications offer more and more functionality and the main purpose of a web application is to support the organization’s business. WAF administrators have to ensure that the WAF doesn’t block any legitimate traffic. It’s almost the same as with Intrusion Detection and Prevention Systems, they require a lot of fine tuning to detect important attacks and ensure functionality in parallel. History proves that this didn’t (and still doesn’t) work for most IDS/IPS implementations, why should it work for WAFs ;-)?
4. WAFs are smart, so they can be used with any web application, no matter how complex it is
Today’s web applications are often quite complex, they use DOM based communication, web services with encryption and very often they create a lot of dynamic content. A WAF can’t use a whitelist approach or the behavior based detection model with these complex web applications because the content changes dynamically. This reduces the options to the signature based detection model which is not as effective as many people believe (see myth No. 1).
5. Vulnerabilities in web applications can’t be fixed in time, only a WAF can help to reduce the attack surface
This is one of the most common sales arguments, because it contains a lot of reasonable arguments, but what these sales guys don’t tell is the fact, that a WAF won’t solve your problem either ;-).
Talking about risk analysis the ERNW way we have 3 contributing factors: probability, vulnerability and impact. A WAF won’t have any influance on the impact, because if the vulnerability gets exploited there’s still the same impact. Looking at probabilities with the risk analysis view, you have to take care that you don’t consider existing controls (like WAFs 😉 ) because we’re talking about the probability that someone tries to attack your web application and I think that’s pretty clear that the installation of a WAF won’t change that ;-). So there’s only the vulnerability factor left that you can change with the implementation of controls.
But me let me ask one question using the picture of the Fukushima incident: What is the better solution to protect nuclear plants from tsunamis? 1. Building a high wall around it to protect it from the water? 2. Build the nuclear plant at a place where tsunamis can’t occur?
I think the answer is obvious and it’s the same with web application vulnerabilities, if you fix them there’s no need for a WAF. If you start using a Security Development Lifecycle (SDL) you can reach this goal with reasonable effort ;-), so it’s not a matter of costs.
Clarifying these myths of web application firewalls, I think the conclusions are clear. Spend your resources for fixing the vulnerabilities in your web applications instead of buying another appliance that needs operational effort, only slightly reducing the vulnerability instead of eliminating it and also costing more money. We have quite a lot of experience supporting our customers with a SDL and from this experience we can say, that it works effectively and can be implemented more easily than many people think.
You are still not convinced ;-)? In short we will publish an ERNW Newsletter (our newsletter archive can be found here) describing techniques to detect und circumvent WAFs and also a new tool called TSAKWAF (The Swiss Army Knife for Web Application Firewalls) which implements these techniques for practical use. Maybe this will change your mind ;-).
On Friday we released our latest technical newsletter with the fancy title “Sell Your Own Device – A Field Study on Decommissioning of Mobile Devices”. It is the result of a field study on decommissioned mobile business devices bought on eBay and about how stored data may be extracted in different ways.
As always we love to share plenty of practical advise: At the end of the newsletter you will find the mitigating controls to securely handle mobile devices at the end of their life cycle process.
Find the newsletter here. And a digitally signed version here.
Special thanks go to Sergej Schmidt for performing the field study.
Talking about our great team: Meet the whole ERNW crew at TROOPERS12, or even better: Dig deeper into mobile security together with Rene Graf during the mobile security workshop. There are a few slots left.
Enjoy the newsletter & hopefully see you soon in Heidelberg! Florian
Currently there’s quite some discussion ongoing why it took Apple so long to fix a severe vulnerability in the update process of iTunes. A severe vulnerability which could easily be exploited by means of an automated tool called evilgrade which can be downloaded here (Hi Francisco!). Just one small note here: did you know that evilgrade was first shown and released at the 2008 edition of Troopers? We had a number of initial releases of tools in the last years (like wafw00f at the 2009 edition and VASTO at the 2010 edition) and we will continue this fine tradition in 2012. I can already promise that some nice code is going to be released for the first time at Troopers12…
Once again there’s a reference to some action movie here, as some of you may have immediately spotted ;-).
For the record: this one is from “Snake Plissken”, the main protagonist in John Carpenter’s “Escape from New York”. There’s another well-known quote of the same character in the kind-of sequel “Escape from L.A.” which goes like: “The more things change, the more they stay the same”. I’m aware that this is not the initial source (but French novelist Jean-Baptiste Alphonse Karr presumably is, at the time in French ;-)); still this gives a nice transition to today’s topic.
To make it short: there’s pieces of software out there which – regardless of ongoing attempts to patch or even rewrite them – just remain crap, security-wise. Regular readers of this blog may have seen (read) me mentioning some of those. Right now I’d like to draw your attention to another one of my all-time favorites in the “is crappy. has been crappy for a long time. will probably continue do to so for a long time” list. Curtain up! for ISC BIND.
ISC published this advisory today (in case you’re too lazy to follow the link, here some quick facts: “BIND 9 Resolver crashes after logging an error in query.c”; severity “serious”; exploitable “remotely”; CVSS 7.8). Apparently it’s exploited in the wild. It’s at least the 5th unauthenticated remote DoS in BIND 9 in the last twelve months (here’s their advisories). And here’s another quote, this time from the BIND 10 project page:
“The architecture of BIND 10 concentrates on these technical aspects: modularity, customizability, clusterization, integration, resilience, and runtime control.”
See what’s missing? You got it. So good luck to those of you still running BIND. Call it snake… oil…
This week I stayed some days in Zurich, to give a workshop and to meet both clients and fellow researchers (kudos again to C. for the awesome office tour @Google). In the course of one of those dinners somehow Troopers was mentioned and a guy asked: “I’ve heard of the conference. What’s so special about it?”
Funnily enough I didn’t even have to respond myself as a 2011 attendee coincidentally present at the table jumped in and started praising the event (“best con ever. great spirit, great talks”). Obviously this gave me a big grin… but it reminded as well me that some of you might ask themselves the very same question.
In my opening remarks of the 2011 edition I tried to describe the Troopers approach and spirit. You can find it here. As for the speakers’ perspective I’d like to point you to this blogpost that Chema (Alonso) wrote before the 2010 edition. It pretty much summarizes how we take care of “our rock stars”…
Btw: the CfP will be open in some days. As in the previous years, there are only few slots left (as most are already assigned to hand-selected speakers).
After the basic iCloud discussion in this post, I would like to add some more technical information. The following items are just a loose compilation of facts about the mentioned controls which allow the restriction of iCloud usage. The basic iCloud usage, consisting of backup, document sync, and photo stream, can be deactivated using the most recent version of the iPhone Configuration Utility:
Since there are no default settings for these values, it is necessary to include the disabled entries in existing configuration profiles.
Another new functionality which can be deactivated using configuration profiles is Siri. Even though this functionality is not directly related to the iCloud at first glance, it still bears a big threat potential. Looking at the SLAs of the iPhone 4s, the following paragraph gets relevant: When you use Siri, the things you say will be recorded and sent to Apple to process your requests. Your device will also send Apple other information, such as your first name and nickname; the names, nicknames, and relationship with you (e.g., “my dad”) of your address book contacts; and song names in your collection (collectively, your “User Data”).
So Siri also uses cloud-based services in the background. The following screenshot shows the option to disallow the usage of Siri:
Thinking of this privacy relevant submission of data, another new option of the most recent tool version gets relevant: “Allow diagnostic data to be sent to Apple”. The two checked options in the following screenshots are also new features of the most recent version of the configuration utility:
That’s it for the short configuration option compilation of today, have a great week everybody,
… the corrupt DEA agent in Luc Besson’s great movie “Léon (The Professional)”. I’m sure quite some of you, dear readers, know the plot…
Just before the final shootout, when sending the first men of the NYPD ESU team into Léon’s apartment, he tells them to “Be careful!”. After learning those men got killed he just comments: “I told you”.
[btw: before yelling to bring “EEEEEEEVERYONE!!!!”, as those familiar with the piece will certainly remember ;-)].
I’m fully aware that I risk playing “the arrogant scumbag card” today and that it’s generally not very nice to refer to one’s own earlier statements with an “I told you” attitude (especially if harm was caused to some party), but this is exactly how I feel when reading these news. And – pls believe me – it’s an expression of utmost despair.
How often do organizations have to be told that running Adobe Flash might not be the greatest idea in the world, security-wise? How many statistics like this one (see section “Vulnerabilities” in the bottom part of it) have to see the light of the world until people realize that (quoting from this blogpost) “running Flash on corporate desktops is simply asking for trouble. Asking for trouble loudly. Very loudly.”?
When we wrote this document on configuring IE8 securely we pointed out that using Adobe Flash required a risk acceptance, from our perspective. Man, how I was attacked! for this very statement afterwards in the customer environment that document was initially developed for. I’ve since mentioned Flash in this blog here, here and here.
Furthermore we’ll include a talk on Flash in next year’s Troopers line-up, I promise. And be it only to avoid this post sounding like a crusade of a bitter old man… (yes, this was a wordplay referring to some character from the movie ;-).
A few days ago the European Network and Information Security Agency (ENISA) published this quite interesting document with the exact title. Here’s what it covers:
“The booming smartphone industry has a special way of delivering software to end-users: appstores. Popular appstores have hundreds of thousands of apps for anything from online banking to mosquito repellent, and the most popular stores (Apple Appstore, Google Android market) claim billions of app downloads. But appstores have not escaped the attention of cyber attackers. Over the course of 2011 numerous malicious apps were found, across a variety of smartphone models. Using malicious apps, attackers can easily tap into the vast amount of private data processed on smartphones such as confidential business emails, location data, phone calls, SMS messages and so on. Starting from a threat model for appstores, this paper identifies five lines of defence that must be in place to address malware in appstores: app review, reputation, kill-switches, device security and jails.”
Just read through it and while I’ve never been a big fan of STRIDE (mainly due the application centric approach which simply is not my cup of tea) I have to say it’s applied elegantly to the “app ecosystem” described in the paper.
The doc somewhat accompanies this one titled “Smartphones: Information security risks, opportunities and recommendations for users” (released by ENISA in late 2010), which is a valuable resource in itself.
Overall excellent work from those guys in Heraklion, providing good insight from and for practitioners in the field.
