Full Disclosure mailing list archives

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


From: Alton Blom <altonius () gmail com>
Date: Thu, 1 May 2014 09:01:58 +1000

That's sad to hear that Security people aren't performing some type of risk
assessment / analysis on the vuln.

In my experience we identified a number of programs that were repeat
offenders and worked with the ops team to talk to the vendor.  If that
didn't succeed the application packaging team worked to add an extra step
to the app deployment and SOE to include a registry update that had the
quotation marks around the path, this fixed all new deployments.  In
addition to this they also deployed updated registry keys to those machines
that already had the app installed.

I understand your pain though.

Alton(ius)


On Thu, May 1, 2014 at 8:37 AM, Mike Cramer <mike.cramer () outlook com> wrote:

I bring this up because this has been an extreme sore point on our network
and our security group utilizing the Nessus plugin. Attempting to explain
to them that UAC and the elevated privilege requirement makes this a
non-issue is falling on deaf ears to those that blindly follow what the
scanner states. There’s little to no wiggle room as there’s very little
information on this that’s out there other than “OMG THE SKY IS FALLING”.



Even Tenable’s own blog post,
http://www.tenable.com/sc-report-templates/microsoft-windows-unquoted-service-path-enumeration,
shows them “exploiting this vulnerability” by using an elevated command
prompt using an elevated privilege token.



There are software vendors that will never ‘fix’ their software. A great
example being the IDT Audio driver released by Dell for their Latitude 6520
series of laptops creates a service called “AESTFilters” which installs an
unquoted service path in C:\Program Files.



Juniper Network Connect VPN Client 7.1.7 also creates a service with an
unquoted service path string.



The only ‘resolution’ is an active mitigation which continuously evaluates
all Windows systems on a network to search remotely for unquoted service
paths.



There exist a couple of scripts that will troll the registry services key
for these issues, but Windows uses the same key to load kernel drivers,
differentiating each service via a “Type” parameter. (
http://support.microsoft.com/kb/103000) I’m not sure how much faith you
place in an active network application remotely modifying an extremely
critical registry sub key on a thousand node network and hope it doesn’t
accidentally place a quote in the wrong location and prevents Windows from
starting for your entire organization. It seems the risk there is
significantly greater than any benefit provided by resolving this issue.



Many operational security groups are placing the burden of resolution on
IT operations departments (My organization is not the only one to go
through this) rather than application vendors.







*From:* Alton Blom [mailto:altonius () gmail com]
*Sent:* Wednesday, April 30, 2014 18:18
*To:* Mike Cramer
*Cc:* Stefan Kanthak; fulldisclosure () seclists org

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



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 <mike.cramer () outlook com>
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-bounces () 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
<stefan.kanthak () nexgo de>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 <http://msdn.microsoft.com/library/cc144175.aspx>
or <http://msdn.microsoft.com/library/cc144101.aspx>:

| 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 <http://msdn.microsoft.com/library/ms682425.aspx> 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 <http://home.arcor.de/skanthak/download/SLOPPY.CMD>

    To catch all instances of this beginners error download
    <http://home.arcor.de/skanthak/download/SENTINEL.CMD>,
    <http://home.arcor.de/skanthak/download/SENTINEL.DLL> and
    <http://home.arcor.de/skanthak/download/SENTINEL.EXE>, 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/


_______________________________________________
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/

Current thread: