|
Patch reliability is unclear. Unless you have an immediate, pressing need to install a specific patch, don't do it. |
borncity.com/win/2020/04/16/dll-hijacking-vulnerabilities-in-nirsoft-tools/#more-14088
This makes me sad, as I am an avid user of Nirsoft tools. Günter Born states:
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… be avoided.
It’s disappointing that the developer of these useful programs did not respond to emails about the issue, but there are a few things to remember. First, malware has to be already running on your system for this to matter. It would have had to have already tricked you into running the malware on your system, or else it would have had to exploit a second, much more severe vulnerability to allow arbitrary code to be run without the user’s intent. It’s a privilege escalation vulnerability, where a malware already running with user privileges (whose ability to cause harm to the OS or to do things like set itself to automatically run at startup is limited) could run a process with administrative rights without triggering a UAC prompt (although running the Nirsoft tool would still trigger UAC, as it should). Once it gained those admin privileges, it would be free to do pretty much anything it wanted, bypassing the protection offered by UAC.
There’s a key bit of info in this quote from the article:
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). (Emphasis added)
The Downloads folder is normally owned by the user in question, not by the system, and that’s the key to the exploit as described.
When you run the Nirsoft program, it asks for administrative privileges with a UAC prompt (since it is an admin tool that needs admin privileges to do its thing), and then it loads .dlls from its program directory, wherever that may be. The attack requires that the malware replace these .dlls with its own, so when the Nirsoft program gets the admin privileges and then calls what it thinks is one of its own bits, it’s actually calling a bit of the malware, and running it with elevated (admin) privileges.
Before that happens, though, the malware would be running with user privileges, and would only be able to replace those .dlls that are part of the Nirsoft program with its own, tainted .dlls if the folder containing the original executable and the .dlls it needs is writable by the user. Generally, that would mean it would have to be owned by the user, which the Downloads folder would be.
The simple solution to this is “Don’t run it from the Downloads folder,” or any other folder that is not owned by the operating system. Put the Nirsoft stuff in a folder of your choosing under Program Files, and it will not be possible for a malware to simply substitute its own .dll for one of the program .dlls, since it will not have permission to write to that location.
Nirsoft tools are quite useful, but they’re not mass-market things that a broad number of Windows users will have and use regularly. A malware would have to be already running when the user runs a Nirsoft administrative program from a non-system location, and that malware would have to be waiting for that very event to be able to use the program to gain admin privileges. It’s not very likely that malware authors would target such a niche program for such an exploit, and that if you’re a user of Nirsoft programs, that this particular malware would already be running on your system when you ran a Nirsoft program. Even in the unlikely event that such a malware was written, and it was running on your system, undetected, until you decided to run the Nirsoft program, the privilege escalation would not work if the Nirsoft program was run from, say, \Program Files.
I’ve used Nirsoft tools when I used Windows, but even without being aware of this issue, I ran them from a subfolder of \Program Files, as that just makes the most sense. That’s the place one would put program files, right? Do that, and this exploit won’t work.
Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, KDE Neon
Acer Swift Go 14, i5-1335U/16GB, KDE Neon (and Win 11)
Windows 10 “Digital license” activation have been exploited for almost 3 years now, due DLL hijacking
did you see Microsoft fixes it? 🙂
DLL load/redirection will never be fully avoided without the user brain
did you see Microsoft fixes it?
Günter Born’s article troubles me. It mentions:
“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.”
This gives the impression that this is a recent problem. However, if you check the Wayback Machine, this security advisory was first captured on August 30th 2017 and mentions mitigations for MUCH earlier versions of Windows dating back to Windows Vista, for goodness sake.
So, Microsoft have been aware of this DLL hijacking vulnerability in multiple versions of their Windows product for several years. What I find strange is that Günter Born chooses to blame Nir Sofer (and other 3rd-party app developers) for not working around something that actually appears to be Microsoft’s fault?
I mean, the DLLs he mentions – dwmapi.dll, uxtheme.dll, version.dll – are all core Windows system files, all found by default in C:\Windows\System32.
So Windows – now with code signing, integrity checking and built-in antimalware – still cannot work out whether a Windows system file is being spoofed maliciously? Have I got this right? I’m more than happy to concede that I’ve misunderstood the content (and tone) of the article.
By tone, I note that after not receiving a reply from Nir Sofer, Günter Born apparently writes to a third person (security researcher Stefan Kanthak):
“I sent him multiple mails about his STARTER ERRORS, but the guy is *** deaf and dumb: NO reaction!”
There could be many reasons why Nir Sofer has not (yet?) responded to Günter Born since the end of January. For example, he could be in hospital. Or maybe Günter Born sent his email in German (despite Nir Sofer’s warning):
“I receive messages in German, Spanish, and other languages on daily basis, but I simply delete them because I cannot understand any word.”
Or he could just be laboriously ploughing through each and every one of his utilities, re-coding around this DLL hijacking vulnerability. Nobody except Nir Sofer knows what the reason is.
(However, to be honest – if I saw that’s how someone described me to the world in digital print then I wouldn’t respond to him/her either… ever. IMO, it’s just downright rude.)
PS – Here’s a Register article concerning Stefan Kanthak. To save you reading it all, I’ll just quote the very last sentence of the article’s conclusion:
“In other words, security can be slow.”
Yes, it certainly can be. Ask Microsoft…
Donations from Plus members keep this site going. You can identify the people who support AskWoody by the Plus badge on their avatars.
AskWoody Plus members not only get access to all of the contents of this site -- including Susan Bradley's frequently updated Patch Watch listing -- they also receive weekly AskWoody Plus Newsletters (formerly Windows Secrets Newsletter) and AskWoody Plus Alerts, emails when there are important breaking developments.
