[FD] SEC Consult SA-20140430-0 :: SQL injection and persistent XSS in the Typo3 3rd party extension si_bibtex

[SEC Consult Vulnerability Lab]

SEC Consult Vulnerability Lab Security Advisory < 20140430-0 >
===
  title: SQL injection and persistent XSS
product: Typo3 3rd party extension si_bibtex
 vulnerable version: si_bibtex 0.2.3
  fixed version: -
 impact: critical
   homepage: http://typo3.org/extensions/repository/view/si_bibtex
  found: 2013-09-24
 by: B. Schildendorfer
 SEC Consult Vulnerability Lab
 https://www.sec-consult.com
===

Vendor description:
---
"TYPO3 is an enterprise-class, Open Source CMS (Content Management System),
used internationally to build and manage websites of all types, from small
sites for non-profits to multilingual enterprise solutions for large
corporations."

Source: http://typo3.org/about/typo3-the-cms/


Software description:
-
"'BibTex Publications' allows you to import Bibtex files from the front-end
and store them in a sysfolder. The front-end plug-in generates list and single
views of entries and provides a simple search tool. It allows also the
automatic import of BibTex files"

Source: http://docs.typo3.org/typo3cms/extensions/si_bibtex/0.2.3/


Business recommendation:

By exploiting this SQL injection vulnerability, an attacker is able to gain
full access to the Typo3 database. He can use this access to crack the stored
backend user passwords which would then lead to a complete system compromise
on success. Depending on the location where the extension is used in the web
application, this may be possible by an unauthenticated attacker.

It is highly recommended to uninstall the si_bibtex extension until the
vulnerabilities are fixed.


Vulnerability overview/description:
---
The vulnerable plugin (si_bibtex) is used to import, export and view
bibliography files used for scientific citation. Flaws in the input validation
of this software lead to SQL injection and persistent cross-site scripting
vulnerabilities.

1) SQL injection

The bibtex "search" and "list" allows a user to display specific bibtex items.
Due to insufficient input validation of a parameter, an attacker can inject
into the SQL query statement. By exploiting this vulnerability, an
attacker gains access to all records stored in the database with the
privileges of the Typo3 database user.

2) Persistent cross-site scripting

The bibtex "import" functionality is prone to persistent cross-site scripting
attacks. The vulnerability can be used to include HTML or JavaScript code to
the affected web page. The imported XSS code will be displayed to every user
who calls the "search" or "list" functionality of this extension.



Proof of concept:
-
No proof of concept code available due to missing solution/workaround.


Vulnerable / tested versions:
-
The following version of the si_bibtex extension has been tested, which was
the most recent version at the time of discovery.
si_bibtex 0.2.3


Vendor contact timeline:

2013-11-05: Contacting vendor through secur...@typo3.org
2013-11-06: Got PGP key from vendor
2013-11-11: Sent the advisory
2014-02-23: Vendor: patch delayed
2014-03-13: Deadline defined for 2014-04-11
2014-04-11: Postponing release of advisory, giving Typo3 team some more time
2014-04-30: Release of security advisory, no patch available


Solution:
-
No patch available.


Workaround:
---
No workaround available.


Advisory URL:
-
https://www.sec-consult.com/en/Vulnerability-Lab/Advisories.htm


~~~
SEC Consult Vulnerability Lab

SEC Consult
Vienna - Bangkok - Frankfurt/Main - Montreal - Singapore - Vilnius

Headquarter:
Mooslackengasse 17, 1190 Vienna, Austria
Phone:   +43 1 8903043 0
Fax: +43 1 8903043 15

Mail: research at sec-consult dot com
Web: https://www.sec-consult.com
Blog: http://blog.sec-consult.com
Twitter: https://twitter.com/sec_consult

EOF B. Schildendorfer / @2014

___
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] Arbitrary code execution by admins in File Gallery 1.7.7 (WordPress plugin)

[Harry Metcalfe]

Hi Illwill,


What circumstance would a WordPress admin not usually have this kind of access 
anyhow?
As Dave said, there are various levels of administrator in WordPress. 
But our perspective on these issues is just that a WordPress 
administrator is not necessarily also a server administrator. Plenty of 
our clients have staff who are administrators but who certainly do not 
have anything equivalent to root server access or permissions. There are 
also plenty of multisite installations of WordPress where the 
administrators of individual blogs have no permissions on other blogs, 
or on the main site.



Why the delay in discovery til reporting?

My fault - a colleague wrote the report, and I didn't notice it at the time.

Harry



On 2014-04-29 05:13, Illwill wrote:
What circumstance would a WordPress admin not usually have this kind 
of access anyhow?


Although it's rarely used, WordPress does have the capability to 
support multiple levels of administrators, in which case one may have 
access to an already installed plugin, but not to install their own.


The same may be true if this plugin were installed in multiuser mode, 
although I haven't kept up on what is permitted in multiuser mode, or 
whether this plugin works in multiuser mode or not.




--
Harry Metcalfe
07790 559 876
@harrym


___
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] Arbitrary code execution by admins in File Gallery 1.7.7 (WordPress plugin)

[Harry Metcalfe]

no, it doesnt matter. the vulnerability is yours and there is 
absolutely no requirement for you to have reported in x amount of 
time. you do not need to justify any amount of time.
Yeah, I know. I generally do intend to get things out promptly though, 
and this was a whoops.


H


On 30/04/2014 13:54, Benji wrote:

Stop

Why the delay in discovery til reporting?

My fault - a colleague wrote the report, and I didn't notice it at the 
time.


no, it doesnt matter. the vulnerability is yours and there is 
absolutely no requirement for you to have reported in x amount of 
time. you do not need to justify any amount of time.


On Wed, Apr 30, 2014 at 1:50 PM, Harry Metcalfe > wrote:


Hi Illwill,


What circumstance would a WordPress admin not usually have
this kind of access anyhow?

As Dave said, there are various levels of administrator in
WordPress. But our perspective on these issues is just that a
WordPress administrator is not necessarily also a server
administrator. Plenty of our clients have staff who are
administrators but who certainly do not have anything equivalent
to root server access or permissions. There are also plenty of
multisite installations of WordPress where the administrators of
individual blogs have no permissions on other blogs, or on the
main site.


Why the delay in discovery til reporting?

My fault - a colleague wrote the report, and I didn't notice it at
the time.

Harry



On 2014-04-29 05:13, Illwill wrote:

What circumstance would a WordPress admin not usually have
this kind of access anyhow?


Although it's rarely used, WordPress does have the capability
to support multiple levels of administrators, in which case
one may have access to an already installed plugin, but not to
install their own.

The same may be true if this plugin were installed in
multiuser mode, although I haven't kept up on what is
permitted in multiuser mode, or whether this plugin works in
multiuser mode or not.


-- 
Harry Metcalfe

07790 559 876
@harrym



___
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/




--
Harry Metcalfe
07790 559 876
@harrym


___
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] LSE Leading Security Experts GmbH - LSE-2014-04-10 - Sitepark IES - Unauthenticated Access

[LSE Leading Security Experts GmbH (Security Advisories)]

=== LSE Leading Security Experts GmbH - Security Advisory 2014-04-10 ===

Sitepark Information Enterprise Server (IES) - Unauthenticated Access
-

Affected Versions
=
Information Enterprise Server (IES) Version 2.9 until 2.9.6

Issue Overview
==
Technical Risk: high
Likelihood of Exploitation: medium
Vendor: Sitepark GmbH
Credits: LSE Leading Security Experts GmbH employees
  Markus Vervier and Sascha Kettler
Advisory URL: https://www.lsexperts.de/advisories/lse-2014-04-10.txt
Advisory Status: Public
CVE-Number: CVE-2014-3006

Issue Description
=
While conducting a penetration test LSE Leading Security Experts GmbH
discovered that the installer of the Information Enterprise Server (IES)
was available to unauthenticated users over HTTP.

When updating from previous versions of IES, an installation form was not
disabled after installation. In this case the servlet "/ies/install" was
exposed to unauthenticated users.

By accessing the servlet at URI "/ies/install/" on an affected IES server,
an unauthenticated attacker was able to set a new password for the manager
account. Additionally sensitive information regarding the IES
installation was displayed.

Temporary Workaround and Fix

LSE Leading Security Experts GmbH advises to prevent access to the
URI "/ies/install/" by configuring web servers or proxy servers accordingly.
For example using the Apache webserver a "Directory" directive would be
needed:


  Order Deny,Allow
  Deny from all
  Satisfy all


A hotfix is available from the vendor via the automatic update functionality
for IES versions 2.9 until 2.9.6.

Impact
==
An attacker is able to learn the license key and sensitive directory names
of the IES. Additionally the password for the account "manager" can be
reset which grants full access rights with the management role.

According to the vendor this issue affects only installations that are
updated from previous versions of IES to versions 2.9 until 2.9.6.

History
===
2014-04-02  Issue discovered
2014-04-03  Vendor informed by customer, Vendor released hotfix and
  updated managed installations
2014-04-16  Permission of customer for advisory
2014-04-16  Direct vendor contact
2014-04-22  Vendor reply
2014-04-27  CVE assigned
2014-04-30  Advisory publicly released


-- 
http://www.lsexperts.de
LSE Leading Security Experts GmbH, Postfach 100121, 64201 Darmstadt
Tel: +49 6151 86086-0, Fax: -299
Unternehmenssitz: Weiterstadt, Amtsgericht Darmstadt: HRB8649
Geschaeftsfuehrer: Oliver Michel, Sven Walther



signature.asc
Description: OpenPGP digital signature

___
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Syhunt Advisory: CGILua session.lua Predictable Session ID Vulnerability

[Felipe Daragon]

Syhunt Advisory: CGILua session.lua Predictable Session ID Vulnerability

Advisory-ID: 201404301
Discovery Date: 03.27.2014
Release Date: 04.30.2014
Affected Applications: CGILua 5.0.x, CGILua 5.1.x., CGILua 5.2 alpha 1 &
CGILua 5.2 alpha 2
Class: Predictable Session ID
Status: Unpatched/Vendor informed
Vendor: CGILua project
Vendor URL: https://github.com/keplerproject/cgilua
Advisory URL: http://www.syhunt.com/advisories/?id=cgilua-weaksessionid

The Common Vulnerabilities and Exposures (CVE) project has
assigned the following CVE to this vulnerability: CVE-2014-2875



Overview:
CGILua is an open source tool for creating dynamic Web pages and
manipulating input data from Web forms. It allows the separation
of logic and data handling from the generation of pages, making
it easy to develop web applications with the Lua programming
language.

Over the years the tool has been adopted by several
organizations worldwide, especially in Brazil where it has been
adopted by some high profile organizations.

Description:
A vulnerability in the session library that ships with CGILua
since version 5.0 beta may allow remote attackers to easily and
quickly guess valid session IDs generated by a Lua web
application and perform session hijacking - for example, gain
access to user sessions of various other logged-in users.



Details:

CGILua 5.2 alpha, released in 2013, generates weak/insufficiently
random session IDs (usually 9-digit long, sometimes shorter),
based on OS time.
Since an attacker can view the source on GitHub, he knows the
generation mechanism. In our attack simulations, we were able to
guess valid session IDs extremely quickly through brute-force
attacks.

CGILua 5.1.x (2007-2010) contains a bug and always generates the
same ID. Since this bug is easily noticeable and makes the
library unusable, we doubt that the version of the session
library included with this release is in production anywhere.

CGILua 5.0.x, released in 2004, generates sequential (non-random)
8-digit long session IDs, making guessing even more easy.



Vulnerability Status:

The project maintainers were initially contacted at the end of
March, 2014.

The maintainer Tomás Guisasola believes that the session IDs
generated by CGILua 5.0 and 5.2 are not insecure in its current
form and that enhancing the randomness of the SID would
not make it more secure.

The maintainer confirmed that the session ID generation in
CGILua 5.1 is buggy - always generates the same ID, thus is
unusable.

Because there is no patch for this vulnerability (the author
does not consider it a security risk and is unresponsive) we
recommend that users simply do not use CGILua's session.lua
library until hopefully there is a patch issued to remedy this.

According to the CGILua changelog, the session API was
introduced in version 5.0 beta, therefore older versions, like
5.0 alpha, 4.x and before don't include the session.lua
library and should not be marked as vulnerable to this
particular issue.

In case you wish to manually patch the session library, consider
using the luuid library, which generates 128-bit random IDs, as
part of the fix, or any other Lua library that can generate
unique IDs based on high-quality randomness. After patching
(either with an official patch or your own patch), it is
necessary to remove/invalidate all sessions generated by the
old, unpatched code.



Disclosure Timeline:

* March 27, 2014 - Emailed the maintainers about the need of
hardening CGILua.
* April 2, 2014 - No reply. Emailed the maintainer once again.
* April 2, 2014 - First maintainer reply (see Vulnerability Status
above for details).
* April 4, 2014 - Syhunt sends information about recommended
SID length and entropy
https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Session_ID_Length
* April 13, 2014 - Syhunt sends details about its own
demonstration tool that is able to guess CGILua session IDs, along
with additional comments in a separate email.
* April 30, 2014 - No response received to emails sent on April 4 & 13.
* April 30, 2014 - Public disclosure.



Credit:
Felipe Daragon
Syhunt Security Research Team, www.syhunt.com

We thank James Mouat, which performed some additional tests,
helping with the diagnosis of this issue.



Copyright © 2014 Syhunt Security

Disclaimer:
The information in this advisory is provided "as is" without
warranty of any kind. Details provided are strictly for
educational and defensive purposes.

Syhunt is not liable for any damages caused by direct or
indirect use of the information provided by this advisory.

___
Sent through the Full Disclosure mailing list
http://n

Re: [FD] lxml (python lib) vulnerability

[Źmicier Januszkiewicz]

FYI -- this seems to be patched with 3.3.5. [0]

Cheers,
Z.

References:
[0] http://lxml.de/3.3/changes-3.3.5.html


2014-04-15 20:30 GMT+02:00 Максим Кочкин :
> Hi, all
>
> I've accidentally found vulnerability in clean_html function of lxml python
> library. User can break schema of url with nonprinted chars (\x01-\x08).
> Seems like all versions including the latest 3.3.4 are vulnerable. Here is
> PoC.
>
>
> from lxml.html.clean import clean_html
>
> html = '''\
> 
> 
> 
> aaa
> bbb
> bbb
> bbb
> bbb
> bbb
> bbb
> bbb
> bbb
> bbb
> 
> '''
>
> print clean_html(html)
>
>
> Output:
>
> 
> 
> aaa
> 
> bbb
> bbb
> bbb
> bbb
> bbb
> bbb
> bbb
> bbb
> bbb
> 
> 
>
>
> I've emailed lxml-guys. Hope they'll fix it soon.
>
> 
> ksimka (@m_ksimka)
>
> ___
> Sent through the Full Disclosure mailing list
> http://nmap.org/mailman/listinfo/fulldisclosure
> Web Archives & RSS: http://seclists.org/fulldisclosure/

___
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Beginners error: iTunes for Windows runs rogue program C:\Program.exe when opening associated files

[Stefan Kanthak]

Hi @ll,

the current version of iTunes for Windows (and of course older versions
too) associates the following vulnerable command lines with some of the
supported file types/extensions:

daap=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
itls=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
itms=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
itmss=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
itpc=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
itsradio=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
iTunes=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
iTunes.AssocProtocol.daap=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
iTunes.AssocProtocol.itls=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
iTunes.AssocProtocol.itms=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
iTunes.AssocProtocol.itmss=C:\Program Files (x86)\iTunes\iTunes.exe /url"%1"
iTunes.AssocProtocol.itpc=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
iTunes.AssocProtocol.pcast=C:\Program Files (x86)\iTunes\iTunes.exe /url"%1"
itunesradio=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
pcast=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"


The command line registered under

[HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Media\iTunes\shell\open\command]
@="C:\Program Files\iTunes\iTunes.exe"

shows the same beginners error too: an unquoted pathname allows the
execution of the rogue programs "C:\Program.exe" or "C:\Program Files.exe"
instead of the intended executable.


>From 
or :

| Note: If any element of the command string contains or might contain
~~
| spaces, it must be enclosed in quotation marks. Otherwise, if the
  ~~~
| element contains a space, it will not parse correctly. For instance,
| "My Program.exe" starts the application properly. If you use
| My Program.exe without quotation marks, then the system attempts to
| launch My with Program.exe as its first command line argument. You
| should always use quotation marks with arguments such as "%1" that are
| expanded to strings by the Shell, because you cannot be certain that
| the string will not contain a space.


"Long" filenames containing spaces exist for about 20 years in Windows.
It's REALLY time that every developer and every QA engineer knows how
to handle them properly.


If you detect such silly bugs: report them and get them fixed.
If the vendor does not fix them: trash the trash!


JFTR: this bugs only exists since Microsoft "masks" it.
  See  for this
  well-known idiosyncrasy:

| For example, consider the string "c:\program files\sub dir\program name".
| This string can be interpreted in a number of ways.
| The system tries to interpret the possibilities in the following order:
| c:\program.exe files\sub dir\program name
| c:\program files\sub.exe dir\program name
| c:\program files\sub dir\program.exe name
| c:\program files\sub dir\program name.exe

  Without this kludge this beginners error would get caught upon
  the very first use of any of these command lines.


Since every user account created during Windows setup has administrative
rights every user owning such an account can create the rogue program,
resulting in a privilege escalation.

JFTR: no, the "user account control" is not a security boundary!


regards
Stefan Kanthak


PS: for static detection of these silly beginners errors download and
run 

To catch all instances of this beginners error download
,
 and
, then read
and run SENTINEL.CMD

___
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] Beginners error: iTunes for Windows runs rogue program C:\Program.exe when opening associated files

[Alton Blom]

Hi Stefan,

SANS had a good post on this a few years ago (
https://isc.sans.edu/diary/Help+eliminate+unquoted+path+vulnerabilities/14464),
which led to large number of services on windows machines with unquoted
paths being discovered and fixed.  At that time I discovered that Windows
Defender on Windows 7 had a problem like yours and reported it to
Microsoft.  It took quite a while to get them to recognise it as a
vulnerability, but it eventually led to
https://technet.microsoft.com/en-us/library/security/ms13-058.aspx being
released and Windows Defender being updated.

At the same time I asked Tenable to create a plugin for Nessus that detects
vulnerable services which they quickly released (plugin 63155).  This in
turn led to a second round of vulnerable services being detected and
patched by vendors.

Also it's worth noting that OSVDB track these types of Vulns as
"Authentication Required, Not a Vulnerability"

Alton(ius)
altonblom.com


On Thu, May 1, 2014 at 5:02 AM, Stefan Kanthak wrote:

> Hi @ll,
>
> the current version of iTunes for Windows (and of course older versions
> too) associates the following vulnerable command lines with some of the
> supported file types/extensions:
>
> daap=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
> itls=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
> itms=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
> itmss=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
> itpc=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
> itsradio=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
> iTunes=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
> iTunes.AssocProtocol.daap=C:\Program Files (x86)\iTunes\iTunes.exe /url
> "%1"
> iTunes.AssocProtocol.itls=C:\Program Files (x86)\iTunes\iTunes.exe /url
> "%1"
> iTunes.AssocProtocol.itms=C:\Program Files (x86)\iTunes\iTunes.exe /url
> "%1"
> iTunes.AssocProtocol.itmss=C:\Program Files (x86)\iTunes\iTunes.exe
> /url"%1"
> iTunes.AssocProtocol.itpc=C:\Program Files (x86)\iTunes\iTunes.exe /url
> "%1"
> iTunes.AssocProtocol.pcast=C:\Program Files (x86)\iTunes\iTunes.exe
> /url"%1"
> itunesradio=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
> pcast=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
>
>
> The command line registered under
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Media\iTunes\shell\open\command]
> @="C:\Program Files\iTunes\iTunes.exe"
>
> shows the same beginners error too: an unquoted pathname allows the
> execution of the rogue programs "C:\Program.exe" or "C:\Program Files.exe"
> instead of the intended executable.
>
>
> From 
> or :
>
> | Note: If any element of the command string contains or might contain
> ~~
> | spaces, it must be enclosed in quotation marks. Otherwise, if the
>   ~~~
> | element contains a space, it will not parse correctly. For instance,
> | "My Program.exe" starts the application properly. If you use
> | My Program.exe without quotation marks, then the system attempts to
> | launch My with Program.exe as its first command line argument. You
> | should always use quotation marks with arguments such as "%1" that are
> | expanded to strings by the Shell, because you cannot be certain that
> | the string will not contain a space.
>
>
> "Long" filenames containing spaces exist for about 20 years in Windows.
> It's REALLY time that every developer and every QA engineer knows how
> to handle them properly.
>
>
> If you detect such silly bugs: report them and get them fixed.
> If the vendor does not fix them: trash the trash!
>
>
> JFTR: this bugs only exists since Microsoft "masks" it.
>   See  for this
>   well-known idiosyncrasy:
>
> | For example, consider the string "c:\program files\sub dir\program name".
> | This string can be interpreted in a number of ways.
> | The system tries to interpret the possibilities in the following order:
> | c:\program.exe files\sub dir\program name
> | c:\program files\sub.exe dir\program name
> | c:\program files\sub dir\program.exe name
> | c:\program files\sub dir\program name.exe
>
>   Without this kludge this beginners error would get caught upon
>   the very first use of any of these command lines.
>
>
> Since every user account created during Windows setup has administrative
> rights every user owning such an account can create the rogue program,
> resulting in a privilege escalation.
>
> JFTR: no, the "user account control" is not a security boundary!
>
>
> regards
> Stefan Kanthak
>
>
> PS: for static detection of these silly beginners errors download and
> run 
>
> To catch all instances of this beginners error download
> ,
> 

Re: [FD] Beginners error: iTunes for Windows runs rogue program C:\Program.exe when opening associated files

[Gynvael Coldwind]

Well spotted.

That said, don't you have to be an admin to be able to create files in
these directories anyway?

So this is only exploitable on FAT, or by admin, or if the ACLs are
set incorrectly right?
-- 
Gynvael Coldwind

___
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] Beginners error: iTunes for Windows runs rogue program C:\Program.exe when opening associated files

[Alton Blom]

Hi Mike,
It's probalby better seen as a way of keeping persistence on a machine than
a full-blown exploit.

Alton(ius)
altonblom.com
@altonius_au


On Thu, May 1, 2014 at 8:05 AM, Mike Cramer  wrote:

> I would like to know how this is a vulnerability.
>
> In order to write to the root of C:\, you need elevated privileges in
> Windows. Once someone gains elevated access, what does creating
> "C:\program.exe" offer them that they couldn't otherwise obtain?
>
> I have never actually seen malware take advantage of this, often times
> leveraging Kernel hooks and driver loading.
>
> It is unintended behavior, yes; but I'd consider it hardly a vulnerability.
>
> -Mike
>
> -Original Message-
> From: Fulldisclosure [mailto:fulldisclosure-boun...@seclists.org] On
> Behalf
> Of Alton Blom
> Sent: Wednesday, April 30, 2014 17:51
> To: Stefan Kanthak
> Cc: fulldisclosure@seclists.org
> Subject: Re: [FD] Beginners error: iTunes for Windows runs rogue program
> C:\Program.exe when opening associated files
>
> Hi Stefan,
>
> SANS had a good post on this a few years ago (
>
> https://isc.sans.edu/diary/Help+eliminate+unquoted+path+vulnerabilities/1446
> 4),
> which led to large number of services on windows machines with unquoted
> paths being discovered and fixed.  At that time I discovered that Windows
> Defender on Windows 7 had a problem like yours and reported it to
> Microsoft.
> It took quite a while to get them to recognise it as a vulnerability, but
> it
> eventually led to
> https://technet.microsoft.com/en-us/library/security/ms13-058.aspx being
> released and Windows Defender being updated.
>
> At the same time I asked Tenable to create a plugin for Nessus that detects
> vulnerable services which they quickly released (plugin 63155).  This in
> turn led to a second round of vulnerable services being detected and
> patched
> by vendors.
>
> Also it's worth noting that OSVDB track these types of Vulns as
> "Authentication Required, Not a Vulnerability"
>
> Alton(ius)
> altonblom.com
>
>
> On Thu, May 1, 2014 at 5:02 AM, Stefan Kanthak
> wrote:
>
> > Hi @ll,
> >
> > the current version of iTunes for Windows (and of course older
> > versions
> > too) associates the following vulnerable command lines with some of
> > the supported file types/extensions:
> >
> > daap=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
> > itls=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
> > itms=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
> > itmss=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
> > itpc=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
> > itsradio=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
> > iTunes=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
> > iTunes.AssocProtocol.daap=C:\Program Files (x86)\iTunes\iTunes.exe
> > /url "%1"
> > iTunes.AssocProtocol.itls=C:\Program Files (x86)\iTunes\iTunes.exe
> > /url "%1"
> > iTunes.AssocProtocol.itms=C:\Program Files (x86)\iTunes\iTunes.exe
> > /url "%1"
> > iTunes.AssocProtocol.itmss=C:\Program Files (x86)\iTunes\iTunes.exe
> > /url"%1"
> > iTunes.AssocProtocol.itpc=C:\Program Files (x86)\iTunes\iTunes.exe
> > /url "%1"
> > iTunes.AssocProtocol.pcast=C:\Program Files (x86)\iTunes\iTunes.exe
> > /url"%1"
> > itunesradio=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
> > pcast=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
> >
> >
> > The command line registered under
> >
> > [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Media\iTunes\shell\open\command]
> > @="C:\Program Files\iTunes\iTunes.exe"
> >
> > shows the same beginners error too: an unquoted pathname allows the
> > execution of the rogue programs "C:\Program.exe" or "C:\Program
> Files.exe"
> > instead of the intended executable.
> >
> >
> > From 
> > or :
> >
> > | Note: If any element of the command string contains or might contain
> > ~~
> > | spaces, it must be enclosed in quotation marks. Otherwise, if the
> >   ~~~
> > | element contains a space, it will not parse correctly. For instance,
> > | "My Program.exe" starts the application properly. If you use My
> > | Program.exe without quotation marks, then the system attempts to
> > | launch My with Program.exe as its first command line argument. You
> > | should always use quotation marks with arguments such as "%1" that
> > | are expanded to strings by the Shell, because you cannot be certain
> > | that the string will not contain a space.
> >
> >
> > "Long" filenames containing spaces exist for about 20 years in Windows.
> > It's REALLY time that every developer and every QA engineer knows how
> > to handle them properly.
> >
> >
> > If you detect such silly bugs: report them and get them fixed.
> > If the vendor does not fix them: trash the trash!
> >
> >
> > JFTR: this bugs only exists since Microsoft "masks" it.

Re: [FD] Beginners error: iTunes for Windows runs rogue program C:\Program.exe when opening associated files

[Mike Cramer]

I would like to know how this is a vulnerability.

In order to write to the root of C:\, you need elevated privileges in
Windows. Once someone gains elevated access, what does creating
"C:\program.exe" offer them that they couldn't otherwise obtain?

I have never actually seen malware take advantage of this, often times
leveraging Kernel hooks and driver loading.

It is unintended behavior, yes; but I'd consider it hardly a vulnerability.

-Mike

-Original Message-
From: Fulldisclosure [mailto:fulldisclosure-boun...@seclists.org] On Behalf
Of Alton Blom
Sent: Wednesday, April 30, 2014 17:51
To: Stefan Kanthak
Cc: fulldisclosure@seclists.org
Subject: Re: [FD] Beginners error: iTunes for Windows runs rogue program
C:\Program.exe when opening associated files

Hi Stefan,

SANS had a good post on this a few years ago (
https://isc.sans.edu/diary/Help+eliminate+unquoted+path+vulnerabilities/1446
4),
which led to large number of services on windows machines with unquoted
paths being discovered and fixed.  At that time I discovered that Windows
Defender on Windows 7 had a problem like yours and reported it to Microsoft.
It took quite a while to get them to recognise it as a vulnerability, but it
eventually led to
https://technet.microsoft.com/en-us/library/security/ms13-058.aspx being
released and Windows Defender being updated.

At the same time I asked Tenable to create a plugin for Nessus that detects
vulnerable services which they quickly released (plugin 63155).  This in
turn led to a second round of vulnerable services being detected and patched
by vendors.

Also it's worth noting that OSVDB track these types of Vulns as
"Authentication Required, Not a Vulnerability"

Alton(ius)
altonblom.com


On Thu, May 1, 2014 at 5:02 AM, Stefan Kanthak
wrote:

> Hi @ll,
>
> the current version of iTunes for Windows (and of course older 
> versions
> too) associates the following vulnerable command lines with some of 
> the supported file types/extensions:
>
> daap=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
> itls=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
> itms=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
> itmss=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
> itpc=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
> itsradio=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
> iTunes=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
> iTunes.AssocProtocol.daap=C:\Program Files (x86)\iTunes\iTunes.exe 
> /url "%1"
> iTunes.AssocProtocol.itls=C:\Program Files (x86)\iTunes\iTunes.exe 
> /url "%1"
> iTunes.AssocProtocol.itms=C:\Program Files (x86)\iTunes\iTunes.exe 
> /url "%1"
> iTunes.AssocProtocol.itmss=C:\Program Files (x86)\iTunes\iTunes.exe 
> /url"%1"
> iTunes.AssocProtocol.itpc=C:\Program Files (x86)\iTunes\iTunes.exe 
> /url "%1"
> iTunes.AssocProtocol.pcast=C:\Program Files (x86)\iTunes\iTunes.exe 
> /url"%1"
> itunesradio=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
> pcast=C:\Program Files (x86)\iTunes\iTunes.exe /url "%1"
>
>
> The command line registered under
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Media\iTunes\shell\open\command]
> @="C:\Program Files\iTunes\iTunes.exe"
>
> shows the same beginners error too: an unquoted pathname allows the 
> execution of the rogue programs "C:\Program.exe" or "C:\Program Files.exe"
> instead of the intended executable.
>
>
> From 
> or :
>
> | Note: If any element of the command string contains or might contain
> ~~
> | spaces, it must be enclosed in quotation marks. Otherwise, if the
>   ~~~
> | element contains a space, it will not parse correctly. For instance, 
> | "My Program.exe" starts the application properly. If you use My 
> | Program.exe without quotation marks, then the system attempts to 
> | launch My with Program.exe as its first command line argument. You 
> | should always use quotation marks with arguments such as "%1" that 
> | are expanded to strings by the Shell, because you cannot be certain 
> | that the string will not contain a space.
>
>
> "Long" filenames containing spaces exist for about 20 years in Windows.
> It's REALLY time that every developer and every QA engineer knows how 
> to handle them properly.
>
>
> If you detect such silly bugs: report them and get them fixed.
> If the vendor does not fix them: trash the trash!
>
>
> JFTR: this bugs only exists since Microsoft "masks" it.
>   See  for this
>   well-known idiosyncrasy:
>
> | For example, consider the string "c:\program files\sub dir\program
name".
> | This string can be interpreted in a number of ways.
> | The system tries to interpret the possibilities in the following order:
> | c:\program.exe files\sub dir\program name c:\program files\sub.exe 
> | dir\program name c:\prog