Message-ID: <CALNSPO5w09LyjhBnaAiRUmDYmirqqXdWaU=wrcvWWbEsy1Mb7g@mail.gmail.com>
Date: Thu, 1 May 2014 08:17:56 +1000
From: Alton Blom <altonius@...il.com>
To: Mike Cramer <mike.cramer@...look.com>
Cc: fulldisclosure@...lists.org, Stefan Kanthak <stefan.kanthak@...go.de>
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@...look.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@...lists.org] On
> Behalf
> Of Alton Blom
> Sent: Wednesday, April 30, 2014 17:51
> To: Stefan Kanthak
> Cc: fulldisclosure@...lists.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@...go.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/

Powered by blists - more mailing lists