Researchers have discovered a code-injection vulnerability in the Windows operating system that cannot, because of the nature of the operating system, be patched. It could be used to bypass current malware protection solutions in place.
“Unfortunately,” writes enSilo researcher Tal Liberman in a report published Oct. 27, “this issue cannot be patched since it doesn’t rely on broken or flawed code — rather it’s a flaw in how these operating system mechanisms are designed.”
The attack technique has been labeled ‘AtomBombing‘. It manipulates Windows’ underlying Atom Tables mechanisms. Atom Tables are used to hold data strings. Applications place the strings into the table and receive back an ‘atom’ identifier for the string.
Windows has several different Atom Tables for different purposes. The Global Atom Table can be used to share data between different DDE applications. “Rather than passing actual strings, a DDE application passes global atoms to its partner application. The partner uses the atoms to obtain the strings from the atom table,” explains Microsoft’s own data sheet.
enSilo has discovered that an attacker can write malicious code into an atom table, and force a legitimate program to retrieve that malicious code. Furthermore, wrote Liberman, “We also found that the legitimate program, now containing the malicious code, can be manipulated to execute that code.”
The result is that maliciousness has been passed from an unknown malicious application to a known good application or process. While security defenses are on red alert to detect and block malicious applications, they often whitelist known good applications or processes. That is the attraction of ‘code injection’ as an attack vector: where it can be achieved, it can be used, notes Liberman, “to bypass security products, hide from the user, and extract sensitive information that would otherwise be unattainable.”
Liberman gives two examples of how AtomBomb code injection can help the attacker to access context-specific data. The first is taking screenshots. Processes can only do this from within the context of the user’s desktop. Malware, however, usually lands in the services desktop, and is unable to execute user screenshots. AtomBombing would allow the attacker to inject code from the services desktop into a process already running within the user desktop, take the screenshot, and pass it back to the malware in the services desktop.
The second example is access to encrypted passwords. Chrome, for example, encrypts users’ stored passwords using the Windows Data Protection API (DPAPI) together with data derived from the current user. Again, passwords can only be accessed from within the user context — which AtomBombing can achieve. “If the malware injects code into a process that’s already running in the context of the current user,” writes Liberman, “the plain-text passwords can be easily accessed.”
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. enSilo believes the issue is another argument for a shift of emphasis from attack prevention to consequence mitigation. “Under the assumption that threat actors will always exploit known and unknown techniques, we need to build our defenses in a way that prevents the consequences of the attack once the threat actor has already compromised the environment.”
