Aangifte 2005 privilege escalation vulnerability

Yorick Koster, June 2006


A privilege escalation vulnerability exists in the Dutch IRS tax report program "Aangifte 2005". This vulnerability exists because of incorrect ACLs on the program's installation directory. Because of this, it is possible for local users to install arbitrary DLL files in this directory and cause these files to be loaded whenever a user starts the tax report program.


It appears that Aangift 2006 is also affected by this issue. By default, Aangifte 2007 is installed under Program Files. Consequently, if Aangifte 2007 is installed in the default folder it will not be vulnerable to this issue. However if the user chooses to install it under a different directoy (for example C:\BDIENST\) than file permissions are inherited from the parent folder. If these permissions are insecure, the application is still affected. In addition users tax reports are no longer installed within the installation folder, instead the users personal folder is used.


By default, the Aangifte 2005 program is installed in the directory C:\BDIENST\2005. The default file permissions for the Users group on Windows XP are:

   * Read & Execute
   * List Folder Contents
   * Read
   * Create Files / Write Data
   * Create Folders / Append Data

These are the default ACLs on Windows XP, which are inherited from the C:\ root directory. On Windows 2000 the C:\ root directory is set to "Everybody Full Control". These permissions are inherited by the Aangifte 2005 including the executables (!).

On Windows XP, all files that are installed in the C:\BDIENST\2005 directory by the Setup program are properly protected through the use of ACLs. Users in the Users group are assigned the following file permissions:

   * Read & Execute
   * Read

Because of these ACLs, regular users are not allowed to overwrite these files. Consequently, it is not possible to overwrite ib2005.exe with a trojaned version (on Windows XP). Users are allowed to create new files though.

DLL injection

Generally, every Windows application is linked against at least one dynamically linked library (DLL), which is kernel32.dll. In most cases, a Windows application is linked against more DLLs. This is also the case for the Aangifte 2005 program. This application is linked against the following DLLs:

C:\Program Files\Microsoft Visual Studio 8\VC\bin>dumpbin /dependents C:\BDIENST\2005\ib2005.exe
Microsoft (R) COFF/PE Dumper Version 8.00.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file C:\BDIENST\2005\ib2005.exe
   Image has the following dependencies:


When Windows loads an application, it will also try to load all the DLLs that this application is linked to. Windows uses a certain search strategy to locate these DLLs. This strategy depends on the versions of Windows that is used. The exact strategy can be found at the following location:
Dynamic-Link Library Search Order

In most cases, the directory from which the application loaded is search first. So, in theory, we can place a custom DLL with the same name as one of the DLLs listed above in the C:\BDIENST\2005 directory and cause it to be loaded when Aangifte 2005 is started. Doing so allows us to execute any code we want with the privileges of the user running Aangifte 2005. Unfortunately for us, the above DLLs are loaded directly from the System directory (C:\WINDOWS\System32).

Besides the DLLs listed above, it is possible that other DLLs are loaded as well. Certain display device drivers and human interface device drivers are known to trigger this behavior. To find out if this is the case on your system, a tool like FileMon can be used to check for this condition.

The following images show how to detect such DLLs. In this case, the target system uses certain NVIDIA drivers that will inject nvdesk32.dll in every newly started application.

Privileges escalation

If a suitable DLL is found, it is possible to escalate privileges. This is possible by placing a custom DLL in the C:\BDIENST\2005 directory. The following proof of concept demonstrates this:

#include <windows.h>
#include <stdlib.h>
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
   return TRUE;

Dynamic-Link Library Redirection

The attack above has one problem; the attack is very system depended. Every system (configuration) has to be inspected separately to find an appropriate DLL. A more reliable attack is required. Fortunately for us, Windows 2000 has introduced "Dynamic-Link Library Redirection". More information about this feature can be found at the following location:
Dynamic-Link Library Redirection

In short, we can instruct Windows to always search the directory from which the application loaded is first even if a path has been supplied. We can do this by creating an AppName.exe.local file, in our case ib2005.exe.local. Doing this enables DLL redirection for the Aangifte 2005 program. This is demonstrated in the following figure:

Using our previous proof of concept will fail. When Aangifte 2005 is loaded, Windows will try to import the functions that are required by Aangifte 2005. This requires that our DLL meets certain criteria or else loading will fail. In order to exploit this issue, a DLL has to be constructed that meets these criteria. One way of doing is this, is by taking the original DLL and insert our code into it.