[German]The Nirsoft tools are probably known to many Windows users. What is less known: The tools come along with nasty DLL hijacking vulnerabilities and should rather be avoided.
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.
Cookies helps to fund this blog: Cookie settings
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.
I don't know, if Nirsoft doesn't care about security – there has been several contact attempts via his contact form from Stefan and me – without any reaction/feedback. So it's just a black box.
Pingback: DLL hijacking vulnerabilities in Nirsoft tools - MalwareSearch.com
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.
what a piece of shit personally attacking someone due to your lack of actually attempting to reach out beyond sending a single email from a public contact form.
No comments – Sofer has been contacted by several people via contact form offered on his site over a longer time period. So I see no obligation, to try different (social media) channels. I just name it, if you see a personal attack, it's simply your problem. If Sofer Nir fix that issue, I'm glad to add this information to the post.
Don't blame the messenger of the news. No more to say, from my point of view.
First of all, Nir Sofer promotes this e-mail address and contact form as the primary way of contacting him. In fact, it's the only way he mentions on his website.
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.
Second, Günter, who is not known to make things up, talks about "requests" he sent to Nir Sofer – plural, not "a single email" – and mentions that he "retrieved the mail". So I assume he either requested and received a confirmation of receipt, or he's using a tracking tag to see which mails of his have been opened.
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. Günter 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 Günter a "piece of shit". The article states the problem and the events in an objective manner. Günter 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.
The most important part is how are you searching for DLL injection. Would you be so kind to have a blog post about it?
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.
A few more details about sentinel.exe may be found here. And some more details about Forward.cab here.
Notes: It seems now, that Defender deletes the files from Forware.cab – so the files need to be excluded from beeing quaratined, to use that test bed
Thank you for your review. I didn't have the knowledge and skills to identify these vunerabilities myself, although I see that virus checkers flag the NirSoft utilities.
I'm disappointed that the DLL vunerabilities are throughout the NirSoft utilities, because the NirSoft utilities give the user tremendously useful abilities to get things done quickly with small programs, either with a GUI or with a command prompt. It reminds me of the good old days of DOS and Windows programming. I don't know of any other place with so many great ideas for utilities — and free to boot!
Considering the lack of response to your requests from NirSoft, we don't know whether he/she even received and read your requests — much less your review — nor anything about his/her attitude towards the risks his software introduces and your review. Nevertheless, your review is useful to others without the expertise, desire, or time to test the benefit/risk of using NirSoft software. Overall, I think your review keeps a professional attitude by simply warning readers of risks without forbidding people from using the utilities completely.
I do think it's strange that NirSoft doesn't have a FB page and makes himself/herself so difficult to read and to have discussions about the software — maybe simply on a real forum on his/her own website.
I wish the author of the software would read these reviews and tweak the software to either get rid of the vunerabilities or to explicitly state the vunerabilities to the software user. In other words, these reviews could be used by NirSoft himself to improve his software and re-publish new versions (a benefit for himself and others).
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.
That said – correct me if I'm wrong, but if an attacker already has write access to your executable's folder, you're pretty much already fucked at that point. Even without the DLL hijacking vulnerability, the attacker could easily just patch their malicious payload directly into the target executable at this point. (Which also has the advantage of not creating new files that could be noticed by the user)
You didn't cat the beef – imho. Portable tools may be executed from user's download folder. But if there is a copy of a system's DLL abused by hijacking, this DLL is loaded from the system wie system privileges. So malware may abuse this for privilege escalations. Correct me, if I'm wrong – but overall – Microsoft's good practice for Win programming says, that developers shall avoid DLL hijacking.
" if an attacker already has write access to your executable's folder, you're pretty much already fucked at that point…the attacker could easily just patch their malicious payload directly into the target executable at this point. "
EXACTLY! This so-called vulnerability is much ado about nothing.
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".
The bottom line is know what you are running on your own PC and take responsibility for it. Programmers don't need to gimp their programs' functionality to take into account users whose PC's are already compromised.
Fear you didn't catched the beef … do we have troll alarm here? If not, please ask Google's search engine about portable apps and also about dll hijacking, and don't spread your misinformation.
Can you point to any cases where Nir Sofer's wonderful collection of Nirsoft tools has been exploited using dll hijacking to let attackers exploit someone? Micro$oft has enough LOLbins out there already. Microsoft Installutil.exe is hilarious. I think I'll go make a donation to Nirsoft now. He has contributed so much goodness over the years.
It's your choice to make a donation. But don't beat the messenger – it's up to you to use the tool, if there is a know vulnerability. That's the goal of the article: Point to a vulnerability to infom people, and allow to take care or mitigate that flaw (if your machine is clean, you don't have to worry).
Your point "have you ever seen a case of misuse" is just silly.
Nir highly likely has close ties with the Israeli 8200 espionage and digital infiltration unit. The tools put in place are there to be put on the machines of cyber experts or individuals interested in forensics in general. As a result, putting a trojan horse there, or injecting a vulnerability is very useful if there is a desire to collect information from it in the future. There are several free utilities in this operation posted online to entice the curious, including sites targeting Iranian scientists and engineers in particular with hacked solutions to tempt them to install them and have security breaches that the state of israel subsequently operate. An example is the Downloady.ir site which targets the scientific and knowledge community and which allows you to download several tools, pirate courses for free under the false guise of a lambda hacking site.
So distrust is the rule