Bug 761327 - Remote Denial Of Service with Unknow binary compiled by "ev1lut10n"
Summary: Remote Denial Of Service with Unknow binary compiled by "ev1lut10n"
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: httpd
Version: 16
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Joe Orton
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened, Security
: 761312 765979 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-08 03:50 UTC by xset1980
Modified: 2013-02-01 15:59 UTC (History)
9 users (show)

(edit)
Clone Of:
: 765979 (view as bug list)
(edit)
Last Closed: 2012-06-06 16:08:14 UTC


Attachments (Terms of Use)
exploit and access_log file into .tar.gz (5.73 KB, application/x-gzip)
2011-12-08 03:53 UTC, xset1980
no flags Details

Description xset1980 2011-12-08 03:50:42 UTC
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

Comment 1 xset1980 2011-12-08 03:53:06 UTC
Created attachment 542354 [details]
exploit and access_log file into .tar.gz

Comment 2 xset1980 2011-12-08 03:58:12 UTC
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@yahoo.com
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

Comment 3 Tomas Hoger 2011-12-08 15:31:22 UTC
Making this public, as your other bug, as well as your references, are already public.

Comment 4 xset1980 2011-12-08 17:29:27 UTC
(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-

Comment 5 Tomas Hoger 2011-12-08 18:23:02 UTC
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.

Comment 7 xset1980 2011-12-08 20:03:05 UTC
@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

Comment 10 Tomas Hoger 2011-12-09 07:51:16 UTC
*** Bug 761312 has been marked as a duplicate of this bug. ***

Comment 11 Tomas Hoger 2011-12-09 08:21:18 UTC
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.

Comment 12 Ramon de C Valle 2011-12-09 08:46:01 UTC
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.

Comment 13 xset1980 2011-12-09 18:48:53 UTC
@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?.

Comment 14 xset1980 2011-12-09 19:45:31 UTC
@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.

Comment 15 Tomas Hoger 2011-12-12 14:48:01 UTC
As noted above, you can protect by limiting the number of connections per IP.  You can do that using e.g. iptables connlimit (see example in e.g. bug #508238, comment #2).

You can find few tips in httpd docs:
http://httpd.apache.org/docs/trunk/misc/security_tips.html#dos

and some discussion of the similar attack concept:
https://lwn.net/Articles/338407/

Comment 16 Tomas Hoger 2011-12-12 14:48:37 UTC
*** Bug 765979 has been marked as a duplicate of this bug. ***

Comment 17 Tomas Hoger 2011-12-21 09:49:25 UTC
ev1lut10n source, with few tweaks since the original version:

http://packetstormsecurity.org/files/107923/rapache2.c

This version too has a problem of sending an incomplete header, as was noted in comment #11.

Comment 18 xset1980 2011-12-24 02:40:51 UTC
@Tomas Hoger

Yes, limiting the number of connections per IP the trouble is solved, _but_, NGINX, Cherokee are not vulnerable (not freeze the web server, only aumented the forker process in CPU usage), but both respond ever.
Apache httpd most efficient "fix", without using iptables, is:

Timeout 3
KeepAlive Off
MaxKeepAliveRequest 0
KeepAliveTimeout 10

With this settings in httpd.conf is parcially solved, the apache 2.2.21 and 2.2.15 freezes 3 seconds with rapache attack and after attack, work fine, but NGINX and cherokee with default configuration, they ignore the bad request of rapache or rapache2 exploit, so, is not a bug and is *a bad code of apache* or is a little bug?.-

Regards.

Comment 19 Joe Orton 2012-06-06 16:08:14 UTC
Being able to hit configured (or default) connection limits is not a bug, it is inevitable.  Everything else is explained by the links provided by Tomas above.


Note You need to log in before you can comment on or make changes to this bug.