Windows DLL Hijack Vulnerability Affects Exe Files As Well - gHacks Tech News

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.

webclient
webclient

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

We need your help

Advertising revenue is falling fast across the Internet, and independently-run sites like Ghacks are hit hardest by it. The advertising model in its current form is coming to an end, and we have to find other ways to continue operating this site.

We are committed to keeping our content free and independent, which means no paywalls, no sponsored posts, no annoying ad formats or subscription fees.

If you like our content, and would like to help, please consider making a contribution:


Previous Post: «
Next Post: »

Comments

  1. kalmly said on September 11, 2010 at 3:50 pm
    Reply

    Thanks for the warning. I’ve always wanted to turn off WebClient but haven’t been able to figure out whether or not I need it. There’s better information out there (either that or I’m getting smarter) than there once was and I’m pretty sure I’m safe turning it off.

  2. ilev said on September 11, 2010 at 8:06 pm
    Reply

    It is dumb to turn off needed services. Microsoft should fix the horrible Windows.
    Turning off WebClient / SMB means sabotaging enterprise workflow and at home it means cutting off services like streaming video/audio to media players, uploading to Picasa albums or Dropbox…..

  3. Cassandra said on September 12, 2010 at 9:52 am
    Reply

    >open the Windows Services with the hotkey Windows-R, regedit and enter

    I believe you mean hotkey Windows-R, services.msc and enter

    1. Martin said on September 12, 2010 at 10:59 am
      Reply

      You are right, corrected. Thanks!

Leave a Reply

Check the box to consent to your data being stored in line with the guidelines set out in our privacy policy

Please note that your comment may not appear immediately after you post it.