+++ This bug was initially created as a clone of Bug #761327 +++ Description of problem: Searching in the web, i found a exploit compiled, that the author not show ANY source code, only delivery a binary compiled in ubuntu (i see in hexedit). The binary is a MODIFIED killapache.pl of Kingcope, the variant is that is realized in C, and the byte range is 0-,0- and not 0-100 like Kingcope, in order, too simulate to remote host that the request is originated in localhost, no in the attacker host, causing a denial of service un httpd service. Apache no respond while the exploit is being launched, if is stopped, show a lot of information in access_log and restore the service in 2 minutes aprox. Version-Release number of selected component (if applicable): Fedora 16 - httpd-2.2.21-1.fc16.x86_64 How reproducible: run ./rapache remote_host_ip_here for a 2-3 minutes Steps to Reproduce: 1.Download the code 2.Run 3. Actual results: Apache server no respond during attack Expected results: Apache identify the attacker, and no confund the localhost with remote host Additional info: I no have the source code of the exploit, is NOT malware, only for test, and the author NOT release its source code, is NOT a security research, is a bad boy. The test is realized in this mode: inet or lan, both tested, in the case of this bug report, lan network (i have 3 boxes with fedora). Attacker: 192.168.0.12 Victim: 192.168.0.10 ################################################################ time ./rapache 192.168.0.10 Remote Apache Denial of Service Exploit by ev1lut10n [+] Attacking 192.168.0.10 please wait in minutes ... ^C[3] Terminado ./rapache 192.168.0.10 [4]+ Detenido ./rapache 192.168.0.10 real 0m21.458s user 0m0.000s sys 0m0.000s ################################################################ Attach access_log after ctrl+c to exploit and killall rapache process Attach exploit --- Additional comment from xset1980 on 2011-12-07 22:53:06 EST --- Created attachment 542354 [details] exploit and access_log file into .tar.gz --- Additional comment from xset1980 on 2011-12-07 22:58:12 EST --- http://myw1sd0m.blogspot.com/2011/09/remote-apache-denial-of-service-exploit.html http://jayakonstruksi.com/backupintsec/rapache.tgz Remote Apache Denial of Service Exploit | coded by ev1lut10n Download url : http://jayakonstruksi.com/backupintsec/rapache.tgz bug found by : Nikolaus Rango (Kingcope) sploit coded by : ev1lut10n evllut10n's email : ev1lut10n_exploit ev1lut10n's gopher : gopher://sdf.org/1/users/ev1lut10 thanks to: X-hack, Danzel, superman,flyff666,peneter,wenkhairu, fadli,gunslinger,petimati,net_spy, and all my friends and you ! ================= root@ev1l:/home/ev1lut10n# ./rapache Remote Apache Denial of Service Exploit by ev1lut10n [-] Usage : ./rapache hostname root@ev1l:/home/ev1lut10n# =================== =========== affected: Apache HTTP Server 1.3.x, 2.0.x through 2.0.64, and 2.2.x through 2.2.19 ============== Diposkan oleh mywisdom di 10:55 Kirimkan Ini lewat Email BlogThis! Berbagi ke Twitter Berbagi ke Facebook --- Additional comment from thoger on 2011-12-08 10:31:22 EST --- Making this public, as your other bug, as well as your references, are already public. --- Additional comment from xset1980 on 2011-12-08 12:29:27 EST --- (In reply to comment #3) > Making this public, as your other bug, as well as your references, are already > public. Ok, no problem, but, i did not know that _this_ particular exploit, modified by ev1lut10n, was public and was being used, since by looking at the creation date, i supposed it was already fixed. Besides that, I did not saw it reported, wich caught my attention, added to the fact that on Freenode's IRC, either in support and social channels for Fedora, they did not pay attention to it, arguing it was my issue, and that in Fedora this didn't occur. So, is because of this i assumed that it wasn't public, and I followed the guide, wich indicated, that if it was a security issue should be mark as private. Anyway, you should know better about this than me, so from my side, the task of making a PoC, has already been done. Regards, Sp0ck -irc.freenode.net- --- Additional comment from thoger on 2011-12-08 13:23:02 EST --- I opted to make this public as the RHEL version of this bug (bug #761312) had the same details and was public, but also because we've already spent time looking into this and have no reason to believe there is a problem with the current fix for the CVE-2011-3192 issue. More information should appear here soon. Thank you for bringing this to our attention. --- Additional comment from xset1980 on 2011-12-08 15:03:05 EST --- @Tomas Hoger Ok, is true, and good for me. The old code in perl of Kingcope is solved with the actual fix (updates), but the new code of rapache no cause the same impact, no high cpu usage and memory, only freeze the httpd server, and the actual versions, fixed, are vulnerable too, the only change that i see is the range, 0-100 replaced by 0-,0-, anyway, i think that depend of Apache Foundation. Other thing!, the actual mitigation method, no work :( Regards. sp0ck --- Additional comment from thoger on 2011-12-09 02:51:16 EST --- *** Bug 761312 has been marked as a duplicate of this bug. *** --- Additional comment from thoger on 2011-12-09 03:21:18 EST --- The mentioned rapache binary is not related to CVE-2011-3192 and Kingcope's killapache.pl and is not a modified / improved variant of it. It does sent a suspiciously-looking Range header with value "0-,0-", but the header is never processed. This is because rapache does not send a valid HTTP request, what is sent lacks proper terminating blank line. Therefore, httpd never sees complete request and eventually times out and drops connection that only provided invalid request. It is unclear, if the Range header is used as disguise, or the intention was to exploit CVE-2011-3192, but it wasn't coded properly. This program starts new threads and opens new connections to target server without any limit. Therefore, if no other protection is in place, it quickly exhausts httpd's connection limit (you should see an error about MaxClients being reached), which blocks connections from other clients. This is no novel attack, but a problem that affects any network-facing service and can be mitigated by e.g. enforcing connection limit per IP. --- Additional comment from rcvalle on 2011-12-09 03:46:01 EST --- I haven't analysed this. However, my guess is that this could be the result of the httpd processing the combination of an invalid "Range" header with an "Accept-Encoding: gzip" within a malformed or non finished HEAD HTTP/1.1 request. --- Additional comment from xset1980 on 2011-12-09 13:48:53 EST --- @Tomas Hoger Aha, and what is the mitigation mode?, because is the same effect in NGINX and Apache running in Windows XP, so, how fix it in my server?. --- Additional comment from xset1980 on 2011-12-09 14:45:31 EST --- @Tomas Hoger Mmm... I'm normal user without any militar computer installation or NASA cluster, or use Cisco product related. I'm normal an user that ask, why occurs this?, If I used Windows with Apache and occurs too. So, this is independent of operative system I use, Linux, OpenBSD, NetBSD on all. However, I try to take down a IIS without successful. IIS resists this "attacks". Why happens this? Too, If you can see the log I added that Apache make auto-petition and source code of this script see make a localhost HEAD petition. In addition to, I tried to see that Apache did it, with netcat and I could see it. So, Apache and other server "believe" this/these petition and attend it. Not only is distress about MaxClients, if not try to attend auto-petitions, but this "dummy" registered on Apache log.
Created attachment 544667 [details] Source Code that cause httpd freeze is a reversed of the binary compiled by ev1lut10n
*** This bug has been marked as a duplicate of bug 761327 ***