Download All Nirsoft Tools
Ogier Dudley
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.
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.
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.
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 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.
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).
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.
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.
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 flschlich 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.
Thank you for this blog post. It is unfortunate that the Nirsoft developer did not respond to you. It would have been nice to know that that he showed concern about security. It is very sad that he apparently does not. Nirsoft has a lot of great tools and utilities that I have used over the years. Now that I know some of them have a significant security vulnerability, I will be very cautions about using them at all. I never would have know this had you not taken the time to write this blog post. So I extend you my sincerest thanks for that. And I also complement you on the professional manner in which it was done. Finally, thanks for the info on Stefan Kanthak's testbed. I will be looking into that.
there are plenty of other ways of contacting nir such as his linkedin or twitter, both of which you never attempted to try and instead attempted using a public contact form that receives endless amounts of spam and has done such for quite some time now.
If he has social media accounts that he could also be contacted through, they don't seem to be linked from the pages. Besides, I'd consider it bad etiquette to contact someone on LinkedIn about topics that are not career-related. And on Twitter, most people don't accept direct messages from strangers (as they shouldn't), and the alternative of a tweet mention is public, and hence not a responsible way of disclosing a security issue.
Sure, most of us have our mailboxes swamped and deal with spam. But if Nir Sofer doesn't see this as a reliable way of contacting him, he shouldn't ask people specifically to use it. Besides, he seems to be responsive to people contacting him by mail on other topics. Gnter isn't the only one who has contacted him about security issues, so his lack of response seems to be highly dependent on the topic.
Third, the only personal attack here is you calling Gnter a "piece of shit". The article states the problem and the events in an objective manner. Gnter doesn't insult Nir Sofer, nor does he tell people not to use his tools. He just alerts people to be aware of what he found. He found a security-senstive issue with the tools, and did a responsible disclosure to the author. He held back writing publicly about it and tried to get in touch multiple times. When that fails, what do you do? You disclose publicly. That's how it's always done in the security field. Anything else would be immoral and irresponsible.
Finally, I like Nir Sofer's tools and have used them often in the past, but this disclosure is almost two years old now and the issues still haven't been fixed. I think we're beyond the point of seeing this as simply a communications issue. At least some response should have been expected, after all we're not talking about some random feature request, but a potential risk to users.
It has been outlined above in brief. Just download the file Forward.cab (see links above) from Stefan Kanthak's website and extract it into a folder, where you later place your (portable) program to test. And download and install Sentinel.exe. The files in Forward.cab are nothing else as stubs, acting as a "honeypot" for DLL hijacking attempts, reporting each incident and sending the API call to the Windows DLL.
If you then try to execute a program on that test bed, that contains a DLL hijacking vulnerability, you will be notified (as shown within the screenshot embedded into the article above) for each possible DLL hijacking attempt.
Most software is installed with executables that inherit ready/write permissions from their parent folder and changing those permissions could very likely lead to breaking the software so you're not likely to be doing it.
Loading DLL files from a program's own directory is NOT a vulnerability. It can be a feature especially when you want to hook an existing library to add functionality to a close-source program. Mods for games do this regularly. Microsoft developed its own hooking library called Detours years ago for such DLL "hijacking".
c80f0f1006