This attack vector allows for the loading of malicious dynamic-link
libraries (DLLs) when loading certain programs in the Windows operating
system. It is due to applications not specifying the full path to the
trusted library to use in the programming code.
By default, if the path to a DLL is not specified, Windows will look in
the current working directory first to find the DLL. If a malicious DLL
with the same name exists in the current directory, it will be loaded
and the system exploited.
In order for this exploit to work, the user must be tricked into opening
a file that is associated with a vulnerable program. A malicious DLL
has to exist in the same directory as the file. For this to happen,
both files must exist on the same filesystem, which could be a local
filesystem, SMB mount, WebDAV mount or inside a compressed image (like ZIP),
Normally trusted files, such as Word .doc, .mp3, .xls, .html, may be
Microsoft has recommended a few workarounds. They include blocking
outbound SMB and WebDAV connections. They also have a tool and registry
hacks to change the DLL search order. This should be tested and
verified before deploying to ensure all programs work properly.
Otherwise, Microsoft recommends software vendors to patch their code to
avoid loading invalid DLL files. The list of software that is affected
is large, which means a lot of patching and updating is on the horizon.
It is recommended that users be educated on this exploit. Remind users
not to open files from untrusted sources, or to look for odd DLL files
in directories where they are opening files.
Looking into the Knowledge Base article on the tool to change the DLL
search path is also recommended.
I will bring up the idea to block outbound SMB and WebDAV traffic to the
computing group to discuss it as a possibility. This will not block
local filesystems with malicious files.