wp securely registering apps

8/7/2019 Wp Securely Registering Apps

1/19

Securely Registering Applications

Author:

Neelay S ShahSenior Software Security Consultant

Foundstone Professional Services


2/19


Table of Contents

Securely Registering Applications 1

Table of Contents 2 Abstract

Introduction 4

Discussion 5

Foundstone DIRE (Detecting Insecurely Registered Executables) 13

Acknowledgements

About Foundstone Professional Services

2 www.foundstone.com | 1.877.91.FOUND


3/193 www.foundstone.com | 1.877.91.FOUND


Abstract

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 users 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 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.


4/19


Introduction

The need for an application to start automatically when the system starts up or when the user logs in isfrequently 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:

Window s 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.



5/19


Discussion

Overview

The vulnerability potentially impacts all registered applications whose installation path contains a

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

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 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.



6/19


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



7/19



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 attackers malicious

binary so it could as well be the attackers 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 M itigation(s)

One of the main hurdles the attacker has to overcome to successfully exploit this vulnerability is to copy the

malicious application to the victims 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 attackers 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.

1 For a overview on service programs and service entry points refer to MSDN documentation athttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/service_control_handler_function.asp


8/19


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 servicesand 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 dont 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

C:\Software.exe.

Cause of the Vulnerability

From a developers perspective then, what implementation flaw can result in their application to be potentially

vulnerable to this flaw? As explained previously, Windows uses the 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



9/19


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

[HKLM\SYSTEM\CurrentControlSet\Services\FoundstoneHacmeTravelServer] :

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).



10/19


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 [HKLM\Microsoft\Windows\CurrentVersion\Run]

Figure 5: Registry structure for securely and insecurely registered logon applications for the current user [HKCU\Microsoft\Windows\CurrentVersion\Run]

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 considerablemitigation 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.



11/19


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

Windows

SC_HANDLE CreateService(

SC_HANDLE hSCManager,

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.append(strServiceBinary); strServiceBinaryPath += L"\"" ;

SC_HANDLE hService = ::CreateService(hSCManager, TRAVEL_SERVICE_NAME, TRAVEL_SERVICE_NAME, SC_MANAGER_ALL_ACCESS, SERVICE_WIN32_OWN_PROCESS, SERVICE_DEMAND_START, SERVICE_ERROR_IGNORE, strServiceBinaryPath.c_str(), NULL, NULL, NULL, NULL, _T( "" ) );

Similarly, for the CreateProcess API



12/1912 www.foundstone.com | 1.877.91.FOUND


BOOL CreateProcess(

LPCTSTR lpApplicationName,

LPTSTR lpCommandLine,

LPSECURITY_ATTRIBUTES lpProcessAttributes,

LPSECURITY_ATTRIBUTES lpThreadAttributes,

BOOL bInheritHandles,

DWORD dwCreationFlags,

LPVOID lpEnvironment,

LPCTSTR lpCurrentDirectory,

LPSTARTUPINFO lpStartupInfo,

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(strApplicationName); strCommandLine.append(L "\" " );

strCommandLine.append(strArguments);

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 */);


13/19


Foundstone DI RE (Detecting In securely Registered Executables)

Description

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

applications.

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 Foundstones Terms of Use and may not be used

for commercial purposes.



14/19



Installation

Prerequisites

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 http://msdn.microsoft.com/netframework/howtoget/

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 http://www.foundstone.com/s3i . The

installation is fairly straight forward and the installer will create a shortcut for the tool in the start menu folder

Foundstone Free Tools.
http://msdn.microsoft.com/netframework/howtoget/http://msdn.microsoft.com/netframework/howtoget/http://www.foundstone.com/s3ihttp://www.foundstone.com/s3ihttp://msdn.microsoft.com/netframework/howtoget/


15/19


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

progresses.

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



16/19


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

Line

Command line registered with Windows to invoke the application. This typically includes

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.



17/19


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

application.

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.



18/19


Figure 8: Scan Result for a Windows 2000 based system



19/19


Acknowledgements

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 Foundst one Professional Services

Foundstone Professional Services, a division of McAfee. Inc., offers expert services and education to helporganizations 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 companys professional services team consists of recognized security experts and authors with broad

security experience with multinational corporations, the public sector, and the US military.

wp securely registering apps

Documents