Full Disclosure mailing list archives
Re: Apache Killer
From: GloW - XD <doomxd () gmail com>
Date: Wed, 14 Sep 2011 12:28:19 +1000
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 () gmail 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 tokcopere this myself, discussed the size of each bucket wich can be made to stupendous amounts and using a different vector, ok, instead ofRange: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 asrangecode. 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/
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Re: Apache Killer xD 0x41 (Sep 13)
- Re: Apache Killer Javier Bassi (Sep 13)
- Re: Apache Killer GloW - XD (Sep 13)
- Re: Apache Killer Javier Bassi (Sep 13)