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.
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.
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.
Good write up by Oliver Lavery, Director of Security Research and Development @ nCricle.
Less technical and more risk-based.