Date: Wed, 14 Sep 2011 12:28:19 +1000
From: GloW - XD <doomxd@...il.com>
To: Javier Bassi <javierbassi@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Apache Killer

Aha this is exactly what me and kcope were discussing, and he pointed out
that size exactly (however he did not know how to replicate to get to it i
think),he mentioned the bucket size being able to be pushed to the exact
amount you just said then, wich is alone enough to really reak some havoc on
things with even using this still ithin the bouncs of the httpd, altho i am
guessing if you send a huge amount of the right request, it would cause a
DoS also. i am about to look at your code and hope i havent just repeated
what you said (again), but your spoton about where im speaking about and
exactly what i meant... the size is the problem wich is still underlying
things, if set very high, this consumes more resources on the target... wich
can be a persistent attack really until this code is limited or, changed, or
a mod made for ranges wich handles the ranges and any overflowing or misuse
by local users, this is the biggest problem here, a malicious local user...
i am suprised no one has tried to make this bigger yet, i know that there is
a seperate apache attacking script wich was posted (mn.pl) but this did not
have the sufficient pulling power of a request-Range type attack... wich if
dne right, i think could still lead to possibly atleast a local memory
exhaustion... i dont think it could get as bad as the actual bug was, but
with the range boundarys how they are, and filter settings against things
like 'bytes=' and to monitor if bytes=0-, wich is kinda useless, if you use
ByTes= the filter is useless... unless there is some settings made specially
for upper/lower and even setting spaces in between..
I guess this is still a problem when you have the size of one single bucket
at 2725, and i have heard, even higher, that was actually the first reason
this whole thing came about, was the discussions around the size of ONE
container alone, wich at that time was about 4850 i believe, around that
figure... so, it has not chnged much, or it has not changed atall i have not
tried to build it in a way that can cause destruction fast,but from what i
did see and read, if setup right, the range function or request-range, could
eat memory and spit it out like chewing tobacco.
Anyhow, to me it is still partly an issue, I am looking for a way to now
block ALL Request-Range requests, and range: requests, in BSD8.2 (stable)
Ipfw rules, so i guess this will have to be good to block this, or maybe a
script running alongside apache to watch the range sizes, but, i will still
persist with trying to find a better solution than range fileds,or a better
way to recieve and handle ALL range requests, it is still not good enough
from a produxction endpoint, altho it might be worth checking the range
filter section and maybe add to it something where it automatically blocks
mutiple single digit ex: 5- , 5- , 5- - block it (higher) number requests..
it is not much but, it is the only thing wich seems to be repetitious to
make any of these attacks now effective, considering the advisory sparked a
tonne of apache updates wich is fine by me, as i watched the damage it did
to a completely un protected box and my jaw dropped.. but to then know it is
still possible to do almost the same thing, using the same code, well, thats
just not designed right... coders could easily code things within limits of
the ranges wich would be set lower if that is a security measure ever used,
then i dont know why it has not been deployed already.
People adapt, computers dont adapt without human intervention..
A trigger to notify/warn of large requests or some halt on requesting until
admin is there, i dont know but there has to be a better way to restrict the
range fields or containers or whatever people are calling it, but to me when
something says bytes= , then thats = data.
I hope that your apachekiller.pl doesnt kill my box to hard, but thanks for
also your interest, and i know many others still hate to admit it but, it is
the biggest thing really to hit apache for along time, something wich forced
alot of updates, and some boxes may not even be able to have anything more
done than medium patches, or temp fixes, because of just setup or the way
the person has configured things, or it would take them to rebuild theyre
entire network... this is what has occurred, and many boxes are still just
not tested to it, the first exploit.pl for that was NOT correct because it
involved mod-deflate and mod_gzip wich later from kcopes own mouth he said
this was inn error, but, that code was still enough to do the job for
pentesting.. still, it was not made according to the end advisory, and
should be done that way, so all fields are tested, and all areas of the
httpd are pushed, with some debug action to help people debug theyre
networks, it would surely not be hard todo this, it is still a problem, and
it wont go away unless the right tools are there to test for it everytime,
and yea sure could maybe add to the code but really, it needed a recode for
pentest environment, where you see range-size,and other things wich would be
useful to helping the debug process.
i guess it is a matter of 'go do it yaself' but, if i must, then i will..and
any code wich assists this to be a proper-exploit, so fits the advisory wich
was given, kcopes worked great but, mixed with abit of later coded scripts,
it could probably be much better for debug anyhow.
I will try my best to work with the killapache2.pl wich would have a major
underlying problem still visible from what has been said, so i guess this
would probably be more functional scripting to use to make it, reverse-code
of the apache killer,wich includes debug+byte-size alignment to be high,
sounds good to me!
thanks for your interest, this topic is a huge one,so i guess it is great to
be part of it, cheers,
xd / dru



On 14 September 2011 11:36, Javier Bassi <javierbassi@...il.com> wrote:

> On Mon, Sep 12, 2011 at 11:26 PM, xD 0x41 wrote:
> > I know this topic is OLD but, i just wonder and, also having spoken to
> kcope
> > re this myself, discussed the size of each bucket wich can be made to
> > stupendous amounts and using a different vector, ok, instead of
> Range:bytes=
> > , picture a GET request with as was shown in the code is there, you
> > "Request-Range: bytes=5-,5-69,5-" , now we have bypassed most filters
> > already in place, and the request range code, is exactly the same as
> range
> > code.
> > Only one person spotted this.
>
> HTTPD advisory was very clear that both Range and Request-Range can be
> used. Everyone who unset Range probably unset Request-Range too. If
> host is vulnerable its a little better to use Range because using
> Request-Range will take 8 bytes more. (more bytes = less ranges)
>
> I have tested a bit the exploit and saw 1300 ranges is just a fixed
> number chosen by kingcope but it can be a little bigger. Range field
> can be almost 8KB long and its a total waste of bytes to use x-y,
> format where y is an increasing number that will take more than one
> digit. So instead of 1300 you can get it to 2725 max if you use repeat
> x-, where x is always single digit number. By doing that the exploit
> gets much more effective.
>
> I have attached the source if anyone cares
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists