How do we mitigate the unpatched vulnerability “AtomBombing” code injection under Windows machines?

Question

Can the unpatched vulnerability called Atombombing bypass the security system's only by executing a malicious.exe program, or are there multiple ways to inject the malicious code?

What are the best practices to mitigate the unpatched vulnerability under Windows machines?

According to Securityweek, the code-injection vulnerability cannot be patched:

The problem for users is that AtomBombing cannot be fixed -- it's the way Windows works. With no chance of a patch, the solution is some other form of mitigation.

Answer 1

As far as I can guess (not completely sure):

Can the unpatched vulnerability called Atombombing bypass the security system's only by executing a malicious.exe program, or are there multiple ways to inject the malicious code?

First we must consider how Atom Bombing works:

It works by injecting some malicious code in the Windows Atom Tables. Atom tables are a kind of tables where any program can "save" some data strings to use later or to share with any other application.

So it gives any potential attacker the chance to use this method as a hijacking or privilege escalation vector, but not for a direct attack or intrusion.

Why? Well, unless another vulnerability/bug is used, Atom Tables can only be modified locally. That means: Only when you're already in, you can add something to the atom tables to inject malicious code.

So, there are multiple ways to exploit this vulnerability, BUT, when you're already IN (using a malicious.exe , exploiting another vulnerability to get into the system and then using Atombombing for privilege escalation, etc., etc.).

What are the best practices to mitigate the unpatched vulnerability under Windows machines?

The only way for Microsoft team to patch this would be removing the Atom Tables, or adding many extra security measures.

The easiest way to defend against this kind of threat, is just checking any atom data saved before using it (on programs) and/or any security system/program/module taking a look constantly on those Atom Entries.

The way to fix this shall be by using a pìece of software that checks periodically the Atom Table entries, looking for malicious code. That's probably going to be added by some anti-malware (or antivirus) firms.

You can check those articles for more information:

• To know more about the attack: http://blog.ensilo.com/atombombing-a-code-injection-that-bypasses-current-security-solutions
• To know more about the Atom Tables "API": https://msdn.microsoft.com/es-es/library/windows/desktop/ms649053(v=vs.85).aspx

Answer 2

The other coments forget something. An attacker can elevate from an unprivileged context (No administrator rights) into a privileged context (admin rights) if it runs into an account which is actually from an administrator. This is called an UAC Bypass.

The Attack

As you may be expecting, this attack involves code injection techniques, such as AtomBombombing (but in fact any other method, even the simple CreateRemoteThread will work).

This is done in 2 steps. The first thing to do is, effectively, inject code into certain processes that run in user mode. There are a few vulnerable processes but I'll be talking about explorer.exe which is also the most stable. This process is not like others, it is special since it has a lot of uses. That's why it has some special privileges. For example, the COM IFileOperation interface can be elevated; This means it will run with some kind of admin-like privileges. This may look useless, since you can only write files with admin rights. But it isn't! Since you can use that to perform another attack; DLL Hijacking. This is step 2. Basically you would place your evil.dll, which may be embebed in the evil.exe, into the same place where autoelevated processes are; Autoelevated programs or processes are programs that once executed will automatically get admin rights. Shortly, this is done by Microsoft since those programs must have those privileges to run correctly and perform things like automated tasks. Finally, we would execute that program, which will load the evil.dll and then auto elevate, therefore granting admin privileges to the attacker code.

Mitigation

Microsoft tried to patch the second step in the past, by whitelisting .dll files and similar techniques, but they failed, since we can easily bypass that just by replacing existing .dll files in some cases.

The first step is not going to be patched at all. Microsoft hasn't patched other injection methods like CreateRemoteThread, why would them patch Atombombing? That would require a huge effort and heavy modification of the OS, which is likely not going to happen. The only way to prevent that would be deleting those special rights from programs like the explorer but it seems like that's not going to happen neither. So basically it depends on AVs to detect if malicious programs will try to inject code using any method.

You can see a POC of the exploit above here

EDIT: I forgot some points of the question. So, this are the technical ways to prevent atombombing from having success: -API hooking: An antivirus solution may intercept and scan all attempts to modify the atom table. The functions GlobalAddAtom() and GlobalGetAtomName() are the ones used to perform this attack. They could intercept the calls and scan the data that is going to be added to the Atom table, searching for key words or more likely, trying to analize the data, if it's a shellcode.

Answer 3

A quick review of this attack clicked these points in my head:

First point

Victim have to run evil.exe to get exploited. Even if attacker somehow persuades victim to run evil.exe, because of the nature of this attack, evil.exe will only be able to inject code in processes running in same security context as evil.exe is running. So, no privilege escalation just by using this attack. (Maybe persuade victim to run evil.exe as Admin? That's not too difficult if victim is already persuaded to run it)

Second point

Code injection is needed because evil.exe could be blocked by Antivirus due to suspicious activity. So, code is injected in legitimate processes. But, browsers and other applications are not in whitelist of antiviruses too. Why would AV trust a browser when #1 source of malicious activity is web? Only whitelisted processes I have seen are svchost.exe and other system processes. Now, the attack requires an alterable thread to inject code into. But getting an alterable thread in system processes (that run in user security context) is difficult. But again, not impossible. And injecting shellcode to normal processes would also work. So this attack is still possible.

Third point

Heart of this attack is ROP chain. Didn't check the details of how ROP chain is implemented but ASLR is enabled on most of the processes now.

Mitigation

Possible mitigation I see is installing EMET. EMET monitors even low level VirtualAlloc functions for possible ROP. Haven't checked it myself but I'm pretty sure EMET will stop the ROP chain of this attack.