DLL hijacking vulnerabilities in Nirsoft tools

[whoknows]

http://borncity.com/win/2020/04/16/dll-hijacking-vulnerabilities-in-nirsoft-tools/

 

[atom0s]

Pretty much every single application made for Windows is "vulnerable" to this. It's not unique or special to Nirsoft tools. This is a common method of DLL injection for things such as games, or hot-patching for various libraries such as runtimes and such known as proxying. Some common targeted libraries are usually things like:

• Direct3D: d3d8.dll, d3d9.dll, dinput.dll, ddraw.dll
• Windows: wsock32.dll, version.dll, uxtheme.dll
• Runtimes: msvcrt libraries, etc.

This is simply due to how the load order works on Windows in general. https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order

[Taitor]

4 hours ago, atom0s said:

Pretty much every single application made for Windows is "vulnerable" to this. It's not unique or special to Nirsoft tools. This is a common method of DLL injection for things such as games, or hot-patching for various libraries such as runtimes and such known as proxying.

It would be fine for games and such but would turn out to be a huge risk if found in security tools.

It maybe worthy of note that the recent Windows versions do check for the MS signatures in system files and reject them if the sigs don't match. So such hijacking could turn out to be a thing of the past in the not so distant future.

[Progman]

How to fix it?  Force all admin privilege software to be installed to Program Files or Admin write only folder? Check each DLL location based on path environment variable and confirm system32?  These are ridiculous ideas IMO.

This has been like this since Win9x...  it's also convenient sometimes for escaping DLL hell to have the search order.  Also convenient to make patches and cracks in some cases too where you deal with packed files or files you dont want to statically modify.

[kao]

1) As atom0s already mentioned, it's not a bug in Nirsoft tools but in Windows. In this case, specifically, how common controls and Desktop Windows Manager work.

2) Dwmapi.dll abuse is a well known issue, the earliest report I could find, dates back to 2010: https://www.exploit-db.com/exploits/14734

3) It's trivial to solve using undocumented directive "loadFrom" in the application manifest file. Something like this and this.

[Progman]

The manifests only work in Win7 and later though?  Had to be the only fix given that static linked DLLs are loaded prior to WinMain.

[kao]

14 minutes ago, Progman said:

manifests only work in Win7 and later

If someone is still using WinXP, he/she has much bigger issues than DLL planting vulnerability in Nirsoft tools.

16 minutes ago, Progman said:

static linked DLLs

From the top of my head, dwmapi.dll is almost never linked statically. But I can't check Nirsoft's tools right now.

[Gorina]

5 hours ago, kao said:

3) It's trivial to solve using undocumented directive "loadFrom" in the application manifest file. Something like this and this.

Of course, that's the solution but it is also just as easy to remove that directive from the app later.

57 minutes ago, kao said:

If someone is still using WinXP, he/she has much bigger issues than DLL planting vulnerability in Nirsoft tools.

True

Edited April 18, 2020 by Gorina

[Progman]

I suppose its true dynamic load via LoadLibrary is still buggy.  Of course you could specify "%SystemRoot%\system32\" + DllName for 32/64-bit apps and for 32-bit apps on 64-bit systems that need to access a 64-bit DLL which is basically pointless in the LoadLibrary context AFAICS: "%SystemRoot%\sysnative\" + DllName.  This would require a buffer and a GetEnvironmentVariable call.  But it achieves exactly the same effect as the manifest for XP...

Win9x/ME at least would be even less an issue since they already do not have any security privileges so the DLL hijack could be done on any app not just a privileged one.

WinXP is still being used by a lot of governments, militaries, hospitals and other institutions without budgets, along with consumers who have used or old hardware.  I'm not sure how important supporting it is these days but I suppose it depends on the app.  I usually liked getting things working on every Windows version because it made the code base much more stable given that Microsoft has gone through serious efforts to maintain backwards and forwards combability due to business requirements.

 

Update: who knows though since MSFT apparently has supported application manifests in XP and Vista:

https://docs.microsoft.com/en-us/windows/win32/win7appqual/compatibility---application-manifest

Quote

Applications without a Compatibility section in their manifest will receive Windows Vista behavior by default on Windows 7 and future Windows versions. Note that Windows XP and Windows Vista ignore this manifest section and it has no impact on them.

 

Edited April 18, 2020 by Progman

[atom0s]

There is basically no point to try and fix it on the system wide level. Injection still being possible in a million other ways defeats the purpose of fixing 1 layer. It will also have the repercussion of breaking existing applications that rely on loading run times and other important libraries directly. A lot of apps ship with their runtimes and other important modules in the programs folder instead of forcing users to install them entirely. This is also done due to patching requirements on some runtimes, running specific versions, etc. If Microsoft decides to enforce things differently or break this from working, they risk breaking thousands of applications. (Granted it is Microsoft, so it wouldn't be the first time they've done this.)

Manifests are also fairly pointless, as they are basically just a 'suggestion' for the system to follow. You can just strip them out or edit them directly. Digitally signed files can also be tampered with fairly easily. Any type of enforcement would have to be done at the system level, which would require either completely changing the load order to remove local folder loading, or give it less priority. Both of which will land up breaking a lot of apps as mentioned.

[Sangavi]

21 hours ago, kao said:

If someone is still using WinXP, he/she has much bigger issues than DLL planting vulnerability in Nirsoft tools.

From the top of my head, dwmapi.dll is almost never linked statically. But I can't check Nirsoft's tools right now.

If someone i sable to plant DLLs in one's system then that person has bigger problems to deal with, whether it be windows xp or windows 10, lol.

[whoknows]

https://www.bleepingcomputer.com/news/security/nearly-300-windows-10-executables-vulnerable-to-dll-hijacking/