Re: [Full-disclosure] Advisory: Range header DoS vulnerability Apache HTTPD 1.3/2.x (CVE-2011-3192)
On 08/24/2011 07:55 PM, Dirk-Willem van Gulik wrote:
Apache HTTPD Security ADVISORY
==
UPDATE 1
Title: Range header DoS vulnerability Apache HTTPD 1.3/2.x
CVE: CVE-2011-3192
Last Change: 20110824 1800Z
Date:20110824 1600Z
Product: Apache HTTPD Web Server
Versions:Apache 1.3 all versions, Apache 2 all versions
Description:
A denial of service vulnerability has been found in the way the multiple
overlapping ranges are handled by the Apache HTTPD server:
http://seclists.org/fulldisclosure/2011/Aug/175
An attack tool is circulating in the wild. Active use of this tools has
been observed.
The attack can be done remotely and with a modest number of requests can
cause very significant memory and CPU usage on the server.
The default Apache HTTPD installation is vulnerable.
There is currently no patch/new version of Apache HTTPD which fixes this
vulnerability. This advisory will be updated when a long term fix
is available.
A full fix is expected in the next 48 hours.
Mitigation:
There are several immediate options to mitigate this issue until a full fix
is available:
1) Use SetEnvIf or mod_rewrite to detect a large number of ranges and then
either ignore the Range: header or reject the request.
Option 1: (Apache 2.0 and 2.2)
# Drop the Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
# optional logging.
CustomLog logs/range-CVE-2011-3192.log common env=bad-range
Option 2: (Also for Apache 1.3)
# Reject request when more than 5 ranges in the Range: header.
# CVE-2011-3192
#
RewriteEngine on
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
RewriteRule .* - [F]
The number 5 is arbitrary. Several 10's should not be an issue and may be
required for sites which for example serve PDFs to very high end eReaders
or use things such complex http based video streaming.
2) Limit the size of the request field to a few hundred bytes. Note that
while
this keeps the offending Range header short - it may break other headers;
such as sizeable cookies or security fields.
LimitRequestFieldSize 200
Note that as the attack evolves in the field you are likely to have
to further limit this and/or impose other LimitRequestFields limits.
See: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize
3) Use mod_headers to completely dis-allow the use of Range headers:
RequestHeader unset Range
Note that this may break certain clients - such as those used for
e-Readers and progressive/http-streaming video.
4) Deploy a Range header count module as a temporary stopgap measure:
http://people.apache.org/~dirkx/mod_rangecnt.c
Precompiled binaries for some platforms are available at:
http://people.apache.org/~dirkx/BINARIES.txt
5) Apply any of the current patches under discussion - such as:
http://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3ccaapsnn2po-d-c4nqt_tes2rrwizr7urefhtkpwbc1b+k1dq...@mail.gmail.com%3e
OS and Vendor specific information
==
Red Hat: Option 1 cannot be used on Red Hat Enterprise Linux 4.
https://bugzilla.redhat.com/show_bug.cgi?id=732928
NetWare: Pre compiled binaries available.
Actions:
Apache HTTPD users who are concerned about a DoS attack against their server
should consider implementing any of the above mitigations immediately.
When using a third party attack tool to verify vulnerability - know that most
of the versions in the wild currently check for the presence of mod_deflate;
and will (mis)report that your server is not vulnerable if this module is not
present. This vulnerability is not dependent on presence or absence of
that module.
Planning:
=
This advisory will be updated when new information, a patch or a new release
is available. A patch or new apache release for Apache 2.0 and 2.2 is
expected
in the next 48 hours. Note that, while popular, Apache 1.3 is deprecated.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Everyone must be also aware of the Request-Range except the Range
field in the header.
From the byterange source
(http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/modules/http/byterange_filter.c)
if (!(range = apr_table_get(r-headers_in, Range))) {
range = apr_table_get(r-headers_in, Request-Range);
}
Advisories must
[Full-disclosure] Advisory: Range header DoS vulnerability Apache HTTPD 1.3/2.x (CVE-2011-3192)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Apache HTTPD Security ADVISORY
==
UPDATE 2
Title: Range header DoS vulnerability Apache HTTPD 1.3/2.x
CVE: CVE-2011-3192
Last Change: 20110826 1030Z
Date:20110824 1600Z
Product: Apache HTTPD Web Server
Versions:Apache 1.3 all versions, Apache 2 all versions
Changes since last update
=
In addition to the 'Range' header - the 'Range-Request' header is equally
affected. Furthermore various vendor updates, improved regexes (speed and
accommodating a different and new attack pattern).
Description:
A denial of service vulnerability has been found in the way the multiple
overlapping ranges are handled by the Apache HTTPD server:
http://seclists.org/fulldisclosure/2011/Aug/175
An attack tool is circulating in the wild. Active use of this tool has
been observed.
The attack can be done remotely and with a modest number of requests can
cause very significant memory and CPU usage on the server.
The default Apache HTTPD installation is vulnerable.
There is currently no patch/new version of Apache HTTPD which fixes this
vulnerability. This advisory will be updated when a long term fix
is available.
A full fix is expected in the next 24 hours.
Background and the 2007 report
==
There are two aspects to this vulnerability. One is new, is Apache specific;
and resolved with this server side fix. The other issue is fundamentally a
protocol design issue dating back to 2007:
http://seclists.org/bugtraq/2007/Jan/83
The contemporary interpretation of the HTTP protocol (currently) requires a
server to return multiple (overlapping) ranges; in the order requested. This
means that one can request a very large range (e.g. from byte 0- to the end)
100's of times in a single request.
Being able to do so is an issue for (probably all) webservers and currently
subject of an IETF discussion to change the protocol:
http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311
This advisory details a problem with how Apache httpd and its so called
internal 'bucket brigades' deal with serving such valid request. The
problem is that currently such requests internally explode into 100's of
large fetches, all of which are kept in memory in an inefficient way. This
is being addressed in two ways. By making things more efficient. And by
weeding out or simplifying requests deemed too unwieldy.
Mitigation:
===
There are several immediate options to mitigate this issue until a full fix
is available. Below examples handle both the 'Range' and the legacy
'Request-Range' with various levels of care.
Note that 'Request-Range' is a legacy name dating back to Netscape Navigator
2-3 and MSIE 3. Depending on your user community - it is likely that you
can use option '3' safely for this older 'Request-Range'.
1) Use SetEnvIf or mod_rewrite to detect a large number of ranges and then
either ignore the Range: header or reject the request.
Option 1: (Apache 2.2)
# Drop the Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (?:,.*?){5,5} bad-range=1
RequestHeader unset Range env=bad-range
# We always drop Request-Range; as this is a legacy
# dating back to MSIE3 and Netscape 2 and 3.
RequestHeader unset Request-Range
# optional logging.
CustomLog logs/range-CVE-2011-3192.log common env=bad-range
CustomLog logs/range-CVE-2011-3192.log common env=bad-req-range
Above may not work for all configurations. In particular situations
mod_cache and (language) modules may act before the 'unset'
is executed upon during the 'fixup' phase.
Option 2: (Pre 2.2 and 1.3)
# Reject request when more than 5 ranges in the Range: header.
# CVE-2011-3192
#
RewriteEngine on
RewriteCond %{HTTP:range} !(bytes=[^,]+(,[^,]+){0,4}$|^$)
# RewriteCond %{HTTP:request-range} !(bytes=[^,]+(?:,[^,]+){0,4}$|^$)
RewriteRule .* - [F]
# We always drop Request-Range; as this is a legacy
# dating back to MSIE3 and Netscape 2 and 3.
RequestHeader unset Request-Range
The number 5 is arbitrary. Several 10's should not be an issue and may be
required for sites which for example serve PDFs to very high end eReaders
or use things such complex http based video streaming.
2) Limit the size of the request field to a few hundred bytes. Note that while
this keeps the offending Range header short - it may break other headers;
such as sizeable cookies or security fields.
LimitRequestFieldSize 200
Note that as the attack evolves in the field you are likely to have
to further limit this and/or impose other LimitRequestFields limits.
See: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize
3
Re: [Full-disclosure] Advisory: Range header DoS vulnerability Apache HTTPD 1.3/2.x (CVE-2011-3192)
On 26/08/11 12:35, Dirk-Willem van Gulik wrote:
Apache HTTPD Security ADVISORY
==
UPDATE 2
Title: Range header DoS vulnerability Apache HTTPD 1.3/2.x
CVE: CVE-2011-3192
Last Change: 20110826 1030Z
Date:20110824 1600Z
Product: Apache HTTPD Web Server
Versions:Apache 1.3 all versions, Apache 2 all versions
Changes since last update
=
In addition to the 'Range' header - the 'Range-Request' header is equally
affected. Furthermore various vendor updates, improved regexes (speed and
accommodating a different and new attack pattern).
Description:
A denial of service vulnerability has been found in the way the multiple
overlapping ranges are handled by the Apache HTTPD server:
http://seclists.org/fulldisclosure/2011/Aug/175
An attack tool is circulating in the wild. Active use of this tool has
been observed.
The attack can be done remotely and with a modest number of requests can
cause very significant memory and CPU usage on the server.
The default Apache HTTPD installation is vulnerable.
There is currently no patch/new version of Apache HTTPD which fixes this
vulnerability. This advisory will be updated when a long term fix
is available.
A full fix is expected in the next 24 hours.
Background and the 2007 report
==
There are two aspects to this vulnerability. One is new, is Apache specific;
and resolved with this server side fix. The other issue is fundamentally a
protocol design issue dating back to 2007:
http://seclists.org/bugtraq/2007/Jan/83
The contemporary interpretation of the HTTP protocol (currently) requires a
server to return multiple (overlapping) ranges; in the order requested. This
means that one can request a very large range (e.g. from byte 0- to the end)
100's of times in a single request.
Being able to do so is an issue for (probably all) webservers and currently
subject of an IETF discussion to change the protocol:
http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311
This advisory details a problem with how Apache httpd and its so called
internal 'bucket brigades' deal with serving such valid request. The
problem is that currently such requests internally explode into 100's of
large fetches, all of which are kept in memory in an inefficient way. This
is being addressed in two ways. By making things more efficient. And by
weeding out or simplifying requests deemed too unwieldy.
Mitigation:
===
There are several immediate options to mitigate this issue until a full fix
is available. Below examples handle both the 'Range' and the legacy
'Request-Range' with various levels of care.
Note that 'Request-Range' is a legacy name dating back to Netscape Navigator
2-3 and MSIE 3. Depending on your user community - it is likely that you
can use option '3' safely for this older 'Request-Range'.
1) Use SetEnvIf or mod_rewrite to detect a large number of ranges and then
either ignore the Range: header or reject the request.
Option 1: (Apache 2.2)
# Drop the Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (?:,.*?){5,5} bad-range=1
RequestHeader unset Range env=bad-range
# We always drop Request-Range; as this is a legacy
# dating back to MSIE3 and Netscape 2 and 3.
RequestHeader unset Request-Range
# optional logging.
CustomLog logs/range-CVE-2011-3192.log common env=bad-range
CustomLog logs/range-CVE-2011-3192.log common env=bad-req-range
Above may not work for all configurations. In particular situations
mod_cache and (language) modules may act before the 'unset'
is executed upon during the 'fixup' phase.
Option 2: (Pre 2.2 and 1.3)
# Reject request when more than 5 ranges in the Range: header.
# CVE-2011-3192
#
RewriteEngine on
RewriteCond %{HTTP:range} !(bytes=[^,]+(,[^,]+){0,4}$|^$)
# RewriteCond %{HTTP:request-range} !(bytes=[^,]+(?:,[^,]+){0,4}$|^$)
RewriteRule .* - [F]
^^
Better use this:
RewriteEngine on
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$) [NC,OR]
RewriteCond %{HTTP:request-range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$) [NC]
RewriteRule .* - [F]
Because if you don't specify the [OR] apache will combine the rules
making an AND (and you don't want this!).
Also use NC=(nocase) to prevent the attacker upper casing bytes=
(don't know if it will work.. but just to prevent)
# We always drop Request-Range; as this is a legacy
# dating back to MSIE3 and Netscape 2 and 3.
RequestHeader unset Request-Range
The number 5 is arbitrary. Several 10's should not be an issue and may be
required for sites which for example serve PDFs
Re: [Full-disclosure] Advisory: Range header DoS vulnerability Apache HTTPD 1.3/2.x (CVE-2011-3192)
Option 2: (Pre 2.2 and 1.3)
# Reject request when more than 5 ranges in the Range: header. #
CVE-2011-3192 # RewriteEngine on RewriteCond %{HTTP:range}
!(bytes=[^,]+(,[^,]+){0,4}$|^$) # RewriteCond %{HTTP:request-range}
!(bytes=[^,]+(?:,[^,]+){0,4}$|^$) RewriteRule .* - [F]
^^ Better use this:
RewriteEngine on RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
[NC,OR] RewriteCond %{HTTP:request-range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
[NC] RewriteRule .* - [F]
Because if you don't specify the [OR] apache will combine the rules making
an AND (and you don't want this!).
Also use NC=(nocase) to prevent the attacker upper casing bytes= (don't
know if it will work.. but just to prevent)
in any case, i found very wierd behavior on some of our webservers. as we
applied the first version of workaround, something about 15% of our webpages
seems to be broken, but the rest of virtual hosts were working fine.
I really dunno why, since LiveHeaders didn't show !any! ranges http header
from my browser but still i was getting Forbidden response :(
I'll digg in deeper (also to rewrite debug log) in the night because I can't
reproduce it on other places ;(
bodik
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Advisory: Range header DoS vulnerability Apache HTTPD 1.3/2.x (CVE-2011-3192)
On 26 Aug 2011, at 12:09, Carlos Alberto Lopez Perez wrote:
RewriteEngine on
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$) [NC,OR]
RewriteCond %{HTTP:request-range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$) [NC]
RewriteRule .* - [F]
Because if you don't specify the [OR] apache will combine the rules
making an AND (and you don't want this!).
Also use NC=(nocase) to prevent the attacker upper casing bytes=
(don't know if it will work.. but just to prevent)
Thank you - will double check add in next/final advisory.
Dw.
___
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] Question about disclosure of WordPress plugin vulnerabilities
Hi. Does anybody know what's the general opinion on disclosure of WordPress plugin vulnerabilities in these two sections: 1) unfiltered string parameter values - while magic_quotes are automatically turned on on WordPress = 3.0 [1] installations 2) admin ones (requires access to the restricted admin area) Kind regards. References: [1] http://kovshenin.com/archives/wordpress-and-magic-quotes/ -- Miroslav Stampar http://about.me/stamparm ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Apache Killer
On Thu, Aug 25, 2011 at 03:52:00PM -0400, valdis.kletni...@vt.edu wrote: On Thu, 25 Aug 2011 21:35:04 +0300, Georgi Guninski said: On Wed, Aug 24, 2011 at 10:45:53AM +0100, Mark J Cox wrote: Use CVE-2011-3192. why the fuck use this shit? So that when two different people issue advisories about it, if they both say CVE-2011-3192, we know it's the same issue. Otherwise if you got some people writing about Kingcope's hole with gzip and others writing about Zalewski's hole with Range: it's hard to tell if they're really the same issue or not. ok, there might be some sense in using canonical names, but why chose possibly the worst service available? from their front page: CVE® - remember, remember what happened with the securityfocus/bugtraq exploit DB? btw, all the shitty id that should be used says: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Paper - Dissecting Java Server Faces for Penetration Testing
On 08/26/2011 05:18 AM, SecNiche Security Labs wrote: Hi This paper sheds light on the findings of security testing of Java Server Faces. JSF has been widely used as an open source web framework for developing efficient applications using J2EE. JSF is compared with ASP.NET framework to unearth potential security flaws. Link : http://www.secniche.org/jsf/dissecting_jsf_pt_aks_kr.pdf Aditya K Sood SecNiche Security Labs http://www.secniche.org ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ Where's the paper? -- Saleh Alsanad PACI computer engineer q8mos...@gmail.com I'm an FSF member -- Help us support software freedom! http://www.fsf.org/jf?referrer=2442 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Paper - Dissecting Java Server Faces for Penetration Testing
Er.on the end of the link, maybe? On 26 August 2011 14:39, Saleh q8mos...@gmail.com wrote: On 08/26/2011 05:18 AM, SecNiche Security Labs wrote: Hi This paper sheds light on the findings of security testing of Java Server Faces. JSF has been widely used as an open source web framework for developing efficient applications using J2EE. JSF is compared with ASP.NET framework to unearth potential security flaws. Link : http://www.secniche.org/jsf/dissecting_jsf_pt_aks_kr.pdf Aditya K Sood SecNiche Security Labs http://www.secniche.org ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ Where's the paper? -- Saleh Alsanad PACI computer engineer q8mos...@gmail.com I'm an FSF member -- Help us support software freedom! http://www.fsf.org/jf?referrer=2442 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- On two occasions...I have been asked, 'Pray, Mr Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. ** IMPORTANT INFORMATION/DISCLAIMER * This document should be read only by those persons to whom it is addressed. If you have received this message it was obviously addressed to you and therefore you can read it, even it we didn't mean to send it to you. However, if the contents of this email make no sense whatsoever then you probably were not the intended recipient, or, alternatively, you are a mindless cretin; either way, you should immediately kill yourself and destroy your computer (not necessarily in that order). Once you have taken this action, please contact us.. no, sorry, you can't use your computer, because you just destroyed it, and possibly also committed suicide afterwards, but I am starting to digress.. * * The originator of this email is not liable for the transmission of the information contained in this communication. Or are they? Either way it's a pretty dull legal query and frankly one I'm not going to dwell on. But should you have nothing better to do, please feel free to ruminate on it, and please pass on any concrete conclusions should you find them. However, if you pass them on via email, be sure to include a disclaimer regarding liability for transmission. * * In the event that the originator did not send this email to you, then please return it to us and attach a scanned-in picture of your mother's brother's wife wearing nothing but a kangaroo suit, and we will immediately refund you exactly half of what you paid for the can of Whiskas you bought when you went to Pets** ** At Home yesterday. * * We take no responsibility for non-receipt of this email because we are running Exchange 5.5 and everyone knows how glitchy that can be. In the event that you do get this message then please note that we take no responsibility for that either. Nor will we accept any liability, tacit or implied, for any damage you may or may not incur as a result of receiving, or not, as the case may be, from time to time, notwithstanding all liabilities implied or otherwise, ummm, hell, where was I...umm, no matter what happens, it is NOT, and NEVER WILL BE, OUR FAULT! * * The comments and opinions expressed herein are my own and NOT those of my employer, who, if he knew I was sending emails and surfing the seamier side of the Internet, would cut off my manhood and feed it to me for afternoon tea. * ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Paper - Dissecting Java Server Faces for Penetration Testing
On 08/26/2011 04:39 PM, Saleh wrote: On 08/26/2011 05:18 AM, SecNiche Security Labs wrote: Hi This paper sheds light on the findings of security testing of Java Server Faces. JSF has been widely used as an open source web framework for developing efficient applications using J2EE. JSF is compared with ASP.NET framework to unearth potential security flaws. Link : http://www.secniche.org/jsf/dissecting_jsf_pt_aks_kr.pdf Aditya K Sood SecNiche Security Labs http://www.secniche.org ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ Where's the paper? Never mind. I Found it -- Saleh Alsanad PACI computer engineer q8mos...@gmail.com I'm an FSF member -- Help us support software freedom! http://www.fsf.org/jf?referrer=2442 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Advisory: Range header DoS vulnerability Apache HTTPD 1.3/2.x (CVE-2011-3192)
Dne 08/26/11 13:26, bodik napsal(a):
Option 2: (Pre 2.2 and 1.3)
# Reject request when more than 5 ranges in the Range: header. #
CVE-2011-3192 # RewriteEngine on RewriteCond %{HTTP:range}
!(bytes=[^,]+(,[^,]+){0,4}$|^$) # RewriteCond %{HTTP:request-range}
!(bytes=[^,]+(?:,[^,]+){0,4}$|^$) RewriteRule .* - [F]
^^ Better use this:
RewriteEngine on RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
[NC,OR] RewriteCond %{HTTP:request-range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
[NC] RewriteRule .* - [F]
in any case, i found very wierd behavior on some of our webservers. as we
applied the first version of workaround, something about 15% of our webpages
seems to be broken, but the rest of virtual hosts were working fine.
because of messing with Options FollowSymLinks or SymLinksIfOwnerMatch and
mod_rewrite i have to implement other workaround ..
b
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Apache Killer
On Fri, 26 Aug 2011 16:19:31 +0300, Georgi Guninski said: ok, there might be some sense in using canonical names, but why chose possibly the worst service available? possibly doesn't mean much unless you have an actual point to make. from their front page: CVE® - remember, remember what happened with the securityfocus/bugtraq exploit DB? I doubt Mitre has any such plans - the ® is there mostly so they can take action against people who invent their own CVE numbers. btw, all the shitty id that should be used says: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. I beleive those are pools allocated to the various CVE Numbering Authorities: https://cve.mitre.org/cve/cna.html#participating_cnas Each of those vendors and researchers has a small pool of pre-assigned numbers they can use - so if Apple or Microsoft gets notified of a vulnerability, they can peel off the next number from their pool and use it without the delay of going back to Mitre to get a number assigned. It usually *doesn't* mean people are sitting on unannounced stuff - it means people are sitting on numbers to use quickly if they have to make an announcement. pgplyHnMXUCdY.pgp Description: PGP signature ___ 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] Jcow CMS 4.x:4.2 = , 5.x:5.2 = | Arbitrary Code Execution
Jcow CMS 4.x:4.2 = , 5.x:5.2 = | Arbitrary Code Execution
1. OVERVIEW
Jcow CMS versions (4.x: 4.2 and lower, 5.x: 5.2 and lower) are
vulnerable to Arbitrary Code Execution.
2. BACKGROUND
Jcow is a flexible Social Networking software written in PHP. It can
help you to build a social network for your interests and passions, a
member community for your existing website and a social networking
site like facebook/myspace/twitter.
3. VULNERABILITY DESCRIPTION
The parameter attachment is not properly sanitized upon submission
to /index.php, which allows attacker to execute arbitrary PHP code of
his own.
4. VERSIONS AFFECTED
Free version: 4.x: 4.2 and lower
Commercial version: 5.x: 5.2 and lower
5. PROOF-OF-CONCEPT/EXPLOIT
http://dev.metasploit.com/redmine/attachments/1660/jcow_eval.rb
jcow 4.2.1:
file: /includes/libs/ss.inc.php
line: 167
$app = $_POST['attachment'];
if (strlen($app) $app != 'status') {
include_once('modules/'.$app.'/'.$app.'.php');
$c_run = $app.'::ajax_post();';
eval($c_run);
exit;
}
jcow 5.2.0:
file: /includes/libs/ss.inc.php
line: 45
$Vd2a57dc1 = $_POST['attachment']; if (strlen($Vd2a57dc1)
$Vd2a57dc1 != 'status') {
include_once('modules/'.$Vd2a57dc1.'/'.$Vd2a57dc1.'.php'); $Ve8200cee
= $Vd2a57dc1.'::ajax_post();';
eval($Ve8200cee); exit; }
6. SOLUTION
Free version users can upgrade to 4.3.1 or higher.
Commercial users can upgrade to 5.3 or higher.
7. VENDOR
Jcow CMS Development Team
http://www.jcow.net
8. CREDIT
This vulnerability was discovered by Aung Khant, http://yehg.net, YGN
Ethical Hacker Group, Myanmar.
9. DISCLOSURE TIME-LINE
2010-06-03: notified vendor
2010-06-03: vendor replied fix would be available within 48hrs
2011-08-24: vendor released fixed versions for 4.x and 5.x,
4.3.1 for free release
5.3 for commercial release
2011-08-26: vulnerability disclosed
10. REFERENCES
Original Advisory URL:
http://yehg.net/lab/pr0js/advisories/[jcow_4.2,5.2]_arbitrary_code_execution
Jcow CMS:
http://sourceforge.net/projects/jcow/files/jcow4/jcow.4.2.1.zip/download
#yehg [2011-08-26]
-
Best regards,
YGN Ethical Hacker Group
Yangon, Myanmar
http://yehg.net
Our Lab | http://yehg.net/lab
Our Directory | http://yehg.net/hwd
___
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] Jcow CMS 4.2 = | Cross Site Scripting
Jcow CMS 4.2 = | Cross Site Scripting 1. OVERVIEW Jcow CMS 4.2 and lower versions are vulnerable to Cross Site Scripting. 2. BACKGROUND Jcow is a flexible Social Networking software written in PHP. It can help you to build a social network for your interests and passions, a member community for your existing website and a social networking site like facebook/myspace/twitter. 3. VULNERABILITY DESCRIPTION The parameter g is not properly sanitized upon submission to /index.php, which allows attacker to conduct Cross Site Scripting attack. This may allow an attacker to create a specially crafted URL that would execute arbitrary script code in a victim's browser. 4. VERSIONS AFFECTED Jcow CMS 4.2 and lower 5. PROOF-OF-CONCEPT/EXPLOIT File: /includes/libs/member.module.php: Line 605: input type=hidden name=g value='.$_REQUEST['g'].' / http://[target]/index.php?p=member/signupemail=username=password=fullname=birthyear=1991birthmonth=01birthday=01gender=0location=Myanmar++about_me=recaptcha_challenge_field=03AHJ_Vuvk8U6zCeSdrjB0GPDuwaRP-tPJ2G7u3Nm5LpmVSGmZs_CIP9I_C0PYZ1zYY6F42zpzGKQkxSiUhhyu-QhhwZA6oTlLNntgAgmRkDjfZpu3j4-bMeQNpOVh1afb4fZ4qwaIxHpP1wL8-8-LgkEBE5auAFmF_wrecaptcha_response_field=g=%22%3E%3Cscript%3Ealert%28/XSS/%29%3C/script%3Eonpost=1agree_rules=1 6. SOLUTION Upgrade to 4.3.1 or higher. The commercial version 5.x.x is not vulnerable. 7. VENDOR Jcow CMS Development Team http://www.jcow.net 8. CREDIT This vulnerability was discovered by Aung Khant, http://yehg.net, YGN Ethical Hacker Group, Myanmar. 9. DISCLOSURE TIME-LINE 2010-06-03: notified vendor 2010-06-03: vendor replied fix would be available within 48hrs 2011-08-24: vendor released fixed version, jcow.4.3.1.ce 2011-08-26: vulnerability disclosed 10. REFERENCES Original Advisory URL: http://yehg.net/lab/pr0js/advisories/[jcow_4.2]_cross_site_scripting Jcow CMS: http://sourceforge.net/projects/jcow/files/jcow4/jcow.4.2.1.zip/download #yehg [2011-08-26] - Best regards, YGN Ethical Hacker Group Yangon, Myanmar http://yehg.net Our Lab | http://yehg.net/lab Our Directory | http://yehg.net/hwd ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Apache Killer
Look like my sites were not vulnerable. Does any of you know which setting or module prevents kingcope's 'killer' from working? I have the latest mod_qos and suhosin extension installed. ModSec is disabled. I simply haven't had time to investigate this issue. Thanks ___ 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] Bypassing PHPIDS 0.6.5
Full Paper: https://sitewat.ch/en/Blog/10 Using these attacks it is possible to bypass all of PHPIDS's rule sets, which defeats all protection PHPIDS can provide. Further more on a default install of PHPIDS the log file can be used to drop a PHP backdoor. There by using PHPIDS as a vital steping stone in turning an LFI vulnerability into remote code execution. Thus PHPIDS 0.6.5 made you less secure. Of course all of these issues have been fixed in PHPIDS 0.7, and by using the latest version of PHPIDS I have no doubt that you're php application will be more secure. If someone tells you that you are absolutely secure, then they are trying to sell you something. However PHPIDS 0.7 provides a strong barrier between your application and an attacker. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Apache Killer
busy man, see this https://mail-archives.apache.org/mod_mbox/httpd-announce/201108.mbox/%3c20110824161640.122d38...@minotaur.apache.org%3E On Fri, Aug 26, 2011 at 13:44, n...@myproxylists.com wrote: Look like my sites were not vulnerable. Does any of you know which setting or module prevents kingcope's 'killer' from working? I have the latest mod_qos and suhosin extension installed. ModSec is disabled. I simply haven't had time to investigate this issue. Thanks ___ 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/
[Full-disclosure] INSECT Pro - Free tool for pentest - New version release 2.7
We are happy to announce a new release of INSECT Pro 2.7 including changes that people ask about most often This is a partial list of the major changes implented in version 2.7 - Available targets now has a submenu under right-click button - Check update function added in order to verify current version - Threading support for GET request - Module log added and functional - Sniffer support added - 50 Remote exploits added - Project saved on userland - Application Data special folder - Executed module windows added and functionality for it - AgentConnect now use telnetlib Download now from: http://www.insecurityresearch.com Juan Sacco (runlvl) -- -- Insecurity Research - Security auditing and testing software Web: http://www.insecurityresearch.com Insect Pro 2.7 was released stay tunned ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] INSECT Pro - Free tool for pentest - New version release 2.7
when is smeone going to warez this... it aint free.. but since its ad here...well, shouldnt we b able to get a copy, thru the wares community : cheers! waiting on those links to come pourin in1 This tool does sound great, i just wont pay for a domplete app without some form of trial...heck metasploit is pro version to, but, they atleast provide a stable and useable free version... insect needs a nudge ! On 27 August 2011 12:02, Juan Sacco jsa...@insecurityresearch.com wrote: We are happy to announce a new release of INSECT Pro 2.7 including changes that people ask about most often This is a partial list of the major changes implented in version 2.7 - Available targets now has a submenu under right-click button - Check update function added in order to verify current version - Threading support for GET request - Module log added and functional - Sniffer support added - 50 Remote exploits added - Project saved on userland - Application Data special folder - Executed module windows added and functionality for it - AgentConnect now use telnetlib Download now from: http://www.insecurityresearch.com Juan Sacco (runlvl) -- -- Insecurity Research - Security auditing and testing software Web: http://www.insecurityresearch.com Insect Pro 2.7 was released stay tunned ___ 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/
Re: [Full-disclosure] Apache Killer
Hello Lists,
the youtube video at the bottom illustrates the threat quite good.
these where the exact same observations I had when initially running the tool.
It has to be noted that a good architecture can very likely mitigate the risks.
For example load balancing to multiple targets will most likely slow
down the tool
giving different results than this flat configuration:
http://www.youtube.com/watch?v=3al1lsvFSpA
2011/8/25 -= Glowing Sex =- doo...@gmail.com:
Hello list,
Note about the original script/script being used..
Just for anyone out there wishing to make this exploit 'useful' , as it
says, this has nothing todo with the 'testapache' used in that code, as this
involves checking on mod_deflate, wich is useless, so instead of that if ($x
= /Partial/) { }
if($x !~ /^http:\/\//) {
print [+] Host seems alive..\n;
return 1;
} else {
return 0;
}
would then test all your servers, not just checking on those wich have
mod_deflate enabled... i am yet to test the latest 'killer' :S but i will
have a look soon.
thx to everyone for theyre help on this, every fix was put it seems into the
apache advisory, most of the fixes put forth here anyhow, wich is great.
apache.orgh saw this list, and ackowledged it had todo something good, and
they did, much props to them for theyre response on the matter, they have
been class act on this, even tho it should have been patched in 2007 or even
around then,... that is for atleast one hole... one, i guess could been
stopped if the coe had been looked at, improved, wich has happened now, so
thankyou to all who res[ponded on this.. but please be sure to adjust the
script so it just tests a live url.
cheers!
xd
The advisory i mentioned was also posted already but this, is great work:
Apache HTTPD Security ADVISORY
==
UPDATE 1
Title: Range header DoS vulnerability Apache HTTPD 1.3/2.x
CVE: CVE-2011-3192
Last Change: 20110824 1800Z
Date: 20110824 1600Z
Product: Apache HTTPD Web Server
Versions: Apache 1.3 all versions, Apache 2 all versions
Description:
A denial of service vulnerability has been found in the way the multiple
overlapping ranges are handled by the Apache HTTPD server:
http://seclists.org/fulldisclosure/2011/Aug/175
An attack tool is circulating in the wild. Active use of this tools has
been observed.
The attack can be done remotely and with a modest number of requests can
cause very significant memory and CPU usage on the server.
The default Apache HTTPD installation is vulnerable.
There is currently no patch/new version of Apache HTTPD which fixes this
vulnerability. This advisory will be updated when a long term fix
is available.
A full fix is expected in the next 48 hours.
Mitigation:
There are several immediate options to mitigate this issue until a full fix
is available:
1) Use SetEnvIf or mod_rewrite to detect a large number of ranges and then
either ignore the Range: header or reject the request.
Option 1: (Apache 2.0 and 2.2)
# Drop the Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
# optional logging.
CustomLog logs/range-CVE-2011-3192.log common env=bad-range
Option 2: (Also for Apache 1.3)
# Reject request when more than 5 ranges in the Range: header.
# CVE-2011-3192
#
RewriteEngine on
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^
$)
RewriteRule .* - [F]
The number 5 is arbitrary. Several 10's should not be an issue and may be
required for sites which for example serve PDFs to very high end eReaders
or use things such complex http based video streaming.
2) Limit the size of the request field to a few hundred bytes. Note that
while
this keeps the offending Range header short - it may break other headers;
such as sizeable cookies or security fields.
LimitRequestFieldSize 200
Note that as the attack evolves in the field you are likely to have
to further limit this and/or impose other LimitRequestFields limits.
See: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize
3) Use mod_headers to completely dis-allow the use of Range headers:
RequestHeader unset Range
Note that this may break certain clients - such as those used for
e-Readers and progressive/http-streaming video.
4) Deploy a Range header count module as a temporary stopgap measure:
http://people.apache.org/~dirkx/mod_rangecnt.c
Precompiled binaries for some platforms are available at:
http://people.apache.org/~dirkx/BINARIES.txt
5) Apply any of the current patches under discussion - such as:
[Full-disclosure] Telecom/Chat Servers = 2.0.1.1 Blind Exploitation Attack Vulnerability
Over the last few days,seen a number of sites getting hacked with a malware
script.
It is done using the WQuery injection attack.
WQuery ($username)
$userdata = hub#;
if (isPasswordCorrect($username:Bg, $pass:M25)) {
$userdata = Bf%ByLogin($F20); ...
}
{
AS BEGIN
'SELECT:'string=B#(Var char 'FROM''$Status%'varchar(150) Brides'
WHERE 'FrIn'Lw =varchar(50) 'Millix*naire'
ph_status` varchar(20)=Count($Car) $2000+'
AND Hs_Status=='3#'
Brth_staus`Varchar(5)= Null;
AND Ss-status' =#Full$
{
$userselect=sxx(20)
curl_setop=$ch(PRIMARY KEY ) (`dk-enter`)=’$fnm’
isGETCHA =$+`FInLawBal`
) TYPE`=MyFXX`;
}
Various Telecom/ISP servers are vulnerable to this attack.
Highly Vulnerable Softwares:
Pidgin
Meebo
MSN
AIM
Gtalk
Yahoo Messenger
Skype
Vypress
Windows Live Messenger
US Robotics
LG Electronics Routers
Intel Routers
Ericsson Routers
Cisco Routers
BT Telecoms
Win XP
Win Vista
Win Server 2008
Win 7
Win 2003
Firefox
Opera
IE all versions
Chrome Browser
Multiple domains being used to distribute the malware, including:
http://t0.gstatic.com/
http://25.media.tumblr.com/tumblr_lo7bl0euPE1ql6o50o1_500
http://25.media.tumblr.com/tumblr_lo7bl0euPE1ql6o50o1_500.jpg
http://24.media.tumblr.com/tumblr_lkrwquzHb41qjs8gqo1_400.gif
http://26.media.tumblr.com/tumblr_lqa82gM6x61qi9sb6o1_500.jpg
http://29.media.tumblr.com/tumblr_liqrr9kkm01qct17go1_500.gif
http://gallys.nastydollars.com/en/42/6b.jpg
http://27.media.tumblr.com/tumblr_liz02y6ztB1qzfemwo1_500.gif
http://gallys.rk.com/en/158/3.jpg
http://24.media.tumblr.com/tumblr_lq7fiiUepU1qg82xfo1_500.gif
All of them hosted at 98.34.90.18.16. Google already blacklisted more than 500
sites due to this infective Vulnerability and the number is growing.
The vulnerability is caused due to an error within the BiteRange filter when
processing requests containing a large amount of SKHS, which can be exploited
to exhaust memory via specially crafted HTTN requests sent to the server.
Some of the Sites assumed could be at high Risks of this campaign:
http://t1.gstatic.com/
http://www.scoreland.com
http://incrediblepass.com
http://anothertranny.com
http://afdnetwork.com/
http://www.kuntal.org
michaelhallk.x.fc2.com
http://chaturbate.com
http://www.spankwire.com/
http://www.joggs.com/
Various sites till date are assumed to be attacked.
This vulnerability has been discovered by FunnyMinds.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
