[Full-disclosure] Simple Machines Forum (SMF) <= 2.0.5 - multiple vulnerabilities

[Moritz Naumann]

According to

http://simplemachines.org/community/?topic=509417#msg3592194

Simple Machines Forum <= 2.0.5 (but > 1.1.*) is vulnerable to one or
more (currently undocumented) security issues.

The changes between v2.0.4 and 2.0.5 can be reviewed at
http://custom.simplemachines.org/upgrades/index.php?action=upgrade;file=smf_patch_2.0.5.tar.gz;smf_version=2.0.4

This is just a heads up, I haven't tried to look into those in detail.

CVE folks: If you'll handle this, please also check the last ones:
http://simplemachines.org/community/?topic=496403.0
http://osvdb.org/show/osvdb/92745
http://osvdb.org/show/osvdb/88909

Moritz
-- 
Naumann IT Security Consulting

Samariterstr. 16
10247 Berlin
Germany

___
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] XSS in Elgg 1.8.12, 1.7.16 (core module "Twitter widget")

[Moritz Naumann]

Hello dear XSS bored audience,

the PHP based social networking engine Elgg [1], versions 1.8.12 and
1.7.16 and earlier, bears a persistent script injection vulnerability in
its core module "Twitter widget", which allows for XSS attacks.

On installations which have the Twitter widget activated (disabled by
default, but in use on many installations), any authenticated user may
add the Twitter to their activity / dashboard page. Editing its
configuration allows the user to set the twitter_username parameter. The
value stored in this parameter will be echoed without sanitation [2]
when this page is viewed by any other user, authenticated or not.

For mitigation, the Twitter widget can be disabled by a site admin (in
the admin backend's plugin configuration area).

According to changes committed [3] to their Git repository Elgg
developers will provide a fix for this issue in the upcoming (?) 1.8.13
release.

This was originally reported by
 Moritz Naumann
 http://moritz-naumann.com
on January 17, to security[at]elgg.org, and got me a prompt vendor
reply. Coordination of advisory release is something to improve upon
next time.

A CVE ID has, to my knowledge, not yet been assigned. Secunia has
assigned it SA52007.

Have fun,

Moritz

[1] http://elgg.org/
[2]
http://github.com/Elgg/Elgg/commit/a74a88501c41e89c8bcd7fc650ae2f8cc0a5003d#L2L21
[3]
http://github.com/Elgg/Elgg/commit/19dc507c2fccb378be2a44a762edf6c1e7afa334#L0R11

___
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

[Moritz Naumann]

On 20.08.2011 00:23 HI-TECH . wrote:
> (see attachment)
> /Kingcope

Works (too) well here. Are there any workarounds other than rate
limiting or detecting + dropping the traffic IPS-wise?

Moritz

___
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] Alice (Telefonica Germany) Modem 1111 DoS + XSS

[Moritz Naumann]

German ISP 'Alice' has been shipping custom embedded devices (DSL
modems/routers etc.) for the past few years. Their first self-branded
DSL modem, Alice Modem , using firmware version 4.19, is prone to at
least the following two security vulnerabilities (after it has passed
initial configuration).

1. Denial of Service (DoS) via HTTP GET:
http://alice.box/natAdd?apptype=userdefined&rulename=%22%3E%3Cscript%3Ealert(%22XSS%22)%3C/script%3E&waninterface=ipwan&inthostip1=192&inthostip2=168&inthostip3=1&inthostip4=99

After accessing this URL, the modem fails to accept any additional
connections via any of the protocols it supports (incl. telnet). The web
interface is only available from within the LAN, but an insecure
redirect from the Internet would work to exploit this.


2. Cross Site Scripting (XSS)
http://alice.box/natAdd?apptype=userdefined&rulename=%3E%3Cscript%3Ealert%28%22XSS%22%29%3C%2Fscript%3E%3Cx+y=&waninterface=ipwan&inthostip1=192&inthostip2=168&inthostip3=1&inthostip4=199&protocol1=proto_6&extportstart1=1&extportend1=1&intportstart1=1&intportend1=1&protocol2=proto_6&extportstart2=&extportend2=&intportstart2=&intportend2=&protocol3=proto_6&extportstart3=&extportend3=&intportstart3=&intportend3=

Accessing this URL via HTTP GET or POST makes the router set a port
forwarding rule whose label ('rulename') contains javascript code. Due
to lack of (server side) input validation, this code is run in the web
browser. Once set, additional requests to the listing of port forwarding
rules at
http://alice.box/webconfig/portforwarding/main_portforwarding.html
will cause the javascript code to be executed, and may trigger cross
site scripting.


Telefonica Germany, previously Hansenet Telekommunication, has been
notified about these issues multiple times starting 2011-03-01. One day
later, I received a response indicating this model is no longer being
shipped and that there will be no fix for it. Additional attempts to get
in touch, explaining that this does not help any of the clients who are
already using this device, were not responded to (other than by
confirming receipt).

The same ISP has their 'secure' client area accessed via
https://www.alice-dsl.de which has obvious implementation flaws:
https://www.ssllabs.com/ssldb/analyze.html?d=www.alice-dsl.de
(which I notified the company about on 2010-12-20)

Moritz Naumann
-- 
Naumann IT Security Consulting
Samariterstr. 16
10247 Berlin
Germany


___
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] Php gif upload thumbnail creation remote exploit

[Moritz Naumann]

On 19.06.2011 13:35 HI-TECH . wrote:
> A good and working example for this technique is the "EQdkp-Plus" PHP 
> Software,
> the URL http:///dkp/plugins/mediacenter/upload.php
> allows to upload image files. There are two checks made by the software:
> * Extensions check, where they forget to check for the php3 extension,
> which might be parsed by the webserver as php code.
> * Check if the upload is actually an image.

Either you or the developer of this software or both of you are missing
the point here: in terms of server side security it does not matter
whether or not PHP code is stripped off an image file by the time it is
converted. In fact, you can always legitimately have comments and other
meta data in image and other media files which are often stored as
unmodified plain text and this could also include PHP code.

What does matter is that this application, its documentation, the
installation you tested against or a mixture of these allow for
executing anything within the "thumbs_b" (and possibly other directories
which contain file uploads) as PHP code in the first place.

Any properly configured webserver which supports CGI or SAPI disallows
any dynamic processing of stored content by default, and only allows for
it in given whitelisted locations. In case of mod_php, this means that
the AddType association should only be in place for a given set of
directories and/or files which are actually meant to contain executable
PHP code. mod_php also offers the PHPEngine bit for this purpose (but
this is flawed by design, since you must not make the process you want
to secure against take the decision whether or not it will run).

Defaulting to no PHP support may not be an option for shared hosting,
but then users and applications - by providing proper documentation and
default setups/webserver configuration snippets - can still choose to
secure the environment they operate in by using a blacklisting or - much
better - a whitelisting approach.

All of this has been said and written many times before - I'm just
summing it up once again since this is still a common mistake which both
software developers and server administrators / shared hosting users
keep repeating on a daily basis. Since shared hosting users are usually
allowed to have no clue of what they are doing, the responsibility is
very much in the domain of server administrators and application
developers to provide secure environments and defaults, as well as good
and easily accessible documentation.

Moritz

___
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] [SquirrelMail-Security] XSS in Squirrelmail plugin 'Virtual Keyboard' <= 0.9.1

[Moritz Naumann]

Hi Paul,

On 16.10.2010 02:44 Paul Lesniewski wrote:
> On Tue, Oct 5, 2010 at 9:28 AM, Moritz Naumann
>  wrote:
>> Squirrelmail plugin 'Virtual Keyboard' version 0.9.1 and lower is
>> vulnerable to cross site scripting (XSS).
[..]
> As a member of the SquirrelMail development team, I am quite
> displeased with this announcement.  

thanks for openly sharing your opinion on this matter.

I guess I have to provide a complete timeline. 'Complete' here, means
from my perspective, since I initially reported the vulnerability and
thus have the responsibility of ensuring it get's published, in time, so
that users are able to patch their vulnerable systems. That's also why
the Full Disclosure Policy [1] requires a steady flow of communication
and information in both directions. Unfortunately, in this case, it was
somewhat one-sided.

May 05, 2010: Moritz reports vulnerability to Daniel and
security-2...@squirrelmail

May 06, 2010: Daniel responds to Moritz and security-2...@squirrelmail,
attaching a fixed version

May 07, 2010: Moritz responds to Daniel and security-2...@squirrelmail,
asking for source code repository or other public storage location

May 07, 2010: Daniel responds to Moritz and security-2...@squirrelmail,
reporting that his account on the squirrelmail.org plugin repository is
disabled and he's trying to get in touch with the Squirrelmail
developers on this

May 07, 2010: Moritz responds to Daniel, stating that (after having
reviewed the new version by Daniel) it should fix the previously
reported vulnerability.

May 10, 2010: Moritz responds to Daniel and security-2...@squirrelmail,
trying to mediate between Daniel and the Squirrelmail developers, in the
interest of getting the security fix out as soon as possible, and
checking with Daniel whether it would be ok to distibute his update by
other means in case his access to the repository cannot be restored in a
timely fashion.

May 10, 2010: Daniel responds to Moritz, giving permission to publish
his work, stating he is awaiting a response by the Squirrelmail Team to
get his plugin repository account reactivated.

May 11, 2010: Paul of Squirrelmail responds to Moritz (for the first
time) and Daniel, stating that the plugin is not conformant with current
Squirrelmail standards, and that he (not the Squirrelmail team as a
whole) will work with Daniel to get the code to release quality, asking
Moritz for patience and  noting that he is "sure [Moritz] will be made
aware of a release".

May 29, 2010: Moritz contacts Daniel, Paul and
security-2...@squirrelmail; not having heard from either Daniel or
anyone from Suqirrelmail for a while, he asks for an update.

May 31, 2010: Daniel responds to Moritz, stating that he is currently ill.

June 01, 2010: Moritz responds to Daniel stating that he will delay the
advisory for another week.

June 02, 2010: Daniel responds to Moritz, Paul and
security-2...@squirrelmail, attaching an improved fixed version

June 07, 2010: Moritz responds to Daniel, Paul and
security-2...@squirrelmail, suggesting that, "unless more changes need
to happen, the Squirrelmail team could probably review and publish"
Daniels new version in their plugin repository.

Oct 05, 2010: Not having heard again from Squirrelmail team or Paul or
Daniel on this matter, realizing that 5 months after the initial report
there is still no security fix available, Moritz publishes an advisory,
including Daniels' fix, in the interest of safeguarding the users of
this plugin (and, yes, for the credit, too).


While I think this timeline puts the handling of this vulnerability in a
different light than your email, I am not going into the details since I
am not interested in extending this discussion - it simply serves no
purpose. My primary interest was in making it possible to fix the
vulnerable installations out there, and this advisory was a result of
it. I would have preferred to see it better handled (and I'm not only
addressing this to you, Paul), but this is not always possible.

If you would like to discuss this further, you are welcome to do so, but
please consider whether it is possible to do this off-list
(I assume only few subscribers, if any, will not consider this
off-topic). I have nothing to hide in this respect, but I also don't
want to annoy people with a mostly - to the general audience of these
mailing lists - irrelevant discussion.

Moritz

[1] http://www.wiretrip.net/rfp/policy.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/

[Full-disclosure] XSS in Horde IMP <=4.3.7, fetchmailprefs.php

[Moritz Naumann]

Hi,

Horde IMP v4.3.7 and lower are subject to a cross site scripting (XSS)
vulnerability:

The fetchmailprefs.php script fails to properly sanitize user supplied
input to the 'fm_id' URL parameter. If exploited, injected code will be
persistent (persistent XSS) and will execute once the user (manually)
accesses mail fetching preferences.

The following URL can be used as a proof of concept:
> [path_to_horde_imp]/fetchmailprefs.php?actionID=fetchmail_prefs_save&fm_driver=imap&fm_id=zzz%22%3E%3Cscript%3Ealert%28%27XSS%27%29%3C%2Fscript%3E%3Cx+y%3D%22&fm_protocol=pop3&fm_lmailbox=INBOX&save=Create

Prior authentication to IMP is required for immediate exploitation.
Follow-up authentication is also possible if the victims' IMP
configuration has folder maintenance options disabled.

This issue has been fixed by Jan Schneider of the Horde Project:
> http://git.horde.org/diff.php/imp/fetchmailprefs.php?rt=horde&r1=1.39.4.10&r2=1.39.4.11

According to him, Horde IMP v4.3.8 (or a release candidate) which fixes
this issue is to be released within the week. Release announcements will
likely be communicated through
http://lists.horde.org/mailman/listinfo/announce

Credits for this discovery:

Moritz Naumann
Naumann IT Security Consulting, Berlin, Germany
http://moritz-naumann.com

Thanks for reading,

Moritz

-- 
Naumann IT Security Consulting
Samariterstr. 16
10247 Berlin
Germany

Web http://moritz-naumann.com
GPG http://moritz-naumann.com/keys/0x277F060C.asc
17FE F47E CE81 FC3A 8D6C 85A0 9FA1 A4BD 277F 060C

Inhaber: Moritz Naumann · StNr. 22/652/12010 · USt-IdNr. DE266365097

___
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] XSS in Horde Application Framework <=3.3.8, icon_browser.php

[Moritz Naumann]

Hi,

Horde Application Framework v3.3.8 and lower are subject to a cross site
scripting (XSS) vulnerability.

The icon_browser.php script fails to properly sanitize user supplied
input to the 'subdir' URL parameter before printing it out as part of a
HTML formatted error message.

The following URL can be used as a proof of concept:

> [path_to_horde]/util/icon_browser.php?subdir= onload="alert('XSS')">&app=horde

Prior authentication is not required for exploitation.

This vulnerability was reported to the Horde Project on 19.05.2010 and
fixed by Michael M. Slusarz in the frameworks' GIT repository within a week:
> http://git.horde.org/diff.php/horde/util/icon_browser.php?rt=horde-git&r1=a978a35c3e95e784253508fd4333d2fbb64830b6&r2=9342addbd2b95f184f230773daa4faf5ef6d65e9

Hoping to see an upcoming fixed release (which did not take place)
I have delayed publication - admittedly too much.

Credits for this discovery:

Moritz Naumann
Naumann IT Security Consulting, Berlin, Germany
http://moritz-naumann.com

Moritz

___
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] Silverstripe <= v2.3.4: two XSS vulnerabilities

[Moritz Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Silverstripe CMS, , version 2.3.4 and lower
(and its unreleased 2.4 branch), is vulnerable to two Cross Site
Scripting issues.

1. The comment posting mechanism of Silverstripe ('PostCommentForm')
fails to properly sanitize the 'CommenterURL' parameter. This allows for
persistent injection of HTML or javascript code within existing HTML tags.

2. The forum module is vulnerable to a reflective XSS issue caused by
the search script failing to properly sanitize input to the 'Search'
parameter. When invoking this URL:
SILVERSTRIPESITE/forums/search/?Search=%22%20onmouseover=%22javascript:alert%280%29;%22
trying to reorder the search results will trigger execution of the
injected javascript code.


According to its quickly responding developers, Silverstripe version
2.3.5 fixes both issues:
http://groups.google.com/group/silverstripe-announce/browse_thread/thread/f51749342eee9456

Relevant SCM changesets:
http://open.silverstripe.org/changeset/97034
http://open.silverstripe.org/changeset/97070
http://open.silverstripe.org/changeset/97073
http://open.silverstripe.org/changeset/97074
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEAREKAAYFAktZ9qEACgkQn6GkvSd/BgzVmACfaNiygTiaMy59QygEu0xeZ93S
KzsAoIIQA7krAVdNycjXdh7EaIMUiVk+
=9I4y
-END 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] Cacti 0.8.7e: Multiple security issues

[Moritz Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Cacti 0.8.7e and earlier versions are affected by multiple security
issues. Issues 1-4 are cross site scripting issues, issue 5 is a
priviledge escalation issue.




1. XSS 1

A HTTP GET request against the following URL will, on a web browser
with Javascript support, cause a dialog box saying '1' to be displayed:

http://CACTIHOST/graph.php?action=zoom&local_graph_id=1&graph_end=1%27%20style=visibility:hidden%3E%3Cscript%3Ealert(1)%3C/script%3E%3Cx%20y=%27

This vulnerability is only exploitable if the victim is allowed to view
graphs. This will be true if the victim has previously authenticated
against Cacti or if both the guest user has been activated (default:
disabled) and the graph view permission was set to 'guest' (default:
'No User').

This vulnerability was tested with Firefox 3.0.6.

The Cacti group provides a patch to fix this vulnerability:
http://www.cacti.net/downloads/patches/0.8.7e/cross_site_fix.patch



2. XSS 2

The following curl invocation will generate a HTTP POST request
against

http://CACTIHOST/graph_view.php?action=tree&tree_id=1&leaf_id=7&select_first=true

with an 'application/x-www-form-urlencoded' content type HTTP body part
containing
  date1=%27%3E%3Cscript%3Ealert%281%29%3C%2Fscript%3E%3Cx+y%3D%27'
Curl will write the resulting output to a file named poc.html.

> curl -d 'date1=%27%3E%3Cscript%3Ealert%282%29%3C%2Fscript%3E%3Cx+y%3D%27' 
> 'http://CACTIHOST/graph_view.php?action=tree&tree_id=1&leaf_id=7&select_first=true'
>  > poc.html

When this file is loaded and rendered by a web browser with Javascript
support, this will cause a dialog box saying '2' to be displayed.

This vulnerability is only exploitable if the victim is allowed to view
graphs. This will be true if the victim has previously authenticated
against Cacti or if both the guest user has been activated (default:
disabled) and the graph view permission was set to 'guest' (default:
'No User').

The Cacti group provides a patch to fix this vulnerability:
http://www.cacti.net/downloads/patches/0.8.7e/cross_site_fix.patch



3. XSS 3

If an attacker or the victim has permission to modify the graph
display settings via graph_settings.php, the attacker is able to
persistently inject javascript code via the 'page_refresh' and
'default_dual_pane_width' parameters.

Setting 'page_refresh' to the following value will, on any consecutive
visitors' web browser with Javascript support, cause a dialog box saying
'3' to be displayed:
  300'>alert(3)alert(3)http://www.cacti.net/downloads/patches/0.8.7e/cross_site_fix.patch



4. XSS 4

A HTTP GET request against the following URL will, on a web browser
with Javascript support, cause a dialog box saying '4' to be displayed:

> >
http://CACTIHOST/graph.php?action=properties&local_graph_id=201&rra_id=0&view_type=tree&graph_start=%3C/pre%3E%3Cscript%3Ealert(4)%3C/script%3E%3Cpre%3E

This vulnerability is only exploitable if the victim is allowed to view
graphs. This will be true if the victim has previously authenticated
against Cacti or if both the guest user has been activated (default:
disabled) and the graph view permission was set to 'guest' (default:
'No User').

Alternatively, a similar injection can be achieved, if an attacker or
his victim has permission to modify the graph display settings via
graph_settings.php. If so, the attacker is able to persistently inject
javascript code via the 'title_size', 'legend_size', 'axis_size' and
'unit_size' parameters.

Setting any of these parameters to the following value will, on any
consecutive visitors' web browser with Javascript support, cause a
dialog box saying '4' to be displayed:
  8alert(4)

This vulnerability was tested with Firefox 3.0.6

The Cacti group provides a patch to fix this vulnerability:
http://www.cacti.net/downloads/patches/0.8.7e/cross_site_fix.patch



5. Priviledge escalation

Finally, due to the permissive way the web interface allows Cacti
to be configured, a cacti administrator is also able to execute
arbitrary commands on the system as the user the Cacti polling mechanism
 runs as (usually a non-priviledged user).

For example, it is possible to successfully spawn (and connect to) a
backdoor/remote shell on the Cacti system by changing the "Data Input
Method" for "Linux - Get Memory Usage". Setting "Input String" to
  nohup nc -l -p  -n -e /bin/sh &
would spawn a remotely accessible shell whenever this handler was called
(every couple of minutes by default on my Debian test system).

Cacti developers say:
> There is no effective way to fix the data input method without breaking 
> Cacti.  It will be reviewed for the release of 0.8.8.



The XSS issues are currently tracked as CVE-2009-4032 (additional CVEs
may or may not be assigned), issue 5 has not been tracked so far (to my
knowledge).
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEAREKAAYFAksOFWYACgkQn6GkvSd/Bgwb0QCfZu7dWpBE7FSeds0jeFa1NmzN
q44An3dl2cZgU/LRpZSjYpuqbo2Ukzbe

Re: [Full-disclosure] PHP "multipart/form-data" denial of service

[Moritz Naumann]

Bogdan Calin wrote:
> Description
> 
> PHP version 5.3.1 was just released. This release contains a patch for a
> denial of service condition we've reported on 27 October 2009. The
> problem is related with PHP's handling of RFC 1867 (Form-based File
> Upload in HTML).

Thanks for the good description and test results, Bogdan.

> Proof of concept
> -
> I'm not going to publish the proof of concept Python script.
> If you have a valid reason why you would need the proof of concept, you
> can contact me at this email address (bogdan [at] acunetix.com).

Someone has apparently written one in bash:
http://www.paste-it.com/view/77958658
If testing for IT security issues wasn't practically illegalized in
Germany I might even have done it myself.

This script wasn't so effective when I tested it here, but it did work
after I spawned a couple processes. It takes it quite a while to prepare
the requests, though, and without the randomization stuff and with
>=python this could probably be done much faster.

___
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] Executing arbitrary PHP code on OpenX <= 2.8.1

[Moritz Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

OpenX adserver version 2.8.1 and lower is vulnerable to remote code
execution. To be exploited, this vulnerability requires banner / file
upload permissions, such as granted to the 'advertiser' and
'administrator' roles.

This vulnerability is caused by the (insecure) file upload mechanism of
affected OpenX versions. These would check magic bytes of an uploaded
file to determine its MIME type, and erroneously assume this
information to be reliable. Additionally, while the file name of
uploaded files is changed, the file extension is not.

As such, it is possible to upload image files with embedded PHP code and
.php file extension. Unless PHP script execution is explicitly prevented
for the file upload location (which has not been documented in the OpenX
manual so far and it is not the result of a default installation), the
PHP code will execute as soon as HTTP access to the file location will
cause it to be executed by the web server.

To clarify, an attacker exploiting this security issue does require
prior access to OpenX, i.e. exploitation is only possible after
successful authentication. On the other hand, advertiser access is a
rather low permission level and should not allow for system access.

If these bugs were not hidden from OpenX' bug tracker, you could read up
more about issue X-5747 here:
https://developer.openx.org/jira/browse/OX/fixforversion/10910

OpenX 2.8.2 has already been released in October to fix this issue and
can be downloaded from
http://www.openx.org/ad-server/download

Moritz Naumann
Naumann IT Security Consulting
Berlin, Germany

http://www.moritz-naumann.com/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEAREKAAYFAksLvToACgkQn6GkvSd/BgxufgCfb27dD4mvPfnOa6YEthKNRzrm
C7YAnieGtdnqtzBO28zThXHHy/WnCeHG
=3R3Y
-END 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] WordPress <= 2.8.5 Unrestricted File Upload Arbitrary PHP Code Execution

[Moritz Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Milan Berger wrote:
> Hi there,
> 
>> IV. PROOF OF CONCEPT
>> -
>> Browser is enough to replicate this issue. Simply log in to your  
>> wordpress blog as a low privileged
>> user or admin. Create a new post and use the media file upload
>> feature to upload a file:
>>
>> test-image.php.jpg
>>
>> containing the following code:
>>
>> >  phpinfo();
>> ?>
>>
>> After the upload you should receive a positive response saying:
>>
>> test-vuln.php.jpg
>> image/jpeg
>> 2009-11-11
>>
>> and it should be possible to request the uploaded file via a link:
>> http://link-to-our-wp-unsecured-blog.com/wp-content/uploads/2009/11/test-vuln.php.jpg
> 
> tried this with lighttpd and wordpress 2.8.5 and PHP 5.2.11-pl0-gentoo
> with Suhosin-Patch 0.9.7
> Shows a broken image no code executed.

This is specific to Apaches' Add* directives, when combined with the PHP
SAPI / Apache module:
http://httpd.apache.org/docs/2.2/mod/mod_mime.html#multipleext
http://isc.sans.org/diary.html?storyid=6139

It's been like that for years, but many Linux distros still ship with
default configurations which bear this issue.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEAREKAAYFAkr8SxwACgkQn6GkvSd/BgyWFACcDDGWwp92WxOunIr26u3juxL5
FvYAn1ynPl1pBolZKyV/mLQrb+i/AROY
=sM0Q
-END 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] PHP APC vulnerable to local attacks

[Moritz Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

PHP APC is an opcode cache for PHP, or, as the developers say: "APC is a
free, open, and robust framework for caching and optimizing PHP
intermediate code."

http://pecl.php.net/package/APC

While at least some of its developers do not consider this an issue
(based on the assumption that "it is pretty well understood that opcode
caches need a better defined environment than the chaos of a general
mass vhosting ISP"), it is not documented and not neccessarily known
that PHP APC does not provide safety measures against local attacks.

According to one of the developers, in a multi-user environment, attacks
that users can currently carry out  against other local users are
* filling the user cache
* constantly delete the cache
both of which may lead to a DoS situation.

In addition, there's a cross site scripting issue which comes into play
when you have local users which are able to create files and cause those
to be cached, and a server admin later visits the apc.php web interface
which comes with PHP APC. See below for further information on this
specific issue.




Cross Site Scripting vulnerability in PHP-APC

PHP APC 3.1.1, 3.0.19 and probably earlier versions of PHP-APC are
subject to a cross site scripting vulnerability which can be triggered
by local users.

This issue is caused by insufficient validation of path and file names
which are displayed to an authenticated admin when viewing the 'System
Cache Entries' and 'User Cache Entries' sections on the apc.php web
management interface.

This issue can be exploited in all environments which different access
levels for the PHP APC admin and other users with local write permissions
apply.

A malicious user with local write access (such as an FTP user on shared
hosting environments) may create two directories
  

[Full-disclosure] Advisory: SANS CMS fails to sanitize web scripting

[Moritz Naumann]

Some monday morning fun:

SANS content management system fails to properly sanitize user inputs,
allowing for injection of malicious web script or HTML.
Prior authentication is required, limiting this issue to blog posts by
people with malicious intentions or who don't know what they're doing.

POC here: http://isc.sans.org/diary.html?storyid=4565

Search the source code for 'adsitelo' (without quotes).

___
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] Tikiwiki 1.9.8 exploit ITW

[Moritz Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

there's a tikiwiki (tikiwiki.org) remote code execution exploit in the
wild, targetting v.1.9.8 and earlier. This vulnerability is being
exploited by multiple hosts (likely a botnet) using multiple payload
websites since at least Tue 08:00 PM UTC to gain access to several
users' hotmail accounts.

Disabling url_fopen() or denying access to tiki-graph_formula.php for
unauthenticated users will prevent your site from being exploited.

I've notified the developers.

If, what it says on http://dev.tikiwiki.org/Security is up to date (i.e.
unfixed security issues of high priority initially reported 9 months
ago), then you really should not use this software.

Moritz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHDpOGn6GkvSd/BgwRCsWxAJ9bTbidmQne58/L+KmMKRM9+qK5PgCgl+Q7
e5sorw+ecp/4TO4YydX5FxA=
=0mUm
-END 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] Update: ViewCVS and ViewVC 'checkout view' content type fixation issue

[Moritz Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi!

Moritz Naumann wrote:
> This does not impact  how much the rest of my report applies. My
> findings are now being discussed on the ViewVC developers mailing list
> [1]. They apparently also impact ViewVC. Whether and to which degree
> what I am reporting can be considered a security issue is, however,
> currently subject to discussion.
> 
> For now, please follow up there only. I will be back to the security
> mailing lists as soon as this has been sufficiently discussed and there
> is something noteworthy to be said.

Here's the update I had announced.

Further discussion on the ViewVC development mailing list [1]
revealed that the content type fixation issue [2] can be found in both
ViewCVS 1.0-dev (and lower) as well as ViewVC 1.0.3 (and lower).

A 'security information' section will be contained in the 'INSTALL' file
[3] of the upcoming ViewVC 1.1.0 release. This will explain how
providing HTTP access to a code repository can have negative effects if
code which can be considered malicious for web clients is contained in
the repository.

The ViewVC code was also changed in that support of the 'checkout view'
functionality (which allows presetting the content type of the HTTP
response) will be optional and disabled by default in future releases of
ViewVC (see changelog [4]). The changes can already be obtained by
checking out revision 1547 or higher off the ViewVC SVN repository.

I recommend that users and distributors of earlier ViewVC and ViewCVS
versions should either backport the patch which disables the 'checkout
view' or the one which makes it optional and deactivate it by default.
A less simple but less restrictive patch would introduce a content type
whitelisting approach.

Thanks to the ViewVC developers for their proactive support in sorting
this out.

Moritz

[1]
[EMAIL PROTECTED]
http://viewvc.tigris.org/servlets/SummarizeList?listName=dev

[2]
Here's the explanation of the content type fixation issue, as given in
my previous email on this topic:

> Please compare what your web browser displays on these locations:
> http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/peach/anno_proto/html/bymap/test00.htm?rev=1.9&content-type=text/vnd.viewcvs-markup
> http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/peach/anno_proto/html/bymap/test00.htm?rev=1.9&content-type=text/html
> 
> The two obviously look somewhat differently, and on the second location
> you can see (assuming you have Javascript activated globally) that a
> request is made to Google (from within the security context of
> cvs.sourceforge.jp).
> 
> This means that ViewCVS and thus the domain it runs in is vulnerable to
> Cross Site Scripting, assuming that someone not fully trustable has
> write permissions on one of the CVS repositories ViewCVS grants access
> to here.
> 
> But XSS is just one possibility. This should also work for delivering
> VML exploits and other funny stuff, such as ... when some victim uses a
> funny web browser (such as Internet Explorer 5.5/6/7) and some attacker
> stores files such as this
>   http://moritz-naumann.com/tests/xss2.jpg
> in a CVS repository and makes the victim access it with with
> '&content-type=image/jpeg' appended to the ViewCVS URL.
> 
> However, all of the above requires that some admin messes around with
> CVS write access on the server ViewCVS grants read access to and gave
> access to someone with bad intentions or no clue. Of course, both of
> this could easily happen on web sites such as Sourceforge (who, however,
> introduced separate subdomains for user authentication and web based
> access to CVS), or sites which use CVS in the way a version controlled
> wiki is used and allow public write access.
> 
> I suggest that Linux distributions should patch this issue short term
> and deprecate support for ViewCVS mid to long term.

[3]
http://[EMAIL PROTECTED]/svn/viewvc/trunk/INSTALL
http://viewvc.tigris.org/source/browse/viewvc/trunk/INSTALL?view=log

[4]
http://[EMAIL PROTECTED]/svn/viewvc/trunk/CHANGES
http://viewvc.tigris.org/source/browse/viewvc/trunk/CHANGES?view=log

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGCqU/n6GkvSd/BgwRCpB9AJ4nJ0dm6OiSlHxgNL8Lc1rgGMvPVwCfY8ow
AJkoyXF/fETiBiHGLOt9j/s=
=Ht8z
-END 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] Horde 3.1.4 (RC1) fixes XSS issue

[Moritz Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

a few hours ago, Horde Framework 3.1.4 was released. This stable release
as well as a previous development release titled 3.1.4 RC1 fix a
script/HTML injection issue which does not require pevious
authentication by the victim.

By redirecting the victims' web browser to a specially crafted URL
containing the payload this issue can be exploited. As the users'
session cookie is already set by the time the injection takes place this
issue makes the user prone to XSS attacks.

The vulnerable file is framework/NLS/NLS.php.

Example:
[Base_HREF]/horde/[Horde_App]/login.php?new_lang=%22%3E%3Cbody%20onload=%22alert%28'XSS'%29%3B

[Horde_App] should be replaced by the name of an installed Horde
application, such as 'imp'.

This can only be exploited on installations which are configured to
display a language selection box on the login pages.

This issue was /not/ initially discovered by me. I document it here as
I happened to come across this while discovering XSS issues in Horde IMP
and to simplify fixing vulnerable versions of repackaged distributions
of this software.

The developers' release announcement can be found at:
  http://lists.horde.org/archives/announce/2007/000315.html

General information on this application is available at
  http://www.horde.org/

Moritz Naumann
http://moritz-naumann.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF+KZ5n6GkvSd/BgwRAvSwAJ9fUFLMnQEYbT3ZftmoCBTTxYhmfACeOrQd
n4JZtVHG3wRI8CpwRbGQjaI=
=VGUL
-END 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] Horde IMP Webmail Client version H3 (4.1.4) fixes multiple XSS issues

[Moritz Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Horde IMP Webmail Client version H3 (4.1.4) was released a few hours
ago. It contains fixes for 2 XSS issues (compared to 4.1.4 RC1).


1. Script injection through email subject lines in threaded view

Subject lines of emails, when displayed in vulnerable versions of IMP in
'multiple message view' (IMP core) or with the thread plugin, are not
properly sanitized.

An email with a custom crafted subject which may then be loaded in the
authenticated webmail session of the victim may inject malicious client
side scripting code (such as Javascript) or HTML and allow for XSS attacks.

Example:
Subject: alert('XSS')

The issue is found in thread.php.



2. Multiple XSS in search function

A victims' web browser, running a previously authenticated IMP session,
may be forced into loading a custom crafted URL pointing to the email
search function. The payload will cause the client side script code
contained in the specially crafted URL to be executed in the security
context of the domain the vulnerable copy of IMP is accessed through.
This allows for mounting XSS attacks.

There were several XSS issues in the search function which have been
fixed at the same time.

Example:
[Base_HREF]/horde/imp/search.php?edit_query=%22%3E%3Cscript%3Ealert%28'XSS'%29%3C/script%3E%3Cx=%22


Credit for discovering both issues and providing a patch for the first
one goes to
  Immerda Project Group
  http://www.immerda.ch
and
  Moritz Naumann
  http://moritz-naumann.com


The developers' release announcement can be found at:
  http://lists.horde.org/archives/announce/2007/000316.html

General information on this application is available at
  http://www.horde.org/imp/

Moritz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF+Jqxn6GkvSd/BgwRAkL9AJ9kpIExrPk2OKfhD+XpGGxK4YQ0OgCfb4bG
8SBYyCJorZCpFALUdzqTUCo=
=W/aM
-END 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] ViewCVS 0.9.4 issues

[Moritz Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Moritz Naumann wrote:
> This was previously considered a HTTP response splitting vulnerability
> by Jose Antonio Coret (Joxean Koret)
> http://lists.grok.org.uk/pipermail/full-disclosure/2005-January/030514.html
> (BID 12112, couldn't find a CVE, AFAICT it is _not_ CAN-2004-1062)
> and, according to him, a patch has been stored on the 1.0-dev CVS
> branch. The 0.9.4 release on viewvc.tigris.org seems to be unpatched and
> it's possible that some Linux distributions and whoever would normally
> care were never patched against this.

I was wrong when I assumed that the 0.9.4 release on viewvc.tigris.org
was unpatched against the issues discovered by Jose Antonio Coret
(Joxean Koret). This issue was actually fixed by the ViewCVS developers
in version 0.9.3. I am sorry for the misconception and the confusion
this has caused.

This does not impact  how much the rest of my report applies. My
findings are now being discussed on the ViewVC developers mailing list
[1]. They apparently also impact ViewVC. Whether and to which degree
what I am reporting can be considered a security issue is, however,
currently subject to discussion.

For now, please follow up there only. I will be back to the security
mailing lists as soon as this has been sufficiently discussed and there
is something noteworthy to be said.

Moritz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF440Vn6GkvSd/BgwRApdwAKCL+aPccWHsmq4Y6MP/SzrjMDtpVACbBVUE
bh85P5I1agzH5TdDwk8KxiM=
=Gsp7
-END 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] ViewCVS 0.9.4 issues

[Moritz Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi!

*
 Short version for the busy ones:
 o  Security issue on ViewCVS 0.9.4
 o  Not really exploitable unless malicious users have CVS write access
AND victim visits pre-crafted URL
*

ViewCVS 0.9.4
http://viewvc.tigris.org/servlets/ProjectDocumentList?folderID=6005
is no longer under development, has been abandoned in favor of ViewVC
(http://viewvc.org/) and should probably no longer be used in production
environments. Unfortunately this script _is_ still widely used, so I
think it's still worth telling about this otherwise not really important
finding.

The issue is one which can hardly be practially exploited (thus this
short and boring 'advisory' and no prior notice to the previous
developers). The source of the problem is that ViewCVS allows users to
specify the content type which the server generated HTTP response will
be sent with.

This was previously considered a HTTP response splitting vulnerability
by Jose Antonio Coret (Joxean Koret)
http://lists.grok.org.uk/pipermail/full-disclosure/2005-January/030514.html
(BID 12112, couldn't find a CVE, AFAICT it is _not_ CAN-2004-1062)
and, according to him, a patch has been stored on the 1.0-dev CVS
branch. The 0.9.4 release on viewvc.tigris.org seems to be unpatched and
it's possible that some Linux distributions and whoever would normally
care were never patched against this.

However, it is actually more than the response splitting issue. For an
example, please compare what your web browser displays on these locations:
http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/peach/anno_proto/html/bymap/test00.htm?rev=1.9&content-type=text/vnd.viewcvs-markup
http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/peach/anno_proto/html/bymap/test00.htm?rev=1.9&content-type=text/html

The two obviously look somewhat differently, and on the second location
you can see (assuming you have Javascript activated globally) that a
request is made to Google (from within the security context of
cvs.sourceforge.jp).

This means that ViewCVS and thus the domain it runs in is vulnerable to
Cross Site Scripting, assuming that someone not fully trustable has
write permissions on one of the CVS repositories ViewCVS grants access
to here.

But XSS is just one possibility. This should also work for delivering
VML exploits and other funny stuff, such as ... when some victim uses a
funny web browser (such as Internet Explorer 5.5/6/7) and some attacker
stores files such as this
http://moritz-naumann.com/tests/xss2.jpg
in a CVS repository and makes the victim access it with with
'&content-type=image/jpeg' appended to the ViewCVS URL.

However, all of the above requires that some admin messes around with
CVS write access on the server ViewCVS grants read access to and gave
access to someone with bad intentions or no clue. Of course, both of
this could easily happen on web sites such as Sourceforge (who, however,
introduced separate subdomains for user authentication and web based
access to CVS), or sites which use CVS in the way a version controlled
wiki is used and allow public write access.

I suggest that Linux distributions should patch this issue short term
and deprecate support for ViewCVS mid to long term.

Web application developer lessons learnt (once again):
1. Explicitly limit your application to the functionality you want and
need it to have.
2. More precisely, do not use user generated data provided in HTTP
requests to specify content types of HTTP responses unless you are using
a whitelisting approach.

Thanks for reading, have a fine day.

Moritz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF41Hln6GkvSd/BgwRAgWSAJ47KZFCVAdzLMURunMFZWrKz7AbFACdHxo7
LTzzddXx7obLmXGsot4d1ug=
=T0XX
-END 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] IE7 status: 8 days after release, 3 unfixed issues

[Moritz Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It's difficult to believe, well, no, actually it's not.

CVE-2005-3312, which is based on information released as early as
September 2005, is still unfixed in Internet Explorer 7 (and any IE6).

POC: http://moritz-naumann.com/tests/xss2.jpg

Whoever doesn't consider this a vulnerability, please direct your
comments to a null device of your choice.

Combined with http://secunia.com/product/12366/?task=advisories
this makes 3 unfixed issues in IE7 within less than ten days.

Maybe some of the 19 unpatched issues listed for IE6 on
  http://secunia.com/product/11/?task=advisories
apply for IE7, too? No, this is not meant to be a secunia promo.

Who got more unfixed IE7 (stable) issues to add to the list?

Moritz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFP/Bzn6GkvSd/BgwRArQzAJoDLuEwqRqE6fyMLTogbUESWJ0AOQCePODO
aehxOF1VUjFqmmFrD89ALRQ=
=PlVS
-END 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] Typo3 v4.x: XSS in extension "Indexed Search" v2.9.0

[Moritz Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

There's a XSS issue in the 'Indexed search' extension 2.9.0 for Typo3.
This extension is part of a default Typo3 4.0.x installlation.

Typo3 4.0.2 fixes it.

http://typo3.org/teams/security/security-bulletins/typo3-20060911-1/

Credits go to Mr. Ekkehard Gümbel (discovery) and Mr. Ingmar Schlecht
(patch).

This is rather old, dating back to september 11th. Unfortunately Typo3
advisories rarely end up here.
http://typo3.org/teams/security/security-bulletins/

Moritz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFF7qMn6GkvSd/BgwRAoNkAJ0aT/fKl7juL2J/BMu/R6agJqxykwCdGqc8
Mufef7E2mYQKUgFibpnoKbs=
=CWLZ
-END 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] Mailman 2.1.8 Multiple Security Issues

[Moritz Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



SA0013 - Public Advisory

+
+   Mailman 2.1.8 Multiple Security Issues  +
+


PUBLISHED ON
  Sep 13, 2006


PUBLISHED AT
  http://moritz-naumann.com/adv/0013/mailmanmulti/0013.txt
  http://moritz-naumann.com/adv/0013/mailmanmulti/0013.txt.sig


PUBLISHED BY
  Moritz Naumann IT Consulting & Services
  Hamburg, Germany
  http://moritz-naumann.com/

  security AT moritz HYPHON naumann D0T com
  GPG key: http://moritz-naumann.com/keys/0x277F060C.asc


AFFECTED APPLICATION OR SERVICE
  Mailman
  http://mailman.sf.net

  Mailman is a mailing list server. It comes with a web based
  management interface, built-in archiving, automatic bounce
  processing, content filtering, digest delivery, spam filters,
  and more. It is a Free Software (GPL).


AFFECTED VERSIONS
  Versions 2.1.0 up to and including 2.1.8.
  Earlier versions may be affected, too.


ISSUES
  Mailman is subject to multiple security vulnerabilities,
  ranging from cross site scripting to log file injection.

  + 1. Cross Site Scripting (CVE-2006-3636)

  Vulnerable versions of the application are subject to a XSS
  vulnerability in several functions and several parameters
  in the mailing list administration area of the web
  interface. An attacker may inject arbitrary client side
  script code into several parameters through HTTP GET and
  POST method requests. Some of the injections will result
  in persistent injection of malicious scripting code.

  To exploit these issues, prior successful authentication
  of the victim IS required. As such, only users who have a
  valid cookie for a specific mailing list stored in their
  client (including administrators who do not make use of the
  logout function) are vulnerable to this.

  The following partial URLs demonstrate some of the issues:

[BaseURI]/mailman/admin/mailman/members?findmember=%22%3E%3Cscript%3Ealert(0)%3B%3C/script%3E%3Cx%20y=%22
[BaseURI]/mailman/edithtml/tests/listinfo.html?html_code=XSS%20demoalert(0)%3B


  + 2. Log file injection
  The application is subject to a log injection vulnerability.

  By injecting CRLF sequences followed by fake time stamps,
  an attacker may inject additional lines into the log files
  created by the application.

  The following partial URL demonstrates this issue:

[BaseURI]/mailman/listinfo/doesntexist%22:%0D%0AJun%2012%2018:22:08%202033%20mailmanctl(24851):%20%22Your%20Mailman%20license%20has%20expired.%20Please%20obtain%20an%20upgrade%20at%20www.phishme.site

  This will result in a message similar to the following to
  be written into /var/log/mailman/error.log:

  Jun 11 18:50:43 2006 (32743) No such list "doesntexist":
  jun 12 18:22:08 2033 mailmanctl(24851): "your mailman license
  has expired. please obtain an upgrade at www.phishme.site"



BACKGROUND

  Cross Site Scripting (XSS):
  Cross Site Scripting, also known as XSS or CSS, describes
  the injection of malicious content into output produced
  by a web application. A common attack vector is the
  inclusion of arbitrary client side script code into the
  applications' output. Failure to completely sanitize user
  input from malicious content can cause a web application
  to be vulnerable to Cross Site Scripting.

  http://www.owasp.org/index.php/Cross_site_scripting
  http://www.cgisecurity.net/articles/xss-faq.shtml

  Log Injection
  Log injection describes the manipulation of log files as
  generated by an application or service in a way which is
  not originally intended by the programmers. An attacker
  may exploit this vulnerability to hide an ongoing attack
  or to trick the administrator of the target system into
  taking actions s/he would not otherwise take.

  http://www.owasp.org/index.php/Log_injection


WORKAROUNDS
  Issue 1:
Client: Disable Javascript.
Server: Prevent access to web administration interface.
  Issue 2:
Client: N/A.
Server: Ignore all lower case log lines.


SOLUTIONS
  The Mailman developers have released version 2.1.9 yesterday.
  This is supposed to fix all of the above issues. The updated
  packages are available at

http://sf.net/project/showfiles.php?group_id=103&package_id=69562&release_id=447065


REFERENCES
  Developer Release Announcement

http://mail.python.org/pipermail/mailman-announce/2006-September/87.html
  Mailman 2.1.9 Release Notes
http://sf.net/project/shownotes.php?group_id=103&release_id=447065


ADDITIONAL CREDIT
  N/A


LICENSE
  Creative Commons Attribution-ShareAlike License Germany
  http://creativecommons.org/licenses/by-sa/2.0/de/







-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFCJqNn6GkvSd/BgwRAqbAAJ9ZLJulLPR8J0z02sCPQphr4YFGlACfR4h5
Y3b1TokfGg6CGYY1fr+C3vI=
=MYVB
-END PGP SIGNATURE-

___
Fu

Re: [Full-disclosure] VHCS 2.x HTTP Error Cross Site Scripting

[Moritz Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

InfoSecBOFH schrieb:
> Cool... so give me a real world attack scenario with this

How to inject arbitrary client side code into this application using
this vulnerability is explained in the advisory. Web links to additional
sources explaining XSS are provided, too.

I do not think there is a requirement to provide proof that a
vulnerability is exploitable to publish it. At least, I can't find this
on the Full Disclosure charter.

If you need more information on this vulnerability, I propose you
aggregate it yourself, hire us or convince me to provide it for free.

Moritz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDhfKWn6GkvSd/BgwRAjgoAJ0ctvWyFsC3C3fKCWGtPy4LNua5hQCeOIj/
G3ihCWhGUciVfT689HzzP+Y=
=kO8I
-END 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] VHCS 2.x HTTP Error Cross Site Scripting

[Moritz Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Moritz Naumann wrote:

> SOLUTIONS Moritz Naumann IT Consulting & Services has crafted a 
> unified diff patch against VHCS 2.4.6.2 which is available at 
> http://moritz-naumann.com/adv/0006/vhcsxss/patch/index.php.diff

This patch had been lost during an upload. It's back, now.

Moritz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDhTZin6GkvSd/BgwRAkx8AJ43RauRSIke/U6GoZA3/4d7rLo2ogCfVcvY
n9zvyiQnzV5Doqn8tsNMrbo=
=Qfzc
-END 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] PmWiki 2.0.12 Cross Site Scripting

[Moritz Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


SA0005

+
+PmWiki 2.0.12 Cross Site Scripting +
+


PUBLISHED ON
  Nov 22, 2005


PUBLISHED AT
  http://moritz-naumann.com/adv/0005/pmwiki/0005.txt
  http://moritz-naumann.com/adv/0005/pmwiki/0005.txt.sig


PUBLISHED BY
  Moritz Naumann IT Consulting & Services
  Hamburg, Germany
  http://moritz-naumann.com/

  SECURITY at MORITZ hyphon NAUMANN d0t COM
  GPG key: http://moritz-naumann.com/keys/0x277F060C.asc


AFFECTED APPLICATION OR SERVICE
  PmWiki
  http://www.pmwiki.org/


AFFECTED VERSION
  Version 2.0 up to and including 2.0.12


BACKGROUND
  Everybody knows XSS.
  http://en.wikipedia.org/wiki/XSS
  http://www.cgisecurity.net/articles/xss-faq.shtml


ISSUE
  PmWiki 2.0.12 is subject to a XSS vulnerability. The
  problem exists in the 'q' parameter passed to the search
  function. Successful exploitation may allow for
  impersonification through session stealing.

  The following URL demonstrates this issue:

[pmwiki_basedir]/Site/Search?action=search&q=TRY%20ANOTHER%20SEARCH%20NOW!%20YES,%20YOU!'%20onMouseOver='alert(document.title);'%20

  This issue is caused by insufficient input validation.



WORKAROUND
  Client: Disable Javascript.
  Server: Prevent access to pagelist.php.


SOLUTIONS
  Install or upgrade to the latest release, version 2.0.13.
  Both releases and patch files are available at
http://www.pmwiki.org/pub/pmwiki/


TIMELINE
  Nov 05, 2005  Discovery
  Nov 05, 2005  Code maintainer notified
  Nov 09, 2005  Code maintainer replies
  Nov 10, 2005  Code maintainer provides fix
  Nov 11, 2005  CVE candidate assignment requested
  Nov 22, 2005  Sick of waiting for Mitre to fix their DB
  Nov 22, 2005  Public disclosure


REFERENCES
  N/A


ADDITIONAL CREDIT
  N/A


LICENSE
  Creative Commons Attribution-ShareAlike License Germany
  http://creativecommons.org/licenses/by-sa/2.0/de/


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDg45kn6GkvSd/BgwRAgeGAJ90QWc8Se621Y1wAtywgPZGgMFz2wCdFt4R
r/WQ/+HbTQq5wyDakQDRAr8=
=hRgJ
-END 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] OTRS 1.x/2.x Multiple Security Issues

[Moritz Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


SA0007

+
+   OTRS 1.x/2.x Multiple Security Issues   +
+


PUBLISHED ON
  Nov 22, 2005


PUBLISHED AT
  http://moritz-naumann.com/adv/0007/otrsmulti/0007.txt
  http://moritz-naumann.com/adv/0007/otrsmulti/0007.txt.sig


PUBLISHED BY
  Moritz Naumann IT Consulting & Services
  Hamburg, Germany
  http://moritz-naumann.com/

  SECURITY at MORITZ hyphon NAUMANN d0t COM
  GPG key: http://moritz-naumann.com/keys/0x277F060C.asc


AFFECTED APPLICATION OR SERVICE
  OTRS
  http://www.otrs.org/

  OTRS, the Open Source Ticket Request System, is a trouble
  ticket system which allows for managing customer telephone
  calls and e-mails.


AFFECTED VERSIONS
  Version 2.0.0 up to and including 2.0.3 and OTRS 1.0.0 up
  to and including 1.3.2.


ISSUES
  OTRS is subject to multiple security vulnerabilities,
  ranging from cross site scripting to SQL injection.

  >>> 1. SQL injection #1
  A malicious user may be able to conduct blind SQL code
  injection on the OTRS 'Login' function. Successful
  authentication is NOT required. By injecting a LEFT JOIN
  statement into the authentication database SQL query,
  an attacker may be able to exploit this issue.

  The following partial URL demonstrates this issue:
  [OTRS_BaseURI]/index.pl?Action=Login&User=%27[SQL_HERE]

  This results in an SQL error message being logged in the
  OTRS system log.

  >>> 2. SQL injection #2
  A malicious user may be able to conduct blind SQL code
  injection on the OTRS 'AgentTicketPlain' function in the
  'TicketID' parameter. Successful authentication IS required,
  however, a non-authenticated user will be prompted for her
  login credentials and the attack will still be carried out
  after the login succeeded. By injecting a LEFT JOIN statement
  into the SQL query, an attacker may be able to exploit this
  issue.

  The following partial URL demonstrates this issue:

[OTRS_BaseURI]/admin/index.pl?Action=AgentTicketPlain&ArticleID=1&TicketID=1%20[SQL_HERE]

  This results in an SQL error message being logged in the
  OTRS system log.

  >>> 3. SQL injection #3
  A malicious user may be able to conduct blind SQL code
  injection on the OTRS 'AgentTicketPlain' function in the
  'ArticleID' parameter. Successful authentication IS required,
  however, a non-authenticated user will be prompted for her
  login credentials and the attack will still be carried out
  after the login succeeded. By injecting a LEFT JOIN statement
  into the SQL query, an attacker may be able to exploit this
  issue.

  The following partial URL demonstrates this issue:

[OTRS_BaseURI]/admin/index.pl?Action=AgentTicketPlain&TicketID=1&ArticleID=1%20[SQL_HERE]

  This results in an SQL error message being logged in the
  OTRS system log.

  >>> 4. Cross Site Scripting #1
  OTRS is subject to a XSS vulnerability on the file attachment
  display function.

  An attacker may send malicious code inside an email attachment
  of Content-Type "text/html". A queue moderator clicking the
  attachment download button (disk symbol) on a ticket created
  based on a HTML email will have this attachment rendered by
  her browser. Thus, any malicious client side code included in
  the HTML attachment will be executed in the security context
  of the OTRS domain.

  This refers to the default configuration
  (AttachmentDownloadType = "inline") but does not apply if
  AttachmentDownloadType is set to "attachment".

  >>> 5. Cross Site Scripting #2
  OTRS is subject to a XSS vulnerability on the queue selection
  function.

  An attacker may inject arbitrary client side script code into
  the 'QueueID' parameter. Successful authentication IS required,
  however, a non-authenticated user will be prompted for her
  login credentials and the attack will still be carried out
  after the login succeeded.

  The following partial URL demonstrates this issue:

[OTRS_BaseURI]/index.pl?QueueID=%22%3E%3Cscript%3Ealert('[XSS_HERE]')%3B%3C/script%3E%3Cx%20y=%22

  >>> 6. Cross Site Scripting #3
  OTRS is subject to a XSS vulnerability on the 'Action'
  parameter. An attacker may inject arbitrary client side script
  code into this parameter. To exploit this issue, successful
  authentication IS required, however, a non-authenticated user
  will be prompted for her login credentials and the attack will
  still be carried out after the login succeeded.

  The following partial URL demonstrates this issue:

[OTRS_BaseURI]/index.pl?Action=">alert(document.title);http://en.wikipedia.org/wiki/SQL_injection
  http://www.cgisecurity.com/questions/sql.shtml

  Cross Site Scripting (XSS):
  Cross Site Scripting, also know

[Full-disclosure] VHCS 2.x HTTP Error Cross Site Scripting

[Moritz Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



SA0006

+
+ VHCS 2.x HTTP Error Cross Site Scripting  +
+


PUBLISHED ON
  Nov 22, 2005


PUBLISHED AT
  http://moritz-naumann.com/adv/0006/vhcsxss/0006.txt
  http://moritz-naumann.com/adv/0006/vhcsxss/0006.txt.sig


PUBLISHED BY
  Moritz Naumann IT Consulting & Services
  Hamburg, Germany
  http://moritz-naumann.com/

  SECURITY at MORITZ hyphon NAUMANN d0t COM
  GPG key: http://moritz-naumann.com/keys/0x277F060C.asc


AFFECTED APPLICATION OR SERVICE
  VHCS
  http://www.vhcs.net/

  VHCS, the Virtual Hosting Control System, is a virtual
  hosting management application.



AFFECTED VERSIONS
  Version 2.2.0 up to and including 2.4.6.2


BACKGROUND
  Cross Site Scripting, also known as XSS or CSS, describes
  the injection of malicious content into output produced
  by a web application. A common attack vector is the
  inclusion of arbitrary client side script code into the
  applications' output. Failure to completely sanitize user
  input from malicious content causes a web application
  to be vulnerable to Cross Site Scripting.

  http://en.wikipedia.org/wiki/XSS
  http://www.cgisecurity.net/articles/xss-faq.shtml


ISSUE
  VHCS is subject to a XSS vulnerability on its HTTP error
  messages. This issue is caused by lack of input sanitation
  in vhcs/gui/errordocs/index.php which returns unfiltered
  web server environment variables.

  Successful exploitation may allow for impersonification
  through session stealing attacks.

  The following URL demonstrates this issue:

[vhcs_basedir]/dev/inputvalidation%3Cscript%3Ealert(window.location.hash)%3B%3C/script%3E#XSS


WORKAROUND
  Client: Disable Javascript.
  Server: Prevent access to vulnerable file(s).


SOLUTIONS
  Moritz Naumann IT Consulting & Services has crafted a
  unified diff patch against VHCS 2.4.6.2 which is available at
http://moritz-naumann.com/adv/0006/vhcsxss/patch/index.php.diff

  VHCS developers may provide a fix in the 2.6 release. A release
  date is not currently set.


TIMELINE
  Oct 06, 2005  Discovery
  Oct 06, 2005  Code maintainer notified
  Oct 06, 2005  Code maintainer replies
  Nov 22, 2005  Public disclosure


REFERENCES
  N/A


ADDITIONAL CREDIT
  N/A


LICENSE
  Creative Commons Attribution-ShareAlike License Germany
  http://creativecommons.org/licenses/by-sa/2.0/de/



- -BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDg4nMn6GkvSd/BgwRArN1AJ4sCDTCsM3uPHAcapmQzxBn3WSPzwCfW8au
TbsbFQDvlDu8KbVYKMwCrOU=
=r1ta
- -END PGP SIGNATURE-

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDg44gn6GkvSd/BgwRAhizAJ0TJV+sjZ8TcWJsY4krH0yoL29SaACePWL0
BJHF33lnVIIH2rvj0GZH8Rg=
=ml2r
-END 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] Antville 1.1 Cross Site Scripting

[Moritz Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



SA0004

+
+ Antville 1.1 Cross Site Scripting +
+


PUBLISHED ON
  Nov 09, 2005


PUBLISHED AT
  http://moritz-naumann.com/adv/0004/antvxss/0004.txt
  http://moritz-naumann.com/adv/0004/antvxss/0004.txt.sig


PUBLISHED BY
  Moritz Naumann IT Consulting & Services
  Hamburg, Germany
  http://moritz-naumann.com/

  info AT moritz HYPHON naumann D0T com
  GPG key: http://moritz-naumann.com/keys/0x277F060C.asc


AFFECTED APPLICATION OR SERVICE
  Antville
  http://www.antville.org/


AFFECTED VERSION
  Version 1.1
  Possibly versions 1.0 and lower (untested)


BACKGROUND
  Everybody knows XSS.
  http://en.wikipedia.org/wiki/XSS
  http://www.cgisecurity.net/articles/xss-faq.shtml


ISSUE
  A XSS vulnerability has been detected in Antville. The
  problem is caused by insufficient input sanitation.

  By making a victim visit a specially crafted URL, it is
  possible to inject client side scripting (such as
  Javascript) and HTML which will be executed/rendered in
  her browser.

  The following URL demonstrates this issue:
[antville_basepath]/project/alert('XSS');

  This may not be easily exploitable for cookie/session
  stealing attacks due to the IP address lock on the session.


WORKAROUND
  Client: Disable Javascript.
  Server: Prevent access to the Antville installation.


SOLUTIONS
  There does not seem to be a patch available. Our attempts
  to contact the developers were unsuccessful.


TIMELINE
  Sep 19, 2005  Discovery
  Sep 19, 2005  Code maintainer notification
  Sep 29, 2005  Another code maintainer notification
  Nov 09, 2005  Public disclosure


REFERENCES
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3530


ADDITIONAL CREDIT
  N/A


LICENSE
  Creative Commons Attribution-ShareAlike License Germany
  http://creativecommons.org/licenses/by-sa/2.0/de/



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDcikon6GkvSd/BgwRAvgIAJ9T6KB39w9Hk3OcJ56I+F6lLRoKWACfTR2c
dz7aukUAwcxTA5/q12mWrsA=
=QLOX
-END 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] Multiple security issues in TikiWiki 1.9.x

[Moritz Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



SA0003

+
+Multiple security issues in TikiWiki 1.9.x +
+


PUBLISHED ON
  Nov 09, 2005


PUBLISHED AT
  http://moritz-naumann.com/adv/0003/tikiw/0003.txt
  http://moritz-naumann.com/adv/0003/tikiw/0003.txt.sig


PUBLISHED BY
  Moritz Naumann IT Consulting & Services
  Hamburg, Germany
  http://moritz-naumann.com/

  info AT moritz HYPHON naumann D0T com
  GPG key: http://moritz-naumann.com/keys/0x277F060C.asc


AFFECTED APPLICATION OR SERVICE
  TikiWiki
  http://tikiwiki.org/


AFFECTED VERSION
  1.9.x up to and including 1.9.2
  Possibly versions < 1.9 (untested)


BACKGROUND
  "Tikiwiki is a full featured Free Software (GNU/LGPL)
  Wiki/CMS/Groupware written in PHP and maintained by an
  active and international community of benevolent
  contributors."


ISSUE 1 (XSS)
  A XSS vulnerability has been detected in the fora code
  of TikiWiki. The problem is caused by insufficient input
  sanitation.

  The following partial URL demonstrates the issue:

[baseURL]/tiki-view_forum_thread.php?forumId=1&comments_parentId=0&topics_offset=10%22%20onmouseover='javascript:alert(document.title)%3B'%3E[PLEASE%20MOVE%20YOUR%20MOUSE%20POINTER%20HERE!]%20%3Cx%20y=%22

  Please move your mouse pointer over the input field
  which says so.


ISSUE 2 (Information Disclosure, possible SQL injection)

  The application discloses the installation path. This
  *may* also be useable to craft an SQL injection.

  The following partial URL demonstrates the issue:

[baseURL]/tiki-view_forum_thread.php?forumId=1&comments_parentId=0&topics_sort_mode=FOOBAH


WORKAROUND
  Issue 1: Disable Javascript (client) or deny access to
  TikiWiki (server).
  Issue 2: Set PHP to log errors to file only (issue 2).


SOLUTIONS
  We are not aware of a maintainer provided fix.


TIMELINE
  Oct  6, 2005: Maintainer informed
  Oct  6, 2005: First maintainer reply
  Oct 14, 2005: Request for additional information sent
to maintainer
  [in between]: issues fixed on maintainer website
  Nov 09, 2005: Public disclosure


REFERENCES
  Issue 1: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3528
  Issue 2: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3529


ADDITIONAL CREDIT
  N/A


LICENSE
  Creative Commons Attribution-ShareAlike License Germany
  http://creativecommons.org/licenses/by-sa/2.0/de/


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDcigMn6GkvSd/BgwRAnfxAJ93CwGPU6+bGrYrYSX4AoXcWmOerACfecUN
b/XTfSxhrOl9eRV4GVBBINI=
=DMEp
-END 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] PoC for PHP Cross Site Scripting (XSS)XVulnerability in phpinfo()

[Moritz Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[EMAIL PROTECTED] schrieb:
> PoC:
> phpinfo.php?GLOBALS[test]=alert(document.cookie);

...or just use
phpinfo.php?[]=alert(document.cookie);

Saves some typing. In contrary to the above, this one only works on IE
(tested 6 on XP SP2) & Konqueror (tested 3.4.2), though.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDa0S+n6GkvSd/BgwRAr56AJ0aSs+7n00IdUk6HQRd+Akwe2EJIgCeOIm9
eLVPXP/uSdLOxg5/w1pB2no=
=C/qI
-END 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] for IE researchers, found a link crashing IE

[Moritz Naumann]

Sorry for duplicate posts to AD & Thierry.

Thierry Zoller wrote:
> Does not crash GERMAN XP SP2 6.0.2900.2180.xpsp_sp2_gdr-050301-1519

Huh? But it does crash for me. German IE 6 SP2.

AppName: explorer.exeAppVer: 6.0.2900.2180   ModName: mshtml.dll
ModVer: 6.0.2900.2769Offset: 002174b1





___
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] SquirrelMail Address Add Plugin XSS

[Moritz Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



SA0002

+
+SquirrelMail Address Add Plugin XSS+
+


PUBLISHED ON
  Sep 28, 2005


PUBLISHED AT
  http://moritz-naumann.com/adv/0002/sqmadd/0002.txt


PUBLISHED BY
  Moritz Naumann IT Consulting & Services
  Hamburg/Germany
  http://moritz-naumann.com/

  info AT moritz HYPHON naumann D0T com
  GPG key: http://moritz-naumann.com/keys/0x277F060C.asc


AFFECTED PRODUCT OR SERVICE
  Address Add Plugin for Squirrelmail >= v1.4.0
  by Jimmy Conner
  http://sqmail.org/


AFFECTED VERSION
  Address Add Plugin Versions 1.9 and 2.0
  Possibly versions < 1.9 (untested)


BACKGROUND
  Everybody knows XSS.
  http://en.wikipedia.org/wiki/XSS
  http://www.cgisecurity.net/articles/xss-faq.shtml


ISSUE
  A XSS vulnerability has been detected in the Address Add Plugin for
  Squirrelmail. The problem is caused by insufficient input sanitation.

  Sending a HTML email containing an IMG tag which provides a SRC
  attribute pointing at the vulnerable plugin may allow an attacker to
  retrieve the victims' cookie and session information without the
  victim being aware. The exploit may be triggered when the victim
  clicks on a specially crafted URL contained in the email and hovers
  the address book form field.

  The following partial URL demonstrates the issue:

/squirrelmail_root_dir/plugins/address_add/add.php?first=HOVER%20ME!%22%20onMouseOver=%22alert('foo');

  Please move your mouse pointer over the input field which says so.

  Other variables on this script can be misused in the same way.


WORKAROUND
  Disable Javascript or disable plugin.


SOLUTIONS
  Version 2.1 of the plugin fixes the issue. The update is available on
  boths the developers' website at
http://sqmail.org
  and on the SquirrelMail website at
http://squirrelmail.org/plugin_view.php?id=101


TIMELINE
  Sep 24, 2005: Maintainer informed
  Sep 25, 2005: First maintainer reply
  Sep 25, 2005: Maintainer provides fix
  Sep 29, 2005: Public disclosure


CREDIT
  N/A


LICENSE
  Creative Commons Attribution-ShareAlike License Germany
  http://creativecommons.org/licenses/by-sa/2.0/de/



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDOx0En6GkvSd/BgwRAu4MAKCFk8Qawjt5p5oG1NYJpbvb9S1P5wCfdhDx
KWCJsXrTsmDnB3zv9gN3Nec=
=+0J4
-END 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] Internet Explorer 6 Meta Refresh Parsing Weakness

[Moritz Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Paul,

and thanks for your opinion.

[EMAIL PROTECTED] schrieb:
> Why should Microsoft be accountable for the mistakes of webmasters? 

It is not. But in my opinion, the producer of the most used web browser
worldwide - independant of its name, organization type or history -
should consider to improve the parsing of its web browser so that it
behaves in a way that conforms with standards, or, if there are none
defined (and that's the case here), the way people expect it. And you
cannot neccessarily say that if you have two 'URL=' statements, the
average web developer would expect it to interpret the second one instead of
- - interpreting the whole string and attempt to browse to the URL or
return a syntax error
- - interpreting only the first 'URL=' statement

> Have you even tested any of ther other browsers? 

I tested it on Internet Explorer 6 SP1 on Win 98 SE, IE 6 SP2 on XP SP2,
Firefox 1.0.6, Deerpark Alpha 2, Opera 8.02.1272 and Konqueror 3.3.2
(all of them on on Debian GNU/Linux 3.1).

All the browsers I tested - except IE - interpreted the full string and
returned either a syntax error or tried to load the content stored at
the URI contained in the string.

Unluckily I forgot to include the URL of the test I set up. You can test
your preferred browser at
http://moritz-naumann.com/adv/0001/ie6meta/poc/index.html

> Even if you have, a webmaster should indeed be responsible for
> blindly redirecting a user to a url supplied in input. This isn't an
> Internet Explorer mistake - it is a webmaster mistake, and quite a
> silly one at that.

I totally agree with you.

However, in my example, it was not done totally blindly, some (though
much too little) filtering of user input was done. And several web
applications I know handle it this way. It is a common technique to get
rid of Referer HTTP headers which may contain session IDs when
forwarding users to an external site. I am not saying this is neccessary
nor a good way to do it, I just say it is done this way in several web
applications.

I think this is a minor issue, and I think that Microsoft is only
partially responsible to fix this behaviour, nevertheless, they are. And
I wanted to get the word out on this to warn web application developers
about this unexpected and - in combination with badly coded web
applications - possibly harmful behaviour. So I did.

> Btw, if this message appears in your mailboxes twice, it's because I
> sent it twice (the first time I received a DNS failure message).

No problem. Better two than none. :)

Regards,
Moritz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDBH8yn6GkvSd/BgwRAg3cAJ48BwsniHYs8RYMVB4dEUPLt0IVFACcDLwq
RICOUdZIIbKTrL6Z4tQMOs4=
=7dmX
-END 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] Internet Explorer 6 Meta Refresh Parsing Weakness

[Moritz Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



SA0001

+
+ Internet Explorer 6 Meta Refresh Parsing Weakness +
+


PUBLISHED ON
  Aug 17, 2005


PUBLISHED AT
  http://moritz-naumann.com/adv/0001/ie6meta/0001.txt


PUBLISHED BY
  Moritz Naumann IT Consulting & Services
  Hamburg/Germany
  http://moritz-naumann.com/

  info AT moritz HYPHON naumann D0T com
  GPG key: http://moritz-naumann.com/keys/0x277F060C.asc


AFFECTED PRODUCT OR SERVICE
  Microsoft Internet Explorer
  http://www.microsoft.com/windows/ie/


AFFECTED VERSION
  Version 6 up to release 6.0.2900.2180 (SP2 + all patches)
  Possibly versions < 6.0 (untested)


BACKGROUND
  While the format of
META http-equiv="refresh"
  and
META name="refresh"
  type HTML headers was never exactly defined by they W3C, web
  browsers have been interpreting this instruction since early
  releases. Web application developers got used to the clients'
  behaviour and using this tag to initiate URL redirections
  became common.

  As most web browsers, Internet Explorer 6 interprets this tag,
  too. However, in contrary to other web browsers, IE6's HTML
  parser uses a pretty loose rule set which facilitates
  injection of malicious code into it when browsing web
  applications which insufficiently sanitize user supplied
  input.

  For example, a web application may use the following PHP code
  (redirect.php) to redirect a web browser to a different URL:


';
echo $meta.$goto;
?>



  Assuming this script is hosted in the web root on example.org,
  the following HTML code would be returned on a request to
  http://example.org/redirect.php?goto=localhost :


http://localhost";>



  Obviously, a web application developer must make sure that no
  malicious code can be injected along the 'goto' parameter passed
  via the HTTP GET method. A common method to sanitize user input
  would be to hardcode the protocol part of the URL ('http://')
  contained in 'goto', and to URL-encode any double quotes. This
  would assumely make it difficult to inject any malicious client
  side code.


ISSUE
  Unlickily, and in contrary to other web browsers, Internet
  Explorer 6 allows multiple 'URL=' parts in the 'content'
  attribute and will only interpret the last value given.
  Resulting from this, it is still possible to inject code into a
  web application using the input sanitization described above
  which will be executed when using Internet Explorer 6.

  For example, Internet Explorer 6 will interpret the following
  statement:

  URL parameter:
goto=;URL=javascript:alert('XSS');
  Resulting META tag:
content="0; URL=http://;URL=javascript:alert('XSS');">
  Resulting behaviour:
Displays Javascript alert with text 'XSS'

  Making use of Internet Explorers loose parsing, a code such as
  this value of the 'goto' URL parameter will work, too:

%20%20%20%20%20;UrL=jaVAscRIpt:alert('XSS');

  will work, too. As any of ';', 'UrL', '=', 'jaVAscRIpt' and ':'
  may be legal content passed to the traget web site (think of a
  search term passed to a search engine), sanitizing this is not
  too easy.

  As the expected behaviour would be that a web browser would
  either return an error message for incorrect syntax or would
  attempt to interpret anything after the first 'URL=' part as the
  target URL, Internet Explorer behaves in a pretty uncommon way. A
  fix on the user agent side would be the best solution for this
  issue.


WORKAROUND
  Client: Disable META REFRESH in Security Settings for the Internet
  Zone.
  Server: Perform thorough sanitization on your web applications.


SOLUTIONS
  Microsoft will not provide a patch.


TIMELINE
  Aug 04, 2005: Vendor informed
  Aug 04, 2005: First vendor reply
  Aug 17, 2005: Vendor finishes investigation, declares itself
  unaccountabile


CREDIT
  N/A


LICENSE
  Creative Commons Attribution-ShareAlike License Germany
  http://creativecommons.org/licenses/by-sa/2.0/de/


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDA6WGn6GkvSd/BgwRAnIRAJ9sK7ub/JwoBwNQjtC8j4QxiVl3kwCfUNqi
o+WaJkCQ9LUzdLtNwdBungg=
=lNVL
-END 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] SEC-CONSULT SA-20050629-0

[Moritz Naumann]

> vulnerable versions:
> ---
> 
> javaprxy.dll 5.00.3810
> internet explorer 6.0.2900.2180.xpsp_sp2_gdr.050301-1519
> 
> these are the versions tested, other versions may of course be vulnerable.

This is quite interesting.

javaprxy.dll, aka 'Interface Proxy for Java' is/was part of the Virtual
Machine for Java which M$ may no longer distribute. Its version number
indicates that it was initially made for IE 5.x.

You can download an archived distribution of the Virtual Machine for
Internet Explorer at
http://web.archive.org/web/20020201205255/http://www.microsoft.com/java/vm/dl_vm40.htm

The file itself is here:
http://web.archive.org/web/20020201205255/http://download.microsoft.com/download/vm/Install/3802/W9X2KMe/EN-US/msjavx86.exe

This package, entitled "Microsoft VM build 3802 for Windows 95/98,
Windows Me, Windows NT 4.0 and Windows XP", will, once extracted to the
TEMP folder, reveal the "javaprxy.dll" file, version 5.00.3802.

I don't know much about the contract M$ and Sun have, but it seems to me
like M$ forgot to remove this file off the hard disks of people who have
upgraded their I8N'd versions of Internet Explorer from v5.x to 6.x (or
just v6 SP 0/1 to v6 SP 1/2).

Just my five cents,
Moritz
___
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] Security of phpBB

[Moritz Naumann]

Tom Edwards wrote:
> I am new to this list and to security in general so please excuse my
> question. A friend told me that our forum software phpBB is not very
> secure and told me about this. Where can I get information on that? What
> must I do to make it secure?

Hi Tom,

many people are concerned about known and unknown security issues
related to phpBB. There have been a lot of security issues with it in
the past, have a look at
  http://www.phpbb.com/security/final_reports.php
(or search the FD archives) for some of the latest.

The assumption many people make is that if so many vulnerabilities are
constantly discovered on this software, it can be assumed that there
still are many left and this application must thus be considered
insecure in general.

While I'm not saying this is a correct conclusion (and I'm also not
saying it was not), much less security issues have been discovered on
other wide-spread bulletin board softwares in the same time (which might
also be related to other factors such as their licensing terms and
pricing which make a comparison difficult, though).

Hope this helps a bit,
Moritz
___
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] Re: Exploits Selling / Buying

[Moritz Naumann]

Matteo Giannone wrote:
> I meant: why opensource.arc.nasa.gov should be linked to a lame irc server 
> like
> irc.exploit.cx ?

Thats a good question, and I'm afraid I can't answer it. However, three
possible explanations come to my mind:

1. the server was compromised and added to the bot.. i mean irc network
2. the server was added to the network by someone at nasa.gov on purpose
3. the server is not really linked to the network and someone is just
trying to make you think so

But then, you probably had these thoughts on your mind as well.
___
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] RE: Exploits Selling / Buying

[Moritz Naumann]

Matteo Giannone wrote:
> 
> wtf opensource.arc.nasa.gov means ?

Got a web browser? ;-)
___
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] Analysis: Postbank.nl Phishing Scam

[Moritz Naumann]

Vincent van Scherpenseel schrieb:
> You can read the analysis at: http://www.syn-ack.org/papers/postbank.html .
> 
> I would love to receive any feedback on it, either positive or negative, as 
> long as arguments are supplied.

Quoting from your analysis:
> Unfortunately I wasn't able to determine what 'RCVD_IN_LSORBS' means.
> A Google and a Google Groups session yielded zero results.

I'm not sure whether this is a common SpamAssassin rule (I simply didn't
check). I also do no know what the 'L' in 'LSORBS' stands for. However,
the rest clearly means that the downmost 'Received' email header line
contained an IP address which is listed in the SORBS ("Spam and Open
Relay Blocking System") DNS blacklist <http://www.sorbs.net/>.

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