My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Windows "Atom Bombing" Attack

Published: 2016-10-28. Last Updated: 2016-10-28 14:00:57 UTC
by Johannes Ullrich (Version: 1)
4 comment(s)

Earlier this week, Ensilo released a blog describing a new code injection attack via Windows Atom Tables [1]. The attack is pretty ingenious and could be used to inject malicious code into running processes or read data from running processes.

Overall, the problem of code injection isn't new, and there are different methods to accomplish code injection. Code injection in its simple form doesn't lead to privilege escalation, nor does it expose your system to new exploits. However, it is a technique that an attacker may use to hide code they are executed as a result of an exploit. Most security tools will whitelist software that you commonly run. Some will even check if the software is modified after it is executed.

Atom tables are a Windows feature meant to allow software to store data, and in some cases to share data with other applications. A user has read/write access to all atom table data created by processes that the user initiated. The result is that malware that the user runs may retrieve data stored to atom tables by other software, or it may modify it to execute malicious code.

Overall, there is no fix expected for this problem. This isn't even a security vulnerability in its current form. Users can always run code and code a user runs typically does have some access to other processes run by the same user (sometimes limited by sandboxing). 

So what does this all mean for you? Not much. It was always bad to run malware, and this is yet another way how malware can hide on your system. There is nothing you have to change in the way you are doing things due to this issue. Future versions of anti-malware may be able to intercept respective API calls to inspect any read/write access to these atom tables.

[1] http://blog.ensilo.com/atombombing-a-code-injection-that-bypasses-current-security-solutions

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Keywords:
4 comment(s)
My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Comments

Windows, back at it again, "It's not a vulnerability, its a feature!"
[quote=comment#38171]Windows, back at it again, "It's not a vulnerability, its a feature!"[/quote]

It's neither a feature NOR a vulnerability!

If you have write access to (the virtual memory of) another process you can create a remote thread there or issue an ALPC.
Since Windows only grants access to other processes of your own userid you gain NOTHING: instead of this rather clumsy double indirect code execution you can run the shellcode direct in you own process!

JFTR: instead of an atom string you can also use a registry entry, a (named) pipe, a mailslot, shared memory (for example the buffer used by OutputDebugString()), environment variables etc. to transfer a string from one process into another.
"Windows, back at it again, "It's not a vulnerability, its a feature!""

Maybe you can explain how other OSs handle this?
It's true that "if you have write access" then you can just schedule a thread, and use some other arbitrary stash like a registry value to transfer more code/data. But you still need to start that flow with some code you control in the target process. On the other hand, the beauty of the "atom bombing" approach is that you don't have to *directly* write your initial code to the target process to begin with, e.g. using VirtualAllocEx and WriteProcessMemory, which are often monitored by security tools. Your "initial code" is already in the target process: GlobalGetAtomName, which allows you to specify an output buffer for your shellcode. So you can basically write to your target process without using a heat-up API function.

Diary Archives