The Zero-Days Of Summer
Summer is coming to a close and yet another “zero-day” exploit is being reported (See here and here). It's not really a "zero-day", as it has been known for a long time; it’s more a design “quirk” or flaw in Windows, but the media likes to say zero-day, so I’ll oblige.
This one is going by the names “Binary Planting”, “DLL load hijacking”, and “DLL preloading”. According to ACROS Security, this vulnerability impacts around 200 widely used Windows applications, many of them from Microsoft. Another day, another zero-day, and the anti-malware vendors and Microsoft are forced to react, update malware signatures, and provide security updates.
This one is a little more pernicious because it involves behavior that many applications rely upon. Microsoft does not have a simple patch for this problem. Rather, they have introduced an update that allows you to create registry entries that may thwart such attacks but requires some pretty heavy lifting (i.e. forethought on the part of the system administrator to use properly). What a pain.
What is interesting is that this zero-day, almost by definition, is exactly the type of attack that whitelisting mitigates. We at Bit9 are not changing a thing in reaction to this latest vulnerability because Parity already stops it.
Let's break it down in simple terms. Most Windows applications contain or rely upon dozens of independent files. These files are dynamically loaded when the application runs – hence the term Dynamic-Link Library (DLL). (Note: Acros Security claims the vulnerability can also impact EXE and COM files, but the principle behind the vulnerability is the same.) When a Windows application loads a DLL file, if it doesn’t specify a full path to that file, Windows will search a predefined set of locations. This allows programs to use shared files in the Windows System folder or anywhere in your PATH environment variable, for example, without any heavy lifting. The application simply needs to specify the filename.
If an attacker can place a file with the same name at a search location before the legitimate version of that file, they can get their code to run – with all the elevated privileges that your application has. Essentially, this solves the second of the two key problems that an attacker must overcome: the first is that they must get their program onto your system; the second is they must find a way to launch that code, ideally bypassing any privilege restrictions. As a bonus, they get a level of stealth because you won’t see any “strange” processes running, and if you were to look at the names of the libraries loaded in memory, you likely won’t see anything suspicious.
(Note: The attacker still needs to get their file onto your system at the right location, or trick you into opening a document from a remote location where their malicious library is present. Therefore, it is likely that an effective use of this vulnerability will still involve using other exploits or social engineering as part of the attack.)
This entire problem is non-existent if you are using an advanced whitelisting solution like Parity. Parity only allows files that are approved to load; it doesn’t matter whether they are in the Windows search path or even in the same folder as a legitimate application. It’s really very simple -- even if the application (or executable) is approved, if it tries to load an unknown or unapproved library, it will be stopped.
This exploit is also a great case study on the limitations of blacklisting. Since the attack can take the form of any known filename in any possible location, there is no malware “signature” that can be used to stop it globally. Only once an instance of such an attack is discovered can a signature be reactively made. Anti-malware technologies may be able to stop some of the vectors by which the file is placed, but unless the file is known bad, its simple existence in an unexpected location is not a good enough trait to build a blacklist signature.
It's also worth noting that other reactive technologies, such as HIPS, would be equally ineffective at stopping this type of attack. A HIPS product looks for suspicious or bad network activity. So, by definition, the malware would already have to be loaded into memory and running before HIPS would be able to detect anything. Moreover, most modern attacks remain stealth, dormant or avoid suspicious network activity. They can do a lot of damage without triggering any HIPS-detectable behavior. Lastly, like anti-malware, HIPS technology is only as good as its latest rules, which need to be updated continually in response to known bad activity, bad IP addresses, etc.
If you’re waiting for your AV or HIPS vendor to fully protect you from this one, good luck.
There are still a few days left in summer. We’ll wait and see what zero-days are lurking in the shadows. But while the blacklisting vendors keep chasing their tails reacting to each new exploit, I’m thinking I might sneak in a few more days at the beach.