Re: [Full-disclosure] Telecom/Chat Servers <= 2.0.1.1 Blind Exploitation Attack Vulnerability
Hey, please do not spoof my email address, thanks xD ___ 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] 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/
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 =- : > 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 unde
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 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/
[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] 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, 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] 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
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] 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: http://[target]/index.php?p=member/signup&email=&username=&password=&fullname=&birthyear=1991&birthmonth=01&birthday=01&gender=0&location=Myanmar++&about_me=&recaptcha_challenge_field=03AHJ_Vuvk8U6zCeSdrjB0GPDuwaRP-tPJ2G7u3Nm5LpmVSGmZs_CIP9I_C0PYZ1zYY6F42zpzGKQkxSiUhhyu-QhhwZA6oTlLNntgAgmRkDjfZpu3j4-bMeQNpOVh1afb4fZ4qwaIxHpP1wL8-8-LgkEBE5auAFmF_w&recaptcha_response_field=&g=%22%3E%3Cscript%3Ealert%28/XSS/%29%3C/script%3E&onpost=1&agree_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/
[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/
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/
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] 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] Paper - Dissecting Java Server Faces for Penetration Testing
Er.on the end of the link, maybe? On 26 August 2011 14:39, 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? > > -- > 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 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] 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/
[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] 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/
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/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}$|^$)
[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 a
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