By: Michael (Micha) Shafir, CTO, MagniFire Websystems Inc.
As time progresses, the battle between hackers and network
administrators wi****ng to protect themselves from network attacks only
intensifies, each side attempting to outsmart the other. Attackers are
continuously figuring out more advanced and malicious ways to attack
web sites while network administrators are trying to stop these
attacks. The situation so far has been one in which the attackers
usually have the first mover advantage overcoming security products
and the network administrators trying to react by constantly improving
their security. The challenge that most administrators and security
vendors face is to develop a security solution that will be
intelligent enough to stop both known as well as unknown attacks so
they will be able to always be a few steps ahead of the hackers.
Current security solutions have done a good job so far protecting web
sites, but we are witnessing a new generation of attacks that require
a new generation of solutions.
Firewalls are a great first line of defense, as they are designed to
protect the information that should not be shared with outside users
on the Internet. However firewalls are suffering from "blind spots" on
their open ****ts when it comes to detecting and stopping attacks that
are using the legitimate application layer forcefully. The problem
starts when you want to offer a service to your customers over the
Internet. In this case you need to allow the users to access your site
first and thus you need to open ****ts on the firewall. For example,
for HTTP applications, ****t 80 has to be opened. From that point
onwards, your site can be accessed through that open ****t, which means
that it's like not having firewall protection at all on that ****t.
This represents a huge flaw in the site's security policy because the
application is then totally unprotected and the possibility of someone
misusing the service to penetrate the web site and attack it becomes
very real.
Intrusion Detection Systems (IDS) are meant to complement firewalls as
another level of security, detecting unauthorized access into the
site. Unfortunately, these systems do nothing to protect against
unknown threats, since most IDSs are signature-based, which means that
they are only as good as their database of stored signatures. Frequent
updates and false-positive alarms are common, making the management of
IDSs time consuming and expensive.
We are now witnessing a new generation of attacks on web sites,
attacking the site through its own application, undetected by the
firewall. These attacks have become more effective and much more
difficult to defeat. For an attacker to launch HTTP compliance script
attacks on a popular or vulnerable site is a relatively simple task.
Take for example the latest AOL "Web Spamming" incident, where by
embedding metatags into the source code, hackers made AOL reroute
thousands of Web searches to a Russian site, improving the site's
rating. A typical approach is to inject a script into a popular object
on any frequently accessed Web site with that will trigger an attack
on another HTTP server, which then becomes the victim. This then
results in a GET attacks that actually look like "legal" request
floods and can cripple the site. Such fake legitimate requests to open
the HTTP or HTTPS homepage are invisible to the firewall since they
look like legitimate traffic. Neither the firewall nor any other
existing security product can differentiate between legitimate users
and fake legitimate request that reach a site. If they can't
differentiate between legitimate traffic and malicious one, how would
they be able to block these attacks?
An excellent example of attacking a site by using the site's own
applications is by "squeezing" the Secure Sockets Layer (SSL)
resources. (Squeezing basically means abusing and overstretching the
resources of the site so that it is not able to give services to
legitimate users). The easiest way to consume SSL connections is to
dry out the SSL's handshake mechanism. Sites using SSL will send you
an encrypted public page first for you to log in. (The transfer of
this traffic will be SSL encrypted). Attackers are abusing this public
page, squeezing the SSL resources by sending faked legitimate SSL
request to this page. Because SSL resources are limited, they quickly
run out so that legitimate users cannot get new SSL connections. This
is a classic SSL squeezing attack that results in a denial of service
to legitimate users.
The fact that the application layer is not protected by today's
security products leads many attackers to target it in order to launch
attacks, so the application actually becomes the attack vehicle. This
should prompt us to ask ourselves a tough question: "are web
applications like Trojan horses"? Unfortunately, the answer is a
resounding 'Yes'. If the applications are not protected by today's
security products and allow attackers to gain access into the network
and attack it, then these applications are acting like Trojan horses.
However, the weak link in today's security policy is not only the
application side; the user at the remote station is also a weak link
by itself. In order to fully understand the end-to-end security issues
of a system which includes users accessing a Web application, we need
to understand that the user at home has all the tools and permissions
that allow him to access the application. This may include VPN or SSL
as well and therefore the complete trust of the application, the
firewalls, the PKIs and IDSs. But how can the application know that
the user is who he claims to be? How can the network administrator be
certain that an attacker has not taken control of some user's station
and is now able to freely access the application and attack it? SSL
and VPN connections do not guarantee that the traffic is legitimate as
they are only an encrypted pipeline. The attacker can get access at
the front end and enter the application directly under the cover of a
legitimate user and pass through all security checks right into the
deepest layers of the network. Once the infected information is opened
at the application server, it's too late. No security system can
inspect an encrypted malicious data on the way in. This is indeed a
troubling situation.
Take for example an on-line bank which is providing service to
thousands of its customers. It is constantly exposed to attacks
through its customers in case their stations' integrity and identity
is compromised. If an attacker takes over or infiltrates a customer's
station, he than will be able to gain full access to the bank and reap
havoc at will. No security mechanism will be able to detect this
attack until it's too late. A possible solution might be to install a
personal firewall on every user station. But this will never pass the
reality test. The cost and complexity of dealing with a large number
of private users and the problems they will face make this proposition
impossible form the start. The only solution is to have a security
solution on the bank's site that will be able to detect and stop
application level attacks.
Despite the widespread use of firewalls and other security solutions,
there are obvious holes in the overall security of many web sites. The
application itself often provides a point of access for hackers to
launch attacks and thus acts like a Trojan horse, allowing attackers
to attack web sites with their own application. A new generation of
security solutions is now needed; one that can effectively detect and
protect against application level attacks and one that is intelligent
enough to constantly learn to protect both known and unknown attacks.
This is the only way to provide the highest level of security to web
applications.
---------------------------------------------------------------------------=
-----
=A9 Michael (Micha) Shafir CTO, MagniFire Websystems Inc.
micha AT magnifire.com
|
