Capture 414 Error - Webdav Exploit

Why not simply filter in iptables INPUT prior to accepting into server?

Purl Gurl <purlgurl DeleteThis @purlgurl.net> wrote in message news:<4070AAD0.3B1DBC4C DeleteThis @purlgurl.net>...
 > Purl Gurl wrote:
 >
  > > Inspired by recent articles on not logging these
  > > idiotic Webdav exploit log entries, I am hoping
  > > someone has developed a hack for capturing the
  > > associated 414 error generated by Apache.
 >
 > Moving this up in order, a final note on this
 > Webdav exploit problem, imported from another
 > thread to here.
 >
 > Thanks to all who provided information.
 >
 > Imported comments:
 >
 > I have had no success with any of the methods
 > presented and a few of my own.
 >
 > Appears a SEARCH method cannot be captured under
 > any circumstances, not for mod_rewrite, not for
 > mod_security nor for custom access logs. I also
 > found IP Address blocking fails for SEARCH methods.
 >
 > I did hack my compiled Apache core to include
 > the SEARCH method, but this failed as well.
 > Apache loads and runs just fine, but will
 > not recognize that specific method.
 >
 > Appears we are stuck with Webdav and massive
 > thirty-thousand bytes plus log entries. Clearly
 > this is a minor vulnerability in Apache. Perhaps
 > Apache developers will address this in the future.
 >
 > With enough hits at a fast pace, a successful
 > Denial Of Service attack could be had.
 >
 > I am currently looking at developing a transparent
 > firewall to address this problem Apache cannot.
 >
 > I will file a bug report with Apache.
 >
 >
 > Kira<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Capture 414 Error - Webdav Exploit 

Purl Gurl wrote:

(snipped)

 > Inspired by recent articles on not logging these
 > idiotic Webdav exploit log entries, I am hoping
 > someone has developed a hack for capturing the
 > associated 414 error generated by Apache.

Lots of articles, lots of discussion on this,
both here in this newsgroup and elsewhere.

I could not find a good entry point for this
addition to this thread, not really fitting
into the flow of things, so I have moved
this upward in a sense.

Conversations continue with some inside
Apache Org. This person in this email
is really nice, very sincere, and is
associated with Apache Org. I will note
some of our conversations are being
shared with Apache Security, when
I deem this appropriate. This email
is shared with Apache Security.

This specific conversation, actually
bits and pieces of larger dialog,
will afford you an idea of what is
taking place outside of this group.

Some do seem very interested in these
issues and I promised to share my
discoveries. I am doing so.

Beneath my signature you will read a
snippet of conversation which will
provide you with a feel for current
talks and efforts.

Purl Gurl

--

(names other than my own are removed)

 > Purl Gurl wrote:

(snipped)

  > > Keep in mind, Apache has a series of bugs
  > > which leaves users in a bad position, leaves
  > > users in a position of not being able to
  > > do anything, literally, about selected
  > > types of attacks. This inability to
  > > effect a cure, really frustrates me.

 > What you need to keep in mind here, is that Apache is handling these
 > requests exactly correctly. It is denying them access to the server as
 > soon as they are received, thereby preventing any damage from being done.

Apache is not handling this correctly. What is
observed is a spinoff reaction of bugs in Apache.

All that is happening is Apache is generating a 414
error because the URI is too long. If an administrator
decreased acceptable URI length to ten bytes, the
same result would manifest for all requests. If URI
length is increased to fifty-thousand bytes, Webdav
would pass through and generate a 404 not found error.

Apache is not preventing damage. Apache is not performing
a security check. Apache is simply producing an error
condition because of the default URI length check,
and in the process, creating a series of subsequent
bugs, which is a common event in all programming.

An exploit of shorter length would pass through
and be processed, yes? Be sure you, the reader,
understand. An exploit within the default URI
length would be processed. No miracle is being
performed by Apache. It just looks that way.

What Apache should be doing is rejecting Webdav based
on the SEARCH request method which is not recognized.
Don't you see? Apache fails to recognize a SEARCH
request method which is not in its list of accepted
request methods, specific to Apache 1.3.x series,
the best server to date.

Apache fails to catch a SEARCH method, an invalid method.

That is a bug.

What comes before the URI content? The request method.
Apache should drop the connection based on the request
method, not the URI length. It does not.

That is a bug.

Use of IP Address blocking should take precedence over
all other functions. What is the first bit of human
readable data coming in? The IP address. With Webdav,
the IP address is completely ignored rather than being
blocked as it should per httpd conf directives. This
is a failure of IP Address blocking.

That is a bug.

Access logging, you already know of this. It is
impossible to control logging of Webdav or any
logging based on error conditions which cannot
be hooked into, such as a 408 error.

That is a very obvious bug which cannot be denied.

However, some deny this. Nonetheless, I know better
and will not fool myself on this. It is a bad bug.


  > > They are bugs despite bugzilla people
  > > claiming they are not.

 > I'll just note one more time that the bug report was closed not because it
 > wasn't a bug, but because it was not the right place to deal with it.

Ok, then what I presented is a bug although bugzilla
claims is not a bug, actually a number of bugs but
bugzilla does not want to public to know because of
security issues, which are really not security issues
being widespread common knowledge, for a very long time.

However, Apache does not provide any means of discussing
security issues. This is done behind closed doors. The
public is not allowed to participate. What is the greatest
source of information for security? The public.

That is a bug in the thinking of Apache developers.

Closing off security discussions from the public is
absolutely illogical. The public is the number one
source of security issues, and the number one source
of security solutions. Even Microsoft knows this.

That is a bug in the thinking of Apache developers.

Consider this, if I submit a bug report about this
inability to control logging for a 414 error, know
what will happen? Resolved - Invalid.

If I submit a bug report about ip blocking failing
because of a 414 error or other errors, what will
happen? Resolved - Invalid.

Almost all bug reports submitted are closed within
a matter of hours, Resolved - Invalid.

Bugzilla people suffer a serious bug; they don't
want to acknowledge bugs. Resolved - Invalid.

 > I hope the security team is able to analyze this problem and get back to
 > you soon.

Based on a majority of responses to my comments being
exceptionally emotional responses, with almost all
being adamant denials of a problem, I do not expect
to receive feedback on this. My hunch is the security
team will deny and dismiss this, as have most in the
bugzilla branch. Have you taken notice of the amount
of insults and hatred directed at me in the newsgroup?

People do not tolerate any critique of Apache.

That is a serious bug.

Are you aware with the addition of an ability to
filter incoming request methods, an ability to
ip block based on request method, an ability
to use regex matching for URI content, Apache
would begin to approach some of the features
of an inline firewall box costing tens of
thousands of dollars?

Wouldn't features like that be a significant
selling point, a significant profit maker?

"Use Apache and you will not need to spend
ten-thousand dollars on IPS hardware."

Can you imagine how many modules could be
written for Apache if not for these bugs
in Apache which prevent hooking error
conditions? All of these problems could
be resolved by mod_security alone, if
Apache did not have these bugs.

To be sure others are clear on this,
because I know you understand, (NAME),
use of mod_security alone would resolve
all of the issues I have set forth, if
mod_security could perform its great
stuff before a 414 error is generated.
Use of mod_security will also catch
a condition which creates a 408 error,
and will catch many other errors.

Apache not allowing mod_security to
perform its tasks, that is not a bug
but a lack of a feature, which is based
in bugs about which I write.

Actually, that is a bug, isn't it?

Apache would be prudent to think this over
and consider applying this type of thinking
to both Apache 1.3.x and Apache 2.x series,
both or none. This is important because
Apache 1.3.x is the superior server of
the two. Apache 2.x is nice but is almost
all whistles and bells, which some like.

No bugs in my thinking.

Thanks again for your comments, help
and sincere demeanor. Clearly you are not
afraid to discuss serious issues, and I do
highly respect your opinions, even when
in opposition to mine.<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Capture 414 Error - Webdav Exploit 

Bill@Melody wrote:

 > Purl Gurl wrote:
  > > Purl Gurl wrote:

   > > > Inspired by recent articles on not logging these
   > > > idiotic Webdav exploit log entries, I am hoping
   > > > someone has developed a hack for capturing the
   > > > associated 414 error generated by Apache.

 > Why not simply filter in iptables INPUT prior to
 > accepting into server?

(Readers should read Hatema's comments next in thread)

Bill, another suggested iptables, which is a good
idea and I promised to research this. Some links
were provided on this, of a similar nature regarding
transparent proxy firewalling.

First, based on my research to date, the best solution.

This best solution is inline firewall hardware. All of
these problems and significantly more, are solved by
inline firewall hardware. However, prices for these
range from five-thousand to fifty-thousand dollars.

* chokes *

I've have been researching software based solutions,
and found benefits and problems. Benefit is software
solutions afford use of machine CPU and memory which
will usually be better than low end inline boxes.
This is, your own machine has greater processing
power, more speed and greater RAM.

Nonetheless, there is a serious problem with software
solutions, a bottleneck is created. Software solutions
cannot match the speed of broadband connections. Speed
is slowed to maybe DSL speed, about fifty kilobytes per.

Another problem with software is a need to remove all
existing firewall applications. Most software solutions
filter incoming and outgoing traffic but not all
prevent program execution such as Zone Alarm does.

Software solutions require talent and some require
subscription based updates, as do inline boxes.

Most software solutions are specific to Unix, Linux,
BSD and others, but not Windows. No portability.
Software solutions can be very expensive.

Use of iptables is valid but as Hatema points out,
you will be constantly chasing dynamic addresses,
or constantly having to add or remove "regex"
style ip addresses. Big disadvantage is you block
those who should not be blocked.

Use of iptables for Win32 is extremely challenging.

Two major factors have developed in my research.

If you want broadband speed, you must use hardware,
at great expense.

If you want an affordable solution, software, you
must sacrifice speed and other applications.

My hope is to nudge Apache in the direction of
incorporating an ability to add "firewall"
modules for Apache. Ivan Ristic wrote an
excellent module, mod_security, which is
strongly suggested for all Apache users.
You really must use his great module.

Ivan and I have discussed issues specific
to this thread. There is a problem. Ivan's
module cannot "hook" many error conditions,
such as Webdav, not because of his module
but because of Apache not allowing this.

So my logic and approach is to nudge Apache
in the direction of allowing module usage,
such as Ivan's module, within the programming
of Apache core. Doing so would allow Apache
to mimic many of the functions of an inline
firewall box costing thousands of dollars.

Using Apache, with modules, as a firewall,
being open source, would be free and have
very little, if any, effect on speed.

Best solution for now, a thirty-thousand
dollar inline firewall box. That is not
a very good solution.

Purl Gurl<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Capture 414 Error - Webdav Exploit 

Agreed that everybody has unique requirements, sysadmin for Yahoo has
a much different job than sysadmin for my own personal/business
network. For me, placing a a iptables rule in the INPUT table of my
Apache server that looks for port 80 requests (the other ports
attempted by this virus are blocked at the router) that have the text
string "SEARCH /" are referred to a new CHAIN where they are promptly
logged and blocked. This method also works for the NIMDA requests for
those bizzare, non-existent files; if you don't like seeing those in
the httpd error_log as well. Processor time is negligent compared to
the present barrage of huge Webdav messages coming in today.

Regardless of how we handle this BS, we will have to adapt as the
virus perps try differnt tactics.

Best of luck, will take your advice and look for that Apache mod for
this and other future requirements.

Purl Gurl <purlgurl RemoveThis @purlgurl.net> wrote in message news:<40736DB7.2C1ECCF1 RemoveThis @purlgurl.net>...
 > Purl Gurl wrote:
 >
 > (snipped)
 >
  > > Inspired by recent articles on not logging these
  > > idiotic Webdav exploit log entries, I am hoping
  > > someone has developed a hack for capturing the
  > > associated 414 error generated by Apache.
 >
 > Lots of articles, lots of discussion on this,
 > both here in this newsgroup and elsewhere.
 >
 > I could not find a good entry point for this
 > addition to this thread, not really fitting
 > into the flow of things, so I have moved
 > this upward in a sense.
 >
 > Conversations continue with some inside
 > Apache Org. This person in this email
 > is really nice, very sincere, and is
 > associated with Apache Org. I will note
 > some of our conversations are being
 > shared with Apache Security, when
 > I deem this appropriate. This email
 > is shared with Apache Security.
 >
 > This specific conversation, actually
 > bits and pieces of larger dialog,
 > will afford you an idea of what is
 > taking place outside of this group.
 >
 > Some do seem very interested in these
 > issues and I promised to share my
 > discoveries. I am doing so.
 >
 > Beneath my signature you will read a
 > snippet of conversation which will
 > provide you with a feel for current
 > talks and efforts.
 >
 > Purl Gurl
 >
 > --
 >
 > (names other than my own are removed)
 >
  > > Purl Gurl wrote:
 >
 > (snipped)
 >
   > > > Keep in mind, Apache has a series of bugs
   > > > which leaves users in a bad position, leaves
   > > > users in a position of not being able to
   > > > do anything, literally, about selected
   > > > types of attacks. This inability to
   > > > effect a cure, really frustrates me.
 >
  > > What you need to keep in mind here, is that Apache is handling these
  > > requests exactly correctly. It is denying them access to the server as
  > > soon as they are received, thereby preventing any damage from being done.
 >
 > Apache is not handling this correctly. What is
 > observed is a spinoff reaction of bugs in Apache.
 >
 > All that is happening is Apache is generating a 414
 > error because the URI is too long. If an administrator
 > decreased acceptable URI length to ten bytes, the
 > same result would manifest for all requests. If URI
 > length is increased to fifty-thousand bytes, Webdav
 > would pass through and generate a 404 not found error.
 >
 > Apache is not preventing damage. Apache is not performing
 > a security check. Apache is simply producing an error
 > condition because of the default URI length check,
 > and in the process, creating a series of subsequent
 > bugs, which is a common event in all programming.
 >
 > An exploit of shorter length would pass through
 > and be processed, yes? Be sure you, the reader,
 > understand. An exploit within the default URI
 > length would be processed. No miracle is being
 > performed by Apache. It just looks that way.
 >
 > What Apache should be doing is rejecting Webdav based
 > on the SEARCH request method which is not recognized.
 > Don't you see? Apache fails to recognize a SEARCH
 > request method which is not in its list of accepted
 > request methods, specific to Apache 1.3.x series,
 > the best server to date.
 >
 > Apache fails to catch a SEARCH method, an invalid method.
 >
 > That is a bug.
 >
 > What comes before the URI content? The request method.
 > Apache should drop the connection based on the request
 > method, not the URI length. It does not.
 >
 > That is a bug.
 >
 > Use of IP Address blocking should take precedence over
 > all other functions. What is the first bit of human
 > readable data coming in? The IP address. With Webdav,
 > the IP address is completely ignored rather than being
 > blocked as it should per httpd conf directives. This
 > is a failure of IP Address blocking.
 >
 > That is a bug.
 >
 > Access logging, you already know of this. It is
 > impossible to control logging of Webdav or any
 > logging based on error conditions which cannot
 > be hooked into, such as a 408 error.
 >
 > That is a very obvious bug which cannot be denied.
 >
 > However, some deny this. Nonetheless, I know better
 > and will not fool myself on this. It is a bad bug.
 >
 >
   > > > They are bugs despite bugzilla people
   > > > claiming they are not.
 >
  > > I'll just note one more time that the bug report was closed not because it
  > > wasn't a bug, but because it was not the right place to deal with it.
 >
 > Ok, then what I presented is a bug although bugzilla
 > claims is not a bug, actually a number of bugs but
 > bugzilla does not want to public to know because of
 > security issues, which are really not security issues
 > being widespread common knowledge, for a very long time.
 >
 > However, Apache does not provide any means of discussing
 > security issues. This is done behind closed doors. The
 > public is not allowed to participate. What is the greatest
 > source of information for security? The public.
 >
 > That is a bug in the thinking of Apache developers.
 >
 > Closing off security discussions from the public is
 > absolutely illogical. The public is the number one
 > source of security issues, and the number one source
 > of security solutions. Even Microsoft knows this.
 >
 > That is a bug in the thinking of Apache developers.
 >
 > Consider this, if I submit a bug report about this
 > inability to control logging for a 414 error, know
 > what will happen? Resolved - Invalid.
 >
 > If I submit a bug report about ip blocking failing
 > because of a 414 error or other errors, what will
 > happen? Resolved - Invalid.
 >
 > Almost all bug reports submitted are closed within
 > a matter of hours, Resolved - Invalid.
 >
 > Bugzilla people suffer a serious bug; they don't
 > want to acknowledge bugs. Resolved - Invalid.
 >
  > > I hope the security team is able to analyze this problem and get back to
  > > you soon.
 >
 > Based on a majority of responses to my comments being
 > exceptionally emotional responses, with almost all
 > being adamant denials of a problem, I do not expect
 > to receive feedback on this. My hunch is the security
 > team will deny and dismiss this, as have most in the
 > bugzilla branch. Have you taken notice of the amount
 > of insults and hatred directed at me in the newsgroup?
 >
 > People do not tolerate any critique of Apache.
 >
 > That is a serious bug.
 >
 > Are you aware with the addition of an ability to
 > filter incoming request methods, an ability to
 > ip block based on request method, an ability
 > to use regex matching for URI content, Apache
 > would begin to approach some of the features
 > of an inline firewall box costing tens of
 > thousands of dollars?
 >
 > Wouldn't features like that be a significant
 > selling point, a significant profit maker?
 >
 > "Use Apache and you will not need to spend
 > ten-thousand dollars on IPS hardware."
 >
 > Can you imagine how many modules could be
 > written for Apache if not for these bugs
 > in Apache which prevent hooking error
 > conditions? All of these problems could
 > be resolved by mod_security alone, if
 > Apache did not have these bugs.
 >
 > To be sure others are clear on this,
 > because I know you understand, (NAME),
 > use of mod_security alone would resolve
 > all of the issues I have set forth, if
 > mod_security could perform its great
 > stuff before a 414 error is generated.
 > Use of mod_security will also catch
 > a condition which creates a 408 error,
 > and will catch many other errors.
 >
 > Apache not allowing mod_security to
 > perform its tasks, that is not a bug
 > but a lack of a feature, which is based
 > in bugs about which I write.
 >
 > Actually, that is a bug, isn't it?
 >
 > Apache would be prudent to think this over
 > and consider applying this type of thinking
 > to both Apache 1.3.x and Apache 2.x series,
 > both or none. This is important because
 > Apache 1.3.x is the superior server of
 > the two. Apache 2.x is nice but is almost
 > all whistles and bells, which some like.
 >
 > No bugs in my thinking.
 >
 > Thanks again for your comments, help
 > and sincere demeanor. Clearly you are not
 > afraid to discuss serious issues, and I do
 > highly respect your opinions, even when
 > in opposition to mine.<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Capture 414 Error - Webdav Exploit 

Bill@Melody wrote:

(snipped)

(Purl Gurl ranted about Webdav exploits and cures)

 > Agreed that everybody has unique requirements,

 > For me, placing a a iptables rule in the INPUT table of my
 > Apache server that looks for port 80 requests (the other ports
 > attempted by this virus are blocked at the router) that have the text
 > string "SEARCH /" are referred to a new CHAIN where they are promptly
 > logged and blocked. This method also works for the NIMDA requests for
 > those bizzare, non-existent files; if you don't like seeing those in
 > the httpd error_log as well. Processor time is negligent compared to
 > the present barrage of huge Webdav messages coming in today.

 > Regardless of how we handle this BS, we will have to adapt as the
 > virus perps try differnt tactics.

Precisely, Bill. This is in keeping with my long rant
on different methodologies. Some like hardware, some
like software, some like iptables, some like log parsing,
your "unique requirements."

"...adapt as the virus perps try different tactics."

All of us need to adapt to changes. Strength is found
in development of new options, before new virii, before
new exploits arrive. There is really nothing wrong with
Apache, and these new circumstances are not something
developers of Apache could anticipate.

Apache developers have performed with excellence. There
is no question Apache is the best server. However, my
suspicion is Apache developers have become a bit too
self-confident because of this wild success of Apache.

Apache developers need to take a proactive stance,
need to be skeptical of Apache and of their own skills.
Healthy skepticism leads to improvement.

"Processor time is negligent compared to the present
barrage of huge Webdav messages coming in today."

Exactly! System resources are being wasted away
very quickly with no need for this. Apache core
could be mildly modified to prevent this, with
great ease and create significant potential for
new modules which, in turn, improve Apache.

Current conditions, cures for these problems
only lead to more wasting of system resources.
The more we try to cure these problems, the
worse circumstances become.

Script Kiddies are in charge, currently.

Microsoft does have "URL scanning" ability in
their IIS server. A lousy server, but this part
they did right. Apache could do this better
and with greater efficiency, along with allowing
users more control over circumstances.

In this single aspect, URL scanning, Apache is
doing a really lousy job. Apache is inferior
to MS IIS regarding this feature.

I know Apache developers can do better and
they should. There must be five-hundred
Apache module writers out there just waiting
for a chance at this, but cannot do anything,
for now. This does not have to remain so.


Purl Gurl<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Capture 414 Error - Webdav Exploit 

Purl Gurl wrote:

 > Bill@Melody wrote:

 > (Purl Gurl ranted about Webdav exploits and cures)

(snipped)

  > > Agreed that everybody has unique requirements,

  > > Regardless of how we handle this BS, we will have to adapt as the
  > > virus perps try differnt tactics.

 > There must be five-hundred Apache module writers
 > out there just waiting for a chance at this....

For Perl Geeks, like myself, modules really rock!

You will discover, though, through internet resources
I am highly critical of a majority of Perl modules.
However, my opinions are truly of no importance,
other than being annoying to fanatic Perl guru types.

Nonetheless, an example using Perl which relates to
Apache module usage.

With older Perl 4.x series, we use "include" like calls
to pull in outside scripts to perform selected tasks.
Those scripts can supercede perl core itself or perhaps
better, enhance perl core with great leeway.

Using Perl 5.x series, now we use modules which also
can supercede perl core. Same as Perl 4 but better
functionality and better features, such as objects.

Those Perl scripts and modules also allow for
very significant portability between systems.

Apache affords some module usage but only at lower
levels of processing. Apache needs to adapt methods
much like Perl which allows modules to supercede
Apache core functions, at least take the driver's
seat when needed.

Perl, today, enjoys thousands of wonderful modules
performing some of the most outrageous and fun tasks.

Apache enjoys far less modules. Use of modules is
very limited and discourages module writers.

Apache users, all readers, without knowing anything
about Perl, can quickly realize how beneficial it
is to allow module writers greater flexibility.

Apache could learn a lot from the Perl language
and Larry Wall. Heck, Apache could be written
to allow use of Perl modules!

Imagine that, Apache module writers and Perl module
writers, both writing beneficial modules for Apache.

Oh, the mischief I could cause if I could write
Perl programs to work directly with Apache!

* tips her white hat *


Purl Gurl<!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Capture 414 Error - Webdav Exploit