You are on page 1of 19

Securely Registering Applications


Neelay S Shah
Senior Software Security Consultant
Foundstone Professional Services
Securely Registering Applications

Table of Contents

Securely Registering Applications 1 

Table of Contents 2 
Abstract 3 
Introduction 4 
Discussion 5 
Foundstone DIRE (Detecting Insecurely Registered Executables) 13 
Acknowledgements 19 
About Foundstone Professional Services 19 

2 | 1.877.91.FOUND
Securely Registering Applications


One of the more powerful and popular features that modern day operating systems offers its end users and
administrators is the ability to register applications that can be automatically initiated. These applications will
typically execute in the background with minimal or no interaction with the end user. This functionality
enhances the end user’s experience and furthermore enables system administrators to exert complete control
over the machines in their environment. What application developers need to be aware of is that attackers
can target these same systems by exploiting ‘insecurely registered applications’ on target systems.

Insecurely registered applications are identified by examining the registered path of the application. If the
registered path contains one or more <space> characters and the path is not enclosed in double quotes then
the application is potentially insecurely registered. This ultimately allows an attacker to potentially invoke
malicious programs at higher privileges than normal, thus creating a privilege escalation vulnerability. An
example of this could be an attacker installing a keyboard logger on a locked down system where ordinary
users do not have the privileges to install any programs let alone malicious programs.

Foundstone has released a free tool called Foundstone DIRE (Detecting Insecurely Registered Executables)
which allows users/system administrators to identify ‘insecurely registered applications’ on their systems.

In this white paper we discuss the insecure registration vulnerability: identifying vulnerable applications, the
impact of the vulnerability and what it takes to successfully exploit the vulnerability. We also cover existing
mitigating factors, the primary cause, and the remediation of this vulnerability.

This white paper is intended for all software developers, architects, testers, deployment engineers and
system administrators.

3 | 1.877.91.FOUND
Securely Registering Applications


The need for an application to start automatically when the system starts up or when the user logs in is
frequently necessary, for instance in the case of applications such as web servers, database servers or anti-
virus software. There are multiple ways which enable application developers to register an application with
Windows so that Windows launches it automatically without requiring any further interaction with the user.
Some examples include:

• Windows Services: Windows services are applications that Windows launches when the system
starts up. Typically, services do not expose any user interface and do not interfere with the logged on
user. Examples of services are: database server such as Microsoft SQL Server

• Logon Applications: Windows logon applications are applications that are started when the user
logs into the system. Regular users can configure logon applications for themselves whereas the
administrative users can configure logon applications for all users. Thus regular users can influence
the logon experience for him/her whereas the administrator can influence the logon experience for all
users. Examples of logon applications are: Instant messaging applications like Yahoo messenger,
application updaters like SunJavaUpdateSched

As simple as it sounds, registering applications with Microsoft Windows can be complex. The problem of
insecurely registering applications with Windows may cause the operating system to launch a malicious
application instead of the intended application. This malicious application will be launched with privileges
intended for the vulnerable application thus making it a privilege escalation vulnerability.

4 | 1.877.91.FOUND
Securely Registering Applications


The vulnerability potentially impacts all registered applications whose installation path contains a <space>
character. For e.g. “C:\Program Files\Foundstone Free Tools\Hacme Travel
1.0\HacmeTravelServer.exe”. This is because the Win32 process APIs use the <space> character to
separate the name of the application being executed from the arguments that will then be passed to this
application. If the application is insecurely registered, i.e. the installation path contains one or more <space>
characters and the installation path is not enclosed in double quotes while registering with Windows, then
Windows will look for “C:\Program.exe” first. If found, Windows launches”C:\Program.exe” and
passes “Files\Foundstone Free Tools\Hacme Travel 1.0\HacmeTravelServer.exe” as
arguments. If Windows does not find “C:\Program.exe” it then looks for “C:\Program
Files\Foundstone.exe” and if found launches it and passes “Free Tools\Hacme Travel
1.0\HacmeTravelServer.exe” as arguments. This process continues and the intended application
“C:\Program Files\Foundstone Free Tools\Hacme Travel 1.0\HacmeTravelServer.exe” is
launched only if none of the following are found on the system:

• C:\Program.exe

• C:\Program Files\Foundstone.exe

• C:\Program Files\Foundstone Free.exe

• C:\Program Files\Foundstone Free Tools\Hacme.exe

• C:\Program Files\Foundstone Free Tools\Hacme Travel.exe

Since in most cases the system drive is “C:\” and the installation directory for most programs is
“C:\Program Files\” the rest of this document assumes this is the path - however the concept is
applicable irrespective of the system drive or application path.

Identifying Vulnerable Applications

There are a couple of ways to identify vulnerable applications:

1. Find the registered applications on the system and examine the installation paths to check if it
contains the <space> character and if the installation path is enclosed in double quotes.

2. Run Foundstone DIRE (Detect Insecurely Registered Executables) tool and it will list out the
vulnerable applications and services installed on the system. The tool essentially automates the first
approach to a large extent.

5 | 1.877.91.FOUND
Securely Registering Applications

Impact of the Vulnerability

The vulnerability allows an attacker to execute a malicious application with potentially higher privileges than
they would otherwise have been allowed. What these privileges are depend upon the configuration of the
vulnerable application.

A majority of services are registered to run under the context of the “LocalSystem” account, so if the
vulnerable application is a Windows service configured to run under the context of “LocalSystem” account,
then the malicious application will execute under the context of “LocalSystem” account, which is the most
privileged account on a Windows system.

If the vulnerable application is a logon application, the malicious application will run under the context of the
logged on user and will result in a privilege escalation when a more privileged user such as a power user or
an administrator logs in and the vulnerable application is a part of the power user/administrator’s log on
profile. For example, an unprivileged user could copy a malicious program as C:\Program.exe (that
performs certain privileged operations) and could then invite the system administrator to logon to the system
under the pretext of troubleshooting the system. Once the administrator logs on, the malicious
C:\Program.exe runs in the context of the logged on administrator and hence the privileged operations
are successfully executed, and at that point the unprivileged user has been successful in realizing his
malicious intent.

A malicious unprivileged user could also exploit the vulnerability to his advantage by successfully disabling
vulnerable critical applications. For instance the unprivileged user could copy a dummy C:\Program.exe
onto the system and now when the system reboots Windows launches the dummy C:\Program.exe
instead of the intended critical application viz. C:\Program Files\anti-virus.exe.

Exploiting the Vulnerability

To successfully exploit a vulnerable service an attacker:

• Must copy the malicious binary to the path which is part of the path of vulnerable service as
illustrated above.

• Launch the vulnerable service by either

o Starting the service or

o Restarting the underlying computer or

o Waiting until somebody manually starts the service or restarts the system

However, successfully exploiting a vulnerable service can be tricky. When Windows starts a service, the
Service Control Manager (SCM) expects the service application to call the

6 | 1.877.91.FOUND
Securely Registering Applications

“StartServiceCtrlDispatcher” 1 function within 30 seconds. If it does not, then the SCM kills the
service application. What this implies is that to successfully exploit the vulnerability, should

• The malicious binary must be able to behave and act as a regular Windows service or

• The malicious binary must spawn a new malicious child process (and this spawned malicious child
process can reside anywhere on the system, since the path is controlled by the attacker’s malicious
binary so it could as well be the attacker’s home directory or any other path on the file system where
the attacker has privileges). This spawned malicious child process then continues to perform the
malicious activity even though the original binary process is killed after 30 seconds.

To successfully exploit a vulnerable logon application an attacker, you must:

• Copy the malicious binary to a path which is part of the path of vulnerable application as illustrated
above and then,

• Wait for a higher privileged user to log in to the system

Existing Mitigation(s)
One of the main hurdles the attacker has to overcome to successfully exploit this vulnerability is to copy the
malicious application to the victim’s file system with a path that matches the vulnerable application as
described above. To do this successfully, the attacker needs to have privileges so that the file system allows
him / her write access to the appropriate path.

In the case of Windows XP, the default file system applications allow only the administrator to create files in
C:\. These default file system permissions combined with the typical installation directory for applications
make it very hard to exploit the vulnerability to elevate privilege on systems running Windows XP. However
on Windows XP, if a vulnerable service is configured to run under the context of “Domain account” then it is
possible for a local administrator to elevate his privileges to a domain user and gain network privileges, which
the “LocalSystem” account typically does not have.

In the case of Windows 2000, the default file system permissions do allow regular users to create files in
C:\. So, from an attacker’s point of view, if he / she had access to even a low privileged account on the
system, then he / she could copy a malicious “Program.exe” to C:\ and then wait for the vulnerable
application to be launched to gain higher privileges and thus compromise the underlying system.

For a overview on service programs and service entry points refer to MSDN documentation at

7 | 1.877.91.FOUND
Securely Registering Applications

The other mitigation that Windows offers is in the form of a warning message that is displayed (as shown in
Figure 1) when the user logs in:

Figure 1: Operating system warning dialog

However, services are started when the system starts up, so this warning message does not cover services
and if there was a vulnerable service then the malicious “C:\Program.exe” is launched without the
knowledge of the user.

As far as the vulnerable logon applications are concerned, Windows does not launch “C:\Program.exe”
unless the user selects to ‘Ignore’ this warning. If the user selects the “Rename” option the malicious
“C:\Program.exe” is not launched. It should be noted that this check is per user and hence one limited
rights user cannot disable the warning message for another user on the system.

The warning dialog message reads “If you do not rename “C:\Program.exe” certain other applications
may not function correctly” and does not mention the potential security risk involved if the user selects the
“Ignore” option.

The warning dialog seems to be hard-coded to look for “C:\Program.*”. So even if you don’t have
“C:\Program.exe” but instead have “C:\Program.dat”, the user is displayed the warning dialog at
logon. Further it is also important to note that if the system is setup so that all applications are installed to
the “C:\Software Installations\” directory, no warning is displayed to indicate the presence of

Cause of the Vulnerability

From a developer’s perspective then, what implementation flaw can result in their application to be potentially
vulnerable to this flaw? As explained previously, Windows uses the <space> character to separate the
application path and the arguments passed to the application and thus if the application is insecurely
registered, Windows can launch a malicious application instead of the intended application.

Services registered with Windows are stored in registry at

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services key and each registered service has a

8 | 1.877.91.FOUND
Securely Registering Applications

separate sub-key under this registry key path and has some predefined values. For e.g. the figure below
shows the registry structure for the insecurely registered FoundstoneHacmeTravelServer service

Figure 2: Registry structure for the insecurely registered Foundstone HacmeTravel service

As can be seen from the figure the application developers have only one registry value “ImagePath” to
register both the application path as well as any arguments that need to be passed to the application, and
this in turn causes the vulnerability to be instantiated. It pushes the onus to securely register the service with
Windows (enclosing the application path in double quotes) on the developer.

Figure 3 below shows the registry structure for the securely registered FoundstoneHacmeTravelServer
service. Note that the “ImagePath” is now appropriately enclosed in double quotes.

Figure 3: Registry structure for the securely registered Foundstone HacmeTravel service

Similarly, logon applications registered with Windows are stored in registry at

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run (All users)

• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run (Current user).

9 | 1.877.91.FOUND
Securely Registering Applications

Each registered logon application has a separate registry value under the above registry keys. For example
figures 4 and 5 below show typical registry entries for a logon application registered for “All users” and for
the “Current user” respectively.

Figure 4: Registry structure for securely and insecurely registered logon applications for all users

Figure 5: Registry structure for securely and insecurely registered logon applications for the current user

The logon applications also register the application path and the arguments to the application in the same
registry value and again in this case the onus is pushed onto the developer to make sure that that he/she
registers the application with Windows securely i.e. enclosing the application path in double quotes.

On a related note, the Win32 API CreateProcess API also suffers from the same vulnerability and
developers must securely invoke CreateProcess so that they do not launch malicious unintended
applications inadvertently.

Remediation of the Vulnerability

In the case of Windows XP and higher versions, the default file system permissions offer considerable
mitigation against the vulnerability but remediation of the vulnerability boils down to registering the
application securely with Windows i.e. as simple as enclosing the application path in double quotes.

10 | 1.877.91.FOUND
Securely Registering Applications

For instance consider the signature of the CreateService API that is typically used to register services with

SC_HANDLE CreateService(


LPCTSTR lpServiceName,

LPCTSTR lpDisplayName,

DWORD dwDesiredAccess,

DWORD dwServiceType,

DWORD dwStartType,

DWORD dwErrorControl,

LPCTSTR lpBinaryPathName,

LPCTSTR lpLoadOrderGroup,

LPDWORD lpdwTagId,

LPCTSTR lpDependencies,

LPCTSTR lpServiceStartName,

LPCTSTR lpPassword );

The parameter lpBinaryPathName points to the application path and the arguments. Developers must take
care to make sure that application path is strictly double quoted as shown in the code snippet below

std::wstring strServiceBinaryPath = L"\""; 
WCHAR strServiceBinary[MAX_PATH]; 
DWORD dwSuccess = ::GetModuleFileName(NULL, strServiceBinary, MAX_PATH); 
//Handle the return error values... 
strServiceBinaryPath += L"\"";   
SC_HANDLE hService = ::CreateService(hSCManager, TRAVEL_SERVICE_NAME, 
                                    TRAVEL_SERVICE_NAME, SC_MANAGER_ALL_ACCESS,  
                                    SERVICE_DEMAND_START, SERVICE_ERROR_IGNORE,  
                                    strServiceBinaryPath.c_str(), NULL, NULL, NULL,  
                                    NULL, _T("") );  

Similarly, for the CreateProcess API

11 | 1.877.91.FOUND
Securely Registering Applications

BOOL CreateProcess(

LPCTSTR lpApplicationName,

LPTSTR lpCommandLine,



BOOL bInheritHandles,

DWORD dwCreationFlags,

LPVOID lpEnvironment,

LPCTSTR lpCurrentDirectory,


LPPROCESS_INFORMATION lpProcessInformation );

Developers must make sure to pass the actual application path in the first parameter lpApplicationName
as shown in the code snippet below:

std::wstring strCommandLine = L"\""; 
strCommandLine.append(L"\" "); 

BOOL bSuccess = CreateProcess(

strApplicationName, /* LPCTSTR lpApplicationName, */
(wchar_t*)strCommandLine.c_str(), /* LPTSTR lpCommandLine, */
NULL, /* LPSECURITY_ATTRIBUTES lpProcessAttributes, */
NULL, /* LPSECURITY_ATTRIBUTES lpThreadAttributes, */
FALSE, /* BOOL bInheritHandles, */
0, /* DWORD dwCreationFlags, */
NULL, /* LPVOID lpEnvironment, */
FALSE, /* LPCTSTR lpCurrentDirectory, */
&si, /* LPSTARTUPINFO lpStartupInfo, */
&pi /* LPPROCESS_INFORMATION lpProcessInformation */

12 | 1.877.91.FOUND
Securely Registering Applications

Foundstone DIRE™ (Detecting Insecurely Registered Executables)

Foundstone DIRE scans the systems to identify the applications registered with Windows, then analyzes these
applications to check if they have been registered securely then displays only the insecurely registered

Following is the list of applications the tool scans for secure registration:

• Registered services

• Logon applications registered for all users

• Logon applications registered specifically for current user

If a vulnerable application is found, the tool describes the vulnerability and the risk rating associated with the
vulnerability. The risk rating for the vulnerability however varies with the operating system version.

The vulnerability is termed as a “Low Risk” for all systems running Windows XP and later because the default
file system permissions combined with the typical application installation directory makes it extremely hard to
exploit. For all systems running Windows 2000 and lower the vulnerability is termed as “High Risk”.

NOTE: This application is provided for free and is limited to Foundstone’s Terms of Use and may not be used
for commercial purposes.

13 | 1.877.91.FOUND
Securely Registering Applications


Foundstone DIRE is a Windows forms application developed using C++. It requires the use of the Microsoft
.NET framework version 2.0. These prerequisites may be obtained using Windows update or by visiting the
websites listed in the following table:

Microsoft .NET Framework v2.0

Foundstone DIRE has been tested on Windows XP, Windows 2000 workstations and Windows 2003 server
running .NET v2.0. While it has not been tested on other versions of Windows, it should execute successfully
on all Windows operating systems that can support the .NET framework v2.0

Installation Steps

Foundstone DIRE can be downloaded from the Foundstone website at The
installation is fairly straight forward and the installer will create a shortcut for the tool in the start menu folder
“Foundstone Free Tools”.

14 | 1.877.91.FOUND
Securely Registering Applications

User Guide
Launching the tool from the start menu shortcut will display the main page as shown below in Figure 6.

Figure 6: Foundstone DIRE main page

Selecting “Start Scan” will launch the scan which will identify the registered applications, analyze them and
display the insecurely registered applications. The “Status” label displays the current status of the scan as it

Figure 7 shows the result of a scan on a Windows XP system

15 | 1.877.91.FOUND
Securely Registering Applications

Figure 7: Scan Result for a Windows XP based system

For all the vulnerable applications certain related information is displayed such as:

Column Description

Command Command line registered with Windows to invoke the application. This typically includes
Line the complete application path and the arguments (if any) passed to the application.

Category Indicates the category of the registered application. Possible values include:

• Service - denotes the application is a registered service.

16 | 1.877.91.FOUND
Securely Registering Applications

• Logon - denotes the application is a registered logon application.

Type Indicates the startup type of the application. The possible values depend on the type of

For services, the possible values include:

• Automatic: The service starts automatically when the system starts.

• Manual: The service starts only when explicitly invoked.

• Disabled: The service is disabled and cannot be started.

For log on applications the possible values include:

• All Users: The logon application is registered for all users of the system.

• Current User: The logon application is registered specifically for the current user.

RunsAs Indicates the privilege with which the vulnerable application is configured to run. For
services, it is the user account with which it is configured to run. For logon applications it
is the logged on users context.

Table 1: Scan Result Description

If any vulnerable applications are found, the tool also displays a brief description of the vulnerability along
with the risk rating associated with this vulnerability. As explained previously this risk rating varies based on
the version of Windows deployed on the system.

Figure 8 shows a scan result when the scan is run on a Windows 2000 based system.

17 | 1.877.91.FOUND
Securely Registering Applications

Figure 8: Scan Result for a Windows 2000 based system

18 | 1.877.91.FOUND
Securely Registering Applications


Jason Bevis and Bill Hau provided vital support with the release of the whitepaper and the tool.

Rudolph Araujo and Bill Hau provided significant support with reviewing the white paper.

Rudolph Araujo, Mark Curphey, Jason Bevis, Dennis Hanzlik and John Viega provided considerable support in
discussing the problem, its impact, identifying the existing mitigations.

Ryan Permeh provided valuable support with reviewing the tool itself.

About Foundstone Professional Services

Foundstone® Professional Services, a division of McAfee. Inc., offers expert services and education to help
organizations continuously and measurably protect their most important assets from the most critical threats.
Through a strategic approach to security, Foundstone identifies and implements the right balance of
technology, people, and process to manage digital risk and leverage security investments more effectively.
The company’s professional services team consists of recognized security experts and authors with broad
security experience with multinational corporations, the public sector, and the US military.

19 | 1.877.91.FOUND