Knee-jerk reactions aren’t required
“By Tony Campbell, APSM Correspondent”
Details of an allegedly un-patchable code injection technique, persistent in all versions of Microsoft’s Windows operating system including Windows 10, have been released by security researchers from enSilo (http://blog.ensilo.com/atombombing-a-code-injection-that-bypasses-current-security-solutions). If this is really un-patchable, what can security teams do to about it?
enSilo claims that this attack vector is particularly troublesome and insidious, since the manipulation of Windows atom tables (https://msdn.microsoft.com/en-us/library/windows/desktop/ms649053%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396) is a basic low-level operating system function and, because it’s not a vulnerability as such, rather it’s there by design to allow processes to share data, there is nothing Microsoft can do about it. enSilo’s suggestion is that organisations should monitor for suspicious changes within application programming interface (API) calls to give themselves a chance of protecting against exploits using this OS feature. Furthermore, in the glorious tradition of modern vulnerability disclosures, they have dubbed their discovery with the emotive, media-friendly name, “AtomBombing.” Sounds scary, right?
I have a few suggestions. Firstly, enSilo claims that all it takes is for a threat actor to get evil.exe onto the victim’s computer then all bets are off. evil.exe can then inject whatever code it likes into running processes to make those processes do whatever they want. Well, it’s not quite as easy as that. They’ll need to find a process that will accept that injected code and allow it to be misused, turning what would normally be innocuous data into some kind of operational code. I agree it’s a potential threat, but it’s hard to exploit – you need to know which processes are running, what they are sharing and have found a process with inherent vulnerabilities that allow it to be misused as executable code – so it’s unlikely and hard. Furthermore, most operating systems have the built-in tools to prevent evil.exe from running in the first place. On Mac OS X, the computer pops up a box that says, you downloaded this file, evil.exe, from the Internet, are you sure you want to run it? Click NO. Moreover, if you do run it and tries to inject code into another application, the injection will only work with processes running in the same user context – so make sure your user accounts use the minimum privileges needed to do their job.
If you have Windows systems, look at application whitelisting to stop evil.exe from executing. Whitelisting is hard to do well and is harder if you have BYOD devices since you can’t enforce central policies, but that’s only because no one’s figured out how to make this security control really user friendly. If we had a big red button that says, “Protect me from dodgy stuff,” which, when turned on, you could only introduce new executables that have been authorised by the user. This would be a good step forward. Even now, administrators can use application whitelisting in monitor mode rather than blocking and pass any new detections of unauthorised applications to their Security Operations Centre, allowing analysts to at least see what new applications have been run.
My own opinion is that the AtomBombing attack vector is only un-patchable when Microsoft has released a statement to say as much. Maybe there is a way to use code signing to authenticate processes with each other in terms of the ones that are authorised to run on the system – then it may be possible to attribute a level of confidence to inter-process communications attesting to their legitimacy. If anyone needs an overview of code signing and how it works, take a look here (https://msdn.microsoft.com/en-us/library/ms537361%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396). This capability is already built into Windows today, so may be a good place to start looking. I’d warn anyone of vendors selling application communication control products that tell you a new threat exists that only their product will defend against. Do your own research, ask an expert and if necessary, reach out to your Microsoft account manager and ask their advice as to what you should do. Whatever you do, don’t make a rash decision to purchase yet more technology to fix a point solution in your security defences.
