DLL hijacking vulnerabilities in Nirsoft tools

[Damosa]

I wasn't expecting this.

You probably already know about Nirsoft tools, these are dozens of little portable programs made to help with your Windows experience. But what you didn't know is that they have DLL hijacking vulnerabilities.

The topic has been bogged down here for quite some time and I have put it off again and again. Because on the one hand the Nirsoft tools promise support for various Windows problems. And on the other hand I don’t have to bother the developer without need. On the other hand, there are serious DLL hijacking vulnerabilities in the tools, and the developer doesn’t care. So every user should know what he is getting into.

What are the Nirsoft tools?
The Nirsoft tools are a collection of helpful Windows programs for various tasks, which are available for free. Behind the tools is the developer Nir Sofer, who describes himself as ‘an experienced developer with extensive knowledge of C++, .NET Framework, Windows API and reverse engineering of undocumented binary formats and encryption algorithms’. The tools are available on the website nirsoft.net. I myself have occasionally used one or the other program from the tool collection. All tools are portable programs and do not need to be installed.

The DLL hijacking vulnerabilities
It was the end of January 2020, when I came across the German article AdvancedRun 1.15 jetzt auch mit Kontextmenü-Eintrag published from the colleagues of deskmodder.de. This is a free tool from Nirsoft, with which you can start other programs with extended rights (administrator, system etc.). Actually a great thing, and since the tools are free of charge, the thought was there to present the whole thing in the blog.



An impulse to run a security audit for the tool
However, due to a sudden impulse, I decided to run the downloaded tool over my testbed to detect vulnerabilities. A tool that uses administrator privileges during operation should have no DLL hijacking vulnerabilities.




The whole thing ended not so well. Launching Advanced Run, I immediately received several warnings (see above figure) because the tool tries to reload dlls like dwmapi.dll, uxtheme.dll, version.dll etc. from its own directory. But also when trying to run another program like Regedit.exe with elevated privileges via the Run button, it triggers the same warning dialogs shown above (although I did not check if the called modules inherit the permissions – the UAC query comes later).

The testbed is provided by Stefan Kanthak, who deals with such security issues. You can download the file Forward.cab from his website and extract it into a folder. There is also a Sentinel.exe, which also has to be copied into this folder.

If a virus scanner jumps on when visiting the Kanthak website: It delivers the Eicar test virus in a data block attribute on its website to test whether browsers evaluate it and load it into memory for execution. A virus scanner should then be activated.

Later, the software to be tested is copied into the folder of the test bed and executed. If there are alarms as shown in the screenshot above, there is a DLL hijacking vulnerability.

Problem is: There is a vulnerability that is frowned upon in ‘good programming practice’. It should be fixed, this is possible. I’ve warned here in the blog about several tools with such vulnerabilities, most of the time it doesn’t help or I catches some comments like why I publish such a thing and I could do it better. But there are also the positive examples for such cases (see below).

Why DLL Hijacking is critical
The observed behavior means that all DLL files reloaded by Advanced Run are also executed as a process with administrative privileges. The user explicitly grants these permissions to the called processes.

Normally this works well, because Windows does not find the expected DLL files in the program’s folder and then searches in the Windows folders and loads the required DLL there. The problem: If such a vulnerability is known, a malware could exploit it.

It is sufficient for the Malware to place DLLs with the expected names in the relevant folder. In order not to attract attention, the Malware could be informed by an event when accessing the folder with the Tools (usually this will be the Downloads folder). Then there would still be time to copy the DLLs into the folder. The user grant the program (intentional) elevated permissions and the Malware DLLs are piggybacked by the DLL hijacking vulnerability receives also the elevated permissions. Advanced Run is virtually an ideal cloak of invisibility for Malware, which could then gain elevated privileges.

For example, Microsoft has published the support article KB2533623 as a Security Advisory (last updated in January 2020), in which this risk is pointed out. There was even an update for older Windows versions to help developers prevent exploitation of the DLL hijacking vulnerability. Another security advisory KB2269637 also addresses this vulnerability.

Sobering experiences with the developer
I then downloaded some more Nirsoft tools from the developer’s website and also ran them over the testbed. The result was the same, they all have a DLL hijacking vulnerability. Developers have the possibility to specify from which paths or folders the system DLLs should be reloaded. If Sofer Nir is an experienced developer, it should be an easy fix.

In December 2019 I informed the developers of the AdwCleaner of Malwarebytes about such a DLL hijacking vulnerability. They reacted immediately and released a bug-fixed version for a few days (see the blog posts AdwCleaner 8.0.1 closes a DLL Hijacking vulnerability). In April, another mishap happened to them, which was promptly fixed after I informed them (see AdwCleaner 8.0.4 closes again a DLL Hijacking vulnerability).

So in January 2020 I contacted Sofer Nir directly via his contact form and raised the issue. Connected to this was the request to react there and give feedback if necessary because I want to publish an article. At the same time I postponed the publication of the article. The hope was that it would work similar to the AdwCleaner cases.

But Sofer Nir did not respond to my requests. Since I am in regular contact with German security researcher Stefan Kanthak, I explicitly asked him about this case at the end of March 2020. Here is the correspondence including the feedback from Stefan Kanthak:

> PS: Have you had contact with Sofer Nir from Nirsoft in the past?
> The Nirsoft tools are suffering from DLL hijacking by the bank
> Weaknesses. I’d sent him an email, but never
> Received an answer (even though he retrieved the mail). I am only
> I haven’t had a chance to write anything about it yet.

I sent him multiple mails about his STARTER ERRORS, but the guy is *** deaf and dumb: NO reaction!


So confirm my picture. I had lost focus on the article again until I was reminded by the comments on the German article Defender stufte fälschlich Winaero Tweaker als Hacker-Tool ein. I do have a hard time ‘to bash’ free tools. But if their creators refuse to dig with DLL hijacking, at least users of the tools should know what a shaky board they are on. So the information is out there now, so draw your conclusions.

Source: borncity.com

[kr_nekdo]

That is such a shame. Bet they didn't update software security for years.