Market hype: “Application Firewalls”, take #2

i’ve been contacted by several people after the previous post on this subject. they asked some questions and raised some points to support and counter the points made in that post. all these questions were about the web vulnerabilities part, not about the http filtering part (“everything over http”)

i’d like to discuss these here and try to answer them to the best of my ability.

i believe in the concept of an application firewall as introduced years ago (long before the web age), just like i know that it is too difficult to implement in most cases and was generally abandoned back then.
in the case of web application firewalls of today’s making, they simply don’t do what they claim.

it is my personal belief that today’s web application firewalls are a waste of money. some people disagree and as i respect them, i will answer their questions one by one, hopefully to their satisfaction.

what made me come to these conclusions?
well, during 2004-2005, among my duties was also the task of securing a server farm of about 200 web servers, most holding several web sites, and sensitive at that (i.e. under constant attack).
some of these servers held only one simple html page. most were updated throughout the day, every day. cms + db + pki authentication. mostly .net or asp built.

being in charge of security, it’s my job to secure the web farm in spite and hopefully together with the production and business needs and sometimes people (good people) who saw security as an hindrance to their work and achieving their goals.

we’ve never been successfully hacked (to our knowledge, naturally).

as we are located in israel and in an often-attacked location with some prestige, most of these companies (from which some of also happen to be located in israel) often came to offer us a pilot of their products.

after testing 4 different web application firewalls, 3 commercial proxies and 5 ips devices (or was it 4? does snort count as an ips or web security system?), i personally had enough.
when you run out of excuses and money to waste, that is one of the conclusions you get to.

don’t take my word for it. keep believing the vendors (these, not all vendors) that show up just to sell an half-done (sucky) product.

these products, when it comes down to it (web-wise) only provide with limited protection and then mostly against a usually solvable problem – sql injections, while adding a potential vulnerability to your network.

how so?

most of these products may appear to be a closed black-box embedded systems, but they are not. i checked into each and every one of them. this is what i usually found:

1. linux or windows.
2. a mass of open ports.
3. unpatched and barely secure machines.
some vendors were a lot better than others, but mostly that was the case.

the year 2005, from this perspective, was the year of the security vendors vulnerabilities. we learned the harsh lesson that there are always bugs (vulnerabilities), no matter how hard one tries to eliminate them. we also learned a harsher lesson. some security vendors are not doing much to secure their applications.

for these reasons and others adding an extra potentially vulnerable device to your network, often even before your network entry-point or firewall, as well as having to rely on the vendor as a 3rd party supplier of patches for their appliance (running a 3rd party operating system and 3rd party applications) makes these devices yet another security risk which shouldn’t be put there unless necessary.

unrelated but important for the illustration: on several occasions in my testing, the web application firewalls also locked-up traffic to the protected servers without any warning or explanation.
‘all’s well’ is what they told me and it took some time to debug the situation and realize my perfectly working application has f*cked up yet again.
this is a bug and therefore shouldn’t really be held against them (depending on your point of view on production systems’ stability and the vendors creating them), but it comes to show the critical potentially dangerous role of these sniffers or bridges sitting on your network in a central location.

there is another problem i do not discuss in the earlier post on this subject:
what of the pages being updated through-out the day, surely you can’t fix a problem you don’t know about?

the people who mentioned this are absolutely right. you can’t. thing is, web application firewalls are not the solution for these problems. they are a very partial solution for just a few of these problems.

how so?

web application firewalls, despite claims by some vendors, are mostly about stopping sql injections and a bit of xss (short for css – cross site scripting). their anomaly detection methods are far from perfect and they cannot stop most attacks.

why?

because real attackers (as opposed to kiddies, automated tools and worms) are smarter than using “script” — which is the trigger word for one of the signatures in your web application firewall.
as another example, there are too many ways for an attacker to send “select”. he or she can do it in many ways or even insert a different comment after every character or 3. with ms sql it is even worse as it is built to understand the most weird and typo-full queries and make them into legal ones.

aside to all that, all the web application firewalls i tested proved to have a very high false positive rate (or detect very little and then have a pretty good one that sells well).

back to the original question:
what of the pages being updated through-out the day, surely you can’t fix a problem you don’t know about?

i’d like to connect this question with penetration testing.

most of us use pen-testers to try and break into our web pages at least once a year (i hope so). that in itself is the same problem — what happens between these tests?

well, considering dmirty’s latest post which illustrated amazingly well what some (not all!!) pen-tests are like (read the comments)…

a question:
in the case of web pages and simple network pen-tests (nothing against real pen-testers — why pay for the service done by an imperfect human being, if they just stump their own logo on the report created by automated programs they got on the web, bought or created themselves?

today you have several companies selling such products for your own use, in a cost that you can cover in the price it would cost you for on to 10 pen-tests, depending on the job. these products are called vulnerability scanners.

web vulnerability scanning provides with a report on as many systems as you like (or paid for under your license), as well as keeps doing it indefinitely, providing your with alerts in semi-real-time
also, the automated product scans a lot more extensively than a single pen-test due to never stopping, unlike a pen-test that’s usually supposed to show you how you’ve been compromised and stop (depending on the job, naturally).
once that happens most won’t pay for an extra test.

another question i got in email was:
what of third party products? often we can’t and are not allowed to fix those.

i have no solution for you except to suggest you choose what products you buy carefully, as well as make sure ahead of time what the vendor’s responsibility is toward fixing possible future holes and how soon they will do it. make sure and ask how much it will cost you.
also ask about patching their 3rd party operating system and 3rd party applications running on that os.

once a friend of mine encountered a company that refused to acknowledge they run on windows, even after he showed them a port-scan and connection results from an open file share. :)
the people you may interact with may not be aware of it, but i would strongly recommend you do your due diligence on this rather than rely on the vendor. a port scan may be a cheap and efficient way to achieve this.

two easy ways i’d strongly recommend for testing the products:

1. try and attack the web page while the product is working and well-configured.
2. port-scan it.

last, i’d like to discuss fixing sql injections and xss problems.

use google, find tutorials, explanations and a lot of other resources. this problem is solvable — solve it.

first get rid of all the ones you have, then try adding extra protection that is good against the worst of kiddies in its current state of evolution.

i truly hope this type of so called web “application firewalls” grow and become far better, but today in my opinion that is simply not the case.

at this point i’d like to say i’d love to see a working “as promised” web application firewall.
i honestly got fond of them and their potential, even if they are mostly un-necessary if people actually fix these bugs like they should. they really are easy to fix.

current web application firewalls can still be useful, but first do your due diligence — find and fix the holes.

you can find the original article of which this follow-up is about here:
http://blogs.securiteam.com/index.php/archives/220.

gadi evron,
ge@beyondsecurity.com.

Share
  • Pingback: SecuriTeam Blogs » Market hype: “Application Firewalls” (everything over HTTP and web vulnerabilities)

  • http://www.stratumsec.net Trevor Hawthorn

    Bottom line, one-size-fits-all signature-based attack detection does not protect custom-made web application.

    The other issue that vendors fail to mention is that even if you don’t subvert application logic via a good ol’ application attack (read: trigger a signature), you can still game the application and own the crap out of the target. I’ve performed plenty of tests where the app was well done, good input validation, etc. But there were logic flaws that allowed me to subvert app logic and gain access to the platform. NOTHING I did triggered any alerts, etc. After all, it was all “normal” traffic.

    A good example for those that don’t have access to app firewalls is mod_security (www.modsecurity.org). It has a few signatures but most of the tuning is left to the user. As it turns out it’s not easy to write signatures that: 1.) Stop bad stuff, 2.) Let your app work. :)

    I tell my customers to take that budget you had slotted for the app firewall and get yourself a functional application security assessment, source code review (security relevant portions of code), and a secure application development training course put on by some clued people.

    Applications are showing security people that traditional security controls can no longer force applications to behave. Software is changing everything, the security world isn’t any different.

  • sunshine

    Yep.

    I’d like to stress that these tools *can* be useful (some companies are fair about what their products can do). Still, the waste is unclear to me as the problem is *mostly* solvable and people can in most cases fix the holes. Why bother pay so much *before* you’ve done even that effort?

    As we demonstrated this isn’t true for all cases, but it is true for 99% of the market (I just made that number up and I believe in it. You don’t have to).

  • Pingback: Waterloo Systems