Message-ID: <53617DCC.4090302@gmail.com>
Date: Wed, 30 Apr 2014 17:48:44 -0500
From: Brandon Perry <bperry.volatile@...il.com>
To: Alton Blom <altonius@...il.com>, 
 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

Stupid people also share their C: drive on networks.

On 04/30/2014 05:17 PM, Alton Blom wrote:
> 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/


_______________________________________________
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