Bug 765979 - Remote Denial Of Service with Unknow binary compiled by "ev1lut10n"
Summary: Remote Denial Of Service with Unknow binary compiled by "ev1lut10n"
Keywords:
Status: CLOSED DUPLICATE of bug 761327
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:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-09 19:47 UTC by xset1980
Modified: 2011-12-12 15:42 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 761327
Environment:
Last Closed: 2011-12-12 14:48:36 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description xset1980 2011-12-09 19:47:48 UTC
+++ 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.

Comment 1 xset1980 2011-12-09 19:49:55 UTC
Created attachment 544667 [details]
Source Code that cause httpd freeze

is a reversed of the binary compiled by ev1lut10n

Comment 2 Tomas Hoger 2011-12-12 14:48:36 UTC

*** This bug has been marked as a duplicate of bug 761327 ***


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