Message-ID: <025B5895F8BCCC40AC35F6CD6D972B1CF93E67@cca-mail1.commonwealthcare.org>
Date: Wed, 14 Sep 2011 09:26:26 -0400
From: "Mikhail A. Utin" <mutin@...monwealthcare.org>
To: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Full-Disclosure Digest, Vol 79, Issue 21

See MS advisory for full list of affected products. It is NOT just 2007. It includes 2010 products as well.

Mikhail A. Utin, CISSP
Information Security Analyst

-----Original Message-----
From: full-disclosure-bounces@...ts.grok.org.uk [mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf Of full-disclosure-request@...ts.grok.org.uk
Sent: Wednesday, September 14, 2011 7:00 AM
To: full-disclosure@...ts.grok.org.uk
Subject: Full-Disclosure Digest, Vol 79, Issue 21

Send Full-Disclosure mailing list submissions to
        full-disclosure@...ts.grok.org.uk

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.grok.org.uk/mailman/listinfo/full-disclosure
or, via email, send a message with subject or body 'help' to
        full-disclosure-request@...ts.grok.org.uk

You can reach the person managing the list at
        full-disclosure-owner@...ts.grok.org.uk

When replying, please edit your Subject line so it is more specific than "Re: Contents of Full-Disclosure digest..."


Note to digest recipients - when replying to digest posts, please trim your post appropriately. Thank you.


Today's Topics:

   1. Seeker Advisory Sep11: Reflected Cross Site       Scripting in
      Microsoft SharePoint Portal (Irene Abezgauz)
   2. Re: Apache Killer (xD 0x41)
   3. Update: Vulnerability in plugins for Typepad,     RapidWeaver,
      Habari, DasBlo, eZ Publish, EE, Serendipity,      Social Web CMS,
      PHP-Fusion, Magento and Sweetcron (MustLive)
   4. Re: Apache Killer (Javier Bassi)
   5. Re: Apache Killer (GloW - XD)
   6. Seeker Advisory Sep11: Insecure Redirect in       Microsoft
      SharePoint Portal (Irene Abezgauz)


----------------------------------------------------------------------

Message: 1
Date: Tue, 13 Sep 2011 20:30:17 +0300
From: "Irene Abezgauz" <irene@...kersec.com>
Subject: [Full-disclosure] Seeker Advisory Sep11: Reflected Cross Site
        Scripting in Microsoft SharePoint Portal
To: <full-disclosure@...ts.grok.org.uk>
Message-ID:
        <408E44BC9EB1A74DB458543F5BCDA35AC412F3@...dalf.Hacktics.local>
Content-Type: text/plain;       charset="windows-1255"

Seeker Research Center Security Advisory

This vulnerability was discovered by Seeker? Automatic Run-Time Application Security Testing Solution Disclosed By Irene Abezgauz, September 13th, 2011

=========
I. Overview
=========
A Cross Site Scripting vulnerability has been identified in Microsoft SharePoint 2007. This vulnerability allows attackers to gain control over valid user accounts, perform operations on their behalf, redirect them to malicious sites, steal their credentials, and more.

A friendly formatted version of this advisory is available at: http://www.seekersec.com/Advisories/SeekerAdvMS04.html

=======
II. Details
=======
The Contact Details Tool Pane web part is vulnerable to cross site scripting attacks in the parameter ctl00$MSOTlPn_EditorZone$Edit0g_7aaa0c6d_72f5_4717_9b22_80188ffdbcde$peopleEditor$hiddenSpanData=
By manipulating an unsuspecting user into submitting a specially crafted form an attacker causes the victim to send the malicious script to the vulnerable SharePoint 2007 instance. The malicious script is then reflected back to the user and executed on his browser.
The Contact Details Tool Pane is an out-of-the-box component, accessible from various locations in SharePoint 2007 in which the Contact Details web-part is present. The exploit in this advisory has been produced when editing Report Center.

=======
III. Exploit
=======
Sample exploitation of this vulnerability would be crafting the following request:
POST /Reports/Pages/Default.aspx HTTP/1.1 ?
ctl00$MSOTlPn_EditorZone$Edit0g_7aaa0c6d_72f5_4717_9b22_80188ffdbcde$peopleEditor$hiddenSpanData=<script>alert(?SeekerSec?)</script>

The request also contains other parameters required by the page, the vulnerable parameter being the parameter noted above.
It seems that when a script is simply placed into the input field there is a client-side encoding of the parameter value, which is insufficient to prevent attacks as directly (not via client) submitted scripts simply do not undergo such validation.

================
IV. Affected Systems
================
Microsoft SharePoint 2007

========
V. Solution
========
Microsoft has released a fix for this vulnerability, see http://technet.microsoft.com/security/bulletin/MS11-074 for further information.

=======
VI. Credit
=======
The vulnerability was automatically discovered by Seeker? - New generation application security testing solution, utilizing ground breaking BRITE? technology (Behavioral Runtime Intelligent Testing Engine).

Further research and publication was performed by Irene Abezgauz, Product Manager, Seeker Security.
For more information please visit www.seekersec.com


-----------------
Irene Abezgauz
Product Manager
Seeker Security
www.seekersec.com
?E-Mail:??? irene@...kersec.com




------------------------------

Message: 2
Date: Tue, 13 Sep 2011 12:26:58 +1000
From: xD 0x41 <secn3t@...il.com>
Subject: Re: [Full-disclosure] Apache Killer
To: full-disclosure@...ts.grok.org.uk
Message-ID:
        <CALCvwp4WE6P0H9LgXCvKyYqhxkpjonP4BW0HB_3+q0gffKivJA@...l.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

I know this topic is OLD but, i just wonder and, also having spoken to kcope re this myself, discussed the size of each bucket wich can be made to stupendous amounts and using a different vector, ok, instead of Range:bytes= , picture a GET request with as was shown in the code is there, you
"Request-Range: bytes=5-,5-69,5-" , now we have bypassed most filters already in place, and the request range code, is exactly the same as range code.
Only one person spotted this.

Anyhow, This started about byte= 'stupendous' amount but, in the end there is a few ways that people are still using this..
remember it does not need any mod_deflate or mod_gzip to function... i have not tested the method outlined on anything new, but it was pretty nasty on the old systems wich is now made worse if you set the byterange to a high amount from start, rather than sending 0- first... you can just avoid it and stay in the middle and lower it, but the problem can be repeated in some packages, and im retesting using a simple bit of code called create_conns.c and modified GET request.
create_conns code is googleable, just google for create_conns.c by n0ah and you have found that app...  you can even try a slowloris app and just send one packet. Simple enough to recreate this.. as this is not about 'range'
anymore.

Also i found this bypasses the filters set by mod_filter wich were 'suggested' and actually added to part of the fix, or some fix's were based on this.. i think that maybe a time to look at some modified code of this, or just setup better traps, better yet, use a patched package, as i do not
*think* these are affected, but dont use any of the quick-fixes is what is to be learnt from this exploit in a BIG way.
on FreeBSD the httpd on v8.0 was affected so badly, i have never seen a httpd die so badly, as with a flavor of citrix wich was interesting. Anyhow moving on...

Anyhow, i know it is old but, i am seeing people still with this problem, who dont realise that some quick-patches, is NOT the way togo...
I would assume apache have seen that request-Range exists in the same LINE as range code, does wich is affected, so they would be abit crazy to NOT patch that.
I do remember one person showing the affected line in wich request-range was, and i looked it up in my code and bingo, it was same as his example so i assume request-range would be used in a request form.
A system GET or POST perhaps... anyhow regardless, i just thought of this and the discussions ive had re this, and think it should be checked 1000% :P Sorry for those who it annoys but, im a fussy fofo on that side of things, ie httpd/ftpd MUST be spankin perfect or i dont rest.
Thanks for those who originally and still, help on this topic.
Always, thx to kcope for atleast releasing it so it could be patched. <3 and ofcourse, always my buddies on #haxnet@ef, who help me with these discussions.
Dos sucks, but hiding from it sucks worse.
cheers to all, and specially for those affected by 9/11,my special regards.
xd / dru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20110913/2f4155b9/attachment-0001.html

------------------------------

Message: 3
Date: Tue, 13 Sep 2011 23:57:42 +0300
From: "MustLive" <mustlive@...security.com.ua>
Subject: [Full-disclosure] Update: Vulnerability in plugins for
        Typepad,        RapidWeaver, Habari, DasBlo, eZ Publish, EE, Serendipity,
        Social Web CMS, PHP-Fusion, Magento and Sweetcron
To: <submissions@...ketstormsecurity.org>,
        <full-disclosure@...ts.grok.org.uk>
Message-ID: <005701cc7257$e47e85c0$9b7a6fd5@ml>
Content-Type: text/plain; format=flowed; charset="windows-1251";
        reply-type=original

Hello list!

One update concerning Cross-Site Scripting vulnerability in multiple plugins for different engines (in plugins for Typepad, RapidWeaver, Habari, DasBlo, eZ Publish, EE, Serendipity, Social Web CMS, PHP-Fusion, Magento and Sweetcron, which all are ports of WP-Cumulus). Which I wrote about earlier.

Besides, EZcumulus for eZ Publish, there is another vulnerable plugin eZ Flash Tag Cloud - it's another plugin for eZ Publish (with tagcloud.swf).
Which is supported by developers, unlike EZcumulus.

Vulnerable version eZ Flash Tag Cloud 1.0. After my informing, the developers fixed XSS in version 1.1 (http://projects.ez.no/ezflashtagcloud/forum/general/flash_tag_cloud_v1_1_security_update),
but it's still vulnerable to HTML Injection.

Concerning EZcumulus then, as representative of eZ Systems told me, because of that EZcumulus is not supported, then downloading of it was disabled at official site (and it'll not be updated to fix this issue). So it's recommended for all eZ Publish users, who are using EZcumulus, to change it to eZ Flash Tag Cloud 1.1.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua




------------------------------

Message: 4
Date: Tue, 13 Sep 2011 22:36:16 -0300
From: Javier Bassi <javierbassi@...il.com>
Subject: Re: [Full-disclosure] Apache Killer
To: full-disclosure@...ts.grok.org.uk
Message-ID:
        <CAKH-_dKKTcuT8u2CYTGCrzcT700g6iyak-x2oHdGN4ZRzB6p+Q@...l.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On Mon, Sep 12, 2011 at 11:26 PM, xD 0x41 wrote:
> I know this topic is OLD but, i just wonder and, also having spoken to
> kcope re this myself, discussed the size of each bucket wich can be
> made to stupendous amounts and using a different vector, ok, instead
> of Range:bytes= , picture a GET request with as was shown in the code
> is there, you
> "Request-Range: bytes=5-,5-69,5-" , now we have bypassed most filters
> already in place, and the request range code, is exactly the same as
> range code.
> Only one person spotted this.

HTTPD advisory was very clear that both Range and Request-Range can be used. Everyone who unset Range probably unset Request-Range too. If host is vulnerable its a little better to use Range because using Request-Range will take 8 bytes more. (more bytes = less ranges)

I have tested a bit the exploit and saw 1300 ranges is just a fixed number chosen by kingcope but it can be a little bigger. Range field can be almost 8KB long and its a total waste of bytes to use x-y, format where y is an increasing number that will take more than one digit. So instead of 1300 you can get it to 2725 max if you use repeat x-, where x is always single digit number. By doing that the exploit gets much more effective.

I have attached the source if anyone cares
-------------- next part --------------
A non-text attachment was scrubbed...
Name: killapache2.pl
Type: text/x-perl
Size: 2089 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20110913/05b3bccd/attachment-0001.bin

------------------------------

Message: 5
Date: Wed, 14 Sep 2011 12:28:19 +1000
From: GloW - XD <doomxd@...il.com>
Subject: Re: [Full-disclosure] Apache Killer
To: Javier Bassi <javierbassi@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Message-ID:
        <CALCvwp73BAfCQaoNj4eRh+v8fWDdy-j4MnwGUv849prBs9ZE=g@...l.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Aha this is exactly what me and kcope were discussing, and he pointed out that size exactly (however he did not know how to replicate to get to it i think),he mentioned the bucket size being able to be pushed to the exact amount you just said then, wich is alone enough to really reak some havoc on things with even using this still ithin the bouncs of the httpd, altho i am guessing if you send a huge amount of the right request, it would cause a DoS also. i am about to look at your code and hope i havent just repeated what you said (again), but your spoton about where im speaking about and exactly what i meant... the size is the problem wich is still underlying things, if set very high, this consumes more resources on the target... wich can be a persistent attack really until this code is limited or, changed, or a mod made for ranges wich handles the ranges and any overflowing or misuse by local users, this is the biggest problem here, a malicious local user...
i am suprised no one has tried to make this bigger yet, i know that there is a seperate apache attacking script wich was posted (mn.pl) but this did not have the sufficient pulling power of a request-Range type attack... wich if dne right, i think could still lead to possibly atleast a local memory exhaustion... i dont think it could get as bad as the actual bug was, but with the range boundarys how they are, and filter settings against things like 'bytes=' and to monitor if bytes=0-, wich is kinda useless, if you use ByTes= the filter is useless... unless there is some settings made specially for upper/lower and even setting spaces in between..
I guess this is still a problem when you have the size of one single bucket at 2725, and i have heard, even higher, that was actually the first reason this whole thing came about, was the discussions around the size of ONE container alone, wich at that time was about 4850 i believe, around that figure... so, it has not chnged much, or it has not changed atall i have not tried to build it in a way that can cause destruction fast,but from what i did see and read, if setup right, the range function or request-range, could eat memory and spit it out like chewing tobacco.
Anyhow, to me it is still partly an issue, I am looking for a way to now block ALL Request-Range requests, and range: requests, in BSD8.2 (stable) Ipfw rules, so i guess this will have to be good to block this, or maybe a script running alongside apache to watch the range sizes, but, i will still persist with trying to find a better solution than range fileds,or a better way to recieve and handle ALL range requests, it is still not good enough from a produxction endpoint, altho it might be worth checking the range filter section and maybe add to it something where it automatically blocks mutiple single digit ex: 5- , 5- , 5- - block it (higher) number requests..
it is not much but, it is the only thing wich seems to be repetitious to make any of these attacks now effective, considering the advisory sparked a tonne of apache updates wich is fine by me, as i watched the damage it did to a completely un protected box and my jaw dropped.. but to then know it is still possible to do almost the same thing, using the same code, well, thats just not designed right... coders could easily code things within limits of the ranges wich would be set lower if that is a security measure ever used, then i dont know why it has not been deployed already.
People adapt, computers dont adapt without human intervention..
A trigger to notify/warn of large requests or some halt on requesting until admin is there, i dont know but there has to be a better way to restrict the range fields or containers or whatever people are calling it, but to me when something says bytes= , then thats = data.
I hope that your apachekiller.pl doesnt kill my box to hard, but thanks for also your interest, and i know many others still hate to admit it but, it is the biggest thing really to hit apache for along time, something wich forced alot of updates, and some boxes may not even be able to have anything more done than medium patches, or temp fixes, because of just setup or the way the person has configured things, or it would take them to rebuild theyre entire network... this is what has occurred, and many boxes are still just not tested to it, the first exploit.pl for that was NOT correct because it involved mod-deflate and mod_gzip wich later from kcopes own mouth he said this was inn error, but, that code was still enough to do the job for pentesting.. still, it was not made according to the end advisory, and should be done that way, so all fields are tested, and all areas of the httpd are pushed, with some debug action to help people debug theyre networks, it would surely not 
 be hard todo this, it is still a problem, and it wont go away unless the right tools are there to test for it everytime, and yea sure could maybe add to the code but really, it needed a recode for pentest environment, where you see range-size,and other things wich would be useful to helping the debug process.
i guess it is a matter of 'go do it yaself' but, if i must, then i will..and any code wich assists this to be a proper-exploit, so fits the advisory wich was given, kcopes worked great but, mixed with abit of later coded scripts, it could probably be much better for debug anyhow.
I will try my best to work with the killapache2.pl wich would have a major underlying problem still visible from what has been said, so i guess this would probably be more functional scripting to use to make it, reverse-code of the apache killer,wich includes debug+byte-size alignment to be high, sounds good to me!
thanks for your interest, this topic is a huge one,so i guess it is great to be part of it, cheers, xd / dru



On 14 September 2011 11:36, Javier Bassi <javierbassi@...il.com> wrote:

> On Mon, Sep 12, 2011 at 11:26 PM, xD 0x41 wrote:
> > I know this topic is OLD but, i just wonder and, also having spoken
> > to
> kcope
> > re this myself, discussed the size of each bucket wich can be made
> > to stupendous amounts and using a different vector, ok, instead of
> Range:bytes=
> > , picture a GET request with as was shown in the code is there, you
> > "Request-Range: bytes=5-,5-69,5-" , now we have bypassed most
> > filters already in place, and the request range code, is exactly the
> > same as
> range
> > code.
> > Only one person spotted this.
>
> HTTPD advisory was very clear that both Range and Request-Range can be
> used. Everyone who unset Range probably unset Request-Range too. If
> host is vulnerable its a little better to use Range because using
> Request-Range will take 8 bytes more. (more bytes = less ranges)
>
> I have tested a bit the exploit and saw 1300 ranges is just a fixed
> number chosen by kingcope but it can be a little bigger. Range field
> can be almost 8KB long and its a total waste of bytes to use x-y,
> format where y is an increasing number that will take more than one
> digit. So instead of 1300 you can get it to 2725 max if you use repeat
> x-, where x is always single digit number. By doing that the exploit
> gets much more effective.
>
> I have attached the source if anyone cares
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20110914/15cb1b85/attachment-0001.html

------------------------------

Message: 6
Date: Wed, 14 Sep 2011 09:41:57 +0300
From: "Irene Abezgauz" <irene@...kersec.com>
Subject: [Full-disclosure] Seeker Advisory Sep11: Insecure Redirect in
        Microsoft SharePoint Portal
To: <full-disclosure@...ts.grok.org.uk>
Message-ID:
        <408E44BC9EB1A74DB458543F5BCDA35AC4133B@...dalf.Hacktics.local>
Content-Type: text/plain; charset="us-ascii"

Seeker Research Center Security Advisory



This vulnerability was discovered by Seeker(r) Automatic Run-Time Application Security Testing Solution

bDisclosed By Irene Abezgauz, September 13th, 2011



=========

I. Overview

=========

An Insecure Redirect vulnerability has been identified in Microsoft SharePoint shared infrastructure. This vulnerability allows an attacker to craft links that contain redirects to malicious sites in the source parameter used throughout SharePoint portal.


The exploitation technique detailed in this document bypasses the cross application redirection restriction which normally limits such redirects restricting access to external sites.



A friendly formatted version of this advisory is available at:
http://www.seekersec.com/Advisories/SeekerAdvMS03.html



=======

II. Details

=======

Multiple pages and components in Microsoft Sharepoint use the source parameter to redirect users to a new location after accessing a certain page, such as:

POST
/Docs/Lists/Announcements/NewForm.aspx?Source=http%3a%2f%2f127.0.0.1%2fD
ocs%2fdefault.aspx

In order to avoid cross application redirects (which pose a threat to the system), Microsoft Sharepoint enforces checks on these redirects, and limits them to localhost or 127.0.0.1, or the SharePoint server IP (the IP redirect is only valid if the redirect is to an actual SharePoint page on the server, redirects to localhost or 127.0.0.1 will work regardless of existence of relevant page).

The implementation of this verification, however, is flawed, and can be circumvented by creating hostnames which begin with the string localhost, or 127.0.0.1 even if they are not localhost.

Due to domain naming restrictions the 127.0.0.1 prefix cannot be used in exploitation, as http://127.0.0.1.seekersec.com is not a valid domain name - subdomain names cannot be digits only. However, redirects to http://localhost.seekersec.com or http://localhostie.seekersec.com are valid. The following prefixes can be provided into the Source parameter to exploit this vulnerability:

                localhostaaa, localhost.seekersec.com, etc.

An attacker can generate an attack by creating a site containing localhost in its name, and crafting a URL which embeds into the source parameter a link that lead to sites outside the current application.
Once a victim follows the specially crafted link he indeed arrives at the selected page of the vulnerable SharePoint application. Once the page operation is completed, the user will be redirected to the URL in the source parameter.



========

III. Exploit

========

Sample exploitation of this vulnerability would be crafting the following link:

http://MySharePoint/Docs/Lists/Announcements/NewForm.aspx?Source=http%3a
%2f%2flocalhost.seekersec.com

It is important to note that in many situations, even if the application does not use the source parameter by default, this parameter can be added manually to the URL, leading to exploitation of this vulnerability.



================

IV. Affected Systems

================

Microsoft SharePoint 2007

Microsoft SharePoint 2010



========

V. Solution

========

Microsoft has released a fix for this vulnerability, see
http://technet.microsoft.com/security/bulletin/MS11-074 for further information.



=======

VI. Credit

=======

The vulnerability was automatically discovered by Seeker(r) - New generation application security testing solution, utilizing ground breaking BRITE(tm) technology (Behavioral Runtime Intelligent Testing Engine).

Further research and publication was performed by Irene Abezgauz, Product Manager, Seeker Security.

For more information please visit www.seekersec.com



-----------------

Irene Abezgauz

Product Manager

Seeker Security

www.seekersec.com

E-Mail:    irene@...kersec.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20110914/f352b8e4/attachment-0001.html

------------------------------

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

End of Full-Disclosure Digest, Vol 79, Issue 21
***********************************************
CONFIDENTIALITY NOTICE: This email communication and any attachments may contain confidential 
and privileged information for the use of the designated recipients named above. If you are 
not the intended recipient, you are hereby notified that you have received this communication 
in error and that any review, disclosure, dissemination, distribution or copying of it or its 
contents is prohibited. If you have received this communication in error, please reply to the 
sender immediately or by telephone at (617) 426-0600 and destroy all copies of this communication 
and any attachments. For further information regarding Commonwealth Care Alliance's privacy policy, 
please visit our Internet web site at http://www.commonwealthcare.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/

Powered by blists - more mailing lists