Windows DLL Hijack Vulnerability Affects Exe Files As Well

The recently discovered DLL hijack vulnerability in Windows appears to be more critical than thought. Up until now it was confirmed that Windows would load dlls from the current working directory if they cannot be found in directories with a higher search priority.

This in turn meant that attackers had to use a dll unknown to the system to exploit the vulnerability. Users who want a confirmed list of Windows programs that are affected by the DLL vulnerability can visit Secunia for that. At the time of writing, a total of 123 different applications by 47 vendors are affected.

The problem with executable files is that the search priority list changes. According to a blog post at the Acros Security blog, exe files are either loaded with the highest or second highest priority in Windows.

This means for instance that a command to launch a new process will look into the current working directory prior to looking into the Windows directories or directories in the path environment.

An attacker could exploit this by placing executable files of the same name in the working directory, e.g. a malicious explorer.exe that is launched by the application executed by the user of the system.

What does it mean? It means that the situation is highly critical as the available workarounds to protect a system from the DLL hijacking vulnerability are not protecting it against the exe hijacking.

[CreateProcess] Apparently the current working directory is in the second place, which means that when an application tries to launch the Windows Calculator by calling something like CreateProcess(NULL,"calc.exe",...), a malicious calc.exe lurking in the current working directory will get launched instead. And remotely, too, if the current working directory happens to point to a remote network share in a local network or on Internet. And no, launching remote executables using these functions will never issue any security warnings to the user, in contrast to ShellExecute*. As far as we know, introducing ShellExecute-like security warnings to these functions would cause serious problems with various batch jobs and server back-end operations running without humans present.

Acros have created a test and have released it to the public. The Online Binary Planting Exposure Test is available on Binaryplanting.com. This test is aimed at users who want totest their exposure to binary planting attacks.

The easiest way to fix the issue, at least for users who do not use WebDav is to disable it. Windows 7 users need to open the Windows Services with the hotkey Windows-R, type services.msc and hit enter.

They then need to locate the service WebClient, which is set to manual by default. A double-click on the entry and the selection of disabled disables the service completely on the operating system.

The issue itself still exists on local drives, after disabling WebDav. An example was given for Apple's Safari web browser, which can be used in the attacks (Apple has updated the browser since then):

As a result of an incorrect process launching in Apple Safari for Windows, an attacker can cause her malicious EXE [1] to be loaded and executed from local drives, remote Windows shares, and even shares located on Internet.

What a remote attacker has to do is plant a malicious explorer.exe on a network share and get the user to open an HTML file from this network location with Safari - which should require minimal social engineering. Then, when the user tries to open one of his downloaded files in the
containing folder (e.g., menu: Window -> Downloads -> right-click on a file -> Show Containing Folder), the malicious explorer.exe is launched instead of the legitimate one.

Alternatively, if the HTML file opens (or redirects to) any "file://" location, Safari's attempt to launch Windows Explorer will result in launching the malicious explorer.exe. (via)

Security software that is up to date is the most effective option in protecting the system from local attacks.

Advertisement