To make a long and complicated story short, a bad guy who exploits this vulnerability places a malicious DLL into your browser’s Downloads folder, then waits. When you run an installer built by an earlier version of NSIS from that folder, the elevation prompt (assuming it runs at admin) shows the legitimate installer’s signature asking you for permission to run the installer. After you grant permission, the victim installer loads the malicious DLL which runs its malicious code with the installer’s permissions. And then it’s not your computer anymore.
So, how does the attacker get the malicious DLL into the browser’s Downloads folder? Surely that must involve some crazy hacking or social engineering, right?
Nah. The bad guy just navigates a frame of your browser to the DLL of his choice and, if you’re on Chrome or Microsoft Edge, the DLL is dropped in the Downloads folder without even asking. Oops.
It’s trivial to simulate this attack to find vulnerable installers, even as a total noob.
1. Simply click this link which downloads a fake DLL (a simple text file containing the string ThisIsNotADLL).
2.Then download and run an installer built by an old version of NSIS:
3. Accept the elevation prompt:
4. Boom… watch Windows try to load your fake DLL as code:
Of course, a real bad guy isn’t going to be nice enough to use a fake DLL, he’ll instead use a valid but malicious one containing code that runs during DLL load, silently rooting your computer or whatever other nefarious thing he’d like.
Around 80% of the installers in my \Downloads\ folder are vulnerable to this attack; half of those are built on NSIS and half are built using other technologies.
You can learn more about DLL Hijacking attacks here.
I’ve found some otherwise-safe installers will perform unqualified calls to system utilities (e.g. to manipulate the firewall or registry, etc). If a bad guy plants an executable of the target name (e.g. “netsh.exe”) in the \Downloads\ folder, it could be executed without warning, much like the DLL hijacking attack.
Here are my suggestions:
- If you build installers with NSIS, please upgrade immediately.
- If you build installers with other technology, test for this attack (version.dll, msi.dll, shfolder.dll, etc). This post suggests a more complete way of finding target filenames. Another post notes that InnoSetup is vulnerable.
- Read Microsoft’s guidance for mitigating this vulnerability.
- Ask your browser vendor what they’re doing to prevent attacks of this nature.