DLL Hijacking: Facts and Fiction

By Oliver LaveryIt’s been
interesting watching DLL hijacking grow from interesting phenomena  to a full-on snowball of hype and FUD over
the last few days. As of this writing Google turns up 152 news articles on the
subject. The vast majority
of coverage is calling this a “new class of attack” and pointing out how “over
30 zero-day vulnerabilities have been found so far!”. The only way to
paraphrase many of the headlines is: “Panic!”

It’s been
interesting watching DLL hijacking grow from interesting phenomena  to a full-on snowball of hype and FUD over
the last few days. As of this writing Google turns up 152 news articles on the
subject. The vast majority
of coverage is calling this a “new class of attack” and pointing out how “over
30 zero-day vulnerabilities have been found so far!”. The only way to
paraphrase many of the headlines is: “Panic!”

Fear and panic,
while good for security companies and media outlets in the short term, are not
responses that benefit users. Risk management isn’t based on emotion, it’s
based on a well-reasoned assessment of risk. In the long run panic can draw
attention away from the day-to-day issues which may represent more risk to the
enterprise.

DLL hijacking simply isn’t the same as a typical zero-day
vulnerability. The technical details of the attack have been covered in depth elsewhere,
so I won’t go into them here, but technical details without context can lead to
exaggerated conclusions. Let’s take a step back and look at this in the context
of history and fact…

First and foremost, DLL hijacking is not a new zero-day vulnerability.
It’s been issued a Bugtraq ID since 2000. I suspect most people who
have worked with C or C++ on Windows were already aware of the surrounding
issues, including the Windows DLL search path. It certainly used to bite me
when I was a full-time coder and accidentally put an old-buggy version of a DLL
I was working on in the wrong place! On Unix DLL hijacking (shared library
preloading) is a feature accomplished through the LD_PRELOAD environment
variable.

The root of this problem lies in the past in an industry far removed
from internet security. Many years ago a Microsoft design error included the
current working directory in the list of directories Windows will search when
looking for a DLL. As a result, it was trivial to use a directory under your
control to trick an application into loading the wrong copy of a DLL, which
could be a security flaw in some circumstances. Later as the Internet grew and
computer security became a pressing issue, Microsoft mitigated this problem by
introducing the SafeDLllSearchMode registry key. It wasn’t a perfect
solution, but it did help the situation. Finally this behavior was enabled by
default in Windows XP SP2.

Prior to SafeDllSearchMode virtually every windows application
was vulnerable to this sort of DLL Hijacking attack. Did it cause infopocalypse?
Did SCADA systems burst into flames world-wide? Nope.

Yet, ten years later, the fact that this DLL hijacking technique can
still be used in some very specific circumstances is apparently cause for
panic. The number of applications that this impacts is apparently big news. Lists are being published. Headlines read that
“exploit code hits the wild”.

The reality is anyone who can stumble through the DLL project wizard
in Visual Studio can write an ‘exploit’ for this vulnerability, and when the
dust settles the lists will look a bit silly — virtually every Windows
application will be found to be vulnerable in one way or another.

Does it matter? Yes. Is it cause for concern? Probably. Should we all
panic about this new ‘glut of zero-days’? Not at all.

The key thing to understand is there are tons of mitigating factors
for this sort of attack, and that’s why it isn’t widely exploited even though
it’s been known for a long time:

  • The user must open a document from a WebDAV share or a network file
    share
    . Reports that say that “opening a file
    from the Internet” can cause a victim to be compromised are extremely
    misleading. That document could be opened via a link in an email, however,
    which is cause for concern, as this sort of attack will always succeed for a
    small population of users.
  • The attacker must guess what vulnerable software you have installed. Since we’ve seen reports that MS Office and other ubiquitous
    applications are vulnerable, that isn’t very hard right now. It’s safe to
    assume we’ll see patches in the coming weeks, at which point attackers will
    have a much worse success rate as they have to predict which software, and in
    some cases what version of a program, a victim has installed.
  • There are easier ways to trick a user. Similar email attacks have been fairly successful this year, but
    they used much simpler vectors. PDF files and Word documents are things users
    are used to receiving in email and opening without a second thought; so
    zero-day vulnerabilities in Acrobat or Word are a big deal. Call me an
    optimist, but I’d like to think users might pause to think harder when a weird
    looking link in email opens up an Explorer window on a WebDAV share on the
    Internet. That’s just not a normal use-case.
  • Virus software can help. Some
    people are reporting that anti-virus can’t block this sort of attack. That’s
    largely false. It is easy to write a malicious DLL, but it’s just as easy to
    create an A/V signature for a malicious DLL as any other malware.

To make a
prediction, we’ll probably see email borne attempts to exploit DLL
hijacking  circulate for a while. They
won’t be that effective, and we’ll all go back to business as usual when the
next big zero-day in a common file format surfaces.

That said, within the enterprise, where opening files or even
applications from shares is commonplace, this could represent a real risk from
an inside attacker. Please do head over to Microsoft and deploy the fix,
there’s really no good reason to load a DLL from a WebDAV or other share in a
security conscious environment.

Oliver Lavery is the director of security research and development at nCircle.

Suggested articles

Discussion

  • HD on

    Some other vectors to watch out for - Carpet Bombing (Aviv Raff demo'ed this with Chrome), ZIP archives, and USB keys. Opening a safe file with safe content should't result in code execution, but it does, and it affects applications bundled with the OS.

  • Anonymous on

    Great article Oliver. There are times when it seems like the "Security News Community" acts more like the daily celebrity entertainment hype shows than a true alert messaging system. It's good to see someone speaking out as a vioce of reason. That being said, it is ironic that the page your article loads on has 60% of it's most popular links and 33% of it's pod cast dedicated to the stories. Looks like you may be a lone voice lost in the "infotainment" babble.

  • Anonymous on

    You are right that this is not new, but what does this say about the app developers who have done little or nothing to prevent DLL hijacking?   Industry (not only Microsoft -- look at Toyota!) seems to be in a mode "don't fix until FUD reaches a level that might affect sales".   Would the patches you predict will be coming have been created without the "full-on snowball"?

  • Anonymous on

    Incorrect fact #1: "The user must open a document from a WebDAV share or a network file share". Create a link (.lnk) to the file and set the "Start In" property of that link. Then e-mail a HREF to that link file. - BANG - single click and you're infected. With no notification, and the original file loads without error. This works for docx and ppt file types (likely many others). You could achieve the same single click infection with .cmd, .ini, .bat, .vbs, etc, etc file types. Incorrect fact #2: "The attacker must guess what vulnerable software you have installed". You have heard of User Agent strings - yes? Since, Firefox, Opera and Safari are all exploitable, and you can force the file to open from a location you control with a linking file, where's the guesswork? Incorrect fact #3: "There are easier ways to trick a user". See above. Your position assumes facts 1 & 2 are accurate - they aren't. Incorrect fact #3: "Virus software can help" . Again, payload encoding and dynamic DLL generation make signature based protections utterly useless. The capability to update signatures to match the infinite possibilities via encoding make this statement nonsense. The opposite of FUD is CUM: Complacent, Uninformed and Marginalized. Congrats; this article achieves all three.
  • LC on

    Ouch!!! that pretty much sums it up.The truth hurts doesn't it!! :-)

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.