Securely Registering Applications

Transcription

1 Author: Neelay S Shah Senior Software Security Consultant Foundstone Professional Services

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

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

4 Introduction 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 antivirus 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 FOUND

5 Discussion Overview 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 FOUND

6 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 o o Starting the service or Restarting the underlying computer or 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 FOUND

7 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. 1 For a overview on service programs and service entry points refer to MSDN documentation at FOUND

8 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 C:\Software.exe. 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 FOUND

9 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) FOUND

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

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

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

13 Foundstone DIRE (Detecting Insecurely 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 Foundstone s Terms of Use and may not be used for commercial purposes FOUND

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

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

16 Figure 7: Scan Result for a Windows XP based system For all the vulnerable applications certain related information is displayed such as: Column Command Line Category Description 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. Indicates the category of the registered application. Possible values include: Service - denotes the application is a registered service FOUND

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

18 Figure 8: Scan Result for a Windows 2000 based system FOUND

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